JSR-292: Why not java.lang.dyn? (original) (raw)

Paul Benedict pbenedict at apache.org
Mon Oct 5 00:27:58 UTC 2009

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.

More information about the core-libs-dev mailing list