java 迁移数据

“对于基础架构提供商而言，升级到最新的JDK根本不容易”

Java 10是在几周前发布的，但我们仍在剖析其最重要的功能（*咳嗽*局部变量类型推断*咳嗽*）以及那些没有引起关注的功能。 现在该讨论迁移了。 是微风还是龙卷风？ 我们的11名受访者将很快就此问题进行评估。

Java 9也将在今天的访谈中露面，因为即使Java 10在这里，我们也想知道我们的Java英雄是否已经迁移到Java 9或选择完全跳过它-这个问题对我们来说尤其重要最近的调查显示，许多开发人员仍在使用Java 8。

资料来源：JAXenter.com民意调查

我们一直在回溯Java SE支持路线图，但是重要的是要意识到Java SE 9和10是短期发行版。 因此，鼓励用户在可用时过渡到下一个版本。 简而言之，这意味着如果他们不在时不给他们机会，以后再也不会和他们一起玩了。

资料来源：Oracle Java SE支持路线图

回到我们的采访系列！

认识我们的Java专家

Donald Smith是Oracle产品管理的高级总监。

Greg Luck是Hazelcast的首席执行官/首席技术官。

Simon Ritter是Azul Systems的副CTO。

Lukas Eder是Data Geekery GmbH的创始人兼研发主管，该公司是jOOQ和Java Champion背后的公司。

Trisha Gee是JetBrains的一名开发倡导者，是伦敦Java社区的重要成员和Java冠军。

Markus Eisele是Lightbend的开发人员倡导主管和Java冠军。

Marcus Biel是一名软件工匠，JCP成员和CleanCode宣传员。

Wayne Citrin博士是JNBridge，LLC的CTO和联合创始人。

David Heffelfinger是Java冠军和Jakarta EE顾问兼讲师。

Nicolai Parlog是一名开发人员（主要是#Java），CodeFX的博客作者，作家，YouTuber和培训师。

Richard Gall是Packt的传播经理。

唐纳德·史密斯（Donald Smith）： 我已经将Java 10作为基本JDK进行演示和演示。

问题不是我们何时迁移到Java 10，而是何时迁移到IMDG的Java 8？

格雷格·勒克（Greg Luck）： Hazelcast有两个开源项目： 以 我们最著名的 Hazelcast In-Memory Data Grid 和一个新的 Hazelcast Jet 流处理引擎。 Hazelcast IMDG的语言级别为Java 6，而Jet的语言级别为Java 8。

Hazelcast IMDG每月拥有49毫米电话房屋-庞大的安装基础。 截至2018年2月底，使用3.6或更高版本的Hazelcast IMDG用户中有95％使用Java8。这比2016年9月的77％有所增加。因此，问题不在于何时迁移到Java 10，而是何时迁移到Java 10。 Java 8 for IMDG？

对于Jet，我们仅在2017年2月发布了第一个公开版本。如果有足够吸引人的功能来保证它，我们将升级到Java的新版本。

对我而言，这突显了Java版本快速发布的严重问题。 尽管应用程序很容易升级到最新的JDK，但是对于基础架构提供商而言，这样做是不容易的，因为他们需要容纳已安装的基础。

Simon Ritter： 我一定会把它用于我编写的演示代码。 由于我不再编写生产代码，因此我可以在使用JDK方面具有更大的灵活性，并且我不必太担心更新。

Lukas Eder： jOOQ将支持它。 而且jOOQ集成测试可能会迁移到Java 10，因为它们也将从JEP 286中受益。

Trisha Gee： 我已经在其中编写了一些示例代码。 我可能会将一些演示迁移到Java 10，以查看它是否对代码的可读性或性能产生重大影响。

Markus Eisele： 我已经使用了一段时间了。 尽早测试，他们经常说测试。 我相信每个人都应在发布Beta版本后立即开始使用它们。 发现困难和错误是社区的努力。

Marcus Biel： 作为一名Java影响者，我显然已经尝试了Java 10早期访问版本，并且我将尽快进行迁移。 但是我的客户刚刚升级到Java 8，因此不幸的是Java 10将不得不等待更长的时间。

还请参见： Java 10终于来了！ 仔细了解新功能

Wayne Citrin： 从Java 5开始，我们的产品必须在所有版本的Java上运行。我们已经针对Java 10测试了我们的产品，并且没有重大更改，但是我们目前不打算使用Java 10实际重建我们的产品。 。

David Heffelfinger： 我可能会迁移一些个人项目。 我是一名顾问，我的大多数客户都是大型的，保守的组织，他们非常规避风险，因此，大多数人可能会在一段时间内不迁移到Java 10。

Nicolai Parlog： 是的。 这相当容易，并且Java 9没有更多的公共更新，因此这很容易。

理查德·加尔（Richard Gall）： 不。 毕竟，Java 10不是长期支持版本。

Greg Luck： 对于IMDG和Jet，我们都检查了它们是否在Java 9上构建和运行。

Hazlecast IMDG 3.10和Hazelcast Jet 0.6都将于4月发布，它们将支持Java9。但是它们都不使用Java 9语言级别。

对于Jet，我们仔细检查了Java Modularity，看是否可以添加它，以便Java 9可以识别它，但不会破坏Java8。这是行不通的。 如果尝试，则会出现以下编译器错误。

Error:(1, 1) java: modules are not supported in -source 1.8
(use -source 9 or higher to enable modules)

因此，没有module-info.java。 但是，如果有人尝试通过将库添加到模块路径来使用Java 9中的非模块化代码，则该库将变为可用。 这称为自动模块。 但是，用于自动模块的名称是jar名称。

一种良好的做法，也是我们在新版本中添加的一种做法，是为这些自动模块创建稳定的名称。 这是通过 在Jar清单中 添加一个 Automatic-Module-Entry条目来完成的。

我们的稳定名称是：

Hazelcast IMDG

Automatic-Module-Name: com.hazelcast

榛树喷射机

Automatic-Module-Name: com.hazelcast.jet

Java 9中模块系统的另一个问题是，一个软件包必须完全包含在一个模块中。 听起来是一个好主意。 但是实际上，我们在客户端和服务器端都有一些带有相同软件包的代码。 因此，这破坏了模块系统。 因此，这需要我们进行重大的重构。

我们还有其他内容，例如管理中心和许多模块。 3.10版中的管理中心已升级到Java 9。 各个模块还将在使用它们的社区的推动下提高其语言水平。

Simon Ritter： 我使用JDK 9进行了一些演示。 总体而言，我发现它非常简单。 我认为，如果直接或间接（通过框架或第三方库）使用内部API（例如sun.misc.Unsafe），则将需要更多工作。

借助IntelliJ IDEA，向Java 9模块的迁移是一种魅力！

Lukas Eder： jOOQ必须支持Java 9（尽管从版本3.10开始，它尚未模块化）。 我们的其他库（包括jOOλ，jOOR，jOOU，jOOX）已被模块化，并作为交叉发布的产品发布给需要的人。 后四个库很容易模块化。

jOOQ不是，因为它内部依赖于JAXB。 对于图书馆供应商而言，升级到Java 9并使其正常运行并非易事，但对于最终用户而言，我认为该过程相当简单。 有大量的好博客记录了这些警告。 我最喜欢的是Nicolai Parlog， 最近我采访了他 。

Trisha Gee： 是的，我做到了。 这很痛苦，因为我很早就在实际发行的第一年就这样做了，所以我使用的许多工具和库都不完全支持Java9。但是值得这样做

a）早期了解Java 9，使用感觉如何，痛点可能是什么（并且还报告错误和其他问题！）和

b）帮助向那些不能与Java 9一起使用的工具和库提供有用的反馈，以便在Java 9发行时就可以使用它们。

我相信，使用最终发布的版本迁移到Java 9，再加上现在对工具和库的支持，将相对简单。

Markus Eisele： 我已经对自己的宠物项目进行了一些本地测试，但还没有什么严肃的过程可以称之为过程。 我基本上遵循了 Oracle官方指南， 并且运行顺利。

Marcus Biel： 去年，我将自己的项目迁移到Java 9。 借助IntelliJ IDEA，向Java 9模块的迁移是一种魅力！ 使用Eclipse Oxygen和Java 9模块并不那么顺利，但是在下一版本中可能会有所改善。

Wayne Citrin： 我们目前正在针对Java 8构建代码，但是我们已经针对Java 9对编译后的产品进行了测试，并且效果很好。 由于版本号API和架构的更改，发生了一项重大更改，但是可以轻松地对其进行修复。 Java 9的多发行版JAR文件功能使我感到兴奋，但是由于我们还不需要利用Java 9或Java 10特定语言的功能，因此我们还没有使用它。 我相信我们会很快。

还请参见： 开发人员仍在使用Java8。这对于Java 10的采用意味着什么？

David Heffelfinger： 在某些项目中，我确实迁移到了Java 9。 但是，我主要使用Java EE，因此某些Java EE应用程序服务器无法在Java 9上正常运行，因此，我的某些项目仍在使用Java 8，许多客户的风险规避也使我继续使用Java。

尼古拉·帕洛格（Nicolai Parlog）：嗯 。 激烈？ :)代码库越大，您可能会遇到的迁移挑战就越多，并且其中许多感觉就像是意外的事故 -我遇到了很多。 修复它们几乎总是意味着要付出一些技术部门的费用，因此我觉得时间投入得很充分。

理查德·加尔（Richard Gall）： 不确定。 在迁移的一些项目中，我主要是FOSS。 其他人则使用Java 8或Java 6。

在我们的访谈系列的第四部分（以后还会有两个）中，我们的受访者会考虑新版本的节奏，并揭示传统开发人员是否应该担心如何利用Java 10。

Java 10的12个JEPS

只是为了刷新您的记忆，Java 10包括通过JDK增强建议（JEPS）定义的12个新增强 ：

1. （JEP 286）局部变量类型推断：增强了Java语言，以将类型推断扩展到具有初始化程序的局部变量的声明。 它将var引入Java，这在其他语言中很常见。
2. （JEP 296）将JDK目录林整合到一个存储库中：将JDK目录林的众多存储库合并到一个存储库中，以简化和简化开发。
3. （JEP 204）车库收集器接口：通过引入干净的垃圾收集器（GC）接口，改进了不同垃圾收集器的源代码隔离。
4. （JEP 307）用于G1的并行完整GC：通过使完整GC并行来提高G1最坏情况的延迟。
5. （JEP 301）应用程序数据类共享：为了改善启动和占用空间，此JEP扩展了现有的类数据共享（“ CDS”）功能，以允许将应用程序类放置在共享档案中。
6. （JEP 312）线程本地握手：介绍一种在不执行全局VM安全点的情况下在线程上执行回调的方法。 使停止单个线程而不是仅停止所有线程或不停止一个线程既可行又便宜。
7. （JEP 313）删除本机头生成器工具：从JDK中删除javah工具，因为它已被javac中的高级功能所取代。
8. （JEP 314）其他Unicode语言标签扩展：增强了java.util.Locale和相关API，以实现BCP 47语言标签的其他Unicode扩展。
9. （JEP 316）在备用存储设备上的堆分配：使HotSpot VM可以在用户指定的备用存储设备（例如NV-DIMM）上分配Java对象堆。
10. （JEP 317）基于实验Java的JIT编译器：使基于Java的JIT编译器Graal可用作Linux / x64平台上的实验JIT编译器。
11. （JEP 319）根证书：在JDK中提供一组默认的根证书颁发机构（CA）证书。
12. （JEP 322）基于时间的发行版本：针对当前和将来的基于时间的发行模型，修订了Java SE平台和JDK的版本字符串方案以及相关的版本信息。

翻译自: https://jaxenter.com/java-10-interview-series-part-3-142957.html

java 迁移数据