说服客户升级到 Java 5

发布于 2024-09-17 17:20:48 字数 877 浏览 7 评论 0原文

我们向一些客户销售打包的 Java Web 应用程序。它基本上是 servlet、一些 SOAP Web 服务和一些静态资源的集合。我们不做 EJB 或任何其他 Java Enterprise 奇特的东西。

我们的一些客户正在运行 IBM WebSphere Application Server v5.1,因此我们的运行时和开发仅限于 Java 1.4。当然,我们希望使用 Java 5(甚至更好的 Java 6)进行开发。在 1.4 中执行 SOAP 需要一个外部库(我们使用 AXIS,但它已经过时了)。我们不能使用枚举、装箱、泛型……找到 1.4 兼容的第三方库变得越来越困难。

目前,客户对这种陈旧但运行良好的设置感到满意。我们希望他们升级他们的 Java 运行时。在这种情况下,意味着升级到IBM WAS 6.1还是7.0?

我们能告诉他们什么?这对他们有什么好处?

到目前为止,我已经得到:

  1. 更好的性能,因为 JVM 在 Java 5 中效率更高(在 Java 6 中甚至更好)。但我无法给出数字。不确定 IBM VM 是否改进了很多(我们的一个客户端运行在 AIX 上)。
  2. 支持。 IBM WAS 5.1 只能通过特殊的扩展支持计划获得支持。

他们是大公司,因此他们提前一年多规划解决方案。他们今天选择了一个成熟的产品,并在几年后进行部署。该产品还有几个月的时间就将报废。

请参阅 IBM WebSphere Application Server 比较

We sell packaged Java web applications to some of our customers. It's basically a collection of servlets, some SOAP web service and some static resources. We don't do EJB nor any other Java Enterprise fancy stuff.

Some of our clients are running IBM WebSphere Application Server v5.1, hence we are limited to Java 1.4 for the run-time and the development. Of course, we would like to do our development using Java 5 (or even better Java 6). Doing SOAP in 1.4 requires an external lib (we use AXIS, but it's aging). We can't use enum, boxing, generics... It's becoming harder to find 1.4 compliant third-party libraries.

The customers are currently satisfied with this old-but-working-well setup. We would like them to upgrade their Java run-time. In this case, it means upgrading to IBM WAS 6.1 or 7.0?

What can we tell them? What's in it for them?

So far I've got:

  1. Better performance as JVM is much more efficient in Java 5 (even better with Java 6). I can't put figures on it, though. Not sure if IBM VM has improved a lot (one of our client is running on AIX).
  2. Support. IBM WAS 5.1 can only be supported through special extended support programs.

They are big corporations, so they plan their solutions more than a year in advance. They select a mature product today and they deploy it years later. The product then has a few months before being end-of-life.

See IBM WebSphere Application Server comparison

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(9

苍风燃霜 2024-09-24 17:20:48

Java 1.5 已于 2009 年 11 月 3 日终止生命周期。

因此,1.4 和 1.5 都不再受支持,这意味着没有安全修复。

所以基本上目前唯一支持的 Java 平台是 Java6(又名 Java 1.6)

Java 1.5 has reached end of life November 3, 2009.

So neither 1.4 nor 1.5 are supported any longer which means no security fixes.

So basically the only supported Java platform currently is Java6 (aka Java 1.6)

待"谢繁草 2024-09-24 17:20:48

你可以告诉他们他们的决定的成本。

如果他们继续选择 Java 1.4,那么添加新功能将花费 yyy 美元。如果他们升级,那么添加相同的功能将花费 xxx 美元。想必他们也有升级系统的成本。如果您可以向他们展示新版本 Java 节省的成本超过了他们升级系统的成本,那么他们就会发现升级可以节省资金。

显然,很难给出开发成本的准确值,但如果您可以估计,在较新版本的 Java 上,开发速度会快大约 30%(因此便宜 30%),那么您可以在以下位置得到一个粗略的数字:至少。

You could tell them the costs of their decision.

If they continue to choose Java 1.4 then adding a new feature will cost $yyy. If they upgrade then adding the same feature would cost $xxx. Presumably they also have a cost of upgrading their systems. If you can show them that the savings on the newer version of Java exceed the cost for them of upgrading their system then they can see that they will save money if they upgrade.

Obviously it is difficult to give exact values for the development costs, but if you can estimate that development would go for example roughly 30% faster (and therefore be 30% cheaper) on a newer version of Java then you can get a rough figure at least.

被你宠の有点坏 2024-09-24 17:20:48

首先,给定版本的 WAS 支持的唯一 SDK 是实际随产品附带的 SDK(换句话说,IBM 不支持在另一个 JDK 上运行 WAS,如果这很重要的话)。

其次,WAS 实际上甚至可能无法从更新版本的 SDK 启动(例如,WAS 6.1 不会从 IBM JDK 1.6 启动)。

  • WAS 5.1:J2EE 1.3,JDK 1.4.2
  • WAS 6.0:J2EE 1.4,JDK 1.4.2
  • WAS 6.1:J2EE 1.4,JDK 1.5
  • WAS 7.0:J2EE 1.5,JDK 1.6

因此,需要更新的运行时可能是大迁移的同义词: JDK 和应用程序服务器的资格认证、管理员培训、平台迁移、应用程序迁移、监控更新、部署工具、回归测试等。对于保守的大公司来说,这通常是一个复杂且极其缓慢的过程。

对于您的情况,您可以考虑对软件进行分支并提供不同的版本并且:

  • 仅对旧版本进行维护
    • 并为旧版本定义 EOL 日期(您无法维护它 Ad Vitam Aeternam)
  • 在新版本上提供新功能 仅
  • 在新版本上提供更激进的定价

您的客户必须有充分的理由采用较新的版本,它必须超过迁移的成本。

First of all, the only SDK that is supported with a given version of WAS is the SDK that actually ships with the product (in other words, IBM won't support running WAS on another JDK, if this matters).

Secondly, WAS might actually not even start with a more recent version of the SDK (WAS 6.1 won't start with IBM JDK 1.6 for example).

  • WAS 5.1: J2EE 1.3, JDK 1.4.2
  • WAS 6.0: J2EE 1.4, JDK 1.4.2
  • WAS 6.1: J2EE 1.4, JDK 1.5
  • WAS 7.0: J2EE 1.5, JDK 1.6

So requiring a more recent runtime will probably be synonym of big migration: qualification of the JDK and application server, training of admins, migration of platforms, migration of applications, update of monitoring, deployment tools, regression testing, etc. This is generally a complex and extremely slow process with big conservative companies.

In your case, you could maybe consider branching your software and offer different versions and:

  • only do maintenance on the old version
    • and define an EOL date for the old versions (you can't maintain it Ad Vitam Aeternam)
  • offer new features on the new version only
  • offer more aggressive pricing on the new version

There must be a good reason for your customers to adopt a newer version and it must out-weight the cost of a migration.

鼻尖触碰 2024-09-24 17:20:48

您开展业务是为了满足您的客户。他们需要(无论是真实的还是感知的)坚持使用过时的平台。

因此,说“是”,但让他们知道您计划在某个日期提高旧平台的维护和升级价格。这是一次完全合理的涨价;您需要维护专业知识和设备,以确保您的代码可以在旧的、不受支持且可能不安全的平台上运行。通过支持他们当前的基础设施,您可以为他们提供真正的价值。

庆幸您不是从事柴油发动机行业。如果是的话,您就会拥有大量拥有二战时期技术的客户。

You're in business to satisfy your customers. They have a need (be it real or perceived) to stick with an obsolete platform.

So, say "yes," but let them know you plan to increase your maintenance and upgrade prices for the old platform on a date certain. This is a perfectly justified price increase; you need to maintain expertise and equipment to make sure your code works on an old, unsupported, and conceivably insecure platform. You're delivering real value to them by supporting their current infrastructure.

And be happy you're not in the diesel engine business. If you were, you'd have plenty of customers with world-war-ii era technology.

凑诗 2024-09-24 17:20:48

去过那里......客户可能很固执。
我使用过 RetroTranslator(http://retrotranslator.sourceforge.net/) 和 Retroweaver(http://retroweaver.sourceforge.net/) 具有 Java 5 功能。但在性能方面却无能为力。

至于 Java 1.5/1.4 EOL,有针对 Java 客户的 Java for Business 计划 - 如果您付费,它们就不是 EOL...

Been there... Clients can be stubborn.
I have used RetroTranslator(http://retrotranslator.sourceforge.net/) and Retroweaver(http://retroweaver.sourceforge.net/) to have Java 5 features. Nothing can be done on the performance side though.

As for Java 1.5/1.4 EOL there is Java for Business program for Java customers - they are not EOL if you pay for them...

世俗缘 2024-09-24 17:20:48

告诉他们有关安全的信息。我不确定sun是否仍然提供旧版本的补丁(pavanlimo回答)。

Tell them about security. I'm not sure if sun still deliver patches for older versions (pavanlimo answer).

过度放纵 2024-09-24 17:20:48

虽然我同意给出的其他答案,但另一个考虑因素是您是否考虑过这种情况?您编写的应用程序是否能够与其他应用程序兼容?我担任系统管理员已经有一段时间了,我最大的抱怨之一是许多开发公司认为我们应该在准备好时改变我们的 IT 环境。当然,如果有 2 个或更多此类开发公司向我的网站提供产品,那么就会出现冲突。

您是否以这样的方式编写您的应用程序,以便我可以运行您选择的 Java 版本和(选择您的数字,但可能大于 2)我需要的其他 Java 版本(通常在同一台服务器上),以支持其他同样重要的应用程序?并且建议向后兼容性是无关紧要的 - 其他供应商不会支持我,除非我使用他们选择的版本。

While I agree with the other answers given, another consideration is have you considered there situation? Have you written the application in such a way that it plays well with others? I've been a system admin for a while now and one of my biggest gripes is the number of development houses that think that we should change our IT environment when they are ready. And of course if there are 2 or more such development houses supplying products to my site then there is conflict.

Have you written your app in such a manner that I could run your choice of Java version and the (pick your number but its likely to be greater than 2) other versions of Java that I require, usually on the same server, to support the other equally important applications? And suggesting backward compatibility is irrelevant - the other vendor will not support me unless I'm on their chosen version.

戏蝶舞 2024-09-24 17:20:48

也许是因为 Java 1.4 已于 10 月 30 日EOL 2008年。
因此,他们的安全可能会受到损害!

显示几个示例,其中安全性实际上因 Java 1.4 而受到损害。

在我看来,他们已经足够害怕了。

Perhaps because Java 1.4 has reached EOL on 30th Oct 2008.
And so, their security can be compromised!.

Show a couple of examples, where, security has actually been compromised due to Java 1.4.

They will be sufficiently scared IMO.

夏了南城 2024-09-24 17:20:48

为什么不去java 6呢? java 1.4 和 java 5 都已经走到了生命的尽头。

Why not go to java 6? Both java 1.4 and java 5 have reached their end of life.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文