Updating Java 6 to Java 7

I’m having issues getting Designer to launch using Java 7 after an upgrade. I installed Java 7 (x64) alongside Java 6 (x86) and took the following steps post-installation, (copy/pasted from an email I’m drafting) …


  1. Download Java Platform (JDK) 7u3

  2. Run the installer

[list]a. When prompted for a location for JDK, use C:\Java\jdk1.7.0_03

b. When prompted for a location for JRE, use C:\Java\jre7

c. When the installation wizard for JavaFX comes up, cancel out of it[/ul]

  1. I changed the JAVA_HOME environment variable to C:\Java\jdk1.7.0_03

  2. I eliminated C:\Java\jdk1.6.0_16\jre\bin from the PATH environment variable. I added %JAVA_HOME%\bin to the beginning of the PATH environment variable.

  3. Within Ignition’s install directory, open the ignition.conf file in the /data folder

[ul]a. Locate the wrapper.java.command=C:/Java/jdk1.6.0_16/jre/bin/java.exe line under Wrapper Java Properties and put a # in front of it, (which will comment it out)

b. Just below it, remove the # from the beginning of the #wrapper.java.command=%JAVA_HOME%/bin/java line

c. Save the file and restart the Ignition Gateway service

d. On Ignition’s web interface, go to the Configure page. Under System Properties, the Version field should read Oracle Corporation 1.7.0_03[/ul]

  1. On Ignition’s web interface, go to the Configure page and clicked the Gateway Settings links under the Configuration heading. Working in the Settings tab, change Allowed JREs under Web-Launch Settings to 1.7+

After taking all these steps, my Designer/Client still uses Java 6, (I’m running everything on the same machine, Gateway & Designer/Client). If I launch the Java Control Panel from the Windows Control Panel, it’s using Java 7, (and doesn’t list my Java 6 JRE either).

I don’t have a great answer for you, I pretty much encountered the same thing on my dev system here, though instead of actually figuring it out, I just kind of uninstalled/reinstalled, etc. until it more or less worked.

One thing that came to mind: take a look at how Window’s is set up to handle JNLP files. The easiest thing to do, I think, is look in the registry under: HKEY_CLASSES_ROOT\JNLPFile\Shell\Open\Command

Mine is going to javaws.exe in System32, so not very exciting… though if yours is pointing to a Java6 install dir, that would obviously be something.


[quote=“Colby.Clegg”]Mine is going to javaws.exe in System32, so not very exciting… though if yours is pointing to a Java6 install dir, that would obviously be something.[/quote]Same here … funny thing is, when I navigate to the file, right-click > Properties > Details, the product name listed is Java™ Platform SE 7 U3.

If I change the registry key’s value and point it to the javaws executable in my JDK directory, the clients/designers launch using Java 7; however, I’d prefer a solution that doesn’t have me tinkering with the registry. I’ve gone into Control Panel > Default Programs (I’m on Windows Server 2008) and make the change there, but that doesn’t seem to make a difference.

I’ll keep digging, thanks Colby.

Just figured I’d share this link while I had it in front of me, lists out some Java related registry entries … http://lopica.sourceforge.net/gotwebstart.html

EDIT: Same information, just from a more official resource … http://www.oracle.com/technetwork/java/javase/runtime-windows-137915.html


Yeah, I was just curious if yours was set differently. I suspected that the web launch exe was probably delegating to the version of Java it thought should be used, but wasn’t sure.

What do you currently have the “Allowed JREs” gateway setting set to? Is it only “1.7+”, or did you add that to the existing list?


[quote=“Colby.Clegg”]What do you currently have the “Allowed JREs” gateway setting set to? Is it only “1.7+”, or did you add that to the existing list?[/quote]Just 1.7+, I got rid of the 1.6+ and 1.5+ entries.

One thing I’m running into with this upgrade - we had to add this to the ignition.conf to get passed a weird Java VerifyError:


That worked for loading up the modules and running code on the gateway. However, I’m still getting the same exception when the initializeScriptManager is called on Designer/Client startup:

com.inductiveautomation.ignition.common.modules.ModuleLoadException: Error loading hook class "com.project.hybrid.global.ignition.hooks.IgnitionGlobalDesigner" for module "Hybrid Global Module Designer--Client". at com.inductiveautomation.ignition.designer.IgnitionDesigner.loadModules(IgnitionDesigner.java:730) at com.inductiveautomation.ignition.designer.IgnitionDesigner.startup(IgnitionDesigner.java:296) at com.inductiveautomation.ignition.designer.DesignerStartupHook$2.run(DesignerStartupHook.java:257) at java.awt.event.InvocationEvent.dispatch(Unknown Source) at java.awt.EventQueue.dispatchEventImpl(Unknown Source) at java.awt.EventQueue.access$000(Unknown Source) at java.awt.EventQueue$3.run(Unknown Source) at java.awt.EventQueue$3.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source) at java.awt.EventQueue.dispatchEvent(Unknown Source) at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source) at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source) at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source) at java.awt.EventDispatchThread.pumpEvents(Unknown Source) at java.awt.EventDispatchThread.pumpEvents(Unknown Source) at java.awt.EventDispatchThread.run(Unknown Source) Caused by: java.lang.VerifyError: Expecting a stackmap frame at branch target 43 in method com.project.hybrid.global.ignition.hooks.IgnitionGlobalDesigner.initializeScriptManager(Lcom/inductiveautomation/ignition/common/script/ScriptManager;)V at offset 12 at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Unknown Source) at com.inductiveautomation.ignition.designer.IgnitionDesigner.loadModules(IgnitionDesigner.java:725) ... 16 more

Any place I should add that same parameter?

Never seen that before. Are you compiling this module using java 7 jdk? Do you also get this error if you compile against 6?

It’s something new to 7. I found the fix thanks to this post: stackoverflow.com/questions/7970 … in-eclipse

I was able to work around the issue by adding the -XX:-UseSplitVerifier to the Runtime Parameters in the Java Control Panel. Looking at the designer.jnlp, the tag doesn’t have the same parameters set using the wrapper.conf. I’m not sure it should, but also not sure where else to control those. If I edit the downloaded .jnlp myself, it lets me fire up the Designer, but doesn’t let me log in without getting the same error so that parameter isn’t being passed to whatever the next step is.

Looks like I spoke too soon - that fix worked on one of the four Ignition servers we’re working with. We’re running 7.4.1b906 with Java 1.7.0_03 across the board.

Have you tried compiling your module using Java 5 or 6 instead of Java 7?

Yeah, it works fine as Java 6 like is discussed in that stackoverflow link, but we’re moving to Java 7 to take advantage of new functionality in Java 7.

I just wonder if there’s a problem in the interplay between stuff compiled for 5/6 and stuff compiled for 7. Just a guess, at this point.

As of 7.4 our gateway scoped stuff is compiled against 6, and designer/client scope compiled against 5. For 7.5 we’re moving to compiling everything against 6.

From what I understand, the real root cause is an Eclipse compiler bug that skews the stackmap. The -XX:-UseSplitVerifier vm arg is just a workaround for that.

We’re still wrestling with this one. We don’t get the error bloeper mentioned with one of the four Ignition installations we’ve got setup, the other three give us the error. Using this answer, I went ahead and setup a deployment.config & deployment.properties file …deployment.system.config=file\:C\:\\Java\\deployment.properties deployment.system.config.mandatory=truedeployment.javaws.jre.0.args=-XX:-UseSplitVerifier… but that doesn’t resolve the issue.

I’m confused as to why this error occurs with one Designer and not all of them. Outside of a normal installation, we’ve done the following …


  1. Configured SSL using this procedure

  2. Within ignition.conf under Wrapper Java Properties, configured it so we’re using wrapper.java.command=%JAVA_HOME%/bin/java (and set the appropriate environment variables) [code]#********************************************************************

Wrapper Java Properties


Java Application

Locate the java binary on the system PATH:


Specify a specific java binary:

3. Like bloeper said, added wrapper.java.additional.10=-XX:-UseSplitVerifier to ignition.conf# Java Additional Parameters wrapper.java.additional.1=-XX:PermSize=64m wrapper.java.additional.2=-XX:MaxPermSize=128m wrapper.java.additional.3=-XX:+UseConcMarkSweepGC wrapper.java.additional.4=-XX:+CMSClassUnloadingEnabled wrapper.java.additional.5=-XX:+CMSPermGenSweepingEnabled wrapper.java.additional.6=-Ddata.dir=data wrapper.java.additional.7=-Dorg.apache.catalina.loader.WebappClassLoader.ENABLE_CLEAR_REFERENCES=false wrapper.java.additional.8=-Xdebug wrapper.java.additional.9=-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8000 wrapper.java.additional.10=-XX:-UseSplitVerifier
I’ve compared the bodies of two jnlp files, one from the working server and one from the broken server … both are identical outside of the obvious differences you’d expect to see. bloeper went ahead and reinstalled Ignition, no luck there.

[color=#BF0000]@Kevin.Herron[/color] We initially suspected something along those lines ourselves; however, the fact that one of the four works has made us set that suspicion aside.

One unique aspect of our module is that we’re utilizing AspectJ. bloeper is going to take AspectJ out of the picture, will let you know if that helps or not.

Are there any additional logging levels we could set that may give us some breadcrumbs to follow? … or perhaps a way to debug our Client/Designer module?


[quote=“bryan_cook”]One unique aspect of our module is that we’re utilizing AspectJ. bloeper is going to take AspectJ out of the picture, will let you know if that helps or not.[/quote]Looks like that ended up being the issue, we updated our AspectJ Development Tools to the latest developer build and the problem has been resolved.

I didn’t find any cleaner methods for having multiple installations of Java side-by-side, although I think that having one installation at 32-bit, one at 64-bit complicated things a bit more … adjusting the registry key mentioned is an acceptable fix for our development environment so I’ll tackle dealing with it elsewhere when there’s a need to.