我可以使用运行时参数来修复 Java 中的错误 API 调用吗? [英] Can I use runtime parameters to fix out of bad API calls in Java?

问题描述

不确定这是否适合提问，但我遇到了 Java 问题.我有一些适用于 Java 6 但不适用于 Java 7 的 Java 代码，错误是:

Not sure if this is the right spot to ask but I'm having a Java issue. I have some Java code that works in Java 6 but not in Java 7, the error is:

java.lang.IllegalStateException: This function should be called while holding treeLock

使用 Java6 有效，但我们的一些外部用户正在运行 Java 7.我发现错误是由调用 validateTree() 引起的，它在 java6 中有效，但在 Java7 中我们需要调用 validate() .当我在本地测试它时，它可以工作.

Using Java6 works but a few of our external users are running Java 7. I figured out the error was caused by a call to validateTree(), which works in java6 but in Java7 we need to call validate() . When I test it locally it works.

这是我的问题，我开始在一家大公司工作，他们不会让我们对代码进行任何更改，直到对其进行彻底审查(我的工作更改将在 2013 年 4 月生效)但在那之前我们的用户越来越恼火.我对 Java 不是最好的，想知道是否有一种方法可以传递运行时参数来改变它?或者我可以在不接触代码库的情况下做些什么?

Here's my problem, I started working at a big corporate and they won't let us make any changes to the code until its been very throughly looked at(my working change is going to take affect in April 2013) but until then our users are getting annoyed. I'm not the best with Java and was wondering if there was a way I could pass a runtime parameters to have this changed? or is there anything I can do without touching the code base?

我很不好意思问这个问题，因为只需实施修复程序就可以轻松解决它，但任何想法或方向都会非常有帮助.

I'm embrassed to ask this question since it could be solved easily by just implementing the fix but any ideas or direction would be very helpful.

更新:理想情况下，我正在寻找可以得到支持的东西，以放入 java 运行时参数，该参数会将所有 validateTree() 引用更改为 validate().

Update: I'm ideally looking for something that I can get support to put in the java runtime parameter that would change all validateTree() references to validate().

推荐答案

我可以使用运行时参数来修复 Java 中的错误 API 调用吗?

Can I use runtime parameters to fix out of bad API calls in Java?

一般来说，不会.

在具体情况下，您可以查看相关类的源代码 Java 7 版本的类库，看看是否有向后兼容的属性.

In a specific case, you could look at the source code of the relevant classes Java 7 version of the class library to see if there is a backwards compatibility property.

假设您找不到修复程序，您就会陷入困境.我建议:

Assuming that you can't find a fix, you are kind of stuck. I'd suggest:

• 建议您的客户在发布修复程序之前使用 Java 6.
• 与您的管理层讨论他们是否可以对他们的政策进行例外处理，以便紧急解决此问题.

如果这些都不起作用，那么真正的问题在于您的客户和您的管理层之间.你已经做了尽可能多的事情.交给上级"处理.

If neither of those works, then the real problem is between your customers and your management. You've done as much as you can do. Leave it to "the higher ups" deal with it.

您可能对我对相关 SO 问题的回答感兴趣，其中涉及为什么 他们做了这个破坏性"的改变.我的看法是，这种变化是为了迫使人们修复一类导致奇怪 UI 行为的阴险、难以重现的应用程序错误.从长远来看，这是一件好事.

You might be interested in my Answer to a related SO Question which touches on the issue of why they made this "breaking" change. My take is that the change is to force people to fix a class of insidious, hard-to-reproduce application bugs that cause strange UI behaviour. And that is a good thing ... in the long term.

基于此，您可以为发布带外修复提供更有力的理由.将 validateTree() 调用替换为 validate() 调用的修复实际上是所有 Java 平台的必要修复，而不仅仅是 Java 7.

Based on that, you could make a stronger case for issuing an out-of-band fix. The fix to replace validateTree() calls with validate() calls is actually a necessary fix for all Java platforms, not just for Java 7.

这篇关于我可以使用运行时参数来修复 Java 中的错误 API 调用吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！