2

Packages that are not included in the JDK (for example javax.websocket) need to be downloaded and referred to with -cp or the CLASSPATH environment variable in order to be imported (otherwise you get the compilation error package X does not exist).

After compilation, when the .class files are obtained, is it possible to transfer these files to a computer that does not have the javax.websocket package, and have the JVM on that computer run them, or is it necessary to have the package on both computers?

In other words: When you write import bar.foo;, you are essentially writing "Every time you see foo, go to this location and see what it is.". However, when you have compiled the source code, does the byte code still say "go to this location and see what it is", or has it already gone to the location and "imported" everything so that the location is no longer needed?

RaminS
  • 2,208
  • 4
  • 22
  • 30
  • Note that `import` statements are for compilation only. They do nothing at runtime. See [this answer](http://stackoverflow.com/questions/1457863/what-causes-and-what-are-the-differences-between-noclassdeffounderror-and-classn?lq=1). Yes, if you're going to use a class, it needs to be available at runtime. – Sotirios Delimanolis Jul 11 '16 at 17:17
  • you need external libraries at runtime as well – Sanjeev Jul 11 '16 at 17:18
  • @SotiriosDelimanolis Are you saying that it would be possible to omit any import statement if the Java designers had allowed you to compile the source code without them, as long as you make sure the packages are available during runtime? – RaminS Jul 11 '16 at 17:37
  • 2
    @Gendarme They exist so that you can use the simple names of types, unqualified, ie. without their package name prefix. Without them, you'd have to use fully qualified names everywhere. – Sotirios Delimanolis Jul 11 '16 at 17:39

2 Answers2

1

After compilation, when the .class files are obtained, is it possible to transfer these files to a computer that does not have the javax.websocket package, and have the JVM on that computer run them, or is it necessary to have the package on both computers?

It is necessary to have the package on both computers. Bytecode assumes that the relevant classes would be made available to JVM at runtime.

Moreover, this is true even for compiling and running on the same computer: the locations from which Java compiler pulls its packages for compilation could be different from the location from which JVM pulls packages when running your code.

Sergey Kalinichenko
  • 714,442
  • 84
  • 1,110
  • 1,523
  • *"the locations from which Java compiler pulls its packages for compilation could be different from the location from which JVM pullls packages when running your code."* Is the`CLASSPATH` variable only for compilation and not used during runtime? In that case, how does one specify the location of runtime package-pulling? – RaminS Jul 11 '16 at 17:32
  • 1
    @Gendarme Both `javac` and `java` will use the same `CLASSPATH` environment variable. However, you have an option of overriding it by passing a `-classpath` option to the compiler or to JVM. According to Oracle, this way of specifying class path is preferred over using `CLASSPATH` variable. – Sergey Kalinichenko Jul 11 '16 at 17:39
  • Note that the `import` statement is really just compile-time sugar for FQCN substitution and has no effect at runtime. e. g. importing `ArrayList` and using it is the same as writing the full FQCN `java.util.ArrayList`. – Kitten May 20 '18 at 02:35
1

A very thorough explanation of the issue can be found, right here on SO, at:

To directly quote author JB Nizet: (added italics are mine)

The compile classpath is the classpath used to compile your Java source files (using javac -cp ..., or your IDE). Every class referenced in the source file must be present in the compile classpath, else the compiler will complain that it can't find the class.

Once you have compiled the classes, you can run a program using them (using java -cp ...). Obviously, the libraries on which your source code depends directly should be in the runtime classpath. But that's not all. If you depend directly on CoolLibrary.jar, and this library internally depends on Guava.jar, then Guava.jar must also be in the runtime classpath, although it was not needed when compiling.

Webapps are a bit special. [... the original answer continues ...]

Community
  • 1
  • 1
Mike Robinson
  • 8,490
  • 5
  • 28
  • 41