Updated: 11/24/2003; 3:06:08 PM.
Code
        

Monday, November 24, 2003

Another Axion Bug

One of my co-workers was working with Axion this week, and the database was mangling all the non-ascii characters in her insert statements. Axion was only set up to accept unicode correctly via bind variables; regular statements did not work. I changed the javaCC parser to use character streams instead of byte streams, and everything seems fine now. If you've had Unicode problems in the past, the HEAD branch of Axion should be an improvement.


2:48:24 PM    comment []

Thursday, November 06, 2003

De nada

I was browsing through some referers, and I happened across this blog entry. Yes, the Latka software is very polite, but I wonder if Kurt realized the REAL reason for that particular phrase.


9:28:16 AM    comment []

Tuesday, October 21, 2003

Dipping into Axion

I did some Axion debugging this week. Rod and I discovered that only SQL inserts are utilizing indices. Deletes and updates are performing table scans every time. Today I checked in a fix for simple delete statements, which produced a significant boost. A series of SQL deletes which took 638 seconds to execute before now takes less than 4 seconds. We're working on more complete index support for updates and deletes, so if you use Axion you may want to keep an eye on the repository activity for a while.


5:03:41 PM    comment []

Friday, May 02, 2003

Continuous integration

Rod has started a series on our Continuous Integration environment [1] [2]. I've also jotted down notes on our CI process for my weblog, but Rod is doing a superlative job, so I'll leave it to the master.

Just one comment on the series so far. When putting together a Continuous Integration environment, you want build failures to evoke one of two feelings:

1. guilt [...] 3 : a feeling of culpability for offenses

2. shame [...] 2 : a condition of humiliating disgrace or disrepute : IGNOMINY

Source: http://www.m-w.com

For most people, shame works better.


2:04:01 PM    comment []

JDK 1.4, now including the kitchen sink

James: Be careful of JDK 1.4

No doubt.  However, James left out my favorite JDK 1.4 "feature", the built-in XML parser.  How convenient!  Unless of course, you want to upgrade or modify it in any way.  Then you have to resort to the incredibly awkward Endorsed Standards Override Mechanism, which is the least hosting-friendly addition to Java in recent memory.  While the Servlet APIs have in recent years made substantial improvements to the organization of their classloaders, the JDK seems to want to unravel this by providing the least amount of modularity possible.

After making the very painful transition to JDK 1.4 a few months ago, I found myself wishing for an LE version of that JDK.  As far as I am concerned, the less APIs the better.  I could do without JAXP, without SAX (and thanks very much for grabbing other organization's APIs as well as your own), without Xerces, and even without JDBC.  I am capable of putting jars in the classpath on my own; I don't need Sun's help for that.  Or at the very least, repackage the classes that don't belong to you! Throw me a bone here, Scott!

Making all those APIs modular does limit Sun's ability to intermingle them, but I think it's worth the tradeoff.  Otherwise, I dread all the new APIs I'll have to work around for 1.5.


1:43:14 PM    comment []

Encoding, schmencoding

I was writing a character encoding FAQ for our company's Wiki when I came across something in the JAXP javadocs that has always puzzled me:

StreamResult Javadocs:  Normally, a stream should be used rather than a reader, so that the transformer may use instructions contained in the transformation instructions to control the encoding.

JAXP has a similar warning for StreamSource as well.

Why is using character streams so ill-advised? The character encoding behaviour that XSL parsers should use seems pretty straightforward to me; everything should be keyed off of the output format specified in the XSLT template. If a character produced by the transformation is allowed by the desired encoding, output it (based on the user's preference) either as a single Java character or as a numeric entity. If the character is unsupported by the encoding, output it as a numeric entity. Isn't this is reasonable way to implement encoding?

I guess the point of the warning in the JAXP docs is that if you are given an arbitrary Writer, you can't be sure if it is backed by a StringBuffer or an underlying OutputStream. If it's a stream, it's certainly possible that the Writer will receive characters that the character-to-byte conversion of the OutputStream does not support.

However, it seems just as likely that, if you give the transformation an arbitrary OutputStream, the bytes produced will be subsequently misinterpreted by any code that converts them back into characters. In the simple case of performing an XSL transformation to a file, an OutputStream would definitely be safer. However if you were, for example, chaining the result of one transformation to another, using an OutputStream seems like an unncessary point of potential misconfiguration. I think JAXP's documentation is very poorly worded in this regard; the implication that OutputStreams are somehow safer seems false.

And on the topic of encoding, there is nothing convenient about the "convenience" classes java.io.FileReader and java.io.FileWriter. If a principal goal of Java's is platform-independence, then those two classes are failures. They really should have made those classes use UTF-8 encoding rather than the platform's default encoding. At work I see lots of encoding problems that are caused by developers who use those classes.


1:15:59 PM    comment []

Thursday, March 27, 2003

Jelly needs to get back on track...

I've been so tied up with work and annoying personal stuff (nothing serious, just other people's screw-ups) that I've neglected Jelly. :( We need to finish up some RCs and get our releases out the door!


12:38:16 PM    comment []

Eclipse 2.1 tomorrow!

I have been looking forward to 2.1 for some time now. Some of my coworkers have been using some of the beta versions, and there are some great new refactoring features. Also, 2.1 will notify you of unused imports, which is definitely a welcome improvement.

Rod turned me onto Eclipse this year. I've tried other Java-aware IDEs, and this is the first I've used that strikes a good balance between speed, feature-richness, and customizibility. I've been slowly converting my coworkers, mainly by providing GUI extensions that automatically convert our ant script properties to an Eclipse project (heavily cribbed from the "eclipse" task in Maven, but integrated directly into the GUI). Soon they will all join the cult. :)


12:28:39 PM    comment []

Thursday, March 20, 2003

Codehaus

Codehaus: Codehaus differentiates itself from other similar efforts in several ways. Unlike the Apache Software Foundation's Jakarta Project, Codehaus places a firm priority on the production of useful code, and less on "community-building" exercises such as voting, committee-forming and proposal-writing. Each project is provided autonomy to organize as it wishes and to address its own customer concerns and requirements directly.

Interesting if cryptic. The implication that Apache does not place a priority on writing code is clearly false, but hopefully that is just poor wording. I'm interested to know how projects have the "autonomy" to organize how they see fit without calling votes or writing proposal. Or is the intention that developers can vote and write proposals, but that there will be no higher authority like the Apache board that can intervene (similar to Tigris)? Sounds like Codehaus projects could either be fun, fluid and open, or just enlightened dictatorships. "Hey you, stop talking and write some code! I make all the decisions around here!" I guess we'll see.


12:40:21 PM    comment []

© Copyright 2003 Morgan Delagrange.
 
November 2003
Sun Mon Tue Wed Thu Fri Sat
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30            
Oct   Dec

Code

Click here to visit the Radio UserLand website.

Subscribe to "Code" in Radio UserLand.

Click to see the XML version of this web page.

Click here to send an email to the editor of this weblog.