[5346] in java-interest
Properties design questions, and more questions
daemon@ATHENA.MIT.EDU (Anselm Baird-Smith)
Tue Feb 6 11:33:20 1996
Date: Thu, 1 Feb 1996 10:06:38 +0500
From: abaird@w3.org (Anselm Baird-Smith)
To: java-interest@java.sun.com
Reply-To: Anselm Baird-Smith <abaird@w3.org>
I don't undertsand the current design for properties:
- why is it split accross all base class - eg Integer.getInteger() -
instead of in the Properties object itself - eg
Properties.getInteger ?
- How can I cope with multiple set of properties: I have an object
that gets all its configuration from properties. I may have multiple
instances of this object, each of them might want its own set of
properties (ie I can't use System.*), hence my first question.
- How can I deal with dynamic changes in properties. The Properties
object provide no ways of monitoring property values, and I don't
want to parse each property value on each access. (right now, I
cache property values in instance variables).
Given all this, I am about to subclass the Properties class, and make
an object that fullfill the above needs, however I am wondering if I
am using properties in the right way (should I just drop them in
favor of some specific configuration file, is the Properties class
meant to be subclassed on a per-application basis).
-----
While I am at it, I have problems with IO operations: most of them are
uninterruptible, which makes writing a server somehow difficult. I
have cope with interrupting read() calls through the following hack:
Server.T1: blocks on socket.read()
Server.T2: close (socket); socket = null; T1.stop(); T1=null ;
This works for read (well, at least on solaris), but I had no lack
with socket.accept(), which I definitely want to interrupt, typically
to shutdown the server properly (is the Thread.interrupt() method
meant to interrupt threads in system calls ? why IO operations doesn't
throw the InterruptedException (ala Modula Alert stuff) ?).
-----
While I am at it, writing native methods that makes system calls is
quite difficult without having some Greeen thread C interface. I have
some native method that interface to UNIX {send|rec}msg(). In order to make
it works nicely, I had to pool - select() -, before calling recmsg()
otherwise, the whole Java runtime would block in the recmsg call
(well, this is a supposition on what I have observed). I believe my
wish is to have the Java runtime use native threads, so that this
problem would disapear by itself.
Thanks for your attention,
Anselm.
-
This message was sent to the java-interest mailing list
Info: send 'help' to java-interest-request@java.sun.com
