There are many reasons to hate Java, it's like shooting fish in a barrel.
But in the last weeks I found some more, half of them aren't even fault of the
standard API (the usual culprit), and I want to share my frustration with the
rest of the world.
It has no unsigned types
Say you want to manage binary protocols, files, etc. You'd like to
store and retrieve bytes and words in machine format, of course, but
you'll have a hard time finding the right value because you can't have
a goddamn unsigned byte!
So if you want —for example— to read the length of a string
which can be bigger than 127 as a single byte, you'll end doing some
aberration like this:
byte strl = foo_retrieve_byte();
int real_strl = strl < 0 ? 256 + strl : strl;
You can't inherit constructors
Maybe there's something in the OOP dogma that mandates this, but if I want
to define a new exception that does nothing, but allows me to differentiate a
custom class of errors, I don't want to explicitly write dummy constructors
instead of writing an empty class —which is simpler and cleaner—
and have the four standard exception constructors for free. So, you'll have to
do this:
public class FooException extends BarException
public FooException() super();
public FooException(String s) super(s);
public FooException(Throwable t) super(t);
public FooException(String s, Throwable t) super(s, t);
Instead of this:
public class FooException extends BarException
You can't declare destructors
Say you've coded a nifty jdbc wrapper that automates most of the boring
stuff, like automatically freeing the connection to the connection pool when
there was an exception thrown, logs errors and maybe queries, handles
auto-commit settings, etc. In the simple case, you'd create an instance, do
some work, and then close the connection; if there was an SQL exception, you
little class will take care of it and re-throw.
BUT, if in the middle of your work in the calling code, you have an
unrelated exception, you need to catch it or you'll leak connections, because
the wrapper class doesn't have a way of handling this, even if the object gets
garbage collected! In the end, I had to write tons of times the same stupid
code:
try
j = JdbcWrapper.new(foo);
j.doSelect(bar);
unrelatedObject.unrelatedMethod();
j.doUpdate(baz);
finally
j.close();
You don't have a sane way of controlling the terminal
Most of the time, when dealing with web applications, you won't need this.
But when you're doing some serious stuff, you might need to write a CLI
application (oh, noes!); and then do some stupid thing like asking the console
to stop echoing characters so you can ask for a password. You'd think that the
smart guys that designed Java would have devised an portable library to handle this trivial
task, but no! Guess what I found when looking at a way of doing this? Some
idiot at SUN
recommending (
and many dummies following) a background thread that spits backspaces
faster than the user can write!
Of course, SUN will tell you that using Strings is insecure for storing
passwords, because they cannot be wiped out like byte arrays. But they fail to
mention something as basic as not showing the fucking password in the first
place, or something as important as wiping the object after using it: you can't
lock memory from Java, so you risk that it could end in some slack in the
swap file.
No, you can't leave stdin/stdout/stderr fscking alone!
When dealing with the previous problem, you say fuck portability and just
call
stty -echo to do the job. Well, you'll find a little
surprise!
Even if you don't ask for the process' reader/writer streams, the Runtime
class will pipe(2) and dup(2) your child process' standard streams. With this
excellent approach you cannot have a child process output stuff to the user,
nor even errors; you cannot allow the child process access the tty (stty
obviously can't do shit with a piped stdin).
And there's no fucking way to tell it to stop crippling your
standard streams!
The only solution I could find was a very ugly shell hack:
Process p = Runtime.getRuntime().exec(
new String[] "sh", "-c", "stty echo > /dev/tty < /dev/tty 2>&1"
);
No, you can't handle signals
After doing the previous hack, you find that if you interrupt your process
while waiting for user input, your console will remain in
noecho
state. So the obvious thing is to catch
SIGINT and friends and
call stty again to restore the console. HA! You will find that there's no
standard way of doing that, and if you really need it, you have to resort to
undocumented
com.sun.* classes which aren't even guaranteed to be
present in every JVM.
My solution was to set up a shutdown hook, which solved this problem, but
would not solve other very common problems that are solved usually with signal
handlers.
Tags: Planet Lugfi, Planet Debian
I Just released NBD 2.9.10. It had been upcoming for a while already,
with a few interesting patches being applied. In addition, some bugfixes
were applied to subversion, and some more interesting things had
happened. Really, a release was getting overdue. Sometimes life just
intervenes.
Anyway, apart from the upstream release, I of course also did a
Debian update of these packages, which also contains some changes that
had been pending for a while. Combined, the changelog mentions five
different bugs of which none are l10n bugs, which is a record (there had
been 5-bug uploads before, but those did include l10n bugs). On top of
that, I closed some other outstanding bugs which really had been closed
a while back, but either I forgot to close the bug, or I forgot that
there even was a bug in the first place.
I should stop slacking so much.
While preparing this upload, it occurred to me that nbd has come a
long way since I got involved with it back in 2001. The original
nbd-server that Pavel Macheck had written did work well, but it was a
bit of a hack; it did not fork() upon startup or anything similar, so
starting it was a pain. It could only serve one device at a time. It was
not documented. It had no concept of a configuration file. The code,
frankly, was also bit of a mess; it was written on a hack night, and not
much design had gone into it.
I guess it was no surprise, then, that no single distribution had a
package for nbd at the time. I only packaged it because I actually had
some use for nbd; at the time, I'd just bought quickstep, my first
functional m68k machine, and had installed Debian on its 250MB hard
disk. However, running a buildd on that machine proved problematic, to
say the least; with so little disk space, you could hardly boot Debian,
and due to speed and clock skew issues, NFS was not an option. So I went
with NBD, which worked great. After a while, quickstep got a bigger hard
disk (it has an 18G disk today), so diskspace was less of an issue at
that point; but, well, I'd been maintaining it already, and that was
fun, so I didn't think of giving up.
When Pavel lost interest in nbd back in 2003, he gave maintenance of
the kernel bits to Paul Clements, and maintenance of the userspace bits
to me. I promptly went ahead with what I thought should have been done
already, but felt reluctant to do at the time to suggest that:
refactoring the code, adding features, etc. Today, nbd-server
does support all of the above things of which I mentioned it
was lacking; and, probably as a result of that, apart from Debian, there
are now packages of nbd in, at least, SuSE, Fedora, Gentoo, uClibc, and
FreeBSD (the latter obviously only containing the server).
Well—the fact that LTSP uses it might have something to do with
it, too ;-)
That's not to say there's nothing left to be done, but I'm quite
happy about how far we've come. Really.
First of all, you can't do All Fool's Day pranks on global web sites because of time zones: if you do, you'll be pranking either early or late somewhere and so you're the fool. Now, I've been a bit quiet recently because I've been moving dozens of Wordpress blogs over to one 
The usability experts of Ubuntu have finally started to handle the single
most mentioned usability issue with Linux: the top level directory names.Quoting Finn C. Tional from the Ubuntu Usability Group:
Exim has the habit of trying to find out about its host names and IP addresses when it starts up. This has, in the
past, been an issue for the Debian packages, since a Debian system might be on a dial-on-demand modem line with
expensive costs and thus should not do unnecessary DNS lookup when the MTA is started.
This article tries to describe the issue and which countermeasures debian took, and asks for tips how to solve this in
the case of IPv6, where our past measures unfortunately do not directly apply.
I’d like to solicit opinions from people who are more experienced than me with Unix, the local resolver library
including /etc/hosts and /etc/nsswitch.conf, DNS, and - especially - the customs that apply on a system running IPv6.
To avoid the extra DNS lookups, the Exim packages have a Debconf option to configure exim for “minimal DNS
usage”, which hardcodes the hostname into Exim’s configuration at package configuration time. This was
necessary since - without this option - exim looks up its own host name in the DNS even when a completely local
operation is invoked.
In some cases, exim still looks up its IP address when a listening daemon starts up. This is why the Debian installer
configures 127.0.1.1 (not 127.0.0.1) for the local hostname on installation, yielding /etc/hosts files like
Slow sunday afternoon? Choose a 
Since yesterday I am through with 
OK, been quiet for a few days, at least on the blog, but in accordance with typical behaviour (for me at least) a quiet blog means a lot of things going on elsewhere. The smallest was a fix for 
Currently, 1.14.17 is in experimental but I've installed it on my system for testing purposes so that I can complete emdebian-tools 1.0.0:
I switched from 
Today's edition of 