Technology: September 2003 Archives

I’ve been thinking a bit about autoboxing, a new feature slated for Java 1.5 which is due out at the end of the year. This is basically an automatic conversion between primitive types (int, double, etc.) and their object wrappers (Integer, Double, etc.).

As far as I can see, this is just a bad idea, and the only reason it’s being considered is because C# has it. Sure, Java makes you jump though hoops when you’re using the object wrappers and there’s definitely an argument for changing something about how this all works, but autoboxing is just the wrong solution in every way. It hides what the language is doing for you in a misleading way.

Just one point: look at the overheads in Java involving object creation, better than they used to be for sure, but do we really want to add more?

Surely a far better solution would be to change the language and remove the primitive types altogether? Than it would also make more sense to allow the standard arithmentic operators to work with BigDecimal and BigInteger (maybe even adding a Complex class) as well. Remember, this is just the written expression of a program, a sufficiently smart compiler should be able to optimize this away based on context, this was supposed to be one of the main advantages of JIT compilation.

In theory, there should be no overhead to using the object wrappers in running code, after the first JIT run this hypothetical code:

for (Integer i = new Integer(0); i < 10; ++)
    // Do something here...

Should be no less efficient than:

for (int i = 0; i < 10; ++i)
    // Do something here...

Note that we could allow the standard operators to work on these ‘blessed’ classes, much the same way as the addition operator works for String concatenation today.

Miguel de Icaza writes about binary encoding for XML (Omri’s page was unavailable, so I can’t comment on that).

This is already in widespread usage, a la WBXML. It’s a pretty successful standard, given that it targets low bandwidth mobile phones they’ve obviously encoded for size, a fact made easier that it also targets a specific schema. I.e. it’s not a generic XML encoding.

Omri’s thesis is that there are multiple things that you might want to optimize for: size, parsing speed and overhead for generating the data and that it is not possible to define a file format that satisfies all of those different needs.

Well, I thought we had already done this with XML. The fact is, you can already use your own favourite encoding. If I want to make it easy to parse then I can use UTF32, if I want to be ‘more standard’ I can use UTF8. I’m not sure about this (I need to check the spec) but in theory you should be able to use any encoding that you want to, as long as all parties agree on it.

I’ve just written my first .net program! (Using mono) It seems very similar to Java, I’m going to grab a book and have a play with it some more over the next few days.

Of source, I’m really trying to learn Lisp, but since the books I bought have been stranded in Vienna it seems like I may have to wait a few weeks for that.

From an article in the New York times:

The security flaws Mr. Kean’s team is scrambling to catch and patch are part of the larger problem with software today. The programs that people rely on for all manner of tasks —- from writing reports and sending e-mail, to monitoring factory floors and managing electric power grids —- are becoming increasingly large, complex and, all but inevitably, filled with bugs.

I just don’t agree about the inevitability of it, software is filled with bugs because people like it that way.

I’m serious.

If people wanted software that was virtually bug free they could have it. Right now. It’s a matter of cost though. In real mission critical systems (e.g. flight computers, life support systems, the controls for nuclear reactors, etc.) I would expect to find a very low level of bugs. I’d also expect to have to pay somewhat more than $500 for it.