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

Ben Evans benjamin.john.evans at googlemail.com
Mon Oct 5 18:01:57 UTC 2009

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.


On Mon, Oct 5, 2009 at 1:27 AM, Paul Benedict <pbenedict at 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 <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.
> >
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20091005/7632eb8f/attachment.html>

More information about the core-libs-dev mailing list