I've recently been learning Processing, a sort of Java based visual language. It has a feature to export sketches/scripts as html documents and open them in a browser and run them with a java applet. However, when I try to open them (on a Mac OS X 10.5.8), it redirects me to the Java page telling me that Apple supplies its own version. I checked for software updates and tried downloading another version of Java to no avail. Also, I checked on a website to see if Firefox had Java, but it said it was disabled, despite my preferences having Javascript checked off.
Any help? Thanks.
You're running an unsupported version of Java, you need to update to 10.6 or higher to get the latest version. https://discussions.apple.com/thread/3995956?start=0&tstart=0
This belongs on https://apple.stackexchange.com/ as well.
Related
Last night a new Java 7 update has been released: 7u65. I have a web application where a service applet is loaded, and after the update, my tests on different PCs did not show issues nor wrong behaviors.
Later, I started to receive issue reports related to my product's Java service applet. All the reports came from users who updated Java JRE to 7u65 (from 7u60):
The applet was not loading at all. I display a "Loading" screen when the application starts, and this was not being displayed. Also, all the services provided by my Java applet were unavailable.
After changing the Java Control Panel's advanced configuration to always show the console (in one of the PCs where this issue happened), I discovered that the applet was not even launching the Java console.
Using the same station where the error happens, trying to access java.com to check the current java version, the Java applet is loaded and the console is displayed without errors.
All tests were performed after clearing Browser and Java Cache, and even after removing the installed certificates (mine is a valid signed applet).
I checked the Java 7u65 release notes and none of the mentioned changes seem to affect my applet. Also, there were no issues while using Java 7u60.
I don't have any clues about what is going on, perhaps because the java update was released hours ago. As the Java console can not be displayed even if I configure Java Control Panel to do so, I can not tell if there is any exception. I can not reproduce the issue in my PCs (Windows 8, nor Windows 7, both at 64 bits), but the issue has been reported on Windows 7 PCs.
One of my friends told me that this seems to be happening on machines where Java 7u60 was in use, and then it was updated to Java 7u65 with no deinstallations. Also, this tends to happen in older OS (ie: WinXP) which is more natural.
I write this question because it seems very odd that some PCs have this issue, and some others not. I'd like to know if any one else is having this issue, knows what could be the reason, or has discovered/applied any solution to it. Also, I'd like to share the solution if I ever happen to find it.
Thanks.
Edit:
External references, related to the same Java version (JRE).
Internet Explorer crashing after updated Java to 7u65: An issue with the same JRE version, this time with Internet Explorer and Firefox.
RS Loading Issue (Java) ~ READ: An issue related to the same JRE version update, this time, in a Java Game.
The future of Java on Windows XP:
This end of support announcement has been misread as "Java no longer works on Windows XP" or "Oracle will stop Java updates from being applied on Windows XP". These statements are not correct.
I just ran into this exact problem with one of my applets.
It looks like some changes were made to the handling of the 'java-vm-args' and 'java_arguments' params in 7u65.
'java_arguments' seems to no longer work, when it is specified, my applet will silently fail without even launching the JVM.
I have had the same problem.
I delete C:\Users\${USER}\AppData\LocalLow\Sun
When i reloaded the web page containg the appelets. The JRE recreated this folder again.
And evrything was OK.
There is no big difference between the folders contents .. but it worked.
It seems to be a bug in the jRE
It seems that oracle has changed something with processing default plugin java arguments,
that caused problem in new java.
When upgrading from older version of java it is possible that value for
deployment.javaws.jre.0.args (or deployment.javaws.jre.1.args)
is not defined in
C:\Users\${USER}\AppData\LocalLow\Sun\Java\Deployment\deployment.properties
If you add
deployment.javaws.jre.0.args=
to deployment.properties, applet will work.
It can be done through Java Control panel also:
Java -> View -> double click on Runtime Parameters cell for java 7u65 to enter edit mode -> OK -> Apply
java-jvm-args solution didn't work for me, applet was launched but arguments were ignored.
Oracle has released an update that resolves this specific issue via version 7u67
http://www.oracle.com/technetwork/java/javase/7u67-relnotes-2251330.html
As Miloš Ratković wrote, if customer hasn't string in deployment.properties
deployment.javaws.jre.X.args=
where x is number of java installation for version 7_65 (number of java installation for particular version is X in string deployment.javaws.jre.X.product=1.7.0_65), Java applet failed to start.
For my case I have a solution - don't pass any arguments for my applet.
In my javascript code for starting applet I'm just comment
<param name="java_arguments" value="some arguments">
string
Also, if you delete the directory C:\Users\${USER}\AppData\LocalLow\Sun, during next startup of java applet java write new deployment.properties with correct java args string
Uninstall java 7 update 65 and reinstall java 7 update 55 Download the windows x86 offline version
Go to Java control panel and uncheck: automatic update
When the next window comes up, click on "do not check"
then click on "apply" and "ok"
close all browsers and reopen them to continue your work
This has worked for me every time so far and I have been doing this for the last two weeks now with "0" issues.
Sorry, this is not the answer. I was trying to verify the feedback about JRE 7u65 not able to accept "java_arguments"; however, I setup a Windows x32 and installed (new) 7u65 without upgrade from any older version. With the "java_arguments", the machine is able to load the applet in IE8 and FF30, when few specific PCs do fail the same applet with upgraded u65.
I have a page with a Java applet that has the following JavaScript code which makes a LiveConnect call when the window is closing to perform some clean up tasks:
window.onbeforeunload = function(e) {
var result = document.OutApplet.closeCheck();
Up until yesterday this was working as expected and performed the clean up tasks within the applet.
Now that Java 7u51 is available I have accessed this applet today and selected 'Later' when prompted to updated to the latest version of Java. Now when I close the window I get a JavaScript error:
Object doesn't support property or method 'closeCheck'
Just to clarify this is with Java 7u45 installed.
Is this expected behaviour or is there anything I can do to make it still work on 7u45? I can't find any mention of this in the release notes and prior to 7u51 our live connect call would still work without being on the latest security baseline.
Update
The above was with my Java security set as High.
I have changed it to Medium and repeated the above. I now get a message asking if I want to allow or block the LiveConnect call.
It seems there is now an undocumented (as far as I can find) requirement that LiveConnect will only work if you are on the security baseline (7u51).
Note the LiveConnect call to the applet works without any changes to the applet once I've updated to 7u51
This is a known Java bug affecting all version from 7u25 to 7u45:
http://bugs.sun.com/view_bug.do?bug_id=8027405
Only solution is to upgrade to 7u45 7u51 or set the java security slider to 'Medium'.
[Edit] corrected fix version according to bug report
As to why this recently (yesterday) started failing was because the baseline has been updated https://javadl-esd-secure.oracle.com/update/baseline.version, now if you edit C:\Users\username\AppData\LocalLow\Sun\Java\Deployment\security\baseline.versions and change the 1.7.0_51 to 1.7.0_45 and save the file, it should start working again(but will eventually be updated probably after some arbitrary time).
1) Close all browsers and programs
2) In the windows explorer, go to %localappdata%low\Sun\Java\Deployment
3) Open the file named “deployment.properties”
4) Add in the below line at the end of this file
deployment.expiration.check.enabled=false
5) Save and close the file
Same problem here.
Oracle did warn about new mandatory (see below) options back in september.
We implemented and delivered them in the end of last year but today they do not seem to work ...
https://blogs.oracle.com/java-platform-group/entry/new_security_requirements_for_rias
http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/manifest.html
Another solution if you can't upgrade you JRE (stuck between 1.7.0_25 and 1.7.0_45) :
open the Java Control Panel of the 1.7 JRE (javacpl.exe)
go to the advanced tab
uncheck the following "Java Plug-in" option : 'Enable the next-generation Java Plug-in'
Is there a way to detect if java is installed on your machine or if java is disabled on the browser. We use java applets in our application but before the applet is loaded we use "deployJava.js". Sadly even if Java is disabled on the browser it says java is not installed.
So is there way to differentiate if Java is installed or Java is disabled, preferably using javascript. I have also tried using "navigator.javaEnabled()" but it gives me the same result as using "deployJava.js".
You can't.
And that would be very annoying if you could. There's already enough information leaking from the browser to the page, if it started telling people what I have installed but that I have ostensibly disabled, that would be very annoying.
I guess it could be possible and useful to envision an API for that, but in the current state there isn't any: either the plugin is here to be used, or it isn't. It doesn't matter whether it's installed or not.
I guess you'll have to work around it by stating in your user-facing messages that Java either needs to be installed or enabled. Or you could offer to download a diagnostic tool to run it and check it locally, that could be another working alternative, though with the obviously annoying extra-steps to perform (and an additional tool for you to support).
Add a redirect to the HTML page in question. Redirect to javaNotEnabledOrNotInstalled.html (but think of a less descriptive and silly name for it).
Early in the applet init(), call JS to cancel the redirect.
Note also that in the traditional applet element..
<applet
code=..
width=..
height=..
alt='Java is installed but disabled!'>
No Java Plug-In installed in this browser. Get Java free from..
</applet>
In this circumstance, if Java is not installed at all, the user should see..
No Java Plug-In installed in this browser. Get Java free from..
However if Java is installed but disabled, they should see..
Java is installed but disabled!
Here is something js window.navigator.plugin
We have applet that uses smartcards to sign something. Everything was OK until new java update on Mac OS.
I'll explain. When macos had java 6 and special plugin for it, everything worked. But now they removed their plugin, and users must download browser-plugin for java 7 from Oracle web site.
Applet still sees Card Reader but doesn't see smartcard in it.
We use reader.isCardPresent() method, and it returns "false", no exceptions etc. like everything ok and there is no card in cardreader. We restore backup of the os, when there was 6 java and MacOS's own plugin, everything works. But we have many clients that have just bought new iMac or MacBook, they cannot use 6 java and apple's plugin.
Everything works on Windows.
We don't use any deprecated methods. Seems like problem with Oracle's plugin for Mac OS.
Anyone had similar problem or may be you have any ideas.
I just make some tests: take code from sample and slightly modify it. Run the sample on jdk1.7.0_09 in macosx 10.8.2. Pcsc framework 1.4.0.
terminal.isCardPresent() return false, but card can be accessed. Bug exist when java running both 32 and 64 bit mode. Pcscd running in 32 bit mode only, because generic pcsc driver is still 32-bit only.
In pcscd debug log i see some parsing errors in SHMMessageReceive, so bug may be in java or in the pcsc framework (winscard_msg.cpp).
Is that possible?
before entering a site, it should check whether java is installed and it has to be of a specific version before redirecting to the designated page.
javascript cannot be used because it can be turned off by the user.
java applet cannot be used to check as it can disabled by the user
thank you.
I think it is naive to assume that someone would have JS disabled but Java installed & enabled.
JS comes with the browser, but Java does not.
JS is enabled by default, and has to be explicitly disabled.
Many sites today either rely on JS, or give a much slicker user experience when JS is enabled.
The deployJava.js
is the latest strategy offered by Sun/Oracle for checking that a browser has a
specified minimum version of Java before running an applet or including a launch link for JWS
applications. If 90% of deployers of applets in the last 2-3 years use the script, what do you think the
chances are of seeing Java installed and enabled in those browsers where JS is disabled?
Sun's former way of ensuring an applet had a necessary version of the plug-in was using
HTMLConverter, which produced the nested OBJECT/EMBED element so hated by validation services
(and any self respecting web developer). This invalid HTML used no JS or Java to do what it did,
it all relied on HTML & the browser/user's ability and willingness to act on the said elements.
However I do not recommend using that approach, I think deployJava.js is a better way to achieve it.
If you are truly insistent on making every attempt to determine the user's Java, and do not mind
'breaking the back button', there are other techniques that can be used. E.G. have a series of pages.
The first page has a meta-refresh redirect to nojs.html set at NN seconds and uses JS to redirect to
hasjs.html immediately.
The hasjs.html tests for Java:
Detect if Java is enabled
Check Java version using something along the lines of javascript:alert(java.lang.System.getProperty('java.version')). It works in the address
bar of FF to pop a dialog that reports 1.6.0_24 on this box.
(Finally) to determine that the applet itself is active (as opposed to crashed/refused at run-time),
see Detect if an Applet is ready.
So as can be seen, JS will not only be able to check if Java is enabled, but can also check the version & that any specific applet has loaded successfully.
You can prompt the user to input which version of Java they have installed. Otherwise, no.
Well, without using Java Applet and without using JavaScript. What else can you use? You are trying to access client specific data, you can't grab such data in the server side.
Rewrite your application in .NET, and then you can enjoy User-Agent lines like this:
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1;
.NET CLR 1.1.4322; .NET CLR 2.0.50727)2011-04-27 23:02:21
I wish browsers were sending same stuff for installed Java... alas, they don't.