On Sun, Feb 1, 2009 at 1:17 AM, Holger Brands
<hbrands@...> wrote:
Hey Glaziers,
now that 1.8 is real, I just wanted to ask for your opinion
what the next version should be (1.9 vs. 2.0) ?
If we're directly heading for a 2.0 release, we should probably
create a 1.x branch for bugfixes.
Initial ideas for a 2.0 could be:
- drop migration kit and other deprecated code
- drop JDK 1.4 support (Sun J2SE 1.4.x EOL is October 30th, 2008)
- fully exploit JDK 1.5 capabilities throughout the code base
- make other changes that could break compatibility but are worth
the effort, for example removing automatic proxy wrapping in the
model adapter classes
...
I've got some ambitious ideas for 2009...
EventBus. We can go overboard on this, but getting a good balance between capability and simplicity is hard.
Rewrite ListEvent. It should include the deleted element and support a move event. I had a long talk with Josh about this about a year ago, and if we got something really good we might even be able to propose a minimal API as a JSR. I'd like this to have a regular Builder and to act more like a value object.
Rewrite TreeList on the new ListEvent. The current TreeList code is pretty clumsy and doesn't report selection events very well.
Android support.
GWT support. Even if we just create an alternate implementation that's API-compatible, that would be handy. Programming ListBoxes and friends on GWT by hand works, but it's not nearly as fun as Glazed Lists. Not to mention dynamic <table>s, <ul>s, etc. Getting Glazed Lists ease-of-development on an AJAX model would really hit home for some apps.
JavaFX support. Sun is pushing JavaFX as 'Swing v2', so I'm curious to check it out. All of their Java rockstars are working on JavaFX, so the platform probably has a bright future.
Tidy up. (support removed code using a migrationkit package)
Kill SeparatorList (mostly obsoleted by TreeList)
Merge RangeList and ThresholdList
Kill FreezableList
Merge CollectionList and CompositeList
Merge TextFilterator/TextFilterable
Integrate with Google Collections. I'm unsure how well this will sell with the Glazed Lists-using masses, but naturally I'm a big fan of Google Collections, which I think of as "Java Collections API 2.0". It could be convenient for our users if:
- we used their Matcher interface. Google Collections' Matcher is coming soonish, and it's fluent!
- we shared the same Function interface.
- we shared the same Ordering interface.
I suspect I'll have trouble convincing others of this, so I'm not totally insistent on this.