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.

-- 
You received this message because you are subscribed to the Google Groups "JVM 
Languages" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jvm-languages+unsubscr...@googlegroups.com.
To post to this group, send email to jvm-languages@googlegroups.com.
Visit this group at http://groups.google.com/group/jvm-languages?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to