I like Java, really, but what an API WTF

danielpitts

The following is completely true.

public class JMenuBar extends JComponent implements Accessible,MenuElement
{
 // snip
 /**
 * Sets the help menu that appears when the user selects the
 * "help" option in the menu bar. This method is not yet implemented
 * and will throw an exception.
 *
 * @param menu the JMenu that delivers help to the user
 */
 public void setHelpMenu(JMenu menu) {
 throw new Error("setHelpMenu() not yet implemented.");
 }
 // snip
}

This is actual code from suns JDK1.5.
I googled to see if this was being worked on, found this bug listing: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4087846 dated "22-OCT-1997"

Yo, Sun Microsystems. This has been an unimplemented (almost necessary) feature for almost 9 years now!

Whiskey_Tango_Foxtro

Swing is one big, giant API WTF, IMO, which is why I switched to C# when it came out.

Windows.Forms >> Swing.

And no, that's not a bitshift. :)

mrprogguy

OH. That reminds me of a huge WTF with Java.

We were building a system to execute Java-based applications in a multi-app kiosk environment, and couldn't get the JRE to load anything at all. The whole framework ran under Windows (because the customer specified it, don't start), and we had a custom browser shell running to host the various applets. But, as I said, nothing would load--not even the Java parts of our "which app is in front" framework.

On a whim, I suggested renaming our custom browser shell "explorer.exe," and WHAM--everything loaded. The JRE for that particular year included code that specifically excluded anything not named "aol.exe" or "explorer.exe" from running Java applets under Windows. It was actually logged as a feature on the Sun website, 'way down in the developer stuff.

This was in a year when Sun was accusing Microsoft of doing everything it could to stop the deployment and use of Java, even to the extent of taking Microsoft to court. Yet Sun was making it practically impossible to host/deploy Java applets in any shell you happened to build under Windows.

That, sports fans, is a serious WTF.

codeman

@mrprogguy said:

OH. That reminds me of a huge WTF with Java.

We were building a system to execute Java-based applications in a multi-app kiosk environment, and couldn't get the JRE to load anything at all. The whole framework ran under Windows (because the customer specified it, don't start), and we had a custom browser shell running to host the various applets. But, as I said, nothing would load--not even the Java parts of our "which app is in front" framework.

On a whim, I suggested renaming our custom browser shell "explorer.exe," and WHAM--everything loaded. The JRE for that particular year included code that specifically excluded anything not named "aol.exe" or "explorer.exe" from running Java applets under Windows. It was actually logged as a feature on the Sun website, 'way down in the developer stuff.

This was in a year when Sun was accusing Microsoft of doing everything it could to stop the deployment and use of Java, even to the extent of taking Microsoft to court. Yet Sun was making it practically impossible to host/deploy Java applets in any shell you happened to build under Windows.

That, sports fans, is a serious WTF.

All I can think of to say is:

Holy WTF, Batman !!!

VGR

At least it's documented, somewhat. The javadoc does state that
it's not implemented and "will throw an exception" (which is not quite
accurate, since an Error is not an Exception, but the point is that you
shouldn't be calling it regardless).

I suspect there's a reason for this. There have been numerous
discussions in the world of UI design on whether the "help menu" is a
good idea. Most UI experts have concluded in the last five years
that it's a bad idea and no one should ever do it, because a menu
that's way off on the right is easy for the user to overlook entirely,
especially on a big window.

Doing the layout for a right-aligned menu would have been trivial, so I
am much more inclined to believe setHelpMenu is "on hold" pending some
UI design discussions, than I am inclined to believe it was due to
someone's inability to make it work.

A JMenuBar uses a BoxLayout, so if you really want a help menu on the trailing edge of the menu bar, it's as simple as this:

JMenuBar menubar = new JMenuBar();

menubar.add(fileMenu);

menubar.add(editMenu);

menubar.add(Box.createGlue());

menubar.add(helpMenu);

In fact, this is mentioned on

How to Use Menus (The Java™ Tutorials > Creating a GUI With Swing > Using Swing Components)

. I've found time and time again that a number of Swing features
are documented in the tutorials which are documented nowhere
else. (Well, they may be in printed books, but I use online
documentation exclusively, mostly Sun's.)

danielpitts

@VGR said:

At least it's documented, somewhat. The javadoc does state that
it's not implemented and "will throw an exception" (which is not quite
accurate, since an Error is not an Exception, but the point is that you
shouldn't be calling it regardless).

I suspect there's a reason for this. There have been numerous
discussions in the world of UI design on whether the "help menu" is a
good idea. Most UI experts have concluded in the last five years
that it's a bad idea and no one should ever do it, because a menu
that's way off on the right is easy for the user to overlook entirely,
especially on a big window.

Doing the layout for a right-aligned menu would have been trivial, so I
am much more inclined to believe setHelpMenu is "on hold" pending some
UI design discussions, than I am inclined to believe it was due to
someone's inability to make it work.

A JMenuBar uses a BoxLayout, so if you really want a help menu on the trailing edge of the menu bar, it's as simple as this:

JMenuBar menubar = new JMenuBar();

menubar.add(fileMenu);

menubar.add(editMenu);

menubar.add(Box.createGlue());

menubar.add(helpMenu);

In fact, this is mentioned on

How to Use Menus (The Java™ Tutorials > Creating a GUI With Swing > Using Swing Components)

. I've found time and time again that a number of Swing features
are documented in the tutorials which are documented nowhere
else. (Well, they may be in printed books, but I use online
documentation exclusively, mostly Sun's.)

Yeah, I ended up making a custom class that adds the Box glue for the right effect. Although, maybe you're right, and the Help menu shouldn't be off to the right.

Now that I'm looking, Firefox doesn't have it off to the right. Well, either way, it should be part of the look and feel :-), and the method is currently useful for generating an Error.
if (failed) new JMenuBar().setHelpMenu(null); // Too lazy to throw my own exception.

TomCo

@danielpitts said:

The following is completely true.

public class JMenuBar extends JComponent implements Accessible,MenuElement
{
 // snip
 /**
 * Sets the help menu that appears when the user selects the
 * "help" option in the menu bar. This method is not yet implemented
 * and will throw an exception.
 *
 * @param menu the JMenu that delivers help to the user
 */
 public void setHelpMenu(JMenu menu) {
 throw new Error("setHelpMenu() not yet implemented.");
 }
 // snip
}

This is actual code from suns JDK1.5.
I googled to see if this was being worked on, found this bug listing: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4087846 dated "22-OCT-1997"

Yo, Sun Microsystems. This has been an unimplemented (almost necessary) feature for almost 9 years now!

I've had my run in with Java & Co. Namely that lovely container, TomCat (blah). We weren't given enough cpu & memory on our desktop machines to run any kind of WebSphere development correctly so I defaulted to installing TomCat. From this point, I figured if I was going to codesmith using Notepad, I might as well replace TomCat with my own implementation. It's done - Web Server (apache replacement), Java Container (tomcat replacement), as well as some (funky?) code that allows database connections using aliases in the code so you don't have to constantly keep track of the conn info, called ConnX (saw this functionality in webshere and duplicated it). Also, using an ad-hoc database query app, if the user stops or closes their browser, the back-end automatically "senses" this and stops the run-away query on the database server. Phew! Talk about reinventing the wheel! The code has been in production for a year now. The only issue is some sort of memory leak seeing how it's running on a slow, outdated HP box using JDK 1.3.1. I'm not blaming HP or Java though - I still think it's something I've done but haven't been given the time to fix it (no matter).

This is just one area where I've challenged myself to rewrite some god-awful Java application (or serlvet/jsp container) that doesn't really do the job for which our company has paid loads of money.

I'm sure there's a few WTFs in my "codebase" as well. I just figure that I could write the same crap as these big software houses at a fraction of the price.

Ahhh. Had to get that (as well as these left over cheese puffs) off my chest. [:|]

asmodeus

My memory may be tainted, since it's been about 3 years since I did much in Java/Swing, but I remember Swing being much easier to work with than Windows.Forms and feeling a lot cleaner - it's mostly things like the TreeView, ListView and ComboBox that I can't stand. Perhaps things are much worse than I remember back in Swing-land. I like working with C# more than Java though.

ammoQ

@flukus said:

Windows.Forms might be good for crappy little static programs but it's absolutely useless for anything remotely complicated. Give me the flexability of GTK/QT/SWT/swing any day.

I guess you refer to the layout managers found in Swing. Isn't there something similar in the latest version of .net?

Richard Nixon

@SilverDirk said:

blah blah blah Delphi blah blah blah

Enough quoted.

sincerely,
Richard Nixon

ammoQ

@SilverDirk said:

People who like Swing and its layout managers scare me. I'm quite sure that it means that they've never used a reasonable UI widget system in their life.

Swing is unintuitive, cumbersome, slow, badly implemented, and not aligned to the needs of the average application.

I strongly agree with that, at least as long as the standard layout managers like gridbag are used. For my own purposes, I've written a layout manager that is much easier to work with and good enough for the apps I make (and faster, too).
But in the latest version of Netbeans I've seen that they have made a new layout manager which makes live much easier.

WTF_Batman

@codeman said:

@mrprogguy said:
OH. That reminds me of a huge WTF with Java.

We were building a system to execute Java-based applications in a multi-app kiosk environment, and couldn't get the JRE to load anything at all. The whole framework ran under Windows (because the customer specified it, don't start), and we had a custom browser shell running to host the various applets. But, as I said, nothing would load--not even the Java parts of our "which app is in front" framework.

On a whim, I suggested renaming our custom browser shell "explorer.exe," and WHAM--everything loaded. The JRE for that particular year included code that specifically excluded anything not named "aol.exe" or "explorer.exe" from running Java applets under Windows. It was actually logged as a feature on the Sun website, 'way down in the developer stuff.

This was in a year when Sun was accusing Microsoft of doing everything it could to stop the deployment and use of Java, even to the extent of taking Microsoft to court. Yet Sun was making it practically impossible to host/deploy Java applets in any shell you happened to build under Windows.

That, sports fans, is a serious WTF.

All I can think of to say is:

Holy WTF, Batman !!!

I try to be a nice guy, buy "holy"? Nah... :-P

ammoQ

@SilverDirk said:

Before anyone mentions JSP/apache etc, I'd point out that those are rather complicated to set up, and you can't just hand them to someone and say "hey, run this on your machine". You also get the multiple-instances deal to worry about.

For small&easy setups, Jetty is your friend.