Java Blog

This has started to accrete things like Ant, as well.

These notes were jotted down as we came across problems during our software development efforts. They may be out of date with respect to the latest version of Java (e.g.: sorting issues). A lot of the problems are really just due to very bad documentation.

See also A Critique of Java.

Misc tools: Javadoc, JSwat debugger, JUnit unit testing framework, TestNG expanded unit testing framework, Testing with Hibernate, Java PathFinder, PMD (Java 'lint'), Automatic bug finder, Code coverage, Modeling / Design by contract, Profiling, Logging.

112) I want to use Java because it has things like FindBugs. I don't want to use Java because it is too bloody verbose. So I'm looking for either a pre-processor that will make me have to do less typing for types (e.g. when just "new"ing something), or a JVM-based scripting language with a tool that will convert the scripts directly to Java source code. That way I could be doing less typing, and yet still getting all the benefits of the Java ecosystem. Unfortunately, I have yet to find what I want...
111) Find more bugs in your Java code with automated tools.
110) I love getting the UnsupportedClassVersionError, and then not being able to find any reference that tells me the mapping between Java 1.x style version numbers and the major.minor style of version reported by the error. (Apparently, 48.0 is 1.4 and 49.0 is 1.5, er, I mean Java 4 and Java 5, respectively, of course!)
109) Java seen as a Kingdom of Nouns (not a good thing, apparently).
108) Um, so does JVMTI just blow security away? It seems like there are some other possible holes? A basic problem with Java that I'm learning from all of this is that the core language doesn't handle larger concepts like issues which arise from serialization; when you say something is private, classically you had one connotation which is less or outright just not valid when things like serialization are applied. Nice.
107) Nice how the safe notice is kinda hard to distinguish from what I would presume to be the unsafe one, in that the unsafe one would have one more small word in it: "not". The fact that it uses bold makes it look to me like it is trying to warn me about something possibly dangerous. Just all 'round bad design.
106) It is funny how GC is supposed to make life easier, yet one ends up having to tweak the system anyway. So you get a whole new area of cluelessness and strife!
105) Word!
104) Try to do anything 2D in Java and you very rapidly come to hate the lack of tuples or out parameters or anything that would make life simple. No, instead you have to make your own coordinates class and use that everywhere. Blah!
103) Face it, backwards compatability for a virtual machine is a sham, and more-over is just a bad idea. You cannot get everything right the first time and expect never to have to make low-level changes. Although life really sucks when you get into versioning problems, I think the buisness reality is that features sell over compatability every time. (Hm, on the other hand... or does that just prove the point?)
102) Those who do not understand the nitty-gritty of concurrency are doomed to make life hell.
101) Some "I hate Java" rants. Nice!
100) I love how JDB writes line numbers with commas, so you get "1,081" rather than "1081", which is just blatently stupid dumb in so many ways. Sheezuz.
99) An omniscient debugger for Java. It is funny that his debugger makes the same UI error as many Java debuggers, presumably because the Java debuggering API is stupid dumb broken: the indicator of what code is currently active is off when you are looking at an entry higher up in the call stack - it looks like the function called has already returned, when the call stack shows that you are actually still in the function. Java sucks! Given that his debugger is supposed to help you see how things have evolved in time, having the cursor in the wrong place is really really confusing, and pretty much destroys any usability there might have been.
98) More JSP suck: you can get NullPointerExceptions when your JSP is being compiled. I figured maybe I could attach JDB and have it break when the NPE happens, but is didn't actually stop anything. Great. Nice. Terrific. So useful. So easy to develop with. Ah! It turns out you have to explicitly tell the debugger you want it to break when exceptions fire. I guess that makes sense now that I think about it.
97) Looks like I have to deconvolve my understanding of C/C++/C# and Java, d'oh. Re-learn something every day...

96) Sooner or later, you will probably have to write code like the except here below, and I think that pretty clearly shows Java's moral bankruptcy (but, see C++ for the other extreme).


     public void add( String reference )
     {
         if( this.countMap.containsKey( reference ) )
         {
             Integer count = (Integer)this.countMap.get(reference);
             this.countMap.put( reference, new Integer( count.intValue()+1 ) );
         }
     }

95) Having just completed an official Sun training class on Servlets/Struts/JSPs, I have to say that I find the entire system to be pretty pathetic. It manages to lose all the power of OO encapsulation (which I think would be better obtained via simple HTML templating), and claims to make UI development easy for non-programmers, but clearly doesn't - they have to learn new lame mini programming languages (tags, expression language) which have quickly bloated themselves. It would be better to just teach the web developers how to program in Java, really. And could they come up with any more hateful things to have to configure? With raw strings that aren't checked at compile time? And result in systems that are impossible to debug (although supposedly there are Eclipse plug-ins that work magic)? Gah, it is just so literally retarded. (I'm glad to see I'm not the only grumbly-pants.)
94) Java is turning into a huge unwiedly morass. Witness how they had to take something nice and simple, and featured and replace it with something bloated that makes what used to be simple things hard. Don't even get me started about all the AWT vs. Swing crap of "do I subclass JFrame or Thread or what?" Every release of Java brings out new ways of doing suff and deprecates old, which means if you try to do a web search for information you get at least 3 different ways of doing things, all incompatible. And in the end, people tell you to just make something an Icon to actually display it, even if it is some 1024x768 Photoshop file. Talk about cognitive dissonance. Expletive!
93) Here's a submission for the top ten most pathetic usability designs ever: In the Java debugger JDB, the way to see a list of already set breakpoints is to invoke the command that removes breakpoints. Only you don't give it any arguments so it doesn't know which one to remove, so it shows you the list of them. Great! Genius! Ship it!
92) This is more of a rant against software in the general sense, but it was recently bugging me with respect to Tomcat. To wit: configuration of systems is a huge nightmare for the newbie. Some of the problems are:
- Interdependencies are not made visible, so if you do something in one part of the overall config you might not know that you have to do something in another part to make things work.
- The more options there are, the harder it is for anybody to write succint documentation that will get people started; there's the OS to consider, there's the version of Java to consider, there's the version of the application to consider, there's the choice of how to hook it up to Apache to consider, etc. Pretty much every single one of the "simple introduction to getting Tomcat running" ended up describing a world that diverged from what I had on my (relatively pristine!) machine. The only way I could get things to work in the end was to take the baked-in example webapp and whittle it down bit by bit, seeing what parts I could delete before it would fail to run. Complete trial-and-error.
- Something that might help would be a visualization of forward mappings from config files to directories and files; the problem is that one has to debug by trying a URL, seeing the result (failture) and then poring through the various and sundry configuration files trying to figure out what to edit.
- Gee, how about having an actual index and glossary with your documentation? No, Google isn't a sufficient answer.
91) Some fun gotchas.
90) Could the Java security model suck any harder? How many versions of Java have been out, and how many years have passed, since they started off claiming that there would be glorious sandbox fun with Java? Pretty clearly a bunch of bull poop!
89) Since Eclipse uses SWT, I guess the blame falls there: you can only click on the check boxes themselves, clicking on their descriptive text does nothing. That's utterly stupid, hateful, and wrong in a painfully 1990's web style.
88) "Somebody remind me why am I using Java? "Because you're an idiot." "Oh, right." "You two!"
87) Ant sucks. I really do quite hate it. The latest reason: If I specify JAVA_HOME, it looks for the 'java' exe in there. If I want to then override that with JAVACMD, it forgets all about JAVA_HOME that I already set, and forces everything based off the JAVACMD path. So that seems to me to completely obviate the entire bloody point of having the two evironment variables (per the Ant docs). Argh!
86) It sure sounds like Sun screwed the pooch re: generics in 1.5. It doesn't help that they'd apparently already screwed her before generics (should Object[] be a superclass of String[]? etc.) leading to confusion upon confusion in 1.5 land. Still, there's a FAQ to get you through the impending heck, should you decide to go that route. And, it sounds like the confusion is mostly for developers of libraries, more so than for consumers of libraries, so at least the trouble is limited in some fashion. The really sad thing, however, is that I think things like SML and Haskell, etc. end up having a much cleaner syntax around all this generics stuff. I despise having to use < and > in my source code! They are the kind of things that give me hand cramps if I have to type too much, you know? We're talking simple ergonomics here, people!
85) The debugger API apparently won't let you set a breakpoint on a closing brace. It says there is no code there. So how are you supposed to get a breakpoint at the end of a while loop iteration? Or look at what happened to a variable at the end of a routine? If you step, you are suddenly out of that block and the variable has gone out of scope, so the debugger won't let you see it. Yeah, that's great. And this is juts with imperative programming - there is no way you are going to be able to debug f(g(x))!
84) Sure, it is great that Java's libraries are so extensive. But then there comes a time when you have to figure out which of the FileOutputStream, GZIPOutputStream, OutputStreamWriter and DataWriter to call close(), and in what order. What a bloody nightmare.
83) It isn't that I need finalizers in Java, which are called when the item is actually collected, I just need a "the reference is going out of scope" call that I can optionall implement, so I can have RAII for closing resources. C# has 'using', and apparently the recent verisons of MS managed C++ let you have RAII, so my claim/belief is apparently backed up with empirical evidence! This feature is particularly important when having to deal with exceptions everywhere.
82) No, really, I love having to write new Integer( iFoo ).toString(), rather than have the compiler do uh/boxing for me.
81) I love how the time and date is represented by a Date class, but the bloody Calendar interfaces are all called setTime() and the like. They never mention Date at all in the names. That's nice and confusing because then you don't know if they are doing that because the routine explicitly ignores the date and, say, only looks at the what time it is in that day, or something. Dumb jerks.
80) I feel like any time I actually try to do anything in Java that implements a class hierarchy, I am getting myself into a place that just doesn't work. Java hinders more than it helps. Maybe it is like the type system in ML where once you figure out how to get it to compile, your shoddy thinking has been worked for you, but so far I just feel like it is being pissy for no good reason (no reason that I've seen explained in the docs, anyway). My current gripe is the fact that static method dispatch is determined at compile time rather than run time. That, as far as I can tell, totally sucks. Combine that with the fact that you cannot easily return more than one value from a function and you are in hell when it comes to trying to abstract out the things you are doing in main() for use by subclasses.
79) As others have pointed out as well, Java says one thing and then does another: it claims to go for some purity, and then it actually throws purity to the dogs. Example: UnsupportedOperationException for use with interfaces. That completely defeats the entire bloody purpose of having interfaces!
78) Ant properties and the checking thereof sucks. They can be used in conditionals, but they are checked by asking if they have a value at all, rather than if the value equals 'true' or 'false'. I think that is confusing and simply poor design.

77) OK, anybody who thinks 'final' is a reasonable thing should go read the last paragraph here. Now, this kind of thing happens all the time - the fundamental point that any real software engineer knows about software is that you cannot nail it down without getting yourself into trouble. Clearly, there should be something other than 'final' to deal with the security issues 'final' supposedly deals with. For example, could one not mark a routine as 'canonical' instead, and then allow other code to require the 'canonical' version of something if they care more about the security aspect over the getting-the-job-done aspect? (I'm not trying to say that we don't need to think about security, or about fragile base classes, I'm trying to suggest that somebody who has zillions of dollars and people (i.e.: Sun) should be figuring out how we can have our cake and eat it as well.)
76) More proof that computers suck (because humans suck): I download a jar file through Firefox on my PC, and then I get an error dialog out of nowhere, titled "Java Virtual Machine Launcher" saying "Failed to load Main-Class manifest attribute from E:\...\foobar.jar". As if that means anything to your average user? I mean, it barely means anything to me and I'm a developer who uses Java! (Turns out Firefox defaults to opening jars with 'jarfile' rather than just saving the thing to disk. Whatever!
75) Have I complained enough about JavaDoc? No, no I haven't. The so-called index it generates includes the types for the arguments to methods, but it doesn't include the variable names. Nice!
74) It bugs me that the @see syntax for javadoc is different than what you would write when writing code. So instead of "Class.method" you have to write "Class#method" which sucks.
73) Here's a dumb bug that sucks ass: Often, the parameters to a constructor are saved as internal member data. So they often have the same names only you say "this.foo = foo" not "foo = foo". Well, if you ever do the latter, or some other screwy variant, then "this.foo" isn't going to be diddly-squat. Should we never name things the same? Should the compiler be smart enough to warn us if things look sketchy?
72) Even with debugging symbols on, the exception stack trace doesn't show you the parameter types to the method, which would be nice in the case of overloaded APIs, no?
71) Somebody want to explain how to set the JVM for a taskdef in Ant? Blah!
70) Here's a simple thing Sun could do to make Java suck less: give us versions of all the collections that are read-only.
69) Java is a pearing down from C++, and then everybody goes and adds back in all the things it needs to suck less; multiple dispatch, profiling, design by contract, etc. But they are incompatible extensions, most of the time because they are doing whacky bytecode injection, or providing a their own VM, or a unique compiler. So we end up in a situation where you can't have your cake and eat it, too, which is such a shame.
68) What is up with the difference in return types for Map.values() vs. Map.keySet()?!
67) The TreeSet API is pretty screwy. They should have broken it out into two different classes, one which could only use the key and value's Comparable implementation, and the other which would require giving it a Comparitor at construcion time.

66) The world of Java is a shining example of why all software systems really, really, really suck ass. To wit: I'm trying to get some profiling information on this program I've written and yet no profiling system I have tried yet has worked. I've tried hprof, JRat, EJP, jvmstat (but I'm stuck on 1.4). I haven't broken down just yet and tried the trial versions of commercial stuff. They have all failed in some manner; some after a few hours of me getting them all set up in the first place (EJP, which gave me results but there were blatantly wrong, or at least mis-categorized). The latest thing is that JRat wants to do bytecode injection which apparently competely breaks the libraries I'm using. Yes! In other words, if you have a sufficiently complicated system where you realize you need a profiler, you are already in the state where no profiler tools will work with your system! So I have a day's worth of work and I'm no closer to having useful profiling information. God, hell. Update: so I try a profiler from UCSF which apparently doesn't do bytecode manipulation, instead it does source code injection... and they completely screw the pooch by assuming that System will always be java.lang.System, so their code doesn't bloody work with our code because we have another System imported from another namespace. Yes! So I hacked, er, corrected their sources... and it still didn't work because the arguments passed to my program were totally screwed up. I really don't feel like debugging that further, and I can only conclude that anything which tries to do injection is going to really, really, suck. (I mean, even more than the other profilers which all really suck.)
65) I'm assuming it is the default Swing "open file" dialog box; it has an icon and a filename next to it, and if you click on the icon twice (slower than double-click) you end up in the "rename file" mode. Now, the entire overloading of double clicking like that sucks everywhere - Mac OS, Windows, etc. - but to then compound that utterly stupid interaction by making it happen even if you only clicked on the icon... well, that clearly takes Java genius!
64) Nice! The Java docs say that "Iterators allow the caller to remove elements from the underlying collection during the iteration with well-defined semantic", but then I get a ConcurrentModificationException, and the docs for that say, "For example, if a thread modifies a collection directly while it is iterating over the collection with a fail-fast iterator, the iterator will thow this exception." So in other words there are at least two different kinds of Iterators, but they don't explain that in the bloody Iterator docs! Kill!
63) Funny how Java is touted as taking security seriously, and then they go and put in holes the size of Nebraksa [pdf].
62) Once down the road of Java inheritance I quickly find yourself limited, or at least confused. Example: I want to have ClassB.foo() inherit from ClassA.foo(), but I want ClassB's version of foo to take a subclass of the argument given to ClassA.foo(). So I end up with APIs that are too generic, and with lots of runtime casting and possible ClassCastExceptions. Sad.
61) They're on 1.4.2 and their docs are still not properly copy-edited. The docs for File.canWrite() say, "Tests whether the application can modify to the file denoted by this abstract pathname." Nice!
60) Great. I just spent a while freaking out, only to finally realize that Jikes supports covariant return types but regular Java (pre 1.5) doesn't. "Strictly Java compatible. Jikes strives to adhere to both The Java Language Specification and The Java Virtual Machine Specification as tightly as possible, and does not support subsets, supersets, or other variations of the language." My ass!
59) Apparently, Java doesn't do anything remotely like cpp when it comes to comments. I'm hacking some code to do some experiements, and I want to change the name of a method from e.g.: FooTheBar() to Foo/*The*/Bar(), but the compiler blows up on that. It didn't remove the comments to boil it down to FooBar()! Argh! (Maybe it was Jikes again?)
58) Is the Java standard for where you put the curly-brackets like the old K&R? I absolutely loathe having the open bracket on the same line as e.g.: the if statement. These days I have to have all curly brackets on their own line, otherwise the code looks like complete and utter jibberish to me!
57) Could the output from Junit's textui.TestRunner suck more? It doesn't even print out the name of the tests as they are being run, only their output, making it harder to figure out what test generated what output. Sheesh.
56) Ant can bite me. The difference between classpath="${project.classpath}" and classpathref="project.classpath" just kills me.
55) More Ant suck: ant -v doesn't show you much at all about what is going on with taskdefs.
54) Javadoc sucks because it won't show you full sub-trees other than from the root of the package. So if you have org.foo.bar, org.foo.bar.baz and org.foo.bar.baz.rumplestilskin, you can't see all of the classes from org.foo.bar.baz on down into rumplestilskin. You can only see all of the classes from org.foo.bar. Or, you can see all of the classes at the level of org.foo.bar.baz, but nothing below or above is included. So that completely and obviously sucks!
53) Another reason Javadocs suck: when you are in the docs for a package, you can't see all the implementors of a standard Java interface (or subclasses of a standard Java class). However, you can do that if you are looking for all the 'children' of a package-defined interface or class. (E.g.: finding all the things in the package descended from java.awt.Window.)
52) Now here's a nice one. Swing's open file dialog box uses a font which doesn't distinguish between lower case ell and upper case eye. So when you have Fool.java and FoolI.java (the latter being the interface that the former implements), what you see is Fool.java and Fooll.java. What! Ever!
51) Swing is such a tub of poo. It has inherent problems, but then even worse is that developers using it go and flaunt any rules or consistency. So jswat has a [F]ile menu (you can get to it using the F keyboard shortcut), and then an entry in it for [E]xit. But junit's TestRunner GUI doesn't have a file menu, it only has a [J]unit menu, and inside that there's E[x]it, oh lord.
50) Jswat's help files are only accessable from the application itself. That is particularly hatefully annoying stupid wrong when you are trying to figure out how to get the thing started up properly; it would obviously be easier and better if the docs were separate simple HTML files. The kicker is that the Swing based help GUI for the files really really sucks. Just use HTML and let people use a fully functional, not- entirely-suckful web browser, duh!
49) Why is it that in Windows I have the mouse wheel set to scroll like 5 lines of text, but in Java Swing applications it scrolls 15? Maybe because Swing is a flying piece of excrement?
48) Ant gets my nomination for the worst command line mnemonic ever: "-emacs, -e ... produce logging information without adornments".
47) Ant doesn't seem to have the equivalent of make's -n feature.
46) Ant is killing me because I can't figure out how to tell it to not scan directories recursively. I just want the stupid thing to stay in the current directory, why should that be so hard to do / find docs explaining it? Argh!
45) I want to tell Ant to use a different compiler so I set up ~/.ant.properties to tell it that. Now, what I want is a way to see if ant found that and is respecting it. The problem is, I have not seen any output from Ant, no matter what arguments I give it, that tells me exactly what compiler it is using. The closest thing I've seen is "Using modern compiler" which doesn't tell me a whole heck of a lot - I want to know exactly what executable it is using. Why is this so obfuscated? Has nobody else on Earth in the entire time from the birth of Ant to the current version needed this? It is just complete lameness from hell! I think that the 'build.compiler' setting doesn't take an absolute path, but there isn't a whole heck of a lot of explanation of how it all works anywhere. Oh the hate! Is there any way to have Ant echo the value of 'build.compiler'? No, not that I've seen yet anyway. Then, there's the wholey different 'executable' param you can use on the 'javac' task which claims that it can take an absolute path. Could this be any more convoluted and inconsistent and crappy? Guess we'll find out when the next release of Ant appears, ha ha! [Update: there are a few things to know. First, the .ant.properties file is not automatically loaded (unlike most 'dot files' from the land of unix). Rather, you have to tell your build.xml file to load the user's file with something like: <property file="${user.home}/.ant.properties"/>. Second, if you are using cygwin you need to place the user's file not in their cygwin home directory, but apparently in "Documents and Settings/user" directory instead. Having done all that, things are actually working. I'm so glad the official ant documentation and FAQ says nothing on the subject...]
44) Sweet, sweet Ant: "Note: The order in which the files building up a FileSet are added to the path-like structure is not defined."
43) I'm so glad the Ant documentation doesn't have an index of keywords, etc.
42) Apparently, Ant won't let me tell it exactly in what order to pass things to java. So the -Djava.ext.dirs that needs to come before the -jar stuff is being placed after, and so the generated command doesn't <expletive&ht; work. I have yet to find a way to tell Ant the explicit ordering. Grn! [Update: Ah hah, I should be using <jvmarg/> instead of just <arg/>.]
41) The transition from 1.4 to 1.5 is a real bitch.
40) I'm trying to get an image loaded and displayed. (This is a step along the road to getting textures in JOGL.) Unless you've tried to do that before, you might not appreciate just how completely insane the Java APIs are for this kind of thing. They manage to take something seemingly simple and through a process of abstraction make the implementation completely obscure. There are too many different ways it can be done (although I have yet to see any of them actually really do anything at all) and they are all seemingly based around asynchronous approaches - I mean, even to get the stupid image size. You can't just block until the image is done loading, you have to do some insane ImageObserver insanity. It is almost as if they do not want you actually using Java to get any work done.
39) The whole Java Web Start thing appears to me to be a piece of crap. It hasn't yet successfully launched an app, instead I get really cryptic security exceptions. Yeah, great. So now what the hell do I do? Wade though tons of Google searches to figure it out? Screw that noise. Oh, and the progress bar for when it is downloading stuff just seems to flash randomly - I've never seen it at anything other than 0 or 100 per cent, and it does not appear to be in any way related to the text notices that go by. Remember, you can't spell "whatever" without spelling "hate"!
38) Why doesn't anybody ever write a clear explanation for the unixy comparison? All they would have to do is put in a table and it would make so much more sense.
this.compareTo( Object other ):

Relation Return Value Rationale

this < other negative this - other < 0

this == other zero this - other = 0

this > other positive this - other > 0
37) Not being able to simply have a method that takes a variable number of parameters sucks.
36) The fact that I have like four different versions of Java on my machine speaks volumes about how much their versioning sucks. Different systems want to install different VMs, SDKs, JREs, whatever. It is so retarded and unmanaged.
35) Swing apps keep on proving to suck. They just don't fit in with the rest of the user interface on my (Windows) machine. For example, Together4 doesn't respect the global font size I've set for Windows in the Display Properties. So the fonts are teeny and hard to read and I hate everyone. Apparently there is a way to change the fonts, although then you have to restart the entire application, too!
34) Subclasses must still explicitly implement interfaces. I guess this is to give them more flexibility, but it seems kinda wrong to me. I mean, a subclass should do everything that a superclass does, right? So I think it should automatically implement the interface, as the superclass declares.
33) java.util.AbstractList.removeRange() is protected. I guess it's just so useful that it's dangerous to let mere programmers at it! So I end up having to subclass ArrayList and adding public void removeRangePublic().
32) So Arrays.asList() doesn't return an ArrayList, just a List interface. Why didn't they return an ArrayList? I mean, it might even be an ArrayList, but the spec doesn't guarantee that so I have to do new ArrayList( Arrays.asList( foo ) ) which seems like overkill.
31) While Swing stuff supposedly can have a native look and feel, I'd be willing to bet that the Open File dialog in the Windows L&F is sufficiently broken to just be outright annoying.
30) The documentation still makes me think a bunch of caffeinated, lobotomized monkeys are running the show. It is pretty unprofessional. I guess that's an indictment of the whole JavaDoc process; coders want to be able to write notes that are very internal, e.g. from the FileSystemView docs:PENDING(jeff) - need to provide a specification for how Mac/OS2/BeOS/etc file systems can modify FileSystemView to handle their particular type of file system. As if I know or care who the hell "jeff" is? If you go and look at the docs for the JFileChooser, you see that nobody even bothered to proof-read them: they forgot the <pre> or <tt> or <code> tags in the example code at the top! Then, there are articles in The Swing Connection that aren't even grammatically correct. What. Ever.
29) Yes, Swing still sucks. The Open File dialog has a button for creating a new folder, but when you use it, it doesn't scroll to show you the new folder, nor does it select it. Other than a slight redraw blink, there's nothing to tell you that pressing the button actually did anything. Plus, it doesn't have any way to change the sort order; it's all by file name. Furthermore I rename the file and hit enter, and the selection is no longer that folder, but the one that is closest to "New Folder" which, in this case, is "PrintHood." It's as if the thing was designed to work as hard as possible to make me lose the folder. Also, it has no robust way of letting you specify a folder, which I've already run into in Cocktail.
28) I thought this was just a problem with the installation of JProbe, but it looks like elite from ICEsoft is doing it as well: I run a Java application on my Windows 2000 box, and at startup I get an absolutely nutty scary error dialog.
27) So InstallAnywhere has a nice thing which figures out which version of a file you should get. It's used, for example, at ICEsoft (broken link?). The only problem is that it does the download using a Java Applet, so if you leave the page, you lose the download dialog box! I figured that it just died. Turns out, and this is even more bad and creepy, it was still running in the background! It finished and out of the blue the just-downloaded installer app fired up!
26) Java Swing doesn't like Win2k's multiple monitor support; If you maximize a window on the secondary display, it tries to draw itself on the primary, and spooges.
25) The JAXP XML stuff has NodeLists, which don't implement anything from the Collections stuff... because that would make sense?
24) The language horribly restricts signatures. I want parametric types!
23) The javadocs need to have a mini TOC for every class, so that when there are a bazillion statics, you don't have to scroll through them all looking for the actual methods, you can just jump to them. I mean, you'd think that maybe the people at javasoft would have thought of this as they were writing java code. Or, maybe they realize the docs are really bad and so absolutely never even bother to use them?
22) I cannot even begin to describe how utterly messed up the Swing html parsing stuff is... but here's some rough sketches: The documentation is pretty much utterly devoid of useful content. Figuring out how to get a parser for your own use is a process of trial and error, with absolutely no guidance from the lame docs. Once you have it going, you will then discover that the docs are actually lying about how things work, like the HTML.Attributes. (E.g.: the docs say getAttributeNames() will return an Enumeration of Strings when in fact it returns an Enumeration of Attributes).
21) You can specify an initial capacity for a java.util.ArrayList, however, that doesn't mean you can put stuff anywhere. You can't add beyond what has already been added. That is, you can't have any blank space. So you can't walk backward down the list, filling it in.
20) I think ifdef is ugly, but there are times when I'd really appreciate having it. Well, I guess I can insert a pre-processor of my own (hell, I could use cpp) into the make process...
19) Character.getNumericValue( '>' ) returns -1. That seems really wrong. Surely the Unicode standard includes that character.
18) It bugs me that the compiler barfs on a break after a throw exception statement, because what if at a later date someone removes the throw? I want to be sure that the switch statement will stop properly.
17) Why doesn't StringBuffer implement everything that String does? It's insanity.
16) If you are slapping a bunch of components together, you can get all sorts of dependency problems where some class library is missing. Sometimes it's really obvious where to get the library, and other times it's nigh impossible to determine - there's the javax.servlet stuff, and then there's quite often some dependency upon sun.servlet stuff, which doesn't seem to come bundled with any standard install. Of course, if you go to the JavaSoft web site and search for sun.servlet.http the hits aren't answers to the question, merely posts of the same question to a discussion list. (Discussion lists are what let the support folks head off to the beach four days a week.) If you end up in the Developer Connection via Sun's web site (and the DC looks exactly like the JavaSoft web site - I've never understood their screwy division), you can finally find useful information (you'd think it would be in a FAQ already)? [Of course, the link I had is now broken. I guess that information was too useful to let live!]
15) The JNDI docs don't seem to ever explicitly say whether it only works with 1.2. (Update: turns out they do, somewhere, but it's like a little note at the end of some small sentence buried in the horribly overgrown and intertwined JavaSoft web site. The answer, by the way, is that it works with 1.1 as well as 1.2.)
14) Dates. If you've used Java dates then you already know what I mean. The kicker is that going from 1.0.x to 1.1.x, they went nuts on the calendar stuff so now you can get the wrong date in any nation, with any calendrical system.
13) Swing. Attempting to have a cross-platform UI toolkit is insane (I've heard great things about the dead Galaxy). People can't even get Windows to work properly across all hardware, so how can you possibly expect to get a UI to work across all sorts of system types? (Note: these complaints were noted in early '99, so maybe things have been fixed since then.)
1. If you have dockable toolbars, when you undock them there is no obvious way to redock them. Turns out you have to hit the close button. Retarded. Systems that don't suck will let you drag the toolbar back over the main application window and will give you some visual feedback about the docking being allowed. Not Swing, no siree.
2. The scroll bars are screwy. In, say, MS Windows, when you grab onto a scroll bar's thumb thing to move the view around, the point at which you grab stays stuck to the mouse cursor. In Swing, that only seems to be the case if Java can manage to keep up with your motion (like, it works for small frames with nothing in them, but not otherwise).
3. JFrame. I can't seem to get rid of the message "For Help, press F1" in the status bar. The kicker is that apparently, if you want to listen for F1 in your application you would have to register a KeyListener on every component in the system. I haven't seen how you can just add it to the 'root' component, and have the events bubble up to there, like in X Windows.
4. In a JTable, if you are editing the (last cell on the) last line, when you hit return nothing happens. It's wanting to move the cursor down a row and it can't, so even though it looks like you've made the change it hasn't actually gone through to the underlying table data. You have to select the cell and hit return again and then maybe it will work. It's also all screwed up on knowing how wide it is; I suspect it's not taking into account the vertical scroll bar.
5. DefaultCellEditor.setClickCountToStart() doesn't work. No value I give it makes a difference; you always have to double-click to get into edit mode. Always.
6. When I click on a JMenuItem the click also ends up going through to the underlying JPanel or whatever it is, causing it to get focus at that point?!
7. Seems like there's never a way to force a widget such as a JComboBox to explicitly have nothing selected. The strange behaviour I'm getting is that you select a choice, and then the box collapses back down to 1 line, but it's hilighted, since that's the item you just selected.
8. You don't get actions as the user is moving the mouse over choices in a JComboBox. So you can't, for example, update a help string as they are checking out different options.
9. Bad APIs: Taking a specific type, but returning a more generic type (e.g.: JPopupMenu takes lets you add MenuItems, but when you get one back out the return type is Component) so then you are in the runtime hell of casting. Utter inconsistency in the names of methods of Swing menus.
12) Why no meta types? See ML. Runtime casting is about as evil as pointer arithmetic.
11) Bad documentation. Terminology changes ('mnemonic' vs. 'shortcut', 'active' vs. 'focus'), and there are no dictionaries. Docs like: public Thing foo() "Returns a foo." No mention of things like side effects (in situations where you could reasonably suspect that they would happen, like removing things from lists). The docs for SwingUtilities.findFocusOwner() do not say whether it recurses. The 1.1 File docs, especially about the path separator, are wrong. More often than not, docs fail to tell you if the index starts at 1 or 0. That would be helpful in classes with mixed modes of indexing (e.g.: Strings).
10) The behaviour of static code is evil.
9) Why isn't there an enumerated type?
8) Requiring super() to be first thing leads to code that's supremely unreadable. Let alone the fact that you can't have a try/catch around it! It's insane!
7) Often with graphics code, using either AWT or the newer 2D libraries, the first frame of animation is lost. Some flush command hasn't gone through, and yet there is no explicit graphics flush command for me to use.
6) The event system seems pretty random; when to test for mouse down vs. click or key press vs. type is all higgledy-piggledy. There's a bug where you have to check for key press for the help key, not key type.
5) The attempt at handling character encoding is bad news. At least, the documentation is bad. E.g.: String.getChars() vs. String.getBytes(), having to know what your 'default platform encoding' is, yadda yadda yadda. E.g.: you can initialize a String with a byte array and then ask for it back from the String and it's different!
4) Whyintheheck does everything have to have a different way of getting a length() / size() / count(), with different naming conventions (Vector.setSize(), StringBuffer.setLength(), or array.length vs. Vector.size())? It's so stupid.
3) There's a file.mkdirs() but no file.touch().
2) There are no standard sorting tools. Hello, qsort is like a standard unix thing. It's not as if anybody ever wants to sort anything I guess.
1) PrintStream is deprecated in favour of PrintWriter, but there aren't nice ways to convert between the two, and you cannot get at the underlying stream. Standard input and output, for crying out loud, are PrintStreams ( try and redirect standard output to your JSP 'out' which is a PrintWriter).

Relation	Return Value	Rationale
this < other	negative	this - other < 0
this == other	zero	this - other = 0
this > other	positive	this - other > 0