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 On Mon, Oct 5, 2009 at 1:27 AM, Paul Benedict <pbened...@apache.org> wrote: > Stepan, > > That is a very good observation. I wonder what others have to say > about it? As you pointed out, there are other java.lang.* sub-packages > that have no impact on the Java language. > > I am in agreement that java.dyn is closer to the language than not -- > hence I think java.lang.dyn is natural. > > Paul > > On Sun, Oct 4, 2009 at 6:34 PM, Stepan Koltsov <y...@mx1.ru> wrote: > > On Sun, Oct 4, 2009 at 15:40, Rémi Forax <fo...@univ-mlv.fr> wrote: > >> Le 04/10/2009 11:39, Christian Thalinger a écrit : > >>> On Sat, 2009-10-03 at 23:43 -0500, Paul Benedict wrote: > >>> > >>>> I've always found it a bit perplexing that java.lang was never chosen > >>>> for the parent package of the Dynamic API. Why is that? Dynamic types > >>>> are now "part of the language" as proven by spec itself and exotic > >>>> identifiers. Will this be reconsidered? > >>>> > >>> [I'm forwarding this question to mlvm-dev.] > >>> > >>> I think John Rose or another member of the EG should have an answer to > >>> this. > >>> > >>> -- Christian > >>> > >>> > >> > >> java.lang => Java the language (not the platform) > >> > >> Exotic identifiers and MethodHandle.invoke calling rules in Java (the > >> language) > >> are not part of the JSR292 spec. > >> JSR 292 => method handle API for any (dynamic?) language > >> > >> So why java.dyn API should be a 'part' of java.lang ? > > > > java.lang.reflect also deals with JVM objects, not Java language. But > > it still java.lang.reflect, not java.reflect. > > > > java.lang.Class is also closer to JVM then to the java language. > > > > java.lang has lots of JVM stuff. > > > > I also think, that package name should be java.lang.dyc, although it > > is not absolutely correct. > > > > "java" root package has lots of libraries (java.io, java.sql), and > > these libraries should not be mixed with JVM interface. > > > > If you think java.lang.dyn is inappropriate, then java.vm.dyn is > > better, because next JVM interface (what ever it will be) can be > > placed into java.vm package too and won't be lost among all java.* > > stuff. > > > > S. > > > _______________________________________________ > mlvm-dev mailing list > mlvm-...@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >
