获取一直FullGC下的java进程HeapDump的小技巧

作者:@善良的右席

小技巧

我们应用的java进程出问题的时候,我们往往会用jmap或者gcore拿到一份HeapDump,拿到MAT上做一次Heap分析,但是 如果你排查的是一直在FullGC的gc问题,你Dump下来的堆往往是正处于FullGC中,可能会导致分析失败。@坤谷 发现了一个小技巧,可以dump下完整而且没有在被移动中的Heap。

操作流程

  • 找到java进程,gdb attach上去, 例如 gdb java -p 22443
  • 找到这个HeapDumpBeforeFullGC的地址(这个flag如果为true,会在FullGC之前做HeapDump,默认是false)
    (gdb) p &HeapDumpBeforeFullGC
    $2 = (<data variable, no debug info> *) 0x7f7d50fc660f <HeapDumpBeforeFullGC>
    
  • 然后把他设置为true,这样下次FGC之前就会生成一份core文件
    (gdb) set *0x7f7d50fc660f = 1
    (gdb) quit
    
  • 最后,等一会,等下次FullGC触发,你就有HeapDump了!

(PS. jstat -gcutil pid 可以查看gc的概况)

 

注意事项,设完,观察heapdump生成路径和磁盘,别生成太多,让磁盘满了,heapdump出来后,及时kill掉应用。

 

Q&A
Q1:把HeapDumpAfterFullGC也设上是不是会更快点儿?
A1:那就是被fullgc完之后的堆了,会不会堆里有些业务垃圾会有助于分析嘛。。

Q2: HeapDumpBeforeFullGC 可以用JCMD改的吧, 我看是manageable 属性
A2: 是的,如果jcmd,jinfo能改,就先用工具。这里是所有别的工具都失败的情况下的办法。一直fullgc的时候jinfo会不生效吧

Q3: jmx,mxbean能直接动态改的,比如去Jconsole里setVmOption,直接将HeapDumpBeforeFullGC和HeapDumpAfterFullGC设置成true,也比较方便的A3: 嗯嗯是的,但是这类方法缺点就是如果应用一直无限fullgc,会导致修改不成功

Q4: 一直fgc,用jmap -histo,我觉得就基本上能看出蛛丝马迹了
A4: 不错。其实很多时候还不需要heapdump,taobao-jdk6/ali-jdk8/ajdk8的大数组警告,直接能看出问题。

Q5: jmap -F 不行吗
A5: 那个时候dump下来的堆,可能正处于gc中,会解析失败

Q6: 文章中不是说等下次full gc吗?既然等到下一次full gc,我觉得jmap -F能dump出文件吧?或者直接设置jvm -XX:+UseHeapDumpBeforeFullGC应该也可以吧?不知道说的对不对
A6: jmap -F的原理和gcore差不多,强行dump出内存,这个时候如果正在gc中,那么内存中对象的引用关系可能是乱的。XX:+UseHeapDumpBeforeFullGC这个flag,线上应用肯定是不会开的。上面的方法就是强制打开这个flag

GreenTeaJUG活动 第22期 JDK9新特性讨论

时间:2016-04-05
地点:网络
组织:@JianhaoMo

甲骨文希望听到中国Java社区关于JDK9的反馈,欢迎任何形式的反馈。

The attachment is the JDK9 new features introduction, could you help to forward it to China Java User Groups? JDK9 first introduces Jigsaw feature, it causes big changes in JDK structure and APIs, we would contact China Java User Group to collect their questions. Could you help to copy me when you send this presentation to the user groups?



This Is Not A Drill
Prepare For JDK 9

Rory O‘Donnell
Senior Quality Manager OpenJDK Quality Lead
Java Platform Group @ Oracle March 19th, 2016

Prepare for JDK 9

Categories of JDK-internal APIs
http://openjdk.java.net/jeps/260
• Non-critical
– No evidence of use outside of JDK
– or used only for convenience
• Critical
– Functionality that would be difficult, if not impossible, to implement outside of the JDK

JEP 260 Proposal
http://openjdk.java.net/jeps/260
• Encapsulate all non-critical internal APIs by default
• Encapsulate all critical internal APIs for which supported replacements exist in JDK 8
• Do not encapsulate critical internal APIs
– Deprecate them in JDK 9
– Plan to remove in JDK 10
– Provide a workaround via command-line flag

JEP 260 Proposal
http://openjdk.java.net/jeps/260
• Propose as critical internal APIs – sun.misc.Unsafe
– sun.misc.{Signal,SignalHandler}
– sun.misc.Cleaner
– sun.reflect.Reflection::getCallerClass
– sun.reflect.ReflecWonFactory

Finding uses of JDK-internal APIs
http://openjdk.java.net/jeps/260
• jdeps tool in JDK 8, improved in JDK 9 • Maven JDeps Plugin

Removed 6 deprecated methods
http://openjdk.java.net/jeps/162
• Flagged for removal in JSR 337, and JEP 162
• Removed
– java.util.logging.LogManager::addPropertyChangeListener
– java.util.logging.LogManager::removePropertyChangeListener
– java.util.jar.Pack200.Packer::addPropertyChangeListener
– java.util.jar.Pack200.Packer::removePropertyChangeListener
– java.util.jar.Pack200.Unpacker::addPropertyChangeListener
– java.util.jar.Pack200.Unpacker::removePropertyChangeListener

Change the binary structure of the JRE and JDK
http://openjdk.java.net/jeps/220
• Motivation
• Not an API but still a disruptive change
• Details in JEP 220
• In JDK 9 since late 2014 to give lots of time for the tools to catch up

Removed
http://openjdk.java.net/jeps/220
• Endorsed standards override mechanism
• Extension mechanism

Other changes
http://openjdk.java.net/jeps/261
• Application and extension class loaders are no longer instances of java.net.URLClassLoader
• Removed: -Xbootclasspath and -Xbootclasspath/p are removed
• Removed: system property sun.boot.class.path
• JEP 261 has the full list of the issues that we know about

New version-string scheme
http://openjdk.java.net/jeps/223
• Old versioning format is difficult to understand
• New format addresses these problems
• Impacts java -version and related properties

What can you do to prepare?
https://wiki.openjdk.java.net/display/AdopKon/JDK+9+Outreach
• Check code for usages of JDK-internal APIs with jdeps
• If you develop tools then check code for a dependency on rt.jar or tools.jar or the runtime-image layout
• Check code that might be sensitive to the version change
• Check code for uses of underscore as an identifier
• Check code for uses of unrecognized VM opWons such as -XX:MaxPermSize
• Test the JDK 9 EA builds and Project Jigsaw EA builds

Thank you!
Quality Outreach effort wiki:
https://wiki.openjdk.java.net/display/quality/Quality+Outreach





[翻译]JDK 8 兼容性指南

翻译官方文档,译者精力有限,忽略部分划删除线。

译者:坤谷(@JianhaoMo),井桐(@张同宝),激酶

 

兼容性是一个复杂的问题。 本文介绍了Java平台潜在的三种不兼容问题:

  • 源码: 源码兼容性问题关注Java源代码转换成class文件是否兼容,包括代码是否仍然可编译。
  • 二进制: 在Java语言规范中,二进制兼容性定义为:“类的改变是二进制兼容的(或者不破坏二进制兼容性),是指如果改变前的类的二进制在链接时没有错误,那么改变后的类在链接时仍然没有错误。”
  • 行为 : 行为兼容性包括在运行时执行的代码的语义。 欲了解更多信息,请参阅OpenJDK的开发人员指南 中,兼容性的种类一节。 下面的兼容性文档跟踪相邻的Java版本之间的不兼容。 例如,这个兼容性文档只报告的Java SE 8和Java SE 7的不兼容,而不是以前的版本。 要检查的Java SE 8与早期的Java版本的不兼容性,必须按顺序跟踪一下不兼容性温的。 Java SE 7和JDK 7的兼容性 JDK 6兼容性 J2SE 5.0不兼容问题(自1.4.2)

二进制兼容性

除了下面列出的不兼容问题,Java SE 8与Java SE 7是二进制兼容的。 除了提到的不兼容,Java SE 7编译的类文件将在Java SE8正常运行。而Java SE 8编译的类文件将无法在早期版本的Java SE运行。

源码兼容性

Java SE 8包括新的语言功能和平台的API。这些都在源文件中使用,这些源文件不能在早期版本的Java平台中编译。
一般情况下,源码兼容性策略是避免引入的源代码不兼容问题。 然而,实现Java SE 8的功能所需的更改可能导致代码无法在Java SE的7编译。见Java SE 8和Java SE 7之间的不兼容性和JDK 8和JDK 7之间的不兼容性。
Deprecated API仅用于与早期版本的兼容性支持。除非打开-nowarn命令行选项,只要使用了Deprecated API,javac编译器就会生成警告信息。 建议应用进行修改,以杜绝使用Deprecated API。
sun.*包的 一些API在发生了变化。 这些API不供开发人员使用。 开发人员导入sun.*包,需要自己承担风险。 欲了解更多详细信息,请参阅为什么开发人员不应该编写调用‘sun’包的程序
对于Deprecated API列表,请参阅Deprecated API。

行为兼容性

简而言之,行为兼容性意味着在输入相同时,程序在不同版本的库或平台执行相同(或等同)的操作。 有些平台行为的底层实现是故意设定为未定义的,这样平台发布可以更改。 出于这个原因,建议写代码不依赖于未定义的行为:如果依赖了未定义行为,问题不能算平台不兼容,而是算代码的bug。

Java类文件

Java类文件格式已经更新为Java SE 8版本。
按照JVM规范,Java SE 8的类文件版本是52.0。 由Java SE 8编译器产生的版本为52.0的类文件不能在早期版本Java SE中使用。
下面的文档有Java语言规范(JLS)和Java虚拟机规范(JVMS)的更改信息。

Java SE 8和Java SE 7之间的不兼容性

尽管Java SE 8是与Java平台的早期版本是非常兼容的, 几乎所有现有的程序可以不加修改地运行在Java SE 8,不过JRE和JDK也有一些小的潜在的不兼容性。为了完整性,这里记录极少数情况下“极端案例”。
本节介绍了Java语言的JVM或Java SE API的Java SE 8不兼容。
请注意,此版本中一些API已弃用,有些功能已被完全删除。 虽然这些都是不兼容,他们被列为在单独的列表。 欲了解更多信息,请参阅Deprecated APIs和JDK 8移除的功能。
2015年3月Java SE 8进行了版本维护,不兼容的问题有相应的修改。

  • JVM:接口默认方法不能触发接口立即初始化

    不兼容性: 行为
    Bug:8043188
    (译者注:8u40已修复)
  • JVM:JDWP支持接口默认方法和静态方法

    不兼容性: 行为
    RFE:8042123
    (译者注:8u40已修复)
  • JVM:对invokespecial指令调用实例初始化方法的校验更加严格
    (译者注:只有当前类型或直接超类的实例允许调用)
    不兼容性: 行为
    REF: 7160765 (译者注:可能是安全相关,无法看到更详细内容)
  • JVM:默认每个类文件中都设置了ACC_SUPER标志
    Java SE 8以及以上,Java虚拟机默认每个类文件中都设置了ACC_SUPER标志,无论标志在类文件的实际值和类文件的版本的。 该ACC_SUPER标志影响invokespecial的行为。
    不兼容性: 行为(译者注:可能是安全相关,无法看到更详细内容)
  • JAVA:classes_text支持小语种
    当使用DateFormat和SimpleDateFormat来格式化日期时间值时 ,上下文有关的月份名称支持既有格式化形式又有独立形式的小语种。 例如,在捷克语中,一月的格式化形式是ledna,而独立形式是leden。 DateFormatSymbols的getMonthNames方法和getShortMonthNames方法返回这些语言的月份格式化形式。请注意,直到的Java SE 7,DateFormatSymbols都是返回独立的形式。您可以用Calendar.getDisplayName方法和Calendar.getDisplayNames方法来制定返回哪种形式。 请参考API文档。
    不兼容性: 行为
    RFE:7079560
  • 核心库:javax.lang.model引入IntersectionType
    在Java SE 8,对于具有multiple bounds的TypeVariables ,javax.lang.model.type.TypeVariable.getUpperBound的返回值和早期版本的返回值不同。现在返回新引入IntersectionType的实例,而原来返回DeclaredType的实例。 这可能会导致javax.lang.model.util.TypeVisitor现有的实现行为改变:之前TypeVariable.getUpperBound返回multiple bounds变量时调用visitDeclared方法,现在调用visitIntersection方法。 对返回值调用getKind()也能观察到差别。
    不兼容性: 行为
    RFE: 6557966
  • 核心库:non-public java.lang.reflect.Proxy
    实现了non-public interface的java.lang.reflect.Proxy将是non-public, final, 且非abstract的。 在Java SE 8之前,代理类是public, final, 且非abstract。

    • 如果现有的代码不在同一个运行时package里面调用Proxy.getProxyClass和Constructor.newInstance方法来创建一个代理实例,它会失败,并抛IllegalAccessException。 对于这样的代码,它需要更改源码为:(1)调用Constructor.setAccessible设置访问标志设置为true,或(2)使用方便的Proxy.newProxyInstance方法。
    • 如果现有代码试图创建其他运行时package的non-public接口代理,需要授权新的permissionReflectPermission("newProxyInPackage.{package name}")不兼容性: 源码
  • 核心库:java.lang.reflect.Proxy不允许空InvocationHandler
    如果给定的InvocationHandler参数为空,java.lang.reflect.Proxy(InvocationHandler h)构造函数现在抛NullPointerException。
    现有代码使用空参数构造动态代理实例将抛NullPointerException。 这种用法估计很罕见,因为空代理实例无论用在何处都将抛NullPointerException。
    不兼容性: 行为
    RFE: 4487672
  • 核心库:java.math的BigDecimal.stripTrailingZeros的零值问题
    Java SE 8之前,如果调用BigDecimal.stripTrailingZeros的数值等于零,将返回该值。 现在则返回常量BigDecimal.ZERO
    不兼容性质: 行为
    RFE: 6480539
  • 核心库:java.net的HttpURLConnection响应头引号问题
    在以前的版本中HttpURLConnection摘要身份验证实现有误,在WWW-Authenticate响应头中对一些值加了引号。 在Java SE 8版本中,这些值不再加引号。 这是严格遵循RFC 2617 HTTP Authentication: Basic and Digest Access Authentication
    一些服务器实现的某些版本已知预期这些值被引用。 HTTP请求到这些服务器可能无法再成功进行身份验证。 而以前由于这些值被加引号而失败的身份验证,可能现在能成功验证。
    不兼容性: 行为
    RFE: 8010505
  • 核心库:java.net的socket非临时端口安全问题
    在此版本中,分配给包括不​​可信代码的所有代码默认socket权限已被更改。 以前,所有代码能够bind任何类型的socket,以及任何大于或等于1024的端口号。此版本仍可以bind socket到每个系统上的临时端口范围。 临时端口的确切范围因操作系统而不同,但通常在高范围(如从49152到65535)。新的限制是bind socket到临时端口范围之外需要显式系统安全策略授权。绝大多数使用客户端TCP socket(开启了SecurityManager)的应用将不会看到任何问题,因为这些通常bind到临时端口。 而使用datagram socket或服务端tcp socket(开启了SecurityManager)应用可能抛安全异常。之前版本不会。 如果发生这种情况,使用者应该检查被请求的端口号是否符合预期。如果符合预期,添加一个socket授权到本地安全策略来解决此问题。
    不兼容性: 行为
  • 核心库:java.net的DatagramPacket构造函数不再声明异常
    在Java SE 8之前,带java.net.SocketAddress参数的java.net.DatagramPacket构造函数,声明抛出java.net.SocketException。 然而,这个异常永远不会被抛出。 在Java SE 8版本中,该构造函数不再声明抛出java.net.SocketException。 如果的代码catch了SocketException或它的超类java.io.IOException ,在使用与Java SE 8编译之前删除这些catch块。
    不兼容性: 源码
    RFE: 8022126
  • 核心库:java.util.i18n的LocaleServiceProvider判断Locale问题
    选择LocaleServiceProvider的机制已经改变。LocaleServiceProvider的实现现在能够通过overideLocaleServiceProvider.isSupportedLocale方法来确定Locale是否支持。 然而,如果从JDK7迁移locale service providers, overide此方法对于严格的扩展检查可能涉及与现有应用程序的一些兼容性问题。参考LocaleServiceProvider类及其isSupportedLocale方法的描述了解更多细节。
    不兼容性: 行为
    RFE: 7168528
  • 客户端库:java.awt

    不兼容性: 行为
    RFE: 7146237
  • 安全库:javax.net.ssl拒绝客户端初始化的renegotiation
    Oracle JSSE provider的新sytem propertyjdk.tls.rejectClientInitializedRenego拒绝客户端初始化的renegotiation 。如果这个sytem property为true。服务端拒绝客户端renegotiation的请求,并且抛出handshake_failure警报。
    不兼容性: 行为
    RFE: 7188658
  • Hotspot JVM:gc删除Perm
    删除并忽略命令行选项 PermSize和MaxPermSize。 如果使用了这两个选项,会发出如下警告:

    Java HotSpot(TM) Server VM warning: ignoring option PermSize=32m; support was removed in 8.0
    Java HotSpot(TM) Server VM warning: ignoring option MaxPermSize=128m; support was removed in 8.0
    

    不兼容性: 源码
    RFE: 6965548

JDK 8与JDK 7之间的不兼容性

本段描述JDK 8在javac、HotSpot或Java SE API中与JDK 7不兼容之处。
需要注意的是,部分API在本次发布中已经标注为不建议使用,甚至部分特性已经被完全移除。这些不兼容的地方在这里单独列出来。如果需要更多的信息,参看Deprecated APIs和JDK 8移除的功能。

  • JVM:JDI中接口支持默认方法和静态方法
    Java SE 8语言规范为接口引入了静态方法和默认方法,因此JDI规范和具体实现中都已经允许使用这个技术。在JDI中,com.sun.jdi.InterfaceType类包含了方法Value invokeMethod(ThreadReference thread, Method method, List<? extends Value> arguments, int options)
    不兼容性: 行为
    RFE: 8042123
    (译者注:8u40已修复)
  • 核心库:java.lang的windows中检测登录用户home目录
    在windows中检测登录用户home目录的步骤,更新为遵照微软推荐的方法。这处改动对在如下两类情况下可能需要重点关注:1.比较旧的windows版本;2.用户home目录在注册表或环境变量中设置到其他的目录下。
    不兼容性: 行为
    RFE: 6519127
  • 核心库:java.lang.reflect的getMethods调用结果
    新特性默认方法会影响两个方法Class.getMethod、Class.getMethods的调用结果。
    Class.getMethod、Class.getMethods的javadoc继承了Java语言规范的定义。Java SE 8改变了这个规则,以便支持默认方法的同时削减继承于超接口的冗余方法(可参考JLS 8, 8.4.8)的数量。比如说,一个类有两个超接口:I和J,每一个都定义了int length();,一般来说,我们认为两个方法都是这个类的成员,但是如果J同样扩展于I,那么在Java SE 8中,这个类仅集成了一个方法:J.length()
    在Java SE 8发布的时候,Class.getMethod和Class.getMethods的实现并没有随定义的更新而更新(两个方法都会返回非继承的超接口的方法)。从兼容性看,这个区别没那么重要了,而与Java SE 7返回的一致性则是优先考虑的。因此无论如何,当重写方法(如上面提到的J.length)为默认方法,首先应该要过滤掉其他重写的方法(如上面提到的I.length)。
    从JDK 8u20开始,代码实现改为在重写默认方法时,增加上面提到的过滤的步骤。
    不兼容性: 行为
    RFE: 8029674
  • 核心库:java.text舍入行为问题
    在之前版本中,当使用NumberFormatDecimalFormat类时,在特殊情况下是会发生舍入行为的错误。这种错误行为一般发生在调用format()方法时,给的值非常接近于格式化字符串所定义的中间位置。在这种情况下,错误的双精度值舍入或不舍入行为就会发生。
    举例说,当使用默认推荐的NumberFormatFormatAPI:NumberFormat nf = java.text.NumberFormat.getInstance(),跟着格式化代码nf.format(0.8055d),0.8055d值在计算机无法精确地表示为一个二进制的值,而是0.80549999999999999378275106209912337362766265869140625。在这里默认的舍入是“half-even”法(译者注:此舍入模式也称为“银行家舍入法”,主要在美国使用。四舍六入,五分两种情况,如果前一位为奇数,则入位,否则舍去),JDK 7中调用format()方法会错误的输出0.806,然而正确的值应该是0.805,因为内存中记录的值是小于中间位置的。
    在所有可能由程序员自定义样式(而不是默认的样式)的位置里,这个舍入行为被修正。
    不兼容性: 行为
    RFE: 7131459
  • 核心库:java.util.collections的removeAll,retainAll不接受null
    在之前的版本中,一些Collection.removeAll(Collection)retainAll(Collection)的实现会静默的忽略传入null参数的情况。从这个版本开始,如果集合传入一个null参数,将会抛出一个NullPointerException
    不兼容性: 行为
    RFE: 8021591
  • 核心服务:java.management强制管理接口public
    在规范中提到的管理接口需要是puclic的,在这个版本中变成强制的了。非public的接口不存续暴露管理功能,所有的MBean和MXBean接口必须是public的。
    系统属性jdk.jmx.mbeans.allowNonPublic用于恢复成之前允许非public管理接口的行为。这个属性是过渡期使用的,在后续的发布版中将会被移除。
    不兼容性: 行为
  • 客户端库:java.awt
    java.awt.Component.setFocusTraversalKeys()方法中,如果参数keystrokes里的任何对象不是AWTKeyStroke的话,会抛出ClassCastException(之前是IllegalArgumentException)。
    不兼容性: 行为
  • 安全库:java.security限制com.sun.media.sound
    com.sun.media.sound添加到了JDK 8受限制包列表中。在SecurityManager下运行的应用无法访问这个包及其下各层级,除非得到明确的授权。com.sun.media.sound包一个内部的、不受支持的包,这相当于是说这不应该被外部的应用所使用。
    不兼容性: 源码
    RFE: 8019830
  • 其他库:corba限制se及其子包
    JDK内部包com.sun.corba.se及其子包已被添加到受限包列表中,运行SecurityManager情况下无法直接访问。
    不兼容性: 行为
    RFE: 8021257
  • 工具:javac改正二进制比较的类型规则
    Java语言规范(JLS)的15.21章节中关于二进制比较的类型规则没有正确的被javac实施。从JDK 5 版本开始,javac根据JLS规范15.21章节接受了一些类型不正确的对象-原生类型比较的程序。这些比较现在会被认为是类型错误。
    不兼容性: 行为
    RFE: 8013357
  • 工具:javac参数和方法的注解拷贝到合成桥接方法
    在这一次发布中,参数和方法的注解将会拷贝到合成桥接方法。这个修复意味着现在程序类似:

    @Target(value = {ElementType.PARAMETER})
    @Retention(RetentionPolicy.RUNTIME)
    @interface ParamAnnotation {}
    
    @Target(value = {ElementType.METHOD})
    @Retention(RetentionPolicy.RUNTIME)
    @interface MethodAnnotation {}
    
    abstract class T<A,B> {
        B m(A a){return null;}
    }
    
    class CovariantReturnType extends T<Integer, Integer> {
        @MethodAnnotation
        Integer m(@ParamAnnotation Integer i) {
            return i;
        }
    
        public class VisibilityChange extends CovariantReturnType {}
    }
    

    每一个生成的桥接方法拥有所有的注解,参数注解也将会复制。这种行为上的改变将会影响一些注解处理器或任何使用注解的普通的程序。
    不兼容性: 行为
    RFE: 6695379

  • 工具:javac参数注解会拷贝到自动生成的内部类构造器
    参数注解会拷贝到自动生成的内部类构造器中。这个修复意味着现在如下的程序:

    @Target(value = {ElementType.PARAMETER})
    @interface ParamAnnotation {}
    
    public class initParams {
      public initParams(@ParamAnnotation int i) {}
    
      public void m() {
         new initParams(2) {};
      }
    }
    

    方法m()里,内部类生成的构造器中,参数int i会有一个注解@ParamAnnotation。这个行为的变化可能影响一些注解处理器,或者使用了注解的应用程序。
    不兼容性:
    行为

  • 工具:javac不再识别编译目标值1.4.1、1.4.2和jsr14
    javac不再识别编译目标值1.4.11.4.2jsr14,这些之前就没有记录在文档中。很多最新的代码生成惯用语中1.4.11.4.21.4使用的更多,而组合选项-source 1.4 -target 1.5会在更新一些的惯用语中使用,同时也会输出更新一些的字节码文件格式。“jsr14”选项则是泛型被添加到平台后的一个过度选项,现在泛型编译目标应该是1.5或更高。
    不兼容性: 行为
    RFE: 8010179
  • 工具:javac类型转换编译问题
    下面的代码在JDK 7中编译会出现警告,而在JDK 8中将无法编译:

    import java.util.List;
    
    class SampleClass {
    
        static class Baz<T> {
            public static List<Baz<Object>> sampleMethod(Baz<Object> param) {
                return null;
            }
        }
    
        private static void bar(Baz arg) {
            Baz element = Baz.sampleMethod(arg).get(0);
        }
    }
    

    JDK 8编译上面的代码中会报如下错误:

    SampleClass.java:12: error:incompatible types: Object cannot be converted to Baz
        Baz element = Baz.sampleMethod(arg).get(0);
    
        Note: SampleClass.java uses unchecked or unsafe operations.
    Note: Recompile with -Xlint:unchecked for details.
    1 error
    

    在这个例子中,原始类型被传递到sampleMethod(Baz<Object>)方法中,而这个方法应该传递的是其子类型(参考JLS,Java SE 7 Edition, 15.12.2.2章节)。如果要可用的话,就需要一个未经检查的转换,而他的返回类型是被擦除的(参考JLS,Java SE 7 Edition, 15.12.2.6章节)。在这个例子中,sampleMethod(Baz<Object>)的返回类型是java.util.List,而不是java.util.List<Baz<Object>>,因此get(int)的返回值是Object,这就和被赋值的Baz类型不一致了。
    更多的信息,请参见java.net上相关的电子邮件交流。
    不兼容性: 源码
    RFE: 7144506

  • 工具:javac的final字段明确赋值问题
    使用this关键字为final字段明确的赋值分析。
    传统的,Java语言禁止通过简单的名字(比如“x”)来访问没有明确赋值的final字段。在Java SE 7里,字段是可以通过“this.x”进行访问的(参见: https://bugs.openjdk.java.net/browse/JDK-7004835)。任何合法的程序在旧的规则下是非法的,而在新的规则下是不安全的,因为他必然会访问一个没有明确赋值的空白的final字段。
    从JDK 8u20开始,javac编译器已经更新实现了Java SE 7的规则。
    不兼容性: 源码
    Bug: 8039026
    (译者注8u20已修复)
  • 工具:javac接口的实现进行编译时接口需要存在
    当编译一个类,这个类中使用到的其中一个类实现了一个接口,而这个接口定义在别的文件中,这种类文件(定义接口的文件)在javac编译时必须可用。这是JDK 8的一个新的需求,不这样做会导致一个编译错误。例如:
    Client.java:

    import p1.A;
    
    class Client {
       void test() {
           new A.m();
       }
    }
    

    p1/A.java:

    package p1;
    
    public class A implements I {
       public void m() { }
    }
    

    p1/I.java:

    package p1;
    
    public interface I {
       void m();
    }
    

    如果p1/I.java或p1/I.class在编译Client.java时不可用,就会出现下面的错误信息:

    Client.java: error: cannot access I
           new A().m();
                ^
      class file for p1.I not found
    

    不兼容性: 行为

  • XML:JAXP的Xalan扩展功能安全问题
    JAXP中的Xalan扩展功能已经修改,以便于当SecurityManager存在时,默认的实现总是会被使用。这一改变会影响DOM Document创建的NodeSet。在之前,DOM实现由DOM工厂查找过程来定位。在这之后,当运行SecurityManager时,查找过程会跳过,并且用默认的DOM实现。
    这个改变仅影响使用了第三方DOM实现的应用。一般来说,NodeSet结构预计与JDK默认实现相兼容。
    不兼容性: 行为
  • XML:JAXP1.6规范更新
    JDK 8附带了JAXP 1.6,包括规范更新,要求使用java.util.ServiceLoader查找服务提供者。跨JAXP的服务提供者能够通过定义在java.util.ServiceLoader的流程被一致的放置。而JDK7中提供者配置文件可以是位于不同地方的,例如,通过不同的类加载器的getXXX方法比起ServiceLoader,这个改变导致与JDK 7的细微的差异。
    JDK 8 ships with JAXP 1.6 and so includes specification updates that mandate the use of java.util.ServiceLoader for finding service providers. Service providers across JAXP will now be located consistently following the process as defined in java.util.ServiceLoader. The changes may result in some subtle differences from implementations of JDK 7 where the provider-configuration file may have been located differently, for example, by using a different getXXX method of the ClassLoader than ServiceLoader.
    应用实现自己的类加载器,应该确认类加载器的getXXX方式的实现是一致的,以便保持兼容性。
    JSR 173中StAX API定义了接收factoryId参数的newInstancenewFactory方法。因为在StAX规范中对这个参数没有任何限制,意味着可以是任意字符串。在JDK 8规范中进行了一下变更,在JAXP上下文里,如果他想要表示服务配置文件的名称,factoryId的值必须是基本服务类的名字,即,他不是一个系统属性名称。
    不兼容性: 行为
    RFE: 8005954
  • XML:JAXP的javax.xml.stream工厂的类加载器不再忽略
    javax.xml.stream工厂中,类加载器参数不再能忽略。
    javax.xml.stream包包含工厂类(XMLEventFactory、XMLOutputFactory、XMLInputFactory),这些工厂类定义newFactory方法时需要两个参数:factoryId和ClassLoader。在JDK 7中,第二个参数在查找和实例化服务时可以被省略。在JDK 8中不再能省略。可以参考这些方法的Java API文档来获取更详细信息。
    不兼容性: 行为
    RFE:
    8005954

Java SE 8中移除的功能

  • API:java.lang的Thread.stop关闭
    Thread.stop方法从JDK 1.2版本就被弃用了。这个方法现在会抛出一个UnsupportedOperationException。
  • 核心库:java.net从需要的协议处理程序的列表中移除ftp协议
    ftp是一个历史遗留的协议,它在很长时间内被一些更加安全的文件传输协议(比如sftp)取代。ftp协议已经从协议处理程序列表中移除并且保证透明的。它实际上不是移除协议处理程序-应用使用这个协议时能够继续工作,但是它的存在已经不再需要。
    RFE: 8000941
  • 安全库:java.security不支持不安全的1024以下RSR密钥
    在衡量基于加密算法的公钥强度上,秘钥的长度是一个很重要的安全参数。小于1024 bits的RSA秘钥被认为是可以破解的。
    在这次更新中,如果他们的RSA秘钥长度小于1024 bits的话认证会被阻止。这个限制是通过Java Security property,jdk.certpath.disabledAlgorithms实施。这种做法会影响附着security property的provider(比如Sun provider和SunJSSE provider)。security property和jdk.certpath.disabledAlgorithms也同样覆盖TLS使用的静态秘钥(X.509证书秘钥)的使用。
    有了这些秘钥长度的限制,这些使用基于长度小于1024 bits的RSA秘钥的X.509证书在证书路径的建立和验证过程中会遇到兼容性的问题。这些秘钥的长度限制同样会影响需要验证X.509证书的JDK组件,比如JAR签名验证,SSL/TLS传输和HTTPS连接。
    为了避免这些兼容性问题,使用了基于长度小于1024 bits的RSA秘钥的X.509证书的用户会被推荐使用更强的秘钥并更新他们的证书。作为一种变通的方法,在自己能够承受的风险之上,为了允许较小长度的秘钥,用户可以调节秘钥的长度来限制安全性(jdk.certpath.disabledAlgorithms)。
    不兼容性: 行为

JDK 8中移除的功能

  • Install:安装时不再提供关闭自动更新选项
    为了关闭JRE的自动更新,关闭自动更新并且设置部署配置中的系统属性文件的deployment.expiration.check.enabled属性为false。为了关闭自动更新,移除Java控制面板中的更新按钮中的检测自动检测功能。查看Deployment Configuration File and Properties获取关于deployment.expiration.check.enabled property的更多信息。
  • Install:Solaris的Class Data Sharing文件不会被创建
    在这之前,Solaris SVID包在安装时会创建Class Data Sharing文件。在JDK 8中,32位的Solaris不再被支持,因此Class Data Sharing文件也默认不会被创建。如果想要手动创建Class Data Sharing文件。执行下列命令:
    $JAVA_HOME/bin/java -Xshare:dump
    当命令执行后,Class Data Sharing文件位于:
    $JAVA_HOME/jre/lib/server/{amd64,sparcv9}/classes.jsa
    RFE: 8023498
  • Deployment:Plugin移除经典的Java Plug-in
    旧的Java Plug-in(Java SE 6u10之前的版本)会在这个版本中被移除。
    RFE: 7076143
  • Deployment:Plugin移除Java 快速开始(Java Quick Starter)
    Java快速开始(JQS)服务在这个版本中会被移除
    RFE: 8004321
  • Deployment:Plugin移除Active-X Bridge
    Active-X Bridge在这个版本会被移除。
    RFE: 8004321
  • 核心库:sun.jdbc.odbc移除JDBC-ODBC Bridge
    从JDK 8版本开始,JDK将不再包含JDBC-ODBC Bridge。JDBC-ODBC Bridge已经被认为是一个过渡期的产品,并且是一个仅仅用于选择JDK软件包并不包含在JRE中的JRE不支持的产品。可以使用数据库供应商提供或者是一个商业版本的JDBC Driver替换JDBC-ODBC Bridge。
    RFE: 7176225
  • Tools:apt移除apt工具
    apt工具以及com.sun.mirror包中和它相关的API都将在这个版本中移除。使用命令行工具javac以及包javax.annotation.processing,包javax.lang.model处理注解。
    RFE:
    7041249
  • Tools:java移除32位的Solaris
    32位的Solaris操作系统的Java实现会在这个版本中移除。$JAVA_HOME/bin$JAVA_HOME/jre/bin文件夹现在只包含64位的版本。为了过渡的目的,ISA(Instruction Specific Architecture)目录中$JAVA_HOME/bin/{sparcv9,amd64}$JAVA_HOME/jre/{sparcv9,amd64}有指向32位版本的符号链接。这些ISA目录将在JDK 9版本中被移除。
    SUNWj8rt,SUNWj8dev和SUNWj8dmo,这些之前包含32位版本的安装包现在包含64位版本。SUNWj8rtx,SUNWj8dvx和SUNWj8dmx安装包将被移除。
    64位版本的java不会包含诸如Java Web Start和Java Plug-in的部署工具,因此桌面集成也不再需要了。
    注意到64位的Solaris的可执行文件不能加载位32位Solaris编译和链接的JNI库。因此任何在32位Solaris系统中创建的JNI库都需要重新编译64位Solaris版本。
    RFE: 8023288

Deprecated API

  • 核心库:java.lang:class_loading弃用endorsed
    endorsed-standards override mechanism允许在Java Community Process维护的标准之外,或者是持续独立发展的作为Java SE平台的独立的APIs上实现新版本并且在运行时刻安装。
    一个模块化的映像是由模块而不是jar包文件组成。往前看,我们希望通过可升级的模块(upgradeable module)只支持模块化形式的认可的标准和独立的APIs。
    这个特性会在JDK 8u40版本中被弃用。这个弃用是为将来的Java SE版本中出现的module特性而做准备的。如果想要了解更多信息,查看JEP 200 – The Modular JDKJEP 220 – Modular Run-Time Images
    这些改变不会改变运行时刻的行为。
    RFE: 8065675
  • 核心库:java.lang:class_loading弃用extension
    扩展机制(extension mechanism)允许包含扩展了Java SE平台APIs的jar文件安装到一个运行时映像,使它们的内容在可见的情况下编译或运行的映像上的每一个应用程序。
    这样的扩展机制在发布于1998年的JDK 1.2版本引入,但是在现在我们看不到任何凭证显示有人去使用这个特性。这并不奇怪,因为多数现代的Java应用程序会直接在class path上直接安装类库而不是在运行时刻去安装类库。
    这个特性会在JDK 8u40版本时弃用。这个弃用是为将来的Java SE版本中出现的module特性而做准备的。如果想要了解更多信息,查看JEP 200 – The Modular JDKJEP 220 – Modular Run-Time Images
    这个特性的弃用需要下列标准规范的改变:

    • java.lang.System.getProperties()方法中,java.ext.dirs系统属性的规范会被修订为包含一个会在将来版本中移除的弃用声明。
    • java.util.jar.Attributes.Name类中,域EXTENSION_INSTALLATIONIMPLEMENTATION_URLIMPLEMENTATION_VENDOR_ID的被弃用表明应该使用class path代替它们。
    • 在JAR文件的规范中,所有和打包JAR包的小程序依赖的已安装的可选包和触发对可选包下载的相关的manifest属性都被弃用。这些属性包括:xtension-Name, Extension-List, <extension>-Extension-Name, <extension>-Specification-Version, <extension>-Implementation-Vendor-ID, <extension>-Implementation-Version, <extension>-Implementation-URL, Implementation-Vendor-Id, Implementation-URL,Extension-Installation。 这些改变不会改变运行时刻的行为。 RFE: 8065702
  • 核心库:java.lang弃用SecurityManager.checkMemberAccess
    SecurityManager.checkMemberAccess被弃用。它在调用者的栈帧深度为4的时候容易出错。JDK的实现将不再调用SecurityManager.checkMemberAccess方法去执行成员变量访问控制的检测;替代它的是调用SecurityManager.checkPermission方法。
    通过重写checkMemberAccess方法定制的SecurityManager的实现可能会被影响导致重写的方法不会被调用。
  • 核心库:java.lang弃用SecurityManager类的checkTopLevelWindow, checkSystemClipboardAccess, checkAwtEventQueueAccess
    可替代的方法: checkPermission
    RFE: 8008981
  • 核心库:java.rmi弃用RMI/JRMP的HTTP代理
    RMI/JRMP的HTTP代理功能被弃用,而且HTTP的代理功能默认被关闭
    RFE: 8023862
  • 核心库:java.rmi弃用RMI(JRMP)静态生成stubs
    不再支持RMI(JRMP)静态生成stubs
    RFE: 8023863
  • 核心库:java.util.jar弃用Pack200.Unpacker接口的addPropertyChangeListener和removePropertyChangeListener
    这些方法希望在将来的Java SE版本中移除
    可替代的方法: 跟踪unpacker执行过程,轮询PROGRESS属性的值。
    RFE: 8000362
  • 核心库:java.util.logging弃用LogManager接口的addPropertyChangeListener和removePropertyChangeListener
    这些方法希望在将来的Java SE版本中移除
  • 核心库:com.sun.security.auth.callback弃用DialogCallbackHandler类
    使用时会告知将会被移除,在JDK 9的版本中会被彻底移除。
    RFE: 7190273
  • 核心服务:javax.management的RMI连接器IIOP将移除
    JSR-160规范已经更新了关于RMI连接器不再需要支持IIOP传输。Oracle JDK 8会继续支持IIOP的传输,但是支持IIOP的传输希望会在将来版本的JMX Remote API中移除。
    RFE: 8001048
  • 客户端库:javax.accessibility弃用javax.swing.JComponent.accessibleFocusHandler
    可替代的方法: java.awt.Component.AccessibleAWTComponent.accessibleAWTFocusHandler
    RFE: 7179482
  • JavaFX:Scene Graph弃用Builder
    可替代的方法: 使用合适的构造器和set方法去构造对象。
    RFE: RT-30520
  • 安全库:java.security弃用insertProvider
    java.security.SecurityPermission insertProvider.{provider name}的目标名称在将来使用时会被劝阻,因为他可能在重写java.security.Provider.getName方法时会遇到命名约束而被阻止。同样,在使用通过插入一个指定命名或者是选择获取的任意名称的provider授予代码权限时会有同样的风险。
    可替代的方法: 新的insertProvider目标名称。兼容现有已经被保留的policy文件,原因在于新旧的权限都会被Security.addProviderinsertProviderAt方法检测。
    RFE: 8001319
  • HotSpot JVM:gc弃用一些组合
    以下的GC组合被弃用:

    • DefNew + CMS
    • ParNew + SerialOld
    • Incremental CMS

    对应的命令行选项会产生警告信息并且建议你不要使用这样的组合。这些命令行选项会在将来的某个主要版本中移除。

    • 命令行选项-Xinggc被弃用
    • 命令行选项-XX:CMSIncrementalMode被弃用。注意,这个命令行选项会影响所有的CMSIncremental选项。
    • 命令行选项-XX:+UseParNewGC被弃用。除非你同时使用选项-XX:+UseConcMarkSweepGC
    • 命令行选项-XX:-UseParNewGC只有在和-XX:+UseConcMarkSweepGC选项一起使用时被弃用。 想要获得更多的信息,请查看 http://openjdk.java.net/jeps/173 RFE:8006479
  • Hotspot:gc弃用CMS GC的前端收集器
    CMS GC的前端收集器(foreground collector)已经被弃用,并且希望在将来的某个版本中移除。使用G1或者是常规的CMS替代。
    比如在使用-XX:+UseCMSCompactAtFullCollection -XX:+CMSFullGCsBeforeCompaction -XX:+UseCMSCollectionPassing等选项时,会打印一个已经弃用的警告,但是VM仍会继续工作。
    RFE: 8027132

[翻译]JDK8有什么新东西?

翻译官方文档,译者精力有限,忽略部分划删除线。
译者:坤谷(@JianhaoMo) ,校对:井桐(@张同宝

Java SE 8是一个Java主要特性的发布版本。本文总结了在Java SE 8、JDK 8以及Oracle实现的Java SE 8中的新特性和增强的功能。点击下面各个组件的名称可以获取该组件增强的更详细说明。

  • Java编程语言
    • Lambda表达式(Lambda Expressions)作为一种新的语言特性引入到这个版本中。它们允许我们将功能作为方法的参数传递,或者把代码看成是数据。Lambda表达式能够让你更加简洁的表达单个方法的接口(函数式接口)的实例。
    • 方法引用(Method references)为有名称的方法提供易于阅读的lambda表达式。
    • 默认方法(Default methods)能够使新功能被添加到库的接口中,并确保与旧版本中为这些接口写的代码二进制兼容。
    • 重复注解(Repeating Annotations)提供对于同样的声明和类型使用时可以多次使用相同的注解类型的能力。
    • 类型注解(Type Annotations)可以在一个类型的任意使用位置使用注解,而不局限于在类型声明处使用。配合可插拔的类型系统(pluggable type system)使用,类型注解可以提高代码的类型检查能力。
    • 改进类型推断
    • 方法参数反射
  • 集合类
    • 新的 java.util.stream包中的类为集合类的元素提供了流式API来支持函数式的操作。该流式API被集成到集合API中,它使得集合类可以进行(串行或并行map-reduce)批量操作。
    • 改进Has​​hMaps键冲突的性能
  • 紧凑的配置,提供了Java SE平台的预定义子集,使得小型设备的应用程序可以不需要再在整个平台上部署运行。
  • 安全
    • 客户端TLS 1.2默认启用
    • 新的AccessController.doPrivileged变量使代码对其权限的子集进行断言,而避免遍历整个方法栈来检查其他权限
    • 更强大的基于密码的加密算法
    • JSSE服务器支持SSL/TLS服务器名称指示(SNI)扩展
    • 支持AEAD算法:增强了SunJCE provider,支持AES/GCM/NoPadding cipher实现以及GCM算法参数。增强SunJSSE provider,支持基于cipher suites的AEAD模式。看考甲骨文提供的文档,JEP 115。
    • 增强KeyStore,包括新的Domain KeyStore类型java.security.DomainLoadStoreParameter,以及keytool工具新的命令选项-importpassword
    • SHA-224消息摘要
    • NSA Suite B Cryptography增强
    • 更好地支持高熵随机数生成
    • 新的java.security.cert.PKIXRevocationChecker类用于配置X.509证书吊销检查。
    • Windows 64位PKCS11。
    • 为Kerberos 5 Replay Caching 新增rcache类型。
    • 支持Kerberos 5协议转换和约束委派。
    • 默认情况下禁用Kerberos 5弱加密类型。
    • 对GSS-API / Kerberos 5提供未绑定的SASL。
    • SASL服务支持多主机名。
    • Mac OS X支持JNI桥接原生JGSS。
    • SunJSSE provider 支持更强的短暂DH密钥。
    • JSSE支持服务器端cipher suites的定制。
  • JavaFX
  • 工具
    • jjs命令用于启动Nashorn引擎。
    • java命令可以启动JavaFX应用程序。
    • 重新设计java man页。
    • jdeps命令行工具用于分析类文件。
    • Java管理扩展(JMX)给诊断命令提供远程访问。
    • jarsigner工具增加请求从Time Stamping Authority(TSA)已签名的时间戳的选项。
    • javac工具
    • javac命令的-parameters选项可以用来存储形参名称并可以用反射API来获取形参名称。
    • javac命令现在能正确地执行在Java语言规范(JLS)第15.21关于相等运算符的类型规则。
    • javac工具支持检查javadoc注释的内容。检查可能导致javadoc生成的文档的各种问题,如无效的HTML或可访问性问题。 该功能是通过启用新的-Xdoclint选项来执行。 欲了解更多信息,请参阅运行“ javac -X”的输出。这个功能也可以在javadoc工具中使用,默认启用。
    • javac工具还提供根据需要生成native头文件的能力。 这免去了构建流程中单独运行javah工具的必要。javac通过使用新的-h选项来开启,该选项用于指定头文件写入指定的目录。 native方法和标注了新注释java.lang.annotation.Native的常量字段,都将生成头文件。
    • Javadoc工具
    • javadoc工具支持新DocTreeAPI,使你能够以抽象语法树的方式遍历Javadoc注释。
    • javadoc工具支持新的Javadoc访问API,使你能够直接从Java应用程序调用Javadoc工具,而不执行新的进程。 请参阅的javadoc新特性了解更多信息。
    • javadoc工具现在已经支持检查javadoc注释的内容,检查可能生成导致各种问题的注释,如无效的HTML或可访问性问题。 该功能是默认启用,并且还可以通过新的-Xdoclint选项控制。 欲了解更多信息,请参阅“javadoc -X ”的输出。 这个功能也可以在javac工具提供,虽然它不是默认启用的。
  • 国际化
    • Unicode的改进,包括对Unicode 6.2.0支持。
    • 采用Unicode的CLDR数据和java.locale.providers系统属性。
    • 新的Calendar和LocaleAPIs。
    • 能够扩展安装自定义资源包。
  • 部署
    • 对于沙盒applets和Java Web Start应用程序,URLPermission现在用于允许连接回他们所启动的服务器,SocketPermission权限不再授予。
    • 所有安全级别的主JAR文件的manifest必须包含权限属性。
  • 日期-时间包
    • 一组新的软件包提供了一个全面的日期-时间模式。
  • 脚本
  • Pack200
    • Pack200支持由JSR 292引入的常量池项和新的字节码。
    • 支持由JSR-292,JSR-308和JSR-335引入的JDK8类文件的变化。
  • IO和NIO
    • Solaris新增基于Solaris事件端口机制的SelectorProvider,使用时,系统属性java.nio.channels.spi.Selector设置为值sun.nio.ch.EventPortSelectorProvider
    • 减少<JDK_HOME>/jre/lib/charsets.jar文件的大小。
    • 优化java.lang.String(byte[], *)构造函数和java.lang.String.getBytes()方法的性能。
  • java.lang和java.util包
    • 并行数组排序
    • 标准Base64编码器和解码器
    • 无符号运算支持
  • JDBC
    • 删除JDBC-ODBC桥。
    • JDBC 4.2引入了新功能。
  • Java DB
    • JDK 8包含Java DB 10.10。
  • 网络
    • 添加类java.net.URLPermission
    • 如果启用了security manager,类java.net.HttpURLConnection 请求打开一个连接需要获得许可。
  • 并发
    • java.util.concurrent包添加了相关类和接口。
    • java.util.concurrent.ConcurrentHashMap类添加了方法,用于支持基于新的流设施和lambda表达式聚合操作。
    • java.util.concurrent.atomic包添加了类,用于支持可扩展的、可更新的变量。
    • java.util.concurrent.ForkJoinPool类添加了方法,用于支持公共线程池。
    • 添加了java.util.concurrent.locks.StampedLock类,提供了有三种模式的capability-based lock,用于控制读/写访问。
  • Java的XMLJAXP
  • Hotsport JVM
    • 为使用Advanced Encryption Standard(AES)添加硬件相关的intrinsics。 可以通过UseAESUseAESIntrinsics两个flag使得Intel硬件上的基于硬件的AES intrinsics生效。 硬件必须是2010或更高版本的Westmere硬件。例如,要启用硬件AES,使用下面的选项: -XX:+ UseAES -XX:+ UseAESIntrinsics要禁用硬件AES使用下面的选项: -XX:-UseAES -XX:-UseAESIntrinsics
    • 去除PermGen。
    • 对方法调用的字节码指令,支持Java编程语言的默认方法。
  • Java Mission Control 5.3发行说明
    • JDK 8包括JavaMission Control 5.3。

GreenTeaJUG活动 第21期 北京 [帮转]甲骨文Java云开发者活动

时间:2015-11-13
地点:北京
组织:@JianhaoMo

帮转甲骨文Java云开发者活动 请点击官方链接,注册报名

分会场:开发者日-应用开发云

会议日程

14:20-15:05
Java SE 云服务: 在云中运行任意 Java 应用

15:05-15:50
如何使用 Java 云服务在 云中进行 Java EE 测试

15:50-16:00
茶歇

16:00-16:45
使用“Software-in-Silicon”云, 开发高缩放性、高性能、安全的应用

16:45-17:30
使用移动服务打造 更具吸引力的移动应用

GreenTeaJUG活动 第20期 杭州

时间:2015-10-18
地点:杭州文一西路969号阿里巴巴西溪园区1-2-7曼陀山庄
组织:@JianhaoMo

主题:Understanding Java Garbage Collection
讲师:Gil Tene,Azul 联合创始人,副总裁,CTO,从95年开始基于Java技术做产品,浸淫虚拟机技术20年。其载有C4 GC算法的Zing JVM能处理TB级别的Java堆而不用担心停顿。Gil 也是Azul的JCP执行委员会的代表。

主题:Java调试那点事
介绍Java调试体系JPDA、 JVMTI、JDWP、JDI等技术,并附有实例源码。
讲师:邱小侠(@肥侠xx),阿里集团客户体验事业群 高级技术专家

报名

活动报名请按照如下格式发邮件到event@greenteajug.cn
主题:GreenTeaJUG活动 第20期 杭州
姓名:XXX
手机号码:xxxxxxxxxxx (需接收入园短信,请确保正确)
邮箱:xxxx@xxx.xxx
公司:xxxx有限公司
职位:xx工程师
Java使用年限:x年

GreenTeaJUG活动 第19期 安利一下近三年的JVM Language Summit

时间:2015-08-13
地点:网络
组织:@JianhaoMo

JVM Language Summit 2015刚开完。

搞这个活动就是觉得关注JVM Language Summit的人太少,主动安利一下。

近三年的链接如下:

JVM Language Summit 2015

JVM Language Summit 2014

JVM Language Summit 2013