Source for 1-Wire Java-USB Project

Posted by Scott Hughes Sun, 06 Nov 2005 06:06:00 GMT

I’ve finally gotten around to creating a source tarball for the work I did to get the Public Domain Kit support files for libUSB running under the 1-Wire API for Java. 80% of the work here was figuring out what to do, so you’ll find there isn’t a lot of code to glue them together. It would be pretty easy, for example, to swap out the PDK files for libUSB with the DS1410E link-level files for Linux. Then you could have parallel port support using the 1-Wire API for Java under Linux as well as the USB port.

The Makefile is geared towards Mac OSX. Everything else, including the C source in the ‘native’ folder, is platform independent and should compile everywhere libUSB does. Using Sun’s reference on how to build JNI libraries for the various platforms, you should be able to modify the Makefile to support your platform. If you have any suggestions for improving the build process, especially if you can help make it a cross-platform Makefile, then please let me know.

PDKAdapterUSB.tar.gz (444kb)

Posted in ,  | Tags , , , ,  | 1 comment

JSR-277 Might Fix Java

Posted by Scott Hughes Fri, 26 Aug 2005 13:25:00 GMT

Thanks to Ted Neward, I just read about this interesting new Java Specification Request: JSR 277

The specification of the Java Module System should define an infrastructure that addresses the above issues. Its components are likely to include:
  1. A distribution format (i.e., a Java module) and its metadata as a unit of delivery for packaging collections of Java code and related resources. The metadata would contain information about a module, the resources within the module, and its dependencies upon other modules. The metadata would also include an export list to restrict resources from being exposed outside the module unintentionally. The metadata may allow subset of exposed resources to be used by other modules selectively.
  2. A versioning scheme that defines how a module declares its own version as well its versioned dependencies upon other modules.
  3. A repository for storing and retrieving modules on the machine with versioning and namespaces isolation support.
  4. Runtime support in the application launcher and class loaders for the discovery, loading, and integrity checking of modules.
  5. A set of support tools, including packaging tools as well as repository tools to support module installation and removal.
We also expect the Java Module System to expose the public J2SE APIs as a virtual module in order to prevent unwanted usage of the private APIs in the implementation.

Modules with metadata about their dependencies sounds like just what the doctor ordered. It’s crazy that Java has such a large and pro-active userbase, yet it is so slow in catching up to the fledgling .NET. Item #1 and #2 should’ve been implemented a long time ago, and Sun knows it. I agree with Ted as well when he says:

About the only thing I *wish* we could do that’s out-of-scope to the JSR is to fix the javac compiler to cease emitting .class files directly, but instead consider .class files to be the moral equivalent of C/C++-compiled .obj files, and automagically do that final step and turn it into a .jar file right out of the box. (Out of curiosity, is there anybody out there who doesn’t immediately jar up your .class files?)

I know I immediately jar mine up, except in the cases where I’m prototyping with a single .class. If Javac auto-jarred, that wouldn’t bother me in that case.

Posted in ,  | Tags ,  | no comments