Re: next GL version?

> Hey Jesse,
>
> these suggestions are ambitious indeed. ;-)
>
> I think we all agree on the first two ideas (event delivery / list  
> event data)
> and their adaption throughout the code base.
>
> With regard to additional platform support (GWT, JavaFX, Android), I  
> guess
> it depends on the available development resources (our time!) and  
> user demand.
>
> To reduce some development and testing effort in the future, I've  
> hinted at
> dropping JDK 1.4 support for the next version.
>
> What do you think of it?
>
> I'd volunteer for making the first two steps, that is,
> the required build-level and implementation-level changes.
> (useful API-level changes could be the third step)
>
> Holger
>
> 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.
>>
>>
>>
>
>
> ____________________________________________________________________
> Psssst! Schon vom neuen WEB.DE MultiMessenger gehört?
> Der kann`s mit allen: http://www.produkte.web.de/messenger/?did=3123
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>