JComboBox with Custom ComboBoxModel Not Updating Value on setSelectedItem()

I wrestled with this issue for some time before figuring out the cause, so I hope this helps someone out there. I had a JComboBox with a custom ComboBoxModel. Everything was working fine, except a call to setSelectedItem would do everything it should (fire events, update the selected item property) except it wasn’t updating the displayed value in the JComboBox itself. Clicking the drop-down would even show the correct item selected, and getSelectedItem() returned the correct result; it was just the box itself that was wrong.

Apparently the displayed value in the JComboBox isn’t based on getSelectedItem(), but rather on the top item in the list. I don’t know how or why this is, or if it’s due to some intricacies of my GUI code, but bringing the selected item to the top of the ComboBoxModel‘s item list when calling setSelectedItem fixed the issue. Go figure.

If anyone has any insight into what causes this, please drop a comment!

The Joys of Hibernate

I just spent the last few days troubleshooting a HibernateException with the error message Illegal attempt to associate a collection with two open sessions. After much Googling, I had tried every solution I could find, and none of them worked – so hopefully this solution will make it into the next person’s search.

In my case, the issue was that I was taking a persistent object, storing it in the HTTP session, and trying to reconstitute it later. By storing the ID in the browser session and loading by ID each time, the error was eliminated.

I hope this helps someone – if so, or if you’re having a similar issue, post in the comments!

Sun Opens Java

Ars Technica is reporting that Sun has finally made good on their promise to open up Java for the masses. This is good news for everyone – in fact, the only one whose benefit stands in question would be Sun. While I’m confidant that they will turn this to their advantage, it certainly assuages fears that trouble for Sun might mean trouble for Java – realistic fears when Sun’s financials look shakier and shakier with each passing quarter. Now, if Sun goes down, they won’t take Java with them.

What’s prevented Java being open-sourced before (according to Sun’s PR department) wasn’t an issue of profitability for Java products – after all, the JVM/JRE and JDK are free, and all of their paid products are not being open sourced – it was an issue of branching. Sun was afraid that if they opened up the Java source, we’d see forks which would eventually diverge, bringing about compatibility issues; it’s bad enough having to make sure that a user has the JVM/JRE installed and that they have an adequately recent version, without having to worry about which JVM they’re using out of an array of options which may not all support the same features.

Personally, I think that’s a rather silly fear – they need to revamp Java’s dependency handling anyway, so why not take the opportunity to do so now? Instead of an application saying “I need this version of the JDK or newer”, say “I need to use this library, and this one, and this one” and make sure those are available. This resolves both the issue of determining what your minimum JRE requirement need be, and the issue of diverging forks supporting different featuresets.

All in all, as a Java developer, I can’t see this as anything but a Good Thing(tm).