Get the mbox for the default node.

The results of this function are memoized as the intent is to obtain a singleton instance for the default node. (The Erlang JInterface docs recommend that only one node be run per JVM instance.)

Note that since this memozation makes no assumptions about the passed node, unexpected results may ensure if the JVM default node isn’t what is passed. Whatever node gets passed will be associated with the default mbox that this function sets.

A wrapper for the mbox-creation method on nodes. See clojang.jinterface.otp.nodes/node.

Provides a simple mechanism for exchanging messages with Erlang processes or other instances of this class.

Each mailbox is associated with a unique pid that contains information necessary for delivery of messages. When sending messages to named processes or mailboxes, the sender pid is made available to the recipient of the message. When sending messages to other mailboxes, the recipient can only respond if the sender includes the pid as part of the message contents. The sender can determine its own pid by calling (self sndr)

Mailboxes can be named, either at creation or later. Messages can be sent to named mailboxes and named Erlang processes without knowing the pid that identifies the mailbox. This is neccessary in order to set up initial communication between parts of an application. Each mailbox can have at most one name.

Since this class was intended for communication with Erlang, all of the send methods take OtpErlangObject arguments. However this class can also be used to transmit arbitrary Java objects (as long as they implement one of java.io.Serializable or java.io.Externalizable) by encapsulating the object in a OtpErlangBinary.

Messages to remote nodes are externalized for transmission, and as a result the recipient receives a copy of the original Java object. To ensure consistent behaviour when messages are sent between local mailboxes, such messages are cloned before delivery.

Additionally, mailboxes can be linked in much the same way as Erlang processes. If a link is active when a mailbox is closed, any linked Erlang processes or OtpMboxes will be sent an exit signal. As well, exit signals will be (eventually) sent if a mailbox goes out of scope and its finalize() method called. However due to the nature of finalization (i.e. Java makes no guarantees about when finalize() will be called) it is recommended that you always explicitly close mailboxes if you are using links *in*nstead of relying on finalization to notify other parties in a timely manner.

When retrieving messages from a mailbox that has received an exit signal, an OtpErlangExit exception will be raised. Note that the exception is queued in the mailbox along with other messages, and will not be raised until it reaches the head of the queue and is about to be retrieved.

Provides a carrier for Erlang messages.

Instances of this class are created to package header and payload information in received Erlang messages so that the recipient can obtain both parts with a single call to receiveMsg().

The header information that is available is as follows:

• a tag indicating the type of message
• the intended recipient of the message, either as a pid or as a String, but never both.
• (sometimes) the sender of the message. Due to some eccentric characteristics of the Erlang distribution protocol, not all messages have information about the sending process. In particular, only messages whose tag is regSendTag contain sender information.

Message are sent using the Erlang external format (see separate documentation). When a message is received and delivered to the recipient mailbox, the body of the message is still in this external representation until get-msg is called, at which point the message is decoded. A copy of the decoded message is stored in the OtpMsg so that subsequent calls to get-msg do not require that the message be decoded a second time.