ok... this might require a little more explanation as to why I'm asking this at all. I'm specifically looking for a solution for the Kindle Touch here, but this is a general question mostly independent from the actual device.
Some of the already existing hacks require patches to (existing) Java classes. The ones I know about are:
- GUI Launcher by Yifan Lu
- Localization (more specifically, the locale_enabler stuff)
- Font Hack (more specifically, the "Kindlet Jailbreak")
There are generally two ways to achieve such a replacement. The obvious one is to simply modify the existing jar. The less obvious, but more elegant and preferred one (at least in this context) is to put them in a different jar, making sure that it appears before the original jar in the classpath. This works because when a class is initially looked up, the classpath is scanned "linearly", and the first occurrence wins.
The second alternative is preferred in this context because it entirely avoids messing with Amazons proprietary files. It will (generally) not affect framework updates, it can be easily undone, etc.
For the first two of the abovementioned hacks, the second method worked, because the classes that required changes were inside /opt/amazon/ebook/booklet/. The "patches" went into /opt/amazon/ebook/lib/ instead, and thus were always loaded before the originals (see below).
For the third hack, it didn't work. But for this particular case (the affected jar is the "simple_json" one), this isn't too much of a problem either, because simple_json is released under the Apache Software license, so it can be freely distributed in the hack installer and uninstaller.
However now, I'm running into a problem. The reason is that in order to solve this problem/request
, a class inside /opt/amazon/ebook/lib/ReaderSDK-impl.jar has to be changed. Publically distributing this file in an installer/uninstaller is extremely questionable from a legal point of view. And of course, I want to use the "elegant" way.
So after all this introduction, here are some relevant lines from /etc/upstart/framework (a lot of the file is stripped away here):
JAR_LIST=$(find $EHOME/lib $EHOME/booklet /usr/local/ebook/lib -name \*.jar 2>/dev/null)
CPATH=$(echo $JAR_LIST | sed -e 's/ \+/:/g')
OPTS="$HEAP $JOPTS $IHPROF $DEBUG $AOPTS"
$JHOME/bin/cvm $OPTS $APP 2>&1 | logger -p local2.debug
The "problem" here is the order of the classpath, or more specifically, the output of "find". Any file in $EHOME/lib is guaranteed to appear before the files in $EHOME/booklet, but the order of files inside the same directory is essentially random.
A simple approach would of course be to edit the file directly, inserting a few sort commands. But that would again go against my goal of being as unintrusive as possible by only *adding* stuff (which can be easily removed) instead of *modifying* stuff.
One way that I thought of, and that would probably work, is to create the file /usr/local/bin/find, which would act as a wrapper to /usr/bin/find, taking some further action on particular arguments.
Can anyone think of another, nicer, alternative?
... a bit like "sudoku for freaks"