Re: next GL version?

> JavaFX will probably be something I use at least some. However, there  
> are no real "components" like a tree or table to support yet so we'll  
> need to wait for JavaFX 2 before that's even a possibility to support.  
> So, nothing much to do there yet.
>
> As for the lock wrappers... I vote +1 for dropping them. But I'm a  
> performance guy, so you probably could have guessed that already. :-)  
> If we don't support Java 1.4, there's no reason to have them, IMO.
>
> Rob
>
> On Feb 6, 2009, at 12:00 PM, Holger Brands wrote:
>
> > 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@...
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>