I was actually doing this until yesterday for compiling the dynalink framework, and while the 1.6 javac did give me a warning and suggested I need a newer version of the compiler, it didn't stop with an error. When those classes were then loaded in an OpenJDK JVM, they nicely passed all tests. So funnily enough, I was able to work on it with the 1.6 compiler :-)
Of course, in my code, I never have actual invokedynamic call sites in the bytecode, it's all about direct MethodHandle manipulation. Attila. On Feb 10, 2011, at 3:03 PM, John Rose wrote: > On Feb 10, 2011, at 3:46 AM, Rémi Forax wrote: > >> The main problem is that when you will run it, with a 1.7 VM because >> MethodHandle is only available with a 1.7 VM, >> the VM will throw a WrongMethodTypeException because as you said the 292 >> magic will be ignored. >> >> I think it's better for the users to don't compile instead of compiling >> something which is inherently wrong. > > Try compiling mh.invokeExact using a 1.6 compiler against a 1.7 rt.jar. You > should get a compile-time error, since the class file version numbers are > wrong. The 1.6 compiler should refuse to load MethodHandle.class from rt.jar. > > If you compile against a non-standard rt.jar, you might get the error you are > observing, but that error won't affect 1.7 users. If it affects backport > users, I suggest taking steps to put the java.dyn package jar in a special > place where the 1.6 compiler is not going to see it, by default. > > There are lots of variations on this theme of version mismatches. But the > class file version number saves us in a lot of them. > > -- John > _______________________________________________ > mlvm-dev mailing list > [email protected] > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev _______________________________________________ mlvm-dev mailing list [email protected] http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
