I am working on a legacy application which is still running on JDK5. As part of our new requirement we need to update it to JDK 8. As per my understanding since Java is backward compatible, this should have worked. When I compiled with JDK 8 , the build was successful. But while launching ,I got the following error :

Error creating bean with name 'AuthorisationDialogController' defined in class path resource [com/some/application/conf/dispense/dispense-controllers.xml]: Error setting property values; nested exception is org.springframework.beans.PropertyAccessExceptionsException: PropertyAccessExceptionsException (1 errors); nested propertyAccessExceptions are: [org.springframework.beans.TypeMismatchException: Failed to convert property value of type [com.some.application.dispense.context.DispenseContextImpl] to required type [com.some.application.admin.AdminContext] for property 'context']

My dependencies looks like the following:

    <dependencies>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring</artifactId>
            <version>1.2.7</version>
        </dependency>
        <dependency>
            <groupId>org.easymock</groupId>
            <artifactId>easymock</artifactId>
            <version>2.2</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.easymock</groupId>
            <artifactId>easymockclassextension</artifactId>
            <version>2.2</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>cglib</groupId>
            <artifactId>cglib</artifactId>
            <version>2.1_3</version>
        </dependency>
        <dependency>
            <groupId>com.micros</groupId>
            <artifactId>aaaa</artifactId>
            <version>${externalVendor}</version>
        </dependency>
        <dependency>
            <groupId>com.micros</groupId>
            <artifactId>bbb</artifactId>
            <version>${externalVendor}</version>
        </dependency>
        <dependency>
            <groupId>com.micros</groupId>
            <artifactId>ccc</artifactId>
            <version>${externalVendor}</version>
        </dependency>
        <dependency>
            <groupId>com.micros</groupId>
            <artifactId>ddd</artifactId>
            <version>${externalVendor}</version>
        </dependency>
        <dependency>
            <groupId>com.micros</groupId>
            <artifactId>eeee</artifactId>
            <version>${externalVendor}</version>
        </dependency>
    </dependencies>

I googled and found out that Spring1.2.6 might not support JDK8. Please can anyone help me what all things I need to take care here. We also have dependency on some external vendor which is built on top of Java5.

If Spring was a library, you would have seen success. It is not, it is a framework.

This means that the Spring framework needs to understand the plugins that provide the logic that solves the rest of the "problem" your program addresses. To do the correct injections and wiring, Spring uses libraries that inspect and configure the plugins written to be managed by Spring.

These libraries do reflection and byte code processing on the plugins. This means that the Spring framework needs to understand Java 8 bytecode. Your version of Spring doesn't. To get a Spring that does, you would update the Apache Maven dependency for Spring; but that will trigger the need to update the plugins to correctly operate with the new Spring version.

In short, you're going to have to migrate a lot more dependencies to newer versions to support Java 8.

Frameworks can be great things, as they can save a lot of time; but, there is an software architecture risk. If the framework needs updating, all of the plugin components may need modification to migrate to the new version. Spring is no exception.

This is why some people prefer to leverage libraries; but, libraries are not a panacea, because you often need to decide how to integrate them (which means you're writing your own framework, but that's easier to control the migrate forward than someone else's framework).