I think it's unfortunate that the JSR was started with a solution (invokedynamic) rather than a problem (implementing dynalangs on the JVM is hard). This is not reflection on John who came to the JSR long after it was created.
I have a lot of sympathy for the position that you outline in your blog post but I would like to wait for the EDR to be published before coming to a settled view on the matter. The devil is in the details and I have not seem all the details yet.
> I have a lot of sympathy for the position that you outline in your > blog post but I would like to wait for the EDR to be published before > coming to a settled view on the matter. The devil is in the details > and I have not seem all the details yet.
I am totally agree. At the end of the day what I say is that API understanded by JVM is better then a new bytecode because it is backword compatible :)
Alex Tkachman wrote: >> I have a lot of sympathy for the position that you outline in your >> blog post but I would like to wait for the EDR to be published before >> coming to a settled view on the matter. The devil is in the details >> and I have not seem all the details yet.
> I am totally agree. At the end of the day what I say is that API > understanded by JVM is better then a new bytecode because it is > backword compatible :)
Current EDR does not introduce a new bytecode, and prefers to have a "special" interface for invokeinterface as a marker for dynamic invocation. The EDR should be public next week.
And although this particular part of the approach would not be back-portable, I'm planning to work with you and John Rose and others to create a backport of the anonymous classloading and method handle APIs. John Rose has also spoken frequently about the importance of solving these issues on older JVMs as well.
Wanting to capture some memories from JavaOne before they fade, and hoping to provide some perspective on where the JVM and its languages might be going, I have written out some impressions on these things. Enjoy:
It will be great to discuss the EDR on this list when it comes out from the JCP. I am hoping this will be the primary public venue for such conversations.
One caveat: The EDR is an early draft, and lacks javadocs. The Java APIs are merely sketched.
I will start committing code to the mlvm repo. in coming weeks, and then we can make javadocs and talk about the detailed shape of the APIs.
> I think it's unfortunate that the JSR was started with a solution > (invokedynamic) rather than a problem (implementing dynalangs on the > JVM is hard). This is not reflection on John who came to the JSR long > after it was created.
See Gilad's old blog entry at http://blogs.sun.com/gbracha/entry/invokedynamic and other blogs from around that time. "Last winter we had a meeting with various people who work on such languages - things like Groovy, Perl, Python/Jython. Our conclusion was that the most practicable thing was to support dynamically typed method invocation at the byte code level." There are some other notes about that meeting floating around on the web somewhere that were published at the time. If this list had existed then, we'd have more information about what was discussed back then and why they came up with the invokedynamic idea.
I'd add the our knowledge of implementing dynamic language on the JVM has evolved a lot since 3 years ago. The reasons back then may differ with the knowledge we have now.
On Tue, May 13, 2008 at 7:53 PM, Patrick Wright <pdoubl...@gmail.com> wrote:
>> I think it's unfortunate that the JSR was started with a solution >> (invokedynamic) rather than a problem (implementing dynalangs on the >> JVM is hard). This is not reflection on John who came to the JSR long >> after it was created.
> See Gilad's old blog entry at > http://blogs.sun.com/gbracha/entry/invokedynamic and other blogs from > around that time. "Last winter we had a meeting with various people > who work on such languages - things like Groovy, Perl, Python/Jython. > Our conclusion was that the most practicable thing was to support > dynamically typed method invocation at the byte code level." There are > some other notes about that meeting floating around on the web > somewhere that were published at the time. If this list had existed > then, we'd have more information about what was discussed back then > and why they came up with the invokedynamic idea.
> > I think it's unfortunate that the JSR was started with a solution > > (invokedynamic) rather than a problem (implementing dynalangs on the > > JVM is hard). This is not reflection on John who came to the JSR long > > after it was created.
> See Gilad's old blog entry at > http://blogs.sun.com/gbracha/entry/invokedynamic and other blogs from > around that time. "Last winter we had a meeting with various people > who work on such languages - things like Groovy, Perl, Python/Jython. > Our conclusion was that the most practicable thing was to support > dynamically typed method invocation at the byte code level." There are > some other notes about that meeting floating around on the web > somewhere that were published at the time. If this list had existed > then, we'd have more information about what was discussed back then > and why they came up with the invokedynamic idea.
Yes I remember the meeting very well (I wasn't at the meeting but I was already working on Groovy when it happened). At the time we expected it to be the beginning of an engagement with Sun on the problems of getting dynamic languages to run efficiently on the JVM. The invokedynamic proposal came as something of a surprise to us it was, and remains, difficult to see how we might have made use of it. Bracha was not very forthcoming with details and moved on to other things before he was able to enter into a dialogue.
This mailing list has made a huge difference and it's been very valuable to be able to exchange information with others who share the problem. Charlie has done a great job here.
I understand from postings on this and the Groovy list that the current proposal does not include a new bytecode so perhaps my original opinion of the utility of invokedynamic was not completely wrong.
We must, of course, wait for the publication of the proposal before coming to an informed position this.
> > I think it's unfortunate that the JSR was started with a solution > > (invokedynamic) rather than a problem (implementing dynalangs on the > > JVM is hard). This is not reflection on John who came to the JSR long > > after it was created.
> See Gilad's old blog entry at > http://blogs.sun.com/gbracha/entry/invokedynamic and other blogs from > around that time. "Last winter we had a meeting with various people > who work on such languages - things like Groovy, Perl, Python/Jython. > Our conclusion was that the most practicable thing was to support > dynamically typed method invocation at the byte code level." There are > some other notes about that meeting floating around on the web > somewhere that were published at the time. If this list had existed > then, we'd have more information about what was discussed back then > and why they came up with the invokedynamic idea.
