Thanks for the PR. However, clicking the meteo button, I got this exception:

java.lang.NoClassDefFoundError: java/net/http/HttpRequest
at info.openrocket.core.communication.OpenMeteoAPI.getElevation(OpenMeteoAPI.java:59)
at info.openrocket.swing.gui.simulation.SimulationConditionsPanel.lambda$addSimulationConditionsPanel$2(SimulationConditionsPanel.java:258)
at java.desktop/javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1972)
at java.desktop/javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2313)
at java.desktop/javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:405)
at java.desktop/javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:262)
at java.desktop/javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:279)
at java.desktop/java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:297)

Also, there is currently no API throttle. I don't want us to swamp the OpenMeteoAPI when multiple users fiddle with the latitude-longitude. This may not be critical for altitude lookup, but it will once we also use OpenMeteo for weather data.

Hi SiboVG,

Thanks for your feedback!

The NoClassDefFoundError is caused by the absence of the java.net.http module. Since I'm unfamiliar with how modules are included in the packaged JRE, and the general rules around JPMS in this project, I'll rewrite the class using HttpsURLConnection.

Regarding API throttling, do you have a rate limit or throttling time frame in mind?

The NoClassDefFoundError is caused by the absence of the java.net.http module. Since I'm unfamiliar with how modules are included in the packaged JRE, and the general rules around JPMS in this project, I'll rewrite the class using HttpsURLConnection.

Hm. I can run the program just fine from IntelliJ, but if I build my own JAR, I get the error. Maybe it's an issue in the gradle configuration. I'll investigate it.

Regarding API throttling, do you have a rate limit or throttling time frame in mind?

OpenMeteo requests a limit of 10,000 API calls per day (per user).

Ok, found the issue. The JarInJarStarter did not use the JDK classloader as a parent, so the http module (included in the Java 11+ JDK) was not being included.

Ok, found the issue. The JarInJarStarter did not use the JDK classloader as a parent, so the http module (included in the Java 11+ JDK) was not being included.

I'm glad you were able to figure that out for me, thank you!

OpenMeteo requests a limit of 10,000 API calls per day (per user).

That should be straight forward enough to implement. However, if the user was to change the query parameters in quick succession (e.g. using the sliders), and send the request to open-meteo, should we also throttle the number of calls within a shorter timeframe? If so, what should that number and timeframe be?

I have to question whether we need rate-limiting. When we pull weather from open-meteo we'll want to have a cache with a one hour expiration; it's really hard for me to imagine we'll have a user who somehow manages to come up with 10,000 API calls a day.

I have to question whether we need rate-limiting. When we pull weather from open-meteo we'll want to have a cache with a one hour expiration; it's really hard for me to imagine we'll have a user who somehow manages to come up with 10,000 API calls a day.

I'm happy to implement it if need be. In the mean time, I will see if I can tackle something else while I wait for the go/no-go :)

I have to question whether we need rate-limiting. When we pull weather from open-meteo we'll want to have a cache with a one hour expiration; it's really hard for me to imagine we'll have a user who somehow manages to come up with 10,000 API calls a day.

Maybe this advanced feature is off by default, and only available if the user supplies their own Open-Meteo key?

I have to question whether we need rate-limiting. When we pull weather from open-meteo we'll want to have a cache with a one hour expiration; it's really hard for me to imagine we'll have a user who somehow manages to come up with 10,000 API calls a day.

Maybe this advanced feature is off by default, and only available if the user supplies their own Open-Meteo key?

open-meteo API doesn't require a key. When they say "open" they mean it!

I have to question whether we need rate-limiting. When we pull weather from open-meteo we'll want to have a cache with a one hour expiration; it's really hard for me to imagine we'll have a user who somehow manages to come up with 10,000 API calls a day.

Maybe this advanced feature is off by default, and only available if the user supplies their own Open-Meteo key?

open-meteo API doesn't require a key. When they say "open" they mean it!

Ah, well then no concerns. Requests would be coming from all sorts of ips.... And yeah who is gonna use 10k in that timeframe? If they do that only limits them.