JSR-292: Why not java.lang.dyn?
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
> 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.
More information about the core-libs-dev