Java使用Spring从5升级到8

Java使用Spring从5升级到8,java,spring,java-8,java-5,Java,Spring,Java 8,Java 5,我正在开发一个仍在JDK5上运行的遗留应用程序。作为新需求的一部分,我们需要将其更新为JDK 8。根据我的理解,因为Java是向后兼容的,所以这应该是可行的。当我使用JDK 8编译时,构建是成功的。但在启动时,我遇到了以下错误: 创建名为“AuthorizationDialogController”的bean时出错 类内路径资源 [com/some/application/conf/dispense/dispense controllers.xml]:错误 设置属性值;嵌套异常是 org.spr

我正在开发一个仍在JDK5上运行的遗留应用程序。作为新需求的一部分,我们需要将其更新为JDK 8。根据我的理解,因为Java是向后兼容的,所以这应该是可行的。当我使用JDK 8编译时,构建是成功的。但在启动时,我遇到了以下错误:

创建名为“AuthorizationDialogController”的bean时出错 类内路径资源 [com/some/application/conf/dispense/dispense controllers.xml]:错误 设置属性值;嵌套异常是 org.springframework.beans.propertyaccessExceptionsExceptionsException: PropertyAccessExceptionsExceptionsException(1个错误);嵌套 PropertyAccessException包括: [org.springframework.beans.typemischException:转换失败 类型的属性值 [com.some.application.dispense.context.DispenceContextImpl]到 属性的必需类型[com.some.application.admin.AdminContext] “上下文”]

我的依赖项如下所示:


org.springframework
春天
1.2.7
org.easymock
轻松的
2.2
测试
org.easymock
easymockclassextension
2.2
测试
cglib
cglib
2.1_3
com.micros
aaaa
${externalVendor}
com.micros
bbb
${externalVendor}
com.micros
ccc
${externalVendor}
com.micros
ddd
${externalVendor}
com.micros
eeee
${externalVendor}

我在谷歌上搜索发现Spring1.2.6可能不支持JDK8。有人能帮我做些什么吗。我们还依赖于一些建立在Java5之上的外部供应商。

如果Spring是一个库,您就会看到成功。它不是,它是一个框架

这意味着Spring框架需要理解提供逻辑的插件,这些逻辑可以解决程序地址的其余“问题”。为了进行正确的注入和连接,Spring使用库来检查和配置Spring管理的插件

这些库对插件进行反射和字节码处理。这意味着Spring框架需要理解Java8字节码。你的Spring版本没有。要获得一个Spring,您需要更新Spring的ApacheMaven依赖项;但这将触发更新插件的需要,以便在新的Spring版本中正确运行

简而言之,为了支持Java8,您必须将更多的依赖项迁移到新版本

框架可以是很棒的东西,因为它们可以节省很多时间;但是,存在软件架构风险。如果框架需要更新,所有插件组件可能需要修改才能迁移到新版本。春天也不例外


这就是为什么有些人喜欢利用图书馆;但是,库不是万能的,因为您经常需要决定如何集成它们(这意味着您正在编写自己的框架,但这比其他人的框架更容易控制向前迁移)。

如异常消息
中所述,无法转换类型的属性值[com.some.application.dispense.context.DispenceContextImpl]转换为所需类型[com.some.application.admin.AdminContext]对于属性“context”
。如果某个地方存在类型不匹配,您能找出哪个类使用该属性吗?正如我在文章中提到的,JDK5不会出现此错误。您很可能应该升级到支持Java 8的Spring版本。如果您不断遇到这些问题,可能不是最新版本。有一点是肯定的:您不能只要在一个maven项目上更改java版本,并期望它能够开箱即用。您的Spring依赖关系是在2006年发布的。哎哟。恐怕您还有很长的路要走,除非代码库不是太大。但是如果应用程序要保留更多年,那就需要花费很多时间。不过,在那之后,最好是有一个p策略是定期更新依赖项(花时间评估有用性/衡量影响/执行所需的更改)。这样,如果需要持续维护(比如在几年内更新到目标Java 11或17,或者由于安全问题更新依赖项),应该不会那么痛苦。