Dynalink 0.5 - now with usage from Java!
104 views
Skip to first unread message
Attila Szegedi
Feb 21, 2013, 2:15:17 PM2/21/13
to jvm-la...@googlegroups.com
Hey folks,
I pushed out Dynalink 0.5 earlier today - as always, available from <http://szegedi.github.com/dynalink/>.
Aside from technical content, I have also significantly revised the User Guide at <https://github.com/szegedi/dynalink/wiki/User-Guide-0.5>. It is now clearly separated into two halves: first for users, second for language implementers.
Probably the most significant change is that the guide now explains how to use Dynalink as a library from pure Java (or any other static language), without any code generation whatsoever! This hopefully significantly lowers the barrier to exploration of this library.
The usage from Java is not actually new; the technique works with any previous version of Dynalink too, it's just not something that was obvious to me earlier. It's actually a good way to integrate Dynalink into environments that don't even generate bytecode; i.e. interpreters, expression evaluators, and such. The technique is actually ridiculously simple: you just explicitly invoke the bootstrap method from your Java code, it returns you a Dynalink-managed CallSite; you ask the call site for its dynamicInvoker(), and then proceed happily using it via invoke[Exact](). There is no step 4.
In other news, I changed the license too - it's now dual-licensed to be Apache 2.0 and 3-clause BSD, with the user choosing which one does he want to apply. The reason for this is explained in <https://github.com/szegedi/dynalink/wiki/Licensing-FAQ>, but the short of it is that I did it in order to be able to license it to OpenJDK.
Which brings us to another piece of information; Dynalink has a bit of a foothold in OpenJDK now; there's a package-renamed version (org.dynalang.dynalink -> jdk.internal.dynalink) of it in the Nashorn OpenJDK repository now, in much the same manner as how ASM is embedded. This in itself doesn't have lot of significance, as this is meant for internal JDK usage; it's package renamed, and it is in a restricted package, to boot - you can still use it outside of a SecurityManager-protected JVM, or even in it if you grant the required accessClassesInPackage privilege to your code, but of course that's not the goal.
As for longer term future, one of these days I'll find time and energy to start drafting a JSR, but don't hold your breath as I have my hands full with Nashorn for some months still. For the time being, if you want to use it, your best choice is still the standalone version on GitHub - I'm primarily working in the GitHub repo on it anyway, and will just snapshot it into OpenJDK as needed.
Attila.
I pushed out Dynalink 0.5 earlier today - as always, available from <http://szegedi.github.com/dynalink/>.
Aside from technical content, I have also significantly revised the User Guide at <https://github.com/szegedi/dynalink/wiki/User-Guide-0.5>. It is now clearly separated into two halves: first for users, second for language implementers.
Probably the most significant change is that the guide now explains how to use Dynalink as a library from pure Java (or any other static language), without any code generation whatsoever! This hopefully significantly lowers the barrier to exploration of this library.
The usage from Java is not actually new; the technique works with any previous version of Dynalink too, it's just not something that was obvious to me earlier. It's actually a good way to integrate Dynalink into environments that don't even generate bytecode; i.e. interpreters, expression evaluators, and such. The technique is actually ridiculously simple: you just explicitly invoke the bootstrap method from your Java code, it returns you a Dynalink-managed CallSite; you ask the call site for its dynamicInvoker(), and then proceed happily using it via invoke[Exact](). There is no step 4.
In other news, I changed the license too - it's now dual-licensed to be Apache 2.0 and 3-clause BSD, with the user choosing which one does he want to apply. The reason for this is explained in <https://github.com/szegedi/dynalink/wiki/Licensing-FAQ>, but the short of it is that I did it in order to be able to license it to OpenJDK.
Which brings us to another piece of information; Dynalink has a bit of a foothold in OpenJDK now; there's a package-renamed version (org.dynalang.dynalink -> jdk.internal.dynalink) of it in the Nashorn OpenJDK repository now, in much the same manner as how ASM is embedded. This in itself doesn't have lot of significance, as this is meant for internal JDK usage; it's package renamed, and it is in a restricted package, to boot - you can still use it outside of a SecurityManager-protected JVM, or even in it if you grant the required accessClassesInPackage privilege to your code, but of course that's not the goal.
As for longer term future, one of these days I'll find time and energy to start drafting a JSR, but don't hold your breath as I have my hands full with Nashorn for some months still. For the time being, if you want to use it, your best choice is still the standalone version on GitHub - I'm primarily working in the GitHub repo on it anyway, and will just snapshot it into OpenJDK as needed.
Attila.
Reply all
Reply to author
Forward
0 new messages