JEP 276 proposed to target JDK 9 discussion

Thu Nov 12 09:44:10 UTC 2015

While javac itself does not generate invokedynamic (apart from lambdas), 
it is possible for other statically typed languages to generate 
invokedynamic -- even with exact signature and use dynalink library in 
the generated bootstrap method. Dynalink offers Java beans linking for 
such languages. Language specific extension linkers written by lang. 
implementers can extend the same or add more linkers for other purposes.

Apart from enabling dynamically typed languages,  dynalink is used in 
other use cases too. For example, Nashorn itself uses callsite flags to 
allow entry/exit tracing, profiling (turned on globally by command line 
option or per function "user directives") - depending on tracing or 
profiling flags a different method is linked (which eventually calls the 
actual target after trace print/bookkeeping).

     jjs -tcs file.js

to enable tracing globally.

So, dynalink is not just about dynamically typed languages - it is 
dynamic linking library - which can be used for other purposes as well.

-Sundar

On 11/12/2015 2:49 PM, Rémi Forax wrote:
> Java is a typechecked langage.
> As you said you 'can' use this proposed API offers a gate to access to artifacts of a dynamically typed languages but it's messy.
>
> In C#, you can use the dynamic keyword to interropt with dynamic languages but you loose type checking and also box everything. That's not the only solution, you can also use interfaces to type values that goes back and forth between Java and your languages.
>
>  From the point of view of javac the methods of these interfaces are compiled using invokedynamic which link to the runtime of the dynamically typed languages associated with the interfaces.
>
> As i said, or should, this JEP is great, it solves the problem of interropt between dynamically typed languages but it doesn't tackle the problem of interropt with statically typed languages, Java the language or others, that runs on the Java Platform.
>
> I don't want to put this JEP on hold but just says that this JEP only solve a part of the interropt problem.
>
> regards,
> Rémi
>
>
>
>
>
>
>
> Le 6 novembre 2015 11:58:20 CET, Attila Szegedi <attila.szegedi at oracle.com> a écrit :
>>> On Nov 6, 2015, at 12:47 AM, Remi Forax <forax at univ-mlv.fr> wrote:
>>>
>>> Let me be the devil advocate.
>> Thank you. Let me address these concerns.
>>
>>> One problem i see with JEP 276 is that it makes Java the Language a
>> second class citizen because unlike with the other dynamic languages,
>> javac will not emit the invokedyanmic calls.
>>> Obviously, given the fact that Java is the elephant in the room, the
>> picture is inversed, all dynamically typed language that run on the JVM
>> will still be second class citizens.
>>
>> Only in the sense that programs written in Java language can’t call
>> into a dynamic language with any special Java syntax; emphasis on
>> special syntax. You can use Dynalink from Java by creating CallSite
>> objects explicitly, letting them be linked by Dynalink and invoking
>> their dynamicInvoker. Nashorn does it when its Java code needs to call
>> back into JavaScript, see the InvokeByName class[1] or
>> Bootstrap.createDynamicInvoker[2]. It’s certainly not less convenient
>> than directly programming against any language runtime’s own Java-side
>> API, and gives you interop with all Dynalink-using languages, not just
>> one. (It actually allows you dynamic POJO linking too from within
>> Java.)
>>
>> The whole notion of “second class citizen language” is highly
>> debatable. This JEP significantly improves the support of non-Java and
>> specifically languages with dynamic types on the JVM. They will not be
>> worse off than before, and I argue that they will, in fact, be much
>> better off (see immediately below).
>>
>>> It seems this JEP stops in the middle of the river, making this JEP,
>> in my opinion, not very useful.
>>
>> There’s a pretty large sandbank in the river that’s worth getting to
>> first. It provides a way for a dynamic language to
>> 1. conveniently link to its own object model, while at the same time
>> 2. link to Java object model with no additional work, and
>> 3. link to object models of other languages with no additional work,
>> and
>> 4. let other languages link its own object models with no additional
>> work.
>>
>> For lots of language implementers points 1 and 2, the benefit of
>> handling their own object model *and Java* at the same call site is a
>> tremendous value proposition. Points 3 and 4, cross-language interop is
>> usually less prominently on their minds, but if it comes for free… As a
>> matter of fact, we were contacted on Nashorn mailing list in the past
>> by people saying they wanted to integrate their language with Nashorn
>> but couldn’t since Dynalink was in jdk.internal.* package, so at least
>> for some that’s important too.
>>
>>> Dynamic languages will interoperate with the others but Java will not
>> interoperate with them.
>>
>> That’s the only part that’s on the other side of your metaphorical
>> river. Except, see above, you can actually do it, just not with a
>> convenient syntax. Adding a “dynamic” type to Java would be a pretty
>> big language feature, with a lot of ripple effects (it affects the type
>> system, after all) and I believe it is better to do it as a separate
>> step, not in the least as it’s a JCP level change. It’s not a done deal
>> that it will actually happen. (It would be a perfectly valid JCP
>> consensus outcome that members would rather not have a dynamic type in
>> Java.)
>>
>> I actually wrote a document some years ago with an initial speculation
>> on what would Java with dynamic type look like on top of Dynalink[3].
>> There’s several moving parts involved there, up to and including how do
>> you associate a javac-compiled .class with a DynamicLinker instance.
>>
>>> So for a dynamic language runtime, encoding callsites using the
>> proposed scheme is a constraint with not so much benefit
>>
>> Purely as a technical sidenote, I dispensed with a mandatory encoding
>> scheme recently[4].
>>
>>> JRuby can already calls Nashorn because both can use Java as a
>> bridge.
>>
>> How can they use Java as a bridge? If you’re referring to writing code
>> in Nashorn to the JRuby object interfaces or vice versa, that’s hardly
>> more convenient than using Dynalink from Java with explicit CallSites.
>> (I’d argue the latter is actually more convenient.)
>>
>>> Moreover, if you compare how dynamically typed languages that run on
>> the JVM are supported by Java compared to statically typed languages,
>> Fortran or C++ by example, they will soon have better support from Java
>> because they will be able to use the C bridge defined by project
>> Panama.
>>
>> Progress being made in supporting natively compiled language runtimes
>> is hardly an argument against progress being made in supporting
>> JVM-hosted language runtimes.
>>
>>> So instead of defining how dynamically typed languages can interop
>> with each others, i think it's a better to define how Java can leverage
>> invokedynamic to call any dynamically typed languages in a typesafe
>> way.
>>
>> This strikes me as a false dichotomy as JEP 276 is not just about
>> dynamic languages cross-interop, as I enumerated above. (Also, what do
>> you mean by “typesafe way” in relation to dynamically typed languages?)
>>
>>> All dynamically typed languages will be free to reuse the same
>> mechanism to interroperate with each others, the JEP 276 should be
>> defined on top of that mechanism.
>>
>> I see your point. You argue that we should first have a
>> Java-to-dynamicLanguages solution in place and then express JEP 276 on
>> top of it. However, for this to work, you’d need to define the target
>> API of the dynamic languages that Java could be linking against, and
>> I’m saying it’d look very much like what JEP 276 defines.
>>
>> More importantly, it hinges on Java actually getting a dynamic type,
>> which is a very big “if”.
>>
>> On the other hand I say that JEP 276 provides a
>> dynamicLanguages-to-anything solution (exactly the opposite direction),
>> and that Java language can be made to be on the “anything” end *if*
>> dynamic type is introduced into Java.
>>
>> Either way, we'd end up with a bridge over the river, it’s just a
>> question what direction we start building it from. The part I propose
>> is already built internally and would be genuinely useful without being
>> dependent on Java also getting a dynamic type.
>>
>> Attila.
>>
>>> cheers,
>>> Rémi
>> [1]
>> http://hg.openjdk.java.net/jdk9/dev/nashorn/file/34b77a618e98/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/InvokeByName.java
>> <http://hg.openjdk.java.net/jdk9/dev/nashorn/file/34b77a618e98/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/InvokeByName.java>
>> [2]
>> http://hg.openjdk.java.net/jdk9/dev/nashorn/file/34b77a618e98/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/Bootstrap.java#l262
>> <http://hg.openjdk.java.net/jdk9/dev/nashorn/file/34b77a618e98/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/Bootstrap.java#l262>
>> [3]
>> https://github.com/szegedi/dynalink/wiki/What-if-Java-had-dynamic-type%3F
>> <https://github.com/szegedi/dynalink/wiki/What-if-Java-had-dynamic-type?>
>> [4] In the preliminary spec API I published for review two weeks ago[5]
>> as announced in an e-mail to core-libs[6], you can see that I dispensed
>> with a mandatory encoding scheme in favor of operations expressed as
>> objects (see Operation interface). Both the producer of the encoding
>> (.class emitter) and its consumer (the bootstrap method) are presumed
>> to be in the same language runtime, so it’s not necessary for a
>> specification to prescribe how do they pass information among
>> themselves. The bootstrap method is responsible to decode information
> >from its parameters into operation objects which then need to be
>> understood by all linkers. We switched to that in the internal code
>> version already, see the JIRA issue[7]).
>> [5] http://cr.openjdk.java.net/~attila/jep276/javadoc.20151022/
>> <http://cr.openjdk.java.net/~attila/jep276/javadoc.20151022/>
>> [6]
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-October/036052.html
>> <http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-October/036052.html>
>> [7] https://bugs.openjdk.java.net/browse/JDK-8139931
>> <https://bugs.openjdk.java.net/browse/JDK-8139931>
>>
>>> ----- Mail original -----
>>>> De: "mark reinhold" <mark.reinhold at oracle.com>
>>>> À: jdk9-dev at openjdk.java.net
>>>> Envoyé: Jeudi 5 Novembre 2015 23:56:43
>>>> Objet: JEPs proposed to target JDK 9  (2015/11/5)
>>>>
>>>> The following JEPs have been placed into the "Proposed to Target"
>>>> state by their owners after discussion and review:
>>>>
>>>>   259: Stack-Walking API
>>>>        http://openjdk.java.net/jeps/259
>>>>
>>>>   264: Platform Logging API and Service
>>>>        http://openjdk.java.net/jeps/264
>>>>
>>>>   269: Convenience Factory Methods for Collections
>>>>        http://openjdk.java.net/jeps/269
>>>>
>>>>   272: Platform-Specific Desktop Features
>>>>        http://openjdk.java.net/jeps/272
>>>>
>>>>   276: Dynamic Linking of Language-Defined Object Models
>>>>        http://openjdk.java.net/jeps/276
>>>>
>>>> Feedback on these proposals is more than welcome, as are reasoned
>>>> objections.  If no such objections are raised by 23:00 UTC next
>>>> Thursday, 12 November, or if they're raised and then satisfactorily
>>>> answered, then per the JEP 2.0 process proposal [1] I'll target
>> these
>>>> JEPs to JDK 9.
>>>>
>>>> (This information is also available on the JDK 9 Project Page [2]).
>>>>
>>>> - Mark
>>>>
>>>>
>>>> [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html
>>>> [2] http://openjdk.java.net/projects/jdk9/
>>>>