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

java singleton – why nested class implementation important

http://en.wikipedia.org/wiki/Initialization_on_demand_holder_idiom is the recommended solution. My friend Rohan pointed out why this solution is sometimes necessary.

Say you can’t eagerly init the static field because it must wait for some service object.

Say you also don’t want to incur the static synchronization every time. Though un-contended lock acquisition is cheap, it’s never free.

Spring self-quiz 2

Q1: spring bean scopes? prototype/singleton/request/session…
A1: http://static.springsource.org/spring/docs/2.5.x/reference/beans.html#beans-factory-scopes

Q3(common): why use spring?
%A3: JMS, MVC, tx, Spring security, AOP,  hibernate,

Q4: how do u use spring tx management
A4: xml or annotation

Q: what's so special about DI, if we can easily use method/constructor injection?

Q: auto wiring and @Inject …?:

Q: singleton bean?