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. >
