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

[Paul Benedict]

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 <yozh at mx1.ru> wrote:
> 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
>>> 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.
>