From: Martin D. <mar...@ge...> - 2006-09-21 21:25:27
|
Kirby Bohling a écrit : > That bug report doesn't appear to match my reality. I couldn't find RADIANS > in any NonSI classes (I checked the units.jar from sourceforge, the jsr108 > from the 2.2.0 binary release, and the latest JScience release). It was in > a SI in all three when I went looking. Maybe I missed something. Yes, maybe there is a typo in the bug report. RADIANS is in the SI class, and DEGREE_ANGLE is in NonSI class in JSR-108. Not sure where they live in JSR-275. > Does anyone have any hints on what it would take to rebuild the 2.2.0 > release with JScience, and a possible list of cavets I'd have to worry about? It may be relatively straightforward. Maybe some constants moved around between SI, NonSI or other classes, but I guess that there is few of them. One canvas is that, if my memory serve me right, There is something like Unit.convert(Unit) method which behave like a "getConverterFrom" method, while JScience provides a "getConverterTo" method. So "A.getConverterFrom(B)" need to be changed to "A.getConverterTo(B)" (or maybe the opposite - I need to check). > I believe both have implementations of GeoAPI things, which is my > only other major concern. I don't think that we are going to have any conflict here, since JScience's implementation lives in a different package. Quite the opposite, you can choose and mix implementations in your program, and see if interoperability work :). I will post an email on Geotools developer list in order to see if we can get a plan for JSR-275 migration. The blocker issue is of course J2SE 1.4 compatibility. In the short term, recent discussion on JSR-275 mailing list suggest to move "javax.units" to "javax.measure.units" package, as well as "javax.quantity" to "javax.measure.quantity" in order to have a common root "javax.measure" for both of them. If this change is applied, we would not have conflict anymore between JSR-275 and JSR-108 (until GeoAPI itself switch to JSR-275). Martin. |