GeoTools
  1. GeoTools
  2. GEOT-746

Remove JAI dependency from the main module

    Details

    • Type: Task Task
    • Status: Closed Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 2.2.1, 2.3.0, 2.4-M0
    • Fix Version/s: 2.5-M2
    • Component/s: main, referencing
    • Labels:
      None

      Description

      Except for the GridCoverage implementation, the JAI dependency in the main module is very small. The only JAI class used is:

      javax.media.jai.util.Range

      It would be easy to provide our own Range implementation in the org.geotools.util package. The proposed transition path is:

      • Create an org.geotools.util.Range class which extends javax.media.jai.util.Range for now (for a smooth transition).
      • Put a clear warning saying that the JAI Range inheritance will be removed in a future release.
      • Wait for users to replace "import javax.media.jai.util.Range" by "import org.geotools.util.Range". No more change required.
      • After the 2.2 release, remove the "extends javax.media.jai.util.Range" clause in the org.geotools.util.Range class.

        Issue Links

          Activity

          Hide
          Jody Garnett added a comment -
          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?
          Show
          Jody Garnett added a comment - 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?
          Hide
          Jody Garnett added a comment -
          Show
          Jody Garnett added a comment - Javadocs used when constructing replacement class: - http://java.sun.com/products/java-media/jai/forDevelopers/jai-apidocs/javax/media/jai/util/Range.html
          Hide
          Martin Desruisseaux added a comment -
          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...

          Show
          Martin Desruisseaux added a comment - 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...
          Hide
          Jody Garnett added a comment -
          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
          Show
          Jody Garnett added a comment - 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
          Hide
          Martin Desruisseaux added a comment -
          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...
          Show
          Martin Desruisseaux added a comment - 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...
          Hide
          Jody Garnett added a comment -
          Range is now hooked up as of -r29950.
          Show
          Jody Garnett added a comment - Range is now hooked up as of -r29950.
          Hide
          Jody Garnett added a comment -
          This work is now complete both uDig and GeoServer are working fine.
          Show
          Jody Garnett added a comment - This work is now complete both uDig and GeoServer are working fine.
          Hide
          Martin Desruisseaux added a comment -
          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...
          Show
          Martin Desruisseaux added a comment - 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...
          Hide
          Martin Desruisseaux added a comment -
          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.
          Show
          Martin Desruisseaux added a comment - 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.

            People

            • Assignee:
              Martin Desruisseaux
              Reporter:
              Martin Desruisseaux
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: