harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [drlvm] VM throws NullPointerException in case java.class.path is not set
Date Thu, 12 Oct 2006 19:03:39 GMT


Oliver Deakin wrote:
> Geir Magnusson Jr. wrote:
>> Well, that's actually an interesting question...  should the VM do it 
>> if not set, or should the launcher do it?  I think that based on the 
>> "principle of least surprise", it should be launcher.
>>
>> The user uses the launcher, so the launcher should be nice to the 
>> user, and "current directory" really is somewhat of a user-oriented 
>> concept, and is what the human expects.
> 
> This doc [1] (in "Description") describes that the default classpath is the
> current directory, but it does not describe where this classpath is set.
> i.e. Can a user writing a custom launcher expect a default classpath to
> be set by the VM?

It's written from the POV of the command line tool.  I think that we 
simply have a document created for people embedding our VM in other 
launch environments.

> 
> This doc [2] hints (in section 7.1) that the user can expect some kind of
> default classpath to be set when writing a custom launcher, but does not
> specify what that classpath will be.

LOL.  That's a big help...  VM chooses at random? :)

> 
> Experience shows us that the RI (and J9) provides a default classpath
> of the current directory if no classpath is explicitly specified. Any 
> custom
> launcher written against either of these VMs could expect this behaviour,
> and as such could fail with DRLVM.

You mean using a launcher?

> 
> I don't feel strongly about it, but IMHO going with the RI behaviour makes
> sense here - if only to allow more custom launchers to work "out of the
> box" with DRLVM, and to save the user having to alter and rebuild any
> launchers they have.
> 
>>
>> Programs use the VM, and I think the VM should be more strict for safety.
> 
> Is it unsafe for the VM to provide a default classpath? If the standard 
> java
> launcher provides a default classpath of ".", then I dont see why it 
> makes a
> difference providing it to a custom launcher. Perhaps Im missing something?
> 

Philosophically, I think so - the _launcher_ is providing the default 
classpath, so it doesn't follow to me that it implies the VM has to 
behave the same way.

That said, if the RI, J9, JRockit all use the current directory as a 
default, we should too, my philosophical mutterings notwithstanding :)

geir


> Regards,
> Oliver
> 
> [1] http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/classpath.html
> [2] http://java.sun.com/docs/books/jni/html/invoke.html#11202
> 
> 
>>
>>
>> geir
>>
>> Oliver Deakin wrote:
>>> Geir Magnusson Jr. wrote:
>>>> Absolutely.  And if not, even the principle of "be kind to your 
>>>> users" dictates that we do something nice for them.
>>>
>>> Agreed - being nice to the user where we can is a good thing! Having the
>>> current directory on the classpath is pretty common - giving it to the
>>> user by default costs nothing and saves them having to explicitly set it
>>> in every launcher they write.
>>>
>>> Regards,
>>> Oliver
>>>
>>>>
>>>> geir
>>>>
>>>> Evgueni Brevnov wrote:
>>>>> Oliver,
>>>>>
>>>>> You have provided strong arguments that RI uses current directory by
>>>>> default. I think it makes sense to be compatible with RI in this
>>>>> particular case.
>>>>>
>>>>> Thanks
>>>>> Evgueni
>>>>>
>>>>> On 10/10/06, Oliver Deakin <oliver.deakin@googlemail.com> wrote:
>>>>>> I have just tried launching the RI with a simple launcher (very 
>>>>>> basic -
>>>>>> CreateJavaVM(),
>>>>>> finds and launches a class, then calls DestroyJavaVM()). The launcher
>>>>>> does not
>>>>>> set java.class.path, and executes the main method of the following

>>>>>> class:
>>>>>>
>>>>>>   public class SysInfo {
>>>>>>       public static void main(String[] args) {
>>>>>>                   System.getProperties().list(System.out);
>>>>>>       }
>>>>>>   }
>>>>>>
>>>>>> The java.class.path value is printed as:
>>>>>>
>>>>>>  java.class.path=
>>>>>>
>>>>>> So it appears that java.class.path property is left empty by default.
>>>>>> However,
>>>>>> to have found the SysInfo class, the RI must have searched in the

>>>>>> current
>>>>>> directory. I can also instantiate other classes that are located

>>>>>> in the
>>>>>> current
>>>>>> directory. So although the java.class.path is set to an empty string,
>>>>>> internally
>>>>>> there is a default inclusion of the current directory.
>>>>>>
>>>>>> IMHO we follow the RI behaviour here, and have an implicit 
>>>>>> inclusion of
>>>>>> the current directory unless the classpath is explicitly set.
>>>>>>
>>>>>> Regards,
>>>>>> Oliver
>>>>>>
>>>>>>
>>>>>> Evgueni Brevnov wrote:
>>>>>> > It seems for me like pretty specified VM behavior to treat 
>>>>>> classpath
>>>>>> > absence as take classes from current directory. At least RI
does 
>>>>>> like
>>>>>> > that when you don't specify classpath on command line.
>>>>>> >
>>>>>> > Evgueni
>>>>>> >
>>>>>> > On 10/10/06, Mikhail Fursov <mike.fursov@gmail.com> wrote:
>>>>>> >> Another solution could be a simple shutdown with the valid
error
>>>>>> >> message.
>>>>>> >> Sometimes the error message is better than hidden behaviour.
>>>>>> >> So the alternative is to check all properties VM needs before

>>>>>> running
>>>>>> >> real
>>>>>> >> startup and fail if some of the properties are not found.
>>>>>> >>
>>>>>> >>
>>>>>> >> On 10/10/06, Evgueni Brevnov <evgueni.brevnov@gmail.com>
wrote:
>>>>>> >> >
>>>>>> >> > Hi All,
>>>>>> >> >
>>>>>> >> > Currently DRLVM starts with help of the launcher. The

>>>>>> launcher does a
>>>>>> >> > lot of stuff required to create VM instatnce. As a
part of 
>>>>>> its job it
>>>>>> >> > sets up java.class.path property. And this is good.
What is 
>>>>>> not good
>>>>>> >> > that DRLVM crashes (actually throws NullPointerException
in
>>>>>> >> > initalization stage) if java.class.path is not set.
I believe 
>>>>>> it makes
>>>>>> >> > sense to point java.class.path to current directory
inside VM if
>>>>>> >> > launcher doesn't set it.
>>>>>> >> >
>>>>>> >> > What do u think?
>>>>>> >> >
>>>>>> >> > Thanks
>>>>>> >> > Evgueni
>>>>>> >> >
>>>>>> >> > 
>>>>>> ---------------------------------------------------------------------
>>>>>> >> > Terms of use : http://incubator.apache.org/harmony/mailing.html
>>>>>> >> > To unsubscribe, e-mail: 
>>>>>> harmony-dev-unsubscribe@incubator.apache.org
>>>>>> >> > For additional commands, e-mail: 
>>>>>> harmony-dev-help@incubator.apache.org
>>>>>> >> >
>>>>>> >> >
>>>>>> >>
>>>>>> >>
>>>>>> >> --
>>>>>> >> Mikhail Fursov
>>>>>> >>
>>>>>> >>
>>>>>> >
>>>>>> > 
>>>>>> ---------------------------------------------------------------------
>>>>>> > Terms of use : http://incubator.apache.org/harmony/mailing.html
>>>>>> > To unsubscribe, e-mail: 
>>>>>> harmony-dev-unsubscribe@incubator.apache.org
>>>>>> > For additional commands, e-mail: 
>>>>>> harmony-dev-help@incubator.apache.org
>>>>>> >
>>>>>> >
>>>>>>
>>>>>> -- 
>>>>>> Oliver Deakin
>>>>>> IBM United Kingdom Limited
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>>>>>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>>>>>> For additional commands, e-mail: 
>>>>>> harmony-dev-help@incubator.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>>>>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>>>>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>>>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>>>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
> 

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message