Remove JAI dependency from the main module

Jody Garnett added a comment - 30/Mar/08 2:34 PM Hi Martin; I find this bug really important as it is something that keeps us from making referencing a stand alone module for use in the OpenJUMP fleet of projects. Here is my idea: * create org.geotools.measure.Range, using test case to ensure coformance with javax.media.jai.util.Range * create an additional "setter" accept org.geotools.measure.Range and transition the geotools library to use it * I am not aware of much use of javax.media.jair.util.Range outside the library?

Jody Garnett added a comment - 30/Mar/08 2:35 PM Javadocs used when constructing replacement class: - http://java.sun.com/products/java-media/jai/forDevelopers/jai-apidocs/javax/media/jai/util/Range.html

Martin Desruisseaux added a comment - 31/Mar/08 3:10 AM Since this bug report has been created, a few subclasses of Range have been created: * DateRange * NumberRange * MeasurementRange On the dark side, those subclasses make less pratical the additional "setters" approach since we would need to duplicate this class hierarchy and duplicate "setters" for them too (and we can't duplicate "getters" unless using different method names). On the bright side most usage of Range is actually usage of one of those subclasses, so a straight replacement of JAI Range by a GeoTools Range may have limited disturbance. Those subclasses live in org.geotools.util, but I must admit that org.geotools.measure would have be a better choice (I wonder if it is worth a move through a "deprecated then delete" cycle...). An alternative may be to create a small JAR containing only javax.media.jai.util.Range. My guess is that the "Java Research License" ( https://jai.dev.java.net/jrl.html ) allow that, but I'm a novice in that matter. Note sure if it would just make things more complicated however...

Jody Garnett added a comment - 17/Apr/08 1:29 AM Implementation completed; subtract was not used anywhere and is thus not implemented. Range was explicitly used in a few private renderer menthods; I have changed them to use NumberRange (which is what they actually were up to being a scale range). While i was able to implement Range itself with Generics; NumberRange can only be done using some serious generics magic: public NumberRange<T extends Number & T extends Comparable<T super Comparable>> extends Range<T> This is comes from the fact that Number does not implement comparable (even though all its children do)... In the end I just extended Range (with no generics) so we could keep all out constructors: - NumberRange( byte, byte ) - NumberRange( int, int ) - NumberRange( long, long ) - etc... If we don't mind killing these constructors you can go with the full on generic solution; the API may be stronger for it? Your calll

Martin Desruisseaux added a comment - 17/Apr/08 2:36 AM We have meet a similar case with org.geotools.parameter implementations. A proposed fix (not yet fully applied in the Parameter case) is to deprecate those constructors and replace them by static factory methods:    public static NumberRange<Byte> create(byte, byte);    etc...

Jody Garnett added a comment - 17/Apr/08 2:43 AM Range is now hooked up as of -r29950.

Jody Garnett added a comment - 17/Apr/08 5:10 PM This work is now complete both uDig and GeoServer are working fine.

Martin Desruisseaux added a comment - 18/Apr/08 12:24 PM The commited Range implementation has some problems. The implementation of "contains(Range)" method seems to do the work of a "intersects(Range)" method (maybe from a copy-and-paste with the edition step forgoten). The "compareMax" method has the sign reverted in the sequence of "if" statements in the "compare == 0" case. Or actually the later problem hide a more subtle problem. The result of both "compareMin" and "compareMax" depends on whatever the given "value" argument is a minimum or a maximum. If a minimum, the first inclusive value is after that minimum. If maximum, the first inclusive value if before that maximum. A boolean "isInclusive" argument is not enough - we need to consider in which direction is the inclusive value. I'm trying to fix those issues...

Martin Desruisseaux added a comment - 18/Apr/08 2:15 PM An implementation with modified algorithms has been commited as of revision 29988. The work is not finish however. We can take the opportunity of having a Range class in the same package than NumberRange for simplifying the implementation of the later.