On Sun, 2006-03-05 at 11:36 -0700, Tom Tromey wrote: > I've been looking into 1.5 support a bit lately, and I think there are > a number of changes we will need to make to the VM layer. Some of > them look quite invasive :-(, but I thought I'd start with a > relatively simple one. > > 1.5 adds some new methods to the reflection classes, e.g., > isVarArgs(). These simply test a bit in the modifiers of the member, > but these new modifier bits (AIUI) should not be returned by > getModifiers(). > > Right now getModifiers() is native in our VM layer, e.g. from Method: > > public native int getModifiers(); > > I propose changing the name of the native method to > getModifiersInternal(), making it private, and having it return all > the bits that are given in the class file. > > Then we would rewrite getModifiers in Java. It would call > getModifiersInternal and strip the appropriate bits. > > Then new things such as isVarArgs or isSynthetic are also trivial to > write in terms of getModifiersInternal. > > This is a breaking change so would require some buy-in from VM > developers. Note however that as it is local to Method (and Field and > Constructor), and since VMs typically copy these in their entirety, it > probably would not result in actual breakage per se. Instead it would > require an update of the code in the VMs in order to make the new > feature available. > > Any comments? > > Sounds good to me; probably best to get it in just after the imminent release so that VM developers have the most time possible to get used to it. > FWIW I've got a patch to make this change, which implements the new > reflection predicates and also the new toGenericString methods. > > > We'll actually need more additions to the VM layer in the reflection > code, for annotations. I think I will hold off on this for a while, > as I think it will require code that is only available on the generics > branch, and we wanted to keep the VM interface the same on both the > trunk and the branch. > > Tom > There are already a few changes on the branch, and I'm not sure whether this is in sync with HEAD. We need to go through the branch and check things like this. Are there actually any changes that require signatures in the VM layer that won't compile on HEAD? If not, then presumably they can be added to HEAD as well. My grasp of 1.5 is that the runtime changes are pretty minimal and we can probably have 1.5 runtime support a long time before compile time support comes from the generic branch, but correct me if I'm wrong about this. If the methods aren't implemented by a VM, then the difference will be a breakage at run-time rather than compile-time, AFAIK, and it leaves the onus on individual VM developers, so each can update to 1.5 as they wish. Thanks for looking at this again, 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/9443c882/attachment.pgp
