Where is option for Java Next-Generation Plugin? - java

I have a problem starting a commercial JavaWS application on IE11 on some computers at work. The application eventually starts but the user has to try several times before it works whick is very annoying.
We are currently using JRE 1.8.0_40 on Windows 7.
I have tried all possible things and in my research I've seen some references to Java Next-Generation Plugin and that It should be activated. When I open the Java Configuration I can't find this option. Why is that?
I have been reading this article where they mention Next-Generation Plugin and different ways of checking that it's activated.

If you read the article I linked thoroughly you find this way of checking/setting the option in the registry:
Go to Start/Run and type in “regedit.exe” in the Run dialog box. Click OK
Navigate to the following area in the registry (32-bit Java keys)
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\JavaSoft\Java Plug-in\<version>
Find or create the registry key UseNewJavaPlugin (REG_DWORD)
Ensure this key is set to value 1
Close the registry and restart your browser sessions for the setting to take affect

Related

Running Java in Internet Explorer 11

I have JRE 8u211 installed on a Windows 10 box with IE 11. I can see the Java plugin (and plugin 2) are installed and enabled. I have the "Allow active content to run in files on my computer" option checked under Security. But I cannot get a Java applet to load. Every time the page loads, I get the "The page you are viewing uses Java" notification as if the browser thinks I don't have Java installed.
What am I missing?
Figured it out. I'd forgotten that IE traditionally doesn't seem to like x64 Java installs very much. Once I dropped a 32 bit version, everything worked.
In the perfect dream world where all software development makes use of current and best practices, applets might be dead. But in the actual world of legacy support, they are (unfortunately) still alive.
I second the comment by Elliot Fischer... However, there is still quite a lot of Hardware that is still being supported, or even potentially manufactured (sold for sure) that can only function with these Java applets.
I had this problem with my Motorola FX7400. Of course Motorola says it's "Service & Support Discontinuation Date" is 30.8.2019. Of course the latest firmware is from 2015 and doesn't have a hint of any type of certificate or signing of java applets!
For most applets that have not been updated since the very latest Java Security settings were upgraded in around 2013-2015 and which most likely are also only 32-bit and have no signing of any sort on them; Do the following steps. Of course, even I CANNOT RECOMMEND THIS METHOD AT ALL FOR APPLICATIONS RUN FROM THE INTERNET Also, you should take precautions when trying to use Java like this on Hardware you are not familiar with.
The steps that are required for Windows 7, 8.1 & 10 with Internet Explorer 11 are as follows:
Download and install latest JRE SE 32bit from here: https://www.oracle.com/technetwork/java/javase/downloads/jre8-downloads-2133155.html (And yes, you need to give out your private data including address and phone number. You also need to pay for a license, if you are not a developer or a private user)
Start Internet Explorer 11 (64 bit seems to work fine)
Ensure ActiveX filtering is disabled Tools -> ActiveX filtering On my install disabling this was only necessary to be able to run the Java test from the "alternate page", which is marked "IE 11 users:": https://www.java.com/en/download/installed.jsp
Check that the Java plugin is enabled Tools -> Manage Add-ons
Check that your security zone has Scripting of Java applets enabled. On my IE11 it was enabled by default even for the Internet-zone set to Medium-High with protected mode on Tools -> Internet Options -> Security -> (select your appropriate zone) -> Custom level -> Scripting of Java applets
If the applet that needs to run is not properly signed (very likely...), it is required to set every single URL where an applet is run in to the exceptions. (As of writing this answer, at least wildcars for paths are working.)
When running the applet, accept the security exception prompts that Java prompts for.
And finally! For some reason there will at some point when loading an applet that previously loaded fine be a prompt about not being able to run the applet, because only applications that meet the very high security settings (signed applets) can be run. To get back to running again, Java's temporary files need to be removed. Restoring security prompts has no effect. Start Menu -> Configure Java -> General tab -> Temporary Internet Files -> Settings... -> Delete Files -> OK C:\Users\%username%\AppData\LocalLow\Sun\Java\Deployment\Cache -directory probably also works.
Security and prompts really have come far in the past 10 years, haven't they?
I jumped here searching for an answer that I found elsewhere and I would like to share.
According to my experience the problems of IEx64 with jre x64 are due to the fact that internet explorer tabs are 32 bit processes, so they work only if they find a 32 bit jre. There is a registry key to force IEx64 to open x64 tabs:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main
Dword TabProcGrowth set to 0
I heard it is considered a security flaw, but it can be accepted if IE is used only with well known legacy web applications.
About IEx64
In the folder
\Program Files (x86)\Internet Explorer
there is the 32 bit version and when you open a page in IEx64 it is actually displayed by an new instance of IEx86. You can check this using task manager, going on detail tab and looking at the application path.

Cannot get Java Applets to work in any browser

We are trying to download something from GE that uses Java to download when logging into the site. This is a windows 7 Professional PC. I have other computers that are able to do this successfully. Here is my order of operations:
Log into the site and select the file I want to download
Click download
It takes me to the page that says it will start in a few seconds but nothing happens. It is supposed to have a box that asks for Java to run.
I have reinstalled Java fresh and still nothing. Tried with multiple user accounts. Added the site to the list of exceptions in the firewalls and Java configuration. I have tried an earlier version of Java. This happens in Mozilla, Chrome and IE. I have made sure that the Java plugin shows up and is enabled. I just cant think of what I am missing. And since we are a contractor GE is not going to help us. Can anyone here think of anything?
Are you sure you have the Java plugin enabled? e.g. in Firefox, go to Settings, Plugins, and change Java Platform SE8 'Next Generation Java Plugin' to 'always activate'?
This sounds similar to the issues I had with Cisco WebVPN, Java-style. Once you have Java installed correctly and set as a plugin for any of the browsers you would like to use, see below.
Before you even start looking at browsers - if you think it is already set up correctly
Look at your Anti-Virus programs or anything else that could prevent it from working. McAfee Host Intrusion Protection is known to cause many Java programs to fail. Kapersky had issues, a while back, with Java on Windows (Java Applets not loading in Windows 8 ).
You must have a 64-bit browser to use 64-bit Java (also mentioned in the Chrome link below).
See below for any specific things that can be modified in the browser.
Chrome 43 is the more complicated browser to set up. They have a dedicated page with instructions.
How do I use Java with the Google Chrome browser?
Firefox 38 will prompt you.
In Internet Explorer 11, it's under Internet Options->Security. I recommend adding the hostname the applet is on as a Trusted Site (Select Trusted Sites and click the Sites button, then add the first part of the url). Click the Custom level button and make sure that Scripting of Java applets is not disabled.
If you still have problems with the applet:
Verify your Java version will work with the applet you are accessing
Verify the plugin is enabled for the browser through the Java Control Panel, which is available in Windows Control Panel, or on Mac/Linux, execute it from the JDK directory ($JAVA_HOME/ControlPanel ).
I ended up fixing the issue. I had to allow their UK site on the list for Java and enable the SSL 2.0 for HTTP in Java config as well

How Java Control Panel on windows functions in conjunction with many different versions of Java installed on the machine?

I'm struggling with specifying which one of the many java installations on my Windows 7 machine would be used by the Internet Explorer for (1) running applete as well as (2) for Java web start.
For example, I am going to that Java-View tab in Java Control Panel, change the checkbox there, then make Java Console visible in the advanced tab and then find from the Console header that not always Java which is checked in the Java-View is actually executing applets in my browser.
In Java Control Panel Java-View along with the "User" tab, there is also a "System" tab.
One usually cannot change anything there, but what does that mean, and does it play any role?
In Java Control Panel Advanced tab you see "Default Java for browsers" checkboxes.
Why Microsoft Internet Explorer checkbox there is always checked and always grayed out?
Is this checkbox important or is it Java-View tab screen, which actually affects IE operations?
Also in jre/bin folder of each java instalation I see javacpl.exe file and can execute each of them, but only one of them, I guess, appears in actual computer Control Panel. How do you determine, which of them is really shown and can be executed through my computer Control Panel? Does it make sense to do anything with alternative javacpl.exe executables - will their execution affect my IE java-related functionality.
Basically, I'm in total confusion of how this mechanism works, and wwould very much appreciate if someone could give some clarification on at least some part of the above questions. And I'm mostly talking here about Java 1.6 and Java 1.7, I guess it would be even more difficult if we try to cover in this question also older java versions.
Thanks a lot for any help on this subject.
Regarding your first question
" which one of the many java installations on my Windows 7 machine would be used by the Internet Explorer for (1) running applete as well as (2) for Java web start."
This can be tested by making your applets contain Java 7 features like "Diamond Operator". Compile it by jdk 1.7 and then try to run in browser, if it runs then your browser is using 1.7 else 1.6.
Second ques -
"In Java Control Panel Java-View along with the "User" tab, there is also a "System" tab. One usually cannot change anything there, but what does that mean, and does it play any role?"
Answer- This is my guess that system tab will contain that option which is configured in JAVA_HOME environment variable OR it can that jdk which was installed more recently installed. Because offcourse default can be only one and not two.
Third question -
"In Java Control Panel Advanced tab you see "Default Java for browsers" checkboxes. Why Microsoft Internet Explorer checkbox there is always checked and always grayed out? Is this checkbox important or is it Java-View tab screen, which actually affects IE operations?"
Answer - The option is grayed out because the option is already chosen for you and you need not specify that.
Hope that helps.

Java ME SDK 3.2 (and 3.3, 3.0 as well) just won't start

When i try to launch it any way, Java ME just freezes. To be more specific, javaw.exe called by device-manager.exe seems to go into infinite loop, since not a single exception or error message is passed. Icon in tray appears, but its menu, instead of devices list, shows only one entry: Exit, which incidentally doesn't work. I can only shutdown it through task manager. And since device-manager is required for emulator, i can't work with it at all.
I tried versions 3.0,3.2,3.3 of Java ME SDK and this problem persists in each one. OS: Windows 7. JDK: 7u25.
I've tried each and every advice i found on the Internet and still can't get it working. Device-manager log shows that the problem starts upon calling "rmiRegistryPortFile".
[2013-07-02 19:20:53.070] DEBUG - strap.BasicObjectConfiguration - Calling create on rmiRegistryPortFile
That's always the last entry in the log.
There was only one way i've managed to get it working - by installing and running it under Windows Virtual PC. Curious thing is, under VM it's working fine in the same very OS (freshly installed Windows 7). But unfortunately that didn't really give much on the cause of the bug, and that's not a solution :( I have to somehow get it working without VM.
I tried reinstalling Windows, that didn't help. Looked through javaw I/O in Process Monitor and compared it with working one. It looks like one of the application threads suddenly shuts down after reading file "rt.jar" (when loading "rmiRegistryPortFile" i guess?), whereas working javaw writes to log-file immediately after that. Windows logs got nothing on the subject: no permission issues, no errors or warnings at the time.
Tried modifying PATH variable to the dir with rmiregistry.exe, did not help. Network sockets are available. Changed DEP settings, same.
Could anyone please help? I've spent days on this bug already.
It's definitely a permission problem. Try to look if any folder related to Java is "READ ONLY".
If you get this error message when trying to run midlets through the built-in emulator of the JavaME SDK 3.0, try disabling DEP for runMidlet.exe.
Data Execution Prevention (DEP) configuration can be found at the following place in Windows: Control Panel > System Security > System > Advanced system Settings > Advanced tab > Performance > Data Execution Prevention.
Add this file to the DEP exclusion list:
<javame-install-dir>\runtimes\cldc-hi-javafx\bin\runMidlet.exe
If things work for you now, complain loudly to Sun (now Oracle) that they need to make software without buffer overflows.
Personally I filed a bug-report against the JavaME SDK 3.0. You should do that too, or make your voice heard on the same bug-report that you're having this problem as well.
Freshly installed windows doesn't have msvcrtXX.dlls
Go to folder runtimes\\cdc-hi\\bin and copy Microsoft.VC80.CRT into runtimes\\cldc-hi-javafx\\bin. This problem will be fixed over autoupdate soon.
Problem with localhost
Please edit <javamesdk_installdir>\\toolkit-lib\\modules\\bootstrap\\conf\\system.properties and change
device-manager.object-registry.host=localhost to: device-manager.object-registry.host=127.0.0.1
Port 1299 might be taken
Please edit <javamesdk_installdir>\\toolkit-lib\\modules\\bootstrap\\conf\\system.properties and change
device-manager.object-registry.port=1299 to: device-manager.object-registry.port=1999
XP 64-bit
Please use 32-bit version of JDK.
Firewall
Make sure that firewall is not blocking communication on ports given in 3. Default port numbers are 1299 for windows and 1999 for Mac.
I have tried all those steps above to no avail, until I replaced my JDK jdk-8u117 with jdk-8u112 (Must be 32 bit) after reading this thread https://community.oracle.com/thread/4009110. I had to restart my machine after changing the Java version because it was not detecting right away after installation. I'm using Netbeans 7.4.

How do you debug Java Applets?

Currently, the only information I have is a one-line error message in the browser's status-bar.
Do you know how I could get a stack-trace for example ?
Aside from the obvious use of the Java console and the applet viewer, starting from Java 6 update 7, you can use the VisualVM that comes with the JDK (JDK_HOME/bin/visualvm). It allows you to view the stack traces of each thread and even view all object instances.
AppletViewer is very handy, you can do a "Run as / Java Applet" from Eclipse to run, or "Debug As / Java Applet" to debug your applet classes.
However, sometimes to debug some security related stuff the browser plugin environment is just too different from appletviewer. Here's what you can do to effectively debug applets in the browser:
1) Obtain debugging info for the binaries
Backup the .jar files from JRE_HOME/lib
(Download and) Install a JDK for the same version as your JRE.
Copy the .jar files from JDK_HOME/jre/lib to JRE_HOME/lib
The files inside the JDK were compiled with the debugging information included (source-code line number information, variable names, etc) and the JRE files don't have this information.
Without this you won't be able to meaningfully step into core class code in your debugger.
2) Enable debugging for the Java Plug-in
Go to the Java Control Panel /
Java /
Java Runtime Settings /
View /
User /
Runtime Parameters
And add the options to enable debugging. Something like this:
-Djava.compiler=NONE -Xnoagent -Xdebug -Xrunjdwp:transport=dt_socket,address=2502,server=y,suspend=n
The interesting options are
the port (using 2502 here, you can use pretty much any free port, just write it down for later) and the suspend - if you need to debug the applet startup, classloading, etc, set this to "y". That way when you access an applet page, the browser will appear to freeze as the JVM immediately gets suspended waiting for a debugger to connect.
3) Use your favorite IDE to Remotely debug the Java Plug-in
In Eclipse, for instance, choose Run / Debug Configurations ... / Remote Java Application
Click on the "New" button.
Make sure connection type is "Socket Attach", choose localhost as the host if your browser is local, and the port you chose earlier (2502 in the example).
You might have to inlude the src.zip in your JDK on the sources tab to have the Java core class sources available.
Save the configuration, and once your browser is running the plug-in (with the JVM suspended or not) run the remote debugger to connect to the plug-in JVM, with a project containing your applet sources open.
This article is a bit old but is still relevant (including a section entitled "How to Debug Applets in Java Plug-in").
Edit: perhaps a better way to get stacktraces is to use the Java plugin console. If you hit "t" in that window, you'll see the following:
Prints out all the existing thread
groups. The first group shown is Group
main. ac stands for active count; it
is the total number of active threads
in a thread group and its child thread
groups. agc stands for active group
count; it is the number of active
child thread groups of a thread group.
pri stands for priority; it is the
priority of a thread group. Following
Group main, other thread groups will
be shown as Group , where name
is the URL associated with an applet.
Individual listings of threads will
show the thread name, the thread
priority, alive if the thread is alive
or destroyed if the thread is in the
process of being destroyed, and daemon
if the thread is a daemon thread.
The other command that I've used most often from that console is the trace level from 0-5:
This sets the trace-level options as described in the next section, Tracing and Logging.
From that page, you'll see that the levels look like this:
0 — off
1 — basic
2 — network, cache, and basic
3 — security, network and basic
4 — extension, security, network and basic
5 — LiveConnect, extension, security, network, temp, and basic
These tools can all be fairly useful as you're trying to unravel what in the world has gotten into the head of your applets. I know that they've worked for me.
The applet viewer supports debug options.
Stack traces from uncaught exceptions will appear to the console. This can be enabled from the Java Control Panel (Advanced > Java console > Show console) or some browsers have various options or plugins for enabling it.
You can attach a debugger to the running PlugIn process.
Perhaps the best way is not to debug at all. Write tests. Write code that doesn't couple to unnecessary assumptions - for instance that you are running as an applet. Unfortunately most GUI/applet example code is written very badly.
I faced issue doing remote applet debugging, every time while trying to connect from eclipse, its throws Connection refused error, my jre version was 64 bit and eclipse 32-bit, when I did replace with 32-bit jre, it worked for me. Also if we have install both 32-bit & 64-bit jre versions, IE by default uses 64-bit jre for applets, chrome and FF may use 32-bit jre versions.
Uncaught exceptions are sent to the console. You can also use System.out to write your own messages to the console. To view the results you'll need to open the console by right clicking the Java icon in the systray and opening the console (note this is different for Microsoft's VM).
To debug applets properly, you can setup Eclipse to debug applets. Right click the applet source file and click Debug as Applet. (If you have parameters for the applet you'll need to set this up.) Then you can step through the applet code as you would debug any other Java code.
For me the most important action to get applet debugging in eclipse, is to set in java control panel(tab java) the right binaries to use, that have debug symbols.
Only JRE included in jdk have this symbols.
So to debug applet in java control panel, tab java, press view button, after find the correct jre under jdk folder, for me for example "C:\Programmi\Java\jdk1.7.0_03\jre", and put check enabled only for this entry.
This is for me the clean way to do what Sami Koivu say.

Categories

Resources