JBPatch

[ixtab]

Originally Posted by arikfunke

I am working on compiling JBPatch for kindle 3.

Now that is great news! - thank you!

Originally Posted by arikfunke

Apart from some minor syntax changes everything was looking quite good. Now however I have stumbled on a more substantial problem.

Kindle 3 uses Java 1.3 which does not have the class "java.util.LinkedHashMap" which is used in configurableSettings.java. Unfortunately my java skills are insufficient to rewrite this modules.

Can anybody help with this to help extend JBPatch to Kindle 3?

I can't really help with testing it, because I don't have a K3, but I'll do my best to give some advice. After all, I guess I'm the only person who knows JBPatch in and out

So let's start with the advice right now:
- ignore the UI-specific parts for the time being. Just focus on the classes in the jbpatch and jbpatch.bootstrap packages, and try to get these to compile and run. The UI is very "optimized" for the Kindle Touch anyway, so it needs to be rewritten from scratch for the K3.
- ignore all patches as well. Every patch is device-specific by definition, and the K3 would need an entirely new set of patches anyway.
- concerning the LinkedHashMap thing: just use any other Map implementation. (for instance: "extends HashMap" or even better: "extends TreeMap".) The LinkedHashMap is only used because it also provides consistent ordering. (TreeMap would provide the same)

Thanks again for even trying to port this to the K3. A few other people had asked about other device support, but they all quickly ran away when they heard about the effort that it will be.

[ixtab]

Originally Posted by knc1

This is for a K3?
Try using version 1.4 rather than 1.3

That's true as well. Actually, I'm pretty sure that the K3 also uses Java 1.4, not Java 1.3. (I did own a K3 some time ago, and I did some experiments with it. And from what I remember, it was 1.4 as well).

EDIT: Confirmed. Kindle 3 uses Java 1.4 as well, so no need to jump through any hoops here. However, you *will* need to adapt all the Swing-specific parts, because the K3 support almost none of the Swing classes (JButton, JCheckbox, etc.)

But as said, I suggest to completely ignore the UI parts for the time being. The JBPatch core will also happily work without any UI (as it did before, actually. All of the UI stuff was only introduced with version 2, and is really only a convenience thing, because it's easier for end users). It is entirely thinkable to have a JBPatch version (and patches) which do not need any UI. That would make things a lot easier to start with, when porting it to the K3.

[knc1]

@ixtab : The 5.2 image file has rsasign jar in it but I have not checked if they are (yet) using signed *.jar files.

Q: Would dealing with signed *.jar files hinder JBpatch?

PS: Firmware 5.2 is Java 1.6 now.

[ixtab]

Originally Posted by knc1

@ixtab : The 5.2 image file has rsasign jar in it but I have not checked if they are (yet) using signed *.jar files.

Q: Would dealing with signed *.jar files hinder JBpatch?

That really depends on how they implemented it. But... given that the Kindlet jailbreak still works on the Paperwhites, there doesn't seem to be a major difference.

Originally Posted by knc1

PS: Firmware 5.2 is Java 1.6 now.

Oh, that's cool! That'll make development much easier for new projects (generics really are a bliss!).

JBPatch will remain 1.4 though... not a big deal anyway. The core and UI are pretty much done, so the new stuff really only concerns new patches. And these (mostly) have to deal with bytecode anyway.

[ixtab]

Originally Posted by knc1

Q: Would dealing with signed *.jar files hinder JBpatch?

One more answer to that question: no, it shouldn't. IIRC, the signature verification is done before the patching - in other words, the file is determined to be correctly signed, and only patched afterwards. This is from memory about how I implemented the class loader, so I'm only 80% sure at this time - I might still be wrong. Time will tell

[knc1]

Originally Posted by ixtab

One more answer to that question: no, it shouldn't. IIRC, the signature verification is done before the patching - in other words, the file is determined to be correctly signed, and only patched afterwards. This is from memory about how I implemented the class loader, so I'm only 80% sure at this time - I might still be wrong. Time will tell

On a non-Java branch of this local subject - - -
In Linux, both the loader and the elf file format supports "signed binaries" for both library and executable files.
(USA - NSA might be the only people who use that "feature".)

Duh...
I am not going to post a "howto" on that, let lab126 learn it somewhere else.

[arikfunke]

Originally Posted by ixtab

EDIT: Confirmed. Kindle 3 uses Java 1.4 as well, so no need to jump through any hoops here.

How did you determine this? The version information of java on K3 claims:

[root@kindle root]# java -fullversion
Sun CDC Java Client phoneme_advanced-Core-1.3-b03 A2Z-SOW2-CR2-20100225-b01 (built on 01/Sep/2012 14:24 PDT)

Am I using the wrong option flag to determine the java version?

[twobob]

http://cowlark.com/kindle/getting-started.html
says it's 1.4 as well.

[root@kindle us]# java -showversion
Product: Sun CDC Java Client phoneme_advanced-Core-1.3-b03 A2Z-SOW2-CR2-20100225-b01 (built on 01/Sep/2012 14:24 PDT)
Profile: Personal Basis Profile (Security Optional Package) 1.1.2 (Specification 1.1.2)
JVM: phoneme_advanced-Core-1.3-b03 A2Z-SOW2-CR2-20100225-b01 (mixed mode)

he uses a mod to make it use some of the 1.5 stuff..

...

Retroweaver integration, allowing Java 1.5 language features (generics! autoboxing! foreach loops!) on the Kindle's 1.4 JVM.

com.cowlark.eventbus, a port of GWT's excellent event bus system, and a wrapper around the Kindle lifecycle APIs so that we don't need to worry about what thread they're calling into our application from.

...

links:
http://retroweaver.sourceforge.net/
http://docs.oracle.com/javame/config...217/index.html
https://kdk-javadocs.s3.amazonaws.com/1.3/index.html

HTH

[arikfunke]

Originally Posted by twobob

[root@kindle us]# java -showversion
Product: Sun CDC Java Client phoneme_advanced-Core-1.3-b03 A2Z-SOW2-CR2-20100225-b01 (built on 01/Sep/2012 14:24 PDT)
Profile: Personal Basis Profile (Security Optional Package) 1.1.2 (Specification 1.1.2)
JVM: phoneme_advanced-Core-1.3-b03 A2Z-SOW2-CR2-20100225-b01 (mixed mode)

Ok. So K3 uses java 1.4 even if the version reported by the java executable reports 1.3? Confusing... but will make compiling for K3 much easier.

Many thanks for pointing this out!

[ixtab]

Originally Posted by arikfunke

How did you determine this? The version information of java on K3 claims:

[root@kindle root]# java -fullversion
Sun CDC Java Client phoneme_advanced-Core-1.3-b03 A2Z-SOW2-CR2-20100225-b01 (built on 01/Sep/2012 14:24 PDT)

Am I using the wrong option flag to determine the java version?

How I determined this? From my own memory/experience, and from what everybody else says online

Just go with Java 1.4, it works.

PS: That version string you are getting may simply be using some other versioning scheme, which isn't related to the JVM version. If it really was JVM 1.3 only, it would refuse to load classes which were compiled for JVM 1.4 - which it doesn't (but it does refuse to load classes which were compiled for Java 5).

[twobob]

would retroweaver make your life easier across all devices then Ixtab?

*yes, I have no idea what I'm talking about*

seems like generics etc. support on all devices would be a good thing for developers looking to port patches across devices (assuming this thing ever hits a 3)

Or as I say is this a stupid question? (I.e you won't use it, you use something else, etc.)

[ixtab]

Originally Posted by twobob

he uses a mod to make it use some of the 1.5 stuff..

links:
http://retroweaver.sourceforge.net/

Just FYI: I'm personally (sometimes) using retrotranslator. For instance, the Font Hack sources are actually written using Java 6 constructs, then "retrotranslated" to 1.4.

http://stackoverflow.com/questions/1...es-to-java-1-4

I didn't go with any of these "retro" tools for JBPatch, because some JBPatch parts are extremely low-level, so I felt more confident using the actual version that is running on the device, instead of relying on some automagic tools. But other than that, I've already used retrotranslator for business-critical applications, and it works great.

[knc1]

For instance:
./usr/java/lib/sunrsasign.jar in META_INF/MANIFEST.MF

Manifest-Version: 1.0 
Created-By: 1.3.1_19 (Sun Microsystems Inc.)

./opt/amazon/ebook/booklet/MobiReader.jar in META_INF/MANIFEST.MF

Manifest-Version: 1.0 
Ant-Version: Apache Ant 1.7.0 
Created-By: Blackdown-1.4.2-02 (Blackdown Java-Linux Team) 
Main-Class: com.amazon.ebook.booklet.reader.Reader

I.E: Mixed version code is "factory stock".

I suppose one could script a look-up of all the *.jar files and "vote" on which answer is correct, or ;
Use the version known to work (1.4).

[ixtab]

Originally Posted by knc1

For instance:
./usr/java/lib/sunrsasign.jar in META_INF/MANIFEST.MF

Manifest-Version: 1.0 
Created-By: 1.3.1_19 (Sun Microsystems Inc.)

./opt/amazon/ebook/booklet/MobiReader.jar in META_INF/MANIFEST.MF

Manifest-Version: 1.0 
Ant-Version: Apache Ant 1.7.0 
Created-By: Blackdown-1.4.2-02 (Blackdown Java-Linux Team) 
Main-Class: com.amazon.ebook.booklet.reader.Reader

I.E: Mixed version code is "factory stock".

I suppose one could script a look-up of all the *.jar files and "vote" on which answer is correct, or ;
Use the version known to work (1.4).

I think you're getting something terribly wrong here.

First, you're only looking at metadata. The "Created-by" entry is purely informational, and could be set to "My favorite pink plush toy, version 2007". It doesn't matter. The only thing that actually matters is the class version embedded in the class file - specifically the major_version and minor_version entries.

Second, the JVM is (of course) downward-compatible. So a Java 7 JVM can of course run bytecode that was produced for a 1.0 JVM. The whole point of the JVM (and its versions) is that new JVM versions (may) include new opcodes, but they will never remove existing ones.

The JVM is exactly what its name says: a virtual machine. And for those who are interested, there is a very clear Specification.

I'm digressing, I know... but: in fact, the JVM and the Java language are not as tightly coupled as many people think. It is by no means a necessity to write code for the JVM in the Java language. (If you're more at home in the Windows world, compare it to the .NET framework - this is exactly the same concept as the JVM).

There are lots of other languages out there which can compile to Java Bytecode - maybe the most famous example is Scala.

Heck, even I wrote a compiler for a simple language, which produced (actually working! yay! ) Bytecode, in the "Compilers" course at University.

[twobob]

huh. well Ixtab I did not know most of that.
Did know a little about the "Jitting" comparable aspects of course from my .net work.

Can totally see where knc and the OP were coming from.
It's a VERY odd way to advertise the version (or fail to advertise in this case)

Bonkers.