« Return to Thread: next GL version?
Re: next GL version?
by Holger Brands
::
Rate this Message:
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@...
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@...
« Return to Thread: next GL version?
| Free embeddable forum powered by Nabble | Forum Help |
