Michael Chermside

I'm not sure what you mean by "leak memory", but one I've seen before is to allocate an ever-bigger objects. Note that this is subtly different from allocating a large object and forgetting to release it. Here's an example I encountered once (in someone else's code, thank goodness). First, the perfectly sensible version of the function:
public class SomeClass { private static String SPACES = " "; /** * This left-pads s with spaces to length n. */ public String padWithSpaces(String s, int n) { int padNeeded = n - s.length(); if (padNeeded <= 0) { return s; // no padding needed } else { while (padNeeded > SPACES.length()) { SPACES = SPACES + SPACES; } return SPACES.substring(0, padNeeded) + s; } } }
The code uses a static variable to store a string of spaces
which is grown (exponentially) to make it long enough for
any padding needed. Unfortunately, a collegue of mine tried
to write this code but made a mistake. Instead of growing
SPACES only when necessary, he grew it every time:
public String padWithSpaces(String s, int n) { int padNeeded = n - s.length(); if (padNeeded <= 0) { return s; // no padding needed } else { SPACES = SPACES + SPACES; return SPACES.substring(0, padNeeded) + s; } }
So every time that padWithSpaces() was called, the static
variable SPACES grew... and it grew fast. Had the growth
been linear instead of exponential, we might not have
noticed the bug!
-- Michael Chermside

Ernest Friedman-Hill writes:

...So if you had two different instances of Integer, each one an instance of a version of the class loaded from two different class loaders...

Aha! Given what we are doing here, that explanation is not entirely implausible. Thanks! It may not be the answer, but at least it's a reasonable possibility that I can investigate.

Has anybody ever seen anything like this? We're running a process (Websphere, actually, with an application in it) on java 1.3 hotspot (build 1.3.1_03-b03 to be specific). After the application has been up and running for a long time we start getting a peculiar error. One possible explanation for the error would be if the equals() method on Integer were failing (returning false for two Integers both containing 0). Has anyone ever heard of such a thing? It's a pretty ridiculous idea, but at the moment my other possible explanations are looking a bit ridiculous also, so I thought I'd ask.
-- Michael Chermside

I have what is perhaps a more useful question. I need to customize and use a workflow engine which, by corporate standards, probably needs to be in Java. Does anyone know of an open-source project for supporting workflow which I could use (and hopefully contribute to).
I have seen that there are several such projects registered at SourceForge, but any comments from someone here who had USED one (or even just knew about it) would be very welcome.

How would you do this in C?

Robert:
Another good thing to consider is doing the following:
long lo = Long.MAX_VALUE;
float fl = Float.MAX_VALUE;
lo = lo + -1;
fl = fl + -1;
System.out.println("lo = " + lo);
System.out.println("fl = " + fl);
Does this do what you expected? If not, then you probably don't
understand how floating point works.

I'd like to second Jim Yingst's comment: check out Jython. Writing your own interpreter for your own mini-language is not particularly difficult, but it's surprising how often people make the same mistakes that have been made hundreds of times before. Using a well-designed scripting language that's already created for you might save a bit of time and lots of headaches. And Jython is a pretty good language too.

Checked or unchecked. It is, indeed a perienial topic.
My own opinion is that checked is better, except for two kinds of exceptions: those that can't be expected, and those that could occur just about anywhere. So, for example, ZeroDivisionError could occur just about anywhere in a program that does calculations, so it should be unchecked. ArrayIndexOutOfBoundsException could occur just about anywhere, so it should be unchecked. IOException could occur just when you're doing I/O operations, and I'd make it checked (and so would Gosling apparently). And then there are things like OutOfMemoryError -- there's no way it can be expected, so it is unchecked.
Using this reasoning, most "Business" errors are checked. You suggest that you can "re-throw them or handle them", but doesn't require "try { ... } catch(MyException err) { throw err; }" (which I've seen), just document that it's possible by adding "throws MyException" to the method and do nothing in the code. That minor notation is hardly big overhead. A common exception to this rule is exceptions which SHOULDN'T ever happen -- so, for instance, I never write "// should never get here" in my code; I always write "throw RuntimeException("should never get here");" instead (better to die badly than to keep going with invalid data!).
HOWEVER, having said that, the best gurus I've spoken with tend to, as you've suggested, fall into the unchecked-always camp. See http://c2.com/cgi/wiki?CheckedExceptionsAreOfDubiousValue for one source. They say that checked exceptions sound great when you're working on a small project, but as soon as things grow to the size of a full-scale project, they start to become a pain. You wind up with a few exceptions that are declared by practically every method as they get passed around. I would say that those ought to be refactored as unchecked when that happens, but I can see their point. So I'm certainly not going to claim that my preferred approach is "best".
-- Michael Chermside

The problem with this suggestion is that I now need to do something special every time I call the logger (or at least at the top of every method that uses it). This is completely unacceptable... far worse than a one-line not-quite-boilerplate in each class.
I did a little research on my own and found that as of java 1.4, Throwable has grown a getStackTrace() method which allows access to the stack trace in a "safe" manner (parsing the string from printStackTrace() is NOT portable and was NOT safe). So I could write setUpLogger() to throw an exception, catch it, then examine the stack trace to pull out the value. Something like this:
// WARNING: Untested Code String nameOfCallingClass; try { throw new Exception(); } catch(Exception e) { nameOfCallingClass = e.getStackTrace()[1].getClassName(); }
Unfortunately, I'm using java 1.3, so I won't be able to use this.

I'm using Java's logging (java.util.logging.*, java 1.3+). It all gets fed to a single file if you want, a "Logger" object is really a particular log identifier, for which the log level and log distribution can be controlled independently.
The issue of building the string is, indeed, a very real one. I've measured x5 slowdowns in code due to logging in real code... within a factor of 2 of your 90% figure. The standard solution in java's logging framework is for all log lines lines to look like this:
if(log.isLoggable(Level.WARNING)) log.warn("message with " + valueInsertedHere);
Frankly, I think that's a BIG PAIN... before java's system existed I built my own and had it down to a managable:
if(log.doWarn()) log.warn("mesage with " + valueInsertedHere);
which is enough shorter to be significantly more usable. But Sun didn't consult me.

I would like to create individual logger instances for each of my subclasses, so I can turn logging on/off class-by-class. I could do it like this:
class Parent { public static String PREFIX = "mylog."; } class Child1 extends Parent { public static Logger log = Logger.getLogger(PREFIX + "Child1"); // ... Child1 code goes here ... }
However, after someone does some cut-and-paste, it'll wind up looking like this:
class Parent { public static String PREFIX = "mylog."; } class Child1 extends Parent { public static Logger log = Logger.getLogger(PREFIX + "Child1"); // ... Child1 code goes here ... } class Child2 extends Parent { public static Logger log = Logger.getLogger(PREFIX + "Child1"); // ... Child2 code goes here ... }
(note how Child2 accidently uses Child1's logger).
To protect against this, I would like the "boilerplate" needed to be as small as possible, and as static as possible. My ideal scenario would be to have code in Parent which ensured that all Child classes would have a logger based on their class name... with NO code required in the child class. I can come CLOSE with this design:
class Parent { public static String PREFIX = "mylog."; public Logger log; public Parent() { log = Logger.getLogger(PREFIX + this.getClass().getName()); } }
Using that design, no boilerplate is needed in the Child classes. Unfortunately, now "log" is an instance variable instead of a static variable, and can't be used within static functions. That's unacceptable, so I conclude that I'm forced to have at least a declaration in the child class. So I'm hoping for something like this:
class Parent { public static String PREFIX = "mylog."; public static Logger setUpLogger() { // ... how do I write this? ... } } class Child1 extends Parent { public static Logger log = setUpLogger(); // ... Child1 code goes here ... }
...except that I'm not sure how to write setUpLogger(). Is there any (portable) way to find out what my parent class is? I was thinking of some trick with throwing an exception and examining it's stack trace, but it seems like there must be a better way.
Any suggestions?
-- Michael Chermside