Java Coding advice meets Hagakure meets a badly translated taiwanese Users Manual

09.10.2006 @ 07.06, Posted in Java

Taged with ,

Look what just came into my inbox:

design problems In their native real OO design principles learned by those at speaking the language (and too short) to spend environment. In other
You’re not and experience of others, support in your own code. You’ll easily counter with your With Design Patterns, Facade, Proxy, and Factory that you can hold your
someone struggles of patterns with others what to expect–a visually-rich you don’t want to the next time you’re

“secret language” a design paddle pattern. want to see how you get to take In their native design problems, and better
Singleton isn’t as simple as it
to use them (and when Best of all, in a way that won’t format designed for the way and experience of others, environment. In other

the next time you’re so that you can spend you have. You know of Design Patterns so Design Patterns, you’ll avoid how patterns are
real OO design principles your brain works. Using the same software on your team.
of Design Patterns so design problems
or on the real relationship

so that you can spend

But you don’t just alone. At any given moment, You want to learn the and Adapter. With Head First
You’re not and experience of others,
you don’t want to

a book, you want

environment. In other you don’t want to design problems about inheritance might
the “Trading Spaces” show. applications. You
the “Trading Spaces” show.

Decorator is something from

principles will help (and too short) to spend support in your own code. of patterns with others
put you to sleep! We think “secret language” how patterns are
you want to learn the of the best practices Head First book, you know

Most importantly, else. Something more the next time you’re at speaking the language to do instead). You want science, and learning theory, You’ll easily counter with your
when to use them, how
you have. You know a book, you want
of patterns with others
someone struggles the latest research in
Java’s built-in pattern

who’ve faced the deep understanding of why the same software reinvent the wheel matter–why to use them,
so you look to Design Design Patterns, you’ll avoid , and how to exploit same problems.
In a way that lets you put support in your own code. you don’t want to environment. In other real OO design principles
words, in real world
same problems.
look “in the wild”. used in the Java API the embarrassment of thinking texts. If you’ve read a to know how they

sounds, how the Factory Singleton isn’t as simple as it Most importantly,

to use them (and when be wrong (and what
so that you can spend (and too short) to spend own with your co-worker on your team.
you want to learn the or on the real relationship
you get to take

you have. You know

The sound advice burried into this little gem needs a lot of contemplation before its wisdom is fully absorbed.

Taking a full Swing at sanity

05.05.2006 @ 15.18, Posted in Java

Taged with , ,

If somebody would actually have the nerve to compile a list of all technologies that most likely have been created simply to annoy people, I’d like to suggest Swing to be somewhere in there. Maybe Number 1 or 2, but definitely in the Top 5.
And I’m not even talking about the LayoutManager from Hell (also known as GridBoxLayout to its more intimate enemies), but just those little quirks that make working with Swing so difficult.
It took me the better part of two afternoons to figure out the answer to this question:

What do you do when you want to replace a component in a Window with another one?

Answer 1
Use component.repaint() on the parent of the changed component. After all, the component should be repainted as soon as possible after this call. Of course, this is a rhetorical entry, because I have to build up some drama.
Answer 2
Use component.invalidate() on the parent of the changed component.
This should also invalidate all parents of the component, so everyone should repaint itself. Sounds fine, but it’s also not working.
Answer 3
Both of them. Use repaint() and invalidate() liberally in the method that changes the component. Change the sequence of the calls, mix and shake it. Set this or that to null, just in case.

As you might have guessed by now, after I arrived at answer 3 (which, of course, is not the correct answer), I was rather furious. More or less by accident I discovered
Answer 4
Use component.revalidate().

As everyone will have guessed by now, Answer 4 is correct. I don’t know why, but I’m sure there is a very plausible explanation for it.

Ceterum censeo LayoutManager esse delendam!

Where am I? Operating System detection with Java

24.04.2006 @ 10.53, Posted in Java

Taged with ,

Cross-platform or not, sometimes it’s important to know on which operating system your program is running on (because you need to know where your jar file is, for example).
Maybe not the nicest way to do it, but working:

private static final String MAC_ID = "Mac";
private static final String WINDOWS_ID = "Windows";

private String OSIdentifier;
private boolean isMac;
private boolean isWindows;
private boolean isUnix;

private String dataPath;
private String configPath;
private String jarPath;

private void init()
{
	OSIdentifier = System.getProperty("os.name");

	if (OSIdentifier.indexOf(MAC_ID) > -1)
	{
		isMac = true;
		dataPath = System.getProperty("user.home") + "/Library/Application Support/myProject/";
		jarPath = "./Contents/Resources/Java/";

	}
	else if (OSIdentifier.indexOf(WINDOWS_ID) > -1)
	{
		isWindows = true;
		dataPath = System.getProperty("user.home") + "\\myProject\\";
		jarPath = ".\\";
	}
	else
	{
		isUnix = true;
		dataPath = System.getProperty("user.home") + "/.myProject/";
		jarPath = "./";
	}

}

Add getters and setters, and you’re good to go. Of course, you might further differentiate between different Unix systems according to your needs.

Automatically adding version information into a Java Manifest file with Ant

23.04.2006 @ 13.38, Posted in Java

Taged with , ,

Version information is important for applications and libraries alike. Somebody using your jar file (be it an application, a library or a part of a larger framework) should be able to tell which version of your program they are using. Equally, giving the users that information should be as little effort for the developer as possible. Some library authors solve this by creating versions of their libraries with the version information in the filename (for example, avalon-excalibur-vm14-20020705.jar, which happened to linger around in a lib directory I have open in my shell, so I used as an example), but this approach is not working very well for applications. Besides, using “versioned” filenames has its own problems (no drop-in replacement of newer versions because the classpath needs to be changed).

Another way to give the users informations about what version of a jar file they are using is to store it in the jar file itself, in a file called the manifest, which is present in all jar files.

This little tutorial shows you how to automatically generate the manifest for your jar file and access the information later on in your Java program (for example, in an “About” dialog). The insertion of the version information will be part of your automated build-process, and your Java application will read this information directly from the jar file. All you need is a text file containing the version name (or number). If you’re working with the subversion SCM, you can also easily add the current revision number to the jar file.

The main advantage of this approach is that version information (or any other information, for that matter) is stored in one place, and set at the time the jar file is created. No need for additional configuration files or hardcoded version identifiers in your classfiles.

Read the rest of this entry »

It never ceases to impress me …

01.01.2006 @ 15.37, Posted in Java

Recently I rewrote the java class that generates the links on the subnet website to work around a smaller problem: I had to make sure that the links I construct never have two slashes inside them, which could happen if someone wanted to create a link with, for example, “mypath/” and “/myPage”.

After I fixed that, I wondered what would be the fastest way to concatinate two Strings and make sure that the result doesn’t have a double-slash at the boundary. (The class in question gets called between 10 and 50 times per page, so speed actually does matter a little.)

Strings in Java are a subject of heated debates, and it is considered general wisdom that StringBuffers are much faster than String objects when concatinating. But how much faster exactly?

Read the rest of this entry »