JRockit is a lot better in development environment, because of the wonderful jrcmd utility and JRA.
If you have installed WebLogic with Sun JDK, you can switch to JRockit by editing the
C:\_yourbeahome_\user_projects\domains\_yourdomain_\bin\setWLEnd.cmd (sh) file,
setting
set JAVA_VENDOR=BEA
set BEA_JAVA_HOME=C:\_yourbeahome_\jrockit_160_05
I am not sure this covers all scenarios, but at least it's a good starting point...
Tuesday, March 23, 2010
Subscribe to:
Post Comments (Atom)
2 comments:
It is very likely that it will not work. Just changing the java executable is not enough. Memory parameters and garbage collection will need changes.
e.g. -XX:PermSize= ,
-XX:MaxPermSize= are not available in jRockit. Garbage collector parameters for jRockit are completely different.
jRockit likes -jrockit better than -server of HotSpot. -server will also work for jockit.
If you are running a small time Weblogic installation for demo, probably you can get away with just changing the value in setDomainEnv.sh|cmd for JAVA_HOME. If its a system in production or testing, its very likely that it will fall flat.
Also if you are running a vendor application on Weblogic, its wise to consult the vendor for support.
Don't undermine SUN HotSpot. Have a look at jconsole, visualvm and standard utilities like jmap...you may change your mind..
With Java 6 you also get G1 garbage collector...touted to be the next generation and a low latency one..
Also underlying OS plays an important role. If Solaris, stick to SUN HotSpot and if Linux or Windows try jRockit.
HotSpot and jRockit are a close match...but I like jRockit better. jRockit Mission Control (toolset) is amazing (jconsole for HotSpot is not far tho..)
setting java_vendor and java_home should do. As for memory parameters and others, commEnv.sh file in /common/bin directory decides what to use depending on JAVA_VENDOR variable.
Post a Comment