[brailleblaster] Re: More on Embosser Drivers
- From: "John J. Boyer" <johnjboyer@xxxxxxxxxxxxx>
- To: brailleblaster@xxxxxxxxxxxxx
- Date: Sat, 6 Nov 2010 23:49:51 -0500
I've actually used Linux software to decompile classes. The name of the
software escapes me at the minute. One could go0 further and disassemble
the byte code. I've tried that with some machine code. The reault was
instructions with the opcodes and generated symbolic addresses, which of
course didn't give much information about thge original source.
Reconstructing the source would be a hand operation from then on. Also,
if the code were optimized, as it usually is for libraries, that would
make reconnstructing the source all the more difficult. I suspect the
same is true for Java bytye code.
You would have to be pretty determined to get any proprietary
information out of a Java class.
John
On Sun, Nov 07, 2010 at 03:50:17AM +0000, Michael Whapples wrote:
> 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 disabilities
> >>>>
> >>>>
> >>>
> >>Alex Jurgensen,
> >>VoiceOver Trainer,
> >>ASquared21@xxxxxxxxxxxxxxxxx
> >>
> >>Visit us on the web at: www.vipbc.org
> >>
>
>
--
My websites:
GodTouches Digital Ministry, Inc. http://www.godtouches.org
Abilitiessoft, Inc. http://www.abilitiessoft.com
Location: Madison, WI, USA
Other related posts:
