You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@commons.apache.org by Stephen Colebourne <sc...@btopenworld.com> on 2002/08/22 21:58:53 UTC

[lang] System properties

One part I find inconvenient about Java is the system properties. These are
looked up by a string name, and I can never remember what the name is, so I
have to go and look it up the javadoc - a great waste of time.

The following code, is the solution in my library. Although seemingly
trivial, it means that any IDE can use code completion to pick the value
without needing to remember the string name.

    public static final String LINE_SEPARATOR =
System.getProperty("line.separator");
    public static final String PATH_SEPARATOR =
System.getProperty("path.separator");
    public static final String FILE_SEPARATOR =
System.getProperty("file.separator");
    public static final String WORKING_DIRECTORY =
System.getProperty("user.dir");
    public static final String OS_NAME = System.getProperty("os.name");
    public static final String OS_ARCH = System.getProperty("os.arch");
    public static final String OS_VERSION =
System.getProperty("os.version");
    public static final String JAVA_VERSION =
System.getProperty("java.version");

How about a SystemUtils for [lang] ?

Stephen


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [lang] System properties

Posted by Juozas Baliuka <ba...@centras.lt>.

+1
I need DEFAULT_FILE_ENCODING too (sometimes have problems with i18n)
----- Original Message -----
From: "Stephen Colebourne" <sc...@btopenworld.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Thursday, August 22, 2002 9:58 PM
Subject: [lang] System properties


> One part I find inconvenient about Java is the system properties. These
are
> looked up by a string name, and I can never remember what the name is, so
I
> have to go and look it up the javadoc - a great waste of time.
>
> The following code, is the solution in my library. Although seemingly
> trivial, it means that any IDE can use code completion to pick the value
> without needing to remember the string name.
>
>     public static final String LINE_SEPARATOR =
> System.getProperty("line.separator");
>     public static final String PATH_SEPARATOR =
> System.getProperty("path.separator");
>     public static final String FILE_SEPARATOR =
> System.getProperty("file.separator");
>     public static final String WORKING_DIRECTORY =
> System.getProperty("user.dir");
>     public static final String OS_NAME = System.getProperty("os.name");
>     public static final String OS_ARCH = System.getProperty("os.arch");
>     public static final String OS_VERSION =
> System.getProperty("os.version");
>     public static final String JAVA_VERSION =
> System.getProperty("java.version");
>
> How about a SystemUtils for [lang] ?
>
> Stephen
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [lang] System properties

Posted by Daniel Rall <dl...@finemaltcoding.com>.

Henri Yandell <ba...@generationjava.com> writes:

> Only thing in SystemUtils that strikes me as odd is a lack of an
> IS_MAC_OSX. Or is that IS_MAC?
> 
> It's important to be able to differentiate between OS9- and OSX+ as
> they're so utterly different. Lots of install scripts contain special bits
> for 'darwin' because it has an odd Java structure.

And in many system-level respects is just unix.  So yes, +1 on
explicit support for Darwin.
-- 

Daniel Rall <dl...@finemaltcoding.com>

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [lang] System properties

Posted by Henri Yandell <ba...@generationjava.com>.

Only thing in SystemUtils that strikes me as odd is a lack of an
IS_MAC_OSX. Or is that IS_MAC?

It's important to be able to differentiate between OS9- and OSX+ as
they're so utterly different. Lots of install scripts contain special bits
for 'darwin' because it has an odd Java structure.

Hen


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [lang] System properties

Posted by Daniel Rall <dl...@finemaltcoding.com>.

"Stephen Colebourne" <sc...@btopenworld.com> writes:

> From: "Daniel Rall" <dl...@collab.net>
> > Sounds okay to me.  Pluggability in the Commons is fine so long as it
> > doesn't encroach into framework-land.
> 
> Daniel, could you define what you mean by framework? Different people mean
> different things (and that is one of the main causes of arguments in
> commons)

I agree that framework means different things to different people.  I
was quoting the Commons charter.

http://www.dictionary.com/search?q=framework

   1. A structure for supporting or enclosing something else,
   especially a skeletal support used as the basis for something being
   constructed.

   2. An external work platform; a scaffold.

These two seem the most appropriate, but of course they don't take
into account the domain-specific semantics of our work.
-- 

Daniel Rall <dl...@finemaltcoding.com>

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [lang] System properties

Posted by Stephen Colebourne <sc...@btopenworld.com>.

From: "Daniel Rall" <dl...@collab.net>
> Sounds okay to me.  Pluggability in the Commons is fine so long as it
> doesn't encroach into framework-land.

Daniel, could you define what you mean by framework? Different people mean
different things (and that is one of the main causes of arguments in
commons)

Stephen


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [lang] System properties

Posted by Daniel Rall <dl...@collab.net>.

"Stephen Colebourne" <sc...@btopenworld.com> writes:

> > > 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].

Sounds okay to me.  Pluggability in the Commons is fine so long as it
doesn't encroach into framework-land.
-- 

Daniel Rall <dl...@finemaltcoding.com>

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [lang] System properties

Posted by Nicola Ken Barozzi <ni...@apache.org>.

Stephen Colebourne wrote:
...

> I committed because I felt enough people thought it seemed good if I avoided
> CPUs.

Please reread it sloooowly...  ;-)

Gosh, sometimes I smile at how really funny these discussions are to 
non-technical people.

My girlfriend is always picking on me because I use shells but I don't 
go to the sea, I branch without touching wood and now... to avoid CPUs 
it's good to commit! ;-))

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [lang] System properties

Posted by Juozas Baliuka <ba...@centras.lt>.

Ok,
I see we will not implement any good parsing at this time.

> 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" <st...@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" <sc...@btopenworld.com>
> > > > > To: "Jakarta Commons Developers List"
> <co...@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" <ba...@generationjava.com>
> > > > > > To: "Jakarta Commons Developers List"
> > > <co...@jakarta.apache.org>;
> > > > > > <bl...@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: <ma...@jakarta.apache.org>
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > To unsubscribe, e-mail:
> > > > > > <ma...@jakarta.apache.org>
> > > > > > > > For additional commands, e-mail:
> > > > > > <ma...@jakarta.apache.org>
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > To unsubscribe, e-mail:
> > > > > > <ma...@jakarta.apache.org>
> > > > > > > For additional commands, e-mail:
> > > > > > <ma...@jakarta.apache.org>
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > To unsubscribe, e-mail:
> > > > > <ma...@jakarta.apache.org>
> > > > > > For additional commands, e-mail:
> > > > > <ma...@jakarta.apache.org>
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > To unsubscribe, e-mail:
> > > > > <ma...@jakarta.apache.org>
> > > > > For additional commands, e-mail:
> > > > > <ma...@jakarta.apache.org>
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > > <ma...@jakarta.apache.org>
> > > > For additional commands, e-mail:
> > > <ma...@jakarta.apache.org>
> > > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [lang] System properties

Posted by Juozas Baliuka <ba...@centras.lt>.

Hi,
I prefer interface for constants like "SystemProperties", it can be used
this way :

 class SystemUtils implements SystemProperties {
  .............................
}

 class MyClass implements SystemProperties{

   MyClass(){

      System.out.println ( JAVA_CLASS_PATH );
      System.out.println ( SystemUtils.JAVA_CLASS_PATH );
     System.out.println (  SystemProperties.JAVA_CLASS_PATH );

   }


}





----- Original Message -----
From: "Steve Downey" <st...@netfolio.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Friday, August 23, 2002 10: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" <st...@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" <sc...@btopenworld.com>
> > > > > > To: "Jakarta Commons Developers List"
> > <co...@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" <ba...@generationjava.com>
> > > > > > > To: "Jakarta Commons Developers List"
> > > > <co...@jakarta.apache.org>;
> > > > > > > <bl...@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: <ma...@jakarta.apache.org>
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > To unsubscribe, e-mail:
> > > > > > > <ma...@jakarta.apache.org>
> > > > > > > > > For additional commands, e-mail:
> > > > > > > <ma...@jakarta.apache.org>
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > To unsubscribe, e-mail:
> > > > > > > <ma...@jakarta.apache.org>
> > > > > > > > For additional commands, e-mail:
> > > > > > > <ma...@jakarta.apache.org>
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > To unsubscribe, e-mail:
> > > > > > <ma...@jakarta.apache.org>
> > > > > > > For additional commands, e-mail:
> > > > > > <ma...@jakarta.apache.org>
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > To unsubscribe, e-mail:
> > > > > > <ma...@jakarta.apache.org>
> > > > > > For additional commands, e-mail:
> > > > > > <ma...@jakarta.apache.org>
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > To unsubscribe, e-mail:
> > > > <ma...@jakarta.apache.org>
> > > > > For additional commands, e-mail:
> > > > <ma...@jakarta.apache.org>
> > > > >
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > > <ma...@jakarta.apache.org>
> > > > For additional commands, e-mail:
> > > <ma...@jakarta.apache.org>
> > > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
> >
> >
>


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


> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [lang] System properties

Posted by Stephen Colebourne <sc...@btopenworld.com>.

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" <st...@netfolio.com>
To: "Jakarta Commons Developers List" <co...@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" <st...@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" <sc...@btopenworld.com>
> > > > > > To: "Jakarta Commons Developers List"
> > <co...@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" <ba...@generationjava.com>
> > > > > > > To: "Jakarta Commons Developers List"
> > > > <co...@jakarta.apache.org>;
> > > > > > > <bl...@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: <ma...@jakarta.apache.org>
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > To unsubscribe, e-mail:
> > > > > > > <ma...@jakarta.apache.org>
> > > > > > > > > For additional commands, e-mail:
> > > > > > > <ma...@jakarta.apache.org>
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > To unsubscribe, e-mail:
> > > > > > > <ma...@jakarta.apache.org>
> > > > > > > > For additional commands, e-mail:
> > > > > > > <ma...@jakarta.apache.org>
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > To unsubscribe, e-mail:
> > > > > > <ma...@jakarta.apache.org>
> > > > > > > For additional commands, e-mail:
> > > > > > <ma...@jakarta.apache.org>
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > To unsubscribe, e-mail:
> > > > > > <ma...@jakarta.apache.org>
> > > > > > For additional commands, e-mail:
> > > > > > <ma...@jakarta.apache.org>
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > To unsubscribe, e-mail:
> > > > <ma...@jakarta.apache.org>
> > > > > For additional commands, e-mail:
> > > > <ma...@jakarta.apache.org>
> > > > >
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > > <ma...@jakarta.apache.org>
> > > > For additional commands, e-mail:
> > > <ma...@jakarta.apache.org>
> > > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
> >
> >
>


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


> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: [lang] System properties

Posted by Steve Downey <st...@netfolio.com>.

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" <st...@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" <sc...@btopenworld.com>
> > > > > To: "Jakarta Commons Developers List"
> <co...@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" <ba...@generationjava.com>
> > > > > > To: "Jakarta Commons Developers List"
> > > <co...@jakarta.apache.org>;
> > > > > > <bl...@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: <ma...@jakarta.apache.org>
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > To unsubscribe, e-mail:
> > > > > > <ma...@jakarta.apache.org>
> > > > > > > > For additional commands, e-mail:
> > > > > > <ma...@jakarta.apache.org>
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > To unsubscribe, e-mail:
> > > > > > <ma...@jakarta.apache.org>
> > > > > > > For additional commands, e-mail:
> > > > > > <ma...@jakarta.apache.org>
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > To unsubscribe, e-mail:
> > > > > <ma...@jakarta.apache.org>
> > > > > > For additional commands, e-mail:
> > > > > <ma...@jakarta.apache.org>
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > To unsubscribe, e-mail:
> > > > > <ma...@jakarta.apache.org>
> > > > > For additional commands, e-mail:
> > > > > <ma...@jakarta.apache.org>
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > > <ma...@jakarta.apache.org>
> > > > For additional commands, e-mail:
> > > <ma...@jakarta.apache.org>
> > > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
>

Re: [lang] System properties

Posted by Stephen Colebourne <sc...@btopenworld.com>.

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" <st...@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" <sc...@btopenworld.com>
> > > > To: "Jakarta Commons Developers List"
<co...@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" <ba...@generationjava.com>
> > > > > To: "Jakarta Commons Developers List"
> > <co...@jakarta.apache.org>;
> > > > > <bl...@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: <ma...@jakarta.apache.org>
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > To unsubscribe, e-mail:
> > > > > <ma...@jakarta.apache.org>
> > > > > > > For additional commands, e-mail:
> > > > > <ma...@jakarta.apache.org>
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > To unsubscribe, e-mail:
> > > > > <ma...@jakarta.apache.org>
> > > > > > For additional commands, e-mail:
> > > > > <ma...@jakarta.apache.org>
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > To unsubscribe, e-mail:
> > > > <ma...@jakarta.apache.org>
> > > > > For additional commands, e-mail:
> > > > <ma...@jakarta.apache.org>
> > > > >
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > > > <ma...@jakarta.apache.org>
> > > > For additional commands, e-mail:
> > > > <ma...@jakarta.apache.org>
> > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: [lang] System properties

Posted by Steve Downey <st...@netfolio.com>.

I think that's a firmer base to start from. From there things can be added.
Perhaps as methods, rather than as attributes. Keep the attribute identical
to the system property, but provide some downward compatibility in the
methods, ie:

static public String getJavaSpecificationVersion() {
  if (JAVA_SPECIFICATION_VERSION != null) {
    return JAVA_SPECIFICATION_VERSION;
  } else if (JAVA_VERSION.startsWith("1.1.") {
    return "1.1";
  } else {
    return null;
  }
}

> -----Original Message-----
> From: Juozas Baliuka [mailto:baliuka@centras.lt]
> Sent: Friday, August 23, 2002 1:46 PM
> To: Jakarta Commons Developers List
> Subject: Re: [lang] System properties
>
>
>
> May be it is better to define constants without any parsing at
> this time ? .
>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [lang] System properties

Posted by Juozas Baliuka <ba...@centras.lt>.

May be it is better to define constants without any parsing at this time ? .


> From: "Steve Downey" <st...@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" <sc...@btopenworld.com>
> > > To: "Jakarta Commons Developers List" <co...@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" <ba...@generationjava.com>
> > > > To: "Jakarta Commons Developers List"
> <co...@jakarta.apache.org>;
> > > > <bl...@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: <ma...@jakarta.apache.org>
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > To unsubscribe, e-mail:
> > > > <ma...@jakarta.apache.org>
> > > > > > For additional commands, e-mail:
> > > > <ma...@jakarta.apache.org>
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > To unsubscribe, e-mail:
> > > > <ma...@jakarta.apache.org>
> > > > > For additional commands, e-mail:
> > > > <ma...@jakarta.apache.org>
> > > > >
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > > <ma...@jakarta.apache.org>
> > > > For additional commands, e-mail:
> > > <ma...@jakarta.apache.org>
> > > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > > <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > > <ma...@jakarta.apache.org>
> > >
> > >
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: [lang] System properties

Posted by Steve Downey <st...@netfolio.com>.

Here's the list I gathered from the JDK API docs for System.getProperties(),
the Spec_Version is the first time the property was added.

I see that java.specification.version wasn't added until 1.2, which is
probably why Lucene is working around it.

Property Name	Description	Spec_Version
file.separator	File separator ("/" on UNIX)	1.1
java.class.path	Java class path	1.1
java.class.version	Java class format version number	1.1
java.compiler	Name of JIT compiler to use	1.4
java.ext.dirs	Path of extension directory or directories	1.3
java.home	Java installation directory	1.1
java.io.tmpdir	Default temp file path	1.4
java.library.path	List of paths to search when loading libraries	1.4
java.specification.name	Java Runtime Environment specification name	1.2
java.specification.vendor	Java Runtime Environment specification vendor	1.2
java.specification.version	Java Runtime Environment specification version
1.2
java.vendor	Java vendor-specific string	1.1
java.vendor.url	Java vendor URL	1.1
java.version	Java version number	1.1
java.vm.name	Java Virtual Machine implementation name	1.2
java.vm.specification.name	Java Virtual Machine specification name	1.2
java.vm.specification.vendor	Java Virtual Machine specification vendor	1.2
java.vm.specification.version	Java Virtual Machine specification version	1.2
java.vm.vendor	Java Virtual Machine implementation vendor	1.2
java.vm.version	Java Virtual Machine implementation version	1.2
line.separator	Line separator ("\n" on UNIX)	1.1
os.arch	Operating system architecture	1.1
os.name	Operating system name	1.1
os.version	Operating system version	1.1
path.separator	Path separator (":" on UNIX)	1.1
user.dir	User's current working directory	1.1
user.home	User's home directory	1.1
user.name	User's account name	1.1


> -----Original Message-----
> From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
> Sent: Friday, August 23, 2002 1:47 PM
> To: Jakarta Commons Developers List
> Subject: Re: [lang] System properties
>
>
> From: "Steve Downey" <st...@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" <sc...@btopenworld.com>
> > > To: "Jakarta Commons Developers List" <co...@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" <ba...@generationjava.com>
> > > > To: "Jakarta Commons Developers List"
> <co...@jakarta.apache.org>;
> > > > <bl...@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: <ma...@jakarta.apache.org>
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > To unsubscribe, e-mail:
> > > > <ma...@jakarta.apache.org>
> > > > > > For additional commands, e-mail:
> > > > <ma...@jakarta.apache.org>
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > To unsubscribe, e-mail:
> > > > <ma...@jakarta.apache.org>
> > > > > For additional commands, e-mail:
> > > > <ma...@jakarta.apache.org>
> > > > >
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > > <ma...@jakarta.apache.org>
> > > > For additional commands, e-mail:
> > > <ma...@jakarta.apache.org>
> > > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > > <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > > <ma...@jakarta.apache.org>
> > >
> > >
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [lang] System properties

Posted by Stephen Colebourne <sc...@btopenworld.com>.

From: "Steve Downey" <st...@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" <sc...@btopenworld.com>
> > To: "Jakarta Commons Developers List" <co...@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" <ba...@generationjava.com>
> > > To: "Jakarta Commons Developers List"
<co...@jakarta.apache.org>;
> > > <bl...@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: <ma...@jakarta.apache.org>
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > To unsubscribe, e-mail:
> > > <ma...@jakarta.apache.org>
> > > > > For additional commands, e-mail:
> > > <ma...@jakarta.apache.org>
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > > <ma...@jakarta.apache.org>
> > > > For additional commands, e-mail:
> > > <ma...@jakarta.apache.org>
> > > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
> >
> >
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: [lang] System properties

Posted by Steve Downey <st...@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.

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.

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.

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; ]



> -----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" <sc...@btopenworld.com>
> To: "Jakarta Commons Developers List" <co...@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" <ba...@generationjava.com>
> > To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>;
> > <bl...@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: <ma...@jakarta.apache.org>
> > > > >
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > > > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> > > >
> > > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [lang] System properties

Posted by Stephen Colebourne <sc...@btopenworld.com>.

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" <sc...@btopenworld.com>
To: "Jakarta Commons Developers List" <co...@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" <ba...@generationjava.com>
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>;
> <bl...@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: <ma...@jakarta.apache.org>
> > > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> > >
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [lang] System properties

Posted by Juozas Baliuka <ba...@centras.lt>.

Yes, it is more about some useful "Constants", I do not thing CPU
"autodetect" is a
good idea, I use configurable values for this stuff . I do not believe it
is possible to find this kind of "good common constants", but it is very
possible I do
not know something usefull.



> 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" <ba...@generationjava.com>
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>;
> <bl...@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: <ma...@jakarta.apache.org>
> > > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> > >
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [lang] System properties

Posted by Stephen Colebourne <sc...@btopenworld.com>.

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" <ba...@generationjava.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>;
<bl...@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: <ma...@jakarta.apache.org>
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> > For additional commands, e-mail:
<ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [lang] System properties

Posted by Juozas Baliuka <ba...@centras.lt>.

It is about the same too:
http://cvs.apache.org/viewcvs/jakarta-lucene/src/java/org/apache/lucene/util
/Constants.java?rev=1.2&content-type=text/vnd.viewcvs-markup

It seems this stuff is usefull for some projects.

----- Original Message -----
From: "Henri Yandell" <ba...@generationjava.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>;
<bl...@apache.org>
Sent: Thursday, August 22, 2002 10: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: <ma...@jakarta.apache.org>
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> > For additional commands, e-mail:
<ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: [lang] System properties

Posted by Henri Yandell <ba...@generationjava.com>.

-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: <ma...@jakarta.apache.org>
> >
>
>
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: [lang] System properties

Posted by Berin Loritsch <bl...@apache.org>.

+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: <ma...@jakarta.apache.org>
> 


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [lang] System properties

Posted by Stephen Colebourne <sc...@btopenworld.com>.

> > 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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [lang] System properties

Posted by Daniel Rall <dl...@finemaltcoding.com>.

"Stephen Colebourne" <sc...@btopenworld.com> writes:

>     public static final String PATH_SEPARATOR =
> System.getProperty("path.separator");
>     public static final String FILE_SEPARATOR =
> System.getProperty("file.separator");

These already exist in java.io.File.  The rest seem like good
additions, since as VM-implementation properties they shouldn't change
during runtime.

> How about a SystemUtils for [lang] ?

+1.  The one from Avalon could be used as the basis.
-- 

Daniel Rall <dl...@finemaltcoding.com>

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: [lang] System properties

Posted by Andrew Conrad <an...@attbi.com>.

I was kind of wondering about Linux == Unix, but just recoded it as I
saw it.

So your saying that potentially there could be a Solaris family
encompassing all Solaris versions, Windows NT family encompassing NT,
2000, XP?

Without thinking too hard about it, the only thing I can think of is to
use a byte as the enumeration type then AND them together and compare.
That will allow a boolean method  isOSFamilyLinux and isOSFamilyUnix to
both return true  (and other possible options:  I think I heard OSX ).  

But that doesn't solve the getOSFamily() method frum returning a
OS_FAMILY_LINUX value which only equals itself.  

I'll think some more about it.




What's the reasoning behind wanting to differentiate between Linux and
Unix, but not SunOS and AIX?


- Andrew


> -----Original Message-----
> From: Stephen Colebourne [mailto:scolebourne@btopenworld.com] 
> Sent: Friday, August 23, 2002 4:28 AM
> To: Jakarta Commons Developers List
> Subject: Re: [lang] System properties
> 
> 
> Andrew,
> My original class returned an enumerated type, in a similar 
> way to the int that you are proposing.
> 
> On coding the [lang] version, I used static booleans for two reasons:
> 1) Lucene and Avalon Excalibur do it that way
> 2) An OS can be under multiple headings (Linux is both UNIX and LINUX)
> 
> I am open on this one, if you can meet (2) above.
> 
> Stephen
> 
> PS. Welcome to commons
> 
> ----- Original Message -----
> From: "Andrew Conrad" <an...@attbi.com>
> To: "'Jakarta Commons Developers List'" 
> <co...@jakarta.apache.org>
> Sent: Friday, August 23, 2002 5:31 AM
> Subject: RE: [lang] System properties
> 
> 
> > I just joined the Commons-Dev, so don't shoot me for my 
> comments but 
> > here goes:
> >
> > I was looking at your SystemUtils class, and I was thinking 
> that using 
> > it would be a little clumsy.
> >
> >
> > Instead of using boolean types for IS_WINDOWS and IS_UNIX, do you 
> > think it would be more friendly if you used int types such as
> >
> > OS_TYPE_WINDOWS, OS_TYPE_UNIX and a static method getOSType() .
> >
> >
> > I was thinking of an execution that might want to branch, you could 
> > use a switch instead of a lot of if/else's
> >
> > switch( SystemUtils.getOSType() ) {
> > case SystemUtils.OS_TYPE_WINDOWS:
> > break;
> > case SystemUtils.OS_TYPE_WINDOWS:
> > break;
> > }
> >
> > I guess it's probably just a preference of coding style....
> >
> > Also, a different naming convention could be   OS_FAMILIY_   and
> > getOSFamily()
> >
> > Just thinking out loud.   If you guys like this idea, I'm 
> offering to
> > rewrite the class.
> >
> >
> > - Andrew
> >
> >
> >
> > > -----Original Message-----
> > > From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
> > > Sent: Thursday, August 22, 2002 3:59 PM
> > > To: Jakarta Commons Developers List
> > > Subject: [lang] System properties
> > >
> > >
> > > One part I find inconvenient about Java is the system properties. 
> > > These are looked up by a string name, and I can never 
> remember what 
> > > the name is, so I have to go and look it up the javadoc - a great 
> > > waste of time.
> > >
> > > The following code, is the solution in my library. Although 
> > > seemingly trivial, it means that any IDE can use code 
> completion to 
> > > pick the value without needing to remember the string name.
> > >
> > >     public static final String LINE_SEPARATOR = 
> > > System.getProperty("line.separator");
> > >     public static final String PATH_SEPARATOR = 
> > > System.getProperty("path.separator");
> > >     public static final String FILE_SEPARATOR = 
> > > System.getProperty("file.separator");
> > >     public static final String WORKING_DIRECTORY = 
> > > System.getProperty("user.dir");
> > >     public static final String OS_NAME = 
> > > System.getProperty("os.name");
> > >     public static final String OS_ARCH = 
> > > System.getProperty("os.arch");
> > >     public static final String OS_VERSION = 
> > > System.getProperty("os.version");
> > >     public static final String JAVA_VERSION = 
> > > System.getProperty("java.version");
> > >
> > > How about a SystemUtils for [lang] ?
> > >
> > > Stephen
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > > <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> > > For
> > > additional commands,
> > > e-mail: <ma...@jakarta.apache.org>
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
> 
> 
> --
> To unsubscribe, e-mail:   
> <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> For 
> additional commands, 
> e-mail: <ma...@jakarta.apache.org>
> 


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [lang] System properties

Posted by Stephen Colebourne <sc...@btopenworld.com>.

Andrew,
My original class returned an enumerated type, in a similar way to the int
that you are proposing.

On coding the [lang] version, I used static booleans for two reasons:
1) Lucene and Avalon Excalibur do it that way
2) An OS can be under multiple headings (Linux is both UNIX and LINUX)

I am open on this one, if you can meet (2) above.

Stephen

PS. Welcome to commons

----- Original Message -----
From: "Andrew Conrad" <an...@attbi.com>
To: "'Jakarta Commons Developers List'" <co...@jakarta.apache.org>
Sent: Friday, August 23, 2002 5:31 AM
Subject: RE: [lang] System properties


> I just joined the Commons-Dev, so don't shoot me for my comments but
> here goes:
>
> I was looking at your SystemUtils class, and I was thinking that using
> it would be a little clumsy.
>
>
> Instead of using boolean types for IS_WINDOWS and IS_UNIX, do you think
> it would be more friendly if you used int types such as
>
> OS_TYPE_WINDOWS, OS_TYPE_UNIX and a static method getOSType() .
>
>
> I was thinking of an execution that might want to branch, you could use
> a switch instead of a lot of if/else's
>
> switch( SystemUtils.getOSType() ) {
> case SystemUtils.OS_TYPE_WINDOWS:
> break;
> case SystemUtils.OS_TYPE_WINDOWS:
> break;
> }
>
> I guess it's probably just a preference of coding style....
>
> Also, a different naming convention could be   OS_FAMILIY_   and
> getOSFamily()
>
> Just thinking out loud.   If you guys like this idea, I'm offering to
> rewrite the class.
>
>
> - Andrew
>
>
>
> > -----Original Message-----
> > From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
> > Sent: Thursday, August 22, 2002 3:59 PM
> > To: Jakarta Commons Developers List
> > Subject: [lang] System properties
> >
> >
> > One part I find inconvenient about Java is the system
> > properties. These are looked up by a string name, and I can
> > never remember what the name is, so I have to go and look it
> > up the javadoc - a great waste of time.
> >
> > The following code, is the solution in my library. Although
> > seemingly trivial, it means that any IDE can use code
> > completion to pick the value without needing to remember the
> > string name.
> >
> >     public static final String LINE_SEPARATOR =
> > System.getProperty("line.separator");
> >     public static final String PATH_SEPARATOR =
> > System.getProperty("path.separator");
> >     public static final String FILE_SEPARATOR =
> > System.getProperty("file.separator");
> >     public static final String WORKING_DIRECTORY =
> > System.getProperty("user.dir");
> >     public static final String OS_NAME =
> > System.getProperty("os.name");
> >     public static final String OS_ARCH =
> > System.getProperty("os.arch");
> >     public static final String OS_VERSION =
> > System.getProperty("os.version");
> >     public static final String JAVA_VERSION =
> > System.getProperty("java.version");
> >
> > How about a SystemUtils for [lang] ?
> >
> > Stephen
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> > For
> > additional commands,
> > e-mail: <ma...@jakarta.apache.org>
> >
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: [lang] System properties

Posted by Andrew Conrad <an...@attbi.com>.

And you could still have some methods  isTypeWindows() for convenience;

- Andrew

> -----Original Message-----
> From: Andrew Conrad [mailto:andrewconrad@attbi.com] 
> Sent: Friday, August 23, 2002 12:31 AM
> To: 'Jakarta Commons Developers List'
> Subject: RE: [lang] System properties
> 
> 
> I just joined the Commons-Dev, so don't shoot me for my 
> comments but here goes:
> 
> I was looking at your SystemUtils class, and I was thinking 
> that using it would be a little clumsy.
> 
> 
> Instead of using boolean types for IS_WINDOWS and IS_UNIX, do 
> you think it would be more friendly if you used int types such as 
> 
> OS_TYPE_WINDOWS, OS_TYPE_UNIX and a static method getOSType() .
> 
> 
> I was thinking of an execution that might want to branch, you 
> could use a switch instead of a lot of if/else's
> 
> 		switch( SystemUtils.getOSType() ) {
> 			case SystemUtils.OS_TYPE_WINDOWS:
> 				break;
> 			case SystemUtils.OS_TYPE_WINDOWS:
> 				break;
> 		}
> 
> I guess it's probably just a preference of coding style....
> 
> Also, a different naming convention could be   OS_FAMILIY_   and
> getOSFamily()
> 
> Just thinking out loud.   If you guys like this idea, I'm offering to
> rewrite the class.
> 
> 
> - Andrew
> 
> 
> 
> > -----Original Message-----
> > From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
> > Sent: Thursday, August 22, 2002 3:59 PM
> > To: Jakarta Commons Developers List
> > Subject: [lang] System properties
> > 
> > 
> > One part I find inconvenient about Java is the system
> > properties. These are looked up by a string name, and I can 
> > never remember what the name is, so I have to go and look it 
> > up the javadoc - a great waste of time.
> > 
> > The following code, is the solution in my library. Although
> > seemingly trivial, it means that any IDE can use code 
> > completion to pick the value without needing to remember the 
> > string name.
> > 
> >     public static final String LINE_SEPARATOR =
> > System.getProperty("line.separator");
> >     public static final String PATH_SEPARATOR = 
> > System.getProperty("path.separator");
> >     public static final String FILE_SEPARATOR = 
> > System.getProperty("file.separator");
> >     public static final String WORKING_DIRECTORY = 
> > System.getProperty("user.dir");
> >     public static final String OS_NAME = 
> > System.getProperty("os.name");
> >     public static final String OS_ARCH = 
> > System.getProperty("os.arch");
> >     public static final String OS_VERSION = 
> > System.getProperty("os.version");
> >     public static final String JAVA_VERSION = 
> > System.getProperty("java.version");
> > 
> > How about a SystemUtils for [lang] ?
> > 
> > Stephen
> > 
> > 
> > --
> > To unsubscribe, e-mail:   
> > <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> > For
> > additional commands, 
> > e-mail: <ma...@jakarta.apache.org>
> > 
> 
> 
> --
> To unsubscribe, e-mail:   
> <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> For 
> additional commands, 
> e-mail: <ma...@jakarta.apache.org>
> 


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: [lang] System properties

Posted by Andrew Conrad <an...@attbi.com>.

Ok, I rewrote the class as I was thinking it should operate and attached
it, just in case my emails didn't make sense (which they tend not to do
late at night)

- Andrew

> -----Original Message-----
> From: Andrew Conrad [mailto:andrewconrad@attbi.com] 
> Sent: Friday, August 23, 2002 12:31 AM
> To: 'Jakarta Commons Developers List'
> Subject: RE: [lang] System properties
> 
> 
> I just joined the Commons-Dev, so don't shoot me for my 
> comments but here goes:
> 
> I was looking at your SystemUtils class, and I was thinking 
> that using it would be a little clumsy.
> 
> 
> Instead of using boolean types for IS_WINDOWS and IS_UNIX, do 
> you think it would be more friendly if you used int types such as 
> 
> OS_TYPE_WINDOWS, OS_TYPE_UNIX and a static method getOSType() .
> 
> 
> I was thinking of an execution that might want to branch, you 
> could use a switch instead of a lot of if/else's
> 
> 		switch( SystemUtils.getOSType() ) {
> 			case SystemUtils.OS_TYPE_WINDOWS:
> 				break;
> 			case SystemUtils.OS_TYPE_WINDOWS:
> 				break;
> 		}
> 
> I guess it's probably just a preference of coding style....
> 
> Also, a different naming convention could be   OS_FAMILIY_   and
> getOSFamily()
> 
> Just thinking out loud.   If you guys like this idea, I'm offering to
> rewrite the class.
> 
> 
> - Andrew
> 
> 
> 
> > -----Original Message-----
> > From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
> > Sent: Thursday, August 22, 2002 3:59 PM
> > To: Jakarta Commons Developers List
> > Subject: [lang] System properties
> > 
> > 
> > One part I find inconvenient about Java is the system
> > properties. These are looked up by a string name, and I can 
> > never remember what the name is, so I have to go and look it 
> > up the javadoc - a great waste of time.
> > 
> > The following code, is the solution in my library. Although
> > seemingly trivial, it means that any IDE can use code 
> > completion to pick the value without needing to remember the 
> > string name.
> > 
> >     public static final String LINE_SEPARATOR =
> > System.getProperty("line.separator");
> >     public static final String PATH_SEPARATOR = 
> > System.getProperty("path.separator");
> >     public static final String FILE_SEPARATOR = 
> > System.getProperty("file.separator");
> >     public static final String WORKING_DIRECTORY = 
> > System.getProperty("user.dir");
> >     public static final String OS_NAME = 
> > System.getProperty("os.name");
> >     public static final String OS_ARCH = 
> > System.getProperty("os.arch");
> >     public static final String OS_VERSION = 
> > System.getProperty("os.version");
> >     public static final String JAVA_VERSION = 
> > System.getProperty("java.version");
> > 
> > How about a SystemUtils for [lang] ?
> > 
> > Stephen
> > 
> > 
> > --
> > To unsubscribe, e-mail:   
> > <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> > For
> > additional commands, 
> > e-mail: <ma...@jakarta.apache.org>
> > 
> 
> 
> --
> To unsubscribe, e-mail:   
> <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> For 
> additional commands, 
> e-mail: <ma...@jakarta.apache.org>
>

RE: [lang] System properties

Posted by Andrew Conrad <an...@attbi.com>.

I just joined the Commons-Dev, so don't shoot me for my comments but
here goes:

I was looking at your SystemUtils class, and I was thinking that using
it would be a little clumsy.


Instead of using boolean types for IS_WINDOWS and IS_UNIX, do you think
it would be more friendly if you used int types such as 

OS_TYPE_WINDOWS, OS_TYPE_UNIX and a static method getOSType() .


I was thinking of an execution that might want to branch, you could use
a switch instead of a lot of if/else's

		switch( SystemUtils.getOSType() ) {
			case SystemUtils.OS_TYPE_WINDOWS:
				break;
			case SystemUtils.OS_TYPE_WINDOWS:
				break;
		}

I guess it's probably just a preference of coding style....

Also, a different naming convention could be   OS_FAMILIY_   and
getOSFamily()

Just thinking out loud.   If you guys like this idea, I'm offering to
rewrite the class.


- Andrew



> -----Original Message-----
> From: Stephen Colebourne [mailto:scolebourne@btopenworld.com] 
> Sent: Thursday, August 22, 2002 3:59 PM
> To: Jakarta Commons Developers List
> Subject: [lang] System properties
> 
> 
> One part I find inconvenient about Java is the system 
> properties. These are looked up by a string name, and I can 
> never remember what the name is, so I have to go and look it 
> up the javadoc - a great waste of time.
> 
> The following code, is the solution in my library. Although 
> seemingly trivial, it means that any IDE can use code 
> completion to pick the value without needing to remember the 
> string name.
> 
>     public static final String LINE_SEPARATOR = 
> System.getProperty("line.separator");
>     public static final String PATH_SEPARATOR = 
> System.getProperty("path.separator");
>     public static final String FILE_SEPARATOR = 
> System.getProperty("file.separator");
>     public static final String WORKING_DIRECTORY = 
> System.getProperty("user.dir");
>     public static final String OS_NAME = 
> System.getProperty("os.name");
>     public static final String OS_ARCH = 
> System.getProperty("os.arch");
>     public static final String OS_VERSION = 
> System.getProperty("os.version");
>     public static final String JAVA_VERSION = 
> System.getProperty("java.version");
> 
> How about a SystemUtils for [lang] ?
> 
> Stephen
> 
> 
> --
> To unsubscribe, e-mail:   
> <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> For 
> additional commands, 
> e-mail: <ma...@jakarta.apache.org>
> 


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>