Thread Rating:
  • 1 Votes - 3 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Java bindings now available
04-08-2011, 12:14 PM
Post: #1
Java bindings now available
Java bindings are now available for ohNet, allowing development of client code in Java for desktop or Android.

Build using make ohNetDll ohNetJavaAll

API docs are available at http://www.openhome.org/build/nightly/docs/Java/

Simon
Find all posts by this user
05-08-2011, 08:47 AM
Post: #2
RE: Java bindings now available
(04-08-2011 12:14 PM)simonc Wrote:  Java bindings are now available for ohNet, allowing development of client code in Java for desktop or Android.

Build using make ohNetDll ohNetJavaAll

API docs are available at http://www.openhome.org/build/nightly/docs/Java/

Simon

Thanks, that's great news!

I tried building this and found a problem in the ohNet.mak file. Around lines 42-49 there are a number of hardcoded references to C:\Program Files (x86)\Java\jdk1.6.0_26 which should be replaced by $(JAVA_HOME).

After making this change I was able to complete the build and run the test org.openhome.net.controlpoint.tests.TestCpDeviceDv sucessfully. I also tried running the test org.openhome.net.device.tests.TestDvDevice but this failed with the following error:

TestDvDeviceJava - starting
iDeviceList size: 0
Exception in thread "main" java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
at java.util.ArrayList.RangeCheck(Unknown Source)
at java.util.ArrayList.get(Unknown Source)
at org.openhome.net.device.tests.TestDvDevice.<init>(TestDvDevice.java:41)
at org.openhome.net.device.tests.TestDvDevice.main(TestDvDevice.java:100)

Is there something else that I need to do to make this test run correctly?

Simon
Find all posts by this user
05-08-2011, 10:28 AM
Post: #3
RE: Java bindings now available
(05-08-2011 08:47 AM)simoncn Wrote:  Thanks, that's great news!

I tried building this and found a problem in the ohNet.mak file. Around lines 42-49 there are a number of hardcoded references to C:\Program Files (x86)\Java\jdk1.6.0_26 which should be replaced by $(JAVA_HOME).

Thanks for letting us know. This is now fixed internally so will make it onto GitHub in the next few days.


(05-08-2011 08:47 AM)simoncn Wrote:  After making this change I was able to complete the build and run the test org.openhome.net.controlpoint.tests.TestCpDeviceDv sucessfully. I also tried running the test org.openhome.net.device.tests.TestDvDevice but this failed with the following error:

TestDvDeviceJava - starting
iDeviceList size: 0
Exception in thread "main" java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
at java.util.ArrayList.RangeCheck(Unknown Source)
at java.util.ArrayList.get(Unknown Source)
at org.openhome.net.device.tests.TestDvDevice.<init>(TestDvDevice.java:41)
at org.openhome.net.device.tests.TestDvDevice.main(TestDvDevice.java:100)

Is there something else that I need to do to make this test run correctly?

You shouldn't need to do anything else; the test works without further configuration for us.

The test uses the device stack to publish a device then uses the control point stack to discover the device and test invoking actions and receiving evented updates. The failure happens when the control point portion of the test fails to discover the device that should have been published. So your problem could be in either device or control point stack...

To help us start figure this out, could you try running the Java TestProxy (org.openhome.net.controlpoint.tests.TestProxy) program please? If you are developing on the subnet you use for your DS, you should see it discovered and brief tests run against it. (Don't worry, the tests don't affect the state of your DS!)

If TestProxy runs correctly, your problems are likely to be with ohNet's device stack. If TestProxy also fails, ohNet's control point stack would be suspect. Either way, further, more targeted debugging would then be required.

Alternatively, we could try to replicate your dev environment to allow us to replicate and investigate the bug you see. If you'd prefer this approach can I check which version of Java and host machine you're using? We've been using 32-bit Java on Windows 7 (64-bit).
Find all posts by this user
05-08-2011, 08:49 PM
Post: #4
RE: Java bindings now available
(05-08-2011 10:28 AM)simonc Wrote:  To help us start figure this out, could you try running the Java TestProxy (org.openhome.net.controlpoint.tests.TestProxy) program please? If you are developing on the subnet you use for your DS, you should see it discovered and brief tests run against it. (Don't worry, the tests don't affect the state of your DS!)

I tried running TestProxy and it crashed in native code inside ohNet.dll during a call to the native method CpDeviceListCreateUpnpServiceType. My x86 assembler skills are slightly rusty but it shouldn't be beyond me to get more detailed information about what's going on in the native code at the point of the crash.

(05-08-2011 10:28 AM)simonc Wrote:  Alternatively, we could try to replicate your dev environment to allow us to replicate and investigate the bug you see. If you'd prefer this approach can I check which version of Java and host machine you're using? We've been using 32-bit Java on Windows 7 (64-bit).

The only difference I can see is that you're on Windows 7 (64-bit) and I'm on Windows 7 (32-bit). My Java version is 1.6.0_07 which is rather old these days but I'd be surprised if that's the cause.

I just reran TestDvDevice to see if I could dig further into that failure, and to my surprise it seems to be working now. I'm going to reboot and retry the tests to see if I get the TestDvDevice failure again. I'll post more news here when I have it.
Find all posts by this user
07-08-2011, 05:24 PM
Post: #5
RE: Java bindings now available
(05-08-2011 08:49 PM)simoncn Wrote:  I tried running TestProxy and it crashed in native code inside ohNet.dll during a call to the native method CpDeviceListCreateUpnpServiceType. My x86 assembler skills are slightly rusty but it shouldn't be beyond me to get more detailed information about what's going on in the native code at the point of the crash.

I have found the cause of this problem. The getIpv4Int() method in Library.java doesn't handle the byte array to signed int conversion correctly. Bytes are signed in Java, and are automatically converted to signed int before any arithmetic operation, so the statement
Code:
int ipv4Addr = ipv4Bytes[0];
produces a negative number when applied to my IP address 192.168.0.9. The same applies to the later expression
Code:
ipv4Bytes[i] << i*8

To fix this, I have changed the code in this method to the following:

Code:
byte[] ipv4Bytes = aAddress.getAddress();
int ipv4Addr = ipv4Bytes[0] & 0xff;

for (int i = 1; i < 4; i++) {
    ipv4Addr |= (ipv4Bytes[i] & 0xff) << i*8;
}
        
return ipv4Addr;

(05-08-2011 08:49 PM)simoncn Wrote:  I just reran TestDvDevice to see if I could dig further into that failure, and to my surprise it seems to be working now. I'm going to reboot and retry the tests to see if I get the TestDvDevice failure again. I'll post more news here when I have it.

I haven't been able to reproduce this problem again. Very mysterious!
Find all posts by this user
08-08-2011, 11:10 AM
Post: #6
RE: Java bindings now available
(07-08-2011 05:24 PM)simoncn Wrote:  
(05-08-2011 08:49 PM)simoncn Wrote:  I tried running TestProxy and it crashed in native code inside ohNet.dll during a call to the native method CpDeviceListCreateUpnpServiceType. My x86 assembler skills are slightly rusty but it shouldn't be beyond me to get more detailed information about what's going on in the native code at the point of the crash.

I have found the cause of this problem. The getIpv4Int() method in Library.java doesn't handle the byte array to signed int conversion correctly. Bytes are signed in Java, and are automatically converted to signed int before any arithmetic operation, so the statement
Code:
int ipv4Addr = ipv4Bytes[0];
produces a negative number when applied to my IP address 192.168.0.9. The same applies to the later expression
Code:
ipv4Bytes[i] << i*8

To fix this, I have changed the code in this method to the following:

Code:
byte[] ipv4Bytes = aAddress.getAddress();
int ipv4Addr = ipv4Bytes[0] & 0xff;

for (int i = 1; i < 4; i++) {
    ipv4Addr |= (ipv4Bytes[i] & 0xff) << i*8;
}
        
return ipv4Addr;

Oops! This problem became apparent to us when tried on systems attached to a different network in an attempt to reproduce the TestDvDevice issue. Thanks for digging into the code to diagnose the problem and provide this correction. The change has been applied internally and should make its way out to GitHub within the next few days.

(07-08-2011 05:24 PM)simoncn Wrote:  
(05-08-2011 08:49 PM)simoncn Wrote:  I just reran TestDvDevice to see if I could dig further into that failure, and to my surprise it seems to be working now. I'm going to reboot and retry the tests to see if I get the TestDvDevice failure again. I'll post more news here when I have it.

I haven't been able to reproduce this problem again. Very mysterious!

Sadly, we have not yet been able to reproduce this problem either. The only way we've been able to mimic the behaviour is by manually disabling the internal device added/removed callbacks which would result in the Java bindings never being informed that a device has been added.

A possible reason for the occurrence could be the callback reference not being initialised/allocated properly on a heavily loaded machine, which would result in the catastrophic failure of no devices ever appearing to be detected.

However, this is just a best guess at a reasonable potential cause until we are able to reproduce it.
Find all posts by this user
08-08-2011, 02:36 PM
Post: #7
RE: Java bindings now available
(08-08-2011 11:10 AM)greggh Wrote:  Sadly, we have not yet been able to reproduce this problem either. The only way we've been able to mimic the behaviour is by manually disabling the internal device added/removed callbacks which would result in the Java bindings never being informed that a device has been added.

A possible reason for the occurrence could be the callback reference not being initialised/allocated properly on a heavily loaded machine, which would result in the catastrophic failure of no devices ever appearing to be detected.

However, this is just a best guess at a reasonable potential cause until we are able to reproduce it.

This may be a useful clue to the cause. I saw the failure when I ran this test immediately after completing a full build, which might well have consumed a lot of resource. It's also possible that I could have had other programs running at the same time (not sure about that). Also, I might have been running my laptop on battery power with the processor speed set to Very Low. I'll see if I can recreate these conditions again.
Find all posts by this user
24-08-2011, 08:59 AM
Post: #8
RE: Java bindings now available
(08-08-2011 02:36 PM)simoncn Wrote:  
(08-08-2011 11:10 AM)greggh Wrote:  Sadly, we have not yet been able to reproduce this problem either. The only way we've been able to mimic the behaviour is by manually disabling the internal device added/removed callbacks which would result in the Java bindings never being informed that a device has been added.

A possible reason for the occurrence could be the callback reference not being initialised/allocated properly on a heavily loaded machine, which would result in the catastrophic failure of no devices ever appearing to be detected.

However, this is just a best guess at a reasonable potential cause until we are able to reproduce it.

This may be a useful clue to the cause. I saw the failure when I ran this test immediately after completing a full build, which might well have consumed a lot of resource. It's also possible that I could have had other programs running at the same time (not sure about that). Also, I might have been running my laptop on battery power with the processor speed set to Very Low. I'll see if I can recreate these conditions again.

I saw this again recently. I tried increasing the length of the wait for Msearch replies from 1 second to 3 seconds, and the device was always detected. With the delay at 1 second it would work about 50% of the time.
Find all posts by this user
24-08-2011, 01:48 PM
Post: #9
RE: Java bindings now available
(24-08-2011 08:59 AM)simoncn Wrote:  I saw this again recently. I tried increasing the length of the wait for Msearch replies from 1 second to 3 seconds, and the device was always detected. With the delay at 1 second it would work about 50% of the time.

Thanks for the feedback. Some of our other device stack tests cope with unusually slow/loaded hosts by waiting up to 30s to find their target device. We'll update the Java tests to do likewise.
Find all posts by this user
24-08-2011, 02:20 PM
Post: #10
RE: Java bindings now available
TestDvDevice has now been updated to wait up to 30s for replies. This change should make it upstream within a couple of days.
Find all posts by this user


Forum Jump: