- Login | Registered
- Collection Success Determine Collection failed, please re-collect Determine
- Share informationPass ppt/DocumentsAsk questionsWrite a blogTransfer resourcesCreate a projectCreate a code Slice
- set up nickname editing introduce yourself and let more people know about youAccount Settings Exit
- CommunityBlogForumDownloadKnowledge BaseTechnical QuestionsGeek HeadlinesHeroes ' MeetingServiceJOBCollegeCODEEventsCSTOC Currency RedemptionClubCTO ClubUniversity Club
Antineutrino's Column
- catalog view
- Summary view
- Subscription
"Expert question and Answer" Wei Chi: Python BASIC programming practical topicslarge collection of "Knowledge base" Swift Resources"Announcements" blog New Skin Onlinecsdn Welfare Phase II Building Java development and operating environmentsTags: javajdkwindowspathlinuxjava development tools2011-09-09 14:24 45668 People read Comments (6) favorite reports This article has been included in: Classification:Programmer's Log
(5) Author of similar articles
X
Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.
Key Words: Java Foundation, Java Platform version, JDK environment build, compile run Java HelloWorld program
The JDK is the abbreviation for Java Development Kit, the Java Development toolset. The JDK is the core of the entire Java, including the Java Runtime Environment (JRE), Java development Tools, and the Java base Class library.
The JRE is the abbreviation for the Java Runtime Environment, which is the Java run-time environment. The Java program must run with the JRE support.
platform version of Java:
Java is divided into J2SE, EE and J2ME three different platform versions, namely Standard Edition (Java 2 Platform, Standards Edition), Enterprise Edition (Java 2 Platform Edition) and mini-version (Java 2 Platform, Micro Edition). Starting with Java 1.5 (or Java 5.0), they are called Java SE, Java EE, and Java ME.
The difference between the platform versions is that the scope of application is different:
- The Standard Edition platform (Java SE) allows you to develop and deploy Java applications that are used in desktop, server, embedded, and live environments. In addition, Java SE contains a class library that supports the implementation of Java Web Services, so Standard Edition is the foundation of the Enterprise Edition.
- The Enterprise Edition platform (Java EE) helps developers develop and deploy Java Web applications. The Enterprise Edition provides Web services, component models, management, and communications APIs that can be used to implement enterprise-class service-oriented architectures (service-oriented Architecture, SOA) and Web 2.0 applications.
- The mini-version of the platform (Java ME) is mainly used in mobile devices and embedded devices, such as mobile phones, PDAs, TV set-top boxes and so on. The mini edition includes a flexible user interface, robust security model, many built-in network protocols, and support for dynamically downloadable online and offline applications. Java ME-based applications, like normal Java programs, can run on many devices with only one compilation.
version of Java:
- May 23, 1995, the Java language was born
- January 1996, JDK 1.0 released
- February 18, 1997, JDK 1.1 released
- December 4, 1998, J2SE 1.2 released, version 1.2 and later is also known as Java 2
- December 8, 1998, Java 2 Enterprise release
- May 8, 2000, J2SE 1.3 released
- February 13, 2002, J2SE 1.4 released
- September 30, 2004, J2SE 1.5 released, J2SE 1.5 version is also known as Java 5.0
- December 2006, Java 6.0 released
- September 2010, Java 7.0 released
Java Development and runtime Environment (Java SE):
1. Download Jdk/jre:
First, visit the Oracle Company's Java SE download home page (http://www.oracle.com/technetwork/java/javase/downloads/index.html), Select a version (currently the latest version is Java SE 7), such as:
This page contains links to multiple versions of the JDK, JRE, help documentation, source code, and other downloads. If you are not a Java programmer, just want to run Java programs in your own system, you only need a JRE, if you want to use Java to develop your own application, you need to download the JDK, which already contains the JRE, so download the JDK without having to download the JRE separately.
Here is an example of a Java SE 7 jdk, click the corresponding download button to go to the download page:
On this page, the JDK download link for each operating system is included, and the JDK of your system is selected to download it to your local hard drive. Note that you need to read "Oracle Binary Code License Agreement for Java SE" before downloading, and you must accept the terms in order to download the JDK (select "Accept License Agreement").
2. Install Jdk/jre:
Installing the JDK in Windows or Linux is simple, no different from installing other programs. (because I have no other operating system environment and no other system, so I'm not sure how to install it in other operating systems, but it shouldn't be too difficult-at least not to install other programs).
In Windows, double-clicking the "Jdk-7-windows-i586.exe" file that you just downloaded will open the installation screen. Click the "Next" button, where you can select the components to install and the installation directory, the right side of the window is a description of the selected components, including the component features and required disk space, you can click the "Change" button to change the installation directory. Click "Next" to begin the formal installation. Once the installation is complete, the installation will be completed by clicking the "Finish" button.
Under the installation folder, you can see the directory structure of the installed JDK. (Note that the folder named "JRE" is included, which is why the JDK previously said to contain the JRE)
The entire installation process is shown in the following pictures:
Note: The operating system is divided into 32-bit operating systems and 64-bit operating systems, corresponding to the JDK is also divided into 32-bit and 64-bit editions (with "i586" or "x86" in the name of the 32-bit version, with "x64" means that the JDK is 64-bit version). The 64-bit version of the JDK can only be installed on a 64-bit operating system, and the 32-bit version of the JDK may be installed on a 32-bit operating system or on a 64-bit operating system. The reason is that 64-bit operating systems are compatible with 32-bit applications.
In other words, even if the CPU is 64-bit, the 64-bit version of the JDK cannot be installed if the operating system installed is 32-bit.
Installing the JDK in Linux is the same as installing other programs. When downloading, you can select the. rpm or. tar.gz format installation files, which are explained later in this example.
First unzip the downloaded file, enter the command "TAR-XF jdk-7-linux-i586.tar.gz-c/usr", unzip the file into the/usr directory, and complete the installation ():
3. Set Environment variables:
An environment variable is a parameter that is used in the operating system to specify the operating system environment, such as the temporary folder location and the System folder location. Environment variables are equivalent to some parameters that are set for a system or application.
When you compile or run a Java program, it is based on the command line, so you must set the values of some environment variables before this. Some Java Ides (integrated development environments) have built-in JDK, so you can use these Ides without specifying environment variables. There are also programs that require personalized environment variables (such as Apache Tomcat requires java_home environment variables).
The use of JDK or JRE is related to several environment variables such as path, classpath, and so on. Let's explain what these variables mean:
The path variable is used to tell the operating system where to find a command. If you empty the value of the path variable, an unknown command error will be prompted when you run an external command in Windows (and, of course, the same in Linux):
Note: In Windows, commands such as "dir", "CD" and so on are internal commands, similar to the resident commands in DOS. These commands are automatically loaded into memory when the command-line window is started, and do not need to go to disk to find the corresponding executable file, so even if the value of the path variable is emptied, the use of these commands will not be affected. However, external commands such as "Java" must be executed by the operating system to the specified directory to find the corresponding executable program before it can be loaded and run. Where to look for these programs is to rely on the path variable to specify.
Linux is similar, even in Linux, the PATH environment variable is more important, because many of the basic Linux commands are external commands, such as "LS", "mkdir" and so on. When the path variable is emptied, these commands will not be available (of course, there are some internal commands that we can still use).
Classpath is used to tell the Java compiler or virtual machine where to look for Java class files when compiling or running a Java program, which is described in more detail later.
In Windows XP or previous versions, click on "Right click My Computer", "Properties", "Advanced", "Environment variables", in Windows Vista and Windows 7, click on "Right My Computer", "Properties", Advanced system settings, advanced, environment variables, open the Environment Variable Settings window:
Create a new user variable named path with the value "C:\Program Files (x86) \java\jdk1.7.0\bin" (remember which directory the previous JDK was installed in?). ), click the "OK" button. Then create a new classpath variable in the same way and temporarily set the value to "." (Full period). Why is it that the value of classpath is temporary and will be explained later.
When the settings are complete, the environment variable Settings window looks like this. Click the OK button and the environment variable setting is complete.
Note: In Windows, environment variables are divided into "User variables" and "System variables", the difference being that "user variables" only work for the current user, while "system variables" work for all users in the system. If you want to share settings for environment variables among multiple users, you can set these environment variables to system variables, otherwise you should use user variables to avoid affecting other users. There are similar concepts in Linux, which we'll look at next.
In Linux, you can modify the environment variables by editing the "~/.BASHRC" file. At the end, add the following lines of script, and then save and exit:
java_home=/usr/jdk1.7.0
Java_bin=/usr/jdk1.7.0/bin
Path= $PATH: $JAVA _home/bin
Classpath=.
Export Java_home java_bin PATH CLASSPATH
Note: In Linux, each user's home directory has a. bashrc file, which is used to save the user's personalization settings, such as command aliases, paths, and, of course, to define environment variables. This file is related to each user, and one user's settings do not affect other users, where setting environment variables is equivalent to the preceding Windows user environment variables. The global settings in Linux are usually saved in the "/etc/profile" file.
In addition, the delimiters for path and classpath in Linux are ":" (colons), while Windows is ";" (semicolon).
When the environment variable is set up, open a new command-line window in Windows and reload the. bashrc file with the "source ~/.BASHRC" command in Linux to make the new environment variable effective. Enter the "java-version" command, which should print something like the following two images:
Output from the Windows command line:
Output from Linux:
Add a few notes to the above steps:
- You can use commands to set environment variables in the Windows command line or in a Linux shell. For example, you can use "set Var_name=some value" in Windows and use "Var_name=some value" in Linux, which differs from the way it is described above: the setting of this method is temporary, These temporary variables are lost when you restart a new command-line window (Windows) or log back on (Linux).
- JDK Version confusion: Sometimes the "java-version" command can be used to print out the version information of the JDK, but it is inconsistent with the version of the JDK we just installed. For example, we installed JDK 7, but printed out the version information for JDK 6, as shown in:
-
Check the path variable and find that there is a path to "C:\Program Files (x86) \java\jdk1.6.0_25\bin", which originally installed two versions of JDK,JDK 6 and JDK 7 in my system. Since this JDK 6 is in the system environment variable path, and the Windows Lookup command corresponds to the program, the first look for a system variable, when found an available Java program, Windows will run this program, and no longer find further. In other words, the system PATH environment variable masks the user path environment variable.
Not only that, the program in the path near the front of the path variable will mask the program with the same name in the path after it. If the same is in the system path variable, "C:\Program Files (x86) \java\jdk1.6.0_25\bin; C:\Program files (x86) \java\jdk1.7.0\bin ", then JDK 6 will still block JDK 7 if they are exchanged in order:" C:\Program Files (x86) \java\jdk1.7.0\bin; C:\Program Files (x86) \java\jdk1.6.0_25\bin ", the result is the opposite.
Not only is it possible for a user to install multiple versions of the JDK, but many of the software products themselves will contain the JDK, even if the user installs only one JDK, but it is still possible to shield the JDK from the software (if the software also sets environment variables). For example, Oracle databases, MYECLIPSE, etc. all contain their own JDK.
Under Windows I have also encountered a problem, that is actually found in the Windows\System32 directory Java.exe, Javaw.exe, Javaws.exe three files because this directory is in a higher position in the system path variable, so it is easy to screen out the JDK that the user installs himself.
There are three ways to solve this problem:
The first approach is to use an absolute path, such as when we run the command with "C:\Program Files (x86) \java\jdk1.7.0\bin\java.exe" (Of course, the. exe can be omitted) instead of "Java." With an absolute path, the operating system navigates directly to the directory where the command resides, and is no longer found through the path variable. The advantage of this approach is that it will never cause the command to be overwritten, but the disadvantage is obvious: you must enter the full path to run the command (usually also very long).
It is important to note that when there are spaces in the absolute path (as in the example above), the command needs to be enclosed in double quotation marks. You do not need to do this when you set the path variable, and the operating system will do it automatically.
The second method is to set the JDK path that you installed to the beginning of the system path variable, so that the operating system looks for the command first to find the path we set. However, the disadvantage of this approach is that it may affect other users (set in the system path variable) and may affect other programs (the other JDK is blocked by us).
The third method is to set a new environment variable, such as "Java_home", and set its value to the path of the JDK we installed, such as "C:\Program Files (x86) \java\jdk1.7.0", when we run, just enter ""%java_home %\bin\java "" (Note that the command is enclosed in double quotation marks when the path contains spaces). Apache Tomcat uses this method.
4. Compile and run the example program:
After the above steps, the JDK environment is set up, and at this point, you may need to compile and run a Java example program to make a final test of the newly built environment. In this section, you will also be talking about how to compile and run a Java program, as well as the role of Classpath. In more detail, you can refer to another article, "a detailed description of the tools provided under the JDK."
This program consists of two. java files: Exceptiondemo.java and Helloworldexception.java, which belong to the main package, while the latter is located in the exceptions package (although it is located in the Test\exceptions folder, The purpose of this arrangement is to better describe the role of classpath):
The following are their source code:
(1) Exceptiondemo.java:
[Java]View PlainCopyprint?
-
- Package main;
-
- Import exceptions. Helloworldexception;
-
- Public class Exceptiondemo {
-
- /**
-
- *
-
- * @param args
-
- * @throws helloworldexception
-
- */
-
- public static void Main (string[] args)
-
- throws Helloworldexception {
-
- throw new Helloworldexception ();
-
- }
-
- }
package main;
import exceptions.HelloWorldException;
public class ExceptionDemo {
/**
*
* @param args
* @throws HelloWorldException
*/
public static void main(String[] args)
throws HelloWorldException {
throw new HelloWorldException();
}
}
(2) Helloworldexception.java:
[Java]View PlainCopy print?
- package exceptions;
- span class= "keyword" >public class helloworldexception extends exception {
- private Static final long serialversionuid = 8679349130620681877l;
- < span class= "keyword" >public helloworldexception () {
- super ( "hello world!");
- }
- }
package exceptions;
public class HelloWorldException extends Exception {
private static final long serialVersionUID = 8679349130620681877L;
public HelloWorldException() {
super("Hello World!");
}
}
This program is still a classic HelloWorld program (although this time it's greeting the world in a very unfriendly way-by throwing an exception).
To compile this program, first try the first method (the following operation is done under the Windows command line, Linux is similar): Enter the src folder, enter "Javac Main\exceptiondemo.java", but compile error:
Why are you suggesting that you can't find helloworldexception? That is because the Java file is located in the "test\exceptions\" directory, but its package name is "Exceptions", from the current src directory, Javac cannot find exceptions directory, because "Src\exceptions" The directory does not exist.
Next, we try the second method: from the SRC directory into the test directory, run "Javac. \main\exceptiondemo.java ":
The compilation actually passed! Can see no error, and the main directory generated a exceptiondemo.class file (Java bytecode file), the compilation is indeed successful. But why? We used the ". \main\exceptiondemo.java ", this is obviously not the Exceptiondemo package path, why the compiler does not error it? In addition, we note that I mistakenly wrote "Exceptiondemo.java" as "Exceptiondemo.java", The letter "D" is the wrong size, the compiler also did not error.
Originally, Javac just will ". \main\exceptiondemo.java "as a normal path to find Java source program files, and then start compiling this file, When it is discovered during compilation that the program also references other classes (such as the Helloworldexception class referenced in Exceptiondemo.java), it pauses compilation of the current file, starts looking for the referenced class file, and, if not found, reports an error, and the compilation fails. The previous method was a failure to find the Helloworldexception class.
So how does the Javac program find other classes referenced by the program? The answer is based on the path specified by Classpath plus the package name of the class referenced by the program. Classpath defaults to ".", which is the current path (we also set the value of Classpath to "." Before, but even if not set, Javac will default to the current path as the starting point to find the referenced class file).
So Javac will check "src\test\exceptions\" here. Whether there is a helloworldexception.class file in it, and if so, continue to check if there is a Helloworldexception.java file, and if both exist, check if Helloworldexception.class is more than helloworl Dexception.java Update, if the answer is yes, load the Helloworldexception.class and continue compiling the Exceptiondemo.java. If the comparison result is an Helloworldexception.java update, or there is no helloworldexception.class, then the Helloworldexception.java file needs to be recompiled. If only the. class file does not exist. java files, load it and continue compiling the Exceptiondemo.java.
If the target file (Helloworldexception.class or Helloworldexception.java) is not found, then Javac will report an error (as before).
That is, the compilation is recursive: When other classes are referenced in the program, JAVAC will determine if the classes need to be compiled, and if necessary, Javac will compile them first, and if they are used again by other classes, Javac will repeat the process until all the compilations are complete. As long as any class in the process is not found, or any errors are found in it, Javac will report an error and abort the compilation (Javac may compile as much as possible before aborting to report as many errors in the program as possible to the user).
You can visualize this process with the following diagram:
As for the reason that we made the case wrong but Javac did not make an error, in fact the previous explanation already implied the explanation: it is because Javac only the. java files in the command as normal files, and because Windows is case-insensitive, there is no error. If you switch to a Linux system, you will be prompted for errors that the file cannot find.
The default classpath is the current directory (".") ), we can also set the required path so that Javac finds the class file (which is why the classpath is only temporarily set to "."). of the cause). In this example, we set Classpath to ".;D: \ Workspaces\workspace_v1.1\my-test\src\test ", note that the delimiter in Linux is": "(colon). You can then compile using the command "Javac Main\exceptiondemo.java" in the SRC directory:
In fact, Exceptiondemo.java can be compiled in any directory at this point, except that the path to the file is changed appropriately. For example, we compile the following command in the D-Packing directory:
This is because Javac always find the Helloworldexception class after Classpath is set.
Sometimes you have to use classpath: when there are many classes involved, and these classes are not in the same directory, we can only use Classpath to specify the paths of these classes--we cannot be in the "current directory" of multiple classes at the same time.
Another problem to be aware of is that the JDK contains Java base classes (such as classes in the Java.lang package) and does not need to specify Classpath--java to know how to find them.
Once the compilation is complete, run our example, the example throws an exception and says hello to the world:
Note that you must enter the full package name and class name (No. class suffix is required), and the capitalization cannot be mistaken (because Java is case-sensitive). The full package name + class name in Java is called the fully qualified name of the class.
So far, we have successfully built a Java development and runtime environment.
Java Development Environment Building
