JSR-292: Why not java.lang.dyn?

[Stepan Koltsov]

John, how about multi-language java.lang.Class or java.lang.reflect.Field?

S.


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
>> 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
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>