[ 
https://issues.apache.org/jira/browse/OPENNLP-776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15412320#comment-15412320
 ] 

Tristan Nixon commented on OPENNLP-776:
---------------------------------------

There are some slight differences depending on whether you want to implement 
Serializable or Externalizable, but the basic pattern is the same. When the 
Java serialization system de-serializes an object, it first looks for a no-arg 
constructor to create an instance of that object, then it relies on setters or 
the methods

private void readObject(java.io.ObjectInputStream in) (for Serializable)

or

public void readExternal( ObjectInput in ) (for Externalizable)

to handle reconstituting the object's state from the stream. To put it another 
way, you can't call readExternal (or readObject) until you have an instance to 
call it on.

Even if I'm to create sub-classes of model classes that are themselves 
externalizable, my sub-class must provide a no-arg constructor, which begs the 
question of what parent-class constructor will it call.

> Model Objects should be Serializable
> ------------------------------------
>
>                 Key: OPENNLP-776
>                 URL: https://issues.apache.org/jira/browse/OPENNLP-776
>             Project: OpenNLP
>          Issue Type: Improvement
>    Affects Versions: tools-1.5.3
>            Reporter: Tristan Nixon
>            Priority: Minor
>              Labels: features, patch
>             Fix For: 1.6.1
>
>         Attachments: externalizable.patch
>
>
> Marking model objects (ParserModel, SentenceModel, etc.) as Serializable can 
> enable a number of features offered by other Java frameworks (my own use case 
> is described below). You've already got a good mechanism for 
> (de-)serialization, but it cannot be leveraged by other frameworks without 
> implementing the Serializable interface. I'm attaching a patch to BaseModel 
> that implements the methods in the java.io.Externalizable interface as 
> wrappers to the existing (de-)serialization methods. This simple change can 
> open up a number of useful opportunities for integrating OpenNLP with other 
> frameworks.
> My use case is that I am incorporating OpenNLP into a Spark application. This 
> requires that components of the system be distributed between the driver and 
> worker nodes within the cluster. In order to do this, Spark uses Java 
> serialization API to transmit objects between nodes. This is far more 
> efficient than instantiating models on each node independently.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to