What's new in 0.4

Changes in 0.4 compared to 0.3

Backwards incompatible changes

• dyn:callPropWithThis has been renamed to dyn:callMethod to be consistent with both dyn:getMethod and dyn:call.

Major new features

• dyn:getMethod and dyn:call operations. Instead of using dyn:callMethod (formerly dyn:callPropWithThis), you can separate the invocation into dyn:getMethod to retrieve an object that represents a method on an object (not bound to the object used to retrieve it), and then dyn:call to invoke the method (still passing a receiver, since the method is not bound to a receiver). It allows more flexibility in implementations, and also allows calls of first-class function objects that didn't originate from a lookup on an object (global functions, closures, etc.). In order to not confuse various namespaces, dyn:getMethod was introduced in addition to dyn:getProp and dyn:getElem as the preferred way to lookup a method on an object. BeansLinker returns objects that correctly represent POJO methods through dyn:getMethod, and react correctly to dyn:call.
• Composite operations: you can now specify multiple get or set operations at a single call site. I.e. if your language has no syntactic distinction between namespaces for properties and elements, you can use dyn:getProp|getElem:color to tell the linkers that at the call site you wish to retrieve a property named 'color', but if it isn't available, it should try to retrieve a container element named 'color' instead. By varying the order of the operations, you can give them different priorities. It is perfectly legal to compile obj.color into dyn:getProp|getElem|getMethod:color, obj['color'] into dyn:getElem|getProp|getMethod:color, obj.color() into dyn:getMethod|getProp|getElem:color (followed by dyn:call), and so on. The built-in BeansLinker makes sure to create as efficient linkage for composite operations as possible (i.e. if it knows that the object will always have a property with the requested name, it'll just ignore the rest of the operations.)

Minor new features

• org.dynalang.dynalink.support.NameCodec class for standardized name mangling/demangling as per John Rose's "Symbolic Freedom in the VM" article. Demangling works automatically as long as you use CallSiteDescriptorFactory.tokenizeName(), mangling needs to be done from your language compiler's bytecode emitter using NameCodec.encode().
• Guards.isNotNull
• Lookup.findGetter and Lookup.findOwnStatic
• CallSiteDescriptorFactory now has a method for tokenizing composite operations.
• DynamicLinker.getLinkerServices() for a wholesale access to the linker's underlying services.

Improvements and fixes

• CallSiteDescriptor now has constants for standard indexing of name tokens, i.e. SCHEME for 0, OPERATION for 1, and NAME_OPERAND for 2.
• We now allow unqualified names in explicit signature selectors, i.e. dyn:getMethod:read(InputStream) instead of dyn:getMethod:read(java.io.InputStream). The resolver is smart enough to match them to actual signature types; you only need fully qualified names if you'd have a conflict in the unqualified name between multiple overloaded methods in that argument position, which is extremely unlikely.
• LinkerServices.asType() now does a conversion of return types too.