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.
Posted by mr1yh1 
Posted by mr1yh1 
Posted by mr1yh1 