如何用Maven编译适配特定Java版本的带依赖Jar包？

Absolutely, you can adjust your Maven build to work with the Java 8u25 environment, but there are a couple of key steps you need to take since the LocalDateStringConverter class you're using wasn't added until JavaFX 8u40. Let's walk through this clearly, since you're new to Java and Maven:

1. Understand the Core Problem #

The LocalDateStringConverter is part of JavaFX, and it was introduced in Java 8 Update 40. Your app was compiled against Java 8u151 (which includes this class), but the user's 8u25 JRE doesn't have it—hence the "missing class" error when launching.

2. Fix Option 1: Replace the Unsupported Class (Recommended for 8u25 Compatibility) #

Since you can't rely on LocalDateStringConverter in 8u25, you can implement the same functionality using older, compatible APIs. Here's a quick example:

import java.time.LocalDate;
import java.time.format.DateTimeFormatter;
import javafx.util.StringConverter;

public class CustomLocalDateConverter extends StringConverter<LocalDate> {
    private final DateTimeFormatter formatter;

    public CustomLocalDateConverter(DateTimeFormatter formatter) {
        this.formatter = formatter;
    }

    @Override
    public String toString(LocalDate date) {
        return date == null ? "" : formatter.format(date);
    }

    @Override
    public LocalDate fromString(String string) {
        return string == null || string.isEmpty() ? null : LocalDate.parse(string, formatter);
    }
}

This does exactly what LocalDateStringConverter does, but uses only APIs available in Java 8u25. Just replace any usage of LocalDateStringConverter with this custom class.

3. Fix Option 2: Configure Maven to Enforce 8u25 Compilation #

To make sure you don't accidentally use APIs that aren't available in 8u25, update your Maven pom.xml with the maven-compiler-plugin to target the older JRE. You'll need the 8u25 JDK installed locally to set the bootclasspath (this tells Maven to compile against the exact class set from 8u25):

<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-compiler-plugin</artifactId>
            <version>3.11.0</version>
            <configuration>
                <source>1.8</source>
                <target>1.8</target>
                <!-- Replace the path below with your local 8u25 JDK's rt.jar and jfxrt.jar -->
                <bootclasspath>${java.home}/lib/rt.jar:${java.home}/lib/jfxrt.jar</bootclasspath>
                <failOnError>true</failOnError>
            </configuration>
        </plugin>
    </plugins>
</build>

This will throw a compilation error if you try to use classes/methods added after 8u25, which helps catch issues early.

4. Build a Fat Jar with Dependencies #

To create a single Jar that includes all your app's dependencies (excluding JRE/JavaFX classes, which are already present in the user's environment), use the maven-shade-plugin:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-shade-plugin</artifactId>
    <version>3.5.1</version>
    <executions>
        <execution>
            <phase>package</phase>
            <goals>
                <goal>shade</goal>
            </goals>
            <configuration>
                <createDependencyReducedPom>true</createDependencyReducedPom>
                <!-- Exclude JRE/JavaFX classes to avoid conflicts -->
                <filters>
                    <filter>
                        <artifact>*:*</artifact>
                        <excludes>
                            <exclude>java/**</exclude>
                            <exclude>javafx/**</exclude>
                        </excludes>
                    </filter>
                </filters>
            </configuration>
        </execution>
    </executions>
</plugin>

Run mvn clean package and you'll get a fat Jar in the target directory that works on 8u25 (once you've replaced the LocalDateStringConverter).

Important Notes #

• You can't just bundle LocalDateStringConverter into your Jar—it's part of JavaFX, which is part of the JRE, and bundling it will cause classloading conflicts.
• If the user can upgrade their JRE to 8u40 or later, that's the simplest fix, but assuming they can't, the custom converter + Maven config above will work.

内容的提问来源于stack exchange，提问作者Denis