We have a web application that uses a third party java applet for encryption and authentication. It's always been a bit finicky, but right now it has me pulling my hair out.
Over the weekend, we migrated to a MS Load balanced cluster, upgraded our DNS, and rolled out all of the MS patches. Now the applet fails for all of our users who are using the MSJVM. The solution is simple, we just have them install a recent version of Sun, but I cannot figure out why the MSJVM is failing.
Every other configuration works (Firefox, Safari, IE with Sun on Window, Linux or Mac) or I can get to work with a reasonable amount of effort, but nothing I can do will make MSJVM work.
I understand the MSJVM is depreciated, but nothing on the site (http://www.microsoft.com/mscorp/java/default.mspx) indicates that it should no longer work. I am looking for information that will either allow us to make the MSJVM work so we can determine if it's easier to fix or install Sun, or that I can use to force our desktop configuration team to update the company policy on the MSJVM.
Thanks
Update 2009.10.19: It's clear that something disabled the MSJVM. We should reject users who are using that JVM but it hasn't been a priority to update the site. We've just been waiting them to fail and then directing them to install SUN.
Most likely the Java version used by your applet is superior than the one supported by the MSJVM.
I have followed your link but I could not find what that version was. I think is something previous to Java 1.2 ( like java 1.1.17 or soemthing like that )
If you happen to have an error message or a screenshot, troubleshooting would be easier.
But, yes, the definitive answer would be to use the latest version of the Java plugin.
I remember there were scripts ( javascript ) tha help to identify the Java version and provided a link to download the latest one, but I cannot find it now. Take a look at java.sun.com and see if you can find it.
Microsoft's JVM was never Java-compliant: http://en.wikipedia.org/wiki/Microsoft_Java_Virtual_Machine
The MSJVM never got beyond Java 1.1.x, which is very old. So any functionality which appeared with Java 1.2 (Java 2, as it was called), such as Swing, won't work. With the MSJVM, you're pretty much limited to AWT for the UI.
Licensing issues and lawsuits triggered by incompatibilities introduced by Microsoft (such as the delegate keyword) meant that Microsoft never took their JVM further.
As of July 30th 2009 I think it was after being extending numerous times the MS JVM is finally no longer supported and at end of life.
A workaround I have seen used before if you absolutely cannot rewrite it would be to use a custom VB script to launch the application, The script would do a quick change on the registry to make MSJVM the default when the app was launched then swap it back to whatever the setting was for normal operation.
i.e.
Set Registry for MS JVM as default
Launch Application
Reset Registry for Sun JRE 1.5.0_X as default.
I dont have the code handy, you should be able to find VB registry modification with a quick google. I can probably dig it up if your stuck.
Related
I am trying to use Emscripten's emconfigure and emmake to compile OpenJDK for the web. The end goal would be to be able to run uncompiled java code natively in the browser. However, running emconfigure ./configure throws the error
configure: The C compiler (located as /usr/lib/emscripten/emcc) does not seem to be the required gcc compiler.
configure: The result from running with --version was: ""
configure: error: A gcc compiler is required. Try setting --with-tools-dir.
I have been searching all day and I haven't found anything along the lines of this error. Is there any easy workaround for this? Should I even be trying to build OpenJDK this way?
Is there any easy workaround for this?
I doubt it. If you look at (for example) jdk11u/make/autoconf/toolchain.m4 you will see the toolchains that are supported on various platforms. Emscripten is not listed.
I expect that emconfigure is trying to use the JDK's autoconf-based configuration framework. And that framework is checking the compiler you are trying to use ... and saying Nope!
You may be able to modify the auto-conf macros to support the Emscripten tool chain. But the next problem will be getting the code to actually compile. And then to getting it to run.
Should I even be trying to build OpenJDK this way?
It is not up to us to say what you should do.
However, I would make some observations.
If you are expecting this to work without significant effort, you are sadly mistaken.
What you are doing is equivalent to trying to port Java to a new OP platform and hardware platform. This is is a massive project. In addition to just getting the JVM to compile, you also have the problem of getting the Hotspot JIT compiler to generate WebAssembly code.
This is probably a bad idea anyway. Once upon a time, mainstream web browser vendors did support Java in the browser. But there were so many "security issues" that (virtually) all vendors have dropped support. Oracle saw the writing on the wall, and in Java 9 they started the process of removing support from the OpenJDK codebase. Applet support and JNLP are gone, and they are planning to get rid of the SecurityManager framework.
What you would be doing is bring back Java support in the web browser ... with the security safeguards stripped out.
Basically, the Java SE platform is to rich to implement securely in a web browser.
If you are still keen on building a JVM using Emscripten, take a look at https://github.com/emscripten-core/emscripten/issues/3342.
But note that they are talking about building JamVM, which is Java 1.6, and hasn't been touched since 2014.
My team is using Pebble template engine for preparing messages. We have done lot of POC on this and everything looks good in our side. We decided to implement that.
Now problem we see here is we are having JRE1.6 in our application servers but pebble jars are compiled in JDK1.7. So we are facing version mismatch error. Can anyone suggest a workaround for this problem?
We are already approaching our release timeline and stuck here :(
Technically, there are 4 options:
You start searching; sometimes either the providers of libraries; or some "mirror site" somewhere has kept older JARs. Maybe those would work instead.
You upgrade your application server to run on a 1.7 runtime.
You could try to de-compile those JARs; to then compile them with Java 6.
Turn to the home page of peeble, find that it points to GitHub ... in other words: we are talking about open source here. So: you download the source, and you build your own jars; using a Java 6 environment.
Option 3 is obviously the most "hackish" one; and there might even be licence terms preventing you from doing that. And on the other hand, option 2 sounds scary; but you know: when you just change the underlying JRE (without touching your app server itself) there is a certain chance that this "just works".
And the real takeaway here: such subtle details are important. You should improve your processes to discover them early up; not during the last 5 minutes of your schedule.
Java 7 is my system default JRE. All of my web browsers are configured to invoke JRE7 on a new instance, as default.
Netbeans fires up Java 8 on a new instance, as its 'isolated' default (isolated in terms as from the rest of the system).
Consider scenario: Chrome is up and running fine, then I'm inspired to code and then open Netbeans. When Netbeans loads, Chrome's java gets funky - I can no longer interact with javascript applets (such as chatango handshakes don't happen, scrollbars become non-responsive, any a host of other anomalies occur). I take the step to reinitialize Chrome, and frames either don't load at all, time out, or stack out of the page's "defined" layout.
Keep in mind, I am NOT (purposely) running any java 8 programs outside of Netbeans.
Why does this occur? My suspicion is that JRE8 replaces the pointers for API calls in the system env.. I would have assumed that the JRE sandbox would have extended to that machine version's libraries, but that seems not to be the case. Is this a fundamental incompatibility, or a bug? Must I suffer it until my choice browser developer releases a Java 8+ compatible browser? Am I the only one that even experiences this?
(I appreciate any feedback that is thoughtful, and not around the lines of LMGTFY or other useless quips)
Thanks!
I have seen something similar happen with Firefox. The reason was a faulty graphics card driver.
Both applications, Firefox and a Java application were using 3D acceleration which resulted in a lot of visual artefacts and crashes later on.
You could try the following:
Disabling any acceleration features in Netbeans (Use sun.java2d.noddraw and sun.java2d.d3d)
Disable acceleration features in Chrome.
Update your graphics card driver
I have written a Java app and an NSIS installer. Works great. The issue is when there is a new version, the full installer needs to be downloaded and run (and possibly the old version uninstalled first).
How do you achieve the "Help >> Check for updates" system that Chrome, Firefox, dozens of other applications use to make staying current less painful.
Any guidance as to the direction to take would be appreciated.
Thanks.
You can use the VPatch nsis plugin (part of the default install) to generate patches so you don't have to do a full install.
Your question does not explicitly state that you want to stick with NSIS. So I take the chance to bring your attention to Java Web Start which requires relatively little setup work and allows to distribute updates without much hassle (and no user interaction required).
NSIS does not support updating as it seems, and trying to implement it in Java will lead to a portability nightmare. Web Start seems to be "just the right tool".
Is anyone else having trouble running Swing applications from IntelliJ IDEA 8 Milestone 1? Even the simplest application of showing an empty JFrame seems to crash the JVM. I don't get a stack trace or anything, it looks like the JVM itself crashes and Windows shows me a pop-up that says the usual "This process is no longer responding" message.
Console applications work fine, and my Swing code works fine when launching from Netbeans or from the command line. I'm running Windows Vista x64 with the JDK 1.6 Update 10 beta, which may be a configuration the Jetbrains guys haven't run into yet.
Ask your question directly on the IDEA website. They always react fast and the problem you have is probably either fixed or documented.
I have actually experienced problems from using the JDK 6u10 beta myself and had to downgrade to JDK 6u7 for the time being. This solved some of my problems with among other things swing.
Also, i have been running IJ8M1 since the 'release' and I am very satisfied with it, especially if you regard the "beta" tag. It feels snappier and also supports multiple cores which makes my development machine rejoice. ;p
Anyway, i use WinXP32 and IJ8M1 with JDK 6u7 and that is afaik very stable indeed.
IDEA 8 Milestone 1 is a beta(ish) "based on a new platform". This may have changed the way that swing is handled. Also you are running a beta JDK.
You will probably get more help/submit a bug at the Jetbrain forums unless they are on SO also. Here is the bug tracker link