Java25和Java8

212 Responses to Java25和Java8

  1. shemanese says:

    还有6之后的版本吗?

  2. kacpermu says:

    哈哈!说你自己吧。我的团队几个月前就切换到Java 11了。进展超乎凡人理解。

  3. ClipboardCopyPaste says:

    不管怎样,别忘了“超过30亿台设备运行Java”这一事实

    • alex_tracer says:

      我想“560亿”(2023年数据)就是“超过30亿台设备”,所以这句话仍然成立。

      • phire says:

        这个数字之所以这么高,是因为它包括了像“你手机里的SIM卡”这样的东西,而SIM卡出于某种原因运行着Java。

        是的,你的SIM卡实际上是一台计算机,它运行着一个精简版的Java。

        • billccn says:

          原因在于,您不希望存储加密密钥的SIM卡使用内存不安全的语言,如汇编语言或C语言。

          Java字节码会被转换为本地代码,并实际编程到卡上。

          • phire says:

            Java字节码会被转换为本地代码,并实际编程到卡上。

            并非如此。SIM卡直接运行Java字节码。它必须运行字节码,因为它支持运行小程序,这些小程序可以由运营商在您的卡上静默安装。SIM卡小程序在美国很少被使用,但在其他国家被使用过。我不知道现在是否还有人使用它们,但现代手机仍然支持与这些应用程序进行交互。

            Defcon 演示文稿:

        • licuala says:

          Java Card是一种智能卡解决方案(并非唯一方案),SIM卡即属于此类,它是Sun公司试图打造基于Java的硬件平台时留下的产物。

          • phire says:

            没错,但SIM卡已将Java Card的Java组件固化到标准中,因此它们很可能始终运行Java,尽管SIM卡上的Java小程序已不再广泛部署 (而且在美国从未广泛部署)

    • mr_4n0n says:

      是的,大多数物种都能进行肛交……这是否意味着一切都兼容?

      • DrSlugger says:

        是的。

      • RiceBroad4552 says:

        大多数物种都能进行肛交

        显然这是事实上的错误。

        任何接受过教育、学过生物学的人都应该知道这一点……

        我不会去研究可靠的来源,但以下是一些大语言模型(LLMs)的说法,它们在底线上的说法或多或少是一致的:

        GPT 4o-mini

        哺乳动物是脊索动物门下的一类动物,它们在已知物种中占比较小。目前已确认的哺乳动物物种约有6400种。相比之下,估计地球上总共有约870万种物种,包括植物、动物、真菌和微生物。

        这意味着哺乳动物占所有物种的 0.07% 左右。但需要注意的是,这个比例可能会随着新发现和分类学的修订而变化。哺乳动物的特征包括:有毛发或皮毛、有哺乳幼崽的乳腺、有三个中耳骨等。

        Llama 3.3 70B

        哺乳动物是属于哺乳纲的特定类群的温血动物。它们的特征包括拥有毛发或皮毛、通过乳腺分泌乳汁哺育幼崽,以及具备乳腺。

        仅有极少数物种属于哺乳动物。据估计,地球上大约有870万个物种,其中只有约5400至5500个物种是哺乳动物。这不到所有物种的1%

        o4-mini

        哺乳动物是地球生物多样性中非常小的一部分。根据不同的统计方法,得到的数字略有不同,但都一致认为不到1%。

        1. 地球上物种总数的估计 • 目前对所有真核生物物种(动物、植物、真菌、原生生物)的估计约为870万种。 • 其中,哺乳动物约有5500种。 → 5500 ÷ 870万 ≈ 0.063%,即约为千分之六。
        2. 已描述(正式目录)的物种 • 约有190万种物种已被正式描述(其中大部分是昆虫、其他无脊椎动物、植物、真菌等)。• 哺乳动物仍约有5,500种。 → 5,500 ÷ 1,900,000 ≈ 0.29%,即不到百分之三。

        结论:哺乳动物占所有物种的比例远低于1%——仅占地球生物多样性的几十分之一。

        [ 请注意,这是大语言模型(LLM)的输出结果,未经仔细核对! ]

          • Nice_Lengthiness_568 says:

            遗憾的是,这不是一个子版块

          • RiceBroad4552 says:

            在谈论一些“显而易见”的事情时,这会有任何区别吗?

            正如所说,任何上过一些生物课的人都应该知道,哺乳动物只是所有物种中的一小部分。(我只是懒得引用一些可靠的来源;如果连大语言模型(LLMs)都能理解这一点,那这真的是一般常识!

            其他物种的生物学结构不允许进行肛交,因为它们根本没有肛门……

            现在这里的人可以自由地通过继续给事实点赞来暴露自己是不懂事的傻瓜。(这个子版块确实以这一点而闻名。人们经常给客观事实点赞,只是因为他们无法接受这些事实……)

            • skilking says:

              我们不是在对客观事实进行负面评价,而是在对你的态度以及你发表的言论没有为讨论增添任何价值进行负面评价。

            • RiceBroad4552 says:

              “这场讨论”已经被家长的评论带离了任何合理的轨道。

              还是说你实际上在声称

              是的,大多数物种都能进行肛交……这是否意味着一切都兼容?

              是严肃对话的一部分?

              一点也不好笑,也毫无意义

              我“只是”指出它“在事实上也是错误的”。

              为了更突出这个说法是多么荒谬,我用大语言模型(LLMs)作为“来源”。即使是最愚蠢的随机鹦鹉也“知道”一些东西,那么任何上过学的人也应该知道这些东西。

              但我可以告诉你为什么人们真的会对此投反对票:

              这里有不少人,尤其是这里,真的不喜欢“并非一切都兼容”这个事实,尤其是同性个体的生物学特征。最后一部分才是真正引发仇恨的原因。有些人真的不喜欢听到这个客观的生物学事实。

            • Sergenti says:

              哦,我明白了,你的意思是你讨厌同性恋者。在一篇关于… 查看笔记 … Java

            • RiceBroad4552 says:

              讨厌同性恋者

              哈哈,这发展得真快。

              你可以放心,我不是在“讨厌同性恋者”。(实际上我曾经有一个同性恋的好朋友,在我搬到其他地方之前。)

              但你的反应只是告诉我,我对情况的解读完全正确:这里的一些“活动家”实际上是在“否认生物学事实”,因为他们无法应对客观现实。

              在一篇关于……的帖子上……查看笔记……Java

              如果你仔细看看,可能会发现是我的父母通过提出一些同性恋话题来偏离了讨论。

              我所做的只是陈述事实。而这些事实显然让一些人发狂了。

              无法应对现实只是这些人的问题,与我无关。

            • Lubiebigos says:

              你听起来像是在最令人讨厌的刻板印象的 Reddit 用户评论数据上训练了一个大语言模型(LLM),然后将其释放到世界上。

            • hicow says:

              我不是在“讨厌同性恋者”。(实际上,我曾经有一个同性恋的好朋友,在我搬到其他地方之前。)

              记住,孩子们,这是真正的、不带讽刺意味的“我不讨厌x,我最好的朋友就是x”在现实中出现。

            • Sergenti says:

              当然,伙计。请放心,我并不认为你是社会上的不适应者 🙂

            • ReadyAndSalted says:

              关键不在于你说什么,而在于你怎么说。你需要读懂气氛并匹配你回应的语气。他们显然是在开玩笑(你可以觉得不好笑,但它仍然是个玩笑)。这意味着你应该以同样的方式回应,例如:

              “如果你没有屁股怎么办?棋局已定,不信鸟的人”

              有人可能会回应说鸟是政府无人机之类的话。此外,你身上带着一种令人无法忍受的自命不凡的优越感。

            • RiceBroad4552 says:

              不,传播带有政治色彩的胡说八道不是“玩笑”。

              我实际上无法忍受胡说八道。

              如果它至少有趣,那还可以原谅。但它不是。

              而且,这里的人,尤其是这里的人,似乎对客观事实非常敏感,这让我真的很生气。

            • ReadyAndSalted says:

              快速提问,如果他说“大多数拥有肛门和阴茎的物种都能进行肛交”,那难道不是政治敏感的胡说八道吗?

              还有,谁让你当笑话警察了?如果大多数人认为这是个笑话,那它就是笑话,毕竟笑话是社会构造的产物。

            • Vegetable_Addition86 says:

              只要你足够努力地去想,任何洞都可以是肛门

        • shakypixel says:

          是什么让你去问大语言模型(LLMs)关于哺乳动物的问题,而不是直接引用你引用的内容,然后问它“对还是错”呢?

          • RiceBroad4552 says:

            只有哺乳动物才有类似于“专用”肛门的东西。

            大多数物种都没有。

            但这又是基本的生物学知识了……

            不过我还是尝试了你的建议,结果喜忧参半:

            ChatGPT 愚蠢至极,在回答关于哺乳动物和某些没有专用肛门、而是拥有所谓泄殖腔(如鸟类)的动物类别时,它没有回答关于“大多数物种”的问题。显然这个话题是某个系统提示的一部分,旨在确保它给出“政治正确”的答案。

            克劳德拒绝回答。

            o4-mini 回答正确,因为它意识到根本没有那么多的物种能够做到这一点。

            Llama 也给出了正确的答案,并给出了正确的理由。

            一般来说,大语言模型(LLMs) 并不是一个好的信息来源,因为它无法提供其他适当来源无法提供的信息。因此,提出过于具体的问题(这些问题可能不会在互联网上被回答过数百次)并不是一个好主意。你会得到混杂、无意义或被操纵(系统提示!)的答案。你只能向大语言模型(LLM)“询问”广为人知的事情。例如,哺乳动物(唯一具有专门肛门的动物)只是所有物种中的一小部分。

            • MBussard45 says:

              你只是进入帖子寻找使用大语言模型(LLMs)的理由吗?因为这就是我在这里感受到的。我们明白你的意思,你可以把半生不熟的想法打进去,然后得到一些冗长的文字来伪装成一个知识分子。在大语言模型出现之前,人们就已经在这样做了。

        • belunos says:

          我猜你在派对上一定很有趣。

          • RiceBroad4552 says:

            因为我听说过一些生物学基础知识?我看不出来有什么关联

            • belunos says:

              你不是英语母语者,还是讽刺对你来说毫无意义?

            • RiceBroad4552 says:

              我不是英语母语者,但这不应该相关。人们说我的英语水平不错。

              整个“对话”毫无意义。有人为了搞笑而说了完全错误的话。我说这完全没道理,因为这是事实上的错误。

              我把一些大语言模型(LLM)的输出放在那里,稍微挑衅了一下。现在大家疯狂了……

              其实这根本不是挑衅。但至少现在我知道什么会引起强烈反应了。对于一场毫无意义的“对话”来说,这结果也不算太糟。😂

              (我不知道现在是谁因为你提问而给你点赞,但肯定不是我。)

            • undefined says:

              [deleted]

            • MBussard45 says:

              这家伙简直无法无天,说实话。

        • StunningChef3117 says:

          你没看错,上面写着“包括植物、动物、真菌和微生物”。显然,无法进行肛交的生物种类比能进行肛交的动物种类更多。这难道是故意为之?如果是的话,请别让我曝光,只是为了恢复对人类的一点希望。

          [编辑]

          我的评论太过严厉,原评论确实提到了“物种”而非“动物”。我仍然认为,考虑到我们讨论的内容,将几乎所有生物都包括在内是一种不诚实的表述。

          • RiceBroad4552 says:

            父评论说“大多数物种”(我理解为“大多数物种”)。

            “大多数物种”包括“植物、动物、真菌和微生物”。

            如果父评论说“哺乳动物”的话,这个说法会更有趣。在这种情况下,我不知道它是真实还是虚假。

            如果该说法涉及“动物物种”,我认为它仍然是错误的(因为昆虫和微生物的种类实在太多)。但在这种情况下,需要更充分的论据和可靠的来源来证明其错误。

            但我并不确定是否完全理解你的评论。

            • StunningChef3117 says:

              我已经添加了编辑,但总结一下。我承认我的评论过于严厉,坦白说有点尴尬,所以我诚恳地道歉,我觉得我应该暂时远离Reddit。但无论如何,我自动将上下文(肛门)解读为动物,而这需要一个肛门。但你说得对,实际上并没有明确说明。总之,抱歉,祝你在网上度过愉快的一周。

            • RiceBroad4552 says:

              我应该暂时离开Reddit

              哈哈,我刚才也在想同样的事情。

              总之,我道歉

              因为在某个(或多或少)“匿名”的互联网论坛上发表了某个随意的评论?

              明天没人会记得……🤣

              而那些把这种事情当真的人,比如我让尴尬的人,可能应该尽量避免上网。

              今天的“受监管”互联网,也就是被审查的互联网,与审查成为常态之前相比,已经非常平静了。那时候你需要非常厚脸皮。

            • StunningChef3117 says:

              我不是说我感到冒犯。我是说我评论中那种攻击性和不礼貌的态度。我没有被你的评论冒犯,而是对Reddit如何腐蚀了我在线上与人交流的方式感到尴尬和惊讶。虽然你可能认为这毫无意义,但我仍然认为有礼貌的对话更令人愉快。正如我所说,我没有主动发起对话,因此需要暂停一下。

            • RiceBroad4552 says:

              虽然你可能认为这毫无意义,但我仍然认为有礼貌的对话更令人愉快。

              这确实更令人愉快。

              但总体而言,这没什么大不了的。在这个子版块里,很少有有意义的对话。所以最终结果是:¯_(ツ)_/¯

              有时确实有值得交谈的人。

              但大多数人并非如此,这就是现实。

              至少我学会了一种撰写极具吸引力的恶搞帖子的有效方法——如果我将来有此需求的话……^^

              无论如何,如果你觉得有必要,就享受你的“数字排毒”吧。

        • BigArchon says:

          兄弟,你在派对上一定很受欢迎 /s

    • tanjonaJulien says:

      就像COBOL一样,迁移成本太高

      • RiceBroad4552 says:

        迁移到哪里?而且为什么要迁移?

        没有哪个企业软件生态系统能像JVM一样丰富。

        而且整个JVM领域仍在不断演进,现在甚至以相当快的速度发展,同时非常重视向后兼容性。

        没有任何东西能取代JVM生态系统!

        因此当然没有人会迁移到其他地方。互联网和其他商业场景中的所有重型工作都是在JVM上完成的;这自有其原因。

        • tanjonaJulien says:

          从Java 8到Java 25,就像那个梗说的,是时候去感受一下草地了

        • MattieShoes says:

          那么,为什么呢?

          因为去他妈的甲骨文。

          • RiceBroad4552 says:

            Java 是开源的。遵循 GPL 协议。

            在使用 Java 平台时,你无需直接接触任何甲骨文的相关内容。

            另一方面,甲骨文为 Java 的开发提供了资金支持。我认为间接接受他们的资金并关心其他事情是可以的。至少他们做了一件对他人有益的事情。因此,在这种情况下,对甲骨文没有问题。

      • kvakerok_v2 says:

        我敢打赌你找不到比COBOL更快的替代品(你找不到)。

        • Ok-Scheme-913 says:

          COBOL主要不是以速度著称——Fortran更有可能在你的现代系统上作为一些低级数学库运行数值算法,而COBOL则不然。

          COBOL更可能在你的银行运行,Tesco也有很多系统仍在运行。因此,它与Java的相似之处在于业务应用程序,但仅此而已。COBOL是一条死胡同,而Java比以往任何时候都更好。

  4. elreduro says:

    我在2019年学习Java 8。我认为它在短期内不会消失。Java 8在旧编程语言版本中相当于新的COBOL。

    • lart2150 says:

      从Java 8到Java 21的兼容性问题并不多。我遇到的唯一问题是加密更改,因为我的项目与一个使用糟糕加密套件的嵌入式系统通信。

      • Shoddy-Pie-5816 says:

        我的意思是,雅加达(Jakarta)的变更可能导致大量导入和语法问题。如果你使用 Spring 或 Spring Boot,也会有一些较大的变更。我已经在 Java 8 和 Spring 框架上工作了几年,我们正在考虑升级到 LTS Java 17。对于像我们这样的庞大遗留系统,我们认为这将带来几个月的时间来处理这些变更。我认为这还取决于你使用的Java工具链。因为许多依赖项对Java 8有最终支持版本,需要仔细审查并更新。仅就我而言,我估计自己将陷入重构地狱数月之久。

        • mon_iker says:

          如果你运行自己的Tomcat服务器(而非Spring Boot自带的),Apache提供了一个便捷的转换工具,可在打包应用时将javax转换为jakarta。我们几年前曾使用该工具将20年前的Spring应用迁移至Java 17。

        • Mujutsu says:

          对于我们来说,从 Spring Boot 2.x 迁移到 Spring Boot 3.x 是一个巨大的变化。Java 升级其实并不是什么大问题。

          • Shoddy-Pie-5816 says:

            可能确实如此。我们使用 Spring 框架时,有很多脆弱的自定义配置用于与其他遗留系统(如 COBOL、RPG 等)集成。我不是说这很好,只是事实如此。

        • _PM_ME_PANGOLINS_ says:

          这并非 JDK 的组成部分。你可以单独升级它而不影响其他依赖项(尽管你可能需要将所有组件升级到受支持的版本)。

        • 7cans_short_of_1pack says:

          我们刚刚完成了从 Spring Boot 2.1 到 2.5 的升级,以及从 Java 8 到 17 的升级,目前正在逐步推进升级工作。我最初以“业余爱好”的方式,从我们较小的服务之一开始升级到2.5,并指出这是为了安全升级而必须完成的。最终管理层认可了这一举措,我们现在几乎在生产环境中全面采用了Java 17。我们计划继续升级到2.7,然后是Java 21,最后是Spring Boot 3.0。虽然已经过去了4个多月,但我们正在逐步实现这一目标。

          • Shoddy-Pie-5816 says:

            我坦白说,短期内我们可能无法实现这一目标。我们团队规模较小,且有太多新业务需要开发。但我希望能够安排一个人专门负责此事,因为新版本中有些不错的质量提升功能值得尝试。不过,现有系统已变得过于庞大,除了那位苦苦支撑了12年的可怜人外,没人愿意触碰它。

      • dmlmcken says:

        Jnlp在后续版本中还支持吗?

        我仍在使用版本8来运行Dell iDrac。

    • Organic_Pineapple_73 says:

      我在2024年启动了一个项目,当我审查一段代码时,开发者说“这是Java 8”

  5. Devatator_ says:

    Minecraft一定是采用新Java版本最快的项目之一。我们目前使用Java 21,除非他们又升级了

  6. SSUPII says:

    在任何搜索引擎上搜索“Java下载”都能得到32位Windows Java 8的结果,这说明了很多问题

    • Ascend says:

      真正的原因是——Java 8是最后一个面向最终用户安装的版本。新应用程序预计会自带JRE。这就是为什么没人再安装Java了。

      • RiceBroad4552 says:

        有趣!今天学到的新知识

        Windows和Mac用户真的很可怜。每个应用程序都附带一些冗余组件,这些组件从未获得过安全更新,而现在JVM也出现了这种情况。

        即使我的系统上已经安装了各种受支持的JDK,当某个工具试图在背后下载JDK时,我已经在Linux上感到愤怒。

        我希望Linux发行版在拆分应用程序时仍能做得很好,因为Oracle的理念会导致安全问题;此外,这还会让人们只针对一个JRE版本进行测试,这非常糟糕。

        • Ok-Scheme-913 says:

          我的意思是,这基本上就是其他应用程序的打包方式——就像你不会抱怨Go将整个胖运行时包含在二进制文件中,甚至没有手动更改它的方法。

          Java可以优化(参见jlink)这个过程,只包含一个模块化的“JRE”,其中只包含应用程序实际使用的模块。

          但总体而言,以一种不依赖JDK的方式打包每个应用程序在一定程度上是不可行的,到了某个阶段,应用程序应该能够自由锁定其依赖项,否则就无法实现可扩展性。

          我个人认为Nix方法效果最好,其他包管理方式都是遗留系统,从未真正发挥过良好作用。

      • TheCorruptedBit says:

        Minecraft 在 Linux 上 🙁

    • RiceBroad4552 says:

      你在说什么?

      也许这是你的个性化结果,但这并非普遍情况。

      • SSUPII says:

        看起来他们开始链接完整的下载页面,而不是仅限于 32 位 Windows

        仍然是Java 8

        • RiceBroad4552 says:

          现在我明白了。

          你是指这里的SEO垃圾信息吗: ?

          (我通常会忽略顶部的“推荐”网站。下面的内容看起来还算合理。)

          嗯,那实际上是甲骨文旗下的网站,看起来是这样……

          这确实看起来很奇怪。

          • SSUPII says:

            它一直由甲骨文拥有

            他们对推动Java新版本发布毫无作为,反而希望人们继续使用8分支(该分支至今仍在接收安全补丁),除非必要。

            • Ok-Scheme-913 says:

              为什么他们对推动新版本发布毫无作为,当…… 甲骨文雇佣了开发新版本的开发者?就像,关于Java有太多愚蠢的观点,天啊

            • RiceBroad4552 says:

              是的,我也一直在想这个问题。(我从未通过谷歌搜索如何下载Java,因为我通过包管理器就能获取所有内容;你知道的,“Linux大师种族”之类的说法。😃)

              甲骨文在这里到底在想什么?

              我的意思是,他们早就放弃了桌面Java,但他们真的不在乎,甚至向最终用户推广“过时”版本,这似乎很奇怪。(过时是指技术意义上的,而不是安全补丁方面。)

              总之,你的原话似乎有道理,看到那团乱麻后,我也很困惑!

            • Ok-Scheme-913 says:

              正如其他评论者提到的,现在已经没有所谓的JRE了。作为应用程序发布者,你需要“自带”JRE,这样可以根据你的具体使用场景进行优化。这个“迷你JRE”会以某种方式与你的应用程序捆绑在一起,并一起发布,只包含必要的JVM模块。例如,你的命令行应用程序不会包含Swing等组件。

            • SSUPII says:

              遗憾的是,几乎没有人这样做。

              他们要么直接使用Java 8,要么引导用户安装相应的OpenJDK(在某些情况下,我见过应用程序直接捆绑整个JRE进行分发)。

      • 0r0B0t0 says:

        第一个结果是使用Java 8,我使用了无痕浏览窗口。

        • sai-kiran says:

          2025年在编程子版块,我不得不说这个XD。
          无痕模式不存储历史记录,并不意味着你拥有不同的指纹。

          能否检测到使用无痕模式或VPN的用户?是的,在大多数情况下,我们能够唯一识别网站访客,即使他们使用无痕模式或VPN。这是因为我们在为访客分配唯一标识符之前,会分析超过100个信号。即使某个信号(如IP地址)发生变化,我们仍能实现高准确度的识别。

      • kvakerok_v2 says:

        这是我获得的结果:

        版本 8 更新 451

        而我甚至不再使用 Java 8

  7. average_turanist says:

    Java 8 是一种奢侈品。

  8. Budget_Avocado6204 says:

    我们最近从 Java 8 升级到了 Java 17

  9. Afraid-Cancel2159 says:

    就连我之前的团队在生产环境中仍在使用Java 8。真的。

  10. Piotrrrrr says:

    我记得我大学里有个学生向教授抱怨,几乎要气炸了,说教授教我们Java 8而不是刚发布的Java 11

  11. Never-asked-for-this says:

    试试1.6吧。

  12. TheSpaceCoffee says:

    然后就是我的公司,我们有一个由承包商提供的封闭环境,使用RH8。

    默认使用Python 3.6。

    没有通过打包的可执行文件提供我们自己的工具的选项,这些工具使用其他版本的Python。

    没有安装Docker,也没有安装它的选项。

    • RiceBroad4552 says:

      我感同身受!

      但他们会说类似这样的话:“但它其实相当新,只有大约7年历史,且支持将持续到2029年中期,所以没有理由去修改一个正常运行的系统。”

      我讨厌任何LTS版本!它们只会阻碍进步,迫使你维护“几十年”前过时的垃圾。就他妈的保持系统更新吧。早发布,常发布!这就是保持维护成本低、减少意外问题、让开发者满意的方法。每隔10到15年升级一次是最大的错误,总是带来巨大的痛苦和大量问题。这就是为什么旧系统根本不升级。这太难了!然后每个人(我指的是愚蠢的管理层)都在担心所有这些“遗留系统”的成本……

      • SN6006 says:

        我有多个生产工作负载面临同样问题。供应商提供X框架,拒绝在同一版本分支内支持升级(如Java 8、PHP 8.0等),并要求“付费升级”

        • RiceBroad4552 says:

          是的,你必须为更新付费。这是有人必须完成的工作。

          但关键是:如果你等待,最终的总成本会高得多,因为在10年后安全更新结束时,升级将被迫进行。升级古老系统非常昂贵(因为工作量巨大;你必须从落后当前技术十年中恢复过来),而且尤其“风险极高”。没有什么比“大爆炸式发布”更冒险了!

          因此,支付所有较小的更新(最好作为你必须拥有的维护合同的一部分)在我看来比等待更便宜。你迟早都要付钱。只是会更晚一些。

    • wolfnest says:

      这听起来很像我认识的某家EDA工具供应商。

  13. AndiArbyte says:

    切换到新版本Java:所有你的代码都会被废弃哦。

    • RiceBroad4552 says:

      你真的用过Java吗?我不确定……

      Java不像PHP,更新后一切都会崩溃。

      Java确实有废弃功能,但非常罕见,而且需要几十年才会真正移除……

      • sathdo says:

        这是现代版本Java的特点。从8到9,以及从10到11的升级,涉及大量企业级功能的破坏性变更,如JAXB和Servlet API。自11版本以来,只要使用LTS版本,升级过程就相当顺畅。

        来源:我曾更新一个2014年编写的企业级单体应用,该应用大量使用了JAXB和Servlet API。转换代码耗时数月。公司甚至在我被裁员前都没部署我的代码,因为运维团队不愿在每台服务器上手动安装Java(该应用未容器化)。

        编辑:如果破坏性更改仅影响你直接控制的代码,这些更改可以轻松处理。如果你有一个需要在8和11之间发生破坏性更改的库的旧应用程序,那将是一个大问题。根据我的经验,最严重的罪魁祸首是Drools(垃圾库;永远不要使用)、Spring、Mockito和Powermock。

        • Ok-Scheme-913 says:

          存在大量兼容性变更

          有两个列表,其中实际上存在脚本可自动修复所有问题。你可能还需要升级两个版本。比如,Word 文档的兼容性问题都比这更严重。

          • RiceBroad4552 says:

            我认为家长说得对。EE Java 的所有部分在过渡到 Jakarta 时并未完整无缺地保留下来。

            但这并非语言层面的问题(包括标准库)。

        • _PM_ME_PANGOLINS_ says:

          Servlet API 甚至从未是 JDK 的一部分,其破坏性更改可以通过全局查找替换来修复。

          Java 中唯一的破坏性更改是 JAXB 被移至独立依赖项,这只需几秒钟即可修复。

      • TigreDeLosLlanos says:

        这让我好奇为什么PHP如此迅速地放弃对旧版本的支持。语言的演进固然可喜,但他们宣布新主要版本的时间,恰好是新项目开始使用最新版本并最终投入生产环境所需的时间。他们已经在5/6年的间隔内发布并放弃了对两个主要版本的支持。

        • RiceBroad4552 says:

          我认为这是试图“修复”语言(尽管这在一般情况下是不可能的)。

          如果需要无限期支持某些已知问题,修复起来非常困难。因此,我认为PHP会尽可能频繁地淘汰旧功能。

          但确实,这让我当时非常恼火,不得不与这个垃圾打交道。即使在次要版本之间,功能也会出现故障。而且没有静态类型系统可以告诉你到底哪里出了问题。更新PHP项目因此成为一场噩梦。

          真幸运我已经脱离了那个环境!

      • SN6006 says:

        我有一个生产工作负载卡在8u171(或更早版本)上,我尝试沿着8个版本进行升级的每一次尝试都遇到了崩溃和错误。供应商毫无用处且不支持更改,这更糟糕。

      • AndiArbyte says:

        是的,当然,但我不是在说从24到25,而是相隔15个版本,这可能是个大问题:D

        • RiceBroad4552 says:

          说实话,我不记得有过重大废弃功能。

          会影响少数人的是移除了安全管理器且未提供替代方案。这确实是个打击,但仅影响极少数人。

          此外,Java 24开始因使用sun.misc.Unsafe而频繁提示警告,尽管该类仍可使用,但很快将被废弃,这将给大量遗留软件(或更准确地说,它们所依赖的库)带来问题。

          除此之外?过去十年中最大的兼容性变更是什么?

        • Ok-Scheme-913 says:

          不。最大的破坏性变更发生在8到9之间,以及9到11之间——而这两者在Java的庞大体系中都只是微不足道的变化。

          此后应该再也不会出现任何问题,除非你像个白痴一样不安全地访问JVM内部。

    • Ok-Scheme-913 says:

      这简直是一派胡言。

      我可以用一个.jar文件在任何操作系统上运行30年前编写的图形应用程序。在二进制和源代码格式下,没有任何其他平台在向后兼容性和向前兼容性方面能与Java相提并论。

      • RiceBroad4552 says:

        嗯,说到源代码,情况并不像你说的那么好。你很可能无法用当前的JDK编译30年前的一些代码。

        但说到二进制兼容性,Java平台确实非常出色。(但公平地说:几乎没有人做二进制兼容性。所以在这方面做到出色并不难。)

        • _PM_ME_PANGOLINS_ says:

          你很可能可以。一切仍然正常工作。

          • RiceBroad4552 says:

            胡说八道。源代码级别上已经出现了足够多的兼容性问题。

            如何使用现代JDK编译Applets?

            安全管理器呢?

            AWT中的内容?

            “strictfp”呢?

            受检查异常?

            终结器?

            新增的关键词(如“enum”)是否会与旧代码冲突?

            或者看看Thread::stop()的当前实现。它看起来像:

             @Deprecated(since=“1.2”, forRemoval=true) public final void stop() {    throw new UnsupportedOperationException(); }

            这些只是随机的一些例子。实际列表非常长!

            这些都是细节,但你的30年前的代码(即Java 1.0)肯定无法在不修改的情况下编译。

            • Ok-Scheme-913 says:

              我的意思是,其中许多是相当具体的库级别的更改,因此我不确定有多少代码实际上包含这些更改,但确实,并非所有30年前的代码都能直接编译通过,而更强烈的说法是它们是否能以相同方式运行,这在每个案例中都无法保证。但绝大多数代码既能编译通过又能以相同方式运行。

              安全管理器只是最近才被废弃,所以仍然有效,AWT 仍然有效,strictfp 在现代 Java 中没有作用,但仍然是一个有效的关键字,所以它会编译得很好。

              已检查的异常没有变化,不确定你指的是什么。终结器不受欢迎,但仍然有效。不确定是否所有新关键字,但记录和变量是上下文相关的,因此你实际上仍然可以将它们用作变量名,因为它们在该上下文中是有效的。Thread.stop 已被废弃近 30 年,但仍未被移除!我认为这比你的说法更能支持我的观点。它可以编译(即使无法以完全相同的方式工作)。

            • RiceBroad4552 says:

              这是相当具体的库级别的更改

              这是什么借口?

              API 发生了变化,旧代码在未经修改的情况下无法编译或正确工作。

              声称“一切仍然正常工作”。不,它并不工作。(实际上,即使有一个反例就足够了,但我们有相当多的反例)

              非常最近被废弃

              这无关紧要。

              它在没有大规模重构的情况下会编译失败。

              AWT 工作

              API 被移动和更改了。

              因此,代码在未经修改的情况下无法工作。

              strictfp 在现代 Java 中不起作用

              这无关紧要。它被添加到了一些标准库API中,但这发生在v1.0之后。因此,使用更改前原始API的旧代码将无法编译。

              即使无法以完全相同的方式运行

              是的,当然。立即抛出异常就是“一切照旧”,对吧?

              如前所述,有许多例子。另一个随机例子:

              此后甚至出现了更多!

              如果“一切仍正常工作”在一般情况下成立,那么没有人会抱怨 Java 更新,所有人都将使用最新版本,因为无需进行迁移工作。

              Java 在向后兼容性方面确实出色。但他们并非魔法师。每次更新都需要特别处理某些问题(而随着 Java 开发速度的加快,这些问题在我看来反而更多了)。

              刚刚在这里看到这个,其中甚至有一些我从未听说过的例子:

              https://www.reddit.com/r/java/comments/nyre4k/break_backward_compatibility/

              所以这个列表比我预期的还要长。

            • Ok-Scheme-913 says:

              没有人说过数学上的陈述,即对于∀x(x仍然可以编译并以等效方式运行),主题是Java具有异常良好的向后兼容性,这被表达为人类陈述,即一切都可以原样编译。此外,由于Hyrum定律,即使是完全向后兼容的更改,仍会在运行时表现出变化,至少在执行速度上会有所不同。

              另外,严格来说,strictfp仍会编译通过。

      • AndiArbyte says:

        你听说过夸张吗? 🙂

  14. marqless says:

    我们刚刚将最后一个生产环境升级到 Java 11

  15. fabkosta says:

    我听说 Java 25 现在有一个 AI 功能。它可以自主编程。

    这是真的吗?

    • Never-asked-for-this says:

      是的。Java 25实际上与Java 8类似,它将再次进行品牌重塑。

      现在它被称为JAIva 25,并引入了一个新的虚拟机,名为JVLLMMLM

  16. Meta_Storm_99 says:

    我听说他们还升级了网站

  17. Rivilen says:

    Java 7团队报到

  18. GotAir says:

    我们刚刚签署了一份为期五年的合同延期,继续使用基于Java 8的第三方软件,而不是升级到需要Java 17的新版本。时间不够用!

  19. Precorus says:

    你们用Java吗?我们还在用Smalltalk!

  20. Enough-Scientist1904 says:

    我的系统在Java 8上运行了9年,它将在8月随Java 8一起终结

  21. lukocat says:

    Java 8 是个噩梦。就像那些讨厌 Java 的人说的一样,Java 8 确实存在这些问题。

    • zackwag says:

      大多数讨厌 Java 的人只是因为它不是 Go 而生气,他们还引用了 Java 5 时期的论点。

      • Ok-Scheme-913 says:

        我的意思是,我宁愿使用Java 5而不是Go。它基本上被宣传为相同的东西(一种简单语言,即使很多人一起使用也不会出错),只是其中一个至少有合理的错误处理(不是由谷歌开发的那个)。

  22. FurySh0ck says:

    哦,我多么喜欢在进行PT时遇到过时的Java服务。这是一个简单的根/系统shell

  23. Puzzleheaded-Ad-4698 says:

    刚在另一个子版块看到这张图。人们已经把它当作梗来用,真是搞笑

  24. private_final_static says:

    看看你用这些花哨的泛型和乱七八糟的东西

  25. rjwut says:

    自Java 8以来,内存管理方面已经有了重大改进,我认为这值得你升级。今年JavaOne上的这场演讲详细介绍了这些内容。

  26. Popular-Departure165 says:

    现在是Kotlin了吗?

  27. clarinetJWD says:

    .Net Framework 4.6.1永恒!

  28. Darklordoverkill says:

    我只有一部搭载Java的诺基亚3410

  29. Equivalent_Decision2 says:

    已确认

  30. MagicalPizza21 says:

    同样的情况。我们有一些用户可能使用的是与新版Java不兼容的旧电脑。

  31. akoOfIxtall says:

    从C# 12降级到4.8的模组制作者:

  32. SerialElf says:

    不不,最好的部分?Java 8仍然是官方Java网站上的第一个搜索结果

  33. Buttons840 says:

    为什么公司仍然停留在如此旧的版本上?你的故事是什么?

    在我自己的工作中,不使用Java,我观察到存在一些技术问题困扰着每个人,但公司文化就是无法解决它们,永远无法解决。比如,我们会抱怨一个问题,也许每隔几个月,技术领导者会谈论如何解决它,但解决它从未真正发生,几年、几十年甚至更长时间过去了,组织就是无法超越某些技术问题。

    而且这些问题非常愚蠢,比如我想到的那家公司就是因为创始人写了一个糟糕的 Ruby 脚本,通过分隔逗号来解析 CSV 文件。这并不是解析 CSV 的正确方式。公司发展壮大后,系统中到处都是 bug,因为我们的系统会遇到包含逗号的数据。这种情况持续了多年!我一直主张修复这个问题,我试图向人们解释,有合适的CSV解析器存在,但没人关心。大家太忙于做风险投资公司给我们数百万美元去做的事情。我最终告诉自己,如果一年后我还在修复CSV解析的bug,我就离开。我在那里待了三年,但我们从未创建一个能正确处理逗号的系统。公司领导可能至今仍认为CSV解析是活跃的研究领域。

    Java 8的情况也是如此吗?

  34. AgentCooderX says:

    25?? 我的简历里还写着Java 2……我的背都疼了

  35. spandexvalet says:

    如果你停留在旧版本,就不需要向后兼容性。

  36. AllMyNamesWasTaken says:

    哦哦哦哦哦哦哦哦哦

  37. InvestingNerd2020 says:

    我一直赞扬那些在Java 17之前就放弃旧版本Java的组织。是的,Java开发者薪资不错,但他们在Java 8中不得不忍受的那些垃圾导致了反创新心态。为了人类的进步,升级到Java 17或更高版本吧!

    抱怨够了。接下来是“Shake it the max”视频。

  38. Not_Artifical says:

    我被告知可以使用任何版本的Java,所以我使用了Java 8和Java 12。我为每个其他项目切换了版本。

  39. bestofalex says:

    Java 8的扩展支持将持续到2023年,而Java 25的扩展支持仅持续到2033年。因此,除了使用便利性、修复安全漏洞、新增功能等优势外,升级几乎没有其他实质性收益。

  40. Illeprih says:

    我还在等待版本250将向量API从孵化阶段移出

  41. DanhNguyen2k says:

    你们用Java吗?

  42. Striking_Baby2214 says:

    像老板一样。😂

  43. edtheshed says:

    一个新的老梗!不错

  44. revolutionPanda says:

    作为去年才开始使用Java的人,最新版本与生产环境中广泛使用的版本之间真的有很大区别吗?

  45. SicgoatEngineer says:

    这就是方式

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注