[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[udig-devel] Java 5 continued ...
|
Thanks for the email Chris - this is not a clear cut issue. It is hard
to justify any change unless
the issue is clear cut.
First off, I'm supporting 1.4 in GeoServer for a long, long time.
Understood - as the question has come up before. As mentioned earlier I
view Java 5 support
as the work of Geotools3 :-)
The second applies more, and that's being _truly_ open source. That
is to say by going with the bleeding edge you are dependant on Sun.
Java's almost but not quite open source nature makes it so other JVMs,
especially on open source operating systems like FreeBSD, lag behind.
...
the people who are strict about open source are very willing to contribute
to new open source projects that they like,
That is a very good point, udig development is a bit limited by the
whole eclipse environment as well
mind you. Although it does say it runs on other JVMs. That is I probably
already isolated open source
purists with the use of the Eclipse Common License on the RCP plug ins
we depend on.
care about being _truly_ open source. I personally would stick with 1.4,
but I also haven't examined 1.5 and the benefits it offers, indeed am kind
The one thing this does bring up is the fact that if/when you roll changes
back into geotools you'll have to back port to java 1.4.
Specifically for the search/catalog work this would be David's call. I
think he is fine with the back
porting pain. Something about him having to do it anyways.
come sooner if we have most developers working in 1.5, and I am very
against upgrading geotools.
I am afraid that day is coming no matter what we do.
One advantage I have run into over the last couple of days is social in
nature. (I talked about tech
merits before). The advantage is that of enthusiasm - giving some of our
friends like James an
excuse to code in Java 5 can go a long way towards adoption. Java 5
would also serve
to differentiate this project from JUMP...
As for using language enhancements and not API enhancements, I'd say
I agree - "in for a penny in for a pound". I wonder if we are already
tripped up by this since most
are developing against a Java 5 JRE. I will try it against a Java 1.5
JRE and see what I can see.
So that's my take. But I can understand if you'd go to 1.5, even though I
would recommend against it, as I admit my reasons are not especially
compelling.
But worthwhile to consider.
So I take it that is a -1 vote Chris :-)
Since you are the project lead on GeoServer we could of also talked about
sharing catalog code and interfaces. Admittedly the right place for any
of that is in the firmly Java 1.4
codebase. I do want to provide common interfaces for GeoServer
developers, the Data Access Guide lists
some of these plans .. here I will quote them:
catalog.getAdapater( org.geotools.data.Repository.class );
There is a large body of code willing to operate against these APIs.
In particular, a
complete set of validation tests operates against
org.geotools.data.Repository and
is directly reusable.
Cheers,
Jody
