Develop Reference

java.lang.ClassFormatError: JVMCFRE074 no Code attribute specified; class=javax/ejb/RemoveException, method=<init>()V, pc=0

I am getting the below error while trying to publish the application EAR in the server.
Deployment from com.ibm.etools.ejbdeploy.EJBDeployer had errors:
RMIC Command returns RC = MyApplicationEJB. The problems which stopped RMIC are displayed, and have also been recorded in the .log file in error: An error has occurred in the compiler; please file a bug report (http://java.sun.com/cgi-bin/bugreport.cgi).
java.lang.ClassFormatError: JVMCFRE074 no Code attribute specified; class=javax/ejb/RemoveException, method=<init>()V, pc=0
at java.lang.ClassLoader.defineClass(ClassLoader.java:275)
at java.lang.ClassLoader.defineClass(ClassLoader.java:212)
at com.ibm.tools.rmic.iiop.DirectoryLoader.loadClass(DirectoryLoader.java:149)
at com.ibm.tools.rmic.iiop.CompoundType.loadClass(CompoundType.java:354)
at com.ibm.tools.rmic.iiop.Type.initClass(Type.java:1008)
at com.ibm.tools.rmic.iiop.Type.setRepositoryID(Type.java:1025)
at com.ibm.tools.rmic.iiop.CompoundType.initialize(CompoundType.java:762)
at com.ibm.tools.rmic.iiop.ValueType.initialize(ValueType.java:323)
at com.ibm.tools.rmic.iiop.ValueType.forValue(ValueType.java:131)
at com.ibm.tools.rmic.iiop.CompoundType.getMethodExceptions(CompoundType.java:1678)
at com.ibm.tools.rmic.iiop.CompoundType$Method.<init>(CompoundType.java:2457)
at com.ibm.tools.rmic.iiop.CompoundType.addAllMethods(CompoundType.java:1308)
at com.ibm.tools.rmic.iiop.RemoteType.isConformingRemoteInterface(RemoteType.java:222)
at com.ibm.tools.rmic.iiop.RemoteType.initialize(RemoteType.java:171)
at com.ibm.tools.rmic.iiop.RemoteType.forRemote(RemoteType.java:90)
at com.ibm.tools.rmic.iiop.CompoundType.makeType(CompoundType.java:852)
at com.ibm.tools.rmic.iiop.CompoundType$Method.<init>(CompoundType.java:2408)
at com.ibm.tools.rmic.iiop.CompoundType.addAllMethods(CompoundType.java:1308)
at com.ibm.tools.rmic.iiop.RemoteType.isConformingRemoteInterface(RemoteType.java:222)
at com.ibm.tools.rmic.iiop.RemoteType.initialize(RemoteType.java:171)
at com.ibm.tools.rmic.iiop.RemoteType.forRemote(RemoteType.java:90)
at com.ibm.tools.rmic.iiop.CompoundType.addRemoteInterfaces(CompoundType.java:1455)
at com.ibm.tools.rmic.iiop.ImplementationType.initialize(ImplementationType.java:166)
at com.ibm.tools.rmic.iiop.ImplementationType.forImplementation(ImplementationType.java:92)
at com.ibm.tools.rmic.iiop.CompoundType.makeType(CompoundType.java:892)
at com.ibm.tools.rmic.iiop.ClassType.initParents(ClassType.java:197)
at com.ibm.tools.rmic.iiop.ImplementationType.initialize(ImplementationType.java:156)
at com.ibm.tools.rmic.iiop.ImplementationType.forImplementation(ImplementationType.java:92)
at com.ibm.tools.rmic.iiop.StubGenerator.getTopType(StubGenerator.java:151)
at com.ibm.tools.rmic.iiop.Generator.generate(Generator.java:285)
at sun.rmi.rmic.Main.doCompile(Main.java:547)
at sun.rmi.rmic.Main.compile(Main.java:148)
at sun.rmi.rmic.Main.main(Main.java:786)
1 error
Can anybody please help me out in this.
I am using - Websphere 9.1 and jdk 1.6. Interesting thing is my colleagues who have a lower version of Websphere - 8.0, do not get this error.
UPDATE: My Websphere's Runtime Environment is - WebSphere Application Server v7.0

In general a ClassFormatError means that the class with the error was compiled at a java level that is greater than the java level being used at runtime.
In the case of WebSphere v9.0 (which only support Java 8+), the javax/ejb/RemoveException class is compiled at the Java 7 level, so running WAS on Java 6 with a class compiled at the Java 7 or higher level will result in a ClassFormatError.
Update:
You have mentioned in the comments that you are using WAS v7.0 and not WAS v9. The overall explanation is the same regardless of what version of WAS you are using, namely, you can't run on a lower java level than what the classes were compiled with.
I recommend checking what java version the javax/ejb/RemoveException class in your WAS install was compiled at, and compare it to the java level you are running on.

JRuby 9.0.5.0 cannot load compiled ruby files

Our application is a RoR app, and currently uses JRuby version 1.7.22, and JRE 8_65. Our app is an on-prem solution, so we use JRuby to host our application on JVM at the target, Windows Server 2012 R2 system. We compile our ruby code, using
jruby -S jrubyc
This takes the .rb file and compiles it to a .class file. In the original .rb, it loads in the class file, like so.
load __FILE__.sub(/\.rb$/, ".class")
This all works with JRuby 1.7.22
Now, we want to update JRuby to 9.0.5.0, but are experiencing some problems when it comes to deploying our application. Basically, that line of code above inside of the .rb file is not working anymore, and we get the error when trying to run a rake db:setup
rake aborted!
LoadError: C:/appname/app/models/app_attribute.class is not compiled Ruby; use java_import to load normal classes
C:/appname/app/models/app_attribute.rb:1:in `<top>'
C:/appname/db/seeds.rb:10:in `<top>'
C:/appname/db/seeds.rb:9:in `block in (root)'
Tasks: TOP => db:setup => db:seed
(See full trace by running task with --trace)
Great. So I replace load with java_import
rake aborted!
ArgumentError: not a valid Java identifier: C:/appname/app/models/app_attribute.class
uri:classloader:/jruby/java/core_ext/object.rb:43:in `block in java_import'
uri:classloader:/jruby/java/core_ext/object.rb:34:in `java_import'
C:/appname/app/models/app_attribute.rb:1:in `<top>'
C:/appname/db/seeds.rb:10:in `<top>'
C:/appname/db/seeds.rb:9:in `block in (root)'
Tasks: TOP => db:setup => db:seed
(See full trace by running task with --trace)
Still not working, no matter what I try. I looked at this post: https://github.com/jruby/jruby/issues/3018
I tried to pass the parameter
jruby -Xaot.loadClasses=true
But I get a warning saying that aot.LoadClasses is not recognized. EVEN THOUGH I see it in the properties when I type
jruby -Xproperties
I have done A LOT of research on this, and have probably have looked at everything on the internet regarding this. Any input will be greatly appreciated. Is there something I missing? I am not fully adept in Java.
Thank you.

might be the same issue as https://github.com/jruby/jruby/issues/3651
which means you'll need to wait for 9.1 or use a snapshot http://ci.jruby.org/
since, the error is slightly different you should look into reproducing with snapshot and if it fails (might be Windows related) a step-by-step reproduction might speed-up getting the issue resolved.
jruby -Xaot.loadClasses=true
this is not needed with Warbler
But I get a warning saying that aot.LoadClasses is not recognized. EVEN THOUGH I see it in the properties when I type
hmm, could you reproduce this with an empty script and no JRUBY_OPTS ?
I have done A LOT of research on this, and have probably have looked at everything on the internet regarding this. Any input will be greatly appreciated.
you might want to try looking into the issue next time :) or considering getting some support
Is there something I missing? I am not fully adept in Java.
you shouldn't be missing anything - its not a Java issue ...

How to disable AspectJ dump files "ajcore.txt"

I've got a Tomcat webapp where I'm using AspectJ for logging and metrics, everything seems fine, but it keep creating several files like ajcore.20150310.113255.780.txt in the root folder. There is no exception in this files, so they are completely useless.
I've found this: https://eclipse.org/aspectj/doc/released/pdguide/ajcore.html
That states that using org.aspectj.weaver.Dump.exception="false" should disable this behavior, yet the files are still appearing. Is there any other way to completely disable the creation of this files? The other option mentioned: org.aspectj.dump.directory would also solve the problem, but it doesn't seem to work either.
This is the content of the file in case it helps for anything:
---- AspectJ Properties ---
AspectJ Compiler 1.7.1 built on Thursday Sep 6, 2012 at 16:39:22 GMT
---- Dump Properties ---
Dump file: ajcore.20150310.113255.780.txt
Dump reason: org.aspectj.weaver.BCException
Dump on exception: true
Dump at exit condition: abort
---- Exception Information ---
---- System Properties ---
... My system properties here
---- Command Line --- Empty
---- Full Classpath --- Empty
---- Compiler Messages --- Empty

Either of the following options may help:
Executing this code before any AspectJ weaving occurs (if possible): org.aspectj.weaver.Dump.setDumpOnExit(org.aspectj.bridge.IMessage.ABORT)
Adding this system property definition to your java command-line: -Dorg.aspectj.weaver.Dump.condition=abort

I think it is good that the AJ core dump happens because something seems to go wrong during LTW compilation:
Dump file: ajcore.20150310.113255.780.txt
Dump reason: org.aspectj.weaver.BCException
So there is an exception and you should investigate and fix it. Maybe some of your classes are woven with the logging code correctly and some are not. Run the weaver in verbose mode and check your console output, maybe you see something strange there. An AJ core file means that the weaver/compiler was shut down completely (abnormal termination).
As for the actual problem, I think that this
---- Command Line --- Empty
looks strange, as if no command line parameters were passed to the weaver. Also that no exception is actually logged is really unusual.
Which Java version are you on? I assume Java 7 because 1.6 is really old and Java 8 needs AspectJ 1.8. Anyway, can you try to use the latest AspectJ version 1.8.5 or at least the latest 1.7.4 from the old release and see if the problem still occurs?

Add this argument to your JVM run: -Dorg.aspectj.weaver.Dump.exception=false
And also see official docs

getting java library error in application

I have a web application that is deployed on WebSphere and that use one java library to generate files in excel format but I am getting the following error in WebSphere, but it will work fine with the TOMCAT server.
What can the problem be?
ERROR IS :-
Error 500: java.lang.LinkageError: LinkageError while defining class:
jxl.format.CellFormat Could not be defined due to: (jxl/format/CellFormat) bad major version at offset=6 This is often caused by having a class defined at multiple locations within the classloader hierarchy. Other potential causes include compiling against an older or newer version of the class that has an incompatible method signature. Dumping the current context classloader hierarchy: ==> indicates defining classloader ==>[0] com.ibm.ws.classloader.CompoundClassLoader#50c450c4 Local ClassPath: C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war\WEB-INF\classes;C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war\WEB-INF\lib\activation-1.1.jar;C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war\WEB-INF\lib\axis.jar;C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war\WEB-INF\lib\cglib-nodep-2.2.jar;C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war\WEB-INF\lib\commons-discovery-0.2.jar;C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war\WEB-INF\lib\commons-logging.jar;C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war\WEB-INF\lib\commons-net-2.0.jar;C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war\WEB-INF\lib\commons-net-ftp-2.0.jar;C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war\WEB-INF\lib\dom4j-1.6.1.jar;C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war\WEB-INF\lib\iText-5.0.6.jar;C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war\WEB-INF\lib\jaxrpc.jar;C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war\WEB-INF\lib\jdom-1.1.jar;C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war\WEB-INF\lib\jettison-1.0.1.jar;C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war\WEB-INF\lib\joda-time-1.6.jar;C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war\WEB-INF\lib\json-rpc-1.0.jar;C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war\WEB-INF\lib\jxl.jar;C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war\WEB-INF\lib\mail-1.4.jar;C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war\WEB-INF\lib\ojdbc14.jar;C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war\WEB-INF\lib\quartz-all-1.5.2.jar;C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war\WEB-INF\lib\saaj.jar;C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war\WEB-INF\lib\scheduler-plugin-example.jar;C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war\WEB-INF\lib\scheduler-plugin.jar;C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war\WEB-INF\lib\servlet-api.jar;C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war\WEB-INF\lib\sqljdbc.jar;C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war\WEB-INF\lib\stax-1.2.0.jar;C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war\WEB-INF\lib\stax-api-1.0.1.jar;C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war\WEB-INF\lib\wsdl4j.jar;C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war\WEB-INF\lib\wstx-asl-3.2.7.jar;C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war\WEB-INF\lib\xml-writer-0.2.jar;C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war\WEB-INF\lib\xom-1.1.jar;C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war\WEB-INF\lib\xpp3_min-1.1.4c.jar;C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war\WEB-INF\lib\xstream-1.3.1.jar;C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war\WEB-INF\lib\xstream-benchmark-1.3.1.jar;C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war Delegation Mode: PARENT_FIRST [1] com.ibm.ws.classloader.JarClassLoader#738995212 Local Classpath: Delegation mode: PARENT_FIRST [2] com.ibm.ws.classloader.ProtectionClassLoader#60e060e0 [3] com.ibm.ws.bootstrap.ExtClassLoader#70567056 [4] org.eclipse.osgi.framework.adaptor.core.CDSBundleClassLoader#4e024e02 [5] sun.misc.Launcher$AppClassLoader#6b806b80 [6] sun.misc.Launcher$ExtClassLoader#3fe03fe ---Original exception--- java.lang.UnsupportedClassVersionError: (jxl/format/CellFormat) bad major version at offset=6 at java.lang.ClassLoader.defineClassImpl(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:222) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:148) at com.ibm.ws.classloader.CompoundClassLoader._defineClass(CompoundClassLoader.java:526) at com.ibm.ws.classloader.CompoundClassLoader.findClass(CompoundClassLoader.java:477) at .............

This is the problem:
Could not be defined due to: (jxl/format/CellFormat) bad major version at offset=6
You're using a JExcel library compiled for a version of Java that your application server does not support. You'll either need to recompile the library or move to a newer version of WebSphere Application Server.
(The product printed the same "defined at multiple locations" error with class loader dump for all LinkageError, regardless of whether that text is actually relevant, until around 6.1.0.21.)

Looks like you've got Andy Khan's JExcel library in the CLASSPATH twice. See if WebSphere ships with it. If it does, remove yours from the application WEB-INF/lib and see if that helps.

Hibernate fails with NullPointerException in EntityTuplizerFactory.constructTuplizer? Why?

I have a problem when I try to instantiate Hibernate and connect with a MySQL database (see error message below).
Curiously enough the connection works fine using the exact same hibernate.cfg.xml file when running Junit tests but it refuses to work when run from Tomcat...
I am starting to run out of ideas.
Any clues or tip where to look?
Caused by: org.hibernate.HibernateException: Unable to instantiate default tuplizer [org.hibernate.tuple.entity.DynamicMapEntityTuplizer]
at org.hibernate.tuple.entity.EntityTuplizerFactory.constructTuplizer(EntityTuplizerFactory.java:110)
at org.hibernate.tuple.entity.EntityTuplizerFactory.constructDefaultTuplizer(EntityTuplizerFactory.java:135)
at org.hibernate.tuple.entity.EntityEntityModeToTuplizerMapping.(EntityEntityModeToTuplizerMapping.java:69)
at org.hibernate.tuple.entity.EntityMetamodel.(EntityMetamodel.java:323)
at org.hibernate.persister.entity.AbstractEntityPersister.(AbstractEntityPersister.java:456)
at org.hibernate.persister.entity.SingleTableEntityPersister.(SingleTableEntityPersister.java:131)
at org.hibernate.persister.PersisterFactory.createClassPersister(PersisterFactory.java:84)
at org.hibernate.impl.SessionFactoryImpl.(SessionFactoryImpl.java:267)
at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1341)
at se.fmt.atlantism.util.HibernateUtil.buildSessionFactory(HibernateUtil.java:16)
... 38 more
Caused by: java.lang.NullPointerException
at org.hibernate.tuple.entity.EntityTuplizerFactory.constructTuplizer(EntityTuplizerFactory.java:107)
... 47 more

I'm writing this for future Googlers and reference.
I've done some more research and the root source of the problem is still not known. However the following article throw me on the right track.
http://www.howtogeek.com/howto/linux/installing-tomcat-6-on-ubuntu/
It seems like the Tomcat (version 6 at least) packages available in Ubuntu (and Debian) are not working correctly. Instead I installed Tomcat using the following guide:
http://www.ctrip.ufl.edu/tomcat6-debian-lenny-howto
While this might not be the premium choice of installation it seems necessary to get Tomcat version 6 running without problems on Ubuntu and/or Debian Lenny.

In my case, this error was resolved by switching the <dependency/> order in my pom.xml. When hibernate (3.2.7.ga) comes before hibernate-annotations (3.4.0.GA) this error occurs. The other way around, it works fine. This is the case even with scope=compile.
I would guess that you need to tweak your classpath, except that (assuming you've dropped both jars in WEB-INF/lib) it should alpha-sort in the correct order. But maybe this will give someone a hint on how to move forward.

In my case it was a simple mistake - the config file *.hbm.xml had a property that the mapped object didnt have! I also heard of cases of that error apearing when you misspell a get/set function - very similar to my case.

I was facing the same problem. It went away after I downloaded "javassist.jar" and put it in the classpath: http://www.java2s.com/Code/Jar/JKL/Downloadjavassistjar.htm

This is how the Tomcat daemon process looks:
root 2605 0.0 0.0 16584 376 ? Ss 15:39 0:00
/usr/bin/jsvc -user tomcat6
-cp /usr/share/java/commons-daemon.jar:/usr/share/tomcat6/bin/bootstrap.jar
-outfile SYSLOG -errfile SYSLOG -pidfile /var/run/tomcat6.pid
-Djava.awt.headless=true -Xmx128M
-Djava.endorsed.dirs=/usr/share/tomcat6/endorsed
-Dcatalina.base=/var/lib/tomcat6 -Dcatalina.home=/usr/share/tomcat6
-Djava.io.tmpdir=/tmp/tomcat6-temp -Djava.security.manager
-Djava.security.policy=/var/lib/tomcat6/work/catalina.policy
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
-Djava.util.logging.config.file=/var/lib/tomcat6/conf/logging.properties
org.apache.catalina.startup.Bootstrap
This is how the Tomcat process looks when run from within Eclipse using the Sysdeo Tomcat launcher plugin:
(this one actually works)
jzaruba 2655 19.7 4.5 358304 46152 ? Sl 15:43 0:01
/usr/lib/jvm/java-6-sun-1.6.0.15/bin/java
-agentlib:jdwp=transport=dt_socket,suspend=y,address=localhost:37377
-Dcatalina.home=/usr/share/tomcat6
-Djava.endorsed.dirs=/usr/share/tomcat6/endorsed
-Dcatalina.base=/var/lib/tomcat6 -Djava.io.tmpdir=/var/lib/tomcat6/temp
-Dfile.encoding=UTF-8 -classpath
/usr/share/tomcat6/bin/bootstrap.jar:/usr/lib/jvm/java-6-sun-1.6.0.15/lib/tools.jar
org.apache.catalina.startup.Bootstrap start
The working one (Eclipse launched) is run using java-6-sun-1.6.0.15, I'm Windows user so I don't know how to tell which JRE is used for /usr/lib/jsvc (looking at it though), but my guess would be it is some OpenJDK... Could this be the difference?
update: jsvc probably uses the same JRE Sysdeo Tomcat launcher does