How do I import the "javax.Measure" package without IDE?

Asked

Viewed 67 times

0

I am trying to import, in Java 8 and without using IDE, the package javax.measure with the following code:

import javax.measure;

public class Measure {
    public static void main(String[] args) {
        System.out.println("Importou!");
    }
}

The problem is that when I try to compile with the javac, the following error is generated:

Measure.java:1: error: package javax does not exist
import javax.measure;

Searching the internet, I only found pages on how to import the javax through Eclipse. I’d like to know how to do this without using the IDE.

  • 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.

1 answer

5


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/)

Browser other questions tagged

You are not signed in. Login or sign up in order to post.