一次编写,到处运行 - 但是能持续多久?

4

Java提出了“一次编写,到处运行”的理念。

如何在长期使用中处理所有框架的技巧?

我几年前用JSF和richfaces编写了一个应用程序。浏览器已经发展并引入了新功能,当然也带来了新的错误。现在该应用程序仍在运行,有时会显示底层库中的javascript错误。

我们真的需要重新实现已完成的应用程序(没有要添加的用例)以适应技术的“改进”吗?

编辑:我提到的应用程序只是一个例子。如果供应商更改许可证,同样的事情很容易发生。(例如Oracle可能会对虚拟机收费,而开放的虚拟机与您的应用程序堆栈不兼容等)


1
社区维基复选框发生了什么事? - stacker
你能举个例子说明你遇到了哪些JavaScript错误吗?我的意思是,它们是否影响应用程序的功能,还是只是令人讨厌的? - Jeremy
2
公平地说,“一次编写,到处运行”适用于Java语言,而不是无关的(尽管名称相似)Javascript脚本语言。 - user2043
1
这就是网络的本质。它在不断发展。如果你想让一个程序在20年后仍能运行,就用C语言编写,并保留源代码以便重新编译。 - Falmarri
@Andrew 我完全同意,但是这个模式重复了多少次?你在Maven中有多少依赖关系? - stacker
显示剩余7条评论
4个回答

4
即使我们相信“一次编写,到处运行”,但这并不完全等同于永久的向后兼容性。实际上,你必须预期未来版本的框架会改变一些东西。有时,这将是删除了曾经保证的行为(最糟糕的更改类型),其他时候,你的代码中的错误将在某个未来版本的库中暴露出来,因为你依赖的实现细节并未得到保证。更少见的情况是,你的旧代码将在最新版本中揭示一个新颖的错误。
在理想的世界里,我们会编写仅依赖于保证行为的代码,并且保证永远不会被删除,因此有效的代码将永远工作。然而,在现实中,很难证明你的程序是完全正确的,语言/框架/库开发人员会做出决策,即他们是否可以添加他们想要的改进,同时保持完美的兼容性。
为了让兼容性获胜,原始API必须足够强大和稳定,以在没有破坏性更改的情况下生存下来。如果它不是这样,那么就会进行不兼容的更改,否则API将被完全放弃。无论哪种方式,除非你有一个旧版本可以运行它,否则你的程序将无法运行。
你问如何做到这一点 - 它要求在第一次进行接口设计时非常好且有些幸运,以允许稍后出现的所有扩展,或者有坚定的承诺和“商业案例”(或非商业动机)来支持“旧”版本。例如,Python 3与Python 2不兼容,但Python 2仍然得到更新的积极支持,因此旧的Python代码仍然可以运行。C99仅删除了C89的一些功能,如果其他所有方法都失败,则C89编译器仍然得到积极维护。浏览器支持HTML的一千零一种旧版本和非标准怪癖。我不知道JSF和richfaces与这些相比如何,或者它们输出依赖于客户端对“旧”(或古怪)HTML / CSS / Javascript行为的支持的页面有多少。
因此,至少在一段时间内,这是可能发生的。但是,在任何安全发布到Web的浏览器中,都没有IE6功能可用(我猜你可以在沙盒VM中运行IE6,或者在你不关心的机器上运行),所以问题在于你最初所依赖的东西。可以预测到专有浏览器扩展将在未来版本中被放弃吗?可能,但那些IE6应用程序编写者是否可以使用当时可用的适当标准来实现他们想要的内容?并非总是如此。即使对于那些没有涉足IE6的人,如果你的应用程序陷入类似的陷阱,你就会很倒霉。

非常感谢您提供这个精彩的答案,我的结论是(由于您的Python/C部分),要么您拥有庞大的社区,要么您应该自己做出贡献。对我来说这没问题,因为它是免费的。 - stacker

1

我认为没有人能真正承诺“无论何时何地都可以运行”。迟早 Linux、Windows 和 MacOS 都会过时,新的操作系统会出现,而且没人会费力去为它们写 JVM,这样你所有的 Java 应用程序将不能再运行。(我有一款老的 MS DOS 游戏,我认为它非常酷,但是它在 Windows DOS 环境下不能运行。该公司推出了一个 Windows 版本,但他们彻底重新设计了游戏,并且在我看来破坏了原有的乐趣。很遗憾。)

同时,新版本向上兼容是一件好事,但供应商偶尔决定这太麻烦了。


+1 我曾经遇到过同样的问题,我编写的“虚拟现实”引擎因为Windows不再允许DOS全屏模式而被弃用。 - stacker
1
@stacker:你可以试试http://www.dosbox.com/。它模拟整个x86,包括DOS,并在其中运行你的DOS程序。不需要像你所说的那样去折腾这些新潮的概念,比如“Windows”和“弃用”! - Steve Jessop
@Jessop:嘿,也许我会看看我是否还有那张光盘。这个Windows东西只是过眼云烟而已。 :-) - Jay
@Steve Jessop,一些公司仍在运行几乎未经改变的COBOL代码,已有30年左右的历史。如果你编写一个Web应用程序,你将花费一半的生产力来进行维护(假设你有相当多的这样的应用程序)。这是相当昂贵的。 - stacker
@stacker:这就是30年不更改需求文档的好处。即使忽略了底层依赖关系的变化,对于大多数Web应用程序来说,这更像是30分钟的事情;-) - Steve Jessop

0
似乎你说的不是应用程序而是小程序(因为提到了JavaScript)。此外,这是一个从部署页面调用JavaScript的小程序。在这种情况下,它并不完全是纯Java。这听起来像是使用Runtime.exec()调用平台相关的命令行,然后更改操作系统并抱怨应用程序无法工作。
或者我可能没有正确理解您的用例?

0

编程语言和技术在不断发展。一般来说,如果一个Web应用程序相当基础,它可能能够进行更新而不需要太多的更改。

基于Java的语言似乎比Microsoft堆栈中的语言更新频率低。然而,JSF 2与之前的版本相比有一些重大变化,而Richfaces 3.x应用程序将需要迁移,如果您想使用Richfaces 4.x。

作为解决方法,您并不总是需要升级;还有很多使用旧语言(例如经典ASP)编写、部署并仍然正常运行的网站。


网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接