JSR-292: Why not java.lang.dyn?
yozh at mx1.ru
Sat Oct 10 02:36:22 UTC 2009
John, how about multi-language java.lang.Class or java.lang.reflect.Field?
On Fri, Oct 9, 2009 at 19:12, John Rose <John.Rose at sun.com> wrote:
> 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.
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
More information about the core-libs-dev