JEP 276 proposed to target JDK 9 discussion (was: JEPs proposed to target JDK 9 (2015/11/5))

Rémi Forax forax at univ-mlv.fr
Mon Nov 9 19:24:52 UTC 2015 

Sorry,
I had a devoxx presentation this morning and i'm not good at multi-tasking.

I will answer to you tomorrow.

Rémi


Le 9 novembre 2015 12:08:38 CET, Attila Szegedi <attila.szegedi at oracle.com> a écrit :
>Hi Rémi, 
>
>would you like to continue this discussion? I’m actively pinging you
>about it as I am hoping to reach a satisfactory conclusion by the
>targeting deadline.
>
>Thanks,
>  Attila.
>
>> On Nov 6, 2015, at 11:58 AM, Attila Szegedi
><attila.szegedi at oracle.com> wrote:
>> 
>>> 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/
>>>> 
>>

More information about the jdk9-dev mailing list