JSR-292: Why not java.lang.dyn? (original) (raw)

John Rose John.Rose at Sun.COM
Fri Oct 9 15:12:00 UTC 2009

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

More information about the core-libs-dev mailing list