JSR-275 "Measures and Units" Early Draft Public Review terminates soon (July 8). Your comments/feedback are important to us (the latest version 0.8 is available here). The JSR-275 should be a major enhancement for Java 7 by providing "strong" typing (through class parameterization) and easy internationalization of Java programs (preventing conversion errors). The reference implementation is provided by the JScience project under BSD License. The basis for the JSR:

Java developers who work with physical quantities (such as developers in the scientific, engineering, medical, and manufacturing domains) need to be able to handle measurements of these quantities in their programs. Inadequate models of physical measurements can lead to significant programmatic errors. In particular, the practice of modeling a measure as a simple number with no regard to the units it represents creates fragile code. Another developer or another part of the code may misinterpret the number as representing a different unit of measurement. For example, it may be unclear whether a person's weight is expressed in pounds, kilograms, or stones. Developers must either use inadequate models of measurements, or must create their own solutions. A common solution can be safer and can save development time for domain-specific work. This JSR proposes to establish safe and useful methods for modeling physical quantities.

Why must we endure more bloat for something a library can do. Surely an apache project could be opened to address this need.

What on earth are you talking about? Just because its a JSR, doesn't mean you're stuck with anything. This isn't an update to a core language specification, its merely a specification request to standardize a common set of functionality. How burdened are you with JSR-168? In a standard JVM, you're not. In most J2EE application servers, you also will not find this functionality. Where does it come from then? As you recommended, a library! If you don't need portlet support don't download the library. I know, not downloading something that you don't need is troublesome, but please try to get by. Hmm, so let me see, we have JSRs running wild that don't affect you in the slightest? That's right, there are probably 100 or more that you don't even know about, because you don't use them, don't load them into a classloader, and they are not in your way.

JSRs are very important to the Java Community and honestly a standardization towards unit measurements can only be a good thing. As Paul mentioned, you are not stuck to anything. Regarding apache project, I would rather implement something like this myself then let apache do it. Also, why don't you open a project for this on apache? Do you know the difference between apache and the JCP?

Why must we endure more bloat for something a library can do.

Surely an apache project could be opened to address this need.

Actually this is one of this JSR which makes sense to have in the core library as it standardizes interfacing of libraries/modules dealing with "quantities" (most of them). It provides strong typing, prevents interface errors (e.g. milliseconds/seconds, radians/degrees, meter/foot etc.) and facilitates internationalization (takes care of unit conversions). If you take the time to read the draft spec or to check the API you will realize that most classes are interfaces and the user needs to know only very few of them (e.g. Measure and Measurable). The RI jar file is less than 75 Kb.

It's unclear to me which objects/fields should be serializable. For what concerns persistence, I would like to support javax.measure in JPOX (for JDO and JPA apis). hints?

Awhile back I was writing software for manufacturing control. One interesting requirement we had to implement was an ability to define custom units of measure (for example: box, or sheet) and custom conversions between units (for a given material 1 lb = 3.5 ft). I have written a library http://sourceforge.net/projects/quantitymanager, which supports a concept of the customizable calculator. It is a bit outdated(was written for java 1.4), but might be useful to people facing same problems. Best regards, Alex

I'm interested to know if we'll have a class java.util.Money in core Java library which can handle currency issue.

Why is everything in javax.measure.quantity an interface with no methods? I've encountered these in weird APIs (like JSR 144) and I never understood them. Why aren't these Enums or something? Who is implementing these interfaces? See item 17 of Effective Java by Josh Bloch.