Quote:
Originally Posted by arikfunke
Ok, this is probably naive, but if JBPatch was written and compiled for K4 in Java 1.4 and K3 also uses Java 1.4, what is going to have to be adjusted? (Apart from the patches and UI.)
Early in this post you wrote that JBPatch would produce no effect if installed on K3... Clearly compiling is not the issue.
|
There are two issues:
First: the UI parts will not work, because the K3 does *not* include the common Swing classes, like JButton. Instead, Amazon decided to use their own replacements, like "KButton". But as said, this is not so important yet, and I really urge you to ignore the UI stuff for the time being.
Second: I simply don't know if the method to "hook" into the system is the same. As said, I only have a K5 at this moment, and I can only describe how it works on this system. The rest of this post will try to make this clear.
So, to start off at the very beginning...
How does JBPatch really work?
It works by modifying the binary code of class files, right before it is actually interpreted as bytecode. For an easier-to-understand example: suppose that the Kindle could only display text files. JBPatch would be the part that can modify text files after they are loaded, but before they are displayed. So, it could, for example, modify all occurences of "red" to return "blue" instead. When loading a file that contains information about Moscow, the text would then suddenly read something like "The Blue Square (Russian: Красная площадь, tr. Krásnaja Plóščaď; IPA: [ˈkrasnəjə ˈploɕːətʲ]) is a city square in Moscow, Russia".
Essentially, every patch does just this: it replaces some known parts of what it was given by something else. There could be another patch which would replace all mentions of "Square" by "Triangle"... well, you get the idea. Of course, it's slightly more technical, but yeah, that actually is the idea of how JBPatch works.
Why can JBPatch work at all?
This is really rather tough to explain, and it can't be done in one or two paragraphs here. Essentially, it has to do with the way that classes are loaded in Java, and with the fact that ClassLoaders are organized hierarchically. You can find all the required information by asking your favorite search engine about "classloader hierarchy java" or similar.
But in short, it's all about getting control (as early as possible) over the class loading procedure. In other words: the JBPatch ClassLoader (called PatchingClassLoader) will try to take control over all class loading, as soon as it is loaded (instantiated) itself.
How does the PatchingClassLoader take control?
This one is relatively easy. By using the
Java Reflection API, the PatchingClassLoader can "hook" in between its own actual (parent) ClassLoader, and that ClassLoader's real parent ClassLoader (To make this clear: yes, it is "parasitically" hooking in between its own "parent" and "grandparent" classloader!) . This, in turn, means that all future classes which are requested to be loaded by the
parent ClassLoader will now go through the PatchingClassLoader. And that's exactly what we want - and we need to take that control as early as possible.
How does JBPatch make sure that it gets control early enough?
This is really the crucial thing: getting control early enough. And it's also exactly the thing why I can't promise anything for JBPatch on devices where I have not tested it myself.
Because it doesn't make sense to list things that don't work... I will list the things that DO work.
On the Kindle Touch:
- the entire system is based on
Concierge OSGi.
-
/opt/amazon/ebook/bin/init.xargs contains the line "
-Dch.ethz.iks.concierge.strictStartup=true"
- so just adding
-istart jbpatch.jar as the first line is enough. That jar file must of course contain the relevant OSGi Bundle manifest entries, but that's easy.
- the jbpatch.jar file will be loaded as the very first file, and it will install the PatchingClassLoader as soon as it is loaded. This, in turn, allows JBPatch to control all subsequent class loading.
So, to summarize it all: to make JBPatch work on a different Firmware, you will need to (a) either verify that the method also works on that device, or (b) find another method to make it work on that device.
Even in case it doesn't lead to anything at all... I hope that the above information was informative.
