Package environment variables and access control and maven profile to implement multi environment packaging

Package in Java

Java USES packages to organize code, first to make the code structure of large projects clear, and second to package is a namespace division, that is, different packages can have the same name of the class, just add the package name before the class name to distinguish them.

Package XXX must be on the first line of the Java file other than the comments to indicate which Package the classes in the current file belong to, and if there is no Package statement, the classes in that file belong to the default Package.

Import XXX is used to Import classes in the current Java file that are not part of the current package so that they can be used in the current file.

Environment variables in Java

1. The path

An environment variable is simply a set of variables (nonsense) that provide parameters to a system and application. For example, path tells the system and applications where to store some necessary programs. For example, if you want to run the ipconfig command, where can the system find it?

In Java, where does the Java application (exe file) go when we want to run the Java program and enter Java XXX at the console? The system passes through path, which copies the directory containing the Java application into the path environment variable, so that running Java XXX later does not result in "' Java 'is not an internal or external command, nor is it a runnable program or batch file." .

2. The classpath

With that said path, classpath solves the problem with the Java command, and with the javac command, which involves the package mechanism in Java.

Java programs are made up of one class at a time, one class at a time, one class at a time, one class at a time, one class at a time, one class at a time, one class at a time, one class at a time, one class at a time, one class at a time, one class at a time, one class at a time, one class at a time, one class at a time.

Summary: classpath specifies the class lookup path, and if the class is not packaged, you need to add its directory to the classpath, and if the class is packaged as a JAR file, you need to write down the actual name of the JAR file.

Classpath is usually set to ". The % JAVA_HOME % \ lib \ dt. Jar; % JAVA_HOME % \ lib \ tools. Jar;"

Where. Represents the current directory and %JAVA_HOME% represents the path to the Java JDK. The dt.jar is dominated by the various control classes in the swing package. In tools.jar are the various tool classes.

When the compiler encounters an import statement, it starts looking in the directory contained in the CLASSPATH.

(reference: (the link: http://www.linuxidc.com/Linux/2012-01/52713.htm))

3. The JAVA_HOME

Specify the path to the JDK

Access control

1. Access control of class members

Access control :public/protected/ package access (no keyword, default) /private

	The class itself	Subclasses in the same package	Subclasses in different packages	Non-subclasses in the same package	Non-subclasses in different packages	In a word
public	can	can	can	can	can	Can be
private	can	Can not be	Can not be	Can not be	Can not be	Self visible only
default	can	can	Can not be	can	Can not be	Only the same package is visible
protected	can	can	can	can	Can not be	Subclass or same package visible

2. Access control permission of the class

Classes have only two types of access control permissions: default (that is, package access control) and public

There is still some time to go, and then I will introduce you to the maven profile implementation of multi-environment packaging

Project development requires multiple environments, generally including development, test, pre-release and four formal environments. Maven can be used to realize packaging and deployment according to different environments. The command is:
MVN package - P dev

Where "dev" is the variable id of the environment, which can be defined by myself. The name I defined is: dev,qa,pre,prod. The specific configuration in pom.xml is as follows:

<?xml version="1.0" encoding="UTF-8"?> 
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> 
  ...... 
  <profiles> 
    <profile> 
      <id>dev</id> 
      <properties> 
        <env>dev</env> 
      </properties> 
      <activation> 
        <activeByDefault>true</activeByDefault> 
      </activation> 
    </profile> 
    <profile> 
      <id>qa</id> 
      <properties> 
        <env>qa</env> 
      </properties> 
    </profile> 
    <profile> 
      <id>pre</id> 
      <properties> 
        <env>pre</env> 
      </properties> 
    </profile> 
    <profile> 
      <id>prod</id> 
      <properties> 
        <env>prod</env> 
      </properties> 
    </profile> 
  </profiles> 
......  
  <build> 
    <filters> 
      <filter>config/${env}.properties</filter> 
    </filters> 
    <resources> 
      <resource> 
        <directory>src/main/resources</directory> 
        <filtering>true</filtering> 
      </resource> 
    </resources> 
    ...... 
  </build> 
</project> 

1. Profiles defines the variable ids for each environment
2. Filters defines the address of the variable profile, where the environment variable in the address is the value defined in the profile above
3. In resources, we define which files in the directory will be replaced by variables defined in the configuration file. Generally, we will put the configuration file of the project under SRC /main/resources, such as db,bean, etc., and the variables used in them will be replaced with fixed values according to the variable configuration in the filter when packaging