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