贵阳网站建设平台,wordpress不能实现静态化,吉林有做网站的吗,百度推广广告收费标准在文章“ 更好的默认NullPointerException消息是否会传入Java#xff1f; ”#xff0c;我总结了当时与JEP 草案有关的背景细节#xff0c;有关使某些类型的NullPointerException #xff08;NPE#xff09;消息更有用。 上周很高兴看到该JEP现在是候选 JEP #xff08; … 在文章“ 更好的默认NullPointerException消息是否会传入Java ”我总结了当时与JEP 草案有关的背景细节有关使某些类型的NullPointerException NPE消息更有用。 上周很高兴看到该JEP现在是候选 JEP JEP 358 “ Helpful NullPointerExceptions”。 在这篇文章中我重点介绍了JEP 358的一些特别有趣的方面。 什么是JEP 358 JEP 358的当前“摘要”简要描述了此JEP“通过准确描述哪个变量为null 提高JVM生成的NullPointerException的可用性。” JEP 358的“动机”部分包括以下段落“如果JVM可以提供查明NPE来源并确定其根本原因所需的信息而无需使用额外的工具或改组代码则整个Java生态系统将受益。 自2006年以来SAP的商业JVM就已经做到了这一点获得了开发人员和支持工程师的一致好评。” 社区对OpenJDK的贡献示例 我感兴趣的JEP 358的一方面是它的背景。 JEP 358的“测试”部分当前指出“自2006年以来SAP的商业JVM中就已经实现了先前的实现并且已经证明是稳定的。” 该声明的目的是证明已经对该功能进行了一些测试但同时指出 SAP及其人员是提出的JDK增强功能的主要贡献者。 JEP的作者Goetz Lindenmaier和Ralf Schmelter 被视为原始作者 已经或已经与SAP保持联系。 我的理解是 SAP OpenJDK版本 SapMachine 尚不包含此功能但商业SAP却包含。 提议的JDK增强功能是一个很好的例子说明多个供应商提供OpenJDK的实现如何在将来使每个人都受益于OpenJDK。 更多细节的缺点 JEP 358解决了由更详细的NPE引入的潜在安全风险。 它指出“ null-detail消息可能包含源代码中的变量名……如果调试信息包含在类文件 javac -g 中”并且“这些以前尚未通过Java的反射API提供给其他程序。” 启用详细的空消息 JEP 358的“替代方案”部分概述了三个人们可能不希望使用较新的更详细的NPE消息的原因性能安全性和兼容性。 它指出“ null -detail消息默认情况下处于关闭状态可以通过命令行选项-XX:SuppressCodeDetailsInExceptionMessages启用。” 该部分补充说“没有办法指定仅关注某些NPE提升字节码”换句话说这是一个全有或全无的选择。 本节以以下语句结束“我们打算在将来的版本中默认启用null详细信息。” 并非所有NullPointerException更详细的消息 JEP 358指出了将应用更详细的消息的NullPointerException类型并将其与将不应用更详细的消息的类型进行了对比。 它指出我特别强调 “ 只有由JVM直接创建和抛出的NPE才会包含null-detail消息。 由JVM上运行的程序显式创建和/或显式抛出的NPE不受以下字节码分析和空细节消息创建的约束。 另外没有报告由隐藏方法中的代码引起的NPE的空细节消息这些方法是由JVM生成和调用的专用低级方法例如用于优化字符串连接。 隐藏的方法没有文件名或行号可以帮助查明NPE的来源因此打印空详细信息将是徒劳的。 如文本所述没有理由尝试提供“隐藏方法”的详细信息。 对于我们自己的代码明确抛出的NPE我们能够在构造异常消息时为其添加有用的上下文。 结论 对此JEP的响应非常热情我认为有很多Java开发人员都希望在以后的OpenJDK发行版中提供更详细的NullPointerException消息。 JDK-8218628 “向NullPointerException添加详细消息描述什么为null。”与JEP 358 JDK-8220715 关联当前与JDK 14关联为“修复版本”。 希望JEP 358正式针对JDK 14 翻译自: https://www.javacodegeeks.com/2019/08/jep-358-helpful-nullpointerexceptions.html
