Re: [drlvm] VM throws NullPointerException in case java.class.path is not set
Tim Ellison wrote: Geir Magnusson Jr. wrote: That said, if the RI, J9, JRockit all use the current directory as a default, we should too, my philosophical mutterings notwithstanding :) That is what Oliver is saying. The 'simple launcher' didn't set up any classpath, and yet the RI could find .class files in '.' -- I can believe that applications embedding the VM may be relying on this behavior. Yah, that's what I meant - sorry if it didn't come across. So we agree to go with the RI and set the default classpath within the VM? Regards, Oliver Regards, Tim -- 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]
Re: [drlvm] VM throws NullPointerException in case java.class.path is not set
Oliver Deakin wrote: Tim Ellison wrote: Geir Magnusson Jr. wrote: That said, if the RI, J9, JRockit all use the current directory as a default, we should too, my philosophical mutterings notwithstanding :) That is what Oliver is saying. The 'simple launcher' didn't set up any classpath, and yet the RI could find .class files in '.' -- I can believe that applications embedding the VM may be relying on this behavior. Yah, that's what I meant - sorry if it didn't come across. So we agree to go with the RI and set the default classpath within the VM? y Regards, Oliver Regards, Tim - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] VM throws NullPointerException in case java.class.path is not set
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
Re: [drlvm] VM throws NullPointerException in case java.class.path is not set
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?
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.
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.
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?
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 [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
Re: [drlvm] VM throws NullPointerException in case java.class.path is not set
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 [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
Re: [drlvm] VM throws NullPointerException in case java.class.path is not set
Geir Magnusson Jr. wrote: That said, if the RI, J9, JRockit all use the current directory as a default, we should too, my philosophical mutterings notwithstanding :) That is what Oliver is saying. The 'simple launcher' didn't set up any classpath, and yet the RI could find .class files in '.' -- I can believe that applications embedding the VM may be relying on this behavior. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] VM throws NullPointerException in case java.class.path is not set
Oliver,
HARMONY-1818 was created to track this issue. Could you attach your
test case (simple launcher) to it?
Thanks
Evgueni
On 10/10/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Absolutely. And if not, even the principle of be kind to your users
dictates that we do something nice for them.
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]
Re: [drlvm] VM throws NullPointerException in case java.class.path is not set
ok, done - thanks for opening the JIRA Evgueni.
Regards,
Oliver
Evgueni Brevnov wrote:
Oliver,
HARMONY-1818 was created to track this issue. Could you attach your
test case (simple launcher) to it?
Thanks
Evgueni
On 10/10/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Absolutely. And if not, even the principle of be kind to your users
dictates that we do something nice for them.
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]
--
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]
Re: [drlvm] VM throws NullPointerException in case java.class.path is not set
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]
--
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]
Re: [drlvm] VM throws NullPointerException in case java.class.path is not set
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.
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]
[drlvm] VM throws NullPointerException in case java.class.path is not set
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]
Re: [drlvm] VM throws NullPointerException in case java.class.path is not set
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
Re: [drlvm] VM throws NullPointerException in case java.class.path is not set
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]
Re: [drlvm] VM throws NullPointerException in case java.class.path is not set
Evgueni, You wrote about the launcher: As a part of its job it sets up java.class.path property. So if it is the part of it's job and the property is not set that means that this is the bug.(?) What is the reason of workarounding this bug in VM code? Are there additional usecases? -- Mikhail Fursov
Re: [drlvm] VM throws NullPointerException in case java.class.path is not set
Mikhail, The reason is as follows. The launcher uses InvocationAPI to start VM. The spec doesn't require to provide java.class.path property. The worst thing which should happen in this case is ClassNotFound exception on attempt to load a class. So I think we have two choices either use current directory to load classes or use empty path. In the second case the search path is boot class path only. Personally I think that second is acceptable as well. Evgueni On 10/10/06, Mikhail Fursov [EMAIL PROTECTED] wrote: Evgueni, You wrote about the launcher: As a part of its job it sets up java.class.path property. So if it is the part of it's job and the property is not set that means that this is the bug.(?) What is the reason of workarounding this bug in VM code? Are there additional usecases? -- 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]
Re: [drlvm] VM throws NullPointerException in case java.class.path is not set
2006/10/10, Evgueni Brevnov [EMAIL PROTECTED]: 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. Please note, you said command line - this is prerogative of the launcher. I agree with Mikhail, the VM itself should do minimal number of assumptions about environment where it is being invoked. 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] VM throws NullPointerException in case java.class.path is not set
I agree with both of you. Second variant doesn't contradict with what you are saying. Do you agree? Evgueni On 10/10/06, Alexey Varlamov [EMAIL PROTECTED] wrote: 2006/10/10, Evgueni Brevnov [EMAIL PROTECTED]: 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. Please note, you said command line - this is prerogative of the launcher. I agree with Mikhail, the VM itself should do minimal number of assumptions about environment where it is being invoked. 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] - 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]
Re: [drlvm] VM throws NullPointerException in case java.class.path is not set
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]
Re: [drlvm] VM throws NullPointerException in case java.class.path is not set
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]
Re: [classlib][luni] On RI, constructor of EnumMap -- EnumMap(ClassK keyType) throws unspecified NullPointerException
2006/8/15, Spark Shen [EMAIL PROTECTED]:
Hi All:
Constructor of EnumMap -- EnumMap(ClassK keyType) behaves a little odd:
I first synthesis an enum type with class body as below:
enum color {
blue{},
red{},
}
Then constructs java.util.EnumMap(ClassK) using this Enum type:
import java.util.EnumMap;
public class ConstructEnumMap {
enum color {
blue{},
red{},
}
enum fruit {
apple,
}
@SuppressWarnings(unchecked)
public static void main(String[] args) {
new EnumMap(fruit.apple.getClass());
*new EnumMap(color.blue.getClass());*
}
}
NullPointerException will be thrown out from the bolded line. While
using enum type without a class body, no such exception
will be thrown out. This behavior is unspecified on spec. IMO, this is a
bug of RI.
What is your opinion about this behavior?
I have the following explanation for this behavior:
even though spec says the constructor should throw NPE if type is
null, implementation actually enforces that type is enum, like this:
if (!type.isEnum()) throw NPE;
This is proved by the following fact, the compiler generated several
classes (ConstructEnumMap$1.class, ConstructEnumMap$color$1.class,
ConstructEnumMap$color$2.class) for empty implementation of color
items, and they are not marked ACC_ENUM. The same way, NPE is thrown
on any non-enum class passed to that constructor.
I consider this runtime behavior quite reasonable, except throwable
type - certainly IAE suits better than NPE... And this is hardly
compiler bug - there is special j.l.Enum.getDeclaringClass() method
for using in such cases.
--
Regards,
Alexey
Best regards
--
Spark Shen
China Software Development Lab, IBM
-
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]
Re: [classlib][luni] On RI, constructor of EnumMap -- EnumMap(ClassK keyType) throws unspecified NullPointerException
Alexey Varlamov 写道:
2006/8/15, Spark Shen [EMAIL PROTECTED]:
Hi All:
Constructor of EnumMap -- EnumMap(ClassK keyType) behaves a little
odd:
I first synthesis an enum type with class body as below:
enum color {
blue{},
red{},
}
Then constructs java.util.EnumMap(ClassK) using this Enum type:
import java.util.EnumMap;
public class ConstructEnumMap {
enum color {
blue{},
red{},
}
enum fruit {
apple,
}
@SuppressWarnings(unchecked)
public static void main(String[] args) {
new EnumMap(fruit.apple.getClass());
*new EnumMap(color.blue.getClass());*
}
}
NullPointerException will be thrown out from the bolded line. While
using enum type without a class body, no such exception
will be thrown out. This behavior is unspecified on spec. IMO, this is a
bug of RI.
What is your opinion about this behavior?
I have the following explanation for this behavior:
even though spec says the constructor should throw NPE if type is
null, implementation actually enforces that type is enum, like this:
if (!type.isEnum()) throw NPE;
This is proved by the following fact, the compiler generated several
classes (ConstructEnumMap$1.class, ConstructEnumMap$color$1.class,
ConstructEnumMap$color$2.class) for empty implementation of color
items, and they are not marked ACC_ENUM. The same way, NPE is thrown
on any non-enum class passed to that constructor.
Hi:
Thank you very much for your information.
But isn't it a little odd that Enum with body is not a Enum?
Why making design decision like this? Will making Enum with body a Enum
type brings any risks?
Best regards
I consider this runtime behavior quite reasonable, except throwable
type - certainly IAE suits better than NPE... And this is hardly
compiler bug - there is special j.l.Enum.getDeclaringClass() method
for using in such cases.
--
Regards,
Alexey
Best regards
--
Spark Shen
China Software Development Lab, IBM
-
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]
--
Spark Shen
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][luni] On RI, constructor of EnumMap -- EnumMap(ClassK keyType) throws unspecified NullPointerException
2006/8/15, Spark Shen [EMAIL PROTECTED]:
Alexey Varlamov 写道:
2006/8/15, Spark Shen [EMAIL PROTECTED]:
Hi All:
Constructor of EnumMap -- EnumMap(ClassK keyType) behaves a little
odd:
I first synthesis an enum type with class body as below:
enum color {
blue{},
red{},
}
Then constructs java.util.EnumMap(ClassK) using this Enum type:
import java.util.EnumMap;
public class ConstructEnumMap {
enum color {
blue{},
red{},
}
enum fruit {
apple,
}
@SuppressWarnings(unchecked)
public static void main(String[] args) {
new EnumMap(fruit.apple.getClass());
*new EnumMap(color.blue.getClass());*
}
}
NullPointerException will be thrown out from the bolded line. While
using enum type without a class body, no such exception
will be thrown out. This behavior is unspecified on spec. IMO, this is a
bug of RI.
What is your opinion about this behavior?
I have the following explanation for this behavior:
even though spec says the constructor should throw NPE if type is
null, implementation actually enforces that type is enum, like this:
if (!type.isEnum()) throw NPE;
This is proved by the following fact, the compiler generated several
classes (ConstructEnumMap$1.class, ConstructEnumMap$color$1.class,
ConstructEnumMap$color$2.class) for empty implementation of color
items, and they are not marked ACC_ENUM. The same way, NPE is thrown
on any non-enum class passed to that constructor.
Hi:
Thank you very much for your information.
But isn't it a little odd that Enum with body is not a Enum?
Why making design decision like this? Will making Enum with body a Enum
type brings any risks?
Seems this is a rhetorical question :).
Actually I think this is well-weighed decision - as long as each enum
item has unique body definition, it must be of unique class, and that
class is evidently not your enum. At most, it could be another enum
containing just single item - but this is not what you'd expect.
Just replace getClass() with getDeclaringClass() or use explicit class
literal (i.e. color.class) and be cool ;)
--
Alexey
Best regards
I consider this runtime behavior quite reasonable, except throwable
type - certainly IAE suits better than NPE... And this is hardly
compiler bug - there is special j.l.Enum.getDeclaringClass() method
for using in such cases.
--
Regards,
Alexey
Best regards
--
Spark Shen
China Software Development Lab, IBM
-
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]
--
Spark Shen
China Software Development Lab, IBM
-
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]
[classlib][luni] On RI, constructor of EnumMap -- EnumMap(ClassK keyType) throws unspecified NullPointerException
Hi All:
Constructor of EnumMap -- EnumMap(ClassK keyType) behaves a little odd:
I first synthesis an enum type with class body as below:
enum color {
blue{},
red{},
}
Then constructs java.util.EnumMap(ClassK) using this Enum type:
import java.util.EnumMap;
public class ConstructEnumMap {
enum color {
blue{},
red{},
}
enum fruit {
apple,
}
@SuppressWarnings(unchecked)
public static void main(String[] args) {
new EnumMap(fruit.apple.getClass());
*new EnumMap(color.blue.getClass());*
}
}
NullPointerException will be thrown out from the bolded line. While
using enum type without a class body, no such exception
will be thrown out. This behavior is unspecified on spec. IMO, this is a
bug of RI.
What is your opinion about this behavior?
Best regards
--
Spark Shen
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Created: (HARMONY-373) beans: Harmony does not throw NullPointerException in several cases while RI does.
On 4/18/06, Dmitry M. Kononov (JIRA) [EMAIL PROTECTED] wrote: beans: Harmony does not throw NullPointerException in several cases while RI does. -- Key: HARMONY-373 URL: http://issues.apache.org/jira/browse/HARMONY-373 Project: Harmony Type: Bug Components: Classlib Reporter: Dmitry M. Kononov Priority: Minor Harmony does not throw NPE as it is described below: 1) java.beans.beancontext.BeanContextSupport.getResourceAsStream(String name, BeanContextChild bcc): Harmony does not throw NullPointerException when name=,bcc=null, while RI throws it. Direct method specification says only Throws: NullPointerException. [SNIP] Dmitry, Out of curiosity, how are you discovering these? I've just uploaded an updated version of my testing tool to HARMONY-325. I think it should find most of the problems you are reporting - see the results file, harmony.exception.differences-0.02.txt. It can also generate test cases. Sadly it doesn't fix the bugs. ;-) Regards, Mark. -- Mark Hindess [EMAIL PROTECTED] IBM Java Technology Centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Created: (HARMONY-373) beans: Harmony does not throw NullPointerException in several cases while RI does.
On 4/18/06, Mark Hindess [EMAIL PROTECTED] wrote: Dmitry, Out of curiosity, how are you discovering these? I've just uploaded an updated version of my testing tool to HARMONY-325. I think it should find most of the problems you are reporting - see the results file, harmony.exception.differences-0.02.txt. It can also generate test cases. Mark, Alex Orlov has mentioned a similar tool in the thread matching reference implementation exception behaviour. This issue (HARMONY-373) is the first one from a series that was discovered by the tool. Actually, I have got lots of issues that have already investigated with prepared unit tests. So, I just prepare patches and file JIRA issues. Thanks. -- Dmitry M. Kononov Intel Managed Runtime Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NullPointerException
On Monday 20 March 2006 09:41, Paulex Yang wrote: My opinion is: either is fine, the only principle is the exception order must be compliant with RI,[...] Good point. I agree. Chris -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369
Re: NullPointerException -- This info should be in wiki
On 3/20/06, karan malhi [EMAIL PROTECTED] wrote: Hi, This information should be put in the wiki under Coding Guidelines or How do I kind of a section. I think that a lot of discussion gets buried in the mailing list and then the same issue crops up again. I am willing to undertake updating the wiki with this information if you all agree. Absolutely agree. I believe all the valuable decisions made here in Harmony during discussions must be put on wiki. For this particular issue Coding Guidelines is fine, I think. -- Anton Avtamonov, Intel Middleware Products Division
Re: NullPointerException -- This info should be in wiki
karan malhi wrote:
Hi,
This information should be put in the wiki under Coding Guidelines
or How do I kind of a section. I think that a lot of discussion
gets buried in the mailing list and then the same issue crops up
again. I am willing to undertake updating the wiki with this
information if you all agree.
Good idea. ;-)
Paulex Yang wrote:
Chris Gray wrote:
On Friday 17 March 2006 08:47, Anton Avtamonov wrote:
Actually null-processing and corresponding NPEs are very very often
omitted from the spec.
I would say that according to the guidelines Paulex proposed (and as I
understood we agreed on) we should be RI-compatible in this case.
Really, spec doesn't say anything regarding null-processing and
therefore throwing NPE in this case does *not* contradict to the spec.
Having NPE we will be better RI-compatible and stay on the same
position in the spec-compatibility (since it is silent).
Therefore I suggest to be RI-compatible by default in all cases when
spec keep silence. I believe it well suites Paulex guidelines (please
correct me if I wrong).
+1
Talking about how particulary we should throw NPE I'm not sure what to
advise: in many cases RI just produces them automatically when actual
call like null.someMehtod() occurs. To provide better notation we can
do that directly, i.e.
if (someVar == null) {
throw NullPointerException(some valuable message)
}
I'm not really sure what is better and would like to know what others
think about.
I prefer to let these things happen automatically whenever possible.
Introducing an explicit check adds extra bytecodes and probably
extra CPU cycles in the non-null case. On some VMs null.someMethod()
might be slower in the null case, but if the RI also throws NPE then
these cases should be truly exceptional in the sense that they
indicate a programming error or a missing resource. OTOH if the RI
treats a null argument as a normal case then this should be
implemented using 'if (someVar == null)', not by catching a NPE(!).
My opinion is:
either is fine, the only principle is the exception order must be
compliant with RI, if it can be happen automatically, great. if can
not, then the explicit check is necessary, while the performance
should be the second consideration.
Chris
Btw, when we will work on documentation (javadoc) I think we should
append references to the standard Sun API in the methods javadoc with
the direct info about null-processing and NPE if a method can produce
it (when it is missing from the original spec of course).
--
Anton Avtamonov,
Intel Middleware Products Division
--
Richard Liang
China Software Development Lab, IBM
Re: NullPointerException
2006/3/19, Chris Gray [EMAIL PROTECTED]:
On Friday 17 March 2006 08:47, Anton Avtamonov wrote:
Actually null-processing and corresponding NPEs are very very often
omitted from the spec.
I would say that according to the guidelines Paulex proposed (and as I
understood we agreed on) we should be RI-compatible in this case.
Really, spec doesn't say anything regarding null-processing and
therefore throwing NPE in this case does *not* contradict to the spec.
Having NPE we will be better RI-compatible and stay on the same
position in the spec-compatibility (since it is silent).
Therefore I suggest to be RI-compatible by default in all cases when
spec keep silence. I believe it well suites Paulex guidelines (please
correct me if I wrong).
+1
Talking about how particulary we should throw NPE I'm not sure what to
advise: in many cases RI just produces them automatically when actual
call like null.someMehtod() occurs. To provide better notation we can
do that directly, i.e.
if (someVar == null) {
throw NullPointerException(some valuable message)
}
I'm not really sure what is better and would like to know what others
think about.
I prefer to let these things happen automatically whenever possible.
Introducing an explicit check adds extra bytecodes and probably extra CPU
cycles in the non-null case. On some VMs null.someMethod() might be slower in
the null case, but if the RI also throws NPE then these cases should be truly
exceptional in the sense that they indicate a programming error or a missing
resource.
I do not agree that performance in case of 'exceptional' behavior
is not important.
Would you use for example a browser that hangs your machine up for an hour if
you type wrong URL? Or if it crashes when some site misses some gif file?
Ideally each usage scenario must work just fine
Thanks,
Mikhail
OTOH if the RI treats a null argument as a normal case then this
should be implemented using 'if (someVar == null)', not by catching a NPE(!).
Chris
Btw, when we will work on documentation (javadoc) I think we should
append references to the standard Sun API in the methods javadoc with
the direct info about null-processing and NPE if a method can produce
it (when it is missing from the original spec of course).
--
Anton Avtamonov,
Intel Middleware Products Division
--
Chris Gray/k/ Embedded Java Solutions BE0503765045
Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/
[EMAIL PROTECTED] +32 3 216 0369
Re: NullPointerException
2006/3/20, Chris Gray [EMAIL PROTECTED]: On Monday 20 March 2006 14:21, Mikhail Loenko wrote: 2006/3/19, Chris Gray [EMAIL PROTECTED]: I prefer to let these things happen automatically whenever possible. Introducing an explicit check adds extra bytecodes and probably extra CPU cycles in the non-null case. On some VMs null.someMethod() might be slower in the null case, but if the RI also throws NPE then these cases should be truly exceptional in the sense that they indicate a programming error or a missing resource. I do not agree that performance in case of 'exceptional' behavior is not important. Would you use for example a browser that hangs your machine up for an hour if you type wrong URL? Or if it crashes when some site misses some gif file? asideI can remember browsers that did that (or at least waited for DNS to time out)./aside I never claimed that performance in case of 'exceptional' behavior is not important. However it is less important than performance in the normal case; for example it would not make sense for Apache to optimise the processing of mistyped URLs at the expense of correctly-typed ones. Ideally the most My experiments have shown that additional check for null is insignificant while accessing time of a null address is substantial. frequently executed code paths should also be the shortest. There are cases where a 'catch' clause can be executed very often, such as the ClassNotFoundException which is thrown when a class loader delegates to its parent and the parent does not find the class. In such cases one might consider optimising this path; but NPEs generally do not fall into this category, they most often indicate a programmer error (not user error) or the Actually, we are developing runtime environment, not an ordinary application and thus those programmers who make errors and write poor-designed code are all our users, clients, and valued customers We should take care of them and make their applications as fast as we can. Thanks, Mikhail absence of some required resource (installation error). That is what I meant by truly exceptional. Respectfully, Chris -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369
RE: NullPointerException
Mikhail Loenko wrote: My experiments have shown that additional check for null is insignificant while accessing time of a null address is substantial. That in itself is not enough to base any conclusions on. You also need to know the ratio between the exception between thrown and not being thrown. The extra bytecode (or jitted machine code) may very well cause additional paging (due to increased memory pressure) and that has to be factored in as well. Regards, Jeroen
Re: NullPointerException
Adding my opinion to the pool of opinions... There are 2 basic approaches used in simpler JVMs (interpreters, simple JITs) to check for null pointers: a) explicit check, and b) operating system signals on invalid memory access. Usually, simpler systems pick one of these two approaches and stick to it. On more advanced JVMs (adaptive systems such as HotSpot and Jikes RVM), the JVM reacts to the behavior of executed code. So, possibly, the JVM would start using os signals first, yet, if a signal is actually raised, the JVM will re-compile and re-optimize the culprit code that raised the signal to add an explicit null check. So, IMO, the current debate is a no-debate. People that use an interpreter or a simple JIT are obviously not looking for high-performance, so trying to save a bytecode or two, or trying to make exceptions run as fast as possible is not really relevant. On the other hand, adaptive JVMs can actually adapt to the best strategy during execution, and thus adding an explicit check or not in the source code will probably make no difference whatsoever. [Adaptive systems go as far as not creating the exception object when they determine that it is safe to do so...] So, my vote goes in the direction of: write what is best for maintenance of the class library source code, not what you think will be fastest for execution on a JVM, as it is difficult to clearly identify the later. :-) Etienne Jeroen Frijters wrote: Mikhail Loenko wrote: My experiments have shown that additional check for null is insignificant while accessing time of a null address is substantial. That in itself is not enough to base any conclusions on. You also need to know the ratio between the exception between thrown and not being thrown. The extra bytecode (or jitted machine code) may very well cause additional paging (due to increased memory pressure) and that has to be factored in as well. Regards, Jeroen -- Etienne M. Gagnon, Ph.D.http://www.info2.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ signature.asc Description: OpenPGP digital signature
Re: NullPointerException -- This info should be in wiki
Yep, these guidelines should be on the website -- Karan please submit a
patch.
Regards,
Tim
Geir Magnusson Jr wrote:
Please, but how about a document for the website?
karan malhi wrote:
Hi,
This information should be put in the wiki under Coding Guidelines
or How do I kind of a section. I think that a lot of discussion
gets buried in the mailing list and then the same issue crops up
again. I am willing to undertake updating the wiki with this
information if you all agree.
Paulex Yang wrote:
Chris Gray wrote:
On Friday 17 March 2006 08:47, Anton Avtamonov wrote:
Actually null-processing and corresponding NPEs are very very often
omitted from the spec.
I would say that according to the guidelines Paulex proposed (and as I
understood we agreed on) we should be RI-compatible in this case.
Really, spec doesn't say anything regarding null-processing and
therefore throwing NPE in this case does *not* contradict to the spec.
Having NPE we will be better RI-compatible and stay on the same
position in the spec-compatibility (since it is silent).
Therefore I suggest to be RI-compatible by default in all cases when
spec keep silence. I believe it well suites Paulex guidelines (please
correct me if I wrong).
+1
Talking about how particulary we should throw NPE I'm not sure what to
advise: in many cases RI just produces them automatically when actual
call like null.someMehtod() occurs. To provide better notation we can
do that directly, i.e.
if (someVar == null) {
throw NullPointerException(some valuable message)
}
I'm not really sure what is better and would like to know what others
think about.
I prefer to let these things happen automatically whenever possible.
Introducing an explicit check adds extra bytecodes and probably
extra CPU cycles in the non-null case. On some VMs null.someMethod()
might be slower in the null case, but if the RI also throws NPE then
these cases should be truly exceptional in the sense that they
indicate a programming error or a missing resource. OTOH if the RI
treats a null argument as a normal case then this should be
implemented using 'if (someVar == null)', not by catching a NPE(!).
My opinion is:
either is fine, the only principle is the exception order must be
compliant with RI, if it can be happen automatically, great. if can
not, then the explicit check is necessary, while the performance
should be the second consideration.
Chris
Btw, when we will work on documentation (javadoc) I think we should
append references to the standard Sun API in the methods javadoc with
the direct info about null-processing and NPE if a method can produce
it (when it is missing from the original spec of course).
--
Anton Avtamonov,
Intel Middleware Products Division
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
Re: NullPointerException
On Friday 17 March 2006 08:47, Anton Avtamonov wrote:
Actually null-processing and corresponding NPEs are very very often
omitted from the spec.
I would say that according to the guidelines Paulex proposed (and as I
understood we agreed on) we should be RI-compatible in this case.
Really, spec doesn't say anything regarding null-processing and
therefore throwing NPE in this case does *not* contradict to the spec.
Having NPE we will be better RI-compatible and stay on the same
position in the spec-compatibility (since it is silent).
Therefore I suggest to be RI-compatible by default in all cases when
spec keep silence. I believe it well suites Paulex guidelines (please
correct me if I wrong).
+1
Talking about how particulary we should throw NPE I'm not sure what to
advise: in many cases RI just produces them automatically when actual
call like null.someMehtod() occurs. To provide better notation we can
do that directly, i.e.
if (someVar == null) {
throw NullPointerException(some valuable message)
}
I'm not really sure what is better and would like to know what others
think about.
I prefer to let these things happen automatically whenever possible.
Introducing an explicit check adds extra bytecodes and probably extra CPU
cycles in the non-null case. On some VMs null.someMethod() might be slower in
the null case, but if the RI also throws NPE then these cases should be truly
exceptional in the sense that they indicate a programming error or a missing
resource. OTOH if the RI treats a null argument as a normal case then this
should be implemented using 'if (someVar == null)', not by catching a NPE(!).
Chris
Btw, when we will work on documentation (javadoc) I think we should
append references to the standard Sun API in the methods javadoc with
the direct info about null-processing and NPE if a method can produce
it (when it is missing from the original spec of course).
--
Anton Avtamonov,
Intel Middleware Products Division
--
Chris Gray/k/ Embedded Java Solutions BE0503765045
Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/
[EMAIL PROTECTED] +32 3 216 0369
Re: NullPointerException
I have reminiscence that the general rule is that unless otherwise stated methods and constructors will throw NPE if passed null argument. Unfortunately I have not found more general place in javadoc stating this except following citing from java.util.logging package description: In general, unless otherwise noted in the javadoc, methods and contructors will throw NullPointerException if passed a null argument. The one broad exception to this rule is that the logging convenience methods in the Logger class (the config, entering, exiting, fine, finer, finest, log, logp, logrb, severe, throwing, and warning methods) will accept null values for all arguments except for the initial Level argument (if any). I understand this as that in general methods and constructors do not check if arguments passed are null or not, otherwise javadoc specifies the exact behavior. Of course there are exceptions which are not stated in javadoc, but those exceptions should be checked on case by case basis. Also I think that exact checks for null arguments are not necessary (except those cases when they have special meaning) and moreover could cause performance impact. -- Nikolay Kuznetsov, Intel Middleware Products Division
Re: NullPointerException
Anton Avtamonov wrote:
On 3/17/06, Karan Malhi [EMAIL PROTECTED] wrote:
Hi,
Some of the methods/constructors in the API throw a NullPointerException
when a null is passed in as an argument. The spec doesnt say anything that
the method/constructor should throw a NullPointerException, neither does it
say anything about how the method/constructor should behave when a null is
passed in.
What should be the approach in that case?
1. Could we check for null within a method and handle it so that the method
does not unneccessarily throw an NPE (this would differ from how the spec
would behave) or
2. should we allow the method to throw an NPE if the spec method also throws
it?
Hi,
Actually null-processing and corresponding NPEs are very very often
omitted from the spec.
I would say that according to the guidelines Paulex proposed (and as I
understood we agreed on) we should be RI-compatible in this case.
Really, spec doesn't say anything regarding null-processing and
therefore throwing NPE in this case does *not* contradict to the spec.
Having NPE we will be better RI-compatible and stay on the same
position in the spec-compatibility (since it is silent).
Therefore I suggest to be RI-compatible by default in all cases when
spec keep silence. I believe it well suites Paulex guidelines (please
correct me if I wrong).
I agree.
Talking about how particulary we should throw NPE I'm not sure what to
advise: in many cases RI just produces them automatically when actual
call like null.someMehtod() occurs. To provide better notation we can
do that directly, i.e.
if (someVar == null) {
throw NullPointerException(some valuable message)
}
I'm not really sure what is better and would like to know what others
think about.
I think either is fine. We have tended to let NPE be thrown 'naturally'
and only tested for it if we need to get the order of exceptions right
wrt the RI.
Btw, when we will work on documentation (javadoc) I think we should
append references to the standard Sun API in the methods javadoc with
the direct info about null-processing and NPE if a method can produce
it (when it is missing from the original spec of course).
Agreed.
Regards,
Tim
--
Anton Avtamonov,
Intel Middleware Products Division
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
Re: NullPointerException
Hi Karan, Actually there is a number of conditions that affect final case-by-case made decision: 1. The spec might say a) that SomeException (SE) is thrown in case of null arg b) that SE is thrown in case of invalid arg c) nothing about wrong args 2. The class and method under consideration might pass argument and control to some user's or third-party class (like some handler or crypto algorithm) and RI's NPE happens originally there. In this case we should study the spec for that class, implications of null arguments in that class and case-by-case decide. I think being compatible with RI is by-default decision, and in the majority of cases is the right decision to take. BTW, explicit check of an arg for null would unnoticably slow down execution in case of non-null argument but would siginificantly speed it up in case of null. Once again, decision is to be made case-by-case Thanks, Mikhail
Re: NullPointerException
On 3/17/06, Karan Malhi [EMAIL PROTECTED] wrote:
Hi,
Some of the methods/constructors in the API throw a NullPointerException
when a null is passed in as an argument. The spec doesnt say anything that
the method/constructor should throw a NullPointerException, neither does it
say anything about how the method/constructor should behave when a null is
passed in.
What should be the approach in that case?
1. Could we check for null within a method and handle it so that the method
does not unneccessarily throw an NPE (this would differ from how the spec
would behave) or
2. should we allow the method to throw an NPE if the spec method also throws
it?
Hi,
Actually null-processing and corresponding NPEs are very very often
omitted from the spec.
I would say that according to the guidelines Paulex proposed (and as I
understood we agreed on) we should be RI-compatible in this case.
Really, spec doesn't say anything regarding null-processing and
therefore throwing NPE in this case does *not* contradict to the spec.
Having NPE we will be better RI-compatible and stay on the same
position in the spec-compatibility (since it is silent).
Therefore I suggest to be RI-compatible by default in all cases when
spec keep silence. I believe it well suites Paulex guidelines (please
correct me if I wrong).
Talking about how particulary we should throw NPE I'm not sure what to
advise: in many cases RI just produces them automatically when actual
call like null.someMehtod() occurs. To provide better notation we can
do that directly, i.e.
if (someVar == null) {
throw NullPointerException(some valuable message)
}
I'm not really sure what is better and would like to know what others
think about.
Btw, when we will work on documentation (javadoc) I think we should
append references to the standard Sun API in the methods javadoc with
the direct info about null-processing and NPE if a method can produce
it (when it is missing from the original spec of course).
--
Anton Avtamonov,
Intel Middleware Products Division
[jira] Commented: (HARMONY-66) java.lang.SecurityManager.checkAccess(Thread t) throws NullPointerException for the dead thread.
[
http://issues.apache.org/jira/browse/HARMONY-66?page=comments#action_12364938 ]
Stepan Mishura commented on HARMONY-66:
---
I've looked into added regression test case and I have the following comment:
The current test case will pass if the method checkAccess() returns silently or
AccessControlException is thrown. I think the test case should be stricter and
pass only in one case. Otherwise the test case may mask a bug in Harmony
implementation.
In our case a security manager is not installed by default and the test case
doesn't install it too. As far as I understand the spec. the method
checkPermission should not be invoked so no AccessControlException is thrown.
However Harmony implementation throws exception.
java.lang.SecurityManager.checkAccess(Thread t) throws NullPointerException
for the dead thread.
Key: HARMONY-66
URL: http://issues.apache.org/jira/browse/HARMONY-66
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Elena Semukhina
Assignee: Tim Ellison
Priority: Minor
java.lang.SecurityManager.checkAccess(Thread t) throws NullPointerException
for the dead thread.
According to specification, the Thread.getThreadGroup() method returns null
if this thread has died.
SecurityManager.checkAccess(Thread t) should take that into account.
Code for reproducing:
public class ThreadCheckAccess {
class ThreadRunning extends Thread {
volatile boolean stopWork = false;
int i = 0;
public void run () {
while (!stopWork) {
}
}
}
public void test() {
SecurityManager sm = new SecurityManager();
System.setSecurityManager(sm);
ThreadRunning t = new ThreadRunning();
t.start();
t.stopWork = true;
try {
t.join();
} catch (InterruptedException e) {
e.printStackTrace();
}
try {
sm.checkAccess(t);
System.out.println(PASSED);
} catch (NullPointerException e) {
e.printStackTrace();
System.out.println(FAILED);
}
}
public static void main(String args[]) {
new ThreadCheckAccess().test();
}
}
Steps to Reproduce:
1. Build Harmony (check-out on 2006-01-31) j2se subset as described in
README.txt.
2. Compile ThreadCheckAccess.java using BEA 1.4 javac
javac -d . ThreadCheckAccess.java
2. Run java using compatible VM (J9)
java -showversion ThreadCheckAccess
Output:
java version 1.4.2 (subset)
(c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as
applicable.
java.lang.NullPointerException
at java.lang.SecurityManager.checkAccess(SecurityManager.java:92)
at java.lang.Thread.checkAccess(Thread.java:423)
at ThreadCheckAccess.test(ThreadCheckAccess.java:23)
at ThreadCheckAccess.main(ThreadCheckAccess.java:32)
FAILED
Output on BEA 1.4.2:
PASSED
Suggested junit test case:
package org.apache.harmony.tests.java.lang;
import junit.framework.TestCase;
public class SecurityManagerTest extends TestCase {
class ThreadRunning extends Thread {
volatile boolean stopWork = false;
int i = 0;
public void run () {
while (!stopWork) {
}
}
}
public void test_checkAccessLjava_lang_Thread() {
SecurityManager sm = new SecurityManager();
System.setSecurityManager(sm);
ThreadRunning t = new ThreadRunning();
t.start();
t.stopWork = true;
try {
t.join();
} catch (InterruptedException e) {
fail(Assert 0: unexpected + e);
}
try {
sm.checkAccess(t);
} catch (NullPointerException e) {
fail(Assert 1: NullPointerException has been thrown);
}
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (HARMONY-66) java.lang.SecurityManager.checkAccess(Thread t) throws NullPointerException for the dead thread.
[
http://issues.apache.org/jira/browse/HARMONY-66?page=comments#action_12364939 ]
Elena Semukhina commented on HARMONY-66:
Tim,
unfortunately the fix is not correct. Now the test fails on checking permission
as follows:
Exception in thread main java.security.AccessControlException: Access denied
(java.lang.RuntimePermission modifyThread)
at java.security.AccessController.checkPermission(AccessController.java:
90)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:704)
at java.lang.SecurityManager.checkAccess(SecurityManager.java:94)
at ThreadCheckAccess.test(ThreadCheckAccess.java:24)
at ThreadCheckAccess.main(ThreadCheckAccess.java:33)
The point is that SecurityManager.checkAccess(Thread) should call
checkPermission only for system threads, otherwise it should return silently.
java.lang.SecurityManager.checkAccess(Thread t) throws NullPointerException
for the dead thread.
Key: HARMONY-66
URL: http://issues.apache.org/jira/browse/HARMONY-66
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Elena Semukhina
Assignee: Tim Ellison
Priority: Minor
java.lang.SecurityManager.checkAccess(Thread t) throws NullPointerException
for the dead thread.
According to specification, the Thread.getThreadGroup() method returns null
if this thread has died.
SecurityManager.checkAccess(Thread t) should take that into account.
Code for reproducing:
public class ThreadCheckAccess {
class ThreadRunning extends Thread {
volatile boolean stopWork = false;
int i = 0;
public void run () {
while (!stopWork) {
}
}
}
public void test() {
SecurityManager sm = new SecurityManager();
System.setSecurityManager(sm);
ThreadRunning t = new ThreadRunning();
t.start();
t.stopWork = true;
try {
t.join();
} catch (InterruptedException e) {
e.printStackTrace();
}
try {
sm.checkAccess(t);
System.out.println(PASSED);
} catch (NullPointerException e) {
e.printStackTrace();
System.out.println(FAILED);
}
}
public static void main(String args[]) {
new ThreadCheckAccess().test();
}
}
Steps to Reproduce:
1. Build Harmony (check-out on 2006-01-31) j2se subset as described in
README.txt.
2. Compile ThreadCheckAccess.java using BEA 1.4 javac
javac -d . ThreadCheckAccess.java
2. Run java using compatible VM (J9)
java -showversion ThreadCheckAccess
Output:
java version 1.4.2 (subset)
(c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as
applicable.
java.lang.NullPointerException
at java.lang.SecurityManager.checkAccess(SecurityManager.java:92)
at java.lang.Thread.checkAccess(Thread.java:423)
at ThreadCheckAccess.test(ThreadCheckAccess.java:23)
at ThreadCheckAccess.main(ThreadCheckAccess.java:32)
FAILED
Output on BEA 1.4.2:
PASSED
Suggested junit test case:
package org.apache.harmony.tests.java.lang;
import junit.framework.TestCase;
public class SecurityManagerTest extends TestCase {
class ThreadRunning extends Thread {
volatile boolean stopWork = false;
int i = 0;
public void run () {
while (!stopWork) {
}
}
}
public void test_checkAccessLjava_lang_Thread() {
SecurityManager sm = new SecurityManager();
System.setSecurityManager(sm);
ThreadRunning t = new ThreadRunning();
t.start();
t.stopWork = true;
try {
t.join();
} catch (InterruptedException e) {
fail(Assert 0: unexpected + e);
}
try {
sm.checkAccess(t);
} catch (NullPointerException e) {
fail(Assert 1: NullPointerException has been thrown);
}
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (HARMONY-66) java.lang.SecurityManager.checkAccess(Thread t) throws NullPointerException for the dead thread.
[
http://issues.apache.org/jira/browse/HARMONY-66?page=comments#action_12365048 ]
Elena Semukhina commented on HARMONY-66:
Tim,
this time the fix looks fine and the test passes.
java.lang.SecurityManager.checkAccess(Thread t) throws NullPointerException
for the dead thread.
Key: HARMONY-66
URL: http://issues.apache.org/jira/browse/HARMONY-66
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Elena Semukhina
Assignee: Tim Ellison
Priority: Minor
java.lang.SecurityManager.checkAccess(Thread t) throws NullPointerException
for the dead thread.
According to specification, the Thread.getThreadGroup() method returns null
if this thread has died.
SecurityManager.checkAccess(Thread t) should take that into account.
Code for reproducing:
public class ThreadCheckAccess {
class ThreadRunning extends Thread {
volatile boolean stopWork = false;
int i = 0;
public void run () {
while (!stopWork) {
}
}
}
public void test() {
SecurityManager sm = new SecurityManager();
System.setSecurityManager(sm);
ThreadRunning t = new ThreadRunning();
t.start();
t.stopWork = true;
try {
t.join();
} catch (InterruptedException e) {
e.printStackTrace();
}
try {
sm.checkAccess(t);
System.out.println(PASSED);
} catch (NullPointerException e) {
e.printStackTrace();
System.out.println(FAILED);
}
}
public static void main(String args[]) {
new ThreadCheckAccess().test();
}
}
Steps to Reproduce:
1. Build Harmony (check-out on 2006-01-31) j2se subset as described in
README.txt.
2. Compile ThreadCheckAccess.java using BEA 1.4 javac
javac -d . ThreadCheckAccess.java
2. Run java using compatible VM (J9)
java -showversion ThreadCheckAccess
Output:
java version 1.4.2 (subset)
(c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as
applicable.
java.lang.NullPointerException
at java.lang.SecurityManager.checkAccess(SecurityManager.java:92)
at java.lang.Thread.checkAccess(Thread.java:423)
at ThreadCheckAccess.test(ThreadCheckAccess.java:23)
at ThreadCheckAccess.main(ThreadCheckAccess.java:32)
FAILED
Output on BEA 1.4.2:
PASSED
Suggested junit test case:
package org.apache.harmony.tests.java.lang;
import junit.framework.TestCase;
public class SecurityManagerTest extends TestCase {
class ThreadRunning extends Thread {
volatile boolean stopWork = false;
int i = 0;
public void run () {
while (!stopWork) {
}
}
}
public void test_checkAccessLjava_lang_Thread() {
SecurityManager sm = new SecurityManager();
System.setSecurityManager(sm);
ThreadRunning t = new ThreadRunning();
t.start();
t.stopWork = true;
try {
t.join();
} catch (InterruptedException e) {
fail(Assert 0: unexpected + e);
}
try {
sm.checkAccess(t);
} catch (NullPointerException e) {
fail(Assert 1: NullPointerException has been thrown);
}
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Assigned: (HARMONY-66) java.lang.SecurityManager.checkAccess(Thread t) throws NullPointerException for the dead thread.
[ http://issues.apache.org/jira/browse/HARMONY-66?page=all ]
Tim Ellison reassigned HARMONY-66:
--
Assign To: Tim Ellison
java.lang.SecurityManager.checkAccess(Thread t) throws NullPointerException
for the dead thread.
Key: HARMONY-66
URL: http://issues.apache.org/jira/browse/HARMONY-66
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Elena Semukhina
Assignee: Tim Ellison
Priority: Minor
java.lang.SecurityManager.checkAccess(Thread t) throws NullPointerException
for the dead thread.
According to specification, the Thread.getThreadGroup() method returns null
if this thread has died.
SecurityManager.checkAccess(Thread t) should take that into account.
Code for reproducing:
public class ThreadCheckAccess {
class ThreadRunning extends Thread {
volatile boolean stopWork = false;
int i = 0;
public void run () {
while (!stopWork) {
}
}
}
public void test() {
SecurityManager sm = new SecurityManager();
System.setSecurityManager(sm);
ThreadRunning t = new ThreadRunning();
t.start();
t.stopWork = true;
try {
t.join();
} catch (InterruptedException e) {
e.printStackTrace();
}
try {
sm.checkAccess(t);
System.out.println(PASSED);
} catch (NullPointerException e) {
e.printStackTrace();
System.out.println(FAILED);
}
}
public static void main(String args[]) {
new ThreadCheckAccess().test();
}
}
Steps to Reproduce:
1. Build Harmony (check-out on 2006-01-31) j2se subset as described in
README.txt.
2. Compile ThreadCheckAccess.java using BEA 1.4 javac
javac -d . ThreadCheckAccess.java
2. Run java using compatible VM (J9)
java -showversion ThreadCheckAccess
Output:
java version 1.4.2 (subset)
(c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as
applicable.
java.lang.NullPointerException
at java.lang.SecurityManager.checkAccess(SecurityManager.java:92)
at java.lang.Thread.checkAccess(Thread.java:423)
at ThreadCheckAccess.test(ThreadCheckAccess.java:23)
at ThreadCheckAccess.main(ThreadCheckAccess.java:32)
FAILED
Output on BEA 1.4.2:
PASSED
Suggested junit test case:
package org.apache.harmony.tests.java.lang;
import junit.framework.TestCase;
public class SecurityManagerTest extends TestCase {
class ThreadRunning extends Thread {
volatile boolean stopWork = false;
int i = 0;
public void run () {
while (!stopWork) {
}
}
}
public void test_checkAccessLjava_lang_Thread() {
SecurityManager sm = new SecurityManager();
System.setSecurityManager(sm);
ThreadRunning t = new ThreadRunning();
t.start();
t.stopWork = true;
try {
t.join();
} catch (InterruptedException e) {
fail(Assert 0: unexpected + e);
}
try {
sm.checkAccess(t);
} catch (NullPointerException e) {
fail(Assert 1: NullPointerException has been thrown);
}
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Resolved: (HARMONY-66) java.lang.SecurityManager.checkAccess(Thread t) throws NullPointerException for the dead thread.
[ http://issues.apache.org/jira/browse/HARMONY-66?page=all ]
Tim Ellison resolved HARMONY-66:
Resolution: Fixed
Elena,
Fixed in LUNI module java.lang.SecurityManager at repo revision 374062.
Please check that this fully resolves your problem.
java.lang.SecurityManager.checkAccess(Thread t) throws NullPointerException
for the dead thread.
Key: HARMONY-66
URL: http://issues.apache.org/jira/browse/HARMONY-66
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Elena Semukhina
Assignee: Tim Ellison
Priority: Minor
java.lang.SecurityManager.checkAccess(Thread t) throws NullPointerException
for the dead thread.
According to specification, the Thread.getThreadGroup() method returns null
if this thread has died.
SecurityManager.checkAccess(Thread t) should take that into account.
Code for reproducing:
public class ThreadCheckAccess {
class ThreadRunning extends Thread {
volatile boolean stopWork = false;
int i = 0;
public void run () {
while (!stopWork) {
}
}
}
public void test() {
SecurityManager sm = new SecurityManager();
System.setSecurityManager(sm);
ThreadRunning t = new ThreadRunning();
t.start();
t.stopWork = true;
try {
t.join();
} catch (InterruptedException e) {
e.printStackTrace();
}
try {
sm.checkAccess(t);
System.out.println(PASSED);
} catch (NullPointerException e) {
e.printStackTrace();
System.out.println(FAILED);
}
}
public static void main(String args[]) {
new ThreadCheckAccess().test();
}
}
Steps to Reproduce:
1. Build Harmony (check-out on 2006-01-31) j2se subset as described in
README.txt.
2. Compile ThreadCheckAccess.java using BEA 1.4 javac
javac -d . ThreadCheckAccess.java
2. Run java using compatible VM (J9)
java -showversion ThreadCheckAccess
Output:
java version 1.4.2 (subset)
(c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as
applicable.
java.lang.NullPointerException
at java.lang.SecurityManager.checkAccess(SecurityManager.java:92)
at java.lang.Thread.checkAccess(Thread.java:423)
at ThreadCheckAccess.test(ThreadCheckAccess.java:23)
at ThreadCheckAccess.main(ThreadCheckAccess.java:32)
FAILED
Output on BEA 1.4.2:
PASSED
Suggested junit test case:
package org.apache.harmony.tests.java.lang;
import junit.framework.TestCase;
public class SecurityManagerTest extends TestCase {
class ThreadRunning extends Thread {
volatile boolean stopWork = false;
int i = 0;
public void run () {
while (!stopWork) {
}
}
}
public void test_checkAccessLjava_lang_Thread() {
SecurityManager sm = new SecurityManager();
System.setSecurityManager(sm);
ThreadRunning t = new ThreadRunning();
t.start();
t.stopWork = true;
try {
t.join();
} catch (InterruptedException e) {
fail(Assert 0: unexpected + e);
}
try {
sm.checkAccess(t);
} catch (NullPointerException e) {
fail(Assert 1: NullPointerException has been thrown);
}
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
