今天，在我们的虚拟工作室中是Sebastian Dashner。 简而言之，这是谁：
在这次采访中，我们将讨论以下主题：
隐藏文字- 通常的问候：他喜欢俄罗斯和西伯利亚，骑JUG自行车；
- 开发者倡导者做什么，是否闲置；
- IBM的开源是什么？
- 保持开发人员的生产力（带有指向塞巴斯蒂安YouTube的链接）；
- Java EE和Jakarta EE的现状；
- 我需要合并Java EE和Jakarta EE吗？
- 关于Eclipse Specification Process的意见；
- 关于IBM WebSphere Liberty Profile，与Full Profile的区别以及与实际产品的关系的讨论；
- 与Helidon项目的关系，以及与“扔掉Java EE并再次重写它”有关；
- Java云支持：Kubernetes，Istio；
- 最后一个问题：台式机上的Linux。
与往常一样，采访来自JUG.ru集团的Evgeny Trifonov（ phillennium ）和Oleg Chirukhin（ olegchir ）。
尤金：让我们从一个非技术性问题开始。 在您的Twitter上，我在JAVA运动衫的新西伯利亚看到了一张您的照片 。 您对这次旅行有什么印象？
塞巴斯蒂安：很高兴您认出这张照片，我在2017年的Joker上有这件运动衫。我绝对记得JBreak会议。 我从来没有想到过我会走到西伯利亚这么遥远的角落-我认为，从我的朋友圈中，我是去过那里的少数人之一。 另外，在会议的前一天，我庆祝了我的生日，我们骑了雪地车，然后坐在浴室里吃了烤肉串。 通常，有许多令人愉快的回忆。 新西伯利亚周围的自然环境非常美丽。 而且，如果您将克拉斯诺亚尔斯克（Krasnoyarsk）和托木斯克（Tomsk）算在内，那么在您周围一千公里的地方，没有其他主要城市，这一事实给人留下了深刻的印象。
Eugene：您是IBM的Java Developer Advocate。 这不是很常见的情况-我认识的其他开发者倡导者倾向于推广他们公司的产品。 您在IBM的确切职责是什么？ 您是否正在尝试以各种可能的方式最大化Java的分发和有效使用？
塞巴斯蒂安：是的，这是对我所做工作的准确描述。 我必须首先补充一点，我的利益不只是公司或产品的利益，而是开发商的利益。 我努力促进他们的工作，并以一种或另一种方式讲授与Java Enterprise有关的东西。 我在博客，播客，研讨会和会议上分享我的知识。 我不出售任何特定产品，而是出售整个技术。
Eugene：您是开源的大力支持者，但是为IBM工作，对于大多数人来说，IBM与开源无关。 同时，我知道IBM有时会在许多开源项目（例如OpenJ9）中相当活跃。 IBM与开源有何关系？
塞巴斯蒂安：您正确地指出，许多人常常低估了IBM对开源项目的参与-在我开始在这家公司工作之前，我本人对此一无所知。 例如，IBM在Cloud Native和Java中进行了大量工作，并且是Kubernetes和Istio的主要贡献者之一。 Eclipse Foundation打开了对OpenJ9源的访问，Eclipse Foundation由IBM创建。 该公司还为无服务器技术的发展做出了贡献，例如Apache OpenWhisk。 总的来说，IBM的程序员对开源非常友好-该公司现在所做的几乎所有事情都具有开源方面或开源。 到目前为止，人们对IBM在这个方向上所做的努力确实还不够熟悉，我作为开发者倡导者的工作除其他事项外，还包括使社区保持最新状态。
奥列格（Oleg）：我最近在推特上读到，您与史蒂夫·钱（Steve Chin）在日本进行了一次特别的JUG摩托车之旅。 骑摩托车的水罐，哇？ 您能详细说明一下吗？
塞巴斯蒂安：那真是太棒了。 我和史蒂夫·钦（Steve Chin）已经骑过摩托车几次，每次我们都尝试将其与会议和用户群体的演讲结合起来。 这样的旅行有几次在德国，三次在日本。 乍看起来，我们这样做似乎只是为了好玩-当然，我们不能否认我们在旅途中度过了愉快的时光。 但是从纯粹的实际角度来看，对于日本或中欧而言，摩托车是一种非常便捷的运输方式，因为那里有用户群和IT社区相距仅一百或两公里，而且您可以避免摩托车交通拥堵。 在每一次旅行中，我们都试图与尽可能多的人会面，并与他们分享我们的知识。
奥列格（Oleg）：您旅行很多，甚至去了俄罗斯，尽管要获得我们的签证并不容易。 有一种观点认为，Developer Advocate不是一个认真的职业。 就像您环游世界一样，在会议上玩得开心–任何都可以，不用写代码。 你觉得你真的很努力吗？ 似乎每天都应该疲惫。
塞巴斯蒂安：我认为两种观点都正确。 我喜欢我的工作，但远非总是那么简单。 一个不会干扰另一个。 确实，旅行可能会令人筋疲力尽，特别是如果您在搬家后没有立即休息，而是在会议上讲话或组织研讨会。 会议之后，您需要再次登机，所以整天都很忙。 另一方面，如果不进行这项活动，那么屋顶将很快地偏离这种节奏，一个人只会被烧光。 通常，如果我设法教别人一些东西并在一天之内举办成功的研讨会，那么即使疲劳也变得令人愉悦。
尤金：据我所知，这项工作需要大量的努力，才能跟上该领域的最新技术。 由于Developer Advocates的额外工作量，这比那些经常编程的人要难。 我知道您经常为Jakarta EE编写代码，因此您显然并没有脱离技术。 同时成为开发者倡导者和开发者难吗？
塞巴斯蒂安：是的，当然，对于我的工作来说，保持一名程序员非常重要，否则您将与现实失去联系。 要熟练地谈论技术，您需要不断使用它的经验。 由于会议的缘故，编程时间实际上要少得多。 此外，您需要对技术方面的内容真正着迷，并且可以准备在晚上和周末度过。 一般而言，活动双方之间必须保持一定的平衡。
奥列格（Oleg）：让我们继续讨论技术问题。 您的博客首页上有一个题词：
IT应该简单而高效。
IT应该解决问题，而不是解决问题。
我相信IT是机会，而不是成本因素。
您认为决定Java开发人员生产力的最重要因素是什么？ 关于如何提高工作效率，生活技巧，特定技术nishtyaki以及jcmd或sdkman等实用程序，有什么技巧吗？
塞巴斯蒂安：是的，有很多这样的程序。 至于简单性，我们正在谈论需要努力消除开发工具和使用这些工具的实现中的过度复杂性。 通常，开发人员本身就被复杂性所吸引，越来越多的功能完全出于运动兴趣而添加到产品中。 您总是需要问自己：此功能会使世界变得更好吗？ 它会帮助解决任何问题吗？ 它将使我们更接近完成产品吗？
如果我们谈论开发人员本人的生产力，我真的可以为此推荐资源。 Google我的名字和短语“开发人员的生产力”。 我录制了一个视频课程， 该课程发布在Youtube上 ，我在那里提供有关此主题的建议。 它讨论了如何使用命令行，热键以及如何使用键盘。 总的要点是如何在更短的时间内完成更多工作。 而且，如果您开始研究此主题，那么工作的自动化和优化过程将被延迟。 您将有更多的时间来思考问题的解决方案，而花更少的时间来愚弄钥匙。 通常，编程性能是非常接近我的主题。
奥列格（Oleg）：据我了解，您是MicroProfile的提交者，因此您可以了解与之相关的所有信息。 请告诉我们Java EE和Jakarta周围发生了什么？ 我读了一些，但是对我来说，作为一个来自春季世界的人，这一切太令人困惑了。
Sebastian：您可能知道，Jakarta EE是Java EE的继承者，Java EE现在已转移到Eclipse Foundation。 这是一个相当复杂的过程，并且尚未完成，因此开发人员无法使用Jakarta EE。 但是，该基础仍基于Java EE标准，起点将是Java EE8。当然，将来，Jakarta EE将继续以与Java EE通过JCP（Java Community Process）发展的方式相同的方式发展。 这意味着由多个公司，公司和个人开发人员组成的社区将共同开发新的Java企业版标准。
由于Java EE中的这些更改，MicroProfile出现了。 它是由几个运行Java EE服务器的供应商创建的。 此处的目标是确保更快地发展技术，减少与严格标准的联系。 在我看来，MicroProfile试图弥补Java EE在现代云原生微服务方面的缺点对我来说非常有趣。 例如，Java EE还没有用于可注入配置，容错，监视，各种OpenTracing等的系统。 MicroProfile使您可以访问所有这些内容，因此您无需自己全部实现它们。 而且，在几乎所有情况下，都与Java EE兼容。 大多数JavaEE开发人员已经熟悉的Java EE标准（例如JAX-RS和CDI）被作为基础。 因此，例如，当我在Java EE应用程序中发现容错能力时，我不会手动编写所有这些内容，而是将MicroProfile与我的应用程序集成在一起。 这两个生态系统很好地融合在一起。 对于许多应用程序，例如Open Liberty或Payara，运行时支持MicroProfile和Java EE。 在这种情况下，剩下要做的就是在运行时中包含某些功能，然后将必要的MicroProfile项目添加到Java EE应用程序中。 在我们等待Java EE最终过渡到Eclipse Foundation的过程中，您可以使用此解决方案。
Oleg：您认为MicroProfile应该成为Jakarta的一部分吗？
塞巴斯蒂安：这是一个很好的问题，目前还没有最终决定。 就个人而言，我认为MicroProfile作为Jakarta EE的一种孵化器最为有效。 新标准首先被添加到MicroProfile（与OpenTracing或可注入配置一样），然后我们研究系统在生产中的行为。 当她成熟时，那些已经证明自己成为完整标准的元素。 因此，我们摆脱了一些不确定性，因为我们已经知道该系统在生产中是否运行良好。
奥列格（Oleg）：由于我们在谈论标准，因此我看到了Eclipse Specification Processes，这是一个巨大的googlodok，很难理解。 包含Jakarta EE规范草案的文档看上去像是一团糟。 你能帮这个球放松吗？ 例如，这与Java社区流程有何不同？
塞巴斯蒂安： Eclipse Foundation是一个开源组织。 目前，我们正在尝试确定Jakarta EE未来将根据其发展的那些流程的形式。 您提到了JCP-因此，我完全同意Jakarta EE的标准应该以JCP为模型的观点。 我相信这个模型表现得很好。 应该记住的是，没有一家公司垄断雅加达EE标准的开发。 几家拥有或多或少相同权利的公司都参与了此过程，因此，如果其中一个公司不再参与开发，他就不会陷入发展中。 我认为这是一个重要的优势，因为该技术非常重要，并且在开放社区中进行开发更安全。
奥列格（Oleg）：如此复杂的技术需要在某些方面进行测试。 您是否使用Java和Jakarta的技术兼容性套件？ 还是您有自己的测试套件？
塞巴斯蒂安：这也是一个非常重要的话题。 在JCP中，所有这些TCK通常都具有封闭源。 这是一个相当可疑的优势。 一方面，规范可以提供测试，以表明某些实现是否有效。 但是普通的开发人员不知道在里面进行了什么确切的测试，这些测试的覆盖范围等等。 现在，TCK已成为开源。 现在，所有公司和开发人员都可以参与其开发和改进。 如果事实证明某个公司的产品无法按照规范中所述运行，则您不仅可以向公司表明这一点，还可以在TCK本身中提出要求。 甚至更好，您可以发送一些请求请求并改进TCK本身。 因此，您不仅可以改善一个供应商的软件，而且可以改善整个生态系统。
Oleg：还有另一种产品名称中带有“ Profile”一词：IBM WebSphere Liberty Profile。 既然您在IBM工作，您能否告诉我们它是什么以及与Open Liberty有什么区别？
塞巴斯蒂安： WebSphere Liberty Profile是Open Liberty的商业版本。 这是IBM为其提供商业支持的Java EE应用服务器。 我可能是错的，但是我认为开放自由在一年半以前就已成为开源。 因此，企业开发人员现在可以使用免费的，经过生产测试的应用程序服务器。 如果公司需要商业支持或某些商业功能，则可以使用WebSphere Liberty Profile。 现在是2019年，我相信现在每个公司都应该提供其产品的开源版本，以便开发人员有机会免费试用该产品。 OpenSource非常重要，我很高兴IBM现在为以前的WebSphere Liberty Server提供了几种选择。
Oleg：听说它是在OSGi之上编写的。 您能告诉我们更多关于它在内部的排列方式吗？
塞巴斯蒂安：我个人没有开发Open Liberty，但据我所知，它确实属于OSGi。 有趣的是，您可以在那里简单地配置要包含的功能。 如果您只想使用仅涵盖少量Java EE标准的MicroProfile，则可以相应地配置系统。 或者，您可以使其具有完整的Java EE应用程序。 由于在运行的实例中仅包含真正需要的内容，因此可以实现最佳的启动时间和最小的资源消耗。
Oleg： Liberty Profile的配置和使用与Full Profile是否不同？ 两种情况下使用的工具是否相同？
塞巴斯蒂安：用法上没有显着差异。 关于功能的选择，两个服务器可以配置相同。 如果您有Java EE或MicroProfile应用程序，则两种类型的设置都相同。
奥列格（Oleg）：公司使用Full Profile已有很长时间了。 在大型组织中使用Liberty Profile是否合理？
塞巴斯蒂安：绝对合理。 即使公司购买了商业支持，也不意味着它必须使用完整配置文件，使用较轻的版本是相当合理的。 如果公司的产品基于现代微服务和轻量级运行时，那么他们最好选择WebSphere Liberty并对其进行配置，以使其仅与MicroProfile一起使用。 幸运的是，商业支持和商业功能与WebSphere的旧世界无关，因此，运行时本身轻巧紧凑，启动速度非常快，可以在几秒钟内完成部署。 因此，如果您具有现代的基于Java EE的应用程序，则可以相应地配置功能并仅包括真正需要的那些标准。 无论您是否使用商业功能，您仍然可以访问此快速而现代的运行时。
Oleg： 10月，Oracle发布了Helidon，这是Java中的轻量级微服务框架。 据我所知，它不使用任何现有的应用程序服务器，它建立在其自己的库集之上。 它们一起提供了构建微服务的基础-配置功能，安全设置，提升Web服务器等。 在此系统之上，甚至还实现了MicroProfile。 我给人的印象是Helidon开发人员认为Java EE有太多遗留问题，需要丢弃并重写。 您如何看待？
塞巴斯蒂安： Helidon是一个非常有趣的项目。 但老实说，我认为需要完全重写Java EE似乎天真。 实际上，大多数应用程序并不需要整体上的Java EE。 通常，需要专用的一组功能/标准，最经常在企业应用程序中使用。 例如，常规MicroProfile尚不提供JPA或用于多线程的复杂脚本。 这至少需要一些Java EE组件。 通常，我现在看到以这种方式创建应用程序的过程。 基于Java EE的最重要和最现代的组件，例如CDI，JPA，JAX-RS，JTA等，我们选择了所需的标准集，而忽略了Java EE中存在的许多继承的东西。 基于此选择，我们将选择支持所有这些功能的运行时。 如果我们正在做与云原生微服务有关的任何事情，那么我们将添加MicroProfile标准，例如容错能力。 但是，像Helidon这样的运行时并不支持仅属于Java EE的功能，而根据我的经验，多线程或JPA是非常必要的功能。 我希望有一个运行时同时支持Java EE / Jakarta EE和Microprofile的运行时，同时提供了选择特定应用程序所需功能的机会。 例如，如果需要持久性并且拥有数据库，则可以启用JPA。 通常，您将具有与MicroProfile非常相似的功能集，但也需要Java EE提供的功能。 这些类型的运行时为Open Liberty，Payara，WildFly等。
Oleg：据我所知，在不久的将来将在雅加达实现的最有趣的功能之一就是对现代云技术的支持。 现在容器中的Java呢？ 据我所记得，几年前在OpenJDK错误跟踪器上，存在一些与兼容性，堆大小，信号等有关的错误。 2019年现在可以在容器中使用Java吗？
塞巴斯蒂安：是的，绝对是。 与此相关的大多数问题的原因不是Java本身，而是Linux处理容器的方式。 通常，容器根本不知道可以设置的各种资源限制。 在最新版本中，这些问题已得到解决。 现在，您可以简单地在容器中运行Java，并且默认情况下将启用这些选项。 而且，如果您要求系统中的内存大小或默认堆大小，则将正确指定这些值。 Java EE在Docker容器中运行良好，并且通常与云原生技术很好地集成在一起。
奥列格：基础设施如何？ 您是否使用Kubernetes或Istio之类的东西？
塞巴斯蒂安：是的，非常活跃。 Docker, Kubernetes, — Istio. Java EE. Cloud-native , , , — , , , ..
: Java EE Kubernetes ? API ?
: Kubernetes Istio . cloud-native . . , Docker, Kubernetes. , - URL, . Kubernetes DNS Istio. . , — -, .
: Java ?
: — Java , . , enterprise- — MicroProfile, cloud-native (Istio, Kubernetes). MicroProfile , . , .
: JPoint « Java Enterprise». ?
: , enterprise-, . — - ; — . Java EE-, , , , .
JPoint. , — . Java-, — .
: . (, «» ). Linux, : ?
: . Linux , , , , . , , . , , . , , . Arch Linux — , . Linux . Ubuntu UI, . — Linux , , , . , , , .
: !
, 5-6 , JPoint «Bulletproof Java Enterprise applications for the hard production life» . Simon Ritter, Kohsuke Kawaguchi, . .
.