Java (swing) and zoom (green) button


I am working through the Java examples on the Developer CD, as well as some from O'Reilley's "Learning Java."

For any pure Java code I saw, clicking the zoom button, that is the green one with the "+" sign, wrecks havoc with the contents of the window. The widgets are echoed in another part of the window, the text in the buttons fly out of them, etc. As one could expect, Cocoa-Java examples are immune.

As far as I can tell, there is no simple remedy. I thought of adding a "WindowListener", but there seems to be no suitable one. On the other hand, if that was simple, I suppose Apple would have fixed the code before putting it in the CD, and exposing itself to embarassment. I also assume this can't be a general problem for Java, as some of the code comes from Sun, and I bet will work on Unix and Windows.

Any ideas? If Apple wants to promote Java as its prime development tool, together with Objective C, standard Java code must work reasonably well out of the box.
I agree that something seems amiss about the resizing of true java apps. The entire view should be invalidated and redrawn from scratch whitch doesn't seem to be happening. I can't say how this works on other platforms as I've only done applet work in true java and I expect a browser to keep window size static. Good luck, but please do report back as to the behaviour on other platforms, I'm curious.

As for java being promoted ... it friggin' rocks! Do a cocoa-java app, and you have access to all of the NS classes through java syntax. Really, I couldn't ask for much more. The only wierdness is the strong typic of java layed on top of the lax typing of Obj.C - anyway, the java thing is likely not quite complete for running swing/awt applets, but the power of knowing java and learning the classes to do real applications (I repeat REAL applications) on cocoa is one of the coolest things I've seen.

After beating my head against C for years, and playing around with the lack of stability / availability and slowness of smalltalk VM's, I'm really happy with the performance, learning curve, and general robustness of the Java on Cocoa environment. Bar none.
Thank you for posting an answer! I was really feeling lonely.

I would definitely consider doing Cocoa-Java, but I think basic problems with pure Java should be solved as first priority on the Mac. I was worried sick at not finding any reference to the resize "bug" in any Tech-note or forum posting. Even jEdit, the GNU Java editor suffers from this problem.

People at Apple should be in a cold sweat. If they think all Mac developers are going to learn Objective C and all will be fine, good luck to them.
1) it seems that the problem (scrambled Java Frame or JFrame after window zoom) affects all sort of Java applications (Swing, AWT, applets)

2) if I *move* the scrambled window even by one pixel, the frame is redrawn correctly. Clicking on the window is not enough, though.

This seems to be a general problem with the Java implementation. Ironically, if there were a java.awt.event.WindowAdapter method for "Zooming", even I could fix that. But there are only methods for closing, iconifying, etc.
I guess I haven't tried the green zoomy button, but I've had no problem simply resizing pure Java apps such as the PHP editor Pepe or some of my own apps.

I <em>did</em> read in an Apple Java note that there were known bugs (to them, not us) with the redrawing, especially with all those horizontal lines.

Has anyone figured out how to get click-thru to Java apps or even within a Java app with multiple windows (like Forte)?

I like the idea of mixing the more familiar (to me) Java with native Cocoa apps, but I'm more excited about being able to use C to access the AltiVec instructions.

If you use Swing do not use the Aqua L&F plugin, use metal.

Swing apps will never behave like mac apps. The Aqua L&F will only make a cheesy facade which at best confuses people expecting a mac app.

Just use metal so when I see a metal app I know I have to adjust my behavior to 'Swing mode' just like I have to adjust to 'windows mode' when switching to VirtualPC.

Also if you're going to use Cocoa, don't bother using Java. It takes a day to learn Objective-C and it kicks Java's butt in terms of flexibility. Java is barely better than C++ which is pretty pathetic.
This is the story. I written a Java applet game which I have ported to Cocoa. (Check out In this case using Objective-C is not an option since I then would have to re-write the whole lot.

But, as far as I can tell there is functionality accessable from Objective-C that I cannot get to from Java. For instance opening a url in the default web browser. Does anyone know if there is a way to mix them toghether? I.e. writing a static method in Objective-C that I call from my Java code.

By the way I think Java is a really neat programming language I think I will stick with it until we get Cocoa-SML... now *that* would be something.
Cocoa was never designed to work with inflexible languages like Java. Many classes are designed with loose typing and forward invocation in mind.

Apple's Java 'bridge' uses proxy objects, not a general runtime. This means creating custom classes in Objective-C to use in Java may be difficult, I wouldn't know. I think it may be easier to do it the other way around, using your Java classes with a Cocoa app written in Objective-C. Even if it's equally doable you should consider this method since you app will likely run a lot better.

Asking on Omni's Mac OS X Dev list would be a better forum for usch specific information.
Strobe, you're out of your gourd. Apple has clearly created a world where Java is a legitimate language for applications, with or without Swing. So it's not as fast as C: Who cares? Not all parts of an application are data-processing intensive, and I'm willing to be that many more people know Java than Objective-C.

CaptainFoo, you might try doing what Apple did which was to use the <em>incredible flexibility</em> of Java using the Java Native Interface (JNI). That let's you declare any Java method abstract (and native) and lets you write the actual code in another language. In this case you'd probably write it in C.

See what books or online tutorials are good for you regarding the JNI. They'll tell you how to construct your C functions to accept Java arguments and such.

You then might end up with two simple files: a .java file with the <em>public void native abstract yadda yadda</em> declaration of a method and a .c file with the C implementation calling Cocoa's "launch in default browser" methods.

Good luck. When you're done, please consider contributing the code to the Code Snippets section of

alternate title: Strobe and his Gourd

Java does suffer a little from C-isms, ... but so does objective C, hence it's name. But my real point here today is the argument of speed, I reference another post I made doing a simple fibinacci test, and my runtime remian in the newer, faster X.0.1 - classic code ran in 12 seconds, java code ran in 16 seconds, and C compiled for X with project Builder (gcc) took 25 seconds. Speed for data processing is not a serious weak spot for java with modern VM's.

In fact, having numerous discussions with theoretical computer scientists as well as some phreaks from IBM RS6000 team, java should often be outperforming C code in data intensive tasks with constant optimizations, aggressive inlining, and some other buzzwords that I don't remember. Learn Obj.C for it's flexibility, but not for its speed.

Thanks for the tip, JNI might be the way to go. I had kind of hoped that Apple had made it simple for us, just select the objects in Interface Builder and click connect or something.

Well I'll have a go with JNI.

By the way, interesting to hear about the speed test Java vs C++...

Apple Dev Team (well, the NeXT boys) are the best.

You may argue on and on whether C, Obj-C or Java is the fastest language, but it doesn't matter that much; with Cocoa and with Java-bridges, native methods and the command line your can write whatever you want:

A cocoa application with the interface built in IB, the model in Java and the controller in either Java with native methods written in C++ for processing-intensive tasks or completely written in Objective-C. Then you could call command line commands from Objective-C, they can be written in C, C++, Java, Perl, AWK, Python, (BA)SH, (T)CSH, you name it.

Let every language do what it was made for. I prefer Java, it's my way of thinking. I understand that if I ever went into byte-by-byte-editing I should resort to C/C++. When I work with large texts and pattern-find-and-replace I will use Perl, that's the strenght of Perl. I don't need speed for most of the time. I wan't efficient coding, well, fun coding.

Theo Hultberg/Iconara