戴尔公司网站设计特色,网页设计教程入门,长沙推广优化公司,dw设计一个简单网站如果您错过了新闻#xff0c; Oracle将向Eclipse基金会捐赠Java EE规范 。 这项决策在规范过程中经历了相当长时间的休眠#xff0c;在此过程中#xff0c;人们理所当然地怀疑Oracle对Java EE失去了战略兴趣。 起初#xff0c;Java EE和更广泛的Java社区很好地满足了捐赠规… 如果您错过了新闻 Oracle将向Eclipse基金会捐赠Java EE规范 。 这项决策在规范过程中经历了相当长时间的休眠在此过程中人们理所当然地怀疑Oracle对Java EE失去了战略兴趣。 起初Java EE和更广泛的Java社区很好地满足了捐赠规范的决定。 在没有Oracle减慢流程速度的情况下Java EE涉及人员可以再次尝试关闭非标准化的API。 直到今天由于Oracle和Eclipse基金会对捐赠的一些细节仍存在分歧因此捐赠过程尚未完成。 在推翻所有知识产权的同时Oracle在规范的新家中使用其Java品牌的方式也不太慷慨。 Java EE当然包含Oracle拥有的开放源代码但受商标保护的平台的名称。 这在法律上带来了一个问题如果您授权第三方使用您的品牌名称那么您就产生了将来限制其使用的权利。 更糟的是在涉及与品牌有关的诉讼时您可能会削弱自己在法庭上的地位。 甲骨文和谷歌在Java许可问题上争论了多年因此人们可以预料到商标将是一个困难的讨论点。 而且在不假装对国际商标法了解太多的情况下更多参与其中的人告诉我“使用它或失去它”对于理解此类分歧的总体座右铭来说已经足够好了。 因此首先将规范从Java EE重命名为Jakarta EE以避免利益冲突。 但是新成立的雅加达EE社区真正令人震惊的事情尚未到来。 经过几个月的讨论有关捐赠的形式Eclipse基金会了解到它既不能拥有托管Java EE中定义的API的当前javax名称空间的所有权。 相反现在计划为所有捐赠的API休眠此名称空间。 因此应该在Jakarta EE的规范过程中创建的任何新API都应托管在新的命名空间中以避免侵犯Oracle的商标。 在这一点上弄清楚这意味着什么很重要。 不禁止Jakarta EE和Eclipse Foundation使用javax命名空间或实现其API。 当前存在的API都不会被删除。 但是在新形成的Jakarta EE规范过程中创建或更新的任何API都将需要存在于一个新的名称空间中该名称空间很可能模仿现有的名称空间但以jakarta作为其前缀而不是javax。 例如如果要将新方法添加到 javax.servlet.Servlet接口该servlet规范的下一版本将需要发布一个名为 jakarta.servlet.Servlet而不是将此方法添加到现有API。 我不是Java EE用户我为什么要关心 正式地大多数人都知道Java平台分为两个部分。 第一部分是Java SE其中所有API均在带有java前缀的软件包中定义。 除此之外Java EE的指定E X内java的X命名空间抚育的API。 这些API并不意味着特定的实现而仅定义由Java EE兼容组件的不同供应商实现的行为。 在这种情况下Java EE是几个互不依赖的API规范的统称。 例如Java消息传递规范JMS定义了一个用于与消息队列进行交互的API而Java servlet规范定义了一个用于将调用分派到Web服务器的API。 实际上据我所知没有Java EE应用程序运行时实现了Java EE规范过程中定义的所有API。 一些Java框架甚至只专注于实现一个规范。 例如Jetty Web服务器仅实现Java servlet规范。 因此如果您通过Spring Boot使用Jetty即使您没有直接与规范交互或认为自己是Java EE用户您还是Java EE的正式用户。 尽管有这种形式上的区别即使您只编写了普通Java而没有包括任何外部依赖关系您也可能会遇到Java EE及其javax名称空间。 这是因为选定的Java EE API与JVM的标准映像捆绑在一起。 除了API之外JVM还附带了该API的默认实现以使用户能够轻松解决常见任务。 例如JAXP是Java EE规范它定义了用于在Java中处理XML的API。 XML处理是一项常见的任务尤其是在面向企业的Java平台上将XML包含在内是一个合理的选择。 对于JAXP其假定的通用用法在今天仍然是事实但是其他与JVM捆绑在一起的Java EE规范的老化程度也不尽相同。 例如对于大多数Java开发人员而言SOAP消息传递不再是首选因此JVM捆绑的JAX-WS实现已成为大多数用户的负担。 为了减少JVM的占用空间并在Java 9中引入Java模块系统一些Java EE API已移至已弃用的模块这些模块计划在将来的版本中删除。 当然这并不意味着模块的API本身已被弃用。 JAX-WS仍然活跃并且被许多人积极使用。 但是由于不赞成使用此模块希望在将来的Java版本中继续使用JAX-WS的人员必须将其作为显式依赖项添加。 在我们在虚拟化硬件上运行微服务的时代减少JVM的占用已成为发展JVM的明显目标。 但是从基本JVM映像中删除Java EE API的另一个好处是。 通过要求用户包括对Java EE API的显式依赖升级Java运行时和Java EE不再捆绑在一起。 在Java 8之前管理此类版本依赖性一直很乏味。 如果您不控制将应用程序部署到的JVM的确切版本则尤其如此。 在Java 8之前JVM仅允许通过将jar文件放入JVM的扩展文件夹中来覆盖隐式的Java EE依赖关系。 但是当您与也会受到影响的其他Java进程共享JVM安装时这当然是有问题的。 另外仍然需要对正在使用的JVM安装进行控制。 为了解决此问题尽管继续进行按需捆绑但Java模块系统默认不再解决不推荐使用的Java EE模块这使得可以在JVM中包含显式版本同时还提供了一种激活旧版兼容性的简单方法。 为了使事情变得更加复杂一小部分Java EE API变成了不允许简单分离的Java SE。 例如JDBC规范分为“客户端”和“服务器端”需求其中前者正式属于Java SE而后者则属于Java EE。 这种区别来自最初的Java哲学在Java哲学中Java SE用于面向用户的桌面应用程序而Java EE用于多个并发用户使用的服务器应用程序。 本着这种精神例如JDBC连接接口是在java.sql包中定义的。 毕竟桌面用户当然可能要连接到数据库。 另一方面由于仅将连接池视为多线程服务器应用程序的要求因此在javax.sql包中定义了JDBC DataSource接口。 从今天的角度来看这种分离当然不再有意义但是名称空间和形式上的区别直到今天仍然存在。 当然在由OpenJDK项目管理的Java SE和现在由Eclipse基金会管理的Jakarta EE内分别使JDBC API演变是没有意义的。 因此并不是将Java EE规范的所有部分都捐赠给了Eclipse因此将为JDBC API保留javax.sql命名空间该JDBC API现在被认为仅是Java SE的一部分。 保留此类API的其他示例是JMX API它严重依赖于本机JVM支持。 当然所有一直被认为是Java SE一部分的其他API例如也以Java扩展名称空间结尾的Swing API将保留在其原始包中。 向后兼容性呢 要记住的重要一点是无论是现在还是将来目前都不会消失现有的javax API。 我个人也希望Jakarta EE现在包含的规范能够在未来很多年内支持javax命名空间。 实际上对于大多数Java EE实现而言处理多个名称空间并不是什么新鲜事物但始终是一个重要的主题。 例如当用JPA规范定义的注释逐步替换其注释时Hibernate库已经成功完成了类似的迁移。 在另一个示例中Spring框架与其本机注释并行地支持Java EE CDI规范。 这样做例如可以通过使用 javax.inject.Inject注释或Spring的本机Autowired注释。 一旦将Inject批注转移到jakarta包中我将期望Spring框架同时支持Java EE和Jakarta EE命名空间正如我也期望Java企业API的其他实现者支持它一样。 随着Jakarta EE成为Java EE的继任者我不希望这种支持的实现或维护成本太高因为应用程序服务器供应商可以简单地实现委托给现已过时的Java EE API的Jakarta EE包装器类。 例如通过定义类似于以下内容的包装器类可以在内部将Java EE servlet视为Jakarta EE servlet public class LegacyServlet implements jakarta.servlet.Servlet { private final javax.servlet.Servlet delegate; public LegacyServlet(javax.servlet.Servlet delegate) { this .delegate delegate; } Override public void service(jakarta.servlet.ServletRequest req, jakarta.servlet.ServletResponse resp) { delegate.service( new LegacyServletRequest(req), new LegacyServletResponse(resp)); } } 如果Jakarta EE的目标是逻辑向后兼容当前规范和API那么这应该相当简单。 如果遵守此原则则还要求API的用户仅更新到Jakarta命名空间以防他们想使用已经需要更改代码的新功能。 因此我希望更改后的名称空间不会对未来的Jakarta EE用户产生太大影响而主要是那些实现其API的人的关注。 回顾过去对Java平台的其他更根本的变化当引入Java模块系统时也是如此例如Java模块系统主要涉及库和框架开发人员而很少涉及Java的最终用户。 当然对这两种名称空间的支持永远不会通用尤其是从长远来看因此Java EE API的用户最终将需要对过渡做出反应。 鉴于该规范保留了其API的二进制兼容性但不包括名称空间前缀的更改因此我确实认为移植软件应该易于克服甚至可以自动化。 任何Java类都在每个类文件的常量池中引用其导入的类型。 对于使用新的jakarta前缀来修补工件的所有常量池中的所有相关类型引用的工具而言这将是微不足道的。 这样做Java EE的旧用户可以避免在被动维护下对其应用程序进行源代码更改而仅在编译后应用此类更改甚至在部署期间修补工件。 是什么推动了Oracle 我当然是软件顾问而不是国际商标管辖权的专家。 我对Oracle的决策过程也没有任何见解。 因此请把这最后一部分当作有根据的推测加上我的个人观点而不是事实摘要。 Java社区中的一些声音当前正在指责Oracle通过限制Javax名称空间的使用来违反Java及其用户的利益。 在Eclipse基金会中也进行了激烈的辩论以至于有人建议以这种方式捐赠Java EE因为它与组织的目标和价值不兼容。 鉴于这一更改确实对Java用户带来了巨大的工作量因此当然可以很快得出这一观点。 但是我无法想象Oracle会轻率地做出这个决定。 甲骨文正在并且一直在Java平台上进行大量投资-Java至今还没有像现在这样活跃-但是它也改变了其战略定位。 对我而言甲骨文在进行这些投资时并不“关心” Java社区的想法根本不合适。 那么我认为该决定的动机是什么 对我来说限制与Java EE无关而是关于Oracle保护其对Java SE的兴趣。 归根结底甲骨文正在向Java投资以获利。 通过允许使用其商标甲骨文将放弃对其品牌的控制权从而使这一目标陷入危险。 当然Oracle依靠Java来开发自己的产品并因此维护它。 但是与此同时该公司试图创建一种战略模型以证明为数百名从事Java工作的全职高素质员工提供资金。 显然甲骨文正在推动销售云解决方案并且鉴于该公司除了实力雄厚之外目前在运行时和数据库方面的主导地位我相信他们在该领域获得重要市场份额的机会比许多人预期的要好。 Oracle在核心平台上取得成功的另一个计划是对Graal VM及其编译器的投资这当然也为Java语言在资源受限的环境如容器内中提供了更广泛的应用范围。 但是尽管在某些领域进行投资Oracle肯定也在寻找削减成本的方法并终止不再具有战略意义或盈利能力不足的企业。 尽管让用户包括我自己感到沮丧的是 像Java飞行记录器这样的成功的项目团队被解雇了 但考虑到绝大多数Java开发人员都不需要这种工具这是有道理的。 我相信Java EE既不适合Oracle的计划也不适合该平台的成本概况并且怀有类似的信念。 有鉴于此Oracle可能考虑了放弃该规范与将其捐赠给其他人维护之间的权衡。 尽管捐赠Java EE的选择似乎是没有成本的但是Oracle无疑会为此做出冒险。 通过允许竞争的组织继续他们在Java EE中的努力这些努力还可以增强他们在Java SE领域与Oracle竞争的能力。 在Red Head和IBM参与了云解决方案市场竞争的那些组织中尤其如此。 通过保护其商标权Oracle的目标仅仅是降低竞争对手使用Java EE争夺Java SE市场份额的风险。 公平地说Oracle为Eclipse基础提供了一种继续使用javax名称空间的方法。 但是这将需要基金会将自身限制为将其产品与Java SE认证的JVM实现捆绑在一起而不是例如将其自己的IBM捐赠的OpenJ9捆绑在一起 。 这样做尽管Eclipse使用了javax名称空间Oracle仍将保留对其品牌的足够控制权但是同时签署如此广泛的协议也不符合该基金会的利益是可以理解的。 只是不意味着如此因此甚至有人可能会认为Eclipse首先是接受Java EE捐赠的错误选择。 接下来是什么 在开源社区中我们经常大声讨论我们的工作资金不足。 而且尽管缺乏盈利能力对于单个开发人员来说难以解决但对于大型公司无论是Oracle还是当前讨论中涉及的任何其他公司而言这当然也是一个问题。 在我看来通过Oracle捐赠Java EE的知识产权Java社区已经移交给了该规范的最重要的价值我们应该集中精力处理已有的东西而不要因附加的字符串而过度分散注意力。 就个人而言如果甲骨文失去了对Java品牌的兴趣而不是站稳了脚跟我将更加担心Java的未来。 对于Jakarta EE我都不认为即将到来的名称空间迁移是规范面临的最大问题。 甚至在最近的停滞期之前许多开发人员就对Java EE的灰尘感到沮丧。 我认为问题是该过程的一部分。 实际上Java EE规范通常来自领先框架的实现。 如果另一个框架想要重新发明如何通过更好的API解决相同的问题则需要不断批评该框架不遵守该标准。 尽管事实是该标准通常只是先前最佳实践的快照但所有这些。 因此我希望Jakarta EE可以专注于其发展而不是过多地保留其过去。 有了引人注目的最先进的API如果它使我免于实现最小改动的迭代那么我就不必担心调整代码。 jakarta.servlet.Servlet API。 翻译自: https://www.javacodegeeks.com/2019/05/jakarta-ee-without-javax-world-wont-end-time-either.html
