markdown test3.md
Posted
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了markdown test3.md相关的知识，希望对你有一定的参考价值。
<div id="logo" fo="http://www.w3.org/1999/XSL/Format"
rx="http://www.renderx.com/XSL/Extensions">
\
[Java SE](https://docs.oracle.com/javase/10/) > [Java SE
Specifications](https://docs.oracle.com/javase/specs/index.html) >
[Java Language Specification](index.html)
</div>
<div class="navheader">
Chapter 1. Introduction
[Prev](index.html)
[Next](jls-2.html)
------------------------------------------------------------------------
</div>
<div class="chapter" lang="en" title="Chapter 1. Introduction">
<div class="titlepage">
<div>
<div>
[]{#jls-1}Chapter 1. Introduction {#chapter1.introduction .title}
---------------------------------
</div>
</div>
</div>
<div class="toc">
**Table of Contents**
[[1.1. Organization of the Specification](jls-1.html#jls-1.1)]{.section}
[[1.2. Example Programs](jls-1.html#jls-1.2)]{.section}
[[1.3. Notation](jls-1.html#jls-1.3)]{.section}
[[1.4. Relationship to Predefined Classes and
Interfaces](jls-1.html#jls-1.4)]{.section}
[[1.5. Feedback](jls-1.html#jls-1.5)]{.section}
[[1.6. References](jls-1.html#jls-1.6)]{.section}
</div>
[]{#jls-1-100}The [Java]{.trademark}® programming language is a
general-purpose, concurrent, class-based, object-oriented language. It
is designed to be simple enough that many programmers can achieve
fluency in the language. The Java programming language is related to C
and C++ but is organized rather differently, with a number of aspects of
C and C++ omitted and a few ideas from other languages included. It is
intended to be a production language, not a research language, and so,
as C. A. R. Hoare suggested in his classic paper on language design, the
design has avoided including new and untested features.
[]{#jls-1-110}The Java programming language is strongly and statically
typed. This specification clearly distinguishes between the
[*compile-time errors*]{.emphasis} that can and must be detected at
compile time, and those that occur at run time. Compile time normally
consists of translating programs into a machine-independent byte code
representation. Run-time activities include loading and linking of the
classes needed to execute a program, optional machine code generation
and dynamic optimization of the program, and actual program execution.
[]{#jls-1-120}The Java programming language is a relatively high-level
language, in that details of the machine representation are not
available through the language. It includes automatic storage
management, typically using a garbage collector, to avoid the safety
problems of explicit deallocation (as in C's `free`{.literal} or C++'s
`delete`{.literal}). High-performance garbage-collected implementations
can have bounded pauses to support systems programming and real-time
applications. The language does not include any unsafe constructs, such
as array accesses without index checking, since such unsafe constructs
would cause a program to behave in an unspecified way.
[]{#jls-1-130}The Java programming language is normally compiled to the
bytecode instruction set and binary format defined in *The Java Virtual
Machine Specification, Java SE 10 Edition*.
<div class="section" title="1.1. Organization of the Specification">
<div class="titlepage">
<div>
<div>
[]{#jls-1.1}1.1. Organization of the Specification {#organization-of-the-specification .title style="clear: both"}
--------------------------------------------------
</div>
</div>
</div>
[]{#jls-1.1-100}Chapter 2 describes grammars and the notation used to
present the lexical and syntactic grammars for the language.
[]{#jls-1.1-110}Chapter 3 describes the lexical structure of the Java
programming language, which is based on C and C++. The language is
written in the Unicode character set. It supports the writing of Unicode
characters on systems that support only ASCII.
[]{#jls-1.1-120}Chapter 4 describes types, values, and variables. Types
are subdivided into primitive types and reference types.
[]{#jls-1.1-130}The primitive types are defined to be the same on all
machines and in all implementations, and are various sizes of
two's-complement integers, single- and double-precision IEEE 754
standard floating-point numbers, a `boolean`{.literal} type, and a
Unicode character `char`{.literal} type. Values of the primitive types
do not share state.
[]{#jls-1.1-140}Reference types are the class types, the interface
types, and the array types. The reference types are implemented by
dynamically created objects that are either instances of classes or
arrays. Many references to each object can exist. All objects (including
arrays) support the methods of the class `Object`{.literal}, which is
the (single) root of the class hierarchy. A predefined
`String`{.literal} class supports Unicode character strings. Classes
exist for wrapping primitive values inside of objects. In many cases,
wrapping and unwrapping is performed automatically by the compiler (in
which case, wrapping is called boxing, and unwrapping is called
unboxing). Class and interface declarations may be generic, that is,
they may be parameterized by other reference types. Such declarations
may then be invoked with specific type arguments.
[]{#jls-1.1-150}Variables are typed storage locations. A variable of a
primitive type holds a value of that exact primitive type. A variable of
a class type can hold a null reference or a reference to an object whose
type is that class type or any subclass of that class type. A variable
of an interface type can hold a null reference or a reference to an
instance of any class that implements the interface. A variable of an
array type can hold a null reference or a reference to an array. A
variable of class type `Object`{.literal} can hold a null reference or a
reference to any object, whether class instance or array.
[]{#jls-1.1-160}Chapter 5 describes conversions and numeric promotions.
Conversions change the compile-time type and, sometimes, the value of an
expression. These conversions include the boxing and unboxing
conversions between primitive types and reference types. Numeric
promotions are used to convert the operands of a numeric operator to a
common type where an operation can be performed. There are no loopholes
in the language; casts on reference types are checked at run time to
ensure type safety.
[]{#jls-1.1-170} Chapter 6 describes declarations and names, and how to
determine what names mean (that is, which declaration a name denotes).
The Java programming language does not require classes and interfaces,
or their members, to be declared before they are used. Declaration order
is significant only for local variables, local classes, and the order of
field initializers in a class or interface. Recommended naming
conventions that make for more readable programs are described here.
[]{#jls-1.1-180} Chapter 7 describes the structure of a program, which
is organized into packages. The members of a package are classes,
interfaces, and subpackages. Packages, and consequently their members,
have names in a hierarchical name space; the Internet domain name system
can usually be used to form unique package names. Compilation units
contain declarations of the classes and interfaces that are members of a
given package, and may import classes and interfaces from other packages
to give them short names.
[]{#jls-1.1-190} Packages may be grouped into modules that serve as
building blocks in the construction of very large programs. The
declaration of a module specifies which other modules (and thus
packages, and thus classes and interfaces) are required in order to
compile and run code in its own packages.
[]{#jls-1.1-191} The Java programming language supports limitations on
external access to the members of packages, classes, and interfaces. The
members of a package may be accessible solely by other members in the
same package, or by members in other packages of the same module, or by
members of packages in different modules. Similar constraints apply to
the members of classes and interfaces.
[]{#jls-1.1-200}Chapter 8 describes classes. The members of classes are
classes, interfaces, fields (variables) and methods. Class variables
exist once per class. Class methods operate without reference to a
specific object. Instance variables are dynamically created in objects
that are instances of classes. Instance methods are invoked on instances
of classes; such instances become the current object `this`{.literal}
during their execution, supporting the object-oriented programming
style.
[]{#jls-1.1-210} Classes support single inheritance, in which each class
has a single superclass. Each class inherits members from its
superclass, and ultimately from the class `Object`{.literal}. Variables
of a class type can reference an instance of that class or of any
subclass of that class, allowing new types to be used with existing
methods, polymorphically.
[]{#jls-1.1-220}Classes support concurrent programming with
`synchronized`{.literal} methods. Methods declare the checked exceptions
that can arise from their execution, which allows compile-time checking
to ensure that exceptional conditions are handled. Objects can declare a
`finalize`{.literal} method that will be invoked before the objects are
discarded by the garbage collector, allowing the objects to clean up
their state.
[]{#jls-1.1-230}For simplicity, the language has neither declaration
"headers" separate from the implementation of a class nor separate type
and class hierarchies.
[]{#jls-1.1-240}A special form of classes, enums, support the definition
of small sets of values and their manipulation in a type safe manner.
Unlike enumerations in other languages, enums are objects and may have
their own methods.
[]{#jls-1.1-250} Chapter 9 describes interfaces. The members of
interfaces are classes, interfaces, constant fields, and methods.
Classes that are otherwise unrelated can implement the same interface. A
variable of an interface type can contain a reference to any object that
implements the interface.
[]{#jls-1.1-251} Classes and interfaces support multiple inheritance
from interfaces. A class that implements one or more interfaces may
inherit instance methods from both its superclass and its
superinterfaces.
[]{#jls-1.1-260}Annotation types are specialized interfaces used to
annotate declarations. Such annotations are not permitted to affect the
semantics of programs in the Java programming language in any way.
However, they provide useful input to various tools.
[]{#jls-1.1-270}Chapter 10 describes arrays. Array accesses include
bounds checking. Arrays are dynamically created objects and may be
assigned to variables of type `Object`{.literal}. The language supports
arrays of arrays, rather than multidimensional arrays.
[]{#jls-1.1-280}Chapter 11 describes exceptions, which are nonresuming
and fully integrated with the language semantics and concurrency
mechanisms. There are three kinds of exceptions: checked exceptions,
run-time exceptions, and errors. The compiler ensures that checked
exceptions are properly handled by requiring that a method or
constructor can result in a checked exception only if the method or
constructor declares it. This provides compile-time checking that
exception handlers exist, and aids programming in the large. Most
user-defined exceptions should be checked exceptions. Invalid operations
in the program detected by the Java Virtual Machine result in run-time
exceptions, such as `NullPointerException`{.literal}. Errors result from
failures detected by the Java Virtual Machine, such as
`OutOfMemoryError`{.literal}. Most simple programs do not try to handle
errors.
[]{#jls-1.1-290}Chapter 12 describes activities that occur during
execution of a program. A program is normally stored as binary files
representing compiled classes and interfaces. These binary files can be
loaded into a Java Virtual Machine, linked to other classes and
interfaces, and initialized.
[]{#jls-1.1-300}After initialization, class methods and class variables
may be used. Some classes may be instantiated to create new objects of
the class type. Objects that are class instances also contain an
instance of each superclass of the class, and object creation involves
recursive creation of these superclass instances.
[]{#jls-1.1-310}When an object is no longer referenced, it may be
reclaimed by the garbage collector. If an object declares a finalizer,
the finalizer is executed before the object is reclaimed to give the
object a last chance to clean up resources that would not otherwise be
released. When a class is no longer needed, it may be unloaded.
[]{#jls-1.1-320}Chapter 13 describes binary compatibility, specifying
the impact of changes to types on other types that use the changed types
but have not been recompiled. These considerations are of interest to
developers of types that are to be widely distributed, in a continuing
series of versions, often through the Internet. Good program development
environments automatically recompile dependent code whenever a type is
changed, so most programmers need not be concerned about these details.
[]{#jls-1.1-330}Chapter 14 describes blocks and statements, which are
based on C and C++. The language has no `goto`{.literal} statement, but
includes labeled `break`{.literal} and `continue`{.literal} statements.
Unlike C, the Java programming language requires `boolean`{.literal} (or
`Boolean`{.literal}) expressions in control-flow statements, and does
not convert types to `boolean`{.literal} implicitly (except through
unboxing), in the hope of catching more errors at compile time. A
`synchronized`{.literal} statement provides basic object-level monitor
locking. A `try`{.literal} statement can include `catch`{.literal} and
`finally`{.literal} clauses to protect against non-local control
transfers.
[]{#jls-1.1-340}Chapter 15 describes expressions. This document fully
specifies the (apparent) order of evaluation of expressions, for
increased determinism and portability. Overloaded methods and
constructors are resolved at compile time by picking the most specific
method or constructor from those which are applicable.
[]{#jls-1.1-350}Chapter 16 describes the precise way in which the
language ensures that local variables are definitely set before use.
While all other variables are automatically initialized to a default
value, the Java programming language does not automatically initialize
local variables in order to avoid masking programming errors.
[]{#jls-1.1-360}Chapter 17 describes the semantics of threads and locks,
which are based on the monitor-based concurrency originally introduced
with the Mesa programming language. The Java programming language
specifies a memory model for shared-memory multiprocessors that supports
high-performance implementations.
[]{#jls-1.1-370}Chapter 18 describes a variety of type inference
algorithms used to test applicability of generic methods and to infer
types in a generic method invocation.
[]{#jls-1.1-380}Chapter 19 presents a syntactic grammar for the
language.
</div>
<div class="section" title="1.2. Example Programs">
<div class="titlepage">
<div>
<div>
[]{#jls-1.2}1.2. Example Programs {#example-programs .title style="clear: both"}
---------------------------------
</div>
</div>
</div>
[]{#jls-1.2-100}Most of the example programs given in the text are ready
to be executed and are similar in form to:
``` {.programlisting}
class Test {
public static void main(String[] args) {
for (int i = 0; i < args.length; i++)
System.out.print(i == 0 ? args[i] : " " + args[i]);
System.out.println();
}
}
```
[]{#jls-1.2-110}On a machine with the Oracle JDK installed, this class,
stored in the file `Test.java`{.literal}, can be compiled and executed
by giving the commands:
``` {.screen}
javac Test.java
java Test Hello, world.
```
[]{#jls-1.2-120}producing the output:
``` {.screen}
Hello, world.
```
</div>
<div class="section" title="1.3. Notation">
<div class="titlepage">
<div>
<div>
[]{#jls-1.3}1.3. Notation {#notation .title style="clear: both"}
-------------------------
</div>
</div>
</div>
[]{#jls-1.3-100}Throughout this specification we refer to classes and
interfaces drawn from the Java SE Platform API. Whenever we refer to a
class or interface (other than those declared in an example) using a
single identifier [*N*]{.emphasis}, the intended reference is to the
class or interface named [*N*]{.emphasis} in the package
`java.lang`{.literal}. We use the canonical name
([§6.7](jls-6.html#jls-6.7 "6.7. Fully Qualified Names and Canonical Names"){.xref})
for classes or interfaces from packages other than
`java.lang`{.literal}.
[]{#jls-1.3-200}Non-normative information, designed to clarify the
specification, is given in smaller, indented text.
This is non-normative information. It provides intuition, rationale,
advice, examples, etc.
[]{#jls-1.3-300}The type system of the Java programming language
occasionally relies on the notion of a [*substitution*]{.emphasis}. The
notation `[F1:=T1,...,Fn:=Tn]`{.literal} denotes substitution of
[F~i~]{.type} by [T~i~]{.type} for 1 [≤]{.symbol} [*i*]{.emphasis}
[≤]{.symbol} [*n*]{.emphasis}.
</div>
<div class="section"
title="1.4. Relationship to Predefined Classes and Interfaces">
<div class="titlepage">
<div>
<div>
[]{#jls-1.4}1.4. Relationship to Predefined Classes and Interfaces {#relationship-to-predefined-classes-and-interfaces .title style="clear: both"}
------------------------------------------------------------------
</div>
</div>
</div>
[]{#jls-1.4-100}As noted above, this specification often refers to
classes of the Java SE Platform API. In particular, some classes have a
special relationship with the Java programming language. Examples
include classes such as `Object`{.literal}, `Class`{.literal},
`ClassLoader`{.literal}, `String`{.literal}, `Thread`{.literal}, and the
classes and interfaces in package `java.lang.reflect`{.literal}, among
others. This specification constrains the behavior of such classes and
interfaces, but does not provide a complete specification for them. The
reader is referred to the Java SE Platform API documentation.
[]{#jls-1.4-110}Consequently, this specification does not describe
reflection in any detail. Many linguistic constructs have analogs in the
Core Reflection API (`java.lang.reflect`{.literal}) and the Language
Model API (`javax.lang.model`{.literal}), but these are generally not
discussed here. For example, when we list the ways in which an object
can be created, we generally do not include the ways in which the Core
Reflection API can accomplish this. Readers should be aware of these
additional mechanisms even though they are not mentioned in the text.
</div>
<div class="section" title="1.5. Feedback">
<div class="titlepage">
<div>
<div>
[]{#jls-1.5}1.5. Feedback {#feedback .title style="clear: both"}
-------------------------
</div>
</div>
</div>
[]{#jls-1.5-100}Readers are invited to report technical errors and
ambiguities in *The [Java]{.trademark}® Language Specification* to
`jls-jvms-spec-comments@openjdk.java.net`{.literal}.
[]{#jls-1.5-110}Questions concerning the behavior of `javac`{.literal}
(the reference compiler for the Java programming language), and in
particular its conformance to this specification, may be sent to
`compiler-dev@openjdk.java.net`{.literal}.
</div>
<div class="section" title="1.6. References">
<div class="titlepage">
<div>
<div>
[]{#jls-1.6}1.6. References {#references .title style="clear: both"}
---------------------------
</div>
</div>
</div>
<div class="bibliography" title="Bibliography">
<div class="titlepage">
<div>
<div>
### []{#d5e157}Bibliography {#bibliography .title}
</div>
</div>
</div>
<div class="bibliomixed">
[]{#d5e158}
Apple Computer. [*Dylan Reference Manual*]{.citetitle}. Apple Computer
Inc., Cupertino, California. September 29, 1995.
</div>
<div class="bibliomixed">
[]{#d5e160}
Bobrow, Daniel G., Linda G. DeMichiel, Richard P. Gabriel, Sonya E.
Keene, Gregor Kiczales, and David A. Moon. [*Common Lisp Object System
Specification*]{.citetitle}, X3J13 Document 88-002R, June 1988; appears
as Chapter 28 of Steele, Guy. [*Common Lisp: The Language*]{.citetitle},
2nd ed. Digital Press, 1990, ISBN 1-55558-041-6, 770-864.
</div>
<div class="bibliomixed">
[]{#d5e163}
Ellis, Margaret A., and Bjarne Stroustrup. [*The Annotated C++ Reference
Manual*]{.citetitle}. Addison-Wesley, Reading, Massachusetts, 1990,
reprinted with corrections October 1992, ISBN 0-201-51459-1.
</div>
<div class="bibliomixed">
[]{#d5e165}
Goldberg, Adele and Robson, David. [*Smalltalk-80: The
Language*]{.citetitle}. Addison-Wesley, Reading, Massachusetts, 1989,
ISBN 0-201-13688-0.
</div>
<div class="bibliomixed">
[]{#d5e167}
Harbison, Samuel. [*Modula-3*]{.citetitle}. Prentice Hall, Englewood
Cliffs, New Jersey, 1992, ISBN 0-13-596396.
</div>
<div class="bibliomixed">
[]{#d5e169}
Hoare, C. A. R. [*Hints on Programming Language Design*]{.citetitle}.
Stanford University Computer Science Department Technical Report No.
CS-73-403, December 1973. Reprinted in SIGACT/SIGPLAN Symposium on
Principles of Programming Languages. Association for Computing
Machinery, New York, October 1973.
</div>
<div class="bibliomixed">
[]{#d5e171}
[*IEEE Standard for Binary Floating-Point Arithmetic*]{.citetitle}.
ANSI/IEEE Std. 754-1985. Available from Global Engineering Documents, 15
Inverness Way East, Englewood, Colorado 80112-5704 USA; 800-854-7179.
</div>
<div class="bibliomixed">
[]{#d5e173}
Kernighan, Brian W., and Dennis M. Ritchie. [*The C Programming
Language*]{.citetitle}, 2nd ed. Prentice Hall, Englewood Cliffs, New
Jersey, 1988, ISBN 0-13-110362-8.
</div>
<div class="bibliomixed">
[]{#d5e175}
Madsen, Ole Lehrmann, Birger Møller-Pedersen, and Kristen Nygaard.
[*Object-Oriented Programming in the Beta Programming
Language*]{.citetitle}. Addison-Wesley, Reading, Massachusetts, 1993,
ISBN 0-201-62430-3.
</div>
<div class="bibliomixed">
[]{#d5e177}
Mitchell, James G., William Maybury, and Richard Sweet. [*The Mesa
Programming Language, Version 5.0*]{.citetitle}. Xerox PARC, Palo Alto,
California, CSL 79-3, April 1979.
</div>
<div class="bibliomixed">
[]{#d5e179}
Stroustrup, Bjarne. [*The C++ Progamming Language*]{.citetitle}, 2nd ed.
Addison-Wesley, Reading, Massachusetts, 1991, reprinted with corrections
January 1994, ISBN 0-201-53992-6.
</div>
<div class="bibliomixed">
[]{#d5e181}
Unicode Consortium, The. [*The Unicode Standard, Version
8.0.0*]{.citetitle}. Mountain View, California, 2015, ISBN
978-1-936213-10-8.
</div>
</div>
</div>
</div>
<div class="navfooter">
------------------------------------------------------------------------
------------------------------------------------- -------------------- ----------------------
[Prev](index.html) [Next](jls-2.html)
The [Java]{.trademark}® Language Specification [Home](index.html) Chapter 2. Grammars
------------------------------------------------- -------------------- ----------------------
</div>
<div class="navfooter" fo="http://www.w3.org/1999/XSL/Format"
rx="http://www.renderx.com/XSL/Extensions">
------------------------------------------------------------------------
[Legal Notice](spec-frontmatter.html)
</div>
以上是关于markdown test3.md的主要内容，如果未能解决你的问题，请参考以下文章