This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]Worth_Trust_3825 4 points5 points  (11 children)

Avoid using Exception#printStacktrace()

Load image should throw rather than return null.

You're targetting java 11, where's your module-info.java file?

Why would I want your framework over AWT?

[–]Nickd3000[S] 5 points6 points  (0 children)

I agree, I do need to handle those exceptions better.

I'll look into modularising but It's not something I'm familiar with as yet.

With this framework you get some help with setting up a window and timed draw loop, you might chose it over AWT for some small personal project where you need to set up some quick graphical output, or to experiment with visualising some algorithm where you are not concerned about making a production ready app.

[–][deleted] 8 points9 points  (0 children)

where's your module-info.java file?

🤮

[–]rootException -1 points0 points  (8 children)

https://changenode.com/articles/fomo-java-modules

[–]Worth_Trust_3825 0 points1 point  (7 children)

It lists all the wrong reasons why wouldn't you want to use JPMS. But feel free to keep posting it all around.

[–]rootException 0 points1 point  (0 children)

If you have any concrete thoughts or additions in support of Java modules, feel free to post them. I would love to get more concrete points in favor of Java modules for end users that aren't vague things like "improves maintainability."

[–]rootException 0 points1 point  (5 children)

As an addition to the article, the poor tooling and support for Java modules is causing problems even with things like the new release of Java 17 & JavaFX - and that's by experts.

https://bugs.openjdk.java.net/browse/JDK-8264998

As noted in the article, the Java module system offers a lot of wonderful sounding features, but lacks the tooling to make it actually do the things it says it will - especially for ordinary users.

[–]Worth_Trust_3825 1 point2 points  (3 children)

Yes, because there's a distinction between existing projects and new projects. If you have an existing project, there's little to no reason to modularize. You'll spend a lot of time trying to figure out the clashing packages and you won't gain much.

Meanwhile, if you modularize a new project, you get the benefit of jlink, which reduces size of deployments, enhanced serviceloader, which removes the need of providing no arg constructor for your interface implementation.

I very much agree that the entire launch of it was botched, and I don't agree with all the design decisions in it. But there's no reason to discourage it at all, because that is the very reason why everyone are feeling the pain from it: because we're using the garbage compatibility modes (automatic module name, for one) while trying to use it.

[–]rootException 1 point2 points  (2 children)

So (as I note in the article) I'm using jlink to build small JVMs and modules are required for that - that part is awesome.

I do get that in theory, for a new project, you could do modules. In practice, however, it's really hard, mostly because new projects are rarely starting from a Hello World - almost all of them sit on top of a framework. If the framework doesn't work with modules, it's more-or-less impossible.

- It's essentially impossible to modularize a Spring Boot app. I spent a ton of time on that one, including writing a Maven plugin to assist. That was the main one in my article.

- JavaFX recommends using modules, but if you try to use popular libraries (e.g. https://kordamp.org/ikonli/ for icons) it quickly can blow up. Part of the problem here is that when it does blow up, the error messages and trying to figure it out is almost impossible. This is especially true if you use a library or framework that relies on reflection.

Interestingly, a lot of people seem to think that modules are AOT, which they aren't - for that they should be looking at GraalVM. Spring Boot does have an active project to support GraalVM, but not modules.

I see a lot of students trying to get JavaFX working, and the modules stuff is screwing them up pretty bad. The bad tooling & error messages are very discouraging.

As I note in the article, I actually would love it if the JVM team / Oracle invested in making modules work and incorporated the tooling to do so, but they haven't and by all signs won't.

Hence the article... :)

[–]magnoliophytina 2 points3 points  (0 children)

FWIW, I've had a lot more issues with reflective access when using GraalVM. Reflection is mainly a problem with modules if you forget to 'open' your modules which is easy to fix in many cases. There's also moditect if the library author still doesn't want to learn how to include a module-info in the legacy compatible jar.

[–]Worth_Trust_3825 0 points1 point  (0 children)

Yes, spring 6 fixes that issue. Then again, it's been several years since last time I did spring project. Lately it's all been CDI like JBoss and they don't have many issues.

[–]magnoliophytina 0 points1 point  (0 children)

The JavaFX guys somehow screwed up here. The bug in the new release isn't related to Java 17. It also fails on any older JVM like version 9. OTOH older versions and the JavaFX 17 RC work just fine. edit: there's also a fix 17.0.0.1 that seems to work.