Cloneable, Object.clone(), Pen.Clone() #java

A few learning points.

The Object.clone() implementation is not that important, because I should always override it in my class like Pen, but here are some observations about this Object.clone():

  • shallow copy, not deep copy, not very useful.
  • this protected method is mostly meant to be invoked by a subclass:
    • If your variable points to some Pen object that’s no Clonable, and you call it from either the same package or a subclass, then you hit CloneNoSupported.
    • if your Pen class implements Clonable, then it should override the clone() method
    • [1] The only way the default Object.clone() gets picked by compiler is when a Cat class implements Clonable but doesn’t override clone(), and you call it from either the same package or a subclass

Clonable is a special marker interface. It could trigger the CloneNotSupported exception, but if you override clone() then this exception may not hit. It’s an obscure detail.

  • I think you can override clone() without implementing Clonable, but this is tricky and non-standard.
  • You could also implement Clonable without overriding clone() .. see [1]
Advertisements

java access levels: protected^package-private..

https://docs.oracle.com/javase/tutorial/java/javaOO/accesscontrol.html (java8) shows two nice tables:

  • There’s no more “private protected
  • default access level is better known as “package-private” — strictly more restrictive than Protected . (Protected is more like Public). The 2nd table shows that
    • a “package-private” member of Alpha is accessible by Beta (same package) only, whereas
    • a “protected” member of Alpha is accessible by Beta and Alphasub

I find it hard to remember so here are some sound bytes

  1. “protected” keyword only increases visibility never decreases it.
  2. So a protected field is more accessible than default (package-private)
    • As an example, without “protected” on field1, subclasses outside the package cannot see field1.
  3. same-package neighbors are trusted more than children outside the package

For a “protected” field1, a non-subclass in the same package can see it just as it can see a default-accessible field2

Not mentioned in the article, but when we say “class Beta can access a member x of Alpha”, it means that the compiler allows you to write, inside Beta methods, code that mentions x. It could be myAlpha.x or it could be Alpha.x for a static member.

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 – y 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.