[Geoserver-devel] GeoTools/GeoServer java 6 polls: java 6 wins by a landslide

GeoServer GeoServer Developer
1

Hi,
the pools have been out for long enough and we are not getting new
votes, so time to get the results I guess.

GeoTools results:
http://www.micropoll.com/a/MicroPollData?id=423595&mode=html
Long story short: no one fully against, only 5% somewhat troubled.

GeoServer results:
http://www.micropoll.com/a/MicroPollData?id=423614&mode=html
Long story short: 1% sees this as a blocker, 4% somewhat troubled.

It seems to me we can switch both to Java 6 when we want.

And when is indeed the next question. Do we do it now or we wait
for the next stable branch cut?

Pros of doing it now: plenthy of time to shake out the java 6 build issues,
easier life for whoever works only on trunk.

Pros of doing it later: ease of backport, coding on trunk on java 6
we'll have some compile or test issues when backporting stuff
to the stable branch.

My suggestion: let's switch now and let's also try to keep the life
of the current trunk "short", 6 months at most.
Which is half of the usual cycle.

"Now" means anyways organizing ourselves so that by the time
we start using java 6 specific API both project have switched
the compiled mode to java 6, are building there without errors,
and are thus ready to take java 6 api usage withou hiccups.

Opinions?

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

2

I kind of wish we had a 4rd poll - asking the comitters if they have already switched to Java 6 (and just rely on the build box to keep things honest).

I like the idea of switching now; and scheduling the life of 8.x up for a release candidate for foss4g in September. I will make the change proposal; part of switching involves updating the developers guide so we need a list of tasks etc…

Aside: While I have ported the docs over; updating the developers guide remains the responsibility of the PMC. While I am hoping that sphinx allows this to be easier for everyone, I don’t want to give the impression that I will update the docs for every last thing we do (or even every second thing).

Jody

Hi,
the pools have been out for long enough and we are not getting new
votes, so time to get the results I guess.

GeoTools results:
http://www.micropoll.com/a/MicroPollData?id=423595&mode=html
Long story short: no one fully against, only 5% somewhat troubled.

GeoServer results:
http://www.micropoll.com/a/MicroPollData?id=423614&mode=html
Long story short: 1% sees this as a blocker, 4% somewhat troubled.

It seems to me we can switch both to Java 6 when we want.

And when is indeed the next question. Do we do it now or we wait
for the next stable branch cut?

Pros of doing it now: plenthy of time to shake out the java 6 build issues,
easier life for whoever works only on trunk.

Pros of doing it later: ease of backport, coding on trunk on java 6
we’ll have some compile or test issues when backporting stuff
to the stable branch.

My suggestion: let’s switch now and let’s also try to keep the life
of the current trunk “short”, 6 months at most.
Which is half of the usual cycle.

“Now” means anyways organizing ourselves so that by the time
we start using java 6 specific API both project have switched
the compiled mode to java 6, are building there without errors,
and are thus ready to take java 6 api usage withou hiccups.

Opinions?

Cheers
Andrea

–

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

EditLive Enterprise is the world’s most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev

Geotools-devel mailing list
Geotools-devel@anonymised.comrceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

3

+1 for switching now.
+1 for faster release cycles (6 months).

Deferring the switch to Java 6 only defers pain that must occur. At some time, trunk will switch to Java 6 while stable is on Java 5.

A faster release cycle (not just this one) would facilitate availability of new features. To preserve stability, perhaps two stable/supported branches?

On 13/06/11 04:33, Andrea Aime wrote:

My suggestion: let's switch now and let's also try to keep the life
of the current trunk "short", 6 months at most.
Which is half of the usual cycle.

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineering Team Leader
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

4

To avoid breaking the build, I use only Java 5 (jdk 1.5.0_22). I've seen enough breakage to know that not everyone uses it.

On 13/06/11 08:49, Jody Garnett wrote:

I kind of wish we had a 4rd poll - asking the comitters if they have already switched to Java 6 (and just rely on the build box to keep things honest).

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineering Team Leader
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

5

Proposal now up:

I hunted down the documentation pages that would need to be updated (only 3 as the tutorials already recommend the use of the latest jdk); but I did not go search for a Jira.

–
Jody Garnett

On Monday, 13 June 2011 at 10:49 AM, Jody Garnett wrote:

I kind of wish we had a 4rd poll - asking the comitters if they have already switched to Java 6 (and just rely on the build box to keep things honest).

I like the idea of switching now; and scheduling the life of 8.x up for a release candidate for foss4g in September. I will make the change proposal; part of switching involves updating the developers guide so we need a list of tasks etc…

Aside: While I have ported the docs over; updating the developers guide remains the responsibility of the PMC. While I am hoping that sphinx allows this to be easier for everyone, I don’t want to give the impression that I will update the docs for every last thing we do (or even every second thing).

Jody

Hi,
the pools have been out for long enough and we are not getting new
votes, so time to get the results I guess.

GeoTools results:
http://www.micropoll.com/a/MicroPollData?id=423595&mode=html
Long story short: no one fully against, only 5% somewhat troubled.

GeoServer results:
http://www.micropoll.com/a/MicroPollData?id=423614&mode=html
Long story short: 1% sees this as a blocker, 4% somewhat troubled.

It seems to me we can switch both to Java 6 when we want.

And when is indeed the next question. Do we do it now or we wait
for the next stable branch cut?

Pros of doing it now: plenthy of time to shake out the java 6 build issues,
easier life for whoever works only on trunk.

Pros of doing it later: ease of backport, coding on trunk on java 6
we’ll have some compile or test issues when backporting stuff
to the stable branch.

My suggestion: let’s switch now and let’s also try to keep the life
of the current trunk “short”, 6 months at most.
Which is half of the usual cycle.

“Now” means anyways organizing ourselves so that by the time
we start using java 6 specific API both project have switched
the compiled mode to java 6, are building there without errors,
and are thus ready to take java 6 api usage withou hiccups.

Opinions?

Cheers
Andrea

–

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

EditLive Enterprise is the world’s most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev

Geotools-devel mailing list
Geotools-devel@anonymised.comge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

6

+1 from me.

I've added Andrea's +1 as well.

On 13/06/11 15:54, Jody Garnett wrote:

Proposal now up:

- http://docs.codehaus.org/display/GEOTOOLS/Java+6

I hunted down the documentation pages that would need to be updated (only 3 as the tutorials already recommend the use of the latest jdk); but I did not go search for a Jira.

--
Jody Garnett

On Monday, 13 June 2011 at 10:49 AM, Jody Garnett wrote:

I kind of wish we had a 4rd poll - asking the comitters if they have already switched to Java 6 (and just rely on the build box to keep things honest).

I like the idea of switching now; and scheduling the life of 8.x up for a release candidate for foss4g in September. I will make the change proposal; part of switching involves updating the developers guide so we need a list of tasks etc...

Aside: While I have ported the docs over; updating the developers guide remains the responsibility of the PMC. While I am hoping that sphinx allows this to be easier for everyone, I don't want to give the impression that I will update the docs for every last thing we do (or even every second thing).

Jody
Hi,
the pools have been out for long enough and we are not getting new
votes, so time to get the results I guess.

GeoTools results:
http://www.micropoll.com/a/MicroPollData?id=423595&mode=html
Long story short: no one fully against, only 5% somewhat troubled.

GeoServer results:
http://www.micropoll.com/a/MicroPollData?id=423614&mode=html
Long story short: 1% sees this as a blocker, 4% somewhat troubled.

It seems to me we can switch both to Java 6 when we want.

And when is indeed the next question. Do we do it now or we wait
for the next stable branch cut?

Pros of doing it now: plenthy of time to shake out the java 6 build issues,
easier life for whoever works only on trunk.

Pros of doing it later: ease of backport, coding on trunk on java 6
we'll have some compile or test issues when backporting stuff
to the stable branch.

My suggestion: let's switch now and let's also try to keep the life
of the current trunk "short", 6 months at most.
Which is half of the usual cycle.

"Now" means anyways organizing ourselves so that by the time
we start using java 6 specific API both project have switched
the compiled mode to java 6, are building there without errors,
and are thus ready to take java 6 api usage withou hiccups.

Opinions?

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net<mailto:Geotools-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/geotools-devel

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineering Team Leader
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre