Wow that is a great rant Bryce - Do you mind if I post it as a comment on my blog post?
I have hooked up GeoTools and JScience before - and it went okay for me. I am now trying to think if that is because I was within the limits of their defined constants ... nope I needed to define my own (but you are correct that I did so as a class). I was able to define additional conversions at runtime ... I wonder if you could be evil and implement a dynamic proxy ... oh to leave Java behind a work with Ruby :-) You have however answered my question about if we care or not; thank you. Jody > The Jscience stuff seems to be hardcoded. Is there any particular reason a > JSR should create a billion identifiers like "VOLT" and "METER"? I can > understand setting up a data model and an API around that model, but > hardcoding all the data items is likely to drag them deep down a rabbit > hole. Should they define all possible units, or just the basic ones? > Worse, when they define Quantities, which quantities are important enough > or common enough to predefine? For the compiler to check consistency, all > Units and all Quantities must be declared as classes, which forces a > situation where we must treat "Classes" as if they were "Objects". Child > classes are now instances of their parents merely because objects don't > exist at compile time. > > But the worst failing of all: extension of the pre-existing units system is > nearly impossible without writing code. Or if you prefer, it is impossible > to write code which generically handles units. If you encounter a data > file which expresses numbers in units of Canadian Dollars per hour, and if > it comes with a full description in a standard format of the new Quantity > (currency) and the new Units (Canadian Dollars), is it possible to ingest > this file into a program which was not written with any knowledge of > currency? > > No. You have to know ahead of time that "Currency" might be an item of > concern. You have to write a class to "instantiate" currency by explicitly > extending Quantity. You may then use this new quantity within your own > program, but may not save the value out and exchange it with any other > program which does not understand currency. It doesn't much matter though, > because your users have had to recompile due to the classes-are-objects > paradigm. ;) > > Other valid Quantities would be [Concentration CO2] and [Concentration O3] > (because you cannot mix and match short of a chemical reaction). > > In short, the JSR does not provide a "form" populated with a default set of > values. It provides _the_ orthodox set of values. This is not the place > of a JSR. Compile time checking is obtained at the cost of run-time > extension and "class abuse". > > Check out: > http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=unitsml > > Making something which implements OASIS's data model in the Java > programming language would seem to be the way to go. This is how the units > professionals choose to convey units. They don't include currency either, > but note that they separate the framework from the set of default values > such that one _can_ supply a currency definition to something which > understands the framework. > > Units are important and shouldn't be rushed or handicapped. :) > Bryce > > [EMAIL PROTECTED] wrote on 07/05/2007 01:42:43 > PM: > > >> I found some subject material for a blog entry ... >> - http://weblogs.java.net/blog/jive/archive/2007/07/jsr275_and_why.html >> >> The review period ends July 8th. >> - https://jsr-275.dev.java.net/files/documents/4333/34956/jsr-275.pdf >> >> Of interest is the no vote from Sun: >> >>> On 2005-06-09 Intel Corp. voted No with the following comment: >>> JSR 108 was withdrawn after 3 years without producing an initial >>> draft. This new JSR appears to be a continuation of that work, but >>> doesn't have an Early Draft scheduled in the near future. Before >>> deciding on a standard, more experience with implentations, >>> exploration of performance impacts in running code (build time[JSR >>> 269] vs runtime processing) and broader input (perhaps from the >>> academic community) may be helpful. Experience with packages outside >>> the standardization process can pave the way for determining what the >>> best way forward is for defining a Java standard. This JSR looks like >>> it would benefit from more R&D before standardization. >>> >> Most of the votes seem guarded - based on previously being burned by JSR >> 108: >> >>> Google is voting yes but with reservations: The API described on >>> >>> > http://www.jscience.org/api/org/jscience/physics/units/package-summary.html > >>> is far too complex. If this API is ever to be included in the JDK it >>> must be simplified considerably. >>> >> So do we care? >> >> Jody >> >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by DB2 Express >> Download DB2 Express C - the FREE version of DB2 express and take >> control of your XML. No limits. Just data. Click to get it now. >> http://sourceforge.net/powerbar/db2/ >> _______________________________________________ >> Geotools-devel mailing list >> Geotools-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/geotools-devel >> > > ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
