下图代码圈住的部分有没有错误?提交后显示编译错误。

声明(declaration的复数);宣言;(纳税品在海关的)申报;【法】(原告的)申诉

若要我们为您移动这些文件,请转到“帮我修复此问题”部分。如果您想自己修复此问题,请转到“我自己修复此问题”部分。
要自动删除这些文件,请点击 “修复此问题”链接。单击“文件下载”对话框中的“运行”,并按照该向导中的步骤执行操作。

注意:此向导可能只提供英文版本。但是,Windows 的其他语言版本也提供自动修复功能。

注意:如果您使用的计算机并未出现此问题,则可将自动修复功能保存至闪存驱动器或 CD 中,然后就可在出现此问题的计算机中运行该功能。
注意:由于 Microsoft Windows 有多个版本,因此下列步骤可能会因您所使用的计算机而不同。如果是这样,请参阅您的产品文档来完成这些步骤。

要自行删除这些文件,请按照以下步骤操作:
单击「开始」,指向“搜索”,然后单击“文件或文件夹”。
在搜索范围框中,单击安装有 Windows 的磁盘驱动器(如 C:),然后单击立即搜索。


错误代码出现原因有很多种: 1.在装系统时没有装好; 2.电脑的有些硬件驱动没有装好; 3.系统的缓存不够,太小了; 4.某些应用程序在安装有些文件会与系统文件相互共用,一但你删除或损坏这个程序的话,也就等于损坏了系统.计算机出现错误代码大部分是以上四个情况导致的,建议你根据不同的情况进行修复! 其实,无论是什么软件、什么程序,都是由程序员进行编写的 每个程序员都希望能编写出完美的应用程序代码 但难免会有疏忽之处.原因有多种: 一.编译错误,是由于不正确编写代码而产生.如非法实用或丢失关键字,遗漏必要的标点符号,函数调用缺参数或括号不匹配等.其它如变量未采用强制显式声明等而引起的错误.VB通常会在代码写时或运行时报错,按报错提示查找解决.

我们在尝鲜 JDK1.5 的时候,相信不少人遇到过 Unsupported major.minor version 49.0 错误,当时定会茫然不知所措。因为刚开始那会儿,网上与此相关的中文资料还不多,现在好了,网上一找就知道是如何解决,大多会告诉你要使用 JDK 1.4 重新编译。那么至于为什么,那个 major.minor 究竟为何物呢?这就是本篇来讲的内容,以使未错而先知。

真正会面试,正好是给我验证了一个事实。

Class 文件的第 5-8 字节为 minor_version 和 major_version。Java class 文件格式可能会加入新特性。class 文件格式一旦发生变化,版本号也会随之变化。对于 JVM 来说,版本号确定了特定的 class 文件格式,通常只有给定主版本号和一系列次版本号后,JVM 才能够读取 class 文件。如果 class 文件的版本号超出了 JVM 所能处理的有效范围,JVM 将不会处理该 class 文件。

JVM 实现的 第二版中修改了对 class 文件主版本号和次版本号的解释。对于第二版而言,class 文件的主版本号与 Java 平台主发布版的版本号保持一致(例如:在 Java 2 平台发布版上,主版本号从 45 升至 46),次版本号与特定主平台发布版的各个发布版相关。因此,尽管不同的 class 文件格式可以由不同的版本号表示,但版本号不一样并不代表 class 文件格式不同。版本号不同的原因可能只是因为 class 文件由不同发布版本的 java 平台产生,可能 class 文件的格式并没有改变。

上面三段节选自《深入 Java 虚拟机》,啰嗦一堆,JDK 1.2 开启了 Java 2 的时代,但那个年代仍然离我们很远,我们当中很多少直接跳在 JDK 1.4 上的,我也差不多,只是项目要求不得不在一段时间里委屈在 JDK 1.3 上。不过大致我们可以得到的信息就是每个版本的 JDK 编译器编译出的 class 文件中都带有一个版本号,不同的 JVM 能接受一个范围 class 版本号,超出范围则要出错。不过一般都是能向后兼容的,知道 Sun 在做 Solaris 的一句口号吗?保持对先前版本的 100% 二进制兼容性,这也是对客户的投资保护。

第一第二种办法能明确知道 major.minor version,而第三种方法应该也没问题,但是碰到{{BANNED}}构建就难说了,比如谁把那个 META-INFO\MANIFEST 打包后换了也未可知。直接查看类的二进制文件的方法可以万分保证,准确无误,就是工具篡改我也认了。

五:编译器比较及症节之所在

7) 最后一点最重要的,某个版本的 JVM 能接受 class 文件的最大主版本号不能超过对应 JDK 带相应 target 参数编译出来的 class 文件的版本号。

上面那句话有点长,一口气读过去不是很好理解,举个例子:1.4 的 JVM 能接受最大的 class 文件的主版本号不能超过用 1.4 JDK 带参数 -target 1.4 时编译出的 class 文件的主版本号,也就是 48。

编译出的 class 文件在 JVM 1.2 下都能加载执行,何况于 JVM 1.3 呢?(当然要去除使用了新版本扩充的 API 的因素)

六:找到问题解决的方法

那么现在如果碰到这种问题该知道如何解决了吧,还会像我所见到有些兄弟那样,去找个 1.4 的 JDK 下载安装,然后用其重新编译所有的代码吗?其实大可不必如此费神,我们一定还记得 javac 还有个 -target 参数,对啦,可以继续使用 1.5 JDK,编译时带上参数 -target 1.4 -source 1.4 就 OK 啦,不过你一定要对哪些 API 是

如果是在开发中,可以肯定的是现在真正算得上是 JAVA IDE 对于工程也都有编译选项设置目标代码的。例如 Eclipse 的项目属性中的 Java Compiler 设置,如图

自已设定编译选项,你会看到选择不同的 compiler compliance level 是,Generated class files compatibility 和 Source compatibility 也在变,你也可以手动调整那两项,手动设置后你就不用很在乎用的什么版本的编译器了,只要求他生成我们希望的字节码就行了,再引申一下就是即使源代码是用 VB 写的,只要能编译成 JVM 能执行的字节码都不打紧。在其他的 IDE 也能找到相应的设置对话框的。

其他时候,你一定要知道当前的 JVM 是什么版本,能接受的字节码主版本号是多少(可对照前面那个表)。获息当前 JVM 版本有两种途径:

第一:如果你是直接用 java 命令在控制台执行程序,可以用 java -version 查看当前的 JVM 版本,然后确定能接受的 class 文件版本

最后一绝招,如果你不想针对低版本的 JVM 用 target 参数重新编译所有代码;如果你仍然想继续在代码中用新的 API 的话;更有甚者,你还用了 JDK 1.5 的新特性,譬如泛型、自动拆装箱、枚举等的话,那你用 -target 1.4 -source 1.4 就没法编译通过,不得不重新整理代码。那么告诉你最后一招,不需要再从源代码着手,直接转换你所正常编译出的字节码,继续享用那些新的特性,新的 API,那就是:请参考之前的一篇日志:Retrotranslator让你用JDK1.5的特性写出的代码能在JVM1.4中运行 ,我就是这么用的,做好测试就不会有问题的。

七:再议一个实际发生的相关问题

这是一个因为拷贝 Tomcat 而产生的 Unsupported major.minor version 49.0 错误。情景是:我本地安装的是 JDK 1.5,然后在网上找了一个 EXE 的 Tomcat 安装文件安装了并且可用。后来同事要一个 Tomcat,不想下载或安装,于是根据我以往的经验是把我的 Tomcat 整个目录拷给他应该就行了,结果是拿到他那里浏览 jsp 文件都出现 Unsupported major.minor version 49.0 错误,可以确定的是他安装的是 1.4 的 JDK,但我还是有些纳闷,先前对这个问题还颇有信心的我傻眼了。惯性思维是编译好的 class 文件拿到低版本的 JVM 会出现如是异常,可现并没有用已 JDK 1.5 编译好的类要执行啊。

其实理解 major.minor 就像是我们可以这么想像,同样是微软件的程序,32 位的应用程序不能拿到 16 位系统中执行那样。

如果我们发布前了解到目标 JVM 版本,知道怎么从 java class 文件中看出 major.minor 版本来,就不用等到服务器报出异常才着手去解决,也就能预知到可能发生的问题。

其他时候遇到这个问题应具体解决,总之问题的根由是低版本的  JVM 无法加载高版本的 class 文件造成的,找到高版本的 class 文件处理一下就行了

我要回帖

更多关于 编程正确运行结果错误 的文章

 

随机推荐