Skip to main content

"java.dyn" is dead, long live to ... (What?)

Posted by forax on January 8, 2011 at 7:13 AM PST

When the JSR 292 was started, it was clear that the users of this new API was dynamic(ally typed) languages so the package was naturally named java.dyn

But it's is clear now that Java (the language) is also a potential user of this API, by example, the actual plan to implement Java lambda uses several features introduced by JSR 292 (see section 3 of JSR 335).
So, the name java.dyn is less accurate.

It's time to rename this package before freezing the API.

Brian Goetz and Mark Reinhold propose to rename it to, mh stands for MethodHandle which is a central class in the design of the API.
I'm not a big fan of that name, I mean it's Ok but I find it too reductive. In the same time, I was not able to find a better name :)

So this is a community call, what is you favorite package name for JSR 292 API knowing that it has to be a subpackage of "java" and that short names (two/three letters) are better ?

There is no garantee that your favorite name will be chosen but I will be a strong suppporter of the name chosen by the majority.

So Java community please help us to find a good name, I wait your comments.


Edit 01/13/10: as several of you noticed there is no real need for a 3 letters package name and the actual content of java.dyn can be seen as a better invocation mechanism. So java.dyn will be renamed to java.dyn.invoke, java.lang.dyn was abandonned because we decide instead of having a giant package that future developements of JSR 292 will be done into several packages (by example java.lang.coroutine if we decide to add coroutine (I will love that)).

I would like to thank all of you to share a part of your brain with us. It was really helpful.


Related Topics >>


"mh", I find that highly

"mh", I find that highly disturbing and unituitive, too.
I convinced the Spec Lead of JSR-331, (Constraint Programming) which just passed the Public Review at a very early stage, to prefer "javax.constraints" over "javax.cp".
"MH" is about as useful as "CP"
"ava.dyn" must be a typo, either it's "java.dyn" or (more likely) "javax.dyn".

"java.dyn" is dead, long live

I do agree on the following:
1- (*.mh) is not a good option: as pointed out, mh is a description of a solution instead of the problem area.
2- java.lang.dyn is a perfect suggestion. I was going to suggest java.lang.type.dyn to describe java dynamically typed languages. so, that in case we would to support static languages (some day), we can have java.lang.type.static, for example.

"java.dyn" is dead, long live

I strongly dislike "mh" - it is meaningless (unlike "io" which is a generally known term)
I believe that "dyn" is perfecly acceptable if this needs to be short, as it implies dyamic, so is clear enough. Since this is about dynamically accessing parts of the code, and adding new parts of code, the term seems appropriate. Viewed from a Java perspective, it should be "java.lang.reflect.dyn", but shorter versions would just about be OK.
I think "handle"/"mh"/"rt"/"vt"/"protocol"/"lambda" variations are poor or limiting.
"dispatch" or "invoke" are OK, but I prefer "dyn".

"java.dyn" is dead, long live

I'm in favor of ".dyn" ending (although something better can come out) but i don't think java.lang.reflect.dyn would be a proper choice because this API has no direct relation to the reflection API. Besides, one could argue it is as akin to the lang.ref package (because the "handle" thing looks like a kind of specialized reference) as it is akin to the lang.reflect package (because of the possibility of method invocation allowed by both).
So i would rather favor the plain simple java.lang.dyn. Short, concise and understandable by everyone.

"java.dyn" is dead, long live

Yes, the analogy to java.lang.ref is a good one. That package is also linked to low-level aspects of Java. So java.lang.dyn makes most sense to me.

"java.dyn" is dead, long live

This is a helpful exercise. Here's a rough tabulation of suggestions so far:

  • 6 java.lang.dispatch chris_e_brown* smanux* nutter* ljnelson taylor_tails spullara
  • 5 NOT-MH pjmlp smanux chris_e_brown ljnelson paolodt
  • 3 java.lang.rt forax nutter* jrose
  • 3 java.lang.handle damonhd* smanux* pjmlp
  • 3 EXPLICIT-WORD pjmlp smanux chris_e_brown
  • 2 java.lang.invoke[r] smanux* nutter*
  • 2 java.lang.dyn paolodt* JSR-292-EG
  • 1 java.reflect.dyn magnum
  • 1 java.lang.vt damonhd*
  • 1 java.lang.t damonhd*
  • 1 java.lang.reflect.dyn arittner
  • 1 java.lang.protocol nutter*
  • 1 java.lang.lambda damonhd*
  • 1 java.lang.dyntype damonhd*
  • 1 java.lang.dynamic chris_e_brown*
  • 1 java.dyn paolodt*

Starred names are people who made multiple suggestions. I arbitrarily tweaked some suggestions, e.g., merging "invoke" with "invoker" and changing "lamba". Some offline suggestions from Charlie Nutter are included.
This morning the JSR 292 EG met. We realized we still liked "dyn", even after moving under "java.lang". The reason we like the more unspecific "dyn" is that it refers to a problem area, not a specific solution (method handles). Most of what we're doing in JDK7 is related to method handles, but the EG hopes to do other interesting JVM extensions in the future. Some, such as interface injection, are likely to fit neatly alongside method handles.
Lots of people here like "java.lang.dispatch". To me that term is uncomfortably off-center, since it describes only a minor aspect of function pointers (method handles). "invoke" would be a more on-center verb. For a noun, "method" would be on-center at present.

"java.dyn" is dead, long live

I'm not sure Interface Injection says 'dyn' to me either. In so far as what package I'd look in.

Silly question but, why can't MethodHandle just go in java.lang.reflect? Since this is the package I'd have guessed.

(Other than it adds another split package in jigsaw ;-) )

"java.dyn" is dead, long live

I would also vote for something other than mh. It just looks plain awful as an API.
Plus we are not in the 70's with C compilers that had 10 characters limit per identiifer.
I would rather see something like java.lang.handle or some of the previous suggestions that use a proper word.

Why not java.reflect.dyn ?

Why not java.reflect.dyn ?

Why not java.reflect.dyn ?

magnum wrote:

Why not java.reflect.dyn ?

You mean java.lang.reflect.dyn (reflect is a subpackage of lang)? I think dyn this is a good subpackage for reflect. (not exaclty, but the IMHO the best place).
br, josh

Why not java.reflect.dyn ?

Yes, sorry. I typed too fast ;)

Why not java.reflect.dyn ? doesn't look great, the other packages under java.lang have more explicit names.
java.lang.handle or java.lang.dispatch are good alternatives. What about java.lang.invoker ?

The current name under lang,

The current name under lang, "mh", arose as a consensus between Brian, Mark, and me. Looking for a short name (like "ref", not "management"), we rejected "meth" for its pharmaceutical connotations, and agreed that "mh" (like "io" or "rmi") would work well.
We know "mh" is not perfect. And I realize that it is incomprehensible to anyone not already thinking about method handles. On the other hand, method handles are a major new element of the JVM, so it would be reasonable to recognize them in the package naming.
The term "rt" is a possibility, but it has the opposite problem of "mh" (which is a little over-specific). Everything under java.* is a "runtime"; think "" or "java.lang.stuff".
As Remi notes, the existing name java.dyn was chosen because the design center for 292 is dynamic languages, and it was thought (at the time) that dynamic languages will have no overlap with Java itself. That has changed, since method handles will play an important part in Java as well as other languages, especially as support for Lambda. (I expect they will also mitigate the class file explosion problems in Scala. Scala is a static language.)
Since the deletion of InvokeDynamic and Linkage, there are at present no classes linked directly to invokedynamic besides InvokeDynamicBootstrapError. Everything at the API level (except ClassValue) is oriented toward method handles.
Meanwhile, other core JVM-linked APIs are named as sub-packages of java.lang (reflect, ref, management, instrument, annotation). Mark wants to put our work in the same namespace.

The current name under lang,

"mh" is an awful name. As an API user, I prefer things like "sql" or "zip", or even "concurrent", but "nio" (vs "io") is a lousy name, and I'm not sure many people can guess (without looking up) what java.rmi.dgc does...
I've nothing against java.lang.dispatch or java.lang.dynamic (as in "behavior" not "language"). It's not a big burden to import the few extra character, especially with an IDE.

The current name under lang,

mh is awful. Short package names that are short simply to be short are awful. Dispatch is good. java.lang.dispatch makes sense to a reasonably informed programmer.
(Side tangent: What is this (comparatively) sudden obsession on the part of the Java community--armed with some of the best IDEs money can buy--with saving keystrokes? The early selling point of Java was once (upon a time) that it was clear and readable at the expense of being terse and incomprehensible. This is a tradeoff I'll take any day of the week.)

The current name under lang,

Nothing sudden about it. It's a long-standing habit from *NIX heritage if nothing else: "rm", "cp", "mv", "cd", /etc (!)

"java.dyn" is dead, long live


java.lang.dispatch looks like

java.lang.dispatch looks like a good contender to me.

In my opinion

In my opinion is incomprensible.
Much better java.dyn or java.lang.dyn .
My two cents.
Cheers, Paolo

"java.dyn" is dead, long live

Some for you to dump in /dev/null:




java.lang.t   (type variables)
java.lang.vt   (variable type)