next GL version?

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

next GL version?

Holger
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
...

On the other side, a 1.9 release could also make sense to
- finish some work that's not yet completed (providing deleted element for example)
- add minor new features without breaking compatibility
- review code base and deprecate things we want to change or drop in 2.0

What do you think?

Holger


____________________________________________________________________
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: next GL version?

Rob Eden
I guess I'd like to flesh out these ideas for event delivery (the EventBus). It seems that many (most?) of the problems that are coming up on the user list these days are due to event ordering, etc. I don't know that we're going to find a perfect solution, but it might be the biggest need. Obviously this would be a 2.0 thing because I'm sure some API's would break.

Rob

On Sun, Feb 1, 2009 at 3:17 AM, Holger Brands <[hidden email]> 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
...

On the other side, a 1.9 release could also make sense to
- finish some work that's not yet completed (providing deleted element for example)
- add minor new features without breaking compatibility
- review code base and deprecate things we want to change or drop in 2.0

What do you think?

Holger


____________________________________________________________________
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: [hidden email]
For additional commands, e-mail: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: next GL version?

James Lemieux
I filled in the build.xml file with 1.9 as the next version number.

I think maybe, until we see 2.0ish kinds of features making their way into the GL codebase we should conservatively keep the next planned release as 1.9. What's a 2.0 kind of feature? Something like:

- deleted values on ListEvents everywhere...
- move types in ListEvents
- reworked ListEventPublisher / ListEventAssembler

Though I can't wait until we can start using 1.5 features everywhere in the code base. (particularly foreach, real var args, and autoboxing)

James

On Sun, Feb 1, 2009 at 12:25 PM, Rob Eden <[hidden email]> wrote:
I guess I'd like to flesh out these ideas for event delivery (the EventBus). It seems that many (most?) of the problems that are coming up on the user list these days are due to event ordering, etc. I don't know that we're going to find a perfect solution, but it might be the biggest need. Obviously this would be a 2.0 thing because I'm sure some API's would break.

Rob


On Sun, Feb 1, 2009 at 3:17 AM, Holger Brands <[hidden email]> 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
...

On the other side, a 1.9 release could also make sense to
- finish some work that's not yet completed (providing deleted element for example)
- add minor new features without breaking compatibility
- review code base and deprecate things we want to change or drop in 2.0

What do you think?

Holger


____________________________________________________________________
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: [hidden email]
For additional commands, e-mail: [hidden email]



Reply | Threaded
Open this post in threaded view
|

Re: next GL version?

Holger
In reply to this post by Holger
Ok, I'm fine with 1.9, too.
So, I guess we don't need a branch (yet).

BTW, if refactoring event data and event delivery is the theme for 2.0,
I'd have no problems to drop JDK 1.4 support in 1.9 already ;-)
Assuming that the next release will take some months at least,
that step would be justifiable in my opinion...

Holger


>I filled in the build.xml file with 1.9 as the next version number.
>
> I think maybe, until we see 2.0ish kinds of features making their way
> into the GL codebase we should conservatively keep the next planned
> release as 1.9. What's a 2.0 kind of feature? Something like:
>
> - deleted values on ListEvents everywhere...
> - move types in ListEvents
> - reworked ListEventPublisher / ListEventAssembler
>
> Though I can't wait until we can start using 1.5 features everywhere
> in the code base. (particularly foreach, real var args, and
> autoboxing)
>
> James
>
> On Sun, Feb 1, 2009 at 12:25 PM, Rob Eden <[hidden email]>
> wrote:
> I guess I'd like to flesh out these ideas for event delivery (the
> EventBus). It seems that many (most?) of the problems that are coming
> up on the user list these days are due to event ordering, etc. I don'
> t know that we're going to find a perfect solution, but it might be
> the biggest need. Obviously this would be a 2.0 thing because I'm
> sure some API's would break.
>
> Rob
>
> On Sun, Feb 1, 2009 at 3:17 AM, Holger Brands <[hidden email]> 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
> ...
>
> On the other side, a 1.9 release could also make sense to
> - finish some work that's not yet completed (providing deleted
> element for example)
> - add minor new features without breaking compatibility
> - review code base and deprecate things we want to change or drop in
> 2.0
>
> What do you think?
>
> Holger
>
> ____________________________________________________________________
> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>


__________________________________________________________________
Deutschlands größte Online-Videothek schenkt Ihnen 12.000 Videos!*
http://entertainment.web.de/de/entertainment/maxdome/index.html


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: next GL version?

Rob Eden
I'm all for it. We dropped support for 1.4 a while back with the Trove  
library. There was a little bit of griping early on, but not too much.  
It's out of support by Sun, so it's quite justifiable at this point.  
It's still used on some (primarily IBM-based) mainframe-type settings  
(AIX, etc.) but that's fairly rare (especially with GL, I would think).

Rob

On Feb 2, 2009, at 1:41 PM, Holger Brands wrote:

> Ok, I'm fine with 1.9, too.
> So, I guess we don't need a branch (yet).
>
> BTW, if refactoring event data and event delivery is the theme for  
> 2.0,
> I'd have no problems to drop JDK 1.4 support in 1.9 already ;-)
> Assuming that the next release will take some months at least,
> that step would be justifiable in my opinion...
>
> Holger
>
>
>> I filled in the build.xml file with 1.9 as the next version number.
>>
>> I think maybe, until we see 2.0ish kinds of features making their way
>> into the GL codebase we should conservatively keep the next planned
>> release as 1.9. What's a 2.0 kind of feature? Something like:
>>
>> - deleted values on ListEvents everywhere...
>> - move types in ListEvents
>> - reworked ListEventPublisher / ListEventAssembler
>>
>> Though I can't wait until we can start using 1.5 features everywhere
>> in the code base. (particularly foreach, real var args, and
>> autoboxing)
>>
>> James
>>
>> On Sun, Feb 1, 2009 at 12:25 PM, Rob Eden <[hidden email]>
>> wrote:
>> I guess I'd like to flesh out these ideas for event delivery (the
>> EventBus). It seems that many (most?) of the problems that are coming
>> up on the user list these days are due to event ordering, etc. I don'
>> t know that we're going to find a perfect solution, but it might be
>> the biggest need. Obviously this would be a 2.0 thing because I'm
>> sure some API's would break.
>>
>> Rob
>>
>> On Sun, Feb 1, 2009 at 3:17 AM, Holger Brands <[hidden email]> 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
>> ...
>>
>> On the other side, a 1.9 release could also make sense to
>> - finish some work that's not yet completed (providing deleted
>> element for example)
>> - add minor new features without breaking compatibility
>> - review code base and deprecate things we want to change or drop in
>> 2.0
>>
>> What do you think?
>>
>> Holger
>>
>> ____________________________________________________________________
>> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>>
>
>
> __________________________________________________________________
> Deutschlands größte Online-Videothek schenkt Ihnen 12.000 Videos!*
> http://entertainment.web.de/de/entertainment/maxdome/index.html
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: next GL version?

Jesse Wilson
In reply to this post by Holger
On Sun, Feb 1, 2009 at 1:17 AM, Holger Brands <[hidden email]> 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.




Reply | Threaded
Open this post in threaded view
|

Re: next GL version?

Holger
In reply to this post by Holger
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 <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: next GL version?

Jesse Wilson
On Fri, Feb 6, 2009 at 10:00 AM, Holger Brands <[hidden email]> wrote:
With regard to additional platform support (GWT, JavaFX, Android), I guess
it depends on the available development resources (our time!) and user demand.

Yup. I'm personally getting involved in Android, so bringing Glazed Lists into the fold there will be something I can take on.
 
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?

Folks who are running on JDK 1.4 aren't interested in new versions of things, so I don't think we should waste effort trying to support them in the future. We'll continue to support our released code. If there's critical fixes, we'll have to create point releases (1.8.1 etc.) so they don't need to upgrade to HEAD.

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)

Fantastic. I'm undecided on whether we should break compatibility by getting rid of our lock wrappers. 


Reply | Threaded
Open this post in threaded view
|

Re: next GL version?

Rob Eden
In reply to this post by Holger
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 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: next GL version?

Holger
In reply to this post by Holger
As I'm currently involved in building a GWT-based application,
I could possibly have a look at GWT support, but not as high priority.

Regarding the lock wrappers, we should also consider
serialisation compatibility:

a) Do we want to be able to deserialize "old" BasicEventLists with the new version?
b) Do we want to be able to deserialize "new" BasicEventLists with an older version?

Basically, I also vote for dropping lock wrappers,
but it could be done in 1.9 or 2.0.
I'd vote for 2.0, unless there will be other (major) API compatibility changes in 1.9...

Holger

> 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 <[hidden email]> 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


_______________________________________________________________________
DSL zum Nulltarif + 20 Euro Extraprämie bei Online-Bestellung über die
DSL Freundschaftswerbung! http://dsl.web.de/?ac=OM.AD.AD008K15279B7069a


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: next GL version?

Holger
In reply to this post by Holger
So, if James also agrees with dropping JDK 1.4 support in 1.9,
I'll create a bugfix branch for 1.8.x
before I go ahead and modify the head version, ok?

Holger

On Fri, Feb 6, 2009 at 10:00 AM, Holger Brands <[hidden email]> wrote:

> With regard to additional platform support (GWT, JavaFX, Android), I
> guess
> it depends on the available development resources (our time!) and
> user demand.
>
> Yup. I'm personally getting involved in Android, so bringing Glazed
> Lists into the fold there will be something I can take on.
> 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?
>
> Folks who are running on JDK 1.4 aren't interested in new versions of
> things, so I don't think we should waste effort trying to support
> them in the future. We'll continue to support our released code. If
> there's critical fixes, we'll have to create point releases (1.8.1
> etc.) so they don't need to upgrade to HEAD.
>
> 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)
>
> Fantastic. I'm undecided on whether we should break compatibility by
> getting rid of our lock wrappers.
>
>
>


____________________________________________________________________
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: next GL version?

Endre Stølsvik
Hi!

What is the reason for not calling such a rather big change 2.0? Seems
like this new version will get a somewhat heavy refactoring in several
aspects.

Why not instead branch on the 1-version? Doing that, you could
potentially release a later 1.9 on that branch if needed, while
focusing on new stuff on the 2-branch, and one wouldn't get such a
huge breach in backwards compatibility while still on the same major
version.

Just my 2c (or however that idiomatic expression goes..)
Endre.

On Thu, Feb 12, 2009 at 19:00, Holger Brands <[hidden email]> wrote:

> So, if James also agrees with dropping JDK 1.4 support in 1.9,
> I'll create a bugfix branch for 1.8.x
> before I go ahead and modify the head version, ok?
>
> Holger
>
> On Fri, Feb 6, 2009 at 10:00 AM, Holger Brands <[hidden email]> wrote:
>> With regard to additional platform support (GWT, JavaFX, Android), I
>> guess
>> it depends on the available development resources (our time!) and
>> user demand.
>>
>> Yup. I'm personally getting involved in Android, so bringing Glazed
>> Lists into the fold there will be something I can take on.
>> 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?
>>
>> Folks who are running on JDK 1.4 aren't interested in new versions of
>> things, so I don't think we should waste effort trying to support
>> them in the future. We'll continue to support our released code. If
>> there's critical fixes, we'll have to create point releases (1.8.1
>> etc.) so they don't need to upgrade to HEAD.
>>
>> 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)
>>
>> Fantastic. I'm undecided on whether we should break compatibility by
>> getting rid of our lock wrappers.
>>
>>
>>
>
>
> ____________________________________________________________________
> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]