2006/10/11, Geir Magnusson Jr. <[EMAIL PROTECTED]>:
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.
Programs use the VM, and I think the VM should be more strict for safety.
Yes, very nice summary. Thanks Geir, for expressing so close to my own
thoughts! :)
--
Alexey
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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:
>>>> [EMAIL PROTECTED]
>>>> >> > For additional commands, e-mail:
>>>> [EMAIL PROTECTED]
>>>> >> >
>>>> >> >
>>>> >>
>>>> >>
>>>> >> --
>>>> >> Mikhail Fursov
>>>> >>
>>>> >>
>>>> >
>>>> > ---------------------------------------------------------------------
>>>> > Terms of use : http://incubator.apache.org/harmony/mailing.html
>>>> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>> > For additional commands, e-mail:
>>>> [EMAIL PROTECTED]
>>>> >
>>>> >
>>>>
>>>> --
>>>> Oliver Deakin
>>>> IBM United Kingdom Limited
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
