Getting started with Java-Environment Variables

Speaking of the story, I think many posts are just a new example. I started to write a Java program using the original library javac.exe‑java.exe. I still thought that it would be okay if I could use ide To write a Java program? But slowly, I found that I could not even understand the most basic import. For some small programs, a package and several class files can be done, but if you want to reuse the previous class, you don't know how to do it. So, huh, let's take a look at the configuration of the most basic environment variable!

The reason for starting with environment variables is mainly because some ides automatically set the Java path. That is to say, after JDK and IDE are installed, you don't need to worry about anything, simply write the code. However, the Java package mechanism is closely related to environment variables. I am not going to talk about environment variables. Which of the following is interesting? Baidu has a lot to do. After all, this is not the focus of this article ~

Well, there are a lot of related environment variables on the Internet in Java. I found an article that inspired me a lot. I deleted some of the nonsense. I wanted to post the author. Unfortunately, I did not know who the author was. I can only pay tribute to the author in my heart...

In Windows, Java mainly uses three environment variables: java_home, classpath, and path.
Java_home points to the JDK installation path, such as C:/jdk_1.4.2. In this path, you should be able to find the bin, Lib, and other directories. It is worth mentioning that you can select any disk directory for the JDK installation path, but we recommend that you set the directory level to a simple one.
Setting method:
Java_home = C:/jdk_1.4.2
The path environment variable exists in Windows. You only need to modify it to point it to the JDK bin directory, in this way, you do not need to enter a large string of paths when compiling and executing programs in the console. The setting method is to keep the original path content and add % java_home %/bin to it (Note: if you do not know about DOS batch processing, you may not understand the meaning of the content caused by %. In fact, the environment variable java_home set in the previous step is referenced here. You can write it as C:/jdk_1.4.2; you can open a console window and enter echo % java_home % to check your settings ):
Path = % java_home %/bin; % PATH %
Similarly, % PATH % references the previously set path environment variable. You just copy the previous value.
I put the classpath environment variables at the end, because you may encounter inexplicable and strange problems later. More than 80% may be caused by incorrect classpath settings, so be careful.
Classpath =.; % java_home %/lib/tools. Jar
The first thing to note is the front "..;". If you cannot see it clearly, I will read it for you-a semicolon. This tells JDK to first find the class file in the current directory when searching for the class.
The specific setting method is as follows: Right-click Win2k/XP and choose "my computer"> "properties"> "advanced"> "environment variable". Modify the value in the system variable box below.

In this way, the environment variables are basically set.

So I create a helloworld. Java file anywhere on the hard disk, such as the root directory of the E disk. The content is as follows:

Public class helloworld ...{
Public static void main (string [] ARGs )...{
System. Out. println ("Hello, world! ");
}
}

Then, at the command prompt, type the following statement to run the program.

C:/Documents and Settings/lzj> E:

E:/> javac helloworld. Java

E:/> JAVA helloworld
Hello, world!

But what if we want to put this helloworld file into a package? Try to add the statement package lzj In the first line of helloworld; what will happen?

Create a folder in the E disk, name it lzj, and cut the modified helloworld. Java into the folder, compile, and run it.

E:/> Cd lzj

E:/lzj> javac helloworld. Java

E:/lzj> JAVA helloworld
Exception in thread "Main" Java. Lang. noclassdeffounderror: helloworld (wrong Nam
E: lzj/helloworld)
At java. Lang. classloader. defineclass1 (native method)
At java. Lang. classloader. defineclass (unknown source)
At java. Security. secureclassloader. defineclass (unknown source)
At java.net. urlclassloader. defineclass (unknown source)
At java.net. urlclassloader. Access $100 (unknown source)
At java.net. urlclassloader $ 1.run( unknown source)
At java. Security. accesscontroller. doprivileged (native method)
At java.net. urlclassloader. findclass (unknown source)
At java. Lang. classloader. loadclass (unknown source)
At sun. Misc. launcher $ appclassloader. loadclass (unknown source)
At java. Lang. classloader. loadclass (unknown source)
At java. Lang. classloader. loadclassinternal (unknown source)

Dizzy, but this time there is an error...

Why? Because helloworld is now affiliated to lzj, Java should be positioned as lzj. helloworld when locating it. So ...... We should run it like this:

E:/lzj> Cd ..

E:/> JAVA lzj. helloworld
Hello, world!

Haha, it's successful! Through this example, we understand that the name of the class file in the package should be "package name. Class Name. In fact, let's think about it. Isn't it all like this in programming to locate a class, for example, java. util. Calendar. -- Except for the class in the Java. lang Package and the package imported using import.

 

-- Okay, this is almost the same. It's time to take the electives ...... If you have time in the evening, I will talk about how to configure your own toolkit, but it works in the same way, very simple ~