First let’s talk about a problem in your import line. As the comment from Guilherme javax
is a namespace generic for extensions, some packages within the javax
are part of the Java SE distribution and others are not. The javax.measure
in particular is not part of the standard Java distribution.
Also, in Java you never import a package like javax.measure
directly.
You can import a specific package class, for example:
import javax.measure.Dimension;
Or you can import all classes from the package (but not recursively within subpacks):
import javax.measure.*;
On your question, the JSR-363 is the specification of Units of Measurement API (bundle javax.measure
). There is also the most current JSR-385 which specifies version 2.0 of this API. To compile and run your application outside of the IDE you will need to download not only the API, but also the reference implementation or one of the compatible implementations. Once you have all the artifacts you must include them in class path.
Usually a system of build with support for declarative control of dependencies such as Maven or the Gradle is used to do this kind of thing. With these tools you can declare the implementation you want and the system will download and include all necessary artifacts in the class path.
For example, with Maven you can add the following dependency to pom.xml:
<dependency>
<groupId>tech.units</groupId>
<artifactId>indriya</artifactId>
<version>2.1.2</version>
</dependency>
Then run the following command to compile your project:
mvn compile
With this Maven will download the Indriya, JSR-385 reference implementation. Maven will also download all transitive dependencies, including Unit-api-2.1.2.jar (most current version of the API) linked by Guilherme.
Alternatively, at least for study purposes, nothing prevents you from downloading the necessary jars and all their dependencies manually. See that if the jar A you need depends on a jar B which in turn depends on C and D you will need A, B, C and D in the class path. In a real project the manual control of dependencies soon becomes tedious and I would certainly recommend using a tool build.
Let’s assume, for example, that you downloaded the jar of the desired version of the API, from a compatible implementation like the uom and all deployment dependencies. These artifacts were saved in a folder lib
next to your code:
lib/
unit-api-1.0.jar
uom-lib-common-1.0.3.jar
uom-se-1.0.10.jar
Measure.java
You can compile the class Measure
with:
javac -cp "lib/*" Measure.java
And run the application with:
java -cp "lib/*" Measure
PS: In this trivial case only the API jar is required for the compilation step, the other artifacts are needed only at runtime. In theory this makes it possible to change the implementation of determinads API without having to recompile or tamper with the application. In practice, however, this does not always work as it should. Small implementation differences can cause problems at runtime. Anyone who has ever had to change the implementation of JPA or JAX-RS or JAXB into a project knows what I’m talking about. The lead spec of JSR-385 and author of Indriya for example provides extra classes in the implementation and recommends their direct use (see: https://unitsofmeasurement.github.io/indriya/)
And which package manager is using "stand alone" (no IDE)? Maven or Gradle? Here’s how to install using different package managers: https://mvnrepository.com/artifact/javax.measure/unit-api/2.1.2. ... just for the record, javax is not a package with everything from "javax", it’s a namespace, probably focused on "extensions" (old issue, old decisions too), several third party packages can be used in this. Even Tomcat (some of Tomcat have already changed namespace) and Apache has Apis that use this namespace.
– Guilherme Nascimento