Quantcast

JTS Version 1.10 Released

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

JTS Version 1.10 Released

Martin Davis
JTS Ver 1.10 has now been released, just in time for the New Year.

The release is available on SourceForge at:
https://sourceforge.net/projects/jts-topo-suite/

Features of this version include:


      Functionality Improvements

    * Added Geometry.reverse() method for all geometry types
    * Added setSrsName, setNamespace, setCustomRootElements methods to
      GMLWriter
    * Added Envelope.getArea method
    * Added copy, copyCoord methods to CoordinateSequences
    * Added area method to Envelope
    * Added extractPoint(pt, offset) methods to LengthIndexedLine and
      LocationIndexedLine
    * Added CoordinatePrecisionReducerFilter
    * Added UnaryUnionOp(Collection, GeometryFactory) constructor to
      handle empty inputs more automatically
    * Added DiscreteHausdorffDistance class
    * Made LineMerger able to be called incrementally
    * Added GeometricShapeFactory.createArcPolygon to create a polygonal
      arc
    * Enhanced Geometry.buffer() to preserve SRID


      Performance Improvements

    * Improved performance for |EdgeList| (by using a more efficient
      technique for detecting duplicate edges)
    * Improved performance for |ByteArrayInStream| (by avoiding use of
      java.io.ByteArrayInputStream)
    * Unrolled intersection computation in HCoordinate to avoid object
      allocation
    * Improved performance for buffering via better offset curve
      generation and simplification.
    * Improved performance for IsValipOp by switching to use STRtree for
      nested hole checking


      Bug Fixes

    * Fixed Geometry.getClassSortIndex() to lazily initialize the sorted
      class list. This fixes a threading bug.
    * Fixed RectangleContains to return correct result for points on the
      boundary of the rectangle
    * Fixed error in com.vividsolutions.jts.simplify.LineSegmentIndex
      which caused polygons simplified using
      TopologyPreservingSimplifier to be invalid in certain situations
    * Fixed error in DouglasPeuckerSimplifier which caused empty
      polygons to be returned when they contained a very small hole
    * Fixed PackedCoordinateSequence to return NaN for null ordinate values
    * Fixed Geometry.centroid() (CentroidArea) so that it handles
      degenerate (zero-area) polygons
    * Fixed Geometry.buffer() (OffsetCurveBuilder) so that it handles
      JOIN_MITRE cases with nearly collinear lines correctly
    * Fixed GeometryFactory.toGeometry(Envelope) to return a CW polygon
    * Fixed UnaryUnionOp to correctly handle heterogeneous inputs with
      P/L/A components
    * Fixed UnaryUnionOp to accept LINEARRINGs
    * Fixed CentroidArea to handle zero-area polygons correctly
    * Fixed WKBWriter to always output 3D when requested, and to handle
      2D PackedCoordinateSequences correctly in this case
    * Fixed NodedSegmentString to handle zero-length line segments
      correctly (via safeOctant)
    * Cleaned up code to remove unneeded CGAlgorithms objects
    * Fixed GeometricShapeFactory.createArc to ensure arc has requested
      number of vertices


      API Changes

    * Moved GML I/O classes into core JTS codebase
    * Changed GMLWriter to not write the srsName attribute by default
    * In DistanceOp switched to using nearestPoints method names
    * Exposed STRtree.getRoot() method

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


      JTS TestBuilder


      UI Improvements

    * Added ability to read GML from input panel
    * Added GML output to View dialog
    * Added file drag'n'drop to Geometry Input text areas
    * Add display of computation time
    * Added Stats panel
    * Added Scalar functions panel, with extensible function list
    * Added *Save as PNG...*

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


      JTS TestRunner


      Functionality Improvements

    * Added -testCaseIndex command-line option


--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022

_______________________________________________
jts-devel mailing list
[hidden email]
http://lists.refractions.net/mailman/listinfo/jts-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

JTS Version 1.10 Released

Aron Olsen

Hi Martin,

 

Happy New Year to you, and congratulations with the new 1.10 release.

I have only one comment:

 

In my JTS 1.10 Eclipse project, Eclipse is complaining about the reference to “IndexedPointInAreaLocator” in “GeometryGraph” at line 471, and Eclipse is unable to find a definition of it.

 

Regards,

Aron.

 

 


_______________________________________________
jts-devel mailing list
[hidden email]
http://lists.refractions.net/mailman/listinfo/jts-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: JTS Version 1.10 Released

Aron Olsen

Hi there,

 

Eclipse claims the definition is ”ambiguous”.

As I can see from the source-file distribution the IndexedPointInAreaLocator.java file exists in both package “com.vividsolutions.jts.algorithm” and in package “com.vividsolutions.jts.algorithm.locate”.

 

Which is to be deleted?

 

/Aron

 


From: [hidden email] [mailto:[hidden email]] On Behalf Of Aron Olsen
Sent: 06 January 2009 12:01
To: [hidden email]
Subject: [jts-devel] JTS Version 1.10 Released

 

Hi Martin,

 

Happy New Year to you, and congratulations with the new 1.10 release.

I have only one comment:

 

In my JTS 1.10 Eclipse project, Eclipse is complaining about the reference to “IndexedPointInAreaLocator” in “GeometryGraph” at line 471, and Eclipse is unable to find a definition of it.

 

Regards,

Aron.

 

 


_______________________________________________
jts-devel mailing list
[hidden email]
http://lists.refractions.net/mailman/listinfo/jts-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: JTS Version 1.10 Released

Martin Davis
In reply to this post by Aron Olsen
The IndexedPointInAreaLocator.java in
com.vividsolutions.jts.algorithm.locate is the correct one.

This is a minor problem with the build script - now fixed. It doesn't
affect the compiled jts-1.10.jar, only the source code copy in the
distribution zip.

Thanks for pointing this out.

Martin

Aron Olsen wrote:

>
> Hi Martin,
>
> Happy New Year to you, and congratulations with the new 1.10 release.
>
> I have only one comment:
>
> In my JTS 1.10 Eclipse project, Eclipse is complaining about the
> reference to “IndexedPointInAreaLocator” in “GeometryGraph” at line
> 471, and Eclipse is unable to find a definition of it.
>
> Regards,
>
> Aron.
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> jts-devel mailing list
> [hidden email]
> http://lists.refractions.net/mailman/listinfo/jts-devel
>  

--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022

_______________________________________________
jts-devel mailing list
[hidden email]
http://lists.refractions.net/mailman/listinfo/jts-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: JTS Version 1.10 Released

Sunburned Surveyor
In reply to this post by Martin Davis
Martin,

Congrats on the new release of JTS. It looks like it involved some
hard work on your part. I look forward to working with the library via
OpenJUMP.

The Sunburned Surveyor

On Fri, Jan 2, 2009 at 12:29 PM, Martin Davis <[hidden email]> wrote:

> JTS Ver 1.10 has now been released, just in time for the New Year.
>
> The release is available on SourceForge at:
> https://sourceforge.net/projects/jts-topo-suite/
>
> Features of this version include:
>
>
>     Functionality Improvements
>
>   * Added Geometry.reverse() method for all geometry types
>   * Added setSrsName, setNamespace, setCustomRootElements methods to
>     GMLWriter
>   * Added Envelope.getArea method
>   * Added copy, copyCoord methods to CoordinateSequences
>   * Added area method to Envelope
>   * Added extractPoint(pt, offset) methods to LengthIndexedLine and
>     LocationIndexedLine
>   * Added CoordinatePrecisionReducerFilter
>   * Added UnaryUnionOp(Collection, GeometryFactory) constructor to
>     handle empty inputs more automatically
>   * Added DiscreteHausdorffDistance class
>   * Made LineMerger able to be called incrementally
>   * Added GeometricShapeFactory.createArcPolygon to create a polygonal
>     arc
>   * Enhanced Geometry.buffer() to preserve SRID
>
>
>     Performance Improvements
>
>   * Improved performance for |EdgeList| (by using a more efficient
>     technique for detecting duplicate edges)
>   * Improved performance for |ByteArrayInStream| (by avoiding use of
>     java.io.ByteArrayInputStream)
>   * Unrolled intersection computation in HCoordinate to avoid object
>     allocation
>   * Improved performance for buffering via better offset curve
>     generation and simplification.
>   * Improved performance for IsValipOp by switching to use STRtree for
>     nested hole checking
>
>
>     Bug Fixes
>
>   * Fixed Geometry.getClassSortIndex() to lazily initialize the sorted
>     class list. This fixes a threading bug.
>   * Fixed RectangleContains to return correct result for points on the
>     boundary of the rectangle
>   * Fixed error in com.vividsolutions.jts.simplify.LineSegmentIndex
>     which caused polygons simplified using
>     TopologyPreservingSimplifier to be invalid in certain situations
>   * Fixed error in DouglasPeuckerSimplifier which caused empty
>     polygons to be returned when they contained a very small hole
>   * Fixed PackedCoordinateSequence to return NaN for null ordinate values
>   * Fixed Geometry.centroid() (CentroidArea) so that it handles
>     degenerate (zero-area) polygons
>   * Fixed Geometry.buffer() (OffsetCurveBuilder) so that it handles
>     JOIN_MITRE cases with nearly collinear lines correctly
>   * Fixed GeometryFactory.toGeometry(Envelope) to return a CW polygon
>   * Fixed UnaryUnionOp to correctly handle heterogeneous inputs with
>     P/L/A components
>   * Fixed UnaryUnionOp to accept LINEARRINGs
>   * Fixed CentroidArea to handle zero-area polygons correctly
>   * Fixed WKBWriter to always output 3D when requested, and to handle
>     2D PackedCoordinateSequences correctly in this case
>   * Fixed NodedSegmentString to handle zero-length line segments
>     correctly (via safeOctant)
>   * Cleaned up code to remove unneeded CGAlgorithms objects
>   * Fixed GeometricShapeFactory.createArc to ensure arc has requested
>     number of vertices
>
>
>     API Changes
>
>   * Moved GML I/O classes into core JTS codebase
>   * Changed GMLWriter to not write the srsName attribute by default
>   * In DistanceOp switched to using nearestPoints method names
>   * Exposed STRtree.getRoot() method
>
> ------------------------------------------------------------------------
>
>
>     JTS TestBuilder
>
>
>     UI Improvements
>
>   * Added ability to read GML from input panel
>   * Added GML output to View dialog
>   * Added file drag'n'drop to Geometry Input text areas
>   * Add display of computation time
>   * Added Stats panel
>   * Added Scalar functions panel, with extensible function list
>   * Added *Save as PNG...*
>
> ------------------------------------------------------------------------
>
>
>     JTS TestRunner
>
>
>     Functionality Improvements
>
>   * Added -testCaseIndex command-line option
>
>
> --
> Martin Davis
> Senior Technical Architect
> Refractions Research, Inc.
> (250) 383-3022
>
> _______________________________________________
> jts-devel mailing list
> [hidden email]
> http://lists.refractions.net/mailman/listinfo/jts-devel
>
_______________________________________________
jts-devel mailing list
[hidden email]
http://lists.refractions.net/mailman/listinfo/jts-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: JTS Version 1.10 Released

Martin Davis
Great!  Let me know if you uncover any problems....

Sunburned Surveyor wrote:

> Martin,
>
> Congrats on the new release of JTS. It looks like it involved some
> hard work on your part. I look forward to working with the library via
> OpenJUMP.
>
> The Sunburned Surveyor
>
> On Fri, Jan 2, 2009 at 12:29 PM, Martin Davis <[hidden email]> wrote:
>  
>> JTS Ver 1.10 has now been released, just in time for the New Year.
>>
>> The release is available on SourceForge at:
>> https://sourceforge.net/projects/jts-topo-suite/
>>
>> Features of this version include:
>>
>>
>>     Functionality Improvements
>>
>>   * Added Geometry.reverse() method for all geometry types
>>   * Added setSrsName, setNamespace, setCustomRootElements methods to
>>     GMLWriter
>>   * Added Envelope.getArea method
>>   * Added copy, copyCoord methods to CoordinateSequences
>>   * Added area method to Envelope
>>   * Added extractPoint(pt, offset) methods to LengthIndexedLine and
>>     LocationIndexedLine
>>   * Added CoordinatePrecisionReducerFilter
>>   * Added UnaryUnionOp(Collection, GeometryFactory) constructor to
>>     handle empty inputs more automatically
>>   * Added DiscreteHausdorffDistance class
>>   * Made LineMerger able to be called incrementally
>>   * Added GeometricShapeFactory.createArcPolygon to create a polygonal
>>     arc
>>   * Enhanced Geometry.buffer() to preserve SRID
>>
>>
>>     Performance Improvements
>>
>>   * Improved performance for |EdgeList| (by using a more efficient
>>     technique for detecting duplicate edges)
>>   * Improved performance for |ByteArrayInStream| (by avoiding use of
>>     java.io.ByteArrayInputStream)
>>   * Unrolled intersection computation in HCoordinate to avoid object
>>     allocation
>>   * Improved performance for buffering via better offset curve
>>     generation and simplification.
>>   * Improved performance for IsValipOp by switching to use STRtree for
>>     nested hole checking
>>
>>
>>     Bug Fixes
>>
>>   * Fixed Geometry.getClassSortIndex() to lazily initialize the sorted
>>     class list. This fixes a threading bug.
>>   * Fixed RectangleContains to return correct result for points on the
>>     boundary of the rectangle
>>   * Fixed error in com.vividsolutions.jts.simplify.LineSegmentIndex
>>     which caused polygons simplified using
>>     TopologyPreservingSimplifier to be invalid in certain situations
>>   * Fixed error in DouglasPeuckerSimplifier which caused empty
>>     polygons to be returned when they contained a very small hole
>>   * Fixed PackedCoordinateSequence to return NaN for null ordinate values
>>   * Fixed Geometry.centroid() (CentroidArea) so that it handles
>>     degenerate (zero-area) polygons
>>   * Fixed Geometry.buffer() (OffsetCurveBuilder) so that it handles
>>     JOIN_MITRE cases with nearly collinear lines correctly
>>   * Fixed GeometryFactory.toGeometry(Envelope) to return a CW polygon
>>   * Fixed UnaryUnionOp to correctly handle heterogeneous inputs with
>>     P/L/A components
>>   * Fixed UnaryUnionOp to accept LINEARRINGs
>>   * Fixed CentroidArea to handle zero-area polygons correctly
>>   * Fixed WKBWriter to always output 3D when requested, and to handle
>>     2D PackedCoordinateSequences correctly in this case
>>   * Fixed NodedSegmentString to handle zero-length line segments
>>     correctly (via safeOctant)
>>   * Cleaned up code to remove unneeded CGAlgorithms objects
>>   * Fixed GeometricShapeFactory.createArc to ensure arc has requested
>>     number of vertices
>>
>>
>>     API Changes
>>
>>   * Moved GML I/O classes into core JTS codebase
>>   * Changed GMLWriter to not write the srsName attribute by default
>>   * In DistanceOp switched to using nearestPoints method names
>>   * Exposed STRtree.getRoot() method
>>
>> ------------------------------------------------------------------------
>>
>>
>>     JTS TestBuilder
>>
>>
>>     UI Improvements
>>
>>   * Added ability to read GML from input panel
>>   * Added GML output to View dialog
>>   * Added file drag'n'drop to Geometry Input text areas
>>   * Add display of computation time
>>   * Added Stats panel
>>   * Added Scalar functions panel, with extensible function list
>>   * Added *Save as PNG...*
>>
>> ------------------------------------------------------------------------
>>
>>
>>     JTS TestRunner
>>
>>
>>     Functionality Improvements
>>
>>   * Added -testCaseIndex command-line option
>>
>>
>> --
>> Martin Davis
>> Senior Technical Architect
>> Refractions Research, Inc.
>> (250) 383-3022
>>
>> _______________________________________________
>> jts-devel mailing list
>> [hidden email]
>> http://lists.refractions.net/mailman/listinfo/jts-devel
>>
>>    
> _______________________________________________
> jts-devel mailing list
> [hidden email]
> http://lists.refractions.net/mailman/listinfo/jts-devel
>
>  

--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022

_______________________________________________
jts-devel mailing list
[hidden email]
http://lists.refractions.net/mailman/listinfo/jts-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

JTS Version 1.10 Released

Aron Olsen
In reply to this post by Martin Davis

Hi Martin,

 

I cannot avoid noticing that JTS is currently coded according to Java 1.4 – not using generics, enumerations and auto-boxing.

Thus, programming against JTS using Java 1.6 compliance level usually results in various compiler-warnings (for example when java.util.List is being referenced).

Furthermore, I also noticed that the GML I/O relies on the (external) xerces XML-api and not on the Java built-in JAXP API.

Are there any plans in the pipeline of having the JTS code-base updgraded to Java 1.6 standards?

 

/Aron

 

PS: The problem with the “sortedClasses” array in Geometry.java could have been solved by making use of an enumeration such as “public enum GeometryType”.

 

 

 

 


_______________________________________________
jts-devel mailing list
[hidden email]
http://lists.refractions.net/mailman/listinfo/jts-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: JTS Version 1.10 Released

Martin Davis
Can you turn off the warnings?

I'm not seeing a huge benefit to moving to using generics etc. There's
also a large amount of work to move everying to generics, I think.
There's also a downside to moving, which is that people running 1.1-1.4
will no longer be able to use the library. (Don't laugh - I have at
least one client who is still using 1.4)

What do others on the list think?

The comment about XML API dependency is interesting. Would it be
possible to encapsulate this dependency and allow either to be used? If
so can you provide code?

Aron Olsen wrote:

>
> Hi Martin,
>
> I cannot avoid noticing that JTS is currently coded according to Java
> 1.4 – not using generics, enumerations and auto-boxing.
>
> Thus, programming against JTS using Java 1.6 compliance level usually
> results in various compiler-warnings (for example when java.util.List
> is being referenced).
>
> Furthermore, I also noticed that the GML I/O relies on the (external)
> xerces XML-api and not on the Java built-in JAXP API.
>
> Are there any plans in the pipeline of having the JTS code-base
> updgraded to Java 1.6 standards?
>
> /Aron
>
> PS: The problem with the “sortedClasses” array in Geometry.java could
> have been solved by making use of an enumeration such as “public enum
> GeometryType”.
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> jts-devel mailing list
> [hidden email]
> http://lists.refractions.net/mailman/listinfo/jts-devel
>  

--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022

_______________________________________________
jts-devel mailing list
[hidden email]
http://lists.refractions.net/mailman/listinfo/jts-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: JTS Version 1.10 Released

David Zwiers
The warning messages have been around for some time, they were
introduced with Java 1.5 -- but they are just warnings ...

David

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Martin
Davis
Sent: January 13, 2009 9:02 AM
To: JTS Topology Suite Development
Subject: Re: [jts-devel] JTS Version 1.10 Released

Can you turn off the warnings?

I'm not seeing a huge benefit to moving to using generics etc. There's
also a large amount of work to move everying to generics, I think.
There's also a downside to moving, which is that people running 1.1-1.4
will no longer be able to use the library. (Don't laugh - I have at
least one client who is still using 1.4)

What do others on the list think?

The comment about XML API dependency is interesting. Would it be
possible to encapsulate this dependency and allow either to be used? If
so can you provide code?

Aron Olsen wrote:

>
> Hi Martin,
>
> I cannot avoid noticing that JTS is currently coded according to Java
> 1.4 - not using generics, enumerations and auto-boxing.
>
> Thus, programming against JTS using Java 1.6 compliance level usually
> results in various compiler-warnings (for example when java.util.List
> is being referenced).
>
> Furthermore, I also noticed that the GML I/O relies on the (external)
> xerces XML-api and not on the Java built-in JAXP API.
>
> Are there any plans in the pipeline of having the JTS code-base
> updgraded to Java 1.6 standards?
>
> /Aron
>
> PS: The problem with the "sortedClasses" array in Geometry.java could
> have been solved by making use of an enumeration such as "public enum
> GeometryType".
>
>
------------------------------------------------------------------------
>
> _______________________________________________
> jts-devel mailing list
> [hidden email]
> http://lists.refractions.net/mailman/listinfo/jts-devel
>  

--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022

_______________________________________________
jts-devel mailing list
[hidden email]
http://lists.refractions.net/mailman/listinfo/jts-devel
_______________________________________________
jts-devel mailing list
[hidden email]
http://lists.refractions.net/mailman/listinfo/jts-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: JTS Version 1.10 Released

mbedward
In reply to this post by Martin Davis
With the unfortunate handicap of type-erasure in Java generics I can't
see that it would make much difference :)

I don't find the warnings to be any problem, though I'm still using
Java 1.5 and will be for some time.

Michael
_______________________________________________
jts-devel mailing list
[hidden email]
http://lists.refractions.net/mailman/listinfo/jts-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: JTS Version 1.10 Released

Fernando González
Personally, I think generics is very interesting since it provides more information at compile time and therefore reduces the possibility of ClassCastExceptions at runtime. However, the main benefit of generics is obtained during development and maybe JTS is in a mature state now so the benefit is not so clear. I personally hate warnings but I think people using java 1.4 is more important than warnings. I think it's a matter of time.

greetings.

On Tue, Jan 13, 2009 at 11:57 PM, Michael Bedward <[hidden email]> wrote:
With the unfortunate handicap of type-erasure in Java generics I can't
see that it would make much difference :)

I don't find the warnings to be any problem, though I'm still using
Java 1.5 and will be for some time.

Michael
_______________________________________________
jts-devel mailing list
[hidden email]
http://lists.refractions.net/mailman/listinfo/jts-devel




_______________________________________________
jts-devel mailing list
[hidden email]
http://lists.refractions.net/mailman/listinfo/jts-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: JTS Version 1.10 Released

aaime
Administrator
In reply to this post by mbedward
Michael Bedward ha scritto:
> With the unfortunate handicap of type-erasure in Java generics I can't
> see that it would make much difference :)
>
> I don't find the warnings to be any problem, though I'm still using
> Java 1.5 and will be for some time.

 From the GeoServer point of view we'll be stuck with java 5 until
J2EE 6 becomes the de facto standard in web app deployments.
Given what I see around, I'd say we'll build on top of java 5 for
another couple of years? (just a gut feeling)

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
_______________________________________________
jts-devel mailing list
[hidden email]
http://lists.refractions.net/mailman/listinfo/jts-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: JTS Version 1.10 Released

Aron Olsen
In reply to this post by Martin Davis
Hi again,
I'm using Eclipse, and it is indeed possible to turn off the warnings (either by compiler options or by inline annotations).
Though, the warning-issue is not that important.
It is much more, that many things can be coded more elegantly.
I am just bringing up the topic to hear what people think.

/Aron.


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Martin Davis
Sent: 13 January 2009 18:02
To: JTS Topology Suite Development
Subject: Re: [jts-devel] JTS Version 1.10 Released

Can you turn off the warnings?

I'm not seeing a huge benefit to moving to using generics etc. There's
also a large amount of work to move everying to generics, I think.
There's also a downside to moving, which is that people running 1.1-1.4
will no longer be able to use the library. (Don't laugh - I have at
least one client who is still using 1.4)

What do others on the list think?

The comment about XML API dependency is interesting. Would it be
possible to encapsulate this dependency and allow either to be used? If
so can you provide code?

Aron Olsen wrote:

>
> Hi Martin,
>
> I cannot avoid noticing that JTS is currently coded according to Java
> 1.4 - not using generics, enumerations and auto-boxing.
>
> Thus, programming against JTS using Java 1.6 compliance level usually
> results in various compiler-warnings (for example when java.util.List
> is being referenced).
>
> Furthermore, I also noticed that the GML I/O relies on the (external)
> xerces XML-api and not on the Java built-in JAXP API.
>
> Are there any plans in the pipeline of having the JTS code-base
> updgraded to Java 1.6 standards?
>
> /Aron
>
> PS: The problem with the "sortedClasses" array in Geometry.java could
> have been solved by making use of an enumeration such as "public enum
> GeometryType".
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> jts-devel mailing list
> [hidden email]
> http://lists.refractions.net/mailman/listinfo/jts-devel
>

--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022

_______________________________________________
jts-devel mailing list
[hidden email]
http://lists.refractions.net/mailman/listinfo/jts-devel


_______________________________________________
jts-devel mailing list
[hidden email]
http://lists.refractions.net/mailman/listinfo/jts-devel
Loading...