JSR-292: Why not java.lang.dyn?
yozh at mx1.ru
Sun Oct 4 16:34:31 PDT 2009
On Sun, Oct 4, 2009 at 15:40, Rémi Forax <forax at 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
>> -- Christian
> java.lang => Java the language (not the platform)
> Exotic identifiers and MethodHandle.invoke calling rules in Java (the
> 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.*
More information about the core-libs-dev