Trust is hard to build and easy to destroy
What, why, when and how – these are the questions that shape the communication between the product developers and their users. Different teams choose different levels of opacity regarding these four questions, and making the answers more opaque over the time leads to a building frustration among the community members. This has been one of the major reasons behind my post on the current state of core Swing, and allow me to further explore this area.
Open-sourcing Java during the JavaOne 2006 and the announcement of OpenJDK project was hailed by Sun as the new era for Java, where everybody can lend their hand in shaping the future of the Java platform. Specifically in the client area, the summer of 2006 has supplied Swing developers with such gems as Chris Campbell’s entry on soft clipping, Chet Haase talking about Java on Vista, official birth of JSR 295 and JSR 296, as well as lively discussions on the SwingX painters and layers. Those have been exciting times for me personally, as they showed a renewed and well backed interest in the Java client side development.
Unfortunately, the last eighteen months have been quite disappointing. The level of openness (or transparency, if you will) set in the summer of 2006 was not a genuine and lasting commitment to the community, which has been effectively shut not only from participating in the decision making process, but in following it as well. And this brings me back to the four questions – what, why, when and how.
The how is perhaps the easiest one, and Java has always been shipped with the matching source archives. This has allowed the users to understand not only how the specific piece works, but also how to work around the specific bugs in order to achieve the required functionality. Even if the internal technical design documents (if any are present) are not available to the community, the full source code is an excellent reference guide to a deeper understanding of the platform and becoming a better Java developer in the process.
The answer to when allows bigger projects to estimate timelines for the different technologies, both existing and emerging. In this area, Java has not been a great success over the last three years. The new 18-month release cycle for major versions (announced at JavaOne 2005) which would have Java 6 ship in summer 2006 and Java 7 to ship in early 2008 has failed, without any explanation or apology. While the main reason for “slipping” Java 7 is the great work that has gone into Java 6 update 10, we still don’t even have the umbrella JSR for Java 7.
The answer to what allows estimating the functionality for the different technologies in coming to decide which one to use. Will we have a cross-platform Swing web browser component in Java 7? Will we have a public Swing API for translucent and shaped windows in Java 7? Will we have a public Swing API for playing, manipulating and producing video streams in Java 7? Will we have binding layer for Swing applications in Java 7? Will we see modern Swing components such as pivot table or date picker in Java 7? Withholding answers to these questions has been a normal practice for the past eighteen months, and this opacity has resulted in quite a few disappointed advocates of the toolkit.
The answer to why defines the level of trust between you and your community. You can be extremely opaque, not only making your decisions behind closed doors, but also presenting them as the only right way. You can be somewhat translucent and write about the reasons behind the decisions, even when the decisions themselves are made without any input from the community. Or, you can be extremely transparent and have the community participate equally in shaping and moving the platform forward.
Different projects will differ in their level of opacity. One-man open source projects are different from commercial companies that are frequently judged by revenue stream and monetization. You have the extremely opaque Apple and somewhat translucent Microsoft. On the other hand, you have an incredibly open Mozilla that already has 61 posts on its aggregator since the beginning of this week. And in between you have projects such as Qt Labs that are engaging in early feeback cycle about emerging functionality in their toolkit.
The last two examples (Mozilla and Qt Labs) show a continuous level of commitment to the two-way communication with their users. Is this coming from the developers? Is this coming from the management? Does it matter at all to your developer users?
If you’re starting a blog about the product and then abandon it after a few weeks, why start it in the first place? If your project has the word “open” in it and then you want to suppress the discussion about the planned features, why bother pretending? Do you really want to hold all your cards close to your chest if you’re trying to compete against a formidable opponent, especially when many of your pre-announced features are already in his well established offerings? Can you afford keeping the potential developers out of the loop instead of using the power of dev-to-dev blogs to build up the excitement? Is it beneficial to your project to hide behind the “open source you can help us instead of whining” mantra, when my chances as a potential outside contributor to add significant new functionality (as opposed to fixing a bug) are almost non existant?
And lastly, can you justify being “heads down” in development / testing to create a void to be filled with rumors, conjectures, interpretations and wild guesses?
November 13th, 2008 at 1:41 pm
Right on.
November 13th, 2008 at 2:25 pm
i guess you’ll like the final javafx 1.0 sdk license then.
hint: no you won’t – http://hg.netbeans.org/javafx65/file/943800e633e2/javafx_sdk-1_0-license.txt
ps: you actually might laugh – “(f) You may not publish or provide the results of any benchmark or comparison tests run on Software to any third party without the prior written consent of Sun.” . You gotta admit this one is genuinely funny.
November 13th, 2008 at 3:03 pm
Yikes! the SDK will not be GPL?? what about Project SceneGraph and the jfx runtime libraries then? last time I checked they were GPL, talk about “Java(FX) enterprise development”.
November 13th, 2008 at 3:38 pm
I know it’s very general, but here sun states “JavaFX Script will be available under the GPL license”. Maybe they are using more licensensing schemes.
November 13th, 2008 at 3:49 pm
i don’t really know what to think, pretty much since they moved the runtime behind closed doors (to this day, i can’t really understand why).
At the time i predicted that openjfx wouldn’t be open source, while really hoping i’d be wrong.
Scenario and decora are definitely gpl and i believe this won’t (can’t?) change, as are the javafx script compiler and the minimal runtime layer it contains (mostly related to animation and all AFAIK), and the java-css project (another building block for javafx that actually can be of interest for swing devs) – but in the meantime when the license issue is raised, the devs publicly acknowledge the ‘problem’ and expect it license to change sometime in the future. I guess it would be logical to think maybe gpl+classpath exception. Who knows.
No idea about jmc – even though the news of the project was really strongly tied to being open source – or project nile, they both are a part of the secret runtime project.
In the meantime, from what i can tell there are javafx licensees who have access to the tech, in whatever state it is.
Maybe it’s a mistake in the netbeans repo (i don’t think so), we’ll know in 2 weeks.
November 13th, 2008 at 10:26 pm
Nice write-up Kirill, it totally summarizes the picture of the Swing world I have today.
November 14th, 2008 at 12:52 am
awesome post kirill,i wish this could get to the office desk of the JSE team at sun and the swing lead. this article totally summarizes why java kindda lags behind on the client side.
November 14th, 2008 at 7:56 am
Thanks for your voice and support. Your saying what me and many of my colleagues have been talking about since JavaFx started. Thank you for being a strong advocate for Swing.
November 14th, 2008 at 9:45 am
[...] aqui(linha 177), discussão a começar aqui. Categorias.net 6pm Apple Bugs EDMS Genéricos Google IIS iPhone Java Javascript Jogos JSP [...]
November 14th, 2008 at 10:39 am
Totally!
It’s very disappointing that the open sourcing of Java hasn’t had much impact on the desktop as it seems to me that there is lots of good stuff available for inclusion and that there are lots of people out there willing to contribute to an open platform :-(
Lots of projects were promised, no so much has been delivered.
Can we endure any more false starts?
November 14th, 2008 at 1:21 pm
> It’s very disappointing that the open sourcing
> of Java hasn’t had much impact on the desktop
Technically and legally it is open-source. What it lacks is the open-source spirit. That one has been suppressed/killed by Sun. I don’t know what different forces are at work inside Sun. From the outside it seems there are strong forces trying to “protect” the open-source Java code base from non-Sun-ers at all.
The much touted 6u10 wasn’t developed out of OpenJDK or in the open, but behind closed doors. But while Sun doesn’t use OpenJDK for their own purposes they still jealously guard OpenJDK and make it is impossible for impure outsiders to get something changed in it.
> Lots of projects were promised
This is a big problem with Sun, when it comes to Java. Lots and lots of broken promises. Each abandoned API a broken promise. Each half-baked API a broken promise. Each long standing bug, or closed without a fix bug a broken promise.
Someone routinely breaking promises like Sun is called a notorious liar in a honest girl’s book. One doesn’t trust a notorious liar. All “what, why, when and how” done right doesn’t help when you are a notorious liar.
November 14th, 2008 at 1:40 pm
“But while Sun doesn’t use OpenJDK for their own purposes they still jealously guard OpenJDK and make it is impossible for impure outsiders to get something changed in it.”
That’s ridiculously uninformed nonsense. There are regular patches going into different OpenJDK projects from contributors outside Sun.
Of course Sun uses OpenJDK for its own purposes, that’s where the development of Hotspot, Da Vinci VM, etc. is taking place, where OpenJDK 6 you are seeing in all Linux distributions is coming from, and so on.
November 14th, 2008 at 1:53 pm
Hi kirill, hi all,
You have taken Mozilla as an example of vibrant community, I agree with you but Rome wasn’t built in a day.
Open sourcing big codebase take LOT of times,
for Mozilla the codebase was opensourced in March 1999 and Mozilla 1.0 was released in June 2002.
my 2 cents,
Rémi
November 14th, 2008 at 2:17 pm
Another great post by Kirill. Keep up the good work!
November 14th, 2008 at 3:27 pm
Not laying blame about why, but Swing does lack community vitality. Compare Swing:
http://lists.wxwidgets.org/pipermail/wx-dev/2008-October/thread.html
with WxWidgets:
http://lists.wxwidgets.org/pipermail/wx-dev/2008-October/thread.html
Or maybe I’m comparing the wrong things?
November 14th, 2008 at 3:28 pm
This was supposed to be the Swing link:
http://mail.openjdk.java.net/pipermail/swing-dev/2008-October/thread.html
November 14th, 2008 at 4:02 pm
> That’s ridiculously uninformed nonsense.
> There are regular patches going into different
> OpenJDK projects from contributors outside Sun.
Sure, they are allowed to do things, in particular things Sun engineers feel they are above: Fixing bugs. What the aren’t allowed to do is doing real changes. And they have to play nicey nicey with their Sun-assigned babysitters. Sun is treating contributors as cheep labor, not as equal developers. And they don’t trust the cheap labor.
> Of course Sun uses OpenJDK for its own
> purposes,
So what part of 6u10, Sun’s latest and greatest thingy, is based on OpenJDK? What part of it was developed in the open?
> OpenJDK 6 you are seeing in all Linux
> distributions is coming from,
And everyone with his or her head in the right place doesn’t use it, but uses Sun’s JRE and JDK for serious applications on Linux. Just so to get the same features, same bugs and broken behavior one finds in the Sun Windows versions. And the Sun versions come from a separate, closed source code base, not from OpenJDK.
And what about Sun’s pathological habit to lie? The half-life-period of the validity of Sun statements regarding desktop issues is now in the range of six month.
November 14th, 2008 at 6:15 pm
The amount of hate toward SUn, even in the Java community itself, is really incomprehensible for me. Of course, some people feel that Sun is never opened enough. They are said to waste their time on JavaFX (not completely opened yet, which surely proves they lied to us when they first opened Java) rather than working hard on Swing. And at the same time, some people (sometimes the same, but I reckon not always) praise Microsoft for being more and more open (.NET vs Mono / Silverlight vs Moonlight), or Adobe to provide use the new ultimate RIA development platform.
We should maybe open our eyes a little, recognize that Sun have serious problems (see the last results, and the lay-off of 16% of their workforce), and pray that they will still be there in some years. “And the Sun versions come from a separate, closed source code base, not from OpenJDK.” => please, please stop to debunk everything they do. Sun’s JDK and OpenJDK ARE coming from the same source code base, but Sun did not have all of the JDK’s intellectual property. Hence they rewrote the parts they could not release as GPL (or seek Open source alternatives for them).
November 14th, 2008 at 9:23 pm
Perfect post… you expressed some of my sentiments exactly. Sun wants to be open source, but simply doesn’t seem to be able to cope with the open source model.
I sat through a JavaFX presentation in July and watched someone from Sun explain how they had taken all this Javadoc functionality and fixed it in ways that the community has been asking for FOREVER, but couldn’t be bothered to apply those fixes back to regular old Java’s javadoc and the guy blamed it on open source.
It killed me. Sun has made themselves irrelevant, and sunk Java with them, and they don’t even know it yet :(
November 15th, 2008 at 3:24 am
@Hervé
> The amount of hate toward SUn, even in the
> Java community itself, is really
> incomprehensible for me.
I think you misunderstand, I don’t think the comments here or Kirill’s original post are an expression of hate or even mistrust, more I think it’s an expression of frustration, not the usual Sun bashing.
I don’t believe Sun should be held responsible for everything in the Java world, but there is obvious confusion about the direction of Java and the lack of a visible, coherent and sustainable mechanism for getting involved, for contributing, can only exacerbate this situation.
Once bitten, twice shy.
November 15th, 2008 at 3:39 am
@Luan O’Carroll: I was not specifically referring to Kirill’s post, but to *some* of the comments here ;-)
November 15th, 2008 at 7:03 am
> please, please stop to debunk everything they
> do. Sun’s JDK and OpenJDK ARE coming from the
> same source code base,
No, they don’t. Sun is maintaining a separate source tree behind closed doors for their commercial Java releases. But read it in Sun’s own words, e.g. in this discussion http://mail.openjdk.java.net/pipermail/discuss/2008-September/001299.html where Dalibor Topic, Sun’s Java open source ambassador, explains why 6u10 won’t be open, and referring to the “Closed 6″ source base. Pay special attention to the first few words:
“Given that the new deployment code wasn’t started and developed in the open, it means a lot of the decisions that may appear obvious from outside have to be made explicitly and carry a non-trivial implementation cost, for example in lawyer-time, or syncing between OpenJDK 7 and Closed 6 – so there is a pretty good economic argument to be made for finishing off the work on 6u10 first, and getting the new deployment code out of ‘beta’, before a decision to push it into the OpenJDK 7 tree can be made.”
Or read it in Sun’s own OpenSource FAQ http://www.sun.com/software/opensource/java/faq.jsp#h4_5
And note the typical Sun “promises” in both references, too.
But lets go back to Dalibor’s first sentence “Given that the new deployment code wasn’t started and developed in the open …”. This apparently deliberate decision is so absolutely typical of Sun. There must be very strong forces inside Sun throwing spanners in the works whenever and wherever they can. A few comments above Martin reported about an JavaFX presentation. This also fits Sun’s modus operandi perfectly.
The discussion here is about trust, building it, keeping it, and destroying it. That behavior of Sun is certainly not building trust, but a good example of destroying what little remains. The conclusion from observing Sun’s past and present behavior really must be that one could never trust Sun, one can’t trust Sun now. And when it comes to desktop issues Sun has a pathological habit of breaking promises.
@Hervé
If you have a problem with a comment then name names. Shouting “someone is being bad” is just childish and what bullies do.
November 15th, 2008 at 6:32 pm
Well said Mr. Grouchnikov.
Daniel
November 16th, 2008 at 5:00 am
@Esra Ygdragor: I avoided to name someone specifically in my own comment, because this would have been childish IMHO, but it seems that it did not stop you from feeling attacked ;-) Please note that I did not write anywhere that “someone is being bad” though ;-)
Considering Dalibor Topic post, you are going too far when you say that “Sun is maintaining a separate source tree behind closed doors for their commercial Java releases”. In short, you are seeing what you want there, not the reality.
November 16th, 2008 at 10:43 am
http://forums.java.net/jive/message.jspa?messageID=308361#308361
“JDK 6 is not based on OpenJDK 6 – the code for JDK 6 has been branched off before OpenJDK 7, from which OpenJDK 6 was branched off.”
Found via reference from
http://blogs.sun.com/darcy/entry/openjdk_6_and_6u10_features
Where you can also read:
“OpenJDK 6 build 12 contained ports of bug fixes from a number of 6u10 component areas (corba, jaxp, jaxws, langtools). Most changes from the core jdk component area of 6u10 were not ported.
…
We at Sun do not plan to do a wholesale port of those 6u10 features from the core jdk to OpenJDK 6. … we will be porting those 6u10 features to OpenJDK 7 … (These jdk area features in 6u10 are separate from plugin and webstart functionality.)”
Why port something if it wasn’t developed separately? And note that the browser plugin and webstart are completely excluded from that porting promise. BTW, a “Sun promis”, and we know how good these are.
And later down in the comments
“6u10 is not developed on top of OpenJDK since SE 6 was branched off before OpenJDK happened.
There is no link to a repository for 6u10. Even if there was, it wouldn’t be of much use to you without Teamware, the Sun-internal non-free DVCS tool used internally for SE 6 development.”
And Hervé, I smell a bully from miles away. You awfully smell like one. I can point to statements from Sun sustaining my claims, while you make baseless claims and attacks.
But let me repeat my questions you have avoided so hard:
So what part of 6u10, Sun’s latest and greatest thingy, is based on OpenJDK? What part of it was developed in the open?
May I summarize? Non. Sun is developing the commercial versions, including 6u10, from a completely separate, behind closed-doors, source tree – still managed with their old own version control system, incompatible with the one used for OpenJDK. Some call this separate tree “Closed 6″, or “core jdk”. Whatever it is called, it exists, and 6u10 is based on it and not based on OpenJDK, not OpenJDK 6 and not OpenJDK 7.
Further, Sun has already stated that not many of the 6u10 changes will ever be ported to OpenJDK 6. And they made a typical Sun “promise” that most of the 6u10 changes might be ported to OpenJDK 7. And they further stated that webstart and the plugin won’t be ported at all.
And that is supposed to build trust?
November 16th, 2008 at 4:38 pm
congratulations Kirill!
You are the first one who sums up all the things that I was thinking about in the last few months!!
Awesome post!
November 16th, 2008 at 5:17 pm
@Esra: I think you are very cynical and are making a bigger deal of this than you need to. I use lots of Sun software and hardware and all of it is -excellent-. My bug reports and RFEs are taken seriously and I have a lot of trust in Sun. I also understand how long of a process it is for them to take a project as large as OpenJDK and go fully open. Rémi pointed out that it took 3 years for Mozilla to go fully open with a 1.0 release. Sun will probably be fully open with JDK7. JWS and browser plugin not being open is a bit odd, but I really don’t care.
November 16th, 2008 at 8:31 pm
The present situation of Java is really disheartening. If initial open source initiatives would not have been there then pain would have been less.
November 17th, 2008 at 5:11 am
“Sure, they are allowed to do things, in particular things Sun engineers feel they are above: Fixing bugs. What the aren’t allowed to do is doing real changes. And they have to play nicey nicey with their Sun-assigned babysitters. Sun is treating contributors as cheep labor, not as equal developers. And they don’t trust the cheap labor.”
Eh, that’s nonsense. More than a handful of projects within OpenJDK are actively led and maintained by developers outside Sun, and they do quite real changes, from a new Java 2D pipeline, to enhancing the GUI backends for portability purposes, to a BSD port, annotations on types, and more.
Since OpenJDK mercurial infrastructure was put in place 6 months go, the project has gone to have around 20 developers with commit access outside Sun. So to assert that Sun doesn’t trust external developers is baseless.
As far as getting patches past the review process is concerned, yes, that’s how open source development is done on real world projects; you discuss changes, you write a patch, you write corresponding tests, and repeat the process until you and the reviewers are happy with the result. OpenJDK is not different from other serious open source projects in that respect: there is a process to follow if you want to get your changes in. Like, say, https://developer.mozilla.org/en/Hacking_Mozilla , or http://www.eclipse.org/projects/dev_process/development_process.php or even http://ldn.linuxfoundation.org/how-participate-linux-community
Deriding that as baby sitting misses the whole point of open source development.
“So what part of 6u10, Sun’s latest and greatest thingy, is based on OpenJDK? What part of it was developed in the open?
May I summarize? Non. ”
That’s wrong. 6u10 includes Hotspot version 11, which was released as part of OpenJDK 7 a while ago, and went into Linux distributions first through free software projects working closely with OpenJDK.
The Hotspot team is now on to version 14 in the OpenJDK repositories, btw. – so Sun is not hiding the stuff being worked on, as you seem to imply.
“Sun is developing the commercial versions, including 6u10, from a completely separate, behind closed-doors, source tree – still managed with their old own version control system, incompatible with the one used for OpenJDK. Some call this separate tree “Closed 6″, or “core jdk”. Whatever it is called, it exists, and 6u10 is based on it and not based on OpenJDK, not OpenJDK 6 and not OpenJDK 7.”
You seem to assume there is a massive conspiracy here somewhere to keep the public in the dark, but it’s not: http://blogs.sun.com/darcy/entry/openjdk_6_genealogy describes the process how OpenJDK 6 came to be. It didn’t make a lot of sense to do the same engineering and legal work necessary for an open source release twice both on the SE 6 maintenance branch and on the SE 7 trunk, so it was done once on the trunk for SE 7, with an eye on the future.
“Further, Sun has already stated that not many of the 6u10 changes will ever be ported to OpenJDK 6. And they made a typical Sun “promise” that most of the 6u10 changes might be ported to OpenJDK 7. And they further stated that webstart and the plugin won’t be ported at all.”
You’re apparently deliberately parsing it wrong.
What has been said is that Sun won’t be doing the backporting work to OpenJDK 6 – that does not mean others won’t want and be able to step up to do it. The backporting work for most workspaces has been done, and Joe has written at length about it in his blog: http://blogs.sun.com/darcy/entry/openjdk_6_logistics_of_partial
The OpenJDK 6 builds in Linux distributions have included backported fixes from OpenJDK 7 for a while already, before those have hit the OpenJDK 6 source code archives, so the community backporting part of the process has worked pretty well in practice so far.
As far as porting ‘most’ of the changes to OpenJDK 7 goes, the 6u10 release contains some non-free code from third parties, so naturally changes to such code can’t be put straightforwardly into OpenJDK 7. Other changes may no longer apply because we’ve moved three revisions ahead with Hotspot, for example, and so on.
There is a whole lot of rational reasons why not all changes from an old maintenance branch of a project are usually pushed forward onto the trunk – but I understand that viewing such things rationally is not very helpful to build up your case against Sun and/or OpenJDK.
As far as the plugin goes, Sun hasn’t actually said ‘NO!’ to porting the plugin / webstart from 6u10 into OpenJDK 7 as you claim – all that’s been going on so far is a discussion within Sun, that hasn’t resulted in a decision being made yet. That, too, is rather understandable, in my opinion: there is a community developed plugin / webstart implementation that works on GNU/Linux (including the 64 bit Linux desktop), so it makes more sense to concentrate on more pressing issues, like, for example, bringing the changes from 6u10 into OpenJDK 7, so that bringing over the plugin/webstart code can follow, once the decision to do it is made.
November 17th, 2008 at 6:47 am
@Esra: It’s funny… I read even just the bits of Sun posts that you quote and I come away with a totally different message and attitude.
Do you understand that Sun already had things under development in a closed source context that they couldn’t simply open on a whim? The fact that they have committed to moving 6u10 things to OpenJDK7 (based on what you have quoted) shows me that they are trying to get things into the open codebase. Just because it didn’t happen in time for OpenJDK6 – as they made clear in their own posts – you want to whine about it. There isn’t anything sinister there.. OpenJDK6 was branched and being prepared for the new license while a much-needed release was being pushed out from the original codebase. It made sense to do it that way because OpenJDK6 codebase was addressing other issues and it was uncertain (or known for sure) that it would not be ready for a proper release. That happened exactly as Sun said it would. Promise kept.
Even if Sun wants to continue to use a closed branch for their own releases, that is also nothing new in the Open Source world.
Be thankful for what you have been given, for free. Rather than whining about what someone else has’t done for you. When Suns starts charging for Java and the JDK, then we have a right to complain. For now, if you don’t like it, don’t use it. If enough people do that Sun will have no choice but to pay attention. Those that don’t move to something else are okay with things so far. Note that in the blogosphere it seems that many are moving on… so I’m not saying it’s the wrong choice… I just wonder what the numbers really look like.
November 18th, 2008 at 3:07 am
Hm.
I don’t know what to think.
I’ve been coding Swing for about 10 years now, slowly getting sucked in deeper and deeper.
Swing itself I find not extremely mature, how come a JTextField doesn’t have a text-changed property event? Why is there a renderer AND an editor for cells in a JTable (do you really want those two to look different)? And JComboBoxes… Well, ah… All in all I often find myself wondering what things are as complex as they are.
And at times I’m wondering if I should drop Swing. Maybe C# with wxwidgets? Whatever. Swing seems like a good first attempt to build a GUI layer. Then you start using it and find it lacks features important in the real world (no sorting in tables until 1.6?).
On the other hand, Swing is extremely flexible. It is not without reason that projects like SwingX and flamingo exist and make it possible to hook in all over the place. This is what I’m doing all the time; I need to know if a getValueAt is for a renderer or an editor? Find that hook.
So Swing is technically great, but practically it lacks. It needs a big work-over with some major refactoring, and would break backward compatibility.
Actually a new GUI framework would not be bad. Take what we know from Swing, learned from experience, and redo it. Keep the lowlevel repaint logic of Swing and rework the components ground up.
Hey.
Hm. In JavaFX maybe?
November 18th, 2008 at 5:46 am
@Tom
> how come a JTextField doesn’t have a text-changed property event?
Document d = textField.getDocument();
d.addDocumentListener(…);
http://java.sun.com/j2se/1.4.2/docs/api/javax/swing/event/DocumentListener.html
> Why is there a renderer AND an editor for cells in a JTable (do you really want those two to look different)?
You joking aren’t ya? There are plenty of use cases in which it makes sense to use two different components as the editor and the renderer.
November 18th, 2008 at 7:34 pm
“Sure, they are allowed to do things, in particular things Sun engineers feel they are above: Fixing bugs. ”
Funny. I don’t consider VisualVM, the MIPS, haiku and *BSD ports, and other projects to be “bug fixes”…
I agree with other commenters, instead of attacking Sun, we should thank them for opening as much as they could from the Java code base… and thank for it’s inclusion on the fedora and ubuntu repositories… thankfully, that will bring new developers to the Java ecosystem..
November 19th, 2008 at 2:20 am
@Behrang, text-changed property event
Sure, there is a way to get to the events, but its not natural / simple / logical. I have a textfield and I want to bind it. For an experienced coder this is no problem, but it is not “simple”.
@Behrang, jtable
Nope. Not kidding. Show me one usecase that is not technical in nature. I’m currently writing a lot of complex cell editors, but always use a Editor-To-Renderer wrapper because I have no need for a special renderer. Yes, I know technical reasons enough to use special renderers (speed), but that is not what I referred to.
November 19th, 2008 at 4:30 am
@Tom
Rendering a color as a filled rectangle but editing it as RGB values? There are plenty of other use cases and if you are not convinced I’ll post more…
November 19th, 2008 at 4:31 am
However lets not change the focus of this article. The thing is Sun doesn’t listen to its users when it has to :-)
November 19th, 2008 at 4:54 am
Great article, summarizes the state of affairs as I see it.
In the meantime NOT waiting for JavaFX yet and continuing using my own Swing hacks.
We will hopefully see a date picker in Java version 13…
November 20th, 2008 at 7:25 am
@Behrang: agreed :-)