Is there any available API to represent various units of item like KG, Litre, Metre, KM, etc

问题

In my project, somewhere I have to work with a unitOfIssue of Items. Now, various items of course can have different units of representation. So, I was searching for some API or some way, to elegantly handle this situation.

Is there any available API, that provides some way to represent these units? I've heard of JScience which seems impressive, but again I am facing another problem with mapping it in JPA. After some google work, I found out that some work is going on in this context as - JScience-JPA, but it seems like it is not yet stable to be used in production.

I also found something about JSR-275, but from this JCP page it seems like it has been rejected.

Then I came across unitsofmeasure, which I haven't yet dig into details. But, again the same issue comes. Can this be mapped with JPA?

Edit: - From this SO question I came across Java Numbers with Unit but I don't know whether it is production ready or not.

I'm really confused, specially after seeing those options above. And JPA is an added concern as to whether I can use any of them or not. Have anyone ever faced such kind of situation, and found a way out of it? I really need some help here. What should I use? And if there is no other way out, then what would be appropriate way to represent these units. One way I see is by using enums. but, of course, that would be the last choice.

回答1:

I was in a project in which we had extensive use of JSR-275 (before it was rejected by JCP). Originally we were not using JPA, but later it was decided that we should persist our model using JPA 2.0 and I had to deal with the persistence of my measure objects.

This may not be the answer to your question, but may bring some interesting thoughts to the discussion.

We considered several alternatives:

Measures were serializable, and JPA can map any serializable object. The problem here is that the measures would be saved as binary objects in the database and they'd be subject to all the issues of serialization (i.e. versioning, etc.)
We could adapt our model by keeping the data in raw types (i.e. integers, double, etc) provided that we agree on using the international unit of measure for every unit. Thus, fields would be based in JPA-supported types, but getters and setters would use measure objects. Configure JPA mapping to be based on fields, not properties. The problem here was having to alter the model to change encapsulated data without affecting the public interface of the domain objects.
Since we were using hibernate as our persistence provider, we could accept to deviate from the JPA standard and use hibernate custom value types to map measure objects to ther corresponding primitive types. Then we could map our types using hibernate annotations for this purpose. (See an example here). The caveat in this one is losing persistence vendor independence.

We ended up using alternative #3 and it worked pretty well for us.