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
