Moderator (MDR): Andrea

Guest-Speaker (SPK): tomball

MDR-Andrea: Hello everyone and welcome to Java Live. Today we will be discussing Swing and JFC with Senior Staff Engineer Tom Ball. Please go ahead and begin to send in your questions.

splante: Are you planning to add more complete keyboard support to the Swing text components, such as Shift-home, Shift-end, shift-control-rightarrow, Control-home, etc.?

SPK-tomball: We're definitely improving the keyboard support (I'm adding JInternalFrame stuff today), but I'm not sure what the exact keycode list will be for text. Our accessibility folks are riding us hard on this however, so it should be fairly complete.

Kabir: Could you please comment on the omission of a PositionLayout manager in the Swing toolkit? Will it ever be implemented? If not, are there any structural constraints which would prevent one from writing their own PositionLayoutManager? Thank you.

SPK-tomball: We've never claimed to be the source of all layout managers, either in the AWT or Swing. To my knowledge, there should be nothing preventing a PositionLayoutManager, unless it just codifies absolute positioning. With multiple L&Fs, that's just asking for trouble.

frankbert: I'm having a lot of trouble with the Swing 0.7 JComboBox. It seems to have very inconsistent behavior showing the pulldown menu. On Solaris, it works every once in a while in a JFrame, and in a regular Frame it works more consistently. On Windows, it never shows the pulldown menu. When inside a modal Dialog box, it never shows the pulldown menu. I even tried adding a mouse listener to it, and explicitly calling the showPopup() method. It still doesn't work. The worst part is that it worked fine in Swing 0.6.1. Is there a known workaround? Are there plans to improve this for the next version of Swing? I would use a Choice() as a workaround, but the setSize() method on it does not work. Argh!

SPK-tomball: JComboBox is undergoing an overhaul as we speak (write?). The API is pretty solid, but its implementation was pretty sorry. We're working on that.

vas: I read in JavaWorld (I think) that a release version of the JFCs will be made available before JDK^TM 1.2 sometime in January. Is this true?

SPK-tomball: JDK 1.2 isn't officially due out until early this summer, while Swing 1.0 (aka JFC 1.1) should release early next month.

mmehrle: First, a general question: I would love to use JFC within my product, but I'm hesitant as to whether or not it will be supported in IE. For now I would only consider it for applications.

SPK-tomball: Try using the Swing 0.7 release, as it's the first version which runs in IE. Right now we're fixing the repaint problems we're seeing with a few components, and doing other IE-specific cleanup. Running well in IE and Netscape Communicator are important requirements for release.

weber: When can we exepect to see the source code for JFC? I noticed it was even left out of the JDK1.2 beta2 src.zip file.

SPK-tomball: Swing's source is now available, and I'm surprised to hear it isn't in the beta2 src.zip. Are you looking in java/awt/swing? The package names are different between the 1.1 and 1.2 versions of Swing so it can be downloaded on 1.1, but part of core for 1.2.

mloy: Can you comment further on the use of com.sun.swing vs. java.awt.swing and how that's shaping up for use with browsers that might not have Swing in their JVM?

SPK-tomball: Sure. The two packages are the best compromise we could come up with for two conflicting marketing requirements: make it downloadable on 1.1 VMs, and part of the java.* core in 1.2.

Basically you have a choice as an applet developer: run on 1.1 browsers and distribute the swing.jar (or require that it first be installed on the user's system), or require a 1.2 browser. The key for deciding this is whether your classes import com.sun.java.swing (for 1.1) or java.awt.swing (for 1.2). We won't force you to cut over—it's your choice to do so when it's appropriate for your customer base.

splante: It doesn't seem right that users of Swing components need to remember which components they may and may not call setBorder without hurting the component's functionality. Have you considered creating an addBorder() method to JComponent?

SPK-tomball: Good idea—I'll pass that on to the group.

dnehring: What is the tentative release schedule for Swing 0.8, Swing 0.9?

SPK-tomball: We're planning on putting together a 1.0 final candidate next week and privately sending it out to those companies who have been the most responsive to us with bug reports, as well as our licensees and our own QA department. Based on the short-cycle feedback we get, we'll polish off the P1s and send that out as JFC 1.1 (don't ask me why it will be named that, it's a marketing thing :-).

We plan on then producing dot-dot releases concurrently with future JDK 1.2 betas and final releases, or when critical bugs are fixed. We won't be doing monthly releases anymore, as we're all a bit tired. :-)

splante: Will JDK 1.1 applets using Swing need to be signed to get around security if Swing is not installed on the users' browsers?

SPK-tomball: No, we've worked around those problems. Some browsers will occasionally report SecurityException stacktraces because they have a bogus Thread.dumpStack in the SecurityException constructor. We catch and work around those exceptions when they occur, so ignore the stacktrace.

mmehrle: Does JDK 1.2 contain the latest version of the SwingSet?

SPK-tomball: No, we're too fast for the rest of the JDK team. :-) One reason Swing has its own release process is that the JDK has grown too big to allow rapid development. We basically succeeded by not working within the system.

vas: Is there any way that my company could request getting the 1.0 final candidate?

SPK-tomball: If you've been proactive in sending us high-quality feedback, you're already on the list. We aren't going to grow the list, however, because the review cycle is so short (two weeks or so). It would take longer to sign people up than we're giving them time for review. I'm sorry if this isn't a perfect process, but that's the cost of developing at Internet speed.

weber: First, I'd like to thank you for all the great responses so far. My question is this: given your early comment about com.sun.java.swing vs. java.awt.swing, can we assume that you will be issuing releases with the com.sun.java.swing package for the forseeable future? By the way, this seems to point to the first real need of a #define :-)

SPK-tomball: Tee, hee, I've already written the preprocessor, as we'll need to do more than change package names to support new 1.2 functionality such as Java 2D, drag and drop, and on-the-spot input method editing. To answer your original question, we plan to offer dot-dot releases well past the release of 1.2, as we realize that 1.1 browsers are going to be around for awhile.

mmehrle: Regarding having a choice to import com.sun.java.swing or java.awt.swing. It would make sense for future VMs to maybe look into either direction when running into a Swing-related import statement. This way we would not have to choose which group to cater to.

SPK-tomball: There's a proposal out to do just that, but it's too early for me to comment on its contents. It still wouldn't address how 1.1 VMs work, however, so our hack will need to be around for awhile. It did wake our VM group up to the problem, however.

weber: For clarification about JFCs release: next week RC1 goes to select group for a two week review, then the final release. Does that mean in a month we should have it?

SPK-tomball: Yes, barring any unexpected P1 problems getting reported. We aren't promising that Swing will be finished for 1.0, but we are promising that the APIs won't change (they will grow for 1.2, but will be backwards-compatible), and that the quality is better than most 1.0 offerings (not a hard bar to clear). The reason we're telling people now about our dot-dot releases is so they know that higher-quality releases will continue to come from our team.

kentam: I am not sure if you got this question but I didn't see a response. Are there planned performance enhancements for the later releases of Swing? Currently, it takes some time to start it up.

SPK-tomball: Absolutely, although right now our priorities are: API correctness (we have to live with it after 1.0), then quality (no P1s, few P2s), then performance. We aren't shunting performance into the "nice, but won't happen" category, though—it's very important to us.

BTW, I'd like to plug an independent company which has a great tool, OptimizeIt, which we're using for our performance analysis. Check out www.optimizeit.com if you are interested in improving your application speed (or helping us focus on critical areas).

splante: The JDBCAdapter class (from the JTable examples), with a little work, it could make a very nice addition to Swing. Are you planning on moving it into Swing?

SPK-tomball: Right now we're more interested in finishing what we've set out already than adding new functionality. If you can improve it and send it to swing-feedback "really soon," we'll use it in place of our current demo.

jbrasch: Will Swing or a subset of Swing be included in a future Personal Java release?

SPK-tomball: Absolutely, as Swing components are more portable than native ones. The PJava folks haven't figured out just how yet, but we're talking.

wwood: I've been looking for some Acrobat or Postscript API documentation on Swing, ala the JavaBeans^TM specification or JNI. Is any available? I've been working with Swing since last summer and going through the HTML documentation can be cumbersome if you're trying to learn about Swing.

SPK-tomball: That's one of the advantages of being on the JDK train—it's slow, but a lot gets done. As Swing is consumed by the JDK, our documentation will get better, and more of the "corner cases" we don't have time to cover will be handled. Our documentation folks are also working with our tools team on creating a better javadoc, and as that starts being used you'll see better API documentation across the board.

weber: Can you comment on which L&Fs will be included in the final release?

SPK-tomball: It's still up in the air, partly because of all the good feedback (including the "it sucks" messages) we got about the Java L&F. One of our licensees is also feverishly working on a too-be-named native L&F, but until it's ready we can't ship it (lawyers and all that nonsense). The general answer is that we'll have a small set of L&Fs bundled with Swing, and will separately make available lots of others in the future. It's more of a bundling and timing issue than anything technical.

kentam: Is it possible to use Swing with the current WorkShop version? I've heard conflicting answers from various sources.

SPK-tomball: This question also applies to other Beans builders: we're working with each of the builder vendors' development teams, and have resolved our Beans incompatibilities. As you all know, being compatible isn't the same as actually working, so the various teams are working on how to play together. In some cases we're doing extra work (such as moving our BeanInfo classes up into the Swing package), and in other cases the builder vendors are changing the ways they do introspection to be more BeanBox-like. It's an ongoing process, which probably won't be fully ironed out when we release 1.0.

Some of you may be aware that I'm skipping the specific bug questions and am grabbing the more general ones. Partly this is because the Swing team functions fairly autonomously: I haven't a clue as to the status on specific bugs in components I don't own. Rest assured, however, that all the team members will get a copy of this transcript so we'll know your problems. (In particular, I know little about trees and tables—they were important enough to put a senior engineer on each.)

kentam: Will there be MDI-style support for the JInternalFrame components (i.e. Tile/Cascade)? I wrote some code to do some of these tasks. However, it was quite difficult because of the lack of documentation on the usage of the DesktopManager and the JInternalFrame.

SPK-tomball: Now that's one component I grabbed a couple of weeks ago, when its developer went on to startup-heaven (may he slave in peace :-).

Although I don't have time to do a full MDI implementation, I'm focusing on making sure the API won't prevent it, and then fixing the worst bugs. Eventually the DefaultDesktopManager will be MDI-compatible.

mmehrle: Regarding the L&Fs, what ever happened with the Windows L&F available for the Solaris download? The political climate between MS and Sun^TM (and the rest of Silicon Valley ;) is not exactly good; so will we have to dispense with a Windows L&F on non-Windows platforms?

SPK-tomball: I recommended that we wait until Microsoft sues us for L&F infringement, which would make them look silly to anyone who remembered their suit with Apple. Wiser heads prevailed, however (that's why I'm not a lawyer), and we had to limit its exposure of that L&F to systems which have a license for it: your Win95 or NT click-license is your right to display those widgets. Any Mac L&F will have the same limitations, as both companies have invested millions into those L&Fs, and consider them to be significant intellectual property. I don't see a technical way around these legal issues.

weber: The docs for EditorPane currently mention support for RTF, but that support doesn't actually exist in 0.7. Will it be there in the final release?

SPK-tomball: Those of you who have studied Swing's text architecture know that it supports "reader-writers" for handling I/O with external file formats. The two formats we intend to support for 1.0 are HTML (in a limited form) and RTF. The RTF reader/writer is being developed outside of the team, and (to put it gently) isn't up to our engineering standards yet. We're cleaning it up, and expect it will be ready for 1.0.

thoth: Can you comment on when JFileChooser and/or the PrintJob classes will be updated?

SPK-tomball: We're cleaning up the choosers, but to be honest, they haven't had the level of review yet to where we feel comfortable freezing their API. We're therefore planning on putting them in a "preview" package so you can use what's there, but won't promise a frozen API until we promote them out of the preview package. This is similar to how in the old days Unix systems had a /usr/bin for final stuff, and /usr/local/bin for interesting, but not fully-baked programs. It's a hack, but we're doing it so you can be confident of what we're committing to as "final API" and what we want to continue improving.

Uh-oh, our monitor's coming. :-)

MDR-Andrea: Well, we've reached the end of the hour. Thanks to everyone who participated—especially Tom. We will not be having Java Live next week, as it is a short week in the United States with the Martin Luther King Jr. holiday. Check the schedule for the most current information on topics and times.

If you'd like more information about Swing, check out the web page, which you can link to from the front page (java.sun.com). And if you'd like to send in more questions and comments, use swing-feedback@ejava.sun.com. Again, thanks for joining and see you next time on Java Live.