jinput and Java 1.6.0_10

Engines, Libraries and Tools JInput
#1

We’re having some problems with Java 1.6.0_10-rc and Java 1.6.0_10-rc2. When running our code through Eclipse everything works fine. When running through an applet, no events are coming through. If I switch to running 1.6.0_7 or earlier JVMs, everything works fine.

I’ve tracked the problem as far as the addKeyboardEvent not getting called from the native libraries. It seems as though the events just aren’t making it into java.

When starting the application, this line is displayed both when running through Eclipse and running through the applet:
Loading: net.java.games.input.DirectAndRawInputEnvironmentPlugin

There are no exceptions in the console. My guess is that this is an issue with the release candidates for update 10 but I can’t really debug things any further than this.

Has anyone else seen this? Is there any fix that I can make in the code?

There is a test application we made here: http://beta.sharendipity.com/assets/1369/. The ‘g’ key will work because it is using Java’s key listener architecture, but pressing the other keys will not as they are going through jinput.

Thank you,

Dale

#2

Hi

I what permissions are you asking for with your applet?, I just checked and the webstart works fine with 1.6.0_10-rc, but your applet doesn’t. I looked in the java logs in C:\Documents and Settings<username>\Application Data\Sun\Java\Deployment\log and the plugin log file has some access control exceptions

java.security.AccessControlException: access denied (java.util.PropertyPermission user.home read)

unfortunatly there is no stack trace there, but the jinput plugin mechanism will try to get the user.home property IIRC.

HTH

Endolf

#3

Thank you for the response.

We are signed, so we don’t explicitly ask for any permissions. We do access the user.home system property as well because we have our own launcher that downloads jars and stores them there. I would also be surprised that the behavior with respect to system security would be different between versions of Java.

Is there any way to tell how jinput would be failing if it could not access user.home? It seems as though things are nearly identical between versions of java. In both cases, during debug I see that we have a RawKeyboard and a RawDevice that are being used. The only difference I can tell is that addKeyboardEvent in RawInputEventQueue is never getting called.

I’m curious if anyone knows of other applets that utilize jinput so that I could see if they work with this version of Java.

Thanks again,

Dale

#4

System.getSecurityManager() == null ?

#5

Hi

Due to the ‘fun’ of loading native libs from an applet, most people end up doing their own loaders. LWJGL for example has an applet loader that downloads the native libs to a temporary directory. Then it sets the library path to include the temp dir and then loads the libs.

See this file.

HTH

Endolf

#6

We do have our own loader, and we’re doing exactly what LWJGL is doing when loading the native libraries. As I mentioned, our applet runs fine in Java versions previous to 1.6 update 10, so it seems that we are doing this correctly.

Has anyone tried building an applet using jinput for keyboard input and running it under update 10? If I get time I’ll try the LWJGL code and see I can build an applet through that. I don’t have much experience with LWJGL so I don’t really know what it will take to do so though.

Dale

#7

Again: System.getSecurityManager() == null ?

Just print it to System.out

When your applet is signed, it should return null. However, when an AccessControlException is raised, I’m suspecting a SecurityManager is still installed - which would be a bug…

#8

System.out.println("security manager is null: " + (System.getSecurityManager() == null));

results in:

security manager is null: false

This is also the case with 1.6.0_07, _04, and _02 though.

#9

Surprising… apparantly my assumption I had the last couple of years, is very wrong.

#10

I was looking into LWJGL and from what I can tell they aren’t using jinput for keyboard interaction but have their own keyboard poller.

I’m kind of at a loss for what to do at this point, other than building the native libraries myself and trying to determine if they’re getting called. Is there no test that I can perform that will help me determine if anything is wrong from the Java side?

#11

LWJGL has its own input lib, which uses jinput under the hood

#12

I understand that LWJGL uses jinput. In looking through their code, it seemed that they are using their own poller for the keyboard though.

WindowsDisplay.doHandleMessage() calls handleKeyButton() which calls WindowsKeyboard.handleKey(). This stores the key state in their own buffer (key_down_buffer), which is used to populate the ByteBuffer that is passed in when WindowsKeyboard.poll() is called, and is also used in WindowsKeyboard.isKeyDown().

It seems that a LWJGLKeyboard is layered on top of this to provide a Controller interface to their own polling mechanism. The pollDevice() call here calls into the WindowsKeyboard.poll() method mentioned above through WindowsDisplay.pollKeyboard().

I’m not describing this to try to prove that I’m right. I admit completely that I could be mistaken. This thread has taken a step in the negative direction. I have an honest problem in production code that I’m trying to fix. The terse comments are dead ends that are not providing any path to a solution. The lack of support is convincing us that we will have to drop jinput if we can’t resolve this soon.

#13

Hi

You’re right about LWJGL not using JInput for keyboards, it doesn’t use it for mice either IIRC, only game controllers (joysticks, gamepads etc). I’ve been looking around at this too, and whilst I can reproduce it, I can’t explain it. I’m am still working on it though.

I’ll not get any time until next week though, the downside of doing this in my spare time.

Cheers

Endolf

#14

Right, I just ran an applet that uses JME, which uses LWJGL, and that seemed to work, so I’m going to have to dig a bit deeper, it is definitely something going wrong that is not down to the JVM security manager type things.

Endolf

#15

Thank you for the response. If there’s anything I can test on my end please let me know. I am however running through Eclipse and don’t have mingw or cygwin installed right now so it would take me some time to build the native libraries and get up to speed on that.

Regards,

Dale

#16

Hi

I’m fairly certain the natives are not even getting loaded, so I suspect that plastering the relevant jinput java code with debug is the way forward with this.

Cheers

Endolf

#17

Right,

Sorry for the delay. I’ve written a simple applet loader. It copies the jars to the a temporary place locally, then passes the property to jinput to tell it where to find the natives.

Check out a working demo here
and the source here and here.

All the jars (including the natives) are signed.

HTH

Endolf