May 03, 2006

Here's the Problem

Versioning and Classloading in Java [linuxintegrators.com]:

This is what I was talking about in a previous post about my trials and tribulations when dealing with Java classloading. It's a little vindicating to see there is a bigger problem at work here, but unless the JVM specification is changed or if there was a decent open source JVM [zdnet.com.au] I still have no work around. That sucks!

Posted by Guy at 06:17 PM | Permalink | Comments (0) | TrackBack

January 25, 2006

Portable Desktop

I guess I should write a small blurb on just what Codename:Hydrogen is, so here you go. Hydrogen is a cross between all the portable apps that are out there and Portable CE [furrygoat.com]. The concept is that Hydrogen is a portable desktop or virtual machine that you can take with you anywhere on some form of portable storage, i.e. flash drive, USB hard drive, etc.

What this brings to the table is a truly portable computing experience that doesn't rely on USB booting or running resource-intensive virtual machines. Also, it will have an encrypted virtual file system so even if it gets lost your data is reasonably well protected.

Why I thought I should make this announcement now is because eyeOS [eyeos.org] is getting some attention right now and I'm just waiting for some genius to put two and two together and say why can't I run eyeOS under Portable Firefox [portableapps.com]? Well, you probably can, but I think the capabilities are limited since eyeOS doesn't own the container [gadgetopia.com].

Posted by Guy at 03:59 PM | Permalink | Comments (0) | TrackBack

January 04, 2006

Overriding Java Classes: Part 2

I was right about haveing to use some bytecode engineering to override classes. I ended up using Apache's BCEL, which allowed me to load up a class from an InputStream, modify it, then dump the bytes for the ClassLoader to load up. It was suprisingly easy, I just had to iterate through the ConstantPool of the class and replace and instances of "java.io.File" and "java/io/File" with my override. However, I think there is a catch that I need to account for, external (or worse, user-entered data) ConstantPools and Java Reflection. Using BCEL I can catch any references for java.io.File, but I can't stop a user from trying to Class.forName("java.io.File") where the String ("java.io.File") is generated at run-time, aka after class loading. So, 90% solution, not bad.

Posted by Guy at 08:07 PM | Permalink | Comments (0) | TrackBack

January 03, 2006

Overriding Java Classes

It started simple enough, I wanted to override a default Java class (one that is contained within the java.* package) to provide enhanced functionality without clients having to rewrite their code. Could I have supplied my classepath in the -Xbootclasspath java parameter? No because I just overrode some classes, not reimplemented them. For example, I wanted to override java.io.File, which is dependent on native code. Since I didn't want to reimplement this native code I couldn't just provide another implementation of java.io.File, but needed to extend it and override the methods I wanted to change.

So what mechanism gives you the power to dictate which classes are loaded given a specific class name? That's right, the ClassLoader. All I would have to do is implement my own ClassLoader that would detect when java.io.File was being loaded and then load and return my own implementation. I figured this would work because my class extended java.io.File so it should virtually look like java.io.File and be castable to java.io.File. Unfortunately I received a ClassCirularityError when I tried this method.

As best I can determine, the ClassCircularityError happened because I tried to define my own class and maskerade it as java.io.File which made it look like my class was its own parent.

Another error I ran into was in defining the class. Once I had my class bytes loaded I tried to define my class as java.io.File. Unfortunately the Java ClassLoader that performs the actual definition (some native code) will not allow you to define a class within the java.* package (java.io.File, java.foo.bar, etc).

I think the only way to do what I want is to do some Byte Code Engineering [apache.org].

Posted by Guy at 01:20 PM | Permalink | Comments (0) | TrackBack

December 25, 2005

Data Stores

Just as a general curiosity I was wondering if seperate data stores would be applicable in today's computing architectures? For example, processors sometimes would have a separate i- and d-cache standing for instruction and data. The i-cache would be for processor instructions, i.e. application logic while the d-cache would be for data, or the stuff that got manipulated as the processors instructions went along. Generally i-cache could be considered relatively read only, while the d-cache was quite random access read/write. My question is if this architecture can prove valid on a larger scale, specifically a read only and read-write split architecture for general purpose computing?

I would see this implemented as a read-only data store containing applications and support libraries while a separate data store would be an analogous d-cache. Just curious.

Posted by Guy at 07:54 PM | Permalink | Comments (0) | TrackBack