Re: About JTextPane, Why "Not equal" ?

Lew wrote:
Tom Hawtin <use...@xxxxxxxxxxxxxxxxx> wrote:
..As ever, static variables suck big time.

Andrew Thompson wrote:
'For those of us that are a little slower than the rest'
(OK.. me) could you expand a little on that?

Whilst awaiting Tom's answer I shall venture a guess, which if Tom's answer differs I shall almost certainly abandon in favor of his explanation.

That's a bad attitude. If you disagree, call me an asshat or something.

Static variables are the global variables of Java. They have implicit effects ignorance of which can lead one to create bugs.

Locale in a String is such a thing - global to all instances of String within a particular run of the JVM unless explicitly specified. This causes portability issues in such code. Likewise, I guess the AttributeSets in a JTextPane are implicit and can lead to surprising portability issues.

I do not know what parts of the JTextPane issue are literally static or global, but I can see the point about implicit characteristics.

I didn't actually see where the problem is in JTextPane (is it actually a in getText, perhaps picking the default document line separator). It's a piece of configuration and even when I'm looking for it, it's not at all obvious. I spend all day (when I'm not posting to usenet) looking through code for bugs. These sort of things annoy me.

So, general problems with (mutable, and immutable with context dependent initialisation) statics:

* The class (and any clients of the class) now depends upon the entire application. This is Bad. You might think you only want to ever use one object per application. But that means that code defines what the application is.

* If that code is ever turned used an applet (or similar), it will break. The idea of what an application is is broken.

* Testing is made much more troublesome, due to the first point. You could try some classloading shenanigans with a bit of reflection, but I'd really rather not.

* Initialisation sequence is not explicit.

* If the initialisation legitimately throws an exception (a security exception, say), then you can never initialise that class again. For instance, you can almost adapt JUnit (3.8.1) GUI runner to run under WebStart, except for one flipping read of a system property.

* Statics are implicitly multithreaded. You just know this is not going to be done right.

So use "Parameterisation from Above"/"Dependency Injection". Or to put it in simpler terms, don't use statics.

Tom Hawtin
.

Quantcast