Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Shameless plug for Pure Java HIDAPI #1

Closed
nyholku opened this issue Oct 20, 2014 · 7 comments
Closed

Shameless plug for Pure Java HIDAPI #1

nyholku opened this issue Oct 20, 2014 · 7 comments
Milestone

Comments

@nyholku
Copy link

nyholku commented Oct 20, 2014

Hi,

sorry to abuse the issue system and hope you don't mind but I felt that some small group of hid4java users might be interested in a different take on the subject matter and I could not figure out how to reach them.

With the help of reading the HIDAPI code I've managed to put together a Pure Java alternative that requires no native libraries when deployed and no C-tool chain to develop:

You can find it here:

https://github.com/nyholku/purejavahidapi

This is not really an alternative to signal11/HIDAPI as this is Jave or actually JVM only where as HIDAPI is C-API/ABI.

br Kusti

@nyholku nyholku closed this as completed Oct 20, 2014
@gary-rowe gary-rowe modified the milestone: Discussion Oct 20, 2014
@gary-rowe
Copy link
Owner

No worries. hid4java is very new (less than a few weeks old at present) and born from a particular need that I had to integrate support for a Trezor device into my primary project MultiBit HD.

If I may offer up some suggestions that may help your project get some traction:

  • change your package structure to reflect your domain name (e.g. org.purejavahidapi)
  • remove the Eclipse .classpath, .project files using .gitignore (see this article)
  • introduce Maven/Gradle as your build system and work towards uploading it to Maven Central - this will greatly improve your project's visibility.

If I could ask you make a correction to your README.md file: hid4java doesn't install the native libraries, it reads them directly out of the JAR using JNA. The actual problem is that these have to be compiled from the signal11/hidapi native libraries for each native platform which can be a pain but this is my responsibility as maintainer of hid4java and downstream users don't need to concern themselves.

@nyholku
Copy link
Author

nyholku commented Oct 20, 2014

Thanks for bearing with me!

And thanks for the tips, I will consider them.

I'm not great fan of domain name based package names, while I see where it is coming from company/organisation based domains are poor cause companies/organisations change names, merge, collapse, die and may at some point have nothing to do with the library/software they originally wrote. Purchasing a project specific domain is better but it is an extra expense not well suited to non-profict projects … at the end of the day name conflicts are rare, any sane software developer will anyway try to come up with a unique name and today with google that is pretty easy to ensure so the good old 90's domain name trick seems like an overkill. Just my opinion though.

I know about .gitignore, but what is the problem with having those Eclipse files in the project? I know they do not provide much useable functionality and do not always work/transport well outside their original context but in the past I've found that some percentage of noobies find them comforting so lowering the threshold to try a project out.

I don't think I will use Maven myself in a hurry but I am going to provide a .bom and precompiled jars like I do for my PureJavaComm project.

Thanks for noticing and sorry for miss-presenting the native lib aspect of hid4java, I'll fix that ASAP.

Thanks for the links to your Bitcoin related stuff … I find all that very intriguing!

@nyholku
Copy link
Author

nyholku commented Oct 20, 2014

Fixed the README, hope it is now ok.

@gary-rowe
Copy link
Owner

Just checked over the revised README.md and it's all good.

There's no particular problem with the .classpath files etc it's just that they often contain information specific your own environment that could confuse newbies if, say, their JVM is named differently. Also not everyone uses Eclipse.

Of course, that's just my opinion.

Best of luck with your project, I'll add myself as a watcher and drop a star on you for innovation :-)

@nyholku
Copy link
Author

nyholku commented Oct 20, 2014

Good!

your are right about the JVM ref in the .classpath file, I may have reconsider this as especially with just JNA in the classpath the value of the .classpath file is minimal. I was going by the experience with some day job related projects with thousands of classes where setting up Eclipse is a chore and why I them around in the version control.

Thanks for the star and let me return the courtesy and good luck with all your projects too,

@ceakins
Copy link

ceakins commented Jun 19, 2015

I really strongly urge you to mavenize it. Newbies will have an easier time importing it.

@nyholku
Copy link
Author

nyholku commented Jun 19, 2015

Feel free to contribute a 'pom', I am not up to speed with maven...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants