Does JInput have the concept of versions? There seems to be only a “latest” download.
I found JInput has a Version class with a getVersion method.
I found that unplugging a controller, then plugging it back in caused it to not be recognized any more. I looked at JInput’s code to see what it would take to reload the controller list each call to getControllers rather than just the first time. Thar be dragons in the JInput code! Yeesh. I’ll just live with it.
I wouldn’t rely on that to tell you more than major version changes, which has only happened once. I really ought to get around to having a nice version control system (and I don’t mean cvs), but I’ve yet to find one better than the build timestamp or svn revision.
There is still an outstanding request for having controller listeners working. There is a listener interface for this. At the moment, if a controller is unplugged the existing controller object in JInput gets closed, any new controllers are ignored. I know of one project that did handle this, but they can’t release the code publicly :(. Maybe it’s time I gave up hoping for other contributors and just did it myself.
It has to handle native code on at least 3 platforms, what did you expect!!! 
Endolf
P.S. Sorry for the delay in responce, spent a couple of days under a duvet with man flu.
Thanks endolf. I was starting to feel very alone! Hope you are feeling better!
My problem is that the only JInput download is simple labeled “latest”. Maybe the build system could write a file named “version” into the root of the zip? I like all JAR files in my project to be named name-version.jar so I can keep things straight in the future.
Controller listeners work fine.
It would be ideal to support unplugging and replugging controllers, and also plugging in a new controller while the app is running. When JInput is first asked to get a list of controllers, it goes out and finds them all. When asked subsequent times, it just uses the existing list. Couldn’t we just go out and find them all every time? Maybe have a new method for doing that?
Heh. 
Well, I expect there to be some nastiness hiding somewhere. JInput does hide this from the developer, but does so with a complex API that is hard to use. Slick puts a thin veneer over JInput to make it easier to use, AFAIK without losing functionality, so it is possible to have a more friendly API.
I don’t like some of the logging. At startup it dumps some stuff. When poll fails it dumps some stuff. Not sure if it is the JDK logging or System.out.
Man, java.net sucks. It is so slow! Also every java.net project seems to look inactive for some reason.
Mostly, enough to be back at work and coding
There are nightly builds that have the build date on them. Hudons builds this every night.
Agreed, thats what the controller listeners were originally intended for.
We could, it’s slow, and there are some clearup issues to resolve ,like people still having references to controllers from the last poll, those old controller/component objects do not always need clearing, we might have the same list, so then the old objects should work still. Thats my plan. Maybe I ought to get on and do this
Yup, it’s not the simplest, but it is very flexible. The idea of JInput was always as a building block, not much more than a wrapper over the native layer. We could have had a JInput utils project that tried some other things.
I recently did a couple of logging updates. Hopefully the logging is all done in JDK logging, which means it can at least be turned off
I’m with you on this one!!!
Endolf
Ok, JInput builds under hudson now stick the build number in the version string, so any build from 200/12/12 or newer should have a build string like
2.0.1-b374
HTH
Endolf