Differences between GitHub and OpenJDK Dynalink

Differences between GitHub and OpenJDK Dynalink

Dynalink currently has two code bases: one here on GitHub, under the package name org.dynalang.dynalink.* and one in OpenJDK, under the jdk.internal.dynalink.* package name.

The GitHub version was historically the first, then it was snapshotted into OpenJDK, and then I continued to work on it primarily there, as part of working on the OpenJDK's embedded JavaScript engine, Nashorn. During this time, Dynalink has retained its language-neutrality, as I was always careful to separate the design concerns and not let anything JavaScript-specific seep in, but rather whenever a requirement came up I took the time to figure out how to formulate a solution for it in a general, language-independent manner.

I am making an effort to periodically sync the two versions, and to this end the 0.8 release of Dynalink here on GitHub matches the state in OpenJDK as of January 1, 2015. The two versions are nearly identical, but there are still some differences. I will explain the differences and the reasons for the differences.

Access and privileges

First of all, the Dynalink in OpenJDK is a so-called restricted package as it lives in the jdk.internal.* package namespace. This means that code running under a security manager would need to have accessClassInPackage.jdk.internal.dynalink runtime permission to access it. This can make using it somewhat less feasible. Also, a common wisdom is that you shouldn't rely on presence of any private APIs in the JDK. The GitHub Dynalink is a library that can be accessed by any code without restrictions.

Dynalink in OpenJDK is also deployed in either ext classpath (in Java 8), or in boot classpath (in Java 9). As such, it runs with unrestricted privileges. It's not much of an issue ordinarily, but the GitHub variant might need a configured security policy if you want to use it under a security manager, to unreflect on Java methods and fields etc.

CLA woes

There are some smaller functional differences between the two. These are stemming from licensing issues. I can only incorporate into the GitHub Dynalink code that I develop myself, or code for which contributors have signed a Contributor License Agreement (CLA). Some of my colleagues at Oracle have added functionality to Dynalink in OpenJDK, but have not signed a CLA for me; hence, those modifications are unavailable in GitHub Dynalink as I can not directly port them. Of course, if a 3rd party implements them in a clean-room fashion and sends me a patch (and signs a CLA), I can incorporate such independently developed bits.

For reasons on not having a signed CLA from other Oracle contributors, the following functionality isn't present in GitHub Dynalink:

• BeansLinker.isDynamicMethod() API.
• Objects implementing java.util.List don't have a property length that aliases their size() method (it's unclear whether this is even desirable, but it's in the OpenJDK version).
• OpenJDK Dynalink doesn't expose static methods and fields on subclasses (e.g. java.util.GregorianCalendar doesn't expose a field named AUGUST, you need to reference java.util.Calendar for it. GitHub Dynalink does this, even though it would be desirable for it too to not do it.
• In OpenJDK Dynalink, you can ask for an explicit overload of a constructor by specifying a signature to BeansLinker.getConstructorMethod(Class clazz, String signature) and the method objects thus returned react as you'd expect to dyn:new invocations. GitHub Dynalink doesn't have this functionality, even though it would be highly desirable. While I could easily write it, I'm unfortunately tainted with the knowledge of the OpenJDK implementation.

Other differences

• In GitHub Dynalink, GuardedInvocation.getSwitchPoints() never returns null, it returns an empty array when the invocation has no switch points. I might make that change soon in OpenJDK too.