next GL version?
|
View:
New views
12 Messages
—
Rating Filter:
Alert me
|
 |
next GL version?
by Holger Brands
::
Rate this Message:
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: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: next GL version?
by Rob Eden
::
Rate this Message:
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 <hbrands@...> wrote: Hey Glaziers, |
|
|
Re: next GL version?
by James Lemieux
::
Rate this Message:
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 <rob@...> 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. |
|
|
|
|
|
Re: next GL version?
by Rob Eden
::
Rate this Message:
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 <rob@...> >> 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 <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 >> ... >> >> 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: dev-unsubscribe@... >> For additional commands, e-mail: dev-help@... >> >> >> > > > __________________________________________________________________ > Deutschlands größte Online-Videothek schenkt Ihnen 12.000 Videos!* > http://entertainment.web.de/de/entertainment/maxdome/index.html > > > --------------------------------------------------------------------- > 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@... |
|
|
Re: next GL version?
by Jesse Wilson
::
Rate this Message:
On Sun, Feb 1, 2009 at 1:17 AM, Holger Brands <hbrands@...> wrote: Hey Glaziers, 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. |
|
|
|
|
|
Re: next GL version?
by Jesse Wilson
::
Rate this Message:
On Fri, Feb 6, 2009 at 10:00 AM, Holger Brands <hbrands@...> wrote:
With regard to additional platform support (GWT, JavaFX, Android), I guess 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 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, Fantastic. I'm undecided on whether we should break compatibility by getting rid of our lock wrappers. |
|
|
Re: next GL version?
by Rob Eden
::
Rate this Message:
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@... |
|
|
|
|
|
|
|
|
Re: next GL version?
by Endre Stølsvik
::
Rate this Message:
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 <hbrands@...> 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 <hbrands@...> 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: dev-unsubscribe@... > For additional commands, e-mail: dev-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
| Free embeddable forum powered by Nabble | Forum Help |
