How Random Babbling Becomes Corporate Policy (t3knomanser) wrote,
How Random Babbling Becomes Corporate Policy
t3knomanser

In other, really geeky news...

The Java class loader is shockingly powerful. First though, my current app (which is almost done, or at least the core is).

For awhile, I've been wanting a toolbar that could run programmable applets, so I made one. As of the moment it's a toolbar that starts in the top-left corner of the screen and can collapse down to just a small button. At some point, I'll worry about making it configurable and repositionable, but for now it'll do. That's detail crap.

Here's the idea. Someone goes and writes their own java class which inherits from my KickerApplet class. Their class can do _anything at all_, though by convention, it's going to be displaying a 64x64 pixel tile in the bar. That tile itself can be used to do anything. In fact, the applet itself is a standalone java application for the most part (I might secure them someday as well, so they can't take over your computer, but then again, that's what I intend to use them for- do stuff on my computer).

Right now, I've got an applet that'll display the results from my Game of Life app I released ages ago, and a few dummy applets that just let me test the logic.

Now, to make this all work, here's what goes on behind the scenes. The KickerApplet designer puts the JAR of my application in his classpath, and builds his applet. Then, the resulting class file gets put into a folder someplace, and renamed .kapp. An entry also gets put in a datafile, so my panel can find it (unimplemented as of yet- I'm just hardcoding). Now, my KickerPanel goes through that datafile and provides the user with a list of available applets. The user chooses some, and adds them.

Now, here's the cool part. I wrote a custom class loader, which circumvents java's built in stuff, and allows me to read the bytecode file, turn it into a Class object, and in turn, create a new instance of that class object. This means that installing a new KickerApplet is as simple as adding an entry to the datafile, and rebuilding the in-program cache of said file. You won't even have to restart the kicker.

There are some problems to this. The java security prevents you from using internal classes, which make writing KickerApplets that handle mouse events, etc. a bit of a pain in the arse. Harder than it needs to be, for sure.

The other bug I'm trying to hammer out is my AppletState class. Everytime you load a new KickerApplet, the AppletState class writes that information to disk, so when you reload, it can reread that information, and the applets you configured last time will be there. For some reason though, it bails when I try and reload that.

At any rate, I hope to have a release with a few KickerApplets and a KickerApplet API doc, so people can write their own. Not that you care. Fuckers.
Subscribe

  • Strange Things People Say About Me (to my face)

    Recently, I've been at the center of a trend. That trend is complete strangers asking me "Are you ____?" A quick summary. For example: Are you…

  • Writer's Block: If I could find my way

    -10,000 years, at minimum. Tomorrow is always better than today, especially when you can't fact-check.

  • Bob Morlang

    When I was working at Tri-Mount, we had these camp trucks. They were army surplus, and while they could take a beating, they only sort of worked. And…

  • Post a new comment

    Error

    Comments allowed for friends only

    Anonymous comments are disabled in this journal

    default userpic

    Your IP address will be recorded 

  • 1 comment