Thanks, Ben; well said. Putting a multi-language JVM feature under java.lang would be the wrong signal. OTOH, if we ever do a type "Dynamic" in the Java language (a la C#) that would belong in java.lang. But we are not, at present. (Despite an earlier blog proposal of mine!) JVM changes are a big enough job for now. -- John
On Oct 5, 2009, at 11:01 AM, Ben Evans wrote: > I think this is somewhat of a red herring. > > After all, there are many classes which live in java.lang which are > fundamental to the operation of the platform, and which any language > which lived on top of the VM would have an intimate relationship > with (eg Object, Class, String, etc). > > If we are moving to a point of view in which the Java language is > not central to the platform, but rather first among equals (by > removing all direct dependencies of the JVM spec on the JLS, etc), > then in an ideal world these classes would live in java.core or > java.platform or something. That would of course break the whole > world, so is clearly not going to happen. The best we can do is not > make the situation worse for future amendments, by not placing > additional classes which are not specific to the Java language into > java.lang. > > I am puzzled, however, by your assertion that dynamic invocation is > closer to the language than 'not', ie closer to the language than > the platform. > > Non-Java languages have been making use (and shipping support for, > in some cases) of dynamic invocation for quite a few months now. The > experience of those language's implementors has been integral to the > development process of this feature. The Java language has been > playing catch-up throughout. It's fantastic that it's in the JLS now > and I look forward to seeing some first-class implementations of it, > but this feature really wasn't crafted with Java as the pre-eminent > use case. > > Ben _______________________________________________ mlvm-dev mailing list [email protected] http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
