RMI could send more than simple VO

[[java the good parts]], written by a RMI authority, is a thin book with a concise but in-depth chapter on RMI. One of the things pointed out was —

In a distributed system like RPC or RMI, sometimes the object sent over network are more than monolithic POJO “value objects” with trivial methods. For example, you could send a special FXDeal object having specialized virtual reval() method. Interface would declare a BaseDeal data type for it. Obviously, receiving end should NOT “slice” this FXDeal object down to BaseDeal and lose the specialized reval().

Not sure how CORBA handles it, but RMI was designed to support it. Basically the serialization stream of the object includes the location to download the FXDeal class bytecode.

## java 7 features – my picks

(Java 8 and java 5 are major changes compared to java 7)

#1) [advanced] fork and join
#2) [advanced] File change notifications
#3) new filesystem io API
#4) try( FileOutputStream fos = newFileOutputStream(“movies.txt”); DataOutputStream dos = newDataOutputStream(fos) ) {
dos.writeUTF(“Java 7 Block Buster”);
} catch(IOException e) {
// log the exception
}

# catch(ExceptionOne | ExceptionTwo | ExceptionThree e) {
# diamond operator. List> my = new List<> ();

[[practical api design]] java

Written by the founder and initial architect of NetBeans, this book has a java root. Freely available in pdf, I find this ebook rather detailed, not a lot of high-level (vague) concepts like most design/architecture books including the classics. It seems to deal with some real world coding and design decisions. I would say these are not life-and-death decisions but still everyday decisions. (In contrast those other books address decisions I don’t encounter or care at all — seem to belong to another level.) Therefore this book is closer to my life as a developer.

There’s a chapter against “extreme” (unhealthy) advice. Unconventional critique:
** an api must be beautiful
** an api must be correct
** an api must be simple
** an api must have good performance
** an api must be 100% compatible
** an api must be symmetrical

chapter on creating a threadsafe API, to be used by clueless and untrained programmers.

chapter on supervising the development of an API

Section on overcoming the fear of committing to a stable API

Section on Factory being better than constructor

Section on making everything final