Java has been a programmer’s dream and what’s the better way to quantify Java’s popularity with the new version release Java 13. After the initial Java enhancement proposal, there have been advancements in JDK features that will blow up Java developer’s mind with a new range of features after the official release on September 17, 2019.
Java一直是程序员的梦想，而用新版本Java 13来量化Java受欢迎程度的更好方法是什么。在最初的Java增强建议之后，JDK功能得到了改进，这些新功能将使Java开发人员大为震惊。在2019年9月17日正式发布之后。
但是，为什么您认为Java如此流行呢？ (But Why do you think Java is so popular?)
Java has been a craze among programmers due to its platform independence and the ability to run on different computers. It has been there for so long that it has been adopted by organizations like banks, insurance companies, enterprises, agencies and mostly by software outsourcing companies.
由于Java的平台独立性和能够在不同计算机上运行的能力，Java引起了程序员的热烈欢迎。 它已经存在了很长时间，已经被银行，保险公司，企业，代理商等组织所采用，并且主要被软件外包公司所采用 。
Java has been there in the business to develop android apps, java web applications, software tools, and scientific applications.
Java一直在开发Android应用程序，Java Web应用程序，软件工具和科学应用程序。
Let us delve into the stats and gauge the popularity ratio of Java applications among other competing programming languages.
让我们深入研究统计数据，并评估Java应用程序在其他竞争性编程语言中的普及率。
As per the recent September report by Tiobe Index, Java applications and programmers has been beholding onto its position and has been giving a tough time to other programming languages.
根据Tiobe Index于9月发布的最新报告，Java应用程序和程序员一直在坚持自己的立场，并一直在艰难地尝试其他编程语言。
After seeing the popularity tribe of Java among the other programming languages, let’s move over to Java 13 JDK’s features in a glance:
在看到Java在其他编程语言中的流行之后，让我们一目了然地转到Java 13 JDK的功能：
- JEP 350: Dynamic CDS Archives JEP 350：动态CDS档案
- JEP 351: ZGC: Uncommit Unused Memory JEP 351：ZGC：取消提交未使用的内存
- JEP 353: Reimplement the Legacy Socket API JEP 353：重新实现旧版套接字API
- JEP 354: Switch Expressions (Preview) JEP 354：开关表达式(预览)
- JEP 355: Text Blocks (Preview) JEP 355：文本块(预览)
Since we can't expect a lot of changes after the initial release of Java 12, still there changes at a functional level that could move over Java programmers to new stable features. The goal is to finalize the preview features by the next LTS version so that they are stable enough and will look good for the next three years. It has been expected that by September 2021, Java 17 will take over the legacy of Java 8 and 11.
由于在Java 12的初始版本发布之后我们不能期望有很多更改，因此在功能级别上仍然存在某些更改，这些更改可能会超过Java程序员而转移到新的稳定功能上。 目标是在下一个LTS版本中最终确定预览功能，以使它们足够稳定并在未来三年中保持良好状态。 预计到2021年9月，Java 17将取代Java 8和11。
在本博客中，我将带您了解Java 13的最新功能。 (In this blog, I am going to take you through the latest features that you can expect from Java 13.)
->动态CDS档案 (-> Dynamic CDS Archives)
Apart from the new features that are obvious to Java developers, a lot has happened under the roof of JVM and in-class library. Class Data Sharing (CDS) was introduced back during Java 5. The ultimate goal of CDS is to shorten the start times of Java applications by storing certain information about classes in Class Data Sharing archives. The data can then be loaded at runtime and used by several JVMs.
除了Java开发人员显而易见的新功能外，在JVM和类库的幕后还发生了很多事情。 类数据共享(CDS)是在Java 5期间引入的。CDS的最终目标是通过将有关类的某些信息存储在类数据共享档案中，从而缩短Java应用程序的启动时间。 然后可以在运行时加载数据并由多个JVM使用。
Until Java 10, however, the shared archives were only accessible for the Bootstrap ClassLoader. Starting with Java 10, CDS was extended by Application Class Data Sharing (AppCDS). AppCDS enables the built-in system and platform class loader as well as user-defined class loaders to access the CDS archives. Class lists are required to create the CDS archives in order to identify the classes to be loaded.
但是，在Java 10之前，共享存档只能由Bootstrap ClassLoader访问。 从Java 10开始，CDS通过应用程序类数据共享(AppCDS)进行了扩展。 AppCDS使内置系统和平台类加载器以及用户定义的类加载器能够访问CDS档案。 创建CDS归档文件需要类列表，以标识要加载的类。
Previously, these class lists had to be determined by trial runs of the application to determine which classes were actually loaded during execution. Since Java 12, default CDS archives are delivered with the JDK by default, which is based on the class list of the JDK.
以前，这些类列表必须通过应用程序的试运行来确定，以确定在执行期间实际加载了哪些类。 从Java 12开始，默认情况下，默认的CDS归档文件随JDK一起提供，它基于JDK的类列表。
Dynamic CDS Archives now build on this. The goal is to save the additional test runs of the application. After an application has been executed, only the newly loaded application and library classes that are not already contained in the Default/Base Layer CDS are archived. Dynamic archiving is activated with command-line commands. In a future extension, the archiving of classes could then run completely automatically and transparently.
现在，动态CDS存档基于此。 目的是保存应用程序的其他测试运行。 执行应用程序后，将仅存档默认/基本层CDS中尚未包含的新加载的应用程序和库类。 动态归档是通过命令行命令激活的。 在将来的扩展中，类的归档将可以完全自动且透明地运行。
-> ZGC：取消提交未使用的内存 (-> ZGC: Uncommit Unused Memory)
Nowadays, it is not so uncommon that the applications have to serve thousands of users at the same time. Such applications need a lot of memory and the management of memory is significant that affects the performance of the application. To meet the stated requirements, Oracle has introduced the Z Garbage Collector (ZGC) in Java 11 as it promises very short pauses when cleaning up heap memories with several terabytes.
如今，应用程序必须同时为成千上万的用户提供服务并不少见。 这样的应用程序需要大量内存，并且内存管理非常重要，这会影响应用程序的性能。 为了满足声明的要求，Oracle在Java 11中引入了Z垃圾收集器( ZGC )，因为它在清理具有数TB的堆内存时承诺非常短的暂停。
Previously, it didn't release the heap memory released reserved for applications. As a result, applications consume far more memory than necessary. An application that runs in low-resource environments is particularly affected. Other garbage collectors such as the G1 and Shenandoah already support the release of unused memory.
以前，它没有释放为应用程序保留的堆内存。 结果，应用程序消耗的内存远远超过了必需的内存。 在资源不足的环境中运行的应用程序尤其受到影响。 G1和Shenandoah等其他垃圾收集器已经支持释放未使用的内存。
->更新的套接字API (-> Renewed Socket APIs)
The Java Socket and Java ServerSocketAPIs are fragments from the JDK 1.0. Most of them consist of legacy from Java and C Code. This makes the maintenance and extensibility much more difficult. The NioSocketImpl is supposed to replace the outdated PlainSocketImpl now. NioSocketImpl is already based on existing New I/O implementation and uses its existing infrastructure in the JDK.
Java Socket和Java ServerSocketAPI是JDK 1.0的片段。 它们中的大多数都包含Java和C代码的遗留物。 这使得维护和扩展性变得更加困难。 NioSocketImpl应该现在替换过时的PlainSocketImpl。 NioSocketImpl已经基于现有的New I / O实现，并在JDK中使用其现有的基础结构。
The previous implementation is not compatible with other planned extensions of the language. For example, concurrency problems hinder the future use of the lightweight user threads (fiber, part of the Project Loom).
先前的实现与该语言的其他计划的扩展不兼容。 例如，并发问题阻碍了轻量级用户线程(光纤，Project Loom的一部分)的未来使用。
->开关表达式的增强 (-> Enhancements for Switch Expressions)
If you look at the feature from the developer’s point of view, then it is the point that is merely interesting. For example, the Switch Expressions was introduced as a preview in Java 12 and it has been extended due to user feedback. The Switch Expressions are an alternative to the cumbersome and error-prone switch statements.
如果从开发人员的角度看功能，那么这只是有趣的一点。 例如，“切换表达式”在Java 12中作为预览引入，由于用户的反馈而被扩展。 Switch表达式是繁琐且容易出错的switch语句的替代方法。
The biggest change in the coding norms that could be seen in Java 13 is the replacement of the keyword break in the switch expression by yield. The background is the better differentiation between a switch statement ( with possible break) and expressions (with yield). The yield statement exits the switch and returns the result of the current branch, similar to a return.
在Java 13中可以看到的编码规范的最大变化是，用yield替换了switch表达式中的关键字break。 背景是switch语句(可能带有break)和表达式(带有yield)之间的更好区分。 yield语句退出开关并返回当前分支的结果，类似于return。
For instance, the below code snippet showcases the scenario where Switch's statement has been used with break and in the other part Switch Expression has been used with the yield to make through the difference between the two.
例如，下面的代码片段展示了以下情况：Switch的语句已与break一起使用，而另一部分中的Switch Expression已与yield一起使用以解决两者之间的差异。
->文本块，而不是原始字符串文字 (-> Text Blocks instead of Raw String Literals)
text block is a new kind to define string literal in the Java language. It may be used to denote a string anywhere that a string literal may be used but offers greater expressiveness and less accidental complexity. The first implementation of Raw String Literals has raised many questions as users have given feedback around the same that has stirred multiple questions.
文本块是一种使用Java语言定义字符串文字的新方法。 它可以用来表示任何可以使用字符串文字的字符串，但是可以提供更高的表达力和更少的偶然复杂性。 Raw String Literals的第一个实现引起了很多问题，因为用户已经就引发了多个问题的问题提供了反馈。
After all, many Java applications can process code snippets from other languages such as HTML or SQL. Until now, such strings could only be defined in a cumbersome way, which makes them difficult to read.
毕竟，许多Java应用程序都可以处理其他语言(例如HTML或SQL)的代码段。 到目前为止，只能以繁琐的方式定义此类字符串，这使它们难以阅读。
For example, extra control commands (escaping with \n) must be used for line breaks. Other languages such as Groovy, Scala or Kotlin have long offered the possibility of defining multi-line texts.
例如，对于换行符，必须使用额外的控制命令(使用\ n转义)。 诸如Groovy，Scala或Kotlin之类的其他语言早就提供了定义多行文本的可能性。
The new text block uses triple quotation marks as delimiters and can be used wherever normal strings are allowed.
新的文本块使用三引号作为分隔符，并且可以在允许使用普通字符串的任何地方使用。
The code snippet below explains the difference between the two:
下面的代码片段说明了两者之间的区别：
The opening and closing triple quotes must be in a separate line. Nevertheless, the actual content starts with the second line. This increases the readability of the source code, as the indentation of the first line is displayed correctly in the source text.
首尾三引号必须放在单独的行中。 但是，实际内容从第二行开始。 因为第一行的缩进在源文本中正确显示，所以这增加了源代码的可读性。
结论： (Conclusion:)
The changes described so far were defined in the JEPs ( Java Enhancement Protocols). There are however further adaptations directly in the class library. But first, you have to install Java 13 while Java 14 version is still in pipeline.
到目前为止描述的更改是在JEP(Java增强协议)中定义的。 但是，直接在类库中进行进一步的修改。 但是首先，您必须在Java 14版本仍在开发中时安装Java 13。
The changes are uncertain and there have been certain features such as Switch Expressions and Text Block that can be finalized. However, the next release is on its way.
变化是不确定的，并且可以完成某些功能，例如开关表达式和文本块。 但是，下一个版本即将推出。
1455
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
