A bug on the constructor for OtpNode which caused NullPointerException, is fixed.
Own Id: OTP-3721
A new class, AbstractConnection, has been added to deal with most of the aspects of the Erlang communication protocol, and which can be subclassed in order to provide different levels of support to the application as necessary. OtpConnection is now a subclass to AbstractConnection.
OtpCookedConnection is a new subclass to AbstractConnection, which together with OtpNode provides an intuitive mailbox-based communication mechanism. By using this interface, applications are no longer required to manage connections explicitly, since the OtpNode now opens and manages connections to remote nodes as needed. Outgoing messages are sent through mailboxes and automatically dispatched through the correct connections to the destination node, while incoming messages are queued in the destination mailbox. This allows parts of an application to communicate with several peers simultaneously without the need to sort and dispatch incoming messages. Additionally, mailboxes can be linked with Erlang processes or with each other, in much the same manner that Erlang processes can be linked together.
The node class hierarchy has changed. The top class is now AbstractNode, and direct subclasses are OtpPeer and OtpLocalNode, of which the latter is extended by OtpNode and OtpSelf. This does not change the functionality of any of the existing classes or methods that take node arguments, however it was necessary in order to group OtpNode and OtpSelf and to provide some common methods for them.
OtpServer is now deprecated. Its functionality has been added to OtpSelf.
An open OtpConnection no longer requires service on a regular basis in order to keep the remote Erlang node from disconnecting. OtpConnection now extends java.lang.Thread so it can keep the connection open and respond to ticks when needed, without intervention from the application. Incoming messages are automatically received and queued for subsequent retrieval through one of the receive methods.
Tracing of inter-node communication can now be set on a per-connection basis. The system property OtpConnection. Trace is still used as before, but now sets only the initial trace level for new connections. Once a connection has been created, its current trace level can be set or retrieved through new methods setTraceLevel and getTraceLevel.
Constructors for OtpErlangAtom and OtpErlangTuple previously declared that OtpErlangDataException would be thrown for certain types of input. These constructors now throw java.lang.IllegalArgumentException instead, which is a runtime exception and is therefore not declared explicitly, nor is it necessary for the caller to explicitly catch it. The rules for creating atoms and tuples have not changed however.
Some of the constructors for OtpErlangPid, OtpErlangPort and OtpErlangRef are now deprecated. The various OtpNode classes provide factory methods instead.
OtpErlangObject and all subclasses representing Erlang data types now implement java.io.Serializable and java.lang.Cloneable.
A user's guide is now available.
Own Id: OTP-3424
A bug in the MD5 handshaking code, that could cause the connection to fail when the Java node was run in a 7-bit character encoding environment, has now been fixed.
Own Id: OTP-3512
A bug in OtpErlangList, which caused message corruption when empty list where encoded, is fixed.
Own Id: OTP-3564
Modifications for using along with new IC types.
Some modifications were done on classes OtpInputStream amd OtpOutputStream in order to work with the new types added on IC.
Own Id: OTP-3331
Machine-depended character encoding problems fixed.
The character encoding (LC_CTYPE) need no longer be defined to an eight bit character set for jinterface connections to work.
Own Id: OTP-3512
New application.