----- Mail original ----- > De: "Attila Szegedi" <szege...@gmail.com> > À: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "Nashorn-dev" <nashorn-dev@openjdk.java.net> > Envoyé: Samedi 2 Janvier 2016 16:54:05 > Objet: Re: Review request for JDK-8133299: Nashorn Java adapters should not > early bind to functions > > I remember sometime back in summer of 2012 I had a hallway conversation with > John Rose in Santa Clara about this. At that time I was implementing the > first version of adapter support in Nashorn, and I was enthusiastically > reporting to him how I hope that I’ll be able to create a generic adapter > implementation for dynamic languages. Then it turned out that there are some > aspects of this that are Nashorn-specific, and unfortunately I haven’t since > figured out a way how to refactor it into a generic + runtime specific > portion… (Especially with Nashorn’s need for managing a thread-local Global > object.) For now, I’m happy to have done this step as it simplifies > Nashorn's adapter implementation a lot. The simplification might actually be > a significant first step towards a generalization.
yes > > I agree it would be beneficial to have a generally reusable solution. There > are some non-obvious tidbits that surface once you embark on this task, such > as (crucial for Nashorn as it’s part of the JDK) maintaining separate > adapter classes for every ProtectionDomain they might be created in etc. One great thing about having the adapter code in the JDK is that you may not care at all about protection domain. After all, one step down, adapters in the JVM that are used when you just from the interpreter to to c1 or c2 (stubs) are invisible. If adapters rely on invokedynamic, you have 3 parts, the client code that call the adapter, the adapter that does an invokedynamic and the target code specified as a method handle. From the security point of view, it's better if the adapter part is transparent because you can reuse them more and you do not have to care about privilege escalation. > > Attila. Rémi > > > On Jan 2, 2016, at 4:45 PM, Remi Forax <fo...@univ-mlv.fr> wrote: > > > > Hi Attila, > > no fully related to that issue but i think that the adapter code should be > > separated from Nashorn and integrated directly into the JDK as a better > > proxy implementation (compared to java.lang.reflect.Proxy), evey dynamic > > language runtimes need this kind of proxies. > > > > here is my attempt to do something like this [1] > > > > Happy new year, > > Rémi > > [1] https://github.com/forax/proxy2 > > > > ----- Mail original ----- > >> De: "Attila Szegedi" <szege...@gmail.com> > >> À: "Nashorn-dev" <nashorn-dev@openjdk.java.net> > >> Envoyé: Samedi 2 Janvier 2016 16:01:56 > >> Objet: Review request for JDK-8133299: Nashorn Java adapters should not > >> early bind to functions > >> > >> Please review JDK-8133299 "Nashorn Java adapters should not early bind to > >> functions" at <http://cr.openjdk.java.net/~attila/8133299/webrev.jdk9> for > >> <https://bugs.openjdk.java.net/browse/JDK-8133299> > >> > >> See implementation notes in > >> <https://bugs.openjdk.java.net/browse/JDK-8133299?focusedCommentId=13883269&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13883269> > >> > >> Also note that this changeset is based on current tip (rev 1584, > >> [da397aea8ada]) and is as such independent of the change sets for > >> JDK-8144917 and JDK-8144919 that are still pending review. > >> > >> Thanks, > >> Attila. > >
