User Tools

Site Tools


info:java

Java notes

JVM Languages

Resources

I haven't seriously used Java in a while, so these may not be the best available, or may be out of date.

java.ext.dirs

java -Djava.ext.dirs=<path> can apparently add paths for Java to search for JAR files. I've seen some discourse that indicates that you should use the -classpath option instead, listing JARs individually.

Ref: http://java.sun.com/javase/6/docs/technotes/guides/extensions/spec.html

getResource()

When using getClass().getResource(String name) to get, for instance, an image, put the images under the src folder, and call it like this:

getClass().getResource("/jgrit/gui/icons/folder_picture.png")

Note the initial slash. The path of the image is src/jgrit/gui/icons/folder_picture.png.

Doing it this way allows it to work both when running from a JAR and when not (e.g. from Eclipse).

Wrong background color for some L&F

Possibly only an issue on Windows. I read something similar about Dabo, the 3-tier application framework for Python.

To fix the issue, add a single JPanel to the frame, and add everything else to it. The JPanel gets the correct color, while the bare JFrame does not.

Qt Jambi (as an alternative to Swing)

I came across this article, which looks like a nice introduction to using Qt in Java: http://www.javaworld.com/javaworld/jw-08-2007/jw-08-qtjambi.html

Debugging with System.out.println()

The following is an archived blog post: Debugging with System.out.println()

Java and Eclipse 26 May 2007 01:38 pm

When designing unit tests, I try to write small tests. Test that are at a low enough level to make a straight-forward job of getting the test to pass. However, there are occasions when a test doesn’t pass for some odd reason and I want to debug.

The disadvantage with IDE debuggers is that they are heavyweight things that take a fair amount of concentration: step-into, step-over, step-into…. step-into, step-over. It’s enough to make you want to get up from your seat and do something else.

To my mind, an easier approach is just to add System.out.println() statements in your code. But you can only do this if the following are true:

  1. You can run an individual test over and over again
  2. The test in question only exercises a small amount of code (is a proper unit test).

The advantage to System.out.println() statements is that you can pose your ‘what is this parameter’s value here?’ and ‘when is this line executed?’ questions in a form that persists until you have found the problem.

Then you just remove those System.out.println() statements, right?

Well, as any developer knows, this doesn’t happen often enough. When developers can’t be bothered to search-and-destroy such statements they lead to ‘console clutter’, a smell where your outstream is cluttered with all kinds of junk left over from previous debugging statements. It’s psychological- if you’ve spent a good long time fixing an issue, you want to get on with something else, or take time out. The job of cleaning up isn’t so attractive. One solution offered to this problem is to use a better logger than "System.out". For example, log4j or the java.util.logging package (I’ve even created my own: jlogging). However, here are some common issues:

  1. Using a logging package is just never as easy to hack in as System.out. There’s often some static field you have to add, along with some import statements, maybe a library dependency to add, etc..
  2. Therefore, some developers still cheat, and use System.out.println statements, and console clutter will still accumulate.
  3. Many logging statements that have long since become redundant remain to clutter the code-base, and there is little consistency between them.

This might seem such a trivial issue. For many, the answer is simply to require developers on their team to adopt the agreed policy. However, in my experience, every such well-meant policy that requires 100% diligence of all the developers on a team invariably fails. So we’re still left with this silly issue about how to debug failing tests.

Here’s a simplest-thing-that-could-possibly-work approach I’ve been using for the past few months which just seems to work really well. In Eclipse (but the same idea would work in other IDEs, as well as Emacs) I’ve edited the "sysout" editor template. (In Eclipse, you get to these dialog via Windows/Preferences/Java/Editor/Templates).

System.out.println(this+”: ${cursor}”+”\n\t “+Thread.currentThread().getStackTrace()[1]);

What this does is simply add an extra tabbed line to each output statement, detailing where the output line originated from. It is formatted in such a way that you can just click on it inside Eclipse and it takes you straight to the line, which you can then delete.

It is easier to type ’sysout’ than ‘System.out.println(”");’ in your code, so developers are likely to continue using the template once they have used it once.

Anyway, this approach has worked so well I decided to take time out and blog about it.

info/java.txt · Last modified: 2015-10-20 21:30 by sam