 |
Improved Drag Gesture in Swing
Posted by shan_man on June 07, 2005 at 12:22 PM | Comments (29)
One small step for Shan, one exciting leap for Swing drag and drop.
Fantastic! The java.net folks kindly set me up a place to share my thoughts,
I sit down and begin typing, and out comes a play on the monumental
Neil Armstrong quote.
I consider: "Why would I start my blog space with a goofy play on
words, appearing to compare Swing drag and drop to humankind landing on the moon?" Well,
the answer is twofold: First, as a software engineer, my mind often travels into
odd or complex places, and seems to stick there for extended periods of time
(like the months I disappeared into fixing the drag and drop bug which I'm about
to tell you about). Driving to work this morning, thinking about how to start off this
blog that I've been planning for some time, in popped the "One small step..." jingle.
As I've just described, I got stuck on it. Although I got a kick out of my own [not so]
wittiness, I realized it was rather cheezy. So I tried playing a game with myself to pass the
commute - if I could forget about it by the time I arrived at work, I'd find something else
to start with. You know how successful trying to forget about something can be...
But the more important reason I started as I did is that it perfectly summarizes this morning
for me. I'm taking my very first step into the world of blogging, and to mark the occasion
I'm announcing a very exciting bug fix to Swing drag and drop. While I wouldn't even think
to seriously compare this to landing on the moon, I know it will mean the world to a rather
large group of Swing drag and drop users.
Until very recently, the sixth highest vote getter on Sun's list of
Top 25 Bugs was bug
4521075 with a
total of 239 votes. This bug reports that the recognition of a drag gesture
in Swing is unlike what is typically expected by users. More specifically, it complains
that Swing requires an item to first be selected with one mouse click,
before pressing on it again and dragging to begin drag and drop. The much more
common paradigm expected by users is that a single mouse press should be able
to select the item and also begin recognition of a drag gesture.
I am extremely pleased to announce that this important bug has been fixed! In fact,
it has already been released to the public in build 36 of Mustang, which you can
download now. And let me top this with
some even better news: This fix is also targeted to be released in update 5 of
J2SE 5.0, due out in the not too distant future.
Originally, the fix for this bug was targeted to be the default behavior in FCS of
J2SE 5.0. However, it turns out that the changes involved were larger and had
more potential for backward incompatibility than was orginally expected. It was a
sad thing to do after all of the effort we'd invested, but we finally decided that this
needed more investigation to eliminate the risk of breaking existing
applications, and therefore it couldn't make 5.0. But that's history!
Today, the fix is available in Mustang with very few potential points of
incompatibility, and we'll make the entire fix available in 5.0 update 5
safely by conditionalizing around a system property,
"sun.swing.enableImprovedDragGesture". So in update 5 you'd launch
your application like this:
java -Dsun.swing.enableImprovedDragGesture APPCLASSNAME
(In Mustang the system property disappears and it just works!)
Most of the details regarding this fix are available in the evaluation of the bug report.
But please let me point out the highlights:
-
JList, JTree, and JFileChooser have been fixed
such that a selection is no longer required before pressing on an item to begin a drag operation.
More importantly, we've carefully studied this behavior and are confident that the many
different combinations of mouse gestures will work as expected
(ex. ctrl-press, ctrl-press then drag, etc).
-
JTable has also been fixed to work as described, but (for good reason) only
in SINGLE_SELECTION mode. The reason behind this decision is that JTable
has always allowed the user to select ranges of cells by dragging the mouse.
The new drag gesture would be identical to the existing gesture for selecting a range of
cells, and this conflict prevented the change from being be made in modes supporting
multiple selections. In these modes, users must continue to select a range of cells first,
before clicking on them to start drag and drop. This behavior is consistent with the
spreadsheet applications we compared with during development.
Of course, the description of this change wouldn't be complete without a quick summary
of any potential points of incompatibility:
-
Consolidation of selection and gesture recognition logic:
Prior to this fix, selection logic and drag gesture recognition logic was separated
into two distinct mouse listeners installed by the UI on each component. The two listeners
knew nothing about each other, and therefore it wasn't possible to make them do the
right thing. In some cases selection needs to happen before considering for a drag
gesture, and in other cases drag and drop should begin without processing selection
changes. Without coordination between the two listeners, this process couldn't work.
The fix was to put all selection and
drag gesture recognition logic into a single mouse listener to be installed
by the UI on each component. This has worked extremely well and has facilitated the fix of this
bug as desired. It has also introduced the first two very minor points of potential
incompatibility. First, I have seen numerous work-arounds posted to forums for this bug,
and some of them include removing or playing with the private listeners on the components.
It is unknown how these work-arounds will fare under the re-designed drag recognition.
The good news is that any problem can be easily fixed by removing the work-around.
The second potential for incompatibility is for developers that have created custom UI
implementations supplying their own mouse listeners that replace the behavior of Swing's
defaults.
Any such implementation would simply suffer from no longer having built-in drag support. We
don't expect this to be a major issue though, as most UIs replace the look of a component and leave
the listeners alone.
-
Handling of cell editors:
The last thing of significance that had to be modified to facilitate this change is the way
that cell editors are handled in JTable and JTree when drag recognition
is turned on. While selection and drag recognition will be considered on mouse press events,
cell editing will now not be considered until after the mouse has been released. This will not affect
most developers at all (after the mouse release, Swing re-processes the press event - and things
will appear to developer code the same as before). The only easily noticeable result of this is
that JComboBoxes in JTables now pop up on the release rather than
the press. This is considered a benefit in that users can now begin drag and drop
or drag to make selections on top of a JComboBox cell without it popping up. Finally,
the value of CellEditor.shouldSelectCell() will now be ignored for table
and tree editors when drag is enabled, on the grounds that cells that aren't selected
can never be dragged.
Phew, that covers it! I can't believe I let my mind back into those last couple of points again.
But seriously folks, I absolutely love working on Swing drag and drop and there's some more
exciting changes in the works that I'll be writing about shortly. So please, if you're interested
in Swing drag and drop, Swing in general, or cheesy plays on words, please come back and visit soon.
Otherwise, life would really be a drag. Ha ha h...OK, I think it's about time I drop it.
Bookmark blog post:  del.icio.us  Digg  DZone  Furl  Reddit
Comments
Comments are listed in date ascending order (oldest first) | Post Comment
-
I'm not sure about the play on words, but I really like the article ! ;)
Nice update on these most-wanted improvements !
Adding / Removing mouse and keyboard listeners is a tricky business that can create conflicts, with behaviours that are difficult to trace.
I develop complex authoring environments in Swing, and I often deal with "weird" mouse-over focus-related behaviours, depending on Drag'n'Drop mode, Windows/MacOSX modifier keys, etc.
User-interaction is one area that deserves attention when designing complex custom components.
Posted by: daniel_weck on June 07, 2005 at 02:45 PM
-
I feel good about this change and I can probably remove some hacky mouse listeners I've had to write, when Mustang is released for all platforms. I'm a little bit concerned about cell renderers and editors - will there be a way to override the drag behavior to accept all mouse input as editor input, if the developer wants to?
Posted by: keithkml on June 07, 2005 at 11:00 PM
-
that is really great news! Thank you for taking the time to fix this, it is a big improvement making Java applications more 'native' feeling.
Posted by: uhilger on June 08, 2005 at 11:54 AM
-
Responses to daniel_wreck, keithkml, and uhilger:
daniel_wreck: I'm still not so sure either! But I'm pleased that you enjoyed the read. I definitely agree with you regarding listeners being a tricky business; it's quite astonishing when you realize all of the different ways that one mouse event can possibly be interpreted (should it cause a focus transfer, selection change, initiate drag and drop, start editing, something else altogether...). Hence the extra amount of time spent investigating and correctly addressing this bug. This should mean a lot less work-arounds, and will hopefully make your job designing complex components that much easier.
keithkml: Thanks for commenting. I'd just like to address the concern you've raised. The logic concerning dealing with the processing of mouse events has been and continues to be within the listener installed by the UI, since it is part of the "feel" of the component. As such, the only non-hacky way to override the behavior is to subclass the UI and provide an alternative listener - and this isn't easy. That being said, I'm only mentioning it because you've asked, not because I believe it will be necessary. For the following reasons, I don't think what you've mentioned is something to be concerned about:
Cell renderers will not be affected at all by this bug fix, just the logic for starting editing.
The only change in behavior is when drag is enabled on the component. So if setDragEnabled(true) hasn't been called, the mouse logic will be as it always was.
This is only a very minor change in when the "start editing" logic is called. We simply give drag and drop and selection a chance first. Once it's decided that drag and drop is not going to happen (on mouse release), then the editor is given a chance to start editing (and if it does, we forward the original mouse press to it so that it sees what it would normally expect).
Hopefully this alleviates your concern!
uhilger: Excellent! It's our pleasure. You know, at some points I've worried that the community thought we'd abandoned them in regards to this fix. But the truth is we've been listening and have known for some time how incredibly important it is to the Swing drag and drop experience. And we've been doing everything in our power to get this safe and correct fix out to you as soon as possible.
Posted by: shan_man on June 09, 2005 at 12:40 PM
-
Shannon,
You wrote: "... JTable has always allowed the user to select ranges of cells by dragging the mouse."
Is there a (relatively) simple way to change this behavior, or do I need to capture mouse events? I'd prefer to have it work as it does in a JList, where you have to use the shift & ctrl keys to make multiple selections. I've looked closely at the docs for JTable and didn't see any simple way to change this behavior...
Thanks!
Posted by: leischj on July 28, 2005 at 06:30 AM
-
Question: I've been able to get the sun.swing.enableImprovedDragGesture property to work when I launch directly from the command line but not when I launch via javaws. To be sure I've uninstalled all other java's except the 1.5.0_05 and even launched the javaws cached jar files directly via command line 'java' (which works, so I know I'm using exactly the same jar files). I don't use the -D on the command line, but use setProperty() in the app. I couldn't find anything in javaws docs to explain (the app is trusted). Any ideas? Thanks.
Posted by: alaricalum on September 17, 2005 at 04:22 AM
-
Hi alaricalum,
Swing reads this property only once, and does so very early in it's lifecycle. As a result, your call to setProperty() happens after the property has already been read, resulting in no change. The same is true if you were to try to set the property in your jnlp file. I've filed a high priority bug on this problem, asking the Java Web Start team to make this property trusted, in the first update release possible. This will allow you to set the property in your jnlp file, causing it to be passed to the command line when java is invoked. In your jnlp file you'll add:
<property name="sun.swing.enableImprovedDragGesture" value="true"/>
The bug, 6341549 (Make sun.swing.enableImprovedDragGesture a trusted property for Java Web Start.) has just been filed and should appear on the JDC shortly. Thanks!
Posted by: shan_man on October 25, 2005 at 01:06 PM
-
Hi leischj,
I apologize for the delay in responding to your question. When I first read your message, no simple way of implementing what you've described came to mind. So I decided to keep thinking about it, and to analyze the source code to see if I could find something for you. Unfortunately, although I can propose something that would give this behavior, it would be a hack and fragile to future implementation changes. I prefer not to steer you in that direction.
Considering this, do you think this is an important option that we should add to JTable? Under what circumstances do you think it would be useful?
Thank you for the question!
Posted by: shan_man on November 04, 2005 at 11:32 AM
-
Hi shan_man,
I have two internal frames with tree inside each of them. When I try to drag a tree node from the frame that is not active it will require me to click twice. Is this enableImprovedDragGestutre property suppose to help with this or it's another bug. I tried to set the property, but it doesn't work. Bug reading bug reports that lead me to this blog, I am assumed that fix described in this article with fix my problem.
Posted by: izelker on November 09, 2005 at 03:22 PM
-
Hi izelker,
There should be no difference between dragging from components in inactive internal frames and components in active ones. So, with this property enabled, you shouldn't have to click twice to drag from a tree in an inactive internal frame. I've just tried this myself and can't reproduce the problem you've described.
Would you please tell me what version of Java you're running (the output of: java -version)? This property was introduced in update 5 of J2SE 5.0. It is the default behavior in Mustang as of build 36.
Thanks!
Posted by: shan_man on November 10, 2005 at 07:55 AM
-
shan_man, thanks for responding. It's funny that I just came back to this page today - I'd completely forgotten about my question that I posted so long ago - and I only came back because I'm researching a talk I'll probably be giving 1Q06 about java se 6.
Anyway, to answer your question simply, I do think it would be great to see in JTables because just about every table-based UI I've ever worked with behaves in the way I described above.
I've recently added drag and drop to our Swing app. The main table is multiple-selection, so to drag an item, you have to click once, click and hold, then drag. We did 4 usability studies with customers showing off our new feature. Literally every one of them got confused when they tried to drag a table row. They found themselves selecting multiple rows and I heard a few "ew"s. :-)
So, to make a long answer one word longer: consistency.
Thanks for considering my experiences. Keep up the great work y'all do with swing!
Posted by: leischj on November 11, 2005 at 10:26 AM
-
Welcome back leischj, and thanks for the follow-up! I'm thrilled to hear you're out there talking about Java 6.0. It's going to be a great release. It sounds like you'll be including some notes about drag and drop in your presentation - and if so, please come back again in a few days. I'm halfway through writing a blog entry to announce some major enhancements to Swing Drag and Drop, and I'll be posting it shortly.
Based on your feedback, I've filed a bug: Bug 6349223 (Offer option to turn off drag selection in JTable) should be visible on the JDC shortly. My personal experience with tables suggests to me that both options are useful. When the component is being used like a spreadsheet (such as in Star Office or Excel), it makes more sense to have dragging select cells. If the component is being used more like a multi-column list, it makes sense to turn this off. We've done the best we can to preserve backward compatibility, but I agree an explicit property would be nice to control this.
By the way, just for comparison, notice that we've made the details view of JFileChooser (which uses JTable) behave exactly as you've requested, since we know in this context that the table is certainly not being used as a spreadsheet :)
All the best!
Posted by: shan_man on November 11, 2005 at 11:06 AM
-
Shannon, Thanks for creating that bug -- glad to see all my complaining is making an impact!
I agree, both options are useful - I hadn't considered the Excel case - it definitely makes sense there. In our UI, all of our tables are as you describe: multi-column lists, ala Win Explorer.
I'm very much looking forward to java 6. we are using 1.4 right now, not moving to 5 because - well, our app just doesn't work well when built and run with a java 5 jre. Having to do with the modal window bug and our workaround for it. So I was tickled to see the new modality features added in mustang. As an early adopter of just about everything, it's killing me to still be using 1.4 :-)
thanks again for taking my suggestion about the jtable dnd behavior!
Posted by: leischj on November 16, 2005 at 10:23 AM
-
Shannon, this bug fix seems to have broken our app. We're not using any work-around for the drag-and-drop functionality it has fixed but we are extending JTable. Can you tell me exactly what behaviour has changed to I can track down the bug this has introduced? (i.e. which methods and what behaviour has changed). Thanks.
Posted by: mrowboth on November 17, 2005 at 01:30 AM
-
Hi Shannon,
I'm a bit late in reading this - but sooner or later I use to stumble across all the great news :-) Currently I'm especially interested in the back-port portion of the fix as SwingX is developed against 1.5 and our JXTreeTable suffered from the old drag recognizing behaviour. Works fine now with the new property enabled - only I'm slightly concerned about the necessity to have the property set "early" in whatever life-cycle. What exactly is the reason for that requirement ? Naively (didn't look at the code yet), I could envision the fixed recognizer to check for the system property every time it has to kick in or listen to changes (don't even know if that's possible ).
Keep up the good work, Jeanette
Posted by: kleopatra on December 20, 2005 at 07:53 AM
-
Hi mrowboth,
I'm sorry to hear that your application doesn't appear to be working, and I am very interested in getting to the bottom of the problem. We take regressions in Java very seriously. As this is a very extensive fix, it is quite difficult to outline what was changed and which methods were affected. Perhaps we could try another approach?
First, can you please tell me what version of Java you're using (the output of: java -version)? Second, would you please explain to me the nature of the problem? Third, and the most helpful, would you care to file a bug in Sun's bug database with a test case (which can remain confidential if you choose)? If you post the "review id" as a comment here, I will immediately pull the bug into our database and investigate the problem. Will this work for you?
Thanks!
Posted by: shan_man on December 20, 2005 at 09:24 AM
-
Hi kleopatra! I hope things are going well with you :)
I'm happy to hear that this backport is beneficial for SwingX - thanks for sharing with me! I'd like to answer your question and explain why the backport is implemented as it is. First, please let me point out again that this backport enables "correct" behavior that we've turned on as the only option in Mustang. The reason we added a property in 5.0 was because we couldn't take a risk on breaking someone in an update release.
Once the need for a property was determined, we had to decide on the type of property. Since this behavior is something we expect developers will turn on (or leave off) all the time, a single set-once global property was determined to be a valid approach. While it could have been made responsive to changes at runtime, that would have required extra engineering and testing, with little benefit. I'll explain:
If you'll recall from my blog, prior to this fix the listeners for selection and for drag and drop were separate entities. With the fix they've been combined into a single listener. For the backport, this new property dicates how the listeners are installed: At UI install time, if the property is unset we install the old pair of listeners. If the property is set, we uninstall the new combined listener. This is more complex than just checking the property dynamically at drag time, and responding to changes in the property would require code to re-install the appropriate listeners on every change. For the reasons I noted above, it did not seem worth it.
Now to the part of your question that asked why the property needs to be set early in the life-cycle. That is partly explained above, in that the property is needed by the UI classes when they're installed. The rest is simply a result of which class reads the property. It happens to be read upon the loading of a Swing utilities class that is used in many places in Swing, and therefore loaded quite early. The reading could be moved to another location to be slightly later. But the very latest is upon UI installation for the affected components, and there'd not be much benefit. Again, since we expect this to be set on the command line or in a JNLP file, there's no reason to modify this.
Hopefully I've satisfied your query by explaining the implementation. By all means, please let me know if you have any further questions. All the best!
Posted by: shan_man on December 20, 2005 at 10:26 AM
-
Hi Shannon,
thanks for your thorough explanation, yeah I'm fully satisfied (and agree with you :-)! Turned out that we can enable it via setProperty as long as it's done before any call to the Swing subsystem - we'll happily live with it.
Merry X-Mas and Happy New Year.
Posted by: kleopatra on December 22, 2005 at 09:56 AM
-
Neat. Now if only it dropped the elements at the location in the list the mouse is pointing at, we'd have ideal drag and drop. :-)
Posted by: trejkaz on February 16, 2006 at 04:28 PM
-
Hi trekjaz. I'm not sure I understand what you mean in your comment, and you've caught my attention - I definitely want to have ideal drag and drop. Have you read my blog on First Class Drag and Drop Support in Mustang? With this support, you are given the exact location when dropping in a list, so you can import to that location. Is that what you need? Thanks!
Posted by: shan_man on February 16, 2006 at 07:31 PM
-
Hi Shannon, I need to enable the enableImprovedDragGesture property for an application in a project at our company. Whenever I start the application as a normal Java application, everything works fine, but when I try starting it as an applet, the property is not set. The problem is that the property is set too late, since in an applet, some SWING-components are already initialized. I'm currently setting the property in the static block of my applet class (which inherits from JApplet), but even this seems to be too late. So, is there some way to set the property earlier in an applet or is there maybe some other way to force SWING to re-read this property? Any help would be highly appreciated! Thanks in advance!
Posted by: ojm on May 02, 2006 at 12:59 AM
-
Hi ojm! As you've noticed, and for the reasons I've outlined above, this property is read by Swing very early in its lifecycle. Unfortunately, there's no way to have Swing re-query it. That being said, you're on the right track to making it work :)
At first I saw absolutely nothing wrong with your approach of setting the property in a static block in your JApplet subclass. Of course, you'd need to ensure the applet had the appropriate permission granted for writing this property, but you said the property wasn't working, not "my applet failed with a security exception", so I assume you've done this.
But I mentioned "at first", didn't I?... In fact, I tested out your approach, wrapped the applet in a frame for display, launched it, and it worked fine! This made it even more puzzling that it wasn't working for you. So I continued, and tried running the applet in a browser, and aha! - it didn't work. I decided to do some debugging to see what was responsible for causing the property to be read before the applet was loaded. And it turned out to be the Java console.
The Java console, which seems to be launched before any applet, uses Swing - causing the property to be read. As such, I imagined that not showing the Java console would solve the problem. And sure enough, when I changed the setting in the Java control panel to hide the console, the property started working. Would you care to give it a try and let me know if this solves it for you? Thanks!
Posted by: shan_man on May 03, 2006 at 08:10 PM
-
Hi Shannon! First of all thank you very much for all your effort in helping me out with my problem. I was really very pleased about your kind support!
Probably, I could have saved you some testing if I had been more precise, sorry: In fact, the permission for setting the SWING property is granted in the policy file, so this wasn't the problem. Furthermore, starting the applet in an applet viewer (actually from within Eclipse) also worked fine, as it did for you. But (as there is always a but... ;)) starting the applet from within a browser did not work, just as it did not for you.
But (and that's now definitely a nice but!) the bad guy indeed seemed to be the Java console as you have pointed out. Simply not displaying it did also the trick for me! Now, everything is working fine and I am pretty happy :-). I guess I would never have come to that conclusion so thanks a lot again! All the best!
Posted by: ojm on May 05, 2006 at 06:53 AM
-
Hi Shannon!
We've got a customized JList and use a spezialized TransferHandler as well as a DragGestureAdapter which initializes DragSource with:
DragSource.getDefaultDragSource().createDefaultDragGestureRecognizer(
(Component) this.dragComp, action,
this);
What could be the reason, that the new DnD doesn't work with that configuration?
As long as we use just setDragEnabled(true) on our JList and don't use the customised DnD Infrastructure, it seems to work.
Java Version is 1.5.0_06
Your suggestions are appreciated!
Posted by: franzb on July 10, 2006 at 08:01 AM
-
franzb:
Your drag gesture recognizer will be competing with the one installed by the swing DnD support. Either one may trigger a drag, which will cause the other to fail. If you don't actually need the drag gesture recognizer, get rid of it.
I don't think there's a way to override the swing DnD drag gesture recognizer without either setDragEnabled(false) or setting the TransferHandler to null (I've been looking).
If you need to listen to drag events, you can still add a listener to the DragSource.getDefaultDragSource() when your transfer handler does exportAsDrag (and remove itself when it gets dragDropEnd).
Posted by: twalljava on July 15, 2006 at 06:19 PM
-
Hi Shannon! Thank you for improving the drag gestures and this blog entry, both have been helpful to me. Like 'leischj' I too desire a table to always use the improved drag behaviour because we represent list of objects in a table and only allow row selections including multiple selections. I have voted for bug 6349223 but I can't wait until dolphin. :-) Do you have any suggsetions? For what its worth, if I comment out your qualification in BasicTableUI.DragFixHandler#canStartDrag and then I get my desired behaviour:
private boolean canStartDrag() {
if (pressedRow == -1 || pressedCol == -1) {
return false;
}
if (isFileList) {
return !outsidePrefSize;
}
// if this is a single selection table
// if ((table.getSelectionModel().getSelectionMode() ==
// ListSelectionModel.SINGLE_SELECTION) &&
// (table.getColumnModel().getSelectionModel().getSelectionMode() ==
// ListSelectionModel.SINGLE_SELECTION)) {
return true;
// }
// return table.isCellSelected(pressedRow, pressedCol);
}
Posted by: mschmiderer on September 13, 2006 at 02:38 PM
-
franzb: It is recommended that you not use AWT drag gesture recognizers with Swing drag and drop components that provide this support for you. These components need special drag recognition that interacts well with their selection logic, and this is the reason we've provided setDragEnabled().
The enhancements described in this blog were made to Swing's drag gesture recognition only, with respect to the way it determines which mouse gestures are selections, and which ones are drags. You'll not see the benefits if you use AWT drag recoginition directly.
I hope this helps!
Posted by: shan_man on November 21, 2006 at 01:02 PM
-
mschmiderer: You've definitely got enough insight into the code to know where the fix belongs! This is exactly where I plan to update the code when it's time to fix 6349223. Unfortunately, I can't think any nice way for you to insert this logic outside the class itself. I'm sorry!
Posted by: shan_man on November 21, 2006 at 01:13 PM
-
I've been trying for some time to solve a problem with drag and drop with our JTree. The problem is that the selection of the tree item happens on the user presses on it rather than when the user clicks it (presses and releases on it)
Imagine a layout like windows explorer. You can select one directory in the tree to show its files in the fileview. You can then mouse press on a different directory in the tree and drag that directory into the fileview of the one selected.
At no point after selecting the first directory does the tree selection change.
I'm not trying to write my own windows explorer but my problem is very similar. We have a component that shows the details of the selected node by listening to the selection change of the tree to keep itself updated. It should be possible for me to drag other treenodes into that view to effect it but at the moment the act of dragging triggers a selction change event and the view is lost.
Any suggestions?
I've done plenty of googling and searches on the sun forums (which is where I found your link here)
Posted by: bobtarling on January 05, 2007 at 12:29 PM
|
java.net RSS Feeds
