jdk11编译版本

⑴ 如何查看一个jar文件是用什么版本jdk编译的

有一种稍微麻烦的办法，可以试试
在jar包中，用winrar解压一个类文件，然后在命令行下面输入
javap -verbose classname
会输出一些信息，大致如下:

Compiled from "HtmlCrawer.java"
public class org.eagleeye.html.HtmlCrawer extends java.lang.Object
SourceFile: "HtmlCrawer.java"
minor version: 0
major version: 50
Constant pool:
const #1 = class #2; // org/eagleeye/html/HtmlCrawer
const #2 = Asciz org/eagleeye/html/HtmlCrawer;
const #3 = class #4; // java/lang/Object
const #4 = Asciz java/lang/Object;
const #5 = Asciz client;
....

后面省略了，可以看到前面有两行:
minor version: 0
major version: 50
表示了类文件的版本，具体内容可以参考:

2008-05-08 17:27 class version一：要解决的问题

我们在尝鲜 JDK1.5 的时候，相信不少人遇到过 Unsupported major.minor version 49.0 错误，当时定会茫然不知所措。因为刚开始那会儿，网上与此相关的中文资料还不多，现在好了，网上一找就知道是如何解决，大多会告诉你要使用 JDK 1.4 重新编译。那么至于为什么，那个 major.minor 究竟为何物呢？这就是本篇来讲的内容，以使未错而先知。

我觉得我是比较幸运的，因为在遇到那个错误之前已研读过《深入 Java 虚拟机》第二版，英文原书名为《Inside the Java Virtual Machine》( Second Edition)，看时已知晓 major.minor 藏匿于何处，但没有切身体会，待到与 Unsupported major.minor version 49.0 真正会面试，正好是给我验证了一个事实。

首先我们要对 Unsupported major.minor version 49.0 建立的直接感觉是：JDK1.5 编译出来的类不能在 JVM 1.4 下运行，必须编译成 JVM 1.4 下能运行的类。(当然，也许你用的还是 JVM 1.3 或 JVM 1.2，那么就要编译成目标 JVM 能认可的类)。这也解决问题的方向。

二：major.minor 栖身于何处

何谓 major.minor，且又居身于何处呢？先感性认识并找到 major.minor 来。

写一个 Java Hello World! 代码，然后用 JDK 1.5 的编译器编译成，HelloWorld.java

public class HelloWorld { public static void main(String[] args) { System.out.println("Hello, World!"); } } public class HelloWorld { public static void main(String[] args) { System.out.println("Hello, World!"); } }

用 JDK 1.5 的 javac HelloWorld.java 编译出来的字节码 HelloWorld.class 用 UltraEdit 打开来的内容如图所示：

从上图中我们看出来了什么是 major.minor version 了，它相当于一个软件的主次版本号，只是在这里是标识的一个 Java Class 的主版本号和次版本号，同时我们看到 minor_version 为 0x0000，major_version 为 0x0031，转换为十制数分别为0 和 49，即 major.minor 就是 49.0 了。

三：何谓 major.minor 以及何用

Class 文件的第 5-8 字节为 minor_version 和 major_version。Java class 文件格式可能会加入新特性。class 文件格式一旦发生变化，版本号也会随之变化。对于 JVM 来说，版本号确定了特定的 class 文件格式，通常只有给定主版本号和一系列次版本号后，JVM 才能够读取 class 文件。如果 class 文件的版本号超出了 JVM 所能处理的有效范围，JVM 将不会处理该 class 文件。

在 Sun 的 JDK 1.0.2 发布版中，JVM 实现支持从 45.0 到 45.3 的 class 文件格式。在所有 JDK 1.1 发布版中的 JVM 都能够支持版本从 45.0 到 45.65535 的 class 文件格式。在 Sun 的 1.2 版本的 SDK 中，JVM 能够支持从版本 45.0 到46.0 的 class 文件格式。

1.0 或 1.2 版本的编译器能够产生版本号为 45.3 的 class 文件。在 Sun 的 1.2 版本 SDK 中，Javac 编译器默认产生版本号为 45.3 的 class 文件。但如果在 javac 命令行中指定了 -target 1.2 标志，1.2 版本的编译器将产生版本号为 46.0 的 class 文件。1.0 或 1.1 版本的 JVM 上不能运行使用-target 1.2 标志所产生的 class 文件。

JVM 实现的 第二版中修改了对 class 文件主版本号和次版本号的解释。对于第二版而言，class 文件的主版本号与 Java 平台主发布版的版本号保持一致(例如：在 Java 2 平台发布版上，主版本号从 45 升至 46)，次版本号与特定主平台发布版的各个发布版相关。因此，尽管不同的 class 文件格式可以由不同的版本号表示，但版本号不一样并不代表 class 文件格式不同。版本号不同的原因可能只是因为 class 文件由不同发布版本的 java 平台产生，可能 class 文件的格式并没有改变。

上面三段节选自《深入 Java 虚拟机》，啰嗦一堆，JDK 1.2 开启了 Java 2 的时代，但那个年代仍然离我们很远，我们当中很多少直接跳在 JDK 1.4 上的，我也差不多，只是项目要求不得不在一段时间里委屈在 JDK 1.3 上。不过大致我们可以得到的信息就是每个版本的 JDK 编译器编译出的 class 文件中都带有一个版本号，不同的 JVM 能接受一个范围 class 版本号，超出范围则要出错。不过一般都是能向后兼容的，知道 Sun 在做 Solaris 的一句口号吗？保持对先前版本的 100% 二进制兼容性，这也是对客户的投资保护。

四：编译器比较及症节之所在

现在不妨从 JDK 1.1 到 JDK 1.7 编译器编译出的 class 的默认 minor.major version 吧。（又走到 Sun 的网站上翻腾出我从来都没用过的古董来）

JDK 编译器版本 target 参数 十六进制 minor.major 十进制 minor.major jdk1.1.8 不能带 target 参数 00 03 00 2D 45.3 jdk1.2.2 不带(默认为 -target 1.1) 00 03 00 2D 45.3 jdk1.2.2 -target 1.2 00 00 00 2E 46.0 jdk1.3.1_19 不带(默认为 -target 1.1) 00 03 00 2D 45.3 jdk1.3.1_19 -target 1.3 00 00 00 2F 47.0 j2sdk1.4.2_10 不带(默认为 -target 1.2) 00 00 00 2E 46.0 j2sdk1.4.2_10 -target 1.4 00 00 00 30 48.0 jdk1.5.0_11 不带(默认为 -target 1.5) 00 00 00 31 49.0 jdk1.5.0_11 -target 1.4 -source 1.4 00 00 00 30 48.0 jdk1.6.0_01 不带(默认为 -target 1.6) 00 00 00 32 50.0 jdk1.6.0_01 -target 1.5 00 00 00 31 49.0 jdk1.6.0_01 -target 1.4 -source 1.4 00 00 00 30 48.0 jdk1.7.0 不带(默认为 -target 1.6) 00 00 00 32 50.0 jdk1.7.0 -target 1.7 00 00 00 33 51.0 jdk1.7.0 -target 1.4 -source 1.4 00 00 00 30 48.0 Apache Harmony 5.0M3 不带(默认为 -target 1.2) 00 00 00 2E 46.0 Apache Harmony 5.0M3 -target 1.4 00 00 00 30 48.0
上面比较是 Windows 平台下的 JDK 编译器的情况，我们可以此作些总结：

1) -target 1.1 时 有次版本号，target 为 1.2 及以后都只用主版本号了，次版本号为 0
2) 从 1.1 到 1.4 语言差异比较小，所以 1.2 到 1.4 默认的 target 都不是自身相对应版本
3) 1.5 语法变动很大，所以直接默认 target 就是 1.5。也因为如此用 1.5 的 JDK 要生成目标为 1.4 的代码，光有 -target 1.4 不够，必须同时带上 -source 1.4，指定源码的兼容性，1.6/1.7 JDk 生成目标为 1.4 的代码也如此。
4) 1.6 编译器显得较为激进，默认参数就为 -target 1.6。因为 1.6 和 1.5 的语法无差异，所以用 -target 1.5 时无需跟着 -source 1.5。
5) 注意 1.7 编译的默认 target 为 1.6
6) 其他第三方的 JDK 生成的 Class 文件格式版本号同对应 Sun 版本 JDK
7) 最后一点最重要的，某个版本的 JVM 能接受 class 文件的最大主版本号不能超过对应 JDK 带相应 target 参数编译出来的 class 文件的版本号。

上面那句话有点长，一口气读过去不是很好理解，举个例子：1.4 的 JVM 能接受最大的 class 文件的主版本号不能超过用 1.4 JDK 带参数 -target 1.4 时编译出的 class 文件的主版本号，也就是 48。

因为 1.5 JDK 编译时默认 target 为 1.5，出来的字节码 major.minor version 是 49.0，所以 1.4 的 JVM 是无法接受的，只有抛出错误。

那么又为什么从 1.1 到 1.2、从 1.2 到 1.3 或者从 1.3 到 1.4 的 JDK 升级不会发生 Unsupported major.minor version 的错误呢，那是因为 1.2/1.3/1.4 都保持了很好的二进制兼容性，看看 1.2/1.3/1.4 的默认 target 分别为 1.1/1.1/1.2 就知道了，也就是默认情况下1.4 JDK 编译出的 class 文件在 JVM 1.2 下都能加载执行，何况于 JVM 1.3 呢？（当然要去除使用了新版本扩充的 API 的因素）

五：找到问题解决的方法

那么现在如果碰到这种问题该知道如何解决了吧，还会像我所见到有些兄弟那样，去找个 1.4 的 JDK 下载安装，然后用其重新编译所有的代码吗？其实大可不必如此费神，我们一定还记得 javac 还有个 -target 参数，对啦，可以继续使用 1.5 JDK，编译时带上参数 -target 1.4 -source 1.4 就 OK 啦，不过你一定要对哪些 API 是 1.5 JDK 加入进来的了如指掌，不能你的 class 文件拿到 JVM 1.4 下就会 method not found。目标 JVM 是 1.3 的话，编译选项就用 -target 1.3 -source 1.3 了。

相应的如果使用 ant ，它的 javac 任务也可对应的选择 target 和 source

<javac target="1.4" source="1.4" ............................/>

如果是在开发中，可以肯定的是现在真正算得上是 JAVA IDE 对于工程也都有编译选项设置目标代码的。例如 Eclipse 的项目属性中的 Java Compiler 设置，如图

自已设定编译选项，你会看到选择不同的 compiler compliance level 是，Generated class files compatibility 和 Source compatibility 也在变，你也可以手动调整那两项，手动设置后你就不用很在乎用的什么版本的编译器了，只要求他生成我们希望的字节码就行了，再引申一下就是即使源代码是用 VB 写的，只要能编译成 JVM 能执行的字节码都不打紧。在其他的 IDE 也能找到相应的设置对话框的。

其他时候，你一定要知道当前的 JVM 是什么版本，能接受的字节码主版本号是多少（可对照前面那个表）。获息当前 JVM 版本有两种途径：

第一：如果你是直接用 java 命令在控制台执行程序，可以用 java -version 查看当前的 JVM 版本，然后确定能接受的 class 文件版本

第二：如果是在容器中执行，而不能明确知道会使用哪个 JVM，那么可以在容器中执行的程序中加入代码System.getProperty("java.runtime.version"); 或 System.getProperty("java.class.version")，获得 JVM 版本和能接受的 class 的版本号。

最后一绝招，如果你不想针对低版本的 JVM 用 target 参数重新编译所有代码；如果你仍然想继续在代码中用新的 API 的话；更有甚者，你还用了 JDK 1.5 的新特性，譬如泛型、自动拆装箱、枚举等的话，那你用 -target 1.4 -source 1.4 就没法编译通过，不得不重新整理代码。那么告诉你最后一招，不需要再从源代码着手，直接转换你所正常编译出的字节码，继续享用那些新的特性，新的 API，那就是：请参考之前的一篇日志：Retrotranslator让你用JDK1.5的特性写出的代码能在JVM1.4中运行，我就是这么用的，做好测试就不会有问题的。

六：再议一个实际发生的相关问题

这是一个因为拷贝 Tomcat 而产生的 Unsupported major.minor version 49.0 错误。情景是：我本地安装的是 JDK 1.5，然后在网上找了一个 EXE 的 Tomcat 安装文件安装了并且可用。后来同事要一个 Tomcat，不想下载或安装，于是根据我以往的经验是把我的 Tomcat 整个目录拷给他应该就行了，结果是拿到他那里浏览 jsp 文件都出现 Unsupported major.minor version 49.0 错误，可以确定的是他安装的是 1.4 的 JDK，但我还是有些纳闷，先前对这个问题还颇有信心的我傻眼了。惯性思维是编译好的 class 文件拿到低版本的 JVM 会出现如是异常，可现并没有用已 JDK 1.5 编译好的类要执行啊。

后来仔细看异常信息，终于发现了 %TOMCAT_HOME%\common\lib\tools.jar 这一眉目，因为 jsp 文件需要依赖它来编译，打来这个 tools.jar 中的一个 class 文件来看看，49.0，很快我就明白原来这个文件是在我的机器上安装 Tomcat 时由 Tomcat 安装程序从 %JDK1.5%\lib 目录拷到 Tomcat 的 lib 目录去的，造成在同事机器上编译 JSP 时是 1.4 的 JVM 配搭着 49.0 的 tools.jar，那能不出错，于是找来 1.4 JDK 的 tools.jar 替换了 Tomcat 的就 OK 啦。

⑵ Java11的新功能有哪些

Java 11 JDK中已计划的新功能
目前来看，JDK 11已有九个已经确认的新功能，而且还有更多新功能仍在考虑之中。计划的新功能包括：
HTTP客户端（标准），这个功能于JDK 9中引入并在JDK 10中得到了更新，现在终于转正了。该API通过CompleteableFutures提供非阻塞请求和响应语义，可以联合使用以触发相应的动作。自从JDK 9和10中引入该功能后，JDK 11完全重写了该功能，现在其实现完全是异步的。RX Flow的概念也得到了实现，这样就无需为了支持HTTP/2而创造许多概念了。现在，在用户层请求发布者和响应发布者与底层套接字之间追踪数据流更容易了。这降低了复杂性，并最大程度上提高了HTTP/1和HTTP/2之间的重用的可能性。Epsilon垃圾回收器，被称为“no-op”回收器，它仅负责内存分配，却没有实现任何实际的内存回收机制。Epsilon回收器可以用于性能测试、内存压力测试和虚拟机接口。它还可以用于短生命周期的任务。lambda参数的局部变量语法，可以消除隐含类型表达式中正式参数定义的语法与局部变量定义语法的不一致。这样就能在隐含类型的lambda表达式中定义正式参数时使用var了。Java的类文件格式将被扩展，以支持新的常量池，CONSTANT_Dynamic。其目标是降低开发新形式的可实现类文件约束带来的成本和干扰。采用Curve25519和Curve448加密的密钥交换比现有的Diffie-Hellman椭圆曲线密钥交换方式更有效、更安全。根据IETF的资料，Curve25519和Curve448两种椭圆曲线采用常量时间的实现方式，以及不会发生异常的数乘实现，能更好地抵抗各种旁路攻击，包括时序攻击、缓存攻击等。该提案的目标是为密钥交换方法提供一个API和实现，同时开发一个平台无关、纯Java的的实现。由于该提案采用了复杂且精密的模算数，因此还是有风险的。飞行记录仪（Flight Recorder）将提供低开销的数据收集框架，用来调试Java应用程序和HotSpot JVM。飞行记录仪是Oracle的商业版JDK的功能，但在JDK 11中，其代码将移动到公开代码库中，这样所有人都能使用该功能了。Iclouded将作为API，以事件的形式产生或消耗数据，同时提供缓存机制、二进制数据工具，同时支持配置和事件过滤。该提案还提议为OS、HotSpot和JDK库提供事件。更新platform API以支持Unicode版本10.0，从而使Java跟上潮流。预计以下的类将支持：lang包中的Character和Stringawt.font包中的NumericShapertext包中的Bidi、BreakIterator和Normalizer实现ChaCha20和Poly1305加密算法。ChaCha20是种相对较新的流加密算法，能代替旧的、不安全的R4流加密。ChaCha20将与Poly1305认证算法配对使用。ChaCha20和ChaCha20-Poly1305加密实现将通过crypto.CipherSpi API于SunJCE（Java加密扩展）中提供。增强Java启动器，使之能够运行单一文件的Java源代码，使得应用程序可以直接从源代码运行。单文件程序常见于小型工具，或开发者初学Java时使用。而且，单一源代码文件有可能会编译成多个类文件，这会增加打包开销。由于这些原因，在运行程序之前进行编译，已成为了不必要的步骤。Java JDK 11仍在开发中的新功能
Java 11的创建者们还在考虑几个对JDK 11的变更或新功能的提案：
给Java添加raw字符串字面值。这样可以更容易地以人类可阅读的形式书写字符序列，而无需特殊的Java标记。这样也能更容易地将非Java语法的字符串提供给Java使用，还能支持多行字符串，而无需使用特殊的标记。扩展switch语句，使之能作为语句或表达式使用。这样还能改进switch处理null值的方式。这些改动可以简化编程，同时为switch支持模式匹配做准备。嵌套的访问控制，对应于Java当前的嵌套类型。嵌套可以让逻辑上属于同一代码实体但被编译到不同的类文件中的类互相访问对方的私有成员，而无需让编译器插入扩大访问权限的方法。JDK 11删除的功能
Java EE和CORBA模块从Java SE9就成了不推荐使用（deprecated），并计划在未来的版本中删除。这个未来版本就是JDK 11。
Java SE 6于2006年12越发布，它为Java EE平台提供了整套的Web服务技术栈：JAX-WS（Java API for XML-based Web Services），JAXB（Java Architecture for XML Binding），JAF（JavaBeans Activation Framework），以及Common Annotations for Java。这些年来，Java EE版本在不断进化，这给Java SE造成了许多麻烦，例如加入与Java SE无关的技术，以及同时维护两个Java版本的困难变得更大。由于独立的Java EE版本由第三方网站提供，Oracle说Java SE或JDK中已经没有必要提供Java EE了。
当然，一些依赖于JDK中的Java EE API及工具的应用程序将无法编译或运行。将JDK 6、7或8移植到新版本时将会产生二进制不兼容和源代码不兼容。Oracle说，受到这些影响的开发者可以部署相应的Java EE版本。
CORBA来自于二十世纪九十年代，Oracle说，现在用CORBA开发现代Java应用程序已经没有意义了，维护CORBA的成本已经超过了保留它带来的好处。
但是删除CORBA将使得那些依赖于JDK提供部分CORBA API的CORBA实现无法运行。目前还没有第三方CORBA版本，也不确定是否会有第三方愿意接手CORBA API的维护工作。
JavaFX已经被移除，因此已经与Java JDK每年两次的更新无关。

⑶ 我的电脑安装jdk11版本显示不兼容，但是我们老师要求我们使用最新版的，怎么办

你这是因为运行环境的JDK和编译环境的JDK版本不同造成的，在低运行版本的环境下运行高编译版本的内容一般就会报这个问题。

⑷ JAVA的JDK最新版本是多少的

目前测试版本为jdk12,稳定版本为jdk11，但是用的最多还是jdk8

⑸ java的JDK更新到什么版本了

Standard Edition（标准版）的最新版：jdk 14。

Early-Access（先行版）的最新版：jdk15。

LTS（长期支持版）的最新版：jdk 11.0.6。

JRE（Java Runtime Environment，Java运行时环境），包含了java虚拟机、java基础类库。是使用java语言编写的程序运行所需要的软件环境。

它相当于操作系统部分，提供了Java程序运行时所需要的基本条件和许多Java基础类，例如，IO类、GUI控件类、网络类等。JRE是提供给普通用户使用的，如果你只想运行别人开发好的Java程序，那么，你的计算机上必须且只需安装JRE。

JDK（Java Development Kit，Java开发工具包），它包含编译工具、解释工具、文档制作工具、打包工具多种与开发相关的工具，是提供给Java开发人员使用的。JDK包含了JRE，同时还包含了编译java源码的编译器javac，还包含了很多java程序调试和分析的工具：jconsole，jvisualvm等工具软件，还包含了java程序编写所需的文档和demo例子程序。

⑹ 为何我的jdk版本是jdk 11却用不了var语法，IDEA中使用var推断类型报错

哈哈，Java里用的不是var语法啊，var语法一般是出现在JS等语言里的
Java中定义对象：
类名 对象名 = 值;

例如：Integer num = new Integer(100);
Javascript（ECMAScript）中定义对象：
var 对象名 = 值;
例如：var arr = new Array(100);

⑺ class编译默认用jdk11

方法如下：
1、在系统变量中，添加【JAVA_HOME】，路径选择jdk安装路径。
2、在用户变量中，配置PATH。
变量值填写JDK的安装目录下的bin目录，因“JAVA_HOME”已配置好，所以可通过JAVA_HOME变量来设置，这样比较灵活，下次要变更JDK的话，只需修改JAVA_HOME即可 。
3、配置CLASS_PATH。
变量值填写JDK相关的jar包，也是通过JAVA_HOME变量来设置，可直接写%JAVA_HOME%libdt.jar;%JAVA_HOME%lib ools.jar，然后连续【确定】