群晖服务器java服务器
JDK 11快要出现在我们身上了，但这不是围坐不做任何借口！ JDK 12的工作已经开始，我们正在跟踪所有正在进行的工作。 而且，由于JDK 11将以社区提供3项JEP贡献 （到目前为止，是一个发行版中社区贡献最多的），因此，让我们看看能否做到这一点！
我们想知道我们的七个Java影响者希望在JDK 12中看到哪些功能，或者将答案与以前版本的愿望清单进行比较。 为了使您了解受访者的愿望清单中的内容，Loom和Valhalla项目以及GraalVM吸引了很多支持者。
由于这是我们访谈系列的最后一部分，因此我们也要讨论Java对无服务器空间的关注（请参阅Project Fn ）。 去年，我们简短地谈论了这个话题，但是现在该深入探讨这个话题了。
只是为了刷新您的记忆，这就是Oracle的Mike Lehmann在2017年告诉我们的 ：
Oracle认为无服务器是自然而然的下一步，从该行业已经从以应用程序服务器为中心的模型转变为容器和微服务，最近有了无服务器。 Serverless就是关于构建应用程序而不必关心计算，存储和网络的基础架构的全部内容–它专注于开发人员，他们只需为应用程序和底层云运行时编写代码，即可解决这些外部资源问题。
不要错过这个Java影响者访谈系列的前四部分：
无服务器会开始重塑Java吗？
认识有影响力的人
Guillaume Laforge（ @ glaforge ）是Google Cloud Platform的开发倡导者，Apache Software Foundation的Apache Groovy PMC主席和Java Champion。
Lukas Eder（ @ lukaseder ）是Data Geekery GmbH的创始人兼研发负责人，该公司是jOOQ背后的公司和Java冠军。
Josh Long（ @ starbuxman ）是Pivotal的Spring Developer Advocate。 他是5本书和3本畅销视频培训的作者。 他还是Java冠军。
Martin Thompson（ @ mjpt777 ）是一名顾问，培训师和教练，专门设计高性能和低延迟的系统。 他还是Java冠军。
昆汀·亚当（Quentin Adam）（ @ waxzce ）是Clever Cloud的首席执行官。
马库斯·埃塞勒（Markus Eisele）： 一般来说，这是另一个多语言的世界，它与所使用的编程语言无关，而与可用的开发人员生产力有关。 Oracle 在这里 推动Fn项目 ，但还有许多其他选择可供探索。
该行业的更普遍的方向是削减可以独立运行的较小的服务。 这意味着Java将需要更好的启动质量，并且可以在JIT机制中使用改进。 新引入的项目，例如Graal和ZGC，已开始从基础架构角度解决这一领域。 我们将看到还有更多的工作要做，以及Java作为一种编程语言如何在迄今为止提供的成熟度和稳定性与我们现在面临的创新周期之间找到平衡。
将您在JShell中运行的脚本之类的东西视为功能即服务解决方案的功能可能很酷，而不必在其中创建具有单个公共方法的Java类。
Guillaume Laforge： 语言本身在容器化或无服务器平台之前可能不会发展很多，但更多的是VM或JDK。
例如，在Java 9和10中，对JVM进行了改进，以了解由容器控制组（cgroup）定义的约束，可用的CPU数量，可用于JVM的实际内存（相对于底层计算机之一）。
无服务器并不总是在容器上/内部运行，但是无服务器产品肯定会从这些改进中受益。
在语言级别上，也许像在JShell中运行的脚本之类的东西被视为功能即服务解决方案的功能可能很酷，而不是必须使用单个公共方法创建Java类。 进一步思考这个想法以得到更简洁的功能定义可能会很有趣。
Lukas Eder： “无服务器”是指存储过程的新名称吗？ 不。它们一直存在，它们不会改变任何东西。
Josh Long：我当然希望如此！ 在Pivotal，我们有一个称为Project Riff的功能即服务平台。 这是一个开放的，Apache 2许可的，功能即服务的平台，该平台建立在Kubernetes和刚刚宣布的KNative技术的基础上，Google和Pivotal合作。
我们还具有Spring Cloud Function，可让您编写与任何一个功能即服务平台无关的代码，并使用适配器进行部署。 Spring带有以注释和POJO为中心的组件模型，这意味着编写函数的方式与使用Java一样简洁。 它可能像一个类一样简单，只有一个方法返回一个java.util.Function <I，O>实例。 甚至只是实现`java.util.Function <I，O>`的类。
还请参见： 认识Helidon，一个新的开源Java微服务框架
但是，这样的应用程序比等效的Node.js应用程序大几行，而且启动速度稍慢。 它比等效的Go应用程序慢得多。 那么，这是一个问题吗？ 我不这么认为。 我认为，关于无服务器或从零扩展平台的讨论是关于拥有自以为是的操作模式。 它是平台即服务的进一步专业化迭代。 也就是说，平台的价值不是我们可以将其扩展为零并节省运行单个应用程序实例的“成本”。 如今，大多数组织可以负担得起公共云基础架构上廉价实例价格。
相反，无服务器是为了优化组织敏捷性。 我要多久才能完成发送电子邮件，调整图像大小或运行报告并运行并响应触发事件的工作？ 有了Project Riff这样的平台，结果很快！ 而且，所有这些都可以与Java生态系统的其余部分集成。 有鉴于此，我认为无服务器已经在重塑Java，它是建立在受云原生应用程序最新趋势启发的演变之上的。 它基于我们在迁移到云原生架构时所了解的运营洞察力。
还请参见： Fn简介：“无服务器必须是开放的，社区驱动的且与云无关的”
Java将来将更适合无服务器-这是个好消息。
Eberhard Wolff： 无服务器有不同的要求。 该代码按需 启动 ，因此 启动时间很重要。 JVM的JIT编译器针对 长时间运行 的 系统 进行了优化 。 随着时间的流逝，JIT将 越来越多的代码编译为机器语言并引入 其他优化。 使用无服务器根本无法获得回报。
同样， 对于无服务器来说 ， 内存消耗更为重要，因为更多的内存会 增加成本。 Java的某些垃圾回收算法会消耗 大量内存。 我认为这些问题是如此根本， 无法解决。 但是，GraalVM可以提前将代码编译 为机器代码，并大大减少了启动时间。 因此，看来 Java将来将更适合无服务器-这是个 好消息！
Martin Thompson： 为了在无服务器领域竞争，Java将必须缩短其启动时间和占用空间。 该领域正在完成工作，但是在与其他语言的占用空间和启动时间竞争时，还有很长的路要走。
还请参见： “ GraalVM的野心比Nashorn的野心要广得多”
昆汀·亚当（Quentin Adam）： Serverless在会议和博客文章中已成为一种趋势，而不是一种新的软件构建方式，正如我在我的文章中所解释的那样 ，今天的FaaS不仅仅是专有应用服务器的回归，而且局限性超出了预期。
但是，如果您查看无服务器的含义，人们希望摆脱服务器管理（而不是摆脱仍在运行软件的服务器），这就是PaaS的核心原则，即自动部署内容并对其进行管理。 从Java的角度来看，这里无事可做，有些人会开始使用无服务器品牌在Java之上创建新的框架或平台，这很好，但是我认为没有什么事情可以使它变得更容易，而且我不认为它必须成为焦点。
您想在Java 12中看到哪些功能？
Markus Eisele： 我仍在热切地监视Valhalla项目的进度，这将是一个很好的补充。 当然，作为新的标准JIT编译器，Graal会很棒。
Guillaume Laforge： 不必 尽一切努力 使Java成为动态语言……我希望看到这种语言增加了一定程度的动态性。
我特别考虑的是诸如dynamic关键字之类的东西，它将使开发人员可以轻松使用JSON负载之类的东西，而无需对某些对象图进行显式编组/解组。 记住，我对Apache Groovy之类的语言提供了对XML和JSON的很好的支持，并且可以通过这种“动态”功能来支持。
GraalVM是一项非常重要的新技术。 因此，这在我的愿望清单中很高。
卢卡斯·埃德（Lukas Eder）： JEP 326 ！ 对于那些喜欢将外部DSL嵌入Java的人来说，这是一个游戏规则改变者（哦，比如说SQL，XML，JSON，CSV，JavaScript，正则表达式，XPath，您可以为它命名）
Josh Long： 我热衷于Project Loom，它支持JVM上的光纤和延续。 不过，我不确定何时发布。
Eberhard Wolff： 我认为GraalVM是一项非常重要的新技术。 因此 ，这在我的愿望清单中很高。 但是， 针对Java 12 的JDK增强 建议不包括GraalVM，它实际上可能是 一个单独的项目。
Martin Thompson： 现在大多数系统都是分布式的，因此网络通信是一个重要功能。 我们在Loom项目上取得了一些进展，但我认为这是错误的战略方向。 大多数应用程序开发人员在进行网络调用时都会使用一个库，因此他们不会直接使用网络API。 消息传递和通信系统的库开发人员正在寻求更好的NIO库，以使用DPDK等最新功能，或者与Windows或Linux API进行更直接的集成。 网络库开发人员对非阻塞API很满意，因此不需要将它们隐藏起来。
还请参见： ZGC：使Java成为更广泛的应用程序更具吸引力的平台
此外，Serverless建议从网络触发事件驱动的设计。 这感觉像是Java的一个被忽视的领域。
模式匹配：此功能非常有趣，可以使代码更具可读性。 这是一个很好的解决方案，可以避免级联if / else时出错，允许编译器检测未发现的选项，这对Java来说确实是一个很好的补充。
Quentin Adam： 对于Java语言，我要注意两点：
- 尝试使其不那么冗长，也许将更多的项目Lombok想法与可选的getter / setter（在编译时自动生成）集成在一起，这将是减少我们代码库中样板代码的好解决方案。
对于Java作为平台，我真的希望在WebAssembly编译上做更多的工作，以便能够在浏览器和区块链上使用JVM / Java代码库。
翻译自: https://jaxenter.com/java-influencers-series-final-part-149208.html
群晖服务器java服务器
1203
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
