RE: New IBM VME available soon
Chris Gray wrote: > Olivier dixit: > > > ok, I just tested myself on Windows and it seems that the RI ignores > > environment variable changes, so I guess it's fine if we > stick with what > > we have in Harmony. > > Now that I think about it, I remember someone complaining > once on a Java newsgroup that changing the CLASSPATH environment > variable had no effect on a running JVM. He got an education in > Java class loading. :-) On Windows at least this actually has nothing to do with class loading. You simply cannot modify an environment variable of a running process (at least not from outside that process). Every process has its own copy, so changing the parent process' environment makes no difference, nor does changing the environment of a child process. Regards, Jeroen - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [general] compatibility packages
Dalibor Topic wrote: > First part of the problem was the JavaScript bridge, which allowed > access to sun.* code, and the second part was sun.misc.Unsafe, which > allows kicking the legs under the Java security mechanism in > three lines of pure Java code, once you get access to it. I respectfully disagree. The fact that the access controls around sun.misc.Unsafe failed was the problem, not the functionality it provides. You can clear the security manager with reflection too, but we rely on the access controls in reflection to protect us against that, if they fail, do you want to remove reflection as well? > I am not aware of any other potentially useful code that uses > sun.misc.Unsafe, but I'd appreciate pointers. I've seen code that had their own implementation of Object[In|Out]putStream, you cannot do that in pure Java (which is lame), but they managed to do it by using sun.reflect.* classes I believe. Regards, Jeroen - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [general] compatibility packages
Dalibor Topic wrote: > So if I can't run the sun.misc.Unsafe remote exploit on > Harmony it is a failure? ;) You keep referring to this, but IMO this is a mischaracterization of the exploit. The exploit used a bug in JavaScript that allowed access to the sun.* package, that was the real problem not the sun.misc.Unsafe class. You also keep hammering on CharToByteConverter as an example of bad code that should trivially be fixed (and it obviously should, if possible, but it's not always that easy), but there is also code out there that uses sun.* classes to do things that are impossible to do with the documented APIs. How would you fix those? BTW, that was a retorical question, because I already know your answer: that's rubbish software that won't work reliably on Sun's JRE anyway, so why should we support it? However, I've spoken with Mark Reinhold about this issue and he told me that Sun sometimes reverts changes to sun.* classes because a customer complains that it broke their code. I asked him if they would be documenting these classes when they do this, but he said they wouldn't. So they seem to live in a dream world where on the one hand they want to discourage usage of sun.* and on the other hand continue to support it. Like compatibility in general this is a hard problem and we need to take a pragmatic approach and I really like the current plan of having an optional suncompat module. Regards, Jeroen - 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
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: JVM spec interpretation questions
[EMAIL PROTECTED] wrote: > I have some questions here: > > (A) If an 'Error' is caught by an application handler > and does not > exit() the program or some other drastic action, I presume that > the application just keeps running. But if it is not > caught, meaning > that none of the methods in the stack have a handler, then it must > be handled by the handler provided by the JVM. At this > point, does > the thread quit, just like an 'Exception' does, or should the JVM > shut down completely? Except for the finalize() case, any Throwable that is not caught by user code is handled by the VM (i.e. passed to the Thread.UncaughtExceptionHandler or ThreadGroup.uncaughtException() method). > (B) In the API spec 1.5.0, there are only two known > direct subclasses > of java.lang.Throwable. Is there any reason at all to > EVER expect an > application to define some class that is a direct > subclass of java.lang.Throwable > that is, not also a subclass of 'Exception' or 'Error'? This question is not relevant to the VM implementer. Rule 1: Whether there is a reason or not, someone will do it. In any case, the VM doesn't really care about it. In all but one case, the VM only cares about Throwable. The single exception is when an exception (i.e. Throwable) escapes from a static initializer, if the exception is not an Error the VM will wrap the exception in an ExceptionInInitializerError. Regards, Jeroen
RE: C compilers comparison: MSVC vs GCC vs DevCpp
Enrico Migliore wrote:
> the code is a simple function that gets called 3 times.
This is a flawed test. Your code doesn't actually do anything, so the
function can be optimized away entirely and this is in fact was MSVC 7.1
does ("the test lasted for 0. seconds")
Regards,
Jeroen
RE: Class library componentization
Sven de Marothy wrote: > Please observe that JAPItools isn't fully 1.5-compatible > (read: problems with generics, I think), so it reports more > errors than what's actually there. Actually, it underestimates the number of errors. For binary compatibility the results are still valid though. The differences really only matter for source level (and to a limited degree reflection) compatibility. Regards, Jeroen
RE: Minutes of First Harmony Meeting
Geir Magnusson Jr. wrote: > I'll buy that, except I'll note that the IKVM license isn't > recognized as an OSS license by OSI Yes it is, it's the zlib license: http://www.opensource.org/licenses/zlib-license.php Regards, Jeroen
RE: The Classpath VM interface. (Please read)
Geir Magnusson Jr. wrote: > You are misrepresenting the problem. it's not that it's language > protection, but that you extend java.lang namespace and are hoping > that you don't get tromped by the spec at some point in the future. > (Nor is it clear that it's good citizenship working in that > namespace as well...) Please send a patch to classpath-patches with your alternative approach, or shut up already ;-) Regards, Jeroen
RE: [arch] How much of java.* and friends does Harmony need to write. Was: VM/Classlibrary interface
Richard S. Hall wrote: > Jeroen Frijters wrote: > > >You are correct, but why take the performance and complexity hit to > >solve a non-existing problem? > > The simpler solution is to just use class loaders as a modularization > mechanism. No, that does not solve the problem of getting access to the internals of public classes. For example, java.lang.VMThread needs to access package private methods in java.lang.Thread. Regards, Jeroen
RE: [arch] How much of java.* and friends does Harmony need to write. Was: VM/Classlibrary interface
You are correct, but why take the performance and complexity hit to solve a non-existing problem? Regards, Jeroen > -Original Message- > From: Aaron Hamid [mailto:[EMAIL PROTECTED] > Sent: Sunday, June 05, 2005 20:44 > To: harmony-dev@incubator.apache.org > Subject: Re: [arch] How much of java.* and friends does > Harmony need to write. Was: VM/Classlibrary interface > > I actually had not considered this issue which would seem to warrant > these classes living in the same package. But can not an equivalent > solution be constructed such that the implementations of these public > classes can hand the VM* classes references to internal > structures (and > vice versa) though well defined interfaces, instead of relying on > visibility modifiers to allow the VM* objects to access > private state of > java.lang classes, thereby allowing the VM* objects to live in a > separate package? Or am I misunderstanding your statement (or maybe > that is just too cumbersome)? > > Aaron > > Jeroen Frijters wrote: > > > > You're missing the fact that moving these classes into > another packages > > creates another problem that is much worse. Namely that you > often need > > to access private state in the public classes, you can do > that by living > > in the same package, that's why the VM* classes live in the > same package > > as their public counterpart. > > > > Regards, > > Jeroen >
RE: [arch] How much of java.* and friends does Harmony need to write. Was: VM/Classlibrary interface
Geir Magnusson Jr. wrote: > On Jun 5, 2005, at 2:12 PM, Jeroen Frijters wrote: > > Geir Magnusson Jr. wrote: > >>> Geir Magnusson Jr. wrote: > >>>> True, except I really hate extending java.lang. :) > >>> > >>> What do you mean by "extending java.lang"? GNU Classpath does not > >>> extend > >>> java.lang (for any reasonable definition of extend). > Having package > >>> private classes is not extending. > >> > >> Why do you say that? Suppose for J2SE 6, the EG adds the public > >> class java.lang.VMObject. then what? > > > > Then we rename it. A new Java version will involve changes to the VM > > interface anyway, so this makes no difference. > > I assume you'd keep it in java.lang? > > Isn't that just sliding the deck chairs around? No, it's a trivial cost. Your proposed solution is in reality much more expensive. You're missing the fact that moving these classes into another packages creates another problem that is much worse. Namely that you often need to access private state in the public classes, you can do that by living in the same package, that's why the VM* classes live in the same package as their public counterpart. Regards, Jeroen
RE: [arch] How much of java.* and friends does Harmony need to write. Was: VM/Classlibrary interface
Geir Magnusson Jr. wrote: > > Geir Magnusson Jr. wrote: > > > >> True, except I really hate extending java.lang. :) > > > > What do you mean by "extending java.lang"? GNU Classpath does not > > extend > > java.lang (for any reasonable definition of extend). Having package > > private classes is not extending. > > Why do you say that? Suppose for J2SE 6, the EG adds the public > class java.lang.VMObject. then what? Then we rename it. A new Java version will involve changes to the VM interface anyway, so this makes no difference. Regards, Jeroen
RE: [arch] How much of java.* and friends does Harmony need to write. Was: VM/Classlibrary interface
Geir Magnusson Jr. wrote: > True, except I really hate extending java.lang. :) What do you mean by "extending java.lang"? GNU Classpath does not extend java.lang (for any reasonable definition of extend). Having package private classes is not extending. Regards, Jeroen
