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 > [email protected] > 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 [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
