Errors when trying to compile from command line

[Adam Sandler]

Hello:

I'm trying to create a program completely from command line -- I'd like to do more programming this way rather than be so dependent upon the command line.  Anyway, here's my folder structure:

C:.
└───src
    ├───main
    │   └───java
    │       └───com
    │           └───myCompany
    │               └───Runner.java
    │
    └───test
        └───java
            └───com
                └───myCompany
                    └───BasicTest.java

Pretty standard Maven stuff.  Here's BasicTest.java:

package com.myCompany;

import junit.framework.TestCase;

public class BasicTest extends TestCase {
	
  public BasicTest() {
  }	  
	
  public void testTrue() {
    assertTrue(true);
  }
}

... and here's Runner.java:

package com.myCompany;

public class Runner {

public static void main(String[] args) {

    BasicTest bt = new BasicTest();
    bt.testTrue();

    System.out.print("Finished");
  }
}

Simple enough, right?  Time to compile BasicTest.java

C:\workspace\BasicTest>javac -cp c:\junit\latest\junit-4.10.jar c:\workspace\BasicTest\src\test\java\com\myCompany\*.java

This works just fine...

When I try to compile Runner.java, I get this:

C:\workspace\BasicTest>javac -cp c:\workspace\BasicTest\src\test\java\com\myCompany c:\workspace\BasicTest\src\main\java\com\myCompany\*.java

c:\workspace\BasicTest\src\main\java\com\myCompany\Runner.java:7: error: cannot find symbol
    BasicTest bt = new BasicTest();
    ^
  symbol:   class BasicTest
  location: class Runner
c:\workspace\BasicTest\src\main\java\com\myCompany\Runner.java:7: error: cannot find symbol
    BasicTest bt = new BasicTest();
                       ^
  symbol:   class BasicTest
  location: class Runner
2 errors

I've googled until I'm blue in the face and cannot figure this error out.  I understand the error, it's elementary enough, what I'm trying to say is I don't understand why I'm getting it -- I explicitly gave the compiler the paths.  Any assistance you can provide is greatly appreciated; thanks!

[Norm Radder]

The classpath should point to the folder that contains the start of the package name: com.myCompany
com is in the java folder so that is where the classpath should point.

[Adam Sandler]

Norm Radder wrote:The classpath should point to the folder that contains the start of the package name: com.myCompany
com is in the java folder so that is where the classpath should point.

I changed the directory to:

C:\workspace\BasicTest\src\main\java\

and ran:

javac -cp com\myCompany c:\workspace\BasicTest\src\main\java\com\myCompany\Runner.java

and got the same errors!

c:\workspace\BasicTest\src\main\java\com\myCompany\Runner.java:7: error: cannot find symbol
   BasicTest bt = new BasicTest();
   ^
 symbol:   class BasicTest
 location: class Runner
c:\workspace\BasicTest\src\main\java\com\myCompany\Runner.java:7: error: cannot find symbol
   BasicTest bt = new BasicTest();
                      ^
 symbol:   class BasicTest
 location: class Runner
2 errors

[Norm Radder]

There needs to be an import statement for the class that is in a package.

[Tim Holloway]

Maven understands that there are 2 source directories, one for the application code and one for the test, and when you select the maven "test" goal, it compiles using both of them. So the classes resolve, seeing as they are both public in the same package, though in different source trees.

The brute force equivalent using the javac in the raw would be like "javac src/main/java/com/myCompany/Runner.java src/text/java/com/myCompany/BasicTest.java -d target".

This gets messy really, really fast, which is why tools like Maven and Ant and Gradle and so forth are popular. As an intellectual exercise, running the java compiler directly can be instructive and I'll admit that I do occasional one-off test-a-feature single-class compiles that way, but for any real-world project, I use Maven or one of its friends.

[Adam Sandler]

Norm Radder wrote:There needs to be an import statement for the class that is in a package.

I'm confused:

https://stackoverflow.com/questions/33766205/java-importing-class-in-the-same-package/33766219#33766219

"If both classes are in same package, you don't have to import it."

Both classes are in the same package.  That's not the only source which cites that same thought.

Alas, I added this line:

import com.myCompany.BasicTest;

to Runner.java:

package com.myCompany;

import com.myCompany.BasicTest;

public class Runner {

public static void main(String[] args) {

    BasicTest bt = new BasicTest();
    bt.testTrue();

    System.out.print("Finished");
  }
}

and got this error:

Runner.java:3: error: cannot find symbol
import com.myCompany.BasicTest;

[Norm Radder]

got this error:  

Can you post the command line that you are using?  The classpath needs to point to the folder holding the com folder on the path to the BasicTest class.

[Tim Holloway]

Read what I said right before your response. Yes, the classes are both in the same package. But the compiler has to be able to see both of those classes in their respective source directories. It cannot intuit the location of one source directory tree from the other directory tree. So you either have to explicitly indicate both source paths, or compile the non-dependent class first and then include its compiled classfile in the javac classpath.

[Tim Holloway]

Norm Radder wrote:

got this error:  

Can you post the command line that you are using?  The classpath needs to point to the folder holding the com folder on the path to the BasicTest class.

He did and it didn't reference both source trees. Hence the failure.

[Norm Radder]

In the  Today 9:58:57 AM post he said that changes had been made.  I don't see the commandline that was used with the changes in that post.

It is better to copy and paste the full contents of the command prompt window to show the directory, command line and error message all together.

[Adam Sandler]

Tim Holloway wrote:The brute force equivalent using the javac in the raw would be like "javac src/main/java/com/myCompany/Runner.java src/text/java/com/myCompany/BasicTest.java -d target".

I didn't think that -d switch would be mandatory to get this to compile... to run your suggestion, I created C:\workspace\BasicTest\classes and ran:

C:\workspace\BasicTest>javac -cp c:\junit\latest\junit-4.10.jar src/test/java/com/myCompany/*.java src/main/java/com/myCompany/*.java -d classes

and it worked!

Thanks!!!

However, I'm still stuck:

When I cd C:\workspace\BasicTest\classes, it looks like this:

C:\workspace\BasicTest\classes>tree
Folder PATH listing
Volume serial number is 0000006F 5089:8272
C:.
└───com
   └───myCompany


Running either:

C:\workspace\BasicTest\classes\com\myCompany>java Runner

or:

C:\workspace\BasicTest\classes\com\myCompany>java com.myCompany.Runner

or:

C:\workspace\BasicTest\classes>java com.myCompany.Runner

throws these errors:

Error: Could not find or load main class
Caused by: java.lang.ClassNotFoundException

Again, thanks for your help thus far!

[Adam Sandler]

Norm Radder wrote:

got this error:  

Can you post the command line that you are using?  The classpath needs to point to the folder holding the com folder on the path to the BasicTest class.

It's the same command as the  5:08:59 PM

You mentioned that, "The classpath should point to the folder that contains the start of the package name: com.myCompany
com is in the java folder so that is where the classpath should point"

So I did this as previously noted:

C:\workspace\BasicTest\src\main\java>javac -cp com\myCompany c:\workspace\BasicTest\src\main\java\com\myCompany\Runner.java
c:\workspace\BasicTest\src\main\java\com\myCompany\Runner.java:7: error: cannot find symbol
   BasicTest bt = new BasicTest();
   ^
 symbol:   class BasicTest
 location: class Runner
c:\workspace\BasicTest\src\main\java\com\myCompany\Runner.java:7: error: cannot find symbol
   BasicTest bt = new BasicTest();
                      ^
 symbol:   class BasicTest
 location: class Runner
2 errors

[Norm Radder]

The classpath needs to point to the folder containing the first folder of the package.

[Adam Sandler]

Norm Radder wrote:The classpath needs to point to the folder containing the first folder of the package.

in the *.java files:

package com.myCompany;

from the command line:

javac -cp com\myCompany

[Tim Holloway]

In other words, don't "cd" to the directory containing the file. Instead, cd to the root of the output classes directory and reference the main class by its fully-qualified name:

cd C:\workspace\BasicTest\classes
java com.myCompany.Runner

OR

java -classpath C:\workspace\BasicTest\classes com.myCompany.Runner

Which avoids the need to "cd". Also "-classpath" can be shortened to "-cp" if you prefer.

[Norm Radder]

In Tim's examples the classpath points to the classes folder.  The classes folder contains the first folder of the package: com

[Tim Holloway]

Whoops. Let's not get the compile (javac) and runtime (java) commands confused here. As I am getting. I really hate having a short, fat screen thanks to HDTV warping the market for computer monitors. Can't read everything without going to portrait mode, which is worse.

Anyway. the classpath ALWAYS points to compiled classes (and JARs of compiled classes, but not JARs within JARs). So to compile in a single command from source, you have to indicate BOTH main and test source files. Or compile the independent class separately and include it in the classpath to the compiler.

The "-d" option on my initial example was to indicate what directory to put the compiled classes in regardless of their source.

When you run, you are executing classes, so the classpath must either be the default (local directory) or explicitly indicated via the -classpath option. And you always execute the fully-qualified classname (package name incuded). The classpath points to the root(s) of the classes, and assumes the standard Java directory structure for packages. That is, it's not valid to put "com.coderanch.messages.MessageEditor" directly in the classes directory - you have to structure it as classes/com/coderanch/messages/MessageEditor.class. Feel free to interpret that with backslashes on Windows machines.

[Adam Sandler]

Sweet!  Thanks.  That works.  Kind of.

Both, but I'll only post one, suggestions throw the same errors:

C:\workspace\BasicTest\src\main\java>cd C:\workspace\BasicTest\classes

C:\workspace\BasicTest\classes>java -classpath C:\workspace\BasicTest\classes com.myCompany.Runner
Exception in thread "main" java.lang.NoClassDefFoundError: junit/framework/TestCase
       at java.base/java.lang.ClassLoader.defineClass1(Native Method)
       at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1007)
       at java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:174)
       at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:801)
       at java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:699)
       at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:622)
       at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:580)
       at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:185)
       at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:496)
       at com.myCompany.Runner.main(Runner.java:7)
Caused by: java.lang.ClassNotFoundException: junit.framework.TestCase
       at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:582)
       at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:185)
       at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:496)
       ... 10 more

This whole thread is originally about compiling with packages.  This latest twist looks more like it's a JUnit thing.  I'm not sure entirely.

Am I doing the following command (also mentioned in previous posts) correctly?

javac -cp c:\junit\latest\junit-4.10.jar src/test/java/com/myCompany/*.java -d classes

Thanks!

[Adam Sandler]

Tim Holloway wrote:The "-d" option on my initial example was to indicate what directory to put the compiled classes in regardless of their source.

Understand... that's why I thought it was odd javac <path>*.java failed but  javac <path>*.java -d classes worked.  I was under the impression that -d was just a place to redirect the classes to if you didn't want them to be in the same place as the source files.  This scenario, javac <path>*.java fails / javac <path>*.java -d classes works implies a dependency.

Tim Holloway wrote: And you always execute the fully-qualified classname (package name incuded).

I didn't do that with java com.myCompany.Runner?

[Adam Sandler]

Norm Radder wrote:In Tim's examples the classpath points to the classes folder.  The classes folder contains the first folder of the package: com

I'm running:

javac -cp com\myCompany

"com" is the first directory.

"com" is the first directory in the argument to javac -cp

[Norm Radder]

javac -cp com\myCompany  

For that command The last folder on the classpath needs to contain the com folder.  The posted commandline above shows that the classpath goes to the myCompany folder.  There needs to be another com folder in the myCompany folder.
The full (relative) path would be:  com\myCompany\com\myCompany\Runner.class
The red path is the package name.  The green path is the classpath.  

The classpath (in green) points to a folder: myCompany.  The first folder of the package name: (com in red) must be in the myCompany folder (where the classpath points).

[Adam Sandler]

Adam Sandler wrote:
This latest twist looks more like it's a JUnit thing.  I'm not sure entirely.

Upon doing some more research, I see I'm using JUnit 3 import statements while using a JUnit 4 jar.  So I modified BasicTest.java like so:

import org.junit.*;
import static org.junit.Assert.*;

and try to compile:

C:\workspace\BasicTest>javac -cp c:\junit\latest\junit-4.10.jar src/test/java/com/myCompany/*.java src/main/java/com/myCompany/*.java -d classes
src\test\java\com\myCompany\BasicTest.java:9: error: cannot find symbol
public class BasicTest extends TestCase {
                              ^
 symbol: class TestCase
1 error

Kinda back to the beginning.  

[Tim Holloway]

I don't see an import statement for the junit TestCase class in your test class source code.

[Adam Sandler]

Tim Holloway wrote:I don't see an import statement for the junit TestCase class in your test class source code.

It's in the original post.  

import junit.framework.TestCase;

From what I gather in the last hour or so, in JUnit 4, that's not necessarily the syntax anymore:

https://stackoverflow.com/questions/2635839/junit-confusion-use-extends-testcase-or-test

Just so I'm being clear, and with the reading I've done in the last bit, here's the full BasicTest.java (changed imports, removed extends, added annotation from the original):

package com.myCompany;

import org.junit.Assert;
import org.junit.Test;

public class BasicTest {
	
  public BasicTest() {
  }
	
  @Test
  public void testTrue() {
    Assert.assertTrue(true);
  }
}

[Tim Holloway]

You still have to import org.junit.Test if you extend TestCase. With the @Test annotation, you need the junit jar on your compile and execution classpaths. And, of course, if you're going to use Junit assertions, import org.junit.Assert.

When you get a ClassNotFoundException, one of 3 things has happened:

1. You misspelled the classname.

2. You mis-identified the package path (either it's not in that package or you mis-spelled the path).

3. You didn't include the directory or jar that contains the class in your classpath.

These 3 rules apply in both compiling and in runtime.

[Adam Sandler]

Tim Holloway wrote:You still have to import org.junit.Test if you extend TestCase.

I apologize in advance for any confusion but I thought I noted that change (not having to extend) on line 6 of the code in my last post.

Tim Holloway wrote: And, of course, if you're going to use Junit assertions, import org.junit.Assert.

Line 3 of the code in my last post?

I was just following the style from the URL in the last post... outlining the differences in they way one uses JUnit 3 and JUnit 4.

Tim Holloway wrote:3. You didn't include the directory or jar that contains the class in your classpath.  

Yep, that's it!  I had it at compile but not execute time.  This is the solution:

C:\workspace\BasicTest\classes>java -classpath c:\junit\latest\junit-4.10.jar;C:\workspace\BasicTest\classes com.myCompany.Runner

Thanks for the time... I know this is all done at the volunteer/community level it's done on personal time. This was a good learning experience; exactly what I wanted.

[Tim Holloway]

Glad we could help.

Sorry if I seemed like I was ignoring some of your examples, but what I was really trying to do was assert the facts and thus re-inforce what you'd done right. Plus sometimes you tried different things, so I wanted to make it certain what the right alternative was among the various examples you gave.

I think by now you can see why Maven is so popular, though.

And I'll admit I started out doing things the hard way (including with Windows batch files), had worked my way up to Ant, and initially resisted Maven because in Ant you could see what the build rules were, but Maven did things by "magic". But gradually I warmed up to it. Having it maintain all those dependencies helped a lot, as did having a standard project structure that could be shipped out and understood (and compiled!) anywhere.

[Jim Venolia]

Timely thread.  Popped in here with exactly the same question OP had and bingo!  Instant answer.

Thanks peeps!

[Adam Sandler]

You did fine; didn't think you were ignoring anything at all.  Sometimes things get lost in non-verbal communication so I'm a bit more patient online.

That and this isn't PERL Monks community after all... so I'm good.

The frustration of all this is exactly why I went through this exercise.  Thanks again!

and Jim... glad this helped!

[Jim Venolia]

Adam Sandler wrote:
and Jim... glad this helped!

It actually didn't, checked everything in with a "giving up on junit for now" comment

I'm guessing I have 3 issues:
A)  The junit4 to junit5 change
B)  There is only a github link to junit5, no clue what to do with that.
C)  The pre-junit5 links are dodgy and I'm not downloading anything from them.
D)  The tutorials I read either refer to a junit I don't have, or assume I know what they're talking about when I have no what they're saying.
E)  Java assumes directory structures?  Or maven, or ant, or whatever.  I have 1 file and 1 test file and I can't make junit work.  grrr

I like my editor, vi.  Or vim.  I don't know how to use vi.  My fingers do.  My brain looks at a chunk of code and sez "that needs to be there".  And there it goes, no brain input from me.  With an IDE?  Everytime I think I want to do something I have to take my hands off the home row, which means being a touch typist is a hindrance instead of an advantage.

[Tim Holloway]

Java assumes/requires directory structures for source and class files. That is true. Maven assumes additional structures for project organization, which helps both it and humans figure out where to find resources when editing or compiling. For example, most Java projects have a src/main/java and a src/test/java so that test code doesn't end up in the production output but is still available for Maven to run junit (or other) tests with.

Junit 5 is built with gradle, which has among its primary distinctions support for languages not limited to Java. The site itself is built by their Jenkins server. I didn't see a ready-made junit5 JAR available anyplace obvious - the implication seemed to be build your own and the build will install the junit5 jar in your local Maven repository. I'm not actually sure if Junit 5 is intended for prime time yet or not.

[Jim Venolia]

As all I'm doing is figuring out junit I have a very simple program (it's methods are add, subtract, multiply, and divide), and a Driver.java that does stuff like calculate 2+2 and verify the result is 4.  2 files, both in the same directory, no resources.  And a Makefile to build it all to boot

No worries, when I do real stuff I use Android Studio (junit works just fine there).

Sorry to hijack the thread.

[Tim Holloway]

I'm not sure that this is a hijack. It's basically the same question. Besides, the original question has been resolved!

Makefiles are a horrible fit for Java. Believe me, I tried. Maven or Ant are your best bet for simple command-line compiling.

For a single-file compile, though, something like:

javac com/coderanch/demo/Driver.java

should allow you to run like this:

java -classpath . com.coderanch.demo.Driver

That's of course assuming you put the following package declaration in your com/coderanch/demo/Driver:

package com.coderanch.demo

Why the package name when it's simpler to just plop everything in the base directory? Well, you can do that and omit the package name, but then the class is compiled into what's known as the default package. That's discouraged, though. Some Java tools get annoyed with resources being in the default package. Plus, from a purely housekeeping point of view, it makes it easier to distinguish one project from another.