Several problems with Island and Java Plugin Examples in Hydra

(Carsten Bartholomae) #1

i have installed the following versions on my machine:

  • Elements
  • Hydra
  • Java

After installing the new hydra, i wanted to try out the examples:

Visual Plugin - Hydra Java -
Compiling succeeds, copying the jar files to the .NET mixed mode sample, starting the c#host:
::the Javaplugin fires the message com.hydra.sample.visualplugin.jar, failed to load (Cannot find installation path)
Compiling and running the java examples from Elements work as expected

Hydra Island Plugin
Compiling the plugin fails with the message
::Error 44 no member ToPCwstr on type string
Than i always get the Warning 56, Hydra.fx compiled with older version, do not use with this on
(the message is not shown here completely, but i think you know what i am refering to)


(marc hoffman) #2

This one is safe to ignore, and will be fixed with the next update. The “problem” is that Hydra on our CI system was still build using an older version of Elements, and v10 warns about that because in rare cares (which do not apply to the code in Hydra) there can be incompatibilities when using a v9-compiled library with v10. The next release (and the next beta) will have that fixed, but it’s a purely cosmetic issue.

My colleagues from the Hydra team will known more about the other two issues in detail — but the first one sounds to be that Hydra cannot find the local Java runtime (which is odd, as I assume since you were able to build the plugin, the Elements compile found not ok — or did you manually have to specify its path?)

(antonk) #3

The Cannot find Java installation path error means that both conditions are met:

a) JAVA_HOME environment variable is not set
b) SOFTWARE\JavaSoft\Java Runtime Environment registry key was not found

The most common reason on this error (besides JVM not installed at all) as that bitness of installed JVM doesn’t match the bithess of the Java host app.

In other words if the host runs as x86 (and please remember that Any CPU-compiled apps usually run as x86) and one has installed JVM x64 - then the host app won’t be able to utilize this JVM installation.

And one more caveat you need to remember about - path to the plugin .jar should NOT contain # char, otherwise Java class loader won’t be able to load the plugin .jar.

(Carsten Bartholomae) #4

a) yes, JAVA_Home environemnt was not set by the oracle installer
b) Registry Key exists and the Elements Java Examples run successfully except the Hydra Plugin

(antonk) #5

Which exactly registry key does exist?

Is it HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment or HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\JavaSoft\Java Runtime Environment ?

Former one is used by x64 applications, latter one - by x86 apps. C# host application is a x86 one. You can check this by adding this code somewhere:

var ptrSize = System.Runtime.InteropServices.Marshal.SizeOf(typeof(System.IntPtr));
MessageBox.Show("Runtime mode: " + ((ptrSize == 4) ? "x86" : "x64"));

(marc hoffman) #6

Note that “anycpu” .NET host apps will run as 64bit, on a 64-bit system, not as 32bit (unless “Prefers32Bit” is set, of course).

FTR, I checked and EBuild looks at the following three registry keys to find the Java Runtime when building. It’ll happily use 32 or 64 bit, whatever it finds there — iow it’ll be less picky than Hydra has to be.

SOFTWARE\Wow6432Node\JavaSoft\Java Runtime Environment
SOFTWARE\JavaSoft\Java Runtime Environment (32-bit registry)
SOFTWARE\JavaSoft\Java Runtime Environment (64-bit registry)

(Carsten Bartholomae) #7

its: HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment

not: HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment

(Carsten Bartholomae) #8

Not: HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\JavaSoft\Java Runtime Environment

(marc hoffman) #9

Well, that depends WOW6432Node is where a 64-bit process sees the 32-bit Registry (Welcome to the mess that is 64-bit Windows). So EBuild checks that so that even when running in 64-bit, it will see the 32-buit Java runtime, too.

(antonk) #10

This means you have x64 version of JVM installed. Given the mixed mode sample host is explicitly marked as x86 it explains why it cannot use this JVM installation.

You need to either install x86 version of JVM or change the host project properties to build as x64.

(Carsten Bartholomae) #11

OK, after compiling c#host for 64 Bit, all worked as expected.
Cas can be closed