Singleton Pattern in java, i saw the Monster.

I was re-factoring an open-source project for fun.
I found file backed configuration classes which are singleton in nature
and they were implemented in a look-like-singleton way
i decided to convert them all into Singleton.

Since it doesn’t need synchronization and
those configuration files needed at start-up not subject to lazy initialization
I preferred static final member and private constructor solution.


class Singleton{

private Singleton(){
...
}

private final Singleton instance = new Singleton();

public static Singleton getInstance(){
return instance;
}
}


class had a member named doc which is initialized inside a method init()
this method is called by constructor.

...
private Document doc;

private Singleton(){
init();
}

private void init(){
doc = ....
}

Code seemed okay but was failing “magically”,
Singleton.getInstance().getDocument() was giving a null doc instance.

After some digging,
I realized that code inside the constructor was just ignored,
Debugger didn’t care break points
whether inside constructor or init() too.
Even throwing a RuntimeException inside constructor had no effect.

i searched about that issue
only found some information about tomcat and jboss may fail in that situation :
http://www.c2.com/cgi/wiki?JavaSingleton

This last approach seems to work well in most cases — and perhaps it is supposed to work per the Java spec. But — as I’ve recently learned the hard way — both Tomcat and JBoss do not always execute this code correctly. In particular, if some code is placed in the body of the constructor, even something trivial like logging to System.out, it is not always executed. I’ve also had initialization of member variables silently fail in the constructor. Unfortunately, deadlines have driven me to seek workarounds rather than research this situation. I’d love to learn more about it, even if that means learning I’ve made some big dumb mistake in what I was trying!

doesn’t give the reason (at least i am not alone.)
NOTE : The code i was working on was swt-powered desktop application ( although tomcat’s servlet-api.jar was in my classpath ).

It’s obviously a bug somewhere
but i can not dare to report it ( first i should isolate the part of code reproduces the issue ).
but if someone interested
i will give the road-map i was on
maybe you’ll see the monster too.

java as a portable application.

When i first installed ubuntu, gcj was the default “java provider”.
Java applications were depending on this package and
i was in doubt to uninstall it.

First i went through update-alternatives –config java
which was a mistake.
( Do you know how many java related things we have ? )

update-alternatives –config java
update-alternatives –config javac
update-alternatives –config javap
update-alternatives –config javah
update-alternatives –config javadoc
update-alternatives –config keytool
update-alternatives –config policytool
update-alternatives –config jarsigner
…
etc.

i discovered later update-java-alternatives does the job.
It seems people are confused about it
a lot of websites are still advising the first form.

But the real point was :
“who want to have a mixture of java tools from different platforms ?”
Why not a single step and “best known form” of the command :
update-alternatives -config java-platform-or-whatever
( maybe a new command for ‘freaky’ installation scenarios )

Those times ubuntu didn’t like the java license.
Nowadays open source java from sun became default.
But it’s worth to notice,
ubuntu always were providing proprietary graphics-card drivers
with an oversimplified installation procedure.

After installing tomcat,
i faced their fashion of deploying things was different than i was familiar.
Tomcat’s files/folders were scattered over different places.
And the JRE/JDK installation, there were symbolic links inside /usr/bin to java executables .

It may be obvious to search a server configuration file
under /etc/ directory for a linux administrator,
moving logs and web applications under /var directory ( and probably on a different partition ) also.
But missing the point :
“java and tomcat are portable in nature”.

I believe all those “policies” doesn’t fit well with java
and decided to put my complaints in public:

• /usr/bin is available for everyone.
  Its practically impossible to force a particular user to another java runtime.
  We can add ANOTHER_JAVA to the user’s PATH,
  but its easy to by-pass.
  We may change file permissions for /usr/bin/java or
  changing permissions of java installation directory it points
  but both of them makes those symbolic links pointless to be there.
• Proper way to put java executables into PATH is
  adding them as export PATH=”$JAVA_HOME”/bin:$PATH.
  Java executables under /usr/bin and a JAVA_HOME variable (possibly pointing somewhere else)
  rise an unnecessary configuration duplication.
  Scripts which checks JAVA_HOME will run one JVM, direct calls will run another JVM.
  It’s confusing !.
• Default place for java.security and java.policy files which should be somewhere under $JAVA_HOME now will be pointed by /usr/bin/java found in PATH.
  Same as above it’s not possible “safely” to set different security policy files for different users.
  And again confusion !.
• Tomcat, when you want to have different instances of it
  you challenge with the “policy”.
  Simplest way is not to install java and related things as ubuntu packages.
  But what about applications depends on them,
  is there a way to make apt happy with “seems unsatisfied” but perfectly complete dependencies ?

  I switched to slackware linux since they are promoting upstream-defaults.
  i found no symbolic links inside usr/bin or whereever.
  JAVA_HOME and PATH was set properly by /etc/profile.d/jdk.sh script.
  There was not a tomcat package ( and definitely there is no need for it )
  i downloaded and unpacked it under /opt/.
  Just a need to set CATALINA_HOME environment variable.

  Portable application logic make things simple.
  We may have different java virtual machines for different purposes.
  same as different version and/or configurations of java application servers.
  Just we need to copy the application folder somewhere else and
  setting some environment variables and file permissions.