Symphonious

Every time I see someone talking about the wonders of GPG I think to myself, “I should probably at least have a GPG key” and then I promptly forget about the whole deal. When Bertrand mentioned he was getting into it I went through the same thought process but this time, because of the exceptionally convenient link to an exceptionally conveniently packaged OS X version of GPG, I actually got around to doing something about it.

So my new key is:

pub  1024D/688564F1 2004-06-19 Adrian Sutton 
Primary key fingerprint: F8D7 C5AE D82E FEBA B9CA  2C0A 9C36 E079 6885 64F1

Joshua Marinacci has started writing a new XHTML renderer in Java. He’s done a pretty impressive job at getting started but I get the impression that he has no idea what he’s in for. At the moment the rendering is pretty good but the speed is absolutely awful. While you shouldn’t ever optimize too early, it’s certainly possible to optimize too late and HTML rendering is one of those areas where you suffer death by a thousand cuts. I wouldn’t be at all surprised if he has to rework large parts of his architecture to reduce the number of string comparisons to speed things up. That’s the kind of thing that you probably should think about before hand (note that I haven’t even looked at the code so he may have already considered that).

The other thing that I notice is that it doesn’t seem to support incremental layout yet so it has to wait for all the images to download before it can do anything. In an HTML editor that pretty easy to do because you’ve already got the code to update the layout quickly in response to changes but I’m not sure if there’s an easy and efficient way to do it without having to implement all that.

The big complaint I have though is that there doesn’t seem to be any licensing information which is something you really should sort out at the very start of the project so people know what they’re getting themselves in for.

Anyway, it will be interesting to see how the project goes.

Update: The project page says the license is LGPL. Oh well, guess I won’t be having anything to do with it then.

Java.Net is having conversations about removing stuff from the standard Java libraries because they’re getting too big. The comment below really stuck out at me:

Combine that with a program to remove redundant functionality (by declaring it deprecated so it gets killed 2 releases later) and you have a powerful tool to get people to stop using old stuff like Vector and StringTokenizer.”

Vector and StringTokenizer aren’t “old stuff” - they’re extremely useful classes with a specific purpose. Vector is a guaranteed thread safe implementation of List - something you can’t possibly get other than declaring that you want a Vector. To clarify that, consider the method signature public void doStuff(List items) what are the thread safe requirements on items? There’s no way to know and the default assumption would be that it doesn’t have to be thread-safe. Whereas with: public void doStuff(Vector items) the code may be less flexible now but the compiler now guarantees that you’ll get something that at least claims to be thread safe. It is still possible to extend Vector and perform non-thread safe operations but that would be a bug in the extending class because it failed to live up to the contract of the parent class.

StringTokenizer is a particularly useful class in that it provides the simplest way to break a String down into tokens. You could iterator of the characters yourself or you could use regex to do this but manually iterating is reinventing the wheel and regex are highly inefficient for doing what StringTokenizer does. Furthermore, nothing in StringTokenizer is marked as deprecated in my copy of the Java 1.4 API, nor anything in Vector.

Seriously, just because you don’t find something useful doesn’t mean it’s not useful.