My old projects use Java 6 (1.6), and I don't know when I update (Java 7), they can run fine ?
我以前的项目使用Java 6(1.6)，我不知道什么时候更新(Java 7)，它们可以正常运行吗?
5 个解决方案
#1
12
There is an official list of known incompatibilities between java 6 and java 7 from Oracle (including descriptions of both binary and source-level incompatibilities in public APIs).
Oracle提供了java 6和java 7之间已知的不兼容的官方列表(包括公共api中二进制和源代码级不兼容的描述)。
Also you can look at the independent analysis of API changes in the Java API Tracker project: http://abi-laboratory.pro/java/tracker/timeline/jre/
您还可以查看Java API跟踪器项目中API更改的独立分析:http://abi-laboratory.pro/java/tracker/timeline/jre/
The report is generated by the japi-compliance-checker tool.
报告是由日本遵从性检查工具生成的。
#2
3
They should do, yes. Java has a reasonably strong history of backward compatibility. However, if these are in any way important projects you should still perform a thorough test pass before deploying anywhere production-like.
他们应该做的,是的。Java具有相当强的向后兼容性历史。但是，如果这些都是重要的项目，您仍然应该在部署到任何类似生产的地方之前执行完整的测试。
#3
1
There shouldn't be any compatibility differences as the JVM is basically the same. However it is early days so there may be subtle differences which cause a problem which people are not yet aware of.
不应该存在任何兼容性差异，因为JVM基本上是相同的。然而，由于时间尚早，所以可能存在细微的差异，从而导致人们尚未意识到的问题。
e.g. Eclipse looks at the Supplier in the java.exe on Windows and sets the command line arguments differently for different suppliers. It has a problem with Java 6 update 22 because Oracle wanted to change it from "Sun" to "Oracle". I believe this has been changed so it is "Oracle" in Java 7 (but still "Sun" for Java 6)
Eclipse用java查看供应商。在Windows上设置exe，并为不同的供应商设置不同的命令行参数。Java 6更新有一个问题，因为Oracle希望将其从“Sun”改为“Oracle”。我相信这已经改变了，所以在Java 7中它是“Oracle”(但在Java 6中仍然是“Sun”)
My point being, that if you write generic Java code, you shouldn't have a problem. However, if you are doing something a bit unusual, you are likely to need to re-test your application.
我的观点是，如果您编写通用Java代码，您应该不会有问题。但是，如果您正在做一些不寻常的事情，您可能需要重新测试您的应用程序。
#4
1
As was already stated backward compatibility is a very important aspect in new Java releases, so in general there should be no problems in switching to a newer Java version. In this case, however, Java 7 seems to have a few bugs in the new hotspot compiler optimizations. The Apache Software Foundation has issued a warning that their products Lucene and Solr are affected by these bugs.
如前所述，向后兼容性是新Java发行版中的一个非常重要的方面，因此通常在切换到新Java版本时应该没有问题。然而，在这种情况下，Java 7在新的hotspot编译器优化中似乎有一些错误。Apache软件基金会已经发出警告，他们的产品Lucene和Solr受到这些缺陷的影响。
http://lucene.apache.org/ # 28 + 7 + 2011 + - +警告% 3 +腐败指数+ +和+ +在+ Apache +崩溃Apache Lucene +核心+ % 2 f + + Solr +和+ Java + 7
The affected loop optimizations can be switched off by starting java with -XX:-UseLoopPredicate.
通过使用-XX:-UseLoopPredicate启动java，可以关闭受影响的循环优化。
#5
0
AFAIS here, there's no Java 6 features which get deprecated in Java 7 so yes, your project should run fine.
在这里，没有Java 6特性在Java 7中被弃用，所以是的，您的项目应该运行良好。
#1
12
There is an official list of known incompatibilities between java 6 and java 7 from Oracle (including descriptions of both binary and source-level incompatibilities in public APIs).
Oracle提供了java 6和java 7之间已知的不兼容的官方列表(包括公共api中二进制和源代码级不兼容的描述)。
Also you can look at the independent analysis of API changes in the Java API Tracker project: http://abi-laboratory.pro/java/tracker/timeline/jre/
您还可以查看Java API跟踪器项目中API更改的独立分析:http://abi-laboratory.pro/java/tracker/timeline/jre/
The report is generated by the japi-compliance-checker tool.
报告是由日本遵从性检查工具生成的。
#2
3
They should do, yes. Java has a reasonably strong history of backward compatibility. However, if these are in any way important projects you should still perform a thorough test pass before deploying anywhere production-like.
他们应该做的,是的。Java具有相当强的向后兼容性历史。但是，如果这些都是重要的项目，您仍然应该在部署到任何类似生产的地方之前执行完整的测试。
#3
1
There shouldn't be any compatibility differences as the JVM is basically the same. However it is early days so there may be subtle differences which cause a problem which people are not yet aware of.
不应该存在任何兼容性差异，因为JVM基本上是相同的。然而，由于时间尚早，所以可能存在细微的差异，从而导致人们尚未意识到的问题。
e.g. Eclipse looks at the Supplier in the java.exe on Windows and sets the command line arguments differently for different suppliers. It has a problem with Java 6 update 22 because Oracle wanted to change it from "Sun" to "Oracle". I believe this has been changed so it is "Oracle" in Java 7 (but still "Sun" for Java 6)
Eclipse用java查看供应商。在Windows上设置exe，并为不同的供应商设置不同的命令行参数。Java 6更新有一个问题，因为Oracle希望将其从“Sun”改为“Oracle”。我相信这已经改变了，所以在Java 7中它是“Oracle”(但在Java 6中仍然是“Sun”)
My point being, that if you write generic Java code, you shouldn't have a problem. However, if you are doing something a bit unusual, you are likely to need to re-test your application.
我的观点是，如果您编写通用Java代码，您应该不会有问题。但是，如果您正在做一些不寻常的事情，您可能需要重新测试您的应用程序。
#4
1
As was already stated backward compatibility is a very important aspect in new Java releases, so in general there should be no problems in switching to a newer Java version. In this case, however, Java 7 seems to have a few bugs in the new hotspot compiler optimizations. The Apache Software Foundation has issued a warning that their products Lucene and Solr are affected by these bugs.
如前所述，向后兼容性是新Java发行版中的一个非常重要的方面，因此通常在切换到新Java版本时应该没有问题。然而，在这种情况下，Java 7在新的hotspot编译器优化中似乎有一些错误。Apache软件基金会已经发出警告，他们的产品Lucene和Solr受到这些缺陷的影响。
http://lucene.apache.org/ # 28 + 7 + 2011 + - +警告% 3 +腐败指数+ +和+ +在+ Apache +崩溃Apache Lucene +核心+ % 2 f + + Solr +和+ Java + 7
The affected loop optimizations can be switched off by starting java with -XX:-UseLoopPredicate.
通过使用-XX:-UseLoopPredicate启动java，可以关闭受影响的循环优化。
#5
0
AFAIS here, there's no Java 6 features which get deprecated in Java 7 so yes, your project should run fine.
在这里，没有Java 6特性在Java 7中被弃用，所以是的，您的项目应该运行良好。