commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@btopenworld.com>
Subject Re: [lang] System properties
Date Sun, 25 Aug 2002 22:29:09 GMT
I have committed these additional system properties to the SystemUtils file.
The system properties seem uncontroversial, so hopefully this is OK.

I also added two Java version handling methods - float getJavaVersion() and
is JavaVersionAtLeast(float). These handle three digit version numbers. eg.
JDK 1.3.1 is 1.31f.

I have commented out the OS parsing code. Its still there, but not in use.
Maybe the class could go in the 1.0 release as it now stands?? It really
depends on how people feel about the Java parsing methods/constants.

Stephen


----- Original Message -----
From: "Steve Downey" <steve.downey@netfolio.com>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Sent: Friday, August 23, 2002 9:29 PM
Subject: RE: [lang] System properties


> Here's a version that incorporates all of the system properties that I'm
> aware of. Javadocs updated to reflect what property, the description of
the
> property, and what JDK the property first appeared in.
>
>
> > -----Original Message-----
> > From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
> > Sent: Friday, August 23, 2002 2:02 PM
> > To: Jakarta Commons Developers List
> > Subject: Re: [lang] System properties
> >
> >
> > I would support this, leave the parsing until 1.1.
> >
> > Except that Steve has just suggested that there are other keys
> > not included
> > yet...
> >
> > Stephen
> >
> >
> > > May be it is better to define constants without any parsing at
> > this time ?
> > .
> > >
> > >
> > > > From: "Steve Downey" <steve.downey@netfolio.com>
> > > > > +1 on collecting all of these into one place. I hate having
> > to look up
> > > the
> > > > > spelling of something like java.vm.specification.version.
> > > > >
> > > > > I think the IS_JAVA_VERSION should come from
> > java.specification.version,
> > > > > rather than stripping off the leading part of java.version.
> > > >
> > > > I declared all the Strings defined in my JDK 1.3 System
> > class. It didn't
> > > > specify java.specification.version. Is this a JDK 1.4 thing? (BTW:
The
> > > > stripping comes from Lucene)
> > > >
> > > > > It might also be nice to have a test for 'is at least'. IOW, to
use
> > > > > java.nio, the version should be at least 1.4. To use
> > collections, the
> > > > > version should be at least 1.2.
> > > >
> > > > +1
> > > >
> > > > > Adding the rest of the standard system properties would probably
be
> > > good,
> > > > > even if some of them are kind of rarely used, i.e.
> > > > > java.specification.vendor.
> > > >
> > > > Do you know where the full list is? I just declared those in
> > the source
> > > code
> > > > of JDK 1.3.
> > > >
> > > > > Naming should probably be absolutely consistent with the defined
> > > property
> > > > > names. That is USER_DIR, instead of USER_WORKING_DIRECTORY. If you
> > feel
> > > > you
> > > > > really need USER_WORKING_DIRECTORY, make it an alias [ public
static
> > > final
> > > > > USER_WORKING_DIRECTORY = USER_DIR; ]
> > > >
> > > > You're probably right,
> > > >
> > > > Stephen
> > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
> > > > > > Sent: Thursday, August 22, 2002 6:28 PM
> > > > > > To: Jakarta Commons Developers List
> > > > > > Subject: Re: [lang] System properties
> > > > > >
> > > > > >
> > > > > > To save loosing any ideas or code, I've written and committed
a
> > > > > > SystemUtils
> > > > > > to [lang]. It draws from
> > > > > > - my code
> > > > > > - Avalon code
> > > > > > - Lucene code
> > > > > > thus is in best traditions of commons.
> > > > > >
> > > > > > It excludes the CPU parser from Avalon that I think is
> > controversial.
> > > > This
> > > > > > can be added later if people want it, or could be a candidate
for
> > > > > > [threading] or [cpu].
> > > > > >
> > > > > > If someone has a violent objection to the class, or has
> > > > > > suggestions, please
> > > > > > feel free to discuss. There are no tests at present.
> > > > > >
> > > > > > I committed because I felt enough people thought it seemed good
> > > > > > if I avoided
> > > > > > CPUs.
> > > > > >
> > > > > > Stephen
> > > > > >
> > > > > > ----- Original Message -----
> > > > > > From: "Stephen Colebourne" <scolebourne@btopenworld.com>
> > > > > > To: "Jakarta Commons Developers List"
> > <commons-dev@jakarta.apache.org>
> > > > > > Sent: Thursday, August 22, 2002 9:52 PM
> > > > > > Subject: Re: [lang] System properties
> > > > > >
> > > > > >
> > > > > > > We could have a SystemUtils class without the Avalon CPU
> > > > > > parsing code, but
> > > > > > > with the other parts of the class. I accept that this won't
> > > > > > solve Avalons
> > > > > > > problems.
> > > > > > >
> > > > > > > The code I have suggested today is new and wasn't considered
> > before.
> > > > > > >
> > > > > > > Stephen
> > > > > > >
> > > > > > > ----- Original Message -----
> > > > > > > From: "Henri Yandell" <bayard@generationjava.com>
> > > > > > > To: "Jakarta Commons Developers List"
> > > > <commons-dev@jakarta.apache.org>;
> > > > > > > <bloritsch@apache.org>
> > > > > > > Sent: Thursday, August 22, 2002 9:35 PM
> > > > > > > Subject: RE: [lang] System properties
> > > > > > >
> > > > > > >
> > > > > > > > -1.
> > > > > > > >
> > > > > > > > We've already reviewed the Avalon System api with
respect to
> > > > > > going into
> > > > > > > > Lang 1.0. I'm pretty sure the people involved in that
review
> > have
> > > > not
> > > > > > > > changed wrt this review, so why should we re-review?
> > > > > > > >
> > > > > > > > If we should, could someone post what has changed?
[Apart
from
> > > > Stephen
> > > > > > > > having a class ;)]
> > > > > > > >
> > > > > > > > Hen
> > > > > > > >
> > > > > > > > On Thu, 22 Aug 2002, Berin Loritsch wrote:
> > > > > > > >
> > > > > > > > > +1
> > > > > > > > >
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From: Stephen Colebourne
> > [mailto:scolebourne@btopenworld.com]
> > > > > > > > > > Sent: Thursday, August 22, 2002 4:24 PM
> > > > > > > > > > To: Jakarta Commons Developers List
> > > > > > > > > > Subject: Re: [lang] System properties
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > > How about a SystemUtils for [lang]
?
> > > > > > > > > > >
> > > > > > > > > > > +1.  The one from Avalon could be used
as the basis.
> > > > > > > > > >
> > > > > > > > > > Just to confirm - the one in Avalon consists
of
> > SystemUtils
> > > > > > > > > > plus 6 pluggable implementations to get
the number of
CPUs
> > > > > > > > > > etc. on a particular machine/OS. Are you
(and
> > others) +1 on
> > > > > > > > > > including this. And Berin is Avalon happy
for the
> > code to be
> > > > > > > > > > adopted by [lang].
> > > > > > > > > >
> > > > > > > > > > Stephen
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > To unsubscribe, e-mail:
> > > > > > > > > > <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> > > > > > > > > > For
> > > > > > > > > > additional commands,
> > > > > > > > > > e-mail: <mailto:commons-dev-help@jakarta.apache.org>
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > To unsubscribe, e-mail:
> > > > > > > <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> > > > > > > > > For additional commands, e-mail:
> > > > > > > <mailto:commons-dev-help@jakarta.apache.org>
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > To unsubscribe, e-mail:
> > > > > > > <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> > > > > > > > For additional commands, e-mail:
> > > > > > > <mailto:commons-dev-help@jakarta.apache.org>
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > To unsubscribe, e-mail:
> > > > > > <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> > > > > > > For additional commands, e-mail:
> > > > > > <mailto:commons-dev-help@jakarta.apache.org>
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > To unsubscribe, e-mail:
> > > > > > <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> > > > > > For additional commands, e-mail:
> > > > > > <mailto:commons-dev-help@jakarta.apache.org>
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > To unsubscribe, e-mail:
> > > > <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> > > > > For additional commands, e-mail:
> > > > <mailto:commons-dev-help@jakarta.apache.org>
> > > > >
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > > <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> > > > For additional commands, e-mail:
> > > <mailto:commons-dev-help@jakarta.apache.org>
> > > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> > > For additional commands, e-mail:
> > <mailto:commons-dev-help@jakarta.apache.org>
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail:
> > <mailto:commons-dev-help@jakarta.apache.org>
> >
> >
> >
>


----------------------------------------------------------------------------
----


> --
> To unsubscribe, e-mail:
<mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:commons-dev-help@jakarta.apache.org>


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message