The java <class-name>
command syntax
First of all, you need to understand the correct way to launch a program using the java
(or javaw
) command.
The normal syntax1 is this:
java [ <options> ] <class-name> [<arg> ...]
where <option>
is a command line option (starting with a "-" character), <class-name>
is a fully qualified Java class name, and <arg>
is an arbitrary command line argument that gets passed to your application.
1 - There are some other syntaxes which are described near the end of this answer.
The fully qualified name (FQN) for the class is conventionally written as you would in Java source code; e.g.
packagename.packagename2.packagename3.ClassName
However some versions of the java
command allow you to use slashes instead of periods; e.g.
packagename/packagename2/packagename3/ClassName
which (confusingly) looks like a file pathname, but isn't one. Note that the term fully qualified name is standard Java terminology ... not something I just made up to confuse you :-)
Here is an example of what a java
command should look like:
java -Xmx100m com.acme.example.ListUsers fred joe bert
The above is going to cause the java
command to do the following:
- Search for the compiled version of the
com.acme.example.ListUsers
class.
- Load the class.
- Check that the class has a
main
method with signature, return type and modifiers given by public static void main(String[])
. (Note, the method argument's name is NOT part of the signature.)
- Call that method passing it the command line arguments ("fred", "joe", "bert") as a
String[]
.
Reasons why Java cannot find the class
When you get the message "Could not find or load main class ...", that means that the first step has failed. The java
command was not able to find the class. And indeed, the "..." in the message will be the fully qualified class name that java
is looking for.
So why might it be unable to find the class?
Reason #1 - you made a mistake with the classname argument
The first likely cause is that you may have provided the wrong class name. (Or ... the right class name, but in the wrong form.) Considering the example above, here are a variety of wrong ways to specify the class name:
Example #1 - a simple class name:
java ListUser
When the class is declared in a package such as com.acme.example
, then you must use the full classname including the package name in the java
command; e.g.
java com.acme.example.ListUser
Example #2 - a filename or pathname rather than a class name:
java ListUser.class
java com/acme/example/ListUser.class
Example #3 - a class name with the casing incorrect:
java com.acme.example.listuser
Example #4 - a typo
java com.acme.example.mistuser
Example #5 - a source filename (except for Java 11 or later; see below)
java ListUser.java
Example #6 - you forgot the class name entirely
java lots of arguments
Reason #2 - the application's classpath is incorrectly specified
The second likely cause is that the class name is correct, but that the java
command cannot find the class. To understand this, you need to understand the concept of the "classpath". This is explained well by the Oracle documentation:
So ... if you have specified the class name correctly, the next thing to check is that you have specified the classpath correctly:
- Read the three documents linked above. (Yes ... READ them! It is important that a Java programmer understands at least the basics of how the Java classpath mechanisms works.)
- Look at command line and / or the CLASSPATH environment variable that is in effect when you run the
java
command. Check that the directory names and JAR file names are correct.
- If there are relative pathnames in the classpath, check that they resolve correctly ... from the current directory that is in effect when you run the
java
command.
- Check that the class (mentioned in the error message) can be located on the effective classpath.
- Note that the classpath syntax is different for Windows versus Linux and Mac OS. (The classpath separator is
;
on Windows and :
on the others. If you use the wrong separator for your platform, you won't get an explicit error message. Instead, you will get a nonexistent file or directory on the path that will be silently ignored.)
Reason #2a - the wrong directory is on the classpath
When you put a directory on the classpath, it notionally corresponds to the root of the qualified name space. Classes are located in the directory structure beneath that root, by mapping the fully qualified name to a pathname. So for example, if "/usr/local/acme/classes" is on the class path, then when the JVM looks for a class called com.acme.example.Foon
, it will look for a ".class" file with this pathname:
/usr/local/acme/classes/com/acme/example/Foon.class
If you had put "/usr/local/acme/classes/com/acme/example" on the classpath, then the JVM wouldn't be able to find the class.
Reason #2b - the subdirectory path doesn't match the FQN
If your classes FQN is com.acme.example.Foon
, then the JVM is going to look for "Foon.class" in the directory "com/acme/example":
If your directory structure doesn't match the package naming as per the pattern above, the JVM won't find your class.
If you attempt rename a class by moving it, that will fail as well ... but the exception stacktrace will be different. It is liable to say something like this:
Caused by: java.lang.NoClassDefFoundError: <path> (wrong name: <name>)
because the FQN in the class file doesn't match what the class loader is expecting to find.
To give a concrete example, supposing that:
- you want to run
com.acme.example.Foon
class,
- the full file path is
/usr/local/acme/classes/com/acme/example/Foon.class
,
- your current working directory is
/usr/local/acme/classes/com/acme/example/
,
then:
# wrong, FQN is needed
java Foon
# wrong, there is no `com/acme/example` folder in the current working directory
java com.acme.example.Foon
# wrong, similar to above
java -classpath . com.acme.example.Foon
# fine; relative classpath set
java -classpath ../../.. com.acme.example.Foon
# fine; absolute classpath set
java -classpath /usr/local/acme/classes com.acme.example.Foon
Notes:
- The
-classpath
option can be shortened to -cp
in most Java releases. Check the respective manual entries for java
, javac
and so on.
- Think carefully when choosing between absolute and relative pathnames in classpaths. Remember that a relative pathname may "break" if the current directory changes.
Reason #2c - dependencies missing from the classpath
The classpath needs to include all of the other (non-system) classes that your application depends on. (The system classes are located automatically, and you rarely need to concern yourself with this.) For the main class to load correctly, the JVM needs to find:
(Note: the JLS and JVM specifications allow some scope for a JVM to load classes "lazily", and this can affect when a classloader exception is thrown.)
Reason #3 - the class has been declared in the wrong package
It occasionally happens that someone puts a source code file into the
the wrong folder in their source code tree, or they leave out the package
declaration. If you do this in an IDE, the IDE's compiler will tell you about this immediately. Similarly if you use a decent Java build tool, the tool will run javac
in a way that will detect the problem. However, if you build your Java code by hand, you can do it in such a way that the compiler doesn't notice the problem, and the resulting ".class" file is not in the place that you expect it to be.
Still can't find the problem?
There lots of things to check, and it is easy to miss something. Try adding the -Xdiag
option to the java
command line (as the first thing after java
). It will output various things about class loading, and this may offer you clues as to what the real problem is.
Also, consider possible problems caused by copying and pasting invisible or non-ASCII characters from websites, documents and so on. And consider "homoglyphs", where two letters or symbols look the same ... but aren't.
Finally, you can apparently run into this problem if you try to launch from a JAR file with incorrect signatures in (META-INF/*.SF)
or if there is a syntax error in the MANIFEST.MF
file (see https://stackoverflow.com/a/67145190/139985).
Alternative syntaxes for java
There are three alternative syntaxes for the launching Java programs using the java command
.
The syntax used for launching an "executable" JAR file is as follows:
java [ <options> ] -jar <jar-file-name> [<arg> ...]
e.g.
java -Xmx100m -jar /usr/local/acme-example/listuser.jar fred
The name of the entry-point class (i.e. com.acme.example.ListUser
) and the classpath are specified in the MANIFEST of the JAR file.
The syntax for launching an application from a module (Java 9 and later) is as follows:
java [ <options> ] --module <module>[/<mainclass>] [<arg> ...]
The name of the entrypoint class is either defined by the <module>
itself, or is given by the optional <mainclass>
.
From Java 11 onwards, you can use the java
command to compile and run a single source code file using the following syntax:
java [ <options> ] <sourcefile> [<arg> ...]
where <sourcefile>
is (typically) a file with the suffix ".java".
For more details, please refer to the official documentation for the java
command for the Java release that you are using.
IDEs
A typical Java IDE has support for running Java applications in the IDE JVM itself or in a child JVM. These are generally immune from this particular exception, because the IDE uses its own mechanisms to construct the runtime classpath, identify the main class and create the java
command line.
However it is still possible for this exception to occur, if you do things behind the back of the IDE. For example, if you have previously set up an Application Launcher for your Java app in Eclipse, and you then moved the JAR file containing the "main" class to a different place in the file system without telling Eclipse, Eclipse would unwittingly launch the JVM with an incorrect classpath.
In short, if you get this problem in an IDE, check for things like stale IDE state, broken project references or broken launcher configurations.
It is also possible for an IDE to simply get confused. IDE's are hugely complicated pieces of software comprising many interacting parts. Many of these parts adopt various caching strategies in order to make the IDE as a whole responsive. These can sometimes go wrong, and one possible symptom is problems when launching applications. If you suspect this could be happening, it is worth trying other things like restarting your IDE, rebuilding the project and so on.
Other References
Some HTTP clients accept this certificate, and others do not. What could make the difference?
The short answer: load balancing, virtual hosting and SNI.
The long answer... first, here's an analysis of the certificate. We need to go though this to ensure there's no obvious mistakes.
From the dump below, there's a wildcard DNS name in the Common Name. Placing a DNS name in the CN is deprecated by both the IETF and the CA/Browser Forums. A "friendly name" should be placed in the CN because its displayed to the user. While its deprecated, its not forbidden.
Instead, DNS names should go in the Subject Alternate Name. There should be two of them. The first would be lucidpress.com
and the second would be *.lucidpress.com
. You need just lucidpress.com
because the wildcard needs to match a label.
For reference, the IETF deprecates a DNS name in the CN in RFC 6125 Section 3.1 Server Identity; and Section 6.4.4 Checking of Common Names.
The CA/Browser Forums deprecates a DNS name in the CN in Baseline Requirements (BR) Section 9.2.2 Subject Common Name Field. Also, according to the CA/B, the Subject Alternate Name is required. See Section 9.2.1 Subject Alternative Name Extension.
Related: RFC 6125, Section 6.4.3, also does not allow the matching of *.lucidpress.com
to lucidpress.com
. The CA/B BR covers wildcards in Section 11.1.3, but it does not discuss matching rules.
With the background information above and the certificate below, here's what is going on.
You have 2 names in the default certificate. Its served by default by Apache because its the first virtual host in the configuration file.
lucidchart.com
*.lucidchart.com
You have 2 names in the Lucid Press' certificate.
lucidpress.com
*.lucidpress.com
I think the difference is Server Name Indication (SNI). Its a TLS extension, so you need TLS 1.0 or above. Those that have no trouble get the Lucid Press certifcate and use TLS 1.0 or above with SNI; those that have trouble get the default certificate and use SSLv3 or no SNI. Windows XP will use TLS 1.0 but not SNI, so its experienced often in the field due to the deployment base.
The browsers accept it because they are using TLS 1.0 or above and sending the SNI extension. Because SNI allows your Apache server to select the proper certificate during the handshake, there are no name matching problems.
Java rejects it because it uses SSLv3, even when you say SSLContext.getInstance("TLS");
. You have to jump through some hoops to ensure you really get TLS 1.0 and above. There's a few questions on Stack Overflow about it. See, for example, Which Cipher Suites to enable for SSL Socket?.
Python
rejects it because I'm guessing you are using 2.x, or you are allowing SSLv3. You need 3.0 or above to get SNI. See Python 3 Support? on the Python FAQ.
wget
added support for SNI in version 1.14. I suspect wget
is not enabling its or using SSLv3.
cURL
likely ensures SNI is used if available. Daniel is very thorough, and he tries to ensure a trouble free experience and secure posture out of the box.
In the OpenSSL dump, the options of interest are -tls1 -servername
. You can get TLS without SNI by omitting -servername
. So you need both tls1
and -servername <host>
.
$ openssl s_client -tls1 -servername www.lucidpress.com \
-connect www.lucidpress.com:443 | openssl x509 -text -noout
depth=3 C = US, O = "The Go Daddy Group, Inc.", OU = Go Daddy Class 2 Certification Authority
verify error:num=19:self signed certificate in certificate chain
verify return:0
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 12250220837273305 (0x2b8582cd6cfed9)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., OU=http://certs.godaddy.com/repository/, CN=Go Daddy Secure Certificate Authority - G2
Validity
Not Before: May 12 16:20:34 2014 GMT
Not After : Jul 9 22:19:45 2015 GMT
Subject: OU=Domain Control Validated, CN=*.lucidpress.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:c8:e0:f6:77:03:c9:5e:cb:51:e3:d3:7a:b6:60:
d9:3d:60:26:9c:4b:00:c5:cb:b1:55:2e:d9:ee:f5:
08:8d:b7:64:e9:31:2e:83:e4:24:f3:89:4e:46:87:
b8:55:b6:34:0a:c9:3b:55:08:10:77:13:7e:85:d6:
8c:fa:06:dd:c1:7f:fa:9e:13:c8:1a:d8:36:22:3c:
cb:16:9f:cb:c7:5b:7c:7c:0b:6d:c3:ef:24:45:15:
5a:7a:38:dd:df:83:eb:c3:ea:9b:57:d5:8f:d8:6c:
ff:33:4a:21:02:2a:92:9a:e0:5d:58:51:75:07:b6:
ad:21:8c:34:91:20:f5:00:9e:f6:dd:90:7e:a8:60:
0e:14:73:de:90:a1:f4:29:83:a0:d8:9d:29:e5:de:
c5:cb:b5:36:84:ba:30:d4:a9:9f:b9:bf:89:26:e5:
80:5a:f6:3b:27:cc:6d:3f:31:1e:cc:51:09:12:73:
a6:de:da:b9:a4:19:86:68:7f:e6:2b:c7:3b:a6:ce:
6a:5a:dd:c9:ac:61:18:80:f5:d4:f1:6a:70:2c:9f:
8f:af:a6:c5:1d:78:97:97:90:92:6c:21:61:39:ce:
f8:c9:99:e2:02:b5:ce:ba:dc:f4:46:ba:e3:1f:ec:
ce:a5:e4:6b:56:1e:e6:20:89:44:7b:2c:9f:3a:c4:
33:f1
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 CRL Distribution Points:
Full Name:
URI:http://crl.godaddy.com/gdig2s1-59.crl
X509v3 Certificate Policies:
Policy: 2.16.840.1.114413.1.7.23.1
CPS: http://certificates.godaddy.com/repository/
Authority Information Access:
OCSP - URI:http://ocsp.godaddy.com/
CA Issuers - URI:http://certificates.godaddy.com/repository/gdig2.crt
X509v3 Authority Key Identifier:
keyid:40:C2:BD:27:8E:CC:34:83:30:A2:33:D7:FB:6C:B3:F0:B4:2C:80:CE
X509v3 Subject Alternative Name:
DNS:*.lucidpress.com, DNS:lucidpress.com
X509v3 Subject Key Identifier:
CA:97:CC:32:09:20:3E:5F:23:05:4C:DD:F2:DA:4B:1C:E5:02:E8:69
Signature Algorithm: sha256WithRSAEncryption
4e:0c:8e:af:d5:c7:06:9e:b9:2c:36:97:d0:9e:1c:84:e8:e1:
69:5a:36:a3:4f:9f:81:c9:78:5d:ca:35:df:63:be:23:88:4c:
ba:eb:17:15:22:78:96:5d:5f:dc:3b:fa:cf:14:b6:e9:3a:fe:
28:19:1c:85:d2:1b:23:b3:79:6d:b2:1d:76:6b:84:97:80:43:
1b:c0:b7:14:78:75:f9:47:31:6e:21:56:0d:5e:73:ed:d3:b2:
4b:ab:dc:b0:af:18:ee:2d:bb:65:ff:c7:cb:ff:53:64:8f:a5:
e8:aa:45:da:fc:0f:b5:8f:da:0f:3e:b1:3b:d0:47:49:52:af:
8d:f7:a3:42:3b:d3:a1:f4:a1:22:d5:fe:2f:4c:59:b4:18:3f:
62:1e:4e:56:65:9b:2b:d6:76:cd:29:74:d6:74:a4:7b:bb:6f:
b2:1d:45:12:67:14:b3:06:a7:36:ee:3a:48:d1:d6:80:2b:fa:
6d:8b:64:01:0f:1e:51:48:0f:8b:e3:7d:13:86:79:a2:b2:04:
05:cb:8d:07:35:d9:fa:7e:6d:5d:42:c0:a5:f4:b2:8e:57:53:
24:b3:aa:e6:92:b1:70:07:73:98:00:91:9b:0f:3e:6e:fe:1d:
78:7c:57:68:47:d7:8e:6f:1a:64:26:7b:69:f5:b1:13:c2:71:
2d:ac:56:b6
$ dig www.lucidchart.com
; <<>> DiG 9.8.5-P1 <<>> www.lucidchart.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19608
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.lucidchart.com. IN A
;; ANSWER SECTION:
www.lucidchart.com. 8 IN CNAME chart-production-webserver-1858537325.us-east-1.elb.amazonaws.com.
chart-production-webserver-1858537325.us-east-1.elb.amazonaws.com. 10 IN A 107.23.98.6
chart-production-webserver-1858537325.us-east-1.elb.amazonaws.com. 10 IN A 54.236.129.63
chart-production-webserver-1858537325.us-east-1.elb.amazonaws.com. 10 IN A 54.88.154.168
;; Query time: 23 msec
;; SERVER: 172.16.1.10#53(172.16.1.10)
;; WHEN: Sun Aug 10 00:02:52 EDT 2014
;; MSG SIZE rcvd: 160
$ dig www.lucidpress.com
; <<>> DiG 9.8.5-P1 <<>> www.lucidpress.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34260
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.lucidpress.com. IN A
;; ANSWER SECTION:
www.lucidpress.com. 599 IN CNAME chart-production-webserver-1858537325.us-east-1.elb.amazonaws.com.
chart-production-webserver-1858537325.us-east-1.elb.amazonaws.com. 59 IN A 54.88.154.168
chart-production-webserver-1858537325.us-east-1.elb.amazonaws.com. 59 IN A 107.23.98.6
chart-production-webserver-1858537325.us-east-1.elb.amazonaws.com. 59 IN A 54.236.129.63
;; Query time: 48 msec
;; SERVER: 172.16.1.10#53(172.16.1.10)
;; WHEN: Sun Aug 10 00:02:38 EDT 2014
;; MSG SIZE rcvd: 160
If interested, this is from sslscan
:
Prefered Server Cipher(s):
SSLv3 256 bits DHE-RSA-AES256-SHA
TLSv1 256 bits DHE-RSA-AES256-SHA
TLSv1.1 256 bits DHE-RSA-AES256-SHA
TLSv1.2 256 bits DHE-RSA-AES256-GCM-SHA384
Best Answer
The problem is the prime size. The maximum-acceptable size that Java accepts is 1024 bits. This is a known issue (see JDK-6521495).
The bug report that I linked to mentions a workaround using BouncyCastle's JCE implementation. Hopefully that should work for you.
UPDATE
This was reported as bug JDK-7044060 and fixed recently.
Note, however, that the limit was only raised to 2048 bit. For sizes > 2048 bit, there is JDK-8072452 - Remove the maximum prime size of DH Keys; the fix appears to be for 9.