Regarding how native libraries are included in jar files, I think the approach both for SWT and JNA is that the library will be extracted to a temporary directory where they are then accessed. I am not sure whether they have cleanup code or just rely on the operating system to clean out temporary directories, its probably the latter as it means that there could be times when the library is already extracted so saving start up time as it need not be extracted again. As an additional note for how SWT and JNA work, they will actually look for the library in a specific location before extracting the one in the jar file, this is done so if the application is being run in a restricted environment where files cannot be written to the file system then the administrator (or whoever installs it) can put the library in the required location.
Now to the point on decompiling Java class files, I haven't tried it but I am sure I have seen linux software for that purpose and I would imagine some software could get back to java source code.
Finally on the point of drivers, I just thought it would be worth allowing driver jars to be added and detected automatically in case there are embosser companies unwilling to let others distribute the files.
Michael Whapples On 07/11/10 03:00, John J. Boyer wrote:
BrailleBlaster will probably include drivers for most common embossers. There will be a combo box for the user to select the one she wants. New drivers can be added as needed. This is the approach of screen readers for Braille displays. BrailleBlaster will not have drivers for displays because they are either driven by screen readers or part of notetakers. I like to translate files using liblouisutdml and then read them in a text editor with my Elba, which has wi-fi, so I get the advantages of the big machine along with portability. It is interesting that compiled C libraries can be included in jar files. How are these libraries called? I thought they had to be installed in a specific place. Perhaps it would be possible to include liblouis and liblouisutdml in a jar file along with the Java bindings. I am actually planning to have bindings only for liblouisutdml. It will have enough functionality that BrailleBlaster need never call liblouis directly. I've tried decompiling class files. All I got was the names of publicv methods and public variables. A more detailed examination of a class file would reveal the byte code, but this is probably no easier to understand than the instructions for a physical machine. So proprietary ingormation inside a class file would probably be quite secure. John On Sat, Nov 06, 2010 at 12:28:46PM -0700, Alex Jurgensen wrote:Hi, Firstly, there is a plugin framework for Java. I'll look up the name of it, but I am heading out the dorr right now, so that will have to wait until I return. On the matter of standard API's for embossers, I use mine under the Common Unix Prinint System, A.K.A.. CUPS. I believe that there will be more drivers writen by ONCE for CUPS. I'll look up the link. Regards, Alex, On 2010-11-06, at 11:25 AM, Michael Whapples wrote:Dealing with the idea of including C/C++ code in a jar file with java bindings, yes this can be done (examples both being SWT and JNA). Now to would this protect those who want to keep things secret? The jar file itself is simply an archive file and is easily extracted. Now if a user were to do this they would find some java class files (these would be the compiled class files not the source) and a DLL or other shared library file (like for any other compiled C/C++ library). So I believe the C/C++ part would be as protected as they may be now without any java bindings. While the C/C++ code may be as secure, a standard java class file I believe can be decompiled, but this probably wouldn't reveal anything top secret as it could simply use their published C/C++ API and so would be just a mapping between two knowns. One thing this does raise in my mind, if drivers are to be done as described by John, BrailleBlaster would need some way to dynamically detect drivers which are installed (may be some sort of plugin system where the user simply has to drop a jar file in a certain directory then next time they start BrailleBlaster that new embosser will be shown). There may be some frameworks already out there to support such a plugin system. Now I do have a slight question, may be the answer is obvious to those more involved in Braille production, why don't embossers use a standard API, may be even the printer API like the tiger printer does? Michael Whapples On 6 Nov 2010, at 11:26, John J. Boyer wrote:I think the driver interface and the classes which implement it should be in a package called org.brailleblaster.drivers The interface would be called driver.java Each class implementing it would be named for the embosser which it suppoorts, for example, Tiger.java Indexd.java Everest.java As I mentioned previously, the drivers should be written in Java or converted from other languages to avoid messing around with bindings. A manufacturer might chose to protect propritary information by supplying a driver compiled into a C or C++ library. In this case it woulod be desirable for the manufacturer to also supply the Java bindings and to incorporate the JNI portion of the bindings into the library containing the driver. Is it possible to put Java code containing proprietary information into a jar file which can be used by the Java compiler and the JRE but which the user cannot see inside? That would make it much easier to get Java drivers from manufacurers. John -- John J. Boyer; President, Chief Software Developer Abilitiessoft, Inc. http://www.abilitiessoft.com Madison, Wisconsin USA Developing software for people with disabilitiesAlex Jurgensen, VoiceOver Trainer, ASquared21@xxxxxxxxxxxxxxxxx Visit us on the web at: www.vipbc.org
