Win a copy of Java Mock Exams (software) this week in the Programmer Certification (OCPJP) forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Running 32bit lib in a 64bit Tomcat (Windows)

 
bobby stone
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My OS is 64bit Windows 8.1. I have installed Tomcat8 (64bit). The window environment variable JAVA_HOME is pointed to the 64bit JDK directory (Java8).
I am trying to host a war file from a 32bit app in Tomcat8 (64bit). Is this possible? This app is 32 bit because one of the library it uses is a 32bit lib from SUN era.
Do I have to uninstall the 64bit Tomcat and install 32bit Tomcat in order to get the war file host in Tomcat?
Please advise.
 
Tim Holloway
Bartender
Posts: 18465
61
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tomcat doesn't have 32-bit and 64-bit versions and neither are WARs. Compiled java code has always been 64-bit. Only the JVM came in 32-bit and 64-bit flavors.

You could break out of the write-once/run-anywhere frame by invoking an external JNI module in a webapp, and that might be compiled to 32-bit or 64-bit memory models, but that's not part of Tomcat.

What I really wonder about, though is that you have a 32-bit module that's a legacy of the "SUN era". Sun machines did not run Windows, they ran SunOS/Solaris, which is Unix. So they wouldn't use DLLs, they'd use Shared Object (.so) library files. You couldn't simply copy an .so to Windows and have it run. Aside from not having the correct file formats, the actual machine code was for the wrong CPU. Solaris was originally a Sparc-based OS, not an Intel-based one.
 
bobby stone
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hmm, I am a bit confused. From https://tomcat.apache.org/download-80.cgi, there are 2 different version of Tomcat for windows, 64bit & 32bit. The version of jdk (64bit or 32bit) must match the version of Tomcat that is in use. Hence the JAVA_HOME environment variable must point to the appropriate directory. So I am a bit confuse about what you said that there are no 64bit or 32bit version of Tomcat. Can you kindly explained. Thanks.
WRT to the 32bit library, it is JAI: http://www.oracle.com/technetwork/articles/javaee/jai-142803.html
There has no new development since 2006. A lot of imaging app use JAI. It is a 32bit app.
The WAR file generated by the app I want to deploy uses JAI.
Hence my original question.
Sorcerer
 
Tim Holloway
Bartender
Posts: 18465
61
Android Eclipse IDE Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you'll notice, there are 32-bit and 64-bit version ONLY for Windows. Not Linux, Unix/MacOS, even though Linux still is available in 32-bit versions (although for how much longer is uncertain).

That's because in addition to the actual Tomcat itself, there are bundles that include extra Windows-only service support stuff which would be different depending on what Windows memory model you are using.

I did some checking about JAI and this is yet another sterling example of Software Debt.

There is a very false conceit among many that "software doesn't wear out". It is very, very wrong. Software rots not from the inside out, but from the outside in. The hardware becomes obsolete, the OS becomes obsolete, in many cases even the source code becomes un-compilable (Java's mechanisms to forestall this last are one of its great strengths, and it's a major reason why I stopped working with Visual Studio and went all-Java).

JAI has not been touched in a decade. That's an eternity in software. It has no vendor support to speak of. Oracle has dumped it on the open market, and no one saw fit to take it over. You're past the point where you could keep debt at bay by paying small amounts at intervals and whatever solution you choose is going to cost you big. Even if you get JAI working, it's going to be a lonely kludge job that will eventually break again and cost a lot of money. And, alas, Murphy's Law can be depended on to have it break at the absolutely most inconvenient moment.

From what I saw, probably the easiest way to get back on track would be to refactor the app to use Apache Commons Imaging, although since I don't know what exact functions you need, I cannot guarantee it. The good news there is that the Apache Commons Imaging library probably doesn't have native code in it so no worry about 32-bit/64 bit. And modern JVMs being what they are, about the only faster way to do graphics would be to have a library that accessed the system's GPU directly and used GPU hardware-specific performance features. Native code libraries are almost never faster these days than what modern JVMs can JIT compile/optimize, so the main use for them now is more when you meed to talk directly to hardware.
 
bobby stone
Greenhorn
Posts: 7
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you for your in depth feedback. I will look at the Common Imaging Library for future usage.
For now, I will try to host the WAR file in my 64bit Tomcat to see if it works.
I know a number of imaging app (medical, geosensing, ... ) are using JAI. They cited the rationale that vector rendering of JAI is extremely efficient.
But you have a point that 10 years of no service upgrade is kind of dumb. As far as I am concern, SUN stopped supporting it long ago, Oracle has abandoned it. It is an orphan library now.
I really should look into the Common Imaging Library you suggested.
Thanks for the explanation.
 
Tim Holloway
Bartender
Posts: 18465
61
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Although JAI has no 64-bit support for Windows, the DLL equivalent (.so) for Linux is available in both 32-bit and 64-bit forms, so you might have better luck spinning up a Linux machine. File format compatability would not be a problem, although if the library looks for specific versions of external libraries, you'd have to get creative.

Actually, there's a whole set of stuff for Solaris, but Oracle appears to be killing Solaris this very week, so I wouldn't risk that.

If you really know that many users of JAI, it would seem like there would be some potential to take over the project yourself. But I cannot find the source code for the DLLs at the official java.net archive. Only binaries and Java code.
 
bobby stone
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tim: I got tied up with other things for a few days. I have a follow up question. Tomcat in my Windows is 64bit. JAI in windows is 32bit only. Based on your feedback, it really doesn't matter whether I have 32bit or 64bit Tomcat installed. Those 32bit, 64bit variants are for internal interface of Tomcat with the version of Windows OS (in my case 64bit). So theoretically, I don't have to uninstall my current 64bit Tomcat and install 32bit Tomcat. Am I correct? I have installed the JAI already.
Thanks in advance.
 
Tim Holloway
Bartender
Posts: 18465
61
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You can try, but I'm not optimistic.

The 16 and 32 bit Tomcat for Windows releases differ in the Windows binary modules for the Windows Service Manager, not in Tomcat itself, so Tomcat and the webapp are 64-bit in either case.

To compare, consider Solaris. Solaris had a base 32-bit JVM product which you could augment by installing their 64-bit JVM product on top of it (unlike some systems, where the 32-bit and 64-bit JVMs were completely separate). I think that there was only 1 Tomcat server used, regardless, but it has been a long while. There are also 32-bit and 64-bit JAI libraries (.so files) for Solaris, however. JAI doesn't have a 64-bit DLL for Windows, however, just a 32-bit DLL.

In the normal course of things, Windows bridged the 32-bit/64-bit gap by using shim modules, but you'd have to provide your own.

It's possible, though unlikely that the JNI kit for Windows could serve as its own shim. That's really your only hope.

Of course, the advantages of such an old build of JAI on modern systems may not even be worth it, since newer code would be more likely to take advantage of multi-threading, advanced graphics-support CPU instructions and modern-day GPUs. To say nothing of the likely performance boost of native 64-bit instructions. Things that weren't available for the most part back the last time JAI was touched.
 
Happiness is not a goal ... it's a by-product of a life well lived - Eleanor Roosevelt. Tiny ad:
the new thread boost feature: great for the advertiser and smooth for the coderanch user
https://coderanch.com/t/674455/Thread-Boost-feature
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!