On Sun, 2006-03-05 at 16:06 -0700, Tom Tromey wrote: > >>>>> "Andrew" == Andrew John Hughes <gnu_andrew@xxxxxxxxxxxxxx> writes: > > Andrew> There are already a few changes on the branch, and I'm not > Andrew> sure whether this is in sync with HEAD. We need to go through > Andrew> the branch and check things like this. > > I thought Jeroen went through this a while back and either changed the > branch or ported changes from the branch back to the trunk, to keep > them in sync. Or am I misremembering this? > Yes, he did some IIRC; but I have a feeling there is still the odd thing or two. Certainly doc/vmintegration needs to be updated; the primary reason I changed this in the first place was to highlight the 1.5 stuff but I still haven't done it. The transformer API is one case; that might even be directly portable to HEAD. > Andrew> Are there actually any > Andrew> changes that require signatures in the VM layer that won't > Andrew> compile on HEAD? If not, then presumably they can be added to > Andrew> HEAD as well. > > I think not right now, but I didn't look into every detail. But > e.g. we can't add the annotation support to the trunk as it requires > new things, like annotation interfaces. > Yeah, it pretty much comes down to adding AnnotatedElement in: http://java.sun.com/j2se/1.5.0/docs/api/java/lang/reflect/AnnotatedElement.html and then its implementation in Class, AccessibleObject, etc. > I made a list of all the 1.5 VM layer changes I could think of: > > - Thread changes > Most can be back ported easily, I think. One API requires an enum > I have like 1 method or something in my generics tree. Yeah, I think the problem here is the new Thread state enum. > - nanoTime > Can be back ported > I have a really dumb implementation in my generics tree > - inherited channel > Can be back ported > - reflection code (not annotations) > Can be back ported; I've got the patch Yes, these are pretty much okay, and probably the most beneficial part. I think this is what Jereon was looking at. nanoTime and the inherited channel are really 1.5 feature additions rather than being related to the language changes. > - concurrency > A pretty tricky API. Derived from Doug Lea's implementation, so at > least for now we don't control it. > This is going to give Jeroen fits I think :-) > I've got this stubbed in my tree, waiting for some time to pretty > it up and submit. This can't be back-ported, too much 1.5 stuff in > there (probably much of it *could* be, by removing generics and > hoping that covariant returns don't bite... but let's not). I think that has to stay on generics, as none of it could be placed on HEAD (whereas the others are extensions of existing features, the concurrency stuff doesn't exist there). > - annotations > Requires 1.5 features Problem is AccessibleObject's signatures AFAICS; perhaps we can abstract these away from the VM interface, which I think is what Jereon did with some of the others, IIRC. The generics bit needs to have these signatures, but the VM level can just pass up the metadata from the class file, and we then handle it centrally in the Classpath Java code. Only problem is that makes it a little less flexible for the VM developers. > - I think there are some new AWT features requiring peers, > but I didn't look in depth > Yes, MouseInfo and PointerInfo IIRC. Pretty much a HEAD 1.5 addition I think. I tend to concentrate just on the reflection level stuff for the new language features when thinking about the generics changes; most stuff outside that is really stuff for HEAD. > All of these are going to break compatibility in our VM layer. It > would be nice if we could agree on some general protocol for making > changes here, since we're going to do it a few times... we definitely > don't want to do this all at once, as the patch would be enormous. > Strongly agree. Do VM developers have a preferred way they'd like to see this handled? Ideally, with regard to the 1.5 code, as little as possible should be mandatory as it isn't required for pre-1.5 bytecode, but this can't always be avoided. I don't think we should rush this through in terms of actual code patches. But I think we should start publically discussing this to the level of suggested new method signatures/classes/etc. so a consensus can be reached. If it helps, we could add the appropriate Classpath-level code in, with appropriate FIXMEs (e.g. /* FIXME VM CHANGE */ ) in place of the VM calls. Once these are in, we then have an exact idea of all the changes required and they can be properly discussed. It seems you have this to a large degree already, so maybe just posting the VM part for discussion would be appropriate. Definately seems to be a case of a major disruption that needs as much input from others as possible, and the lists are probably the best way to do this. > Tom Cheers, -- Andrew :-) Please avoid sending me Microsoft Office (e.g. Word, PowerPoint) attachments. See http://www.fsf.org/philosophy/no-word-attachments.html If you use Microsoft Office, support movement towards the end of vendor lock-in: http://opendocumentfellowship.org/petition/ "Value your freedom, or you will lose it, teaches history. `Don't bother us with politics' respond those who don't want to learn." -- Richard Stallman Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html public class gcj extends Freedom implements Java { ... } -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://developer.classpath.org/pipermail/classpath/attachments/20060305/32792f63/attachment-0001.pgp
