Re: [arch] How much of java.* and friends does Harmony need to write. Was: VM/Classlibrary interface
Jeroen I think there are at least two perceived problems being voiced: * aversion to the idea of "polluting" a standard library distribution (e.g. Classpath) with VM-specific interface implementations. Although there have been assurances that such work is trivial and the interface is always-changing, it makes it harder to decouple the VM from the class library (although another opinion is that this is not a goal of Harmony anyway).The fact that all (?) VMs using the Classpath library must make modifications to Classpath itself is an indication that perhaps standardization on interfaces (not implementations of course) would be beneficial. * uncomfortableness with relying on language visibility modifiers alone to prevent user code access to these internal APIs (this I am personally not that concerned about) Not to be pedantic - but for purposes of clarification can we quantify the "performance and complexity hit" for using well-defined interfaces as opposed to carnal knowledge between the class library and VM interface implementations? From what I have understood, for example, of the JikesRVM, these sorts of things are candidates for some heavy optimizations - especially given that these interfaces should not be used by user code at all, and should probably not be reloaded/unloaded/subject to traditional class loading issues (perhaps use some modularization, annotation, or magic keyword syntax that allows aggressive optimization of otherwise "public" interfaces?). Aaron Jeroen Frijters wrote: 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
On Sun, 2005-06-05 at 14:20 -0300, Geir Magnusson Jr. wrote: > > > > Reimplementing java.lang certainly is a penalty. > > I don't understand - I might have misstated something. Why do you > think I want to re-implement java.lang? No, I can't speak for you. But it's been suggested on this list. > Any JVM that uses GNU Classpath has to implement java.lang parts, right? > All I'm suggesting that we move the stuff that's not standard java.lang as > defined in a spec somewhere off to another package name. Thanks for clarifying your position. > Why not do it now so we don't have to fix it later, since to do J2SE > 5 we *are* going to have to modify it... Because I'm doubtful that we'll be able to produce a good specification without anyone having done at least one implementation. > But before we go leaping off to 1.6, how about 1.5? And perhaps support 1.4 before that? I'd say wait until you get full 1.4 before worrying about 1.5. > >> why not? Why restrict that freedom for users? > >> > > > > 1) Because Sun hasn't documented their VM interface. > > We don't care, do we? We can do our own. Ok. But then you won't be able to use Sun's class library. Which I believed was the point here? > Remember the modularity goal - we want people to be able to take this > stuff and plug-n-play with whatever they want. If for whatever > reason they wanted to plug in Sun's class library, why would we want > to prevent that? I don't see any reason for wanting to prevent that. But I don't see why you should go out of your way to enable it, if it means implementing undocumented proprietary interfaces. And it does. /Sven
Re: [arch] How much of java.* and friends does Harmony need to write. Was: VM/Classlibrary interface
Jeroen Frijters wrote: 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. You are correct, if your design is such that you need private access both ways, then you are pretty much screwed. I would have thought that java.lang.Thread would have only needed access to java.lang.VMThread, not the other way around. C'est la vie. -> richard
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
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. It is possible (since I have done it in my OSGi framework) to create a class loader that handles libraries packaged as JAR files such that some packages are externally visible and some are not. Thus, the VM objects could be in another package and all have public access modifiers, but they would only be accessible to classes inside the JAR file, not outside of it. Sure, it is not impossible to get access to the VM classes in this approach, but none of the proposed solutions offer this guarantee either. -> richard 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
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
On Sun, Jun 05, 2005 at 02:20:53PM -0300, Geir Magnusson Jr. wrote: > > On Jun 5, 2005, at 1:45 PM, Sven de Marothy wrote: > > >On Sun, 2005-06-05 at 06:25 -0300, Geir Magnusson Jr. wrote: > > > >>On Jun 4, 2005, at 12:59 PM, Sven de Marothy wrote: > >> > >>>AFAIK there are > >>>no other class libraries out there which you'll legally be able to > >>>distribute with Harmony. So why create flexibility when there aren't > >>>options? > >>> > >>> > >> > >>Are you kidding? There aren't options *now* (well, that's not really > >>true, is it...), > >> > > > >Could you elaborate on that? I don't know of any class library > >distributable under the Apache license. > > There are other licenses. Remember, we aren't only concerned about > ourselves, but what a downstream user of our stuff will want to do. > We tend to try to protect their freedoms as well. (See "Ulcer, > Geir's, re J2EE TCK license") Could you elaborate on those things? You sound as if there is some option for downstream users on your mind, but you are not coming out with it, and it is not very clear what it is from guessing what you might be thinking of ;) > > > > > >>but that doesn't meant that options won't come > >>around in the future. I think we're still in the very beginning of > >>"managed runtime environments" and generalization w/o penalty is a > >>Good Thing(tm). > >> > > > >Reimplementing java.lang certainly is a penalty. > > I don't understand - I might have misstated something. Why do you > think I want to re-implement java.lang? Any JVM that uses GNU > Classpath has to implement java.lang parts, right? All I'm > suggesting that we move the stuff that's not standard java.lang as > defined in a spec somewhere off to another package name. I beliee the confusion exists because someone else suggested reimplementing all of java.lang with a rather odd justification, to be able to mix in SCSLd code, that is not practicable nor legally possible to distribute ;) Your argumentation jumped right into the middle of that and that may have lead people to assume wrong things. Maybe you should simply start a new thread, present a use case, show what breaks, and we can analyze it. Hunting things down in this long htread seems to be very confusing for everyone. > > > >Again, this is NOT a major issue. *If* or *when* these options become > >available, *that* will be the time to adress this. It is not such a > >major task as folks seem to think here to change the VM-classlib > >interface. Indeed it has been done already for VMs such as JikesRVM. > > > Why not do it now so we don't have to fix it later, since to do J2SE > 5 we *are* going to have to modify it... Given that no such options exist, it is not possible to make any ammendments for them right now, right, as noone knws what ammendments they would need? ;) What are the options on your mind? Could you give us some nice scenarios, name some names, to see what motivates the discussion and how we can fix the the problems in the VM interface for those users and/or clear up any misconceptions about it. cheers, dalbor topic > > > >Reimplementing java.lang is more work. > > See above - I think there is a miscommunication here > > > > > > > > >>And maybe we have more to learn in this area from other > >>implementations and newer Java APIs. > >> > > > >I don't like "maybe"s. I like specific problems for which I can devise > >specific solutions. > > Me too, and I'm hoping someone who has done this will point out some > specific problems they needed to solve. > > > > >Maybe Java 1.6 will require VMs to be able to make breakfast; > >Should we > >start designing a VM-toaster interface, just in case? > > As long as you don't put it in java.lang, I'm all for it... :) > > But before we go leaping off to 1.6, how about 1.5? > > > > > > >>>Why would you want to have a Free VM which can use non-free > >>>libraries? > >>> > >>> > >> > >>why not? Why restrict that freedom for users? > >> > > > >1) Because Sun hasn't documented their VM interface. > > We don't care, do we? We can do our own. > > > > >2) Because people who have Sun's class library already have Sun's VM. > >What would they want with Harmony for? > > Ya never know :) > > > > >3) Because I thought the main idea was a complete VM under the Apache > >license. Not ASL+SCSL. > > Remember the modularity goal - we want people to be able to take this > stuff and plug-n-play with whatever they want. If for whatever > reason they wanted to plug in Sun's class library, why would we want > to prevent that? > > geir > > -- > Geir Magnusson Jr +1-203-665-6437 > [EMAIL PROTECTED] > >
Re: [arch] How much of java.* and friends does Harmony need to write. Was: VM/Classlibrary interface
On Sun, Jun 05, 2005 at 06:20:37AM -0300, Geir Magnusson Jr. wrote: > > On Jun 3, 2005, at 6:39 PM, Dalibor Topic wrote: > > > > >That's a rather weird thing to standardise, being the internals of > >a binding > >between the library and the VM, and necessarily something that is > >in flux, as > >VMs and class libraries change internally. And they do change quite > >a bit over > >time ;) > > > > > > I assume they only change as the Java API changes? I.e. the > interface needed for 1.4 could be different than the interface needed > for 1.5 etc? (and similarly, if the interface is different, it > implies a required change on both sides of it ?) They change according to everyone'S needs. That may be chanes in the API specs that require native or VM specific support, but also may be cleanups, optimizations, bug fixes, and so on. > > If that's so, then I think it is reasonable to standardize - you'd > just have the standard interface for a given Java API version... So far, things have continued to evolved quickly to accomodate the needs of all different VMs in classpath, and quite effectively. So, as lng as everything continues to be in flux, i doubt it will be something to standardise on right now. the changes are proposed on the classpath mailing list, and discussed there. cheers, dalibor topic > geir > > -- > Geir Magnusson Jr +1-203-665-6437 > [EMAIL PROTECTED] > > >
RE: [arch] How much of java.* and friends does Harmony need to write. Was: VM/Classlibrary interface
There is also http://java.sun.com/docs/books/vmspec/2nd-edition/ClassFileFormat-final- draft.pdf. According to http://asm.objectweb.org/doc/tutorial-annotations.html it included "modifications for J2SE 5.0 to support changes mandated by JSR-14, JSR-175, and JSR-201, as well as minor corrections and adjustments." Nick > -Original Message- > From: Ulrich Kunitz [mailto:[EMAIL PROTECTED] > Sent: Monday, 6 June 2005 8:01 AM > To: harmony-dev@incubator.apache.org > Subject: Re: [arch] How much of java.* and friends does > Harmony need to write. Was: VM/Classlibrary interface > > On Sun, 5 Jun 2005, Geir Magnusson Jr. wrote: > > > > Also from time to time the VM interface has to be > extended for new > > > VMs, which have different needs. This is one reason that the > > > interface isn't yet stable, even for 1.4. > > > > It would be interesting to know why and how it was extended > - there's > > something to learn there. I'm also interested in getting > some input > > from the commercial VM developers. > > The new features in 1.5 varargs, enums, annotations, and > generics required additions to the class file format. More > changes appear to be introduced to improve debugging (type > infos about local variables). > > Tom Tromey has already found a link to an updated class file > description: > > http://java.sun.com/docs/books/vmspec/2nd-edition/UpdatedClass FileFormat.pdf > > Here is a short and probably incomplete overview over the changes: > > varargs: ACC_VARARGS, ACC_BRIDGE (?) > enums:ACC_ENUM > annotations: ACC_ANNOTATION > > New attributes: EnclosingMethod, Signature (for generics), > LocalVariableTypeTable, > RuntimeVisibleAnnotations, > RuntimeInvisibleAnnotations, > RumtimeVisibleParameterAnnotations, > RumtimeInvisibleParameterAnnotations, > > Uli > IMPORTANT: This e-mail, including any attachments, may contain private or confidential information. If you think you may not be the intended recipient, or if you have received this e-mail in error, please contact the sender immediately and delete all copies of this e-mail. If you are not the intended recipient, you must not reproduce any part of this e-mail or disclose its contents to any other party. This email represents the views of the individual sender, which do not necessarily reflect those of education.au limited except where the sender expressly states otherwise. It is your responsibility to scan this email and any files transmitted with it for viruses or any other defects. education.au limited will not be liable for any loss, damage or consequence caused directly or indirectly by this email.
Re: [arch] How much of java.* and friends does Harmony need to write. Was: VM/Classlibrary interface
On Sun, 5 Jun 2005, Geir Magnusson Jr. wrote: > > Also from time to time the VM interface has to be extended for new > > VMs, which have different needs. This is one reason that the > > interface isn't yet stable, even for 1.4. > > It would be interesting to know why and how it was extended - there's > something to learn there. I'm also interested in getting some input from the > commercial VM developers. The new features in 1.5 varargs, enums, annotations, and generics required additions to the class file format. More changes appear to be introduced to improve debugging (type infos about local variables). Tom Tromey has already found a link to an updated class file description: http://java.sun.com/docs/books/vmspec/2nd-edition/UpdatedClassFileFormat.pdf Here is a short and probably incomplete overview over the changes: varargs:ACC_VARARGS, ACC_BRIDGE (?) enums: ACC_ENUM annotations:ACC_ANNOTATION New attributes: EnclosingMethod, Signature (for generics), LocalVariableTypeTable, RuntimeVisibleAnnotations, RuntimeInvisibleAnnotations, RumtimeVisibleParameterAnnotations, RumtimeInvisibleParameterAnnotations, Uli
Re: [arch] How much of java.* and friends does Harmony need to write. Was: VM/Classlibrary interface
> "Geir" == Geir Magnusson <[EMAIL PROTECTED]> writes: >> Yes, 1.5 *will* add new requirements to the VM interface. But the >> Classpath VM interface isn't some immutable static thing either. >> All I'm saying here is: how about crossing that bridge when you get >> there, instead of deciding out of hand that it isn't good enough? Geir> Guess which version of J2SE we want to do... So far nobody has systematically looked at all the VM layer changes needed for 1.5. However, I have looked at a few. The ones I've looked at are mostly related to Class or reflection; we need to add some more methods to VMClass and friends to account for the new data that is available. We also needed VMClass.cast(), a change to VMSystem for the new getenv, and a change to VMProcess for ProcessBuilder. As far as I know we won't need any major overhauls, just additions here and there. But if someone wanted to go through all the new bits and check this, that would be helpful. Better yet, actually go write the new bits, there is plenty of 1.5 stuff still to be done. Tom
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" == Geir Magnusson <[EMAIL PROTECTED]> writes: >> I still don't understand why you think this. >> Could you explain what problem might arise? Geir> Sun adds "java.lang.VMObject" as a public class (ok, farfetched) or Geir> adds it as a private class (not so farfetched). Ok, this is the scenario. This I understand. But what actual problem does this cause? Tom
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
On Jun 5, 2005, at 2:06 PM, Tom Tromey wrote: "Geir" == Geir Magnusson <[EMAIL PROTECTED]> writes: Dan> I've Dan> never tried that, but Geir is right, I think it can be done if Dan> you try hard enough. In the second case, when there is a security manager, then, no, you cannot get around the access controls, even with reflection. Geir> Why would I have to "get around" the access controls? I'm the VM. I Geir> can do magic things, right? (I should be able to...) I thought we were talking about malicious user code. Ah - sorry. I was tired and on a plane home from Brazil. I though we were talking about how the code running in the context of the VM (as opposed to user code) could get ahold of the necessary classes (and protect them from malicious user code) geir Tom -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [arch] How much of java.* and friends does Harmony need to write. Was: VM/Classlibrary interface
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? geir Regards, Jeroen -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [arch] How much of java.* and friends does Harmony need to write. Was: VM/Classlibrary interface
On Jun 5, 2005, at 2:05 PM, Tom Tromey wrote: "Geir" == Geir Magnusson <[EMAIL PROTECTED]> writes: Geir> That's not fair. I told you that *I* think that extending java.lang Geir> is a *bad idea*. I still don't understand why you think this. Could you explain what problem might arise? Sun adds "java.lang.VMObject" as a public class (ok, farfetched) or adds it as a private class (not so farfetched). Geir> Also, I don't know what the 1.4 and 1.5 Java API requirements on the Geir> VM are, but given that GNU Classpath isn't there yet, isn't it even Geir> plausible that may have something to add? Yeah, the VM interface has to be extended in a few ways for 1.5. Also from time to time the VM interface has to be extended for new VMs, which have different needs. This is one reason that the interface isn't yet stable, even for 1.4. It would be interesting to know why and how it was extended - there's something to learn there. I'm also interested in getting some input from the commercial VM developers. geir Tom -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [arch] How much of java.* and friends does Harmony need to write. Was: VM/Classlibrary interface
On Jun 5, 2005, at 1:45 PM, Sven de Marothy wrote: On Sun, 2005-06-05 at 06:25 -0300, Geir Magnusson Jr. wrote: On Jun 4, 2005, at 12:59 PM, Sven de Marothy wrote: AFAIK there are no other class libraries out there which you'll legally be able to distribute with Harmony. So why create flexibility when there aren't options? Are you kidding? There aren't options *now* (well, that's not really true, is it...), Could you elaborate on that? I don't know of any class library distributable under the Apache license. There are other licenses. Remember, we aren't only concerned about ourselves, but what a downstream user of our stuff will want to do. We tend to try to protect their freedoms as well. (See "Ulcer, Geir's, re J2EE TCK license") but that doesn't meant that options won't come around in the future. I think we're still in the very beginning of "managed runtime environments" and generalization w/o penalty is a Good Thing(tm). Reimplementing java.lang certainly is a penalty. I don't understand - I might have misstated something. Why do you think I want to re-implement java.lang? Any JVM that uses GNU Classpath has to implement java.lang parts, right? All I'm suggesting that we move the stuff that's not standard java.lang as defined in a spec somewhere off to another package name. Again, this is NOT a major issue. *If* or *when* these options become available, *that* will be the time to adress this. It is not such a major task as folks seem to think here to change the VM-classlib interface. Indeed it has been done already for VMs such as JikesRVM. Why not do it now so we don't have to fix it later, since to do J2SE 5 we *are* going to have to modify it... Reimplementing java.lang is more work. See above - I think there is a miscommunication here And maybe we have more to learn in this area from other implementations and newer Java APIs. I don't like "maybe"s. I like specific problems for which I can devise specific solutions. Me too, and I'm hoping someone who has done this will point out some specific problems they needed to solve. Maybe Java 1.6 will require VMs to be able to make breakfast; Should we start designing a VM-toaster interface, just in case? As long as you don't put it in java.lang, I'm all for it... :) But before we go leaping off to 1.6, how about 1.5? Why would you want to have a Free VM which can use non-free libraries? why not? Why restrict that freedom for users? 1) Because Sun hasn't documented their VM interface. We don't care, do we? We can do our own. 2) Because people who have Sun's class library already have Sun's VM. What would they want with Harmony for? Ya never know :) 3) Because I thought the main idea was a complete VM under the Apache license. Not ASL+SCSL. Remember the modularity goal - we want people to be able to take this stuff and plug-n-play with whatever they want. If for whatever reason they wanted to plug in Sun's class library, why would we want to prevent that? geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [arch] How much of java.* and friends does Harmony need to write. Was: VM/Classlibrary interface
> "Geir" == Geir Magnusson <[EMAIL PROTECTED]> writes: >> 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. Geir> Why do you say that? Suppose for J2SE 6, the EG adds the public Geir> class java.lang.VMObject. then what? I already explained how this can't cause a user-visible problem. Maybe you could explain what problem you see arising. As I see it there are a few cases here: * Someone takes code that uses this 1.6 feature and: 1. Compiles it against our library. -> this fails as our VMObject is package-private -> This is no different from using any other unimplemented class 2. Compiles it against 1.6 and runs it against our library -> this fails as our VMObject is package-private -> This is no different from using any other unimplemented class * Someone takes a part of our java.lang, which uses our VMObject, and runs them on a 1.6 VM -> Yes, this fails. But this is not supported either upstream (there is no supported way to override parts of the class library, other than those parts mentioned in the endorsed dirs spec) or by us (since it is a silly thing to do) * Note that user code can't use our VMObject as it is not user-visible Renaming our VMObject in our next release causes no problems for any code. The VMs have to change, but then the VMs have to change with each major release anyway, since ordinarily new features are added which require new VM glue. Tom
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" == Geir Magnusson <[EMAIL PROTECTED]> writes: Dan> I've Dan> never tried that, but Geir is right, I think it can be done if Dan> you try hard enough. >> In the second case, when there is a security manager, then, no, you >> cannot get around the access controls, even with reflection. Geir> Why would I have to "get around" the access controls? I'm the VM. I Geir> can do magic things, right? (I should be able to...) I thought we were talking about malicious user code. Tom
Re: [arch] How much of java.* and friends does Harmony need to write. Was: VM/Classlibrary interface
On Jun 5, 2005, at 1:30 PM, Sven de Marothy wrote: On Sun, 2005-06-05 at 06:21 -0300, Geir Magnusson Jr. wrote: That's not fair. I told you that *I* think that extending java.lang is a *bad idea*. You many not agree, but that's not the same is NIH. That doesn't mean that java.lang.VMObject can't be move to another package, preserving the code in it's entirety. Yes, that's a change for VMs that were [lazily] depending on language semantics to protect those private package extensions, but that's life. Yes, well the impression I was getting was that the discussion here has drifted away from the pros and cons of the Classpath VM interface, and towards ideas of creating your own, or reimplementing java.lang, or even forking Classpath. Fair enough. But I'd really like to rope this back to the pros and cons of the GNU Classpath VM interface. Also, I don't know what the 1.4 and 1.5 Java API requirements on the VM are, but given that GNU Classpath isn't there yet, isn't it even plausible that may have something to add? Yes, 1.5 *will* add new requirements to the VM interface. But the Classpath VM interface isn't some immutable static thing either. All I'm saying here is: how about crossing that bridge when you get there, instead of deciding out of hand that it isn't good enough? Guess which version of J2SE we want to do... geir /Sven -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [arch] How much of java.* and friends does Harmony need to write. Was: VM/Classlibrary interface
> "Geir" == Geir Magnusson <[EMAIL PROTECTED]> writes: Geir> That's not fair. I told you that *I* think that extending java.lang Geir> is a *bad idea*. I still don't understand why you think this. Could you explain what problem might arise? Geir> Also, I don't know what the 1.4 and 1.5 Java API requirements on the Geir> VM are, but given that GNU Classpath isn't there yet, isn't it even Geir> plausible that may have something to add? Yeah, the VM interface has to be extended in a few ways for 1.5. Also from time to time the VM interface has to be extended for new VMs, which have different needs. This is one reason that the interface isn't yet stable, even for 1.4. Tom
Re: [arch] How much of java.* and friends does Harmony need to write. Was: VM/Classlibrary interface
On Jun 5, 2005, at 11:19 AM, Jeroen Frijters 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? geir Regards, Jeroen -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [arch] How much of java.* and friends does Harmony need to write. Was: VM/Classlibrary interface
+1 to that! On Sun, 2005-06-05 at 11:53 -0400, Aaron wrote: > From what I understood from this thread (and of course my understanding > could be wrong), there is some contention over where to "hide" this > Classlib-VM interface and implementation so that user code is least able > to use/abuse it. One suggestion was to use existing package visibility > modifiers and stash the classes in java.lang. Another was to take these > classes and put them in a package other than java.lang to keep java.lang > "pure" (at which point they presumably would have to be "public"). > Another was to use classloader or VM "magic" (or perhaps some more > sophisticated module publishing scheme) to hide the existence of these > classes. > > In my humble opinion, I'm not overly concerned about spending a lot of > effort to "hide" this code from application code, because it is already > demonstrably wrong to use them (from user code), and with the proper > measures one can easily circumvent the security manager and access > hidden fields/methods anyway. > > Frankly, > move-forward-with-Classpath-design-and-change-in-the-future-if-we-need-to > sounds fine to me. > > Aaron >
Re: [arch] How much of java.* and friends does Harmony need to write. Was: VM/Classlibrary interface
On Sun, 2005-06-05 at 06:25 -0300, Geir Magnusson Jr. wrote: > On Jun 4, 2005, at 12:59 PM, Sven de Marothy wrote: > > AFAIK there are > > no other class libraries out there which you'll legally be able to > > distribute with Harmony. So why create flexibility when there aren't > > options? > > > > Are you kidding? There aren't options *now* (well, that's not really > true, is it...), Could you elaborate on that? I don't know of any class library distributable under the Apache license. > but that doesn't meant that options won't come > around in the future. I think we're still in the very beginning of > "managed runtime environments" and generalization w/o penalty is a > Good Thing(tm). Reimplementing java.lang certainly is a penalty. Again, this is NOT a major issue. *If* or *when* these options become available, *that* will be the time to adress this. It is not such a major task as folks seem to think here to change the VM-classlib interface. Indeed it has been done already for VMs such as JikesRVM. Reimplementing java.lang is more work. > And maybe we have more to learn in this area from other > implementations and newer Java APIs. I don't like "maybe"s. I like specific problems for which I can devise specific solutions. Maybe Java 1.6 will require VMs to be able to make breakfast; Should we start designing a VM-toaster interface, just in case? > > Why would you want to have a Free VM which can use non-free libraries? > > > > why not? Why restrict that freedom for users? 1) Because Sun hasn't documented their VM interface. 2) Because people who have Sun's class library already have Sun's VM. What would they want with Harmony for? 3) Because I thought the main idea was a complete VM under the Apache license. Not ASL+SCSL. /Sven
Re: [arch] How much of java.* and friends does Harmony need to write. Was: VM/Classlibrary interface
On Sun, 2005-06-05 at 06:21 -0300, Geir Magnusson Jr. wrote: > That's not fair. I told you that *I* think that extending java.lang > is a *bad idea*. You many not agree, but that's not the same is > NIH. That doesn't mean that java.lang.VMObject can't be move to > another package, preserving the code in it's entirety. Yes, that's a > change for VMs that were [lazily] depending on language semantics to > protect those private package extensions, but that's life. Yes, well the impression I was getting was that the discussion here has drifted away from the pros and cons of the Classpath VM interface, and towards ideas of creating your own, or reimplementing java.lang, or even forking Classpath. > Also, I don't know what the 1.4 and 1.5 Java API requirements on the > VM are, but given that GNU Classpath isn't there yet, isn't it even > plausible that may have something to add? Yes, 1.5 *will* add new requirements to the VM interface. But the Classpath VM interface isn't some immutable static thing either. All I'm saying here is: how about crossing that bridge when you get there, instead of deciding out of hand that it isn't good enough? /Sven
Re: [arch] How much of java.* and friends does Harmony need to write. Was: VM/Classlibrary interface
From what I understood from this thread (and of course my understanding could be wrong), there is some contention over where to "hide" this Classlib-VM interface and implementation so that user code is least able to use/abuse it. One suggestion was to use existing package visibility modifiers and stash the classes in java.lang. Another was to take these classes and put them in a package other than java.lang to keep java.lang "pure" (at which point they presumably would have to be "public"). Another was to use classloader or VM "magic" (or perhaps some more sophisticated module publishing scheme) to hide the existence of these classes. In my humble opinion, I'm not overly concerned about spending a lot of effort to "hide" this code from application code, because it is already demonstrably wrong to use them (from user code), and with the proper measures one can easily circumvent the security manager and access hidden fields/methods anyway. Frankly, move-forward-with-Classpath-design-and-change-in-the-future-if-we-need-to sounds fine to me. Aaron Geir Magnusson Jr. wrote: On Jun 3, 2005, at 5:22 PM, Aaron Hamid wrote: I'm sort of confused by this discussion also. It seems to be about at what granularity we start introducing vm- specific interfaces/implementations. At some point the class library has to interface with the VM. We can do that at a very high level of course, by simply subsuming the entirety of java.lang.* and "avoid" this issue by simply making the java.lang package THE "interface", Well, if GNU Classpath is any indication, you *can't* do that w/o extending java.lang, and therefore you aren't avoiding the issue - you are just burying it in java.lang. but we certainly don't want to rewrite and be responsible for all that code if we can avoid it. The only other alternative (at least that I have read) is some compromise whereby "core" classes rely on an "even-more-core" VM-specific API that will necessarily be different for each VM. Yes - and that would be opaque to the class library implementations... for example, the interface contract would specify what is needed for both sides (VM and class lib) and then it's up to the implementor of the VM to do the right thing wrt the interface w/ the full freedom to do it in any way they want, and similar for the class library implementation. As far as I can tell, there is no such standard interface. So the best we have is to use the ad-hoc interface required by our most likely class library candidate (Classpath), and simultaneously try to ignite interest in standardizing the aforementioned interface across many VMs. Well, that's one way. Another might be to start with the GNU Classpath interface and work out a "standard" interface based on a) further needs (i.e. what does 1.5 require?) b) spec/engineering considerations around java.lang (still to be hashed out) c) the experience of implementors like IBM/Sun/BEA that have done this too I'd be happy to offer a patch to GNU Classpath that supported such a beastie if we could ever come up with it. Obviously this is not going to gain us any leverage with existing proprietary VM s unless they also retrofit their library Well, if we pay attention to what they are doing, we may be able to pull this off. And why wouldn't they want to? They all are reinventing the wheel, a wheel that doesn't provide them with any advantages over their competitors - I can't see why they wouldn't want to standardize on a common approach and codebase :) - the only option in that case is to excise everything but java.lang.* from our bundling of Classpath and try to glue on the remaining portion of, say, Sun's library, or IBM's library; of course then those third party libraries must not cheat and use some of their own unpublished VM-specific interfaces, which they already do. Right - we need to figure out why they do it, what they need, and what we can use for our interface. The point is to stop the madness [vm] [vm-interface] [java.lang.* core (e.g. from Classpath)] [rest of the class library (e.g rest of Classpath, or some third party library)] I would not base any policy on support for developers breaking language rules. Yes you can "cheat" and use reflection to bypass visibility limitations (and I have even had to do this on some occasions to hack around some things), but you leave compatibility and portability at the door when you start doing such things. Where? in the VM? I think the VM can do whatever it wants, as long as the code executing on the VM is secure geir Aaron Tom Tromey wrote: "Dan" == Dan Lydick <[EMAIL PROTECTED]> writes: Dan> That includes the language protection features like Geir's Dan> example of package private, which are an interesting game of Dan> navigating class file structures with reflection, etc. I've Dan> never tri
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
Re: [arch] How much of java.* and friends does Harmony need to write. Was: VM/Classlibrary interface
Geir Magnusson Jr. wrote: Dan> That includes the language protection features like Geir's Dan> example of package private, ... Sorry for not following up on some of my previous remarks on such things. But briefly, here's a trick that works, without any need for language-based module support (which would be much nicer, and will surely come for J2SE7, but isn't strictly needed in this case.) If you have functionality that should only be used across the packages inside the JDK library, and never by users, define it as (non-static) public method of a class (defined outside of java.* packages) that has no public constructors, but does have a factory method. That factory method includes the one bit of pure VM magic: It must only allow creation (or return a singleton) if the calling class is in bootclasspath, otherwise throwing some kind of exception. (The implementation of this check is just a specialization of other kinds of security checks JVMs must do.) Of course all JDK classes using such functionality should never pass around references to such classes. (This is one of the places where language support is needed). You'd like to define as few such classes as possible. It would be nice to standardize these across JVMs, but as I mentioned before, this is hard because JVM implementors want these internal APIs to remain flexible. This is probably the best way to handle all of those aspects of required Java APIs that cannot be described as bytecodes and/or require close Java<->JVM coupling for the sake of efficiency. This scheme also applies to replacements for "native" in those cases where the implementation is not a call to native code, but is instead "intrinsified", causing a JIT to produce custom instructions, as in the JikesRVM "magic" classes. I believe that the lack of such a facility might be one reason for some JVMs not yet supporting java.util.concurrent, which requires something like this to support compareAndSet instructions etc which must be intrinsified for performance to be acceptable. -Doug
Re: [arch] How much of java.* and friends does Harmony need to write. Was: VM/Classlibrary interface
On Jun 3, 2005, at 4:34 PM, Tom Tromey wrote: "Dan" == Dan Lydick <[EMAIL PROTECTED]> writes: Dan> That includes the language protection features like Geir's Dan> example of package private, which are an interesting game of Dan> navigating class file structures with reflection, etc. I've Dan> never tried that, but Geir is right, I think it can be done if Dan> you try hard enough. There are two cases. In the first case there is no security manager. All the code is trusted. In this case, yes, using reflection you can work around access protections. In practice I don't see how this matters, as the code is already trusted... if it does something weird, well, so what? It could also do weird things to your filesystem or anything else. In the second case, when there is a security manager, then, no, you cannot get around the access controls, even with reflection. Why would I have to "get around" the access controls? I'm the VM. I can do magic things, right? (I should be able to...) Dan> The underlying idea here is to make as few changes as possible to Dan> as little of the java.*, especially java.lang.*, or other core Dan> library packages in order to give the Harmony JVM runtime Dan> environment the greatest flexibility for using libraries. Heck, Dan> if it's done right, you might be able to use Sun's or IBM's Dan> java.* library implementation! I see where you're coming from, but I don't see how this furthers the goal of Harmony, which as I understand it is to have a complete, compatible, open J2SE implementation. Yes. I could believe that there are alternative class library implementations that a user might choose to use. With a clean, standard interface, the user should be able to just plug-n-play (modulo compatibility certification requirements) both the VM implementation and the class library implemetation. But then, I'm not really getting this part of the discussion. For instance, why does Harmony need a VM layer different from the one Classpath provides? I don't understand that. I'm not sure we don't, other than the bit about extending java.lang, which I just personally don't really like. I understand why it's done - to just take advantage of the language protection features - but I wonder if there are other ways that are equally as satisfactory for the intended purpose. geir Tom -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [arch] How much of java.* and friends does Harmony need to write. Was: VM/Classlibrary interface
On Jun 3, 2005, at 5:22 PM, Aaron Hamid wrote: I'm sort of confused by this discussion also. It seems to be about at what granularity we start introducing vm- specific interfaces/implementations. At some point the class library has to interface with the VM. We can do that at a very high level of course, by simply subsuming the entirety of java.lang.* and "avoid" this issue by simply making the java.lang package THE "interface", Well, if GNU Classpath is any indication, you *can't* do that w/o extending java.lang, and therefore you aren't avoiding the issue - you are just burying it in java.lang. but we certainly don't want to rewrite and be responsible for all that code if we can avoid it. The only other alternative (at least that I have read) is some compromise whereby "core" classes rely on an "even-more-core" VM-specific API that will necessarily be different for each VM. Yes - and that would be opaque to the class library implementations... for example, the interface contract would specify what is needed for both sides (VM and class lib) and then it's up to the implementor of the VM to do the right thing wrt the interface w/ the full freedom to do it in any way they want, and similar for the class library implementation. As far as I can tell, there is no such standard interface. So the best we have is to use the ad-hoc interface required by our most likely class library candidate (Classpath), and simultaneously try to ignite interest in standardizing the aforementioned interface across many VMs. Well, that's one way. Another might be to start with the GNU Classpath interface and work out a "standard" interface based on a) further needs (i.e. what does 1.5 require?) b) spec/engineering considerations around java.lang (still to be hashed out) c) the experience of implementors like IBM/Sun/BEA that have done this too I'd be happy to offer a patch to GNU Classpath that supported such a beastie if we could ever come up with it. Obviously this is not going to gain us any leverage with existing proprietary VM s unless they also retrofit their library Well, if we pay attention to what they are doing, we may be able to pull this off. And why wouldn't they want to? They all are reinventing the wheel, a wheel that doesn't provide them with any advantages over their competitors - I can't see why they wouldn't want to standardize on a common approach and codebase :) - the only option in that case is to excise everything but java.lang.* from our bundling of Classpath and try to glue on the remaining portion of, say, Sun's library, or IBM's library; of course then those third party libraries must not cheat and use some of their own unpublished VM-specific interfaces, which they already do. Right - we need to figure out why they do it, what they need, and what we can use for our interface. The point is to stop the madness [vm] [vm-interface] [java.lang.* core (e.g. from Classpath)] [rest of the class library (e.g rest of Classpath, or some third party library)] I would not base any policy on support for developers breaking language rules. Yes you can "cheat" and use reflection to bypass visibility limitations (and I have even had to do this on some occasions to hack around some things), but you leave compatibility and portability at the door when you start doing such things. Where? in the VM? I think the VM can do whatever it wants, as long as the code executing on the VM is secure geir Aaron Tom Tromey wrote: "Dan" == Dan Lydick <[EMAIL PROTECTED]> writes: Dan> That includes the language protection features like Geir's Dan> example of package private, which are an interesting game of Dan> navigating class file structures with reflection, etc. I've Dan> never tried that, but Geir is right, I think it can be done if Dan> you try hard enough. There are two cases. In the first case there is no security manager. All the code is trusted. In this case, yes, using reflection you can work around access protections. In practice I don't see how this matters, as the code is already trusted... if it does something weird, well, so what? It could also do weird things to your filesystem or anything else. In the second case, when there is a security manager, then, no, you cannot get around the access controls, even with reflection. Dan> The underlying idea here is to make as few changes as possible to Dan> as little of the java.*, especially java.lang.*, or other core Dan> library packages in order to give the Harmony JVM runtime Dan> environment the greatest flexibility for using libraries. Heck, Dan> if it's done right, you might be able to use Sun's or IBM's Dan> java.* library implementation! I see where you're coming from, but I don't see how this furthers the goal of Harmony, which as I understand it is to have a complete, compatible, open J2SE implementa
Re: [arch] How much of java.* and friends does Harmony need to write. Was: VM/Classlibrary interface
On Jun 4, 2005, at 5:49 PM, Sven de Marothy wrote: On Sat, 2005-06-04 at 21:44 +0200, Santiago Gala wrote: So why create flexibility when there aren't options? to enable the development of other options? without arriving to flexibility syndrome, good interfaces enable competing implementations. If you're going to go off and write your own class library, implementing the VM-specific parts is the least of your problems. Your question has exactly the same mindset that Sun people's comments: "Java is free enough, you have our implementation for free, why do you want another one?" :-) No, it isn't the same mindset at all, because I can give you a specific list of grievances I have with the Sun license. But nobody here seems to be able to give list any specific problems with the GNU Classpath VM interface other than "It's not ours.". That's not fair. I told you that *I* think that extending java.lang is a *bad idea*. You many not agree, but that's not the same is NIH. That doesn't mean that java.lang.VMObject can't be move to another package, preserving the code in it's entirety. Yes, that's a change for VMs that were [lazily] depending on language semantics to protect those private package extensions, but that's life. Also, I don't know what the 1.4 and 1.5 Java API requirements on the VM are, but given that GNU Classpath isn't there yet, isn't it even plausible that may have something to add? geir /Sven -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [arch] How much of java.* and friends does Harmony need to write. Was: VM/Classlibrary interface
On Jun 4, 2005, at 12:59 PM, Sven de Marothy wrote: On Fri, 2005-06-03 at 14:01 -0500, Dan Lydick wrote: Naw, but have you ever looked into how to design and construct a JVM? The fundamental classes like java.lang can typically have implementation-specific requirements, so I am trying to focus on isolating these items from the rest of the library. Right, this is a concern for all. GNU Classpath does this through its VM inteface classes (e.g. VMObject, VMClass, VMClassLoader) I don't see why this isn't good enough. It's certainly seems good enough for the existing VMs which use Classpath. What I mean is implementation policy on how a class library does its work. If the Harmony implementation can keep from being forced to do things somebody else's way, then Harmony may use libraries from vendors such as these without concern of being forced into their JVM or other class library implementation. Basically this means commanding a central core of packages via the bootstrap class loader and letting a library supplier do the rest. Well, again, I can't see what's so bad about Classpath's way of doing this. And I can't see why you would want this freedom. Freedom is good! Software livre! (I *just* couldn't resist...) AFAIK there are no other class libraries out there which you'll legally be able to distribute with Harmony. So why create flexibility when there aren't options? Are you kidding? There aren't options *now* (well, that's not really true, is it...), but that doesn't meant that options won't come around in the future. I think we're still in the very beginning of "managed runtime environments" and generalization w/o penalty is a Good Thing(tm). I mean, you can at least just use the Classpath interface for the time being, and use this strategy once there is some reason to. True, except I really hate extending java.lang. :) And maybe we have more to learn in this area from other implementations and newer Java APIs. The underlying idea here is to make as few changes as possible to as little of the java.*, especially java.lang.*, or other core library packages in order to give the Harmony JVM runtime environment the greatest flexibility for using libraries. Heck, if it's done right, you might be able to use Sun's or IBM's java.* library implementation! Why would you want to have a Free VM which can use non-free libraries? why not? Why restrict that freedom for users? Why would anyone want to do that? You can't distribute them together. I think that depends upon your definition of "free". If you mean "free" as "allowing unhindered action", then you could. If you mean "free" as in "bound by restrictions on the recipient that prevents choice in action", then no, you are right. Remember, we (at the ASF) don't mind that someone might take our software and bundle with proprietary anything. We think that "the market" drives contributions back - it doesn't need to be forced through a license. Really, if you want a real solution here, it's to get Sun to publish a spec for the VM-Classlib interface which we can all use, and this problem will go away by itself. With input from Sun, IBM, BEA, HP, GNU Classpath and everyone else w/ experience here, we have a chance of achieving just that. Sun is a welcome and peer participant in this community, and I think they have a lot to offer, if they'd just start contributing . At least this is my idea. I don't know if this is actually possible because it is heavily dependent on the library implementation from vendor X, Y, and Z. I do like the idea of using/reusing GNU Classpath where it shines and of Harmony either contributing to it or extending it where some improvements are appropriate or writing complete replacements where the implementation is too weak for our use. At least this is what I have gathered from others in the discussion on the list on this subject. The way I've intepreted most of the posts here, is that most were decidedly against forking Classpath. What makes you think that there are Harmony-specific improvements to be made which wouldn't be usable by others? I feel like there's a lot of uncertainty being cast on GNU Classpath here for no reason. A lot of folks seem to have the impression we've got different goals and/or priorities. We do not. I don't believe we do. I personally have engineering concerns about the interface (distinguished from legal/license or philosophical concerns, both of which I left behind when we started this...) I don't want to fork GNU Classpath, and I want to do everything I can to help that community flourish. That said, I do want to keep the door open for others. This is the extent of what I mean. I don't want to re-invent any wheels that don't need it. Ok. Well I still don't understand. Classpath has a VM-classlib interface which is being used by a whole bunch of VMs. If that in
Re: [arch] How much of java.* and friends does Harmony need to write. Was: VM/Classlibrary interface
On Jun 3, 2005, at 6:39 PM, Dalibor Topic wrote: That's a rather weird thing to standardise, being the internals of a binding between the library and the VM, and necessarily something that is in flux, as VMs and class libraries change internally. And they do change quite a bit over time ;) I assume they only change as the Java API changes? I.e. the interface needed for 1.4 could be different than the interface needed for 1.5 etc? (and similarly, if the interface is different, it implies a required change on both sides of it ?) If that's so, then I think it is reasonable to standardize - you'd just have the standard interface for a given Java API version... geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [arch] How much of java.* and friends does Harmony need to write. Was: VM/Classlibrary interface
On Sat, 2005-06-04 at 21:44 +0200, Santiago Gala wrote: > > So why create flexibility when there aren't > > options? > > to enable the development of other options? > without arriving to flexibility syndrome, good interfaces enable > competing implementations. If you're going to go off and write your own class library, implementing the VM-specific parts is the least of your problems. > Your question has exactly the same mindset that Sun people's comments: "Java > is free > enough, you have our implementation for free, why do you want another > one?" :-) No, it isn't the same mindset at all, because I can give you a specific list of grievances I have with the Sun license. But nobody here seems to be able to give list any specific problems with the GNU Classpath VM interface other than "It's not ours.". /Sven
Re: [arch] How much of java.* and friends does Harmony need to write. Was: VM/Classlibrary interface
El sáb, 04-06-2005 a las 17:59 +0200, Sven de Marothy escribió: (...) > So why create flexibility when there aren't > options? to enable the development of other options? without arriving to flexibility syndrome, good interfaces enable competing implementations. Your question has exactly the same mindset that Sun people's comments: "Java is free enough, you have our implementation for free, why do you want another one?" :-) Regards Santiago -- VP and Chair, Apache Portals (http://portals.apache.org) Apache Software Foundation signature.asc Description: This is a digitally signed message part
Re: [arch] How much of java.* and friends does Harmony need to write. Was: VM/Classlibrary interface
On Fri, 2005-06-03 at 14:01 -0500, Dan Lydick wrote: > Naw, but have you ever looked into how to design and > construct a JVM? The fundamental classes like java.lang > can typically have implementation-specific requirements, > so I am trying to focus on isolating these items from > the rest of the library. Right, this is a concern for all. GNU Classpath does this through its VM inteface classes (e.g. VMObject, VMClass, VMClassLoader) I don't see why this isn't good enough. It's certainly seems good enough for the existing VMs which use Classpath. > What I mean is implementation policy on how a class > library does its work. If the Harmony implementation > can keep from being forced to do things somebody else's > way, then Harmony may use libraries from vendors such > as these without concern of being forced into their > JVM or other class library implementation. Basically > this means commanding a central core of packages via > the bootstrap class loader and letting a library > supplier do the rest. Well, again, I can't see what's so bad about Classpath's way of doing this. And I can't see why you would want this freedom. AFAIK there are no other class libraries out there which you'll legally be able to distribute with Harmony. So why create flexibility when there aren't options? I mean, you can at least just use the Classpath interface for the time being, and use this strategy once there is some reason to. > The underlying idea here is to make as few changes > as possible to as little of the java.*, especially > java.lang.*, or other core library packages in order > to give the Harmony JVM runtime environment the > greatest flexibility for using libraries. Heck, > if it's done right, you might be able to use Sun's > or IBM's java.* library implementation! Why would you want to have a Free VM which can use non-free libraries? Why would anyone want to do that? You can't distribute them together. Really, if you want a real solution here, it's to get Sun to publish a spec for the VM-Classlib interface which we can all use, and this problem will go away by itself. > At least this is my idea. I don't know if this is > actually possible because it is heavily dependent > on the library implementation from vendor X, Y, and > Z. I do like the idea of using/reusing GNU Classpath > where it shines and of Harmony either contributing to > it or extending it where some improvements are > appropriate or writing complete replacements where > the implementation is too weak for our use. At least > this is what I have gathered from others in the > discussion on the list on this subject. The way I've intepreted most of the posts here, is that most were decidedly against forking Classpath. What makes you think that there are Harmony-specific improvements to be made which wouldn't be usable by others? I feel like there's a lot of uncertainty being cast on GNU Classpath here for no reason. A lot of folks seem to have the impression we've got different goals and/or priorities. We do not. > This is the extent of what I mean. I don't want to > re-invent any wheels that don't need it. Ok. Well I still don't understand. Classpath has a VM-classlib interface which is being used by a whole bunch of VMs. If that inteface isn't good enough for Harmony (and given that the Harmony JVM does not exist, it seems premature to decide that it isn't), then I'd suggest improving it instead of reimplementing a bunch of stuff. /Sven
Re: [arch] How much of java.* and friends does Harmony need to write. Was: VM/Classlibrary interface
Aaron Hamid cornell.edu> writes: > As > far as I can tell, there is no such standard interface. So the best we have is to use the ad-hoc interface > required by our most likely class library candidate (Classpath), and simultaneously try to ignite > interest in standardizing the aforementioned interface across ma > ny VMs. That's a rather weird thing to standardise, being the internals of a binding between the library and the VM, and necessarily something that is in flux, as VMs and class libraries change internally. And they do change quite a bit over time ;) > Obviously this is not going to gain us any leverage with existing proprietary VM > s unless they also retrofit their library - the only option in that case is to excise everything but > java.lang.* from our bundling of Classpath and try to glue on the remaining portion of, say, Sun's > library, or IBM's library; of course then those third party libraries must not cheat and use some of their > own unpublished VM-specific interfaces, which they already do. Harmony is not a proprietary VM, so that's not really a problem for Harmony. Retrofitting VMs away from different interfaces into GNU Classpath has been done already in projects like JikesRVM, with very good results, and does not seem to pose an unsurmountable challenge to VM developers in general. > I would not base any policy on support for developers breaking language rules. Yes you can "cheat" and use > reflection to bypass visibility limitations (and I have even had to do this on some occasions to hack > around some things), but you leave compatibility and portability at the door when you start doing such things. +1. cheers, dalibor topic
Re: [arch] How much of java.* and friends does Harmony need to write. Was: VM/Classlibrary interface
I'm sort of confused by this discussion also. It seems to be about at what granularity we start introducing vm-specific interfaces/implementations. At some point the class library has to interface with the VM. We can do that at a very high level of course, by simply subsuming the entirety of java.lang.* and "avoid" this issue by simply making the java.lang package THE "interface", but we certainly don't want to rewrite and be responsible for all that code if we can avoid it. The only other alternative (at least that I have read) is some compromise whereby "core" classes rely on an "even-more-core" VM-specific API that will necessarily be different for each VM. As far as I can tell, there is no such standard interface. So the best we have is to use the ad-hoc interface required by our most likely class library candidate (Classpath), and simultaneously try to ignite interest in standardizing the aforementioned interface across many VMs. Obviously this is not going to gain us any leverage with existing proprietary VM s unless they also retrofit their library - the only option in that case is to excise everything but java.lang.* from our bundling of Classpath and try to glue on the remaining portion of, say, Sun's library, or IBM's library; of course then those third party libraries must not cheat and use some of their own unpublished VM-specific interfaces, which they already do. [vm] [vm-interface] [java.lang.* core (e.g. from Classpath)] [rest of the class library (e.g rest of Classpath, or some third party library)] I would not base any policy on support for developers breaking language rules. Yes you can "cheat" and use reflection to bypass visibility limitations (and I have even had to do this on some occasions to hack around some things), but you leave compatibility and portability at the door when you start doing such things. Aaron Tom Tromey wrote: "Dan" == Dan Lydick <[EMAIL PROTECTED]> writes: Dan> That includes the language protection features like Geir's Dan> example of package private, which are an interesting game of Dan> navigating class file structures with reflection, etc. I've Dan> never tried that, but Geir is right, I think it can be done if Dan> you try hard enough. There are two cases. In the first case there is no security manager. All the code is trusted. In this case, yes, using reflection you can work around access protections. In practice I don't see how this matters, as the code is already trusted... if it does something weird, well, so what? It could also do weird things to your filesystem or anything else. In the second case, when there is a security manager, then, no, you cannot get around the access controls, even with reflection. Dan> The underlying idea here is to make as few changes as possible to Dan> as little of the java.*, especially java.lang.*, or other core Dan> library packages in order to give the Harmony JVM runtime Dan> environment the greatest flexibility for using libraries. Heck, Dan> if it's done right, you might be able to use Sun's or IBM's Dan> java.* library implementation! I see where you're coming from, but I don't see how this furthers the goal of Harmony, which as I understand it is to have a complete, compatible, open J2SE implementation. But then, I'm not really getting this part of the discussion. For instance, why does Harmony need a VM layer different from the one Classpath provides? I don't understand that. Tom
Re: [arch] How much of java.* and friends does Harmony need to write. Was: VM/Classlibrary interface
> "Dan" == Dan Lydick <[EMAIL PROTECTED]> writes: Dan> That includes the language protection features like Geir's Dan> example of package private, which are an interesting game of Dan> navigating class file structures with reflection, etc. I've Dan> never tried that, but Geir is right, I think it can be done if Dan> you try hard enough. There are two cases. In the first case there is no security manager. All the code is trusted. In this case, yes, using reflection you can work around access protections. In practice I don't see how this matters, as the code is already trusted... if it does something weird, well, so what? It could also do weird things to your filesystem or anything else. In the second case, when there is a security manager, then, no, you cannot get around the access controls, even with reflection. Dan> The underlying idea here is to make as few changes as possible to Dan> as little of the java.*, especially java.lang.*, or other core Dan> library packages in order to give the Harmony JVM runtime Dan> environment the greatest flexibility for using libraries. Heck, Dan> if it's done right, you might be able to use Sun's or IBM's Dan> java.* library implementation! I see where you're coming from, but I don't see how this furthers the goal of Harmony, which as I understand it is to have a complete, compatible, open J2SE implementation. But then, I'm not really getting this part of the discussion. For instance, why does Harmony need a VM layer different from the one Classpath provides? I don't understand that. Tom
[arch] How much of java.* and friends does Harmony need to write. Was: VM/Classlibrary interface
> [Original Message] > From: Sven de Marothy <[EMAIL PROTECTED]> > To: > Cc: <[EMAIL PROTECTED]> > Date: 6/3/05 11:07:06 AM > Subject: Re: [arch] VM/Classlibrary interface > > Hello, > > > > > > And you can circumvent the language protection (package private...) > > > if you work hard enough too, I believe... > > > > > > Keeping out of "java.lang" seems wise if we can arrange it... > > > By writing _only_ java.lang and java.lang.*, > > we can truly speak of a separate implementation. > > Adding only _parts_ of libraries like GNU ClassPath > > would mean that users would implement Harmony library > > policies, not Sun's, FSF's, or anybody elses. > > Blatant Not-Invented-Hereism. This isn't about "Control over the > implementation", this was about language protection features. > Naw, but have you ever looked into how to design and construct a JVM? The fundamental classes like java.lang can typically have implementation-specific requirements, so I am trying to focus on isolating these items from the rest of the library. That includes the language protection features like Geir's example of package private, which are an interesting game of navigating class file structures with reflection, etc. I've never tried that, but Geir is right, I think it can be done if you try hard enough. > The FSF doesn't have any "library policy". What are you talking about? What I mean is implementation policy on how a class library does its work. If the Harmony implementation can keep from being forced to do things somebody else's way, then Harmony may use libraries from vendors such as these without concern of being forced into their JVM or other class library implementation. Basically this means commanding a central core of packages via the bootstrap class loader and letting a library supplier do the rest. If there are conflicts, then reasonable discussion between the teams should be able to solve them. For example, if a GNU Classpath method depends on a specific feature of java.lang.System where there is a conflict between the Harmony and GNU implementation, good communication between the library teams should be able to solve the matter easily so both the Harmony JVM and JVM's that use GNU Classpath as-is could use the resulting change, no matter which side the change was ultimately on, perhaps even it amounted to changes to both sides. The underlying idea here is to make as few changes as possible to as little of the java.*, especially java.lang.*, or other core library packages in order to give the Harmony JVM runtime environment the greatest flexibility for using libraries. Heck, if it's done right, you might be able to use Sun's or IBM's java.* library implementation! Just have the Harmony class loader control the key packages for JVM integrity and away you go. (Well, that may be a bit much, but you get the idea.) ;-) At least this is my idea. I don't know if this is actually possible because it is heavily dependent on the library implementation from vendor X, Y, and Z. I do like the idea of using/reusing GNU Classpath where it shines and of Harmony either contributing to it or extending it where some improvements are appropriate or writing complete replacements where the implementation is too weak for our use. At least this is what I have gathered from others in the discussion on the list on this subject. > > > By writing _only_ java.lang and java.lang.*, > > we can truly speak of a separate implementation. > > Why do you need a seperate implementation? The Harmony JVM implementation. Study out _any_ JVM implementation and you will find that most crucial classes in java.lang.* require native calls into the JVM itself. Other packages doing native calls are likely to call a shared object library .so/.dll for such operations. But even if a JVM has its native java.lang.* methods call a .so/.dll, those methods are _intimately_ connected to the internal state of the JVM. This is the extent of what I mean. I don't want to re-invent any wheels that don't need it. Dan Lydick
