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

John Rose John.Rose at Sun.COM
Fri Oct 9 08:12:00 PDT 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 mlvm-dev mailing list