Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Building with Java 21 #655

Open
krishnak opened this issue Feb 4, 2024 · 5 comments
Open

Building with Java 21 #655

krishnak opened this issue Feb 4, 2024 · 5 comments

Comments

@krishnak
Copy link

krishnak commented Feb 4, 2024

I have Java Version 21 (Bell Soft). When I clone the repository - I have modified the top level pom.xml to the correct JAVA targets to 21.

I have also modified JaCoCo dependency to the latest version which supports Java 21. However compilation fails with the following when building charts - is there a solution to overcome this

[ERROR] /home/krishnak/chart-fx-main/chartfx-chart/src/main/java/io/fair_acc/chartfx/ui/ObservableDeque.java:[17,8] types java.util.Deque<E> and java.util.List<E> are incompatible;
  both define reversed(), but with unrelated return types
[INFO] 1 error
[INFO] -------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary for chartfx-parent master-SNAPSHOT:
[INFO] 
[INFO] chartfx-parent ..................................... SUCCESS [  0.802 s]
[INFO] chartfx-bench ...................................... SUCCESS [  1.979 s]
[INFO] chartfx-generate ................................... SUCCESS [  0.620 s]
[INFO] chartfx-dataset .................................... SUCCESS [ 34.907 s]
[INFO] chartfx_math ....................................... SUCCESS [ 12.864 s]
[INFO] chartfx-chart ...................................... FAILURE [  1.226 s]
[INFO] chartfx-acc ........................................ SKIPPED
[INFO] chartfx-samples .................................... SKIPPED
[INFO] chartfx-report ..................................... SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  52.500 s
[INFO] Finished at: 2024-02-04T07:53:30+05:30
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.11.0:compile (default-compile) on project chartfx: Compilation failure
[ERROR] /home/krishnak/chart-fx-main/chartfx-chart/src/main/java/io/fair_acc/chartfx/ui/ObservableDeque.java:[17,8] types java.util.Deque<E> and java.util.List<E> are incompatible;
[ERROR]   both define reversed(), but with unrelated return types
[ERROR] 
[ERROR] -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.11.0:compile (default-compile) on project chartfx: Compilation failure
/home/krishnak/chart-fx-main/chartfx-chart/src/main/java/io/fair_acc/chartfx/ui/ObservableDeque.java:[17,8] types java.util.Deque<E> and java.util.List<E> are incompatible;
  both define reversed(), but with unrelated return types


@wirew0rm
Copy link
Member

Hey, thanks for your interest in chart-fx and sharing your findings here.

That looks like there was some API changes with Deque and List in newer java versions. If I'm not mistaken it should not be necessary to bump the java level to use a newer jdk if you don't want to modify chart-fx and use newer java features in your modifications.

That being said we are of course interested in following the development of the java ecosystem and making sure we can successfully compile also on the newest source level. At the same time, as a library we try not to force our users too much into the bleeding edge, but most of the changes usually can be made in a backwards compatible way. I'll have to find some time to look into this, but if you have made or make progress on this in the meantime, feel free to share it here and/or open a PR.

Last but not least, we're always interested in understanding how and where chartfx is being used, so if you can share some information about your use of chartfx, feel free to share some info and/or screenshots about what you are building/what you built/are building: https://github.com/fair-acc/chart-fx/discussions/categories/show-and-tell

@dlemmermann
Copy link

dlemmermann commented May 16, 2024

The reason for this compilation issue is described in detail here: https://inside.java/2023/05/12/quality-heads-up/

If the ObservableDeque.reversed() method is not used anywhere then a simply implementation throwing an UnsupportedOperationException might be all that is needed.

This is how I implemented it:

    /**
     * Unsupported: we need to override this method because of a name clash between
     * java.util.List and java.util.Deque. Both define a method called reversed() but with
     * different return types. This method was introduced in Java 21. Read more about it here:
     * https://inside.java/2023/05/12/quality-heads-up/
     */
    public ObservableDeque<E> reversed() {
        /*
         * Throw an exception. A better solution would be a complete implementation
         * of a reversed observable deque. However, that is quite a bit of work and if not needed
         * then why do it. To see an example for this approach, see LinkedList.reversed().
         */
        throw new UnsupportedOperationException("reversed() not supported");
    }

For this approach we do not even have to change the compiler level settings in the project. Only drawback is that we cannot annotate the method with "Override" as that would fail in older Java versions.

@dlemmermann
Copy link

BTW, several samples also fail when running with Java 21 as they are using reflections that are clashing with the module system. I think it would be a good idea to move the project at least to the module system and to assume JDK 17 as the minimum.

@wirew0rm
Copy link
Member

I did multiple attempts at moving to the module system, but the problem was always that there were (and probably are) still some dependencies that are not yet modularized and the articles I read back then all made this a prerequisite (the only way out being maven plugins that basically repackage the unmodularized dependencies). Since this was now 4 years ago, a lot might have changed, but back then I put a lot of time into this only to realize that it could not work for us.

I don't think dropping jdk11 should be a big deal by now 👍

@dlemmermann
Copy link

This is indeed not an issue. I constantly use the module system with third party libs that are not modularised, yet.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants