search

WorldWindEarth / WorldWindJava

A community supported fork of the NASA WorldWind Java SDK (WWJ) is for building cross-platform 3D geospatial desktop applications in Java.
https://worldwind.earth/WorldWindJava/
48 stars 14 forks source link

Gradle improvements #44

Closed wcmatthysen closed 5 years ago

wcmatthysen commented 5 years ago

Description of the Change

Made some improvements to the Gradle build script to allow the project to be opened in NetBeans via the Gradle plugin. We can now build the project in NetBeans, run the unit tests, debug it as well as run some of the examples all from NetBeans. The Travis config was also changed to build the project with Gradle.

Why Should This Be In Core?

We want to eventually migrate over to using Gradle as our primary way to build the project. These are some of the necessary changes that we need to make to get there.

Benefits

Easy setup and build of the project in NetBeans (and potentially other IDEs).

Potential Drawbacks

None at this point.

Applicable Issues

Issue #11

robmilton commented 5 years ago

@wcmatthysen It looks like the build checks include Oracle and Open JDK 8 and 11. Just wondering why we wouldn't also include Oracle and Open JDK 12 since its general release tool place earlier this year. I don't know that there's a significant amount of change between 11 and 12, but it seems like it might be reasonable to include the latest Java release. Thoughts?

EDIT I'm not yet familiar with the build testing in GitHub. It dawns on me that these checks may simply be inherited from the project and not specific to this pull request. Is that the case? If so I should direct my question elsewhere...

wcmatthysen commented 5 years ago

@robmilton, I agree. We can probably add it now. In the past we tested against OpenJDK (or OracleJDK) 12 by getting it via openjdk-ea if you look at the Travis-config. Now that it is released, it looks like we can actually add it (see: https://travis-ci.community/t/openjdk-12-no-longer-usable/2718/23). I suppose openjdk-ea will now test against Java 13 early-access releases if I'm not mistaken.

wcmatthysen commented 5 years ago

@robmilton, the builds against the different JDKs are as a result of the Travis-config that was inherited from the upstream repository and updated by @emxsys. The travis.yml file indicates to GitHub that we want to build and test the changes in each pull-request on Travis. It is not just specific to this pull-request. Each and every pull-request kicks off a Travis build that compiles WorldWind on the different JDKs and runs the unit tests on all of them as well.

robmilton commented 5 years ago

@wcmatthysen, thanks for the explanation. I'm learning how all these pieces fit together. I'm hoping to get to a point soon to be able to contribute as well. I'd love to at least support efforts to get WorldWindJava working on Java 9+ (preferably the keeping it up to date with the latest Java release).

PJHogan commented 5 years ago

Good luck world crew! Making it all work in smooth wonder with the latest!!!

gbburkhardt commented 5 years ago

@wcmatthysen, thanks for the explanation. I'm learning how all these pieces fit together. I'm hoping to get to a point soon to be able to contribute as well. I'd love to at least support efforts to get WorldWindJava working on Java 9+ (preferably the keeping it up to date with the latest Java release).

We've been using WorldWind with Java 11 for about two months now. There weren't any major problems. Probably the most work that should be down is updating routines that use deprecated methods. For the rest of our application, figuring out how to fit JAXB in took the most effort. But that library isn't used by WorldWind. We're using AdoptOpenJDK 11.03.

gbburkhardt commented 5 years ago

@wcmatthysen It looks like the build checks include Oracle and Open JDK 8 and 11. Just wondering why we wouldn't also include Oracle and Open JDK 12 since its general release tool place earlier this year. I don't know that there's a significant amount of change between 11 and 12, but it seems like it might be reasonable to include the latest Java release. Thoughts?

EDIT I'm not yet familiar with the build testing in GitHub. It dawns on me that these checks may simply be inherited from the project and not specific to this pull request. Is that the case? If so I should direct my question elsewhere...

Well, to use the Oracle Java builds, someone might need to come with the USD $40 for the license fee. ;-)

wcmatthysen commented 5 years ago

@emxsys, @gbburkhardt, I think we can merge this. The first Travis-build failed because I erroneously pushed the gradle-improvements branch to this repo instead of my own fork. I then immediately removed the branch from this repo, but this caused the "Travis CI - Branch" build to fail as it couldn't get the branch anymore. After this I pushed the changes to my own fork. You'll see that the "Travis CI - Pull Request" build succeeds. I added openjdk12 as a new entry to build against and it successfully builds against Java 12 which is good news. The build against openjdk-ea (which is Java 13 if I'm not mistaken) fails though and we'll probably need to address this at some point.

robmilton commented 5 years ago

@gbburkhardt, I'm excited to hear you've been running WWJ with Java 11 for a while! I'll definitely be interested in pursuing this topic with you in the near future. In addition to the changes to WW I'd be interested to hear how you're handling the runtime since it seems the JRE is no longer available as of Java 11. If you have a distributed application are you using JLink to package the necessary runtime components in your application? Or are you relying on users installing the JDK? Just interested to hear what you're doing.

The other reason for this post is to ask about the gradle build. I just built WWJ-CE for the first time since the NetBeans project folder was removed and the project moved to a gradle build. When I run my application I'm getting errors stating: java.lang.NoSuchMethodError: java.nio.ByteBuffer.flip()Ljava/nio/ByteBuffer;

I had this EXACT same behavior a number of weeks back when I tried compiling WW with Java 9. A quick search on Google resulted in many hits explaining Java 9 made a change to java.nio.ByteBuffer.flip() which now returns a ByteBuffer where it used to return a Buffer.

I see that build.gradle is setting sourceCompatibility and targetCompatibility to 1.8. But I don't see where the JDK is specified. How can I guarantee with the gradle build that I'm building using JDK 8 and not JDK 9+?

I'm hoping that if I build using JDK 8 it will address this problem...

robmilton commented 5 years ago

This issue was that the platform being used by the gradle build was JDK 11. I hadn't noticed the "Platform for build scripts" section in "Gradle project". Once I unchecked the "Inherit" checkbox I was able to choose JDK 8 as the build platform. And after I built using JDK 8 the errors went away.

gbburkhardt commented 5 years ago

@gbburkhardt, I'm excited to hear you've been running WWJ with Java 11 for a while! I'll definitely be interested in pursuing this topic with you in the near future. In addition to the changes to WW I'd be interested to hear how you're handling the runtime since it seems the JRE is no longer available as of Java 11. If you have a distributed application are you using JLink to package the necessary runtime components in your application? Or are you relying on users installing the JDK? Just interested to hear what you're doing.

The other reason for this post is to ask about the gradle build. I just built WWJ-CE for the first time since the NetBeans project folder was removed and the project moved to a gradle build. When I run my application I'm getting errors stating: java.lang.NoSuchMethodError: java.nio.ByteBuffer.flip()Ljava/nio/ByteBuffer;

I had this EXACT same behavior a number of weeks back when I tried compiling WW with Java 9. A quick search on Google resulted in many hits explaining Java 9 made a change to java.nio.ByteBuffer.flip() which now returns a ByteBuffer where it used to return a Buffer.

I see that build.gradle is setting sourceCompatibility and targetCompatibility to 1.8. But I don't see where the JDK is specified. How can I guarantee with the gradle build that I'm building using JDK 8 and not JDK 9+?

I'm hoping that if I build using JDK 8 it will address this problem...

gbburkhardt commented 5 years ago

Unfortunately, compiling without errors is not enough. I notice that the WorldWindow and InstallImagery example applications don't completely display correctly with Java 11. There's some work needed there.

robmilton commented 5 years ago

@gbburkhardt, thanks for sharing that. I am very interested in getting WWJ to a point where it is compatible with the latest Java release. However, I work for a very small company and have an very large backlog of work. So I'm trying to figure out how I can best support WWJ improvements while getting things done for work.

I really appreciate all that you guys have been doing to move WWJ forward.