On Sat, 2006-04-22 at 08:30 +0200, Jeroen Frijters wrote: > Andrew John Hughes wrote: > > On Fri, 2006-04-21 at 15:23 +0200, Jeroen Frijters wrote: > > > Since we can now support annotations on the trunk I'd like to merge > > > Class/VMClass with the versions from the generics branch > > > (modulo any 1.5 language feature, of course). > > > > I thought we agreed that these should be exactly the same, > > and that new language features shouldn't be part of the runtime > > interface? > > Yes, but these were already in the generics version of VMClass, so I > just left them in. I definitely agree that it would be better to take > them out (and also to move getEnumConstants entirely to Class, I don't > see why anyone would want to specialize it). >
The new patch certainly looks better in this regard,with only one change to VMClass. I originally thought EnumConstants might be optimizable at the VM level as fields are marked as enumeration constants; this is why I included it in the VM layer. > > > If your VM already supports the generics branch, no changes > > > should be needed. If you don't yet support it, you need to > > > implement VMClass.getDeclaredAnnotations, if you use a custom > > > version of VMClass, you also need to copy VMClass.getEnumConstants. > > > > Is implementing getDeclaredAnnotations in full really the best way to > > go? I'm not saying it isn't (you may have studied this in more detail > > than I), but I was under the impression that some of it may be > > simplified by a gnu.java.lang.annotation.Annotation with native parts. > > There's probably room for more Java code and IKVM has a bunch more that > I'd be happy to check into Classpath, but I haven't thought deeply about > it outside of the IKVM context. > Ah, so IKVM already has some of this implemented? Great. I guess it depends on other VM implementors and how much control they want over this. I think the implementation of the signature parser was a good idea, and the annotation support should have a similar division. > I also have annotation serialization support (compatible with the JDK), > but that requires a class in the sun.* package (which I implemented by > looking at the serialized form of an annotation) and I'm not sure if > everyone would agree to that. > Sounds ugly; maybe they will make this part of the API for 1.6? > Regards, > Jeroen > 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 { ... }
signature.asc
Description: This is a digitally signed message part
