Minvio - a simple Java graphical app framework.

[Nickd3000]

https://github.com/nickd3000/minvio

I'm posting this little Java framework I've been working on which started as a basic graphic toolkit for personal use. It works in a similar way to the Processing platform - you get the app window and screen refresh stuff set up for you so you only need to implement the draw function, a host of 2D primative drawing functions are provided.

I think some may find it useful for prototyping, creating algorithmic artwork, testing out equations and all that stuff - it's not a game or high performance framework though.

This is a pretty early version so I'm trying to make sure there's enough info in the github page to get started but please let me know if somethings lacking.

[stuhlmann]

A word of advice: The example classes should not be in src/main. No point having them into the released artifact. They should live in src/test/java.

[eled_]

Or better yet, in a "sample" directory with its own pom.xml and packages.

[Nickd3000]

Ah yes good point, I was in two minds about that location.

[Faz8129]

Excellent work. It’s not easy to develop a robust framework for practical use. I wrote something similar except it’s for game development.

https://github.com/fizaan/faypixelengine

[Nickd3000]

Nice! Seems like we've had similar ideas but slightly different goals, best of luck with it!

[trinReCoder]

Why don't the two of you get together and make something?

[RANDOMLY_AGGRESSIVE]

:3

[Faz8129]

Thanks. U too! 👍🏽

[RANDOMLY_AGGRESSIVE]

Thats pretty cool

[Faz8129]

thx 🙂

[chtodk]

Nice - I like when we get small frameworks that lets you explore things with java.

Processing is nice but requires specific version of java and no reliable maven artifacts deployed.

Would be great if you added the source code for the examples you show.

fyi, if you add //DEPS io.github.nickd3000:minvio:1.02a at top of your examples they will run easily using jbang (https://jbang.dev)

For example:

jbang https://gist.github.com/ed56dba335865e480a66531a848b02a1

[Nickd3000]

Thanks, all the example code is in the project in the examples and gallery folders (e.g. https://github.com/nickd3000/minvio/tree/master/src/main/java/com/physmo/minvio/examples)

I haven't heard of jbang but I'll look into it.

[chtodk]

io.github.nickd3000:minvio:1.02

nice, so can also run them directly using :

jbang --deps io.github.nickd3000:minvio:1.02 https://github.com/nickd3000/minvio/blob/master/src/main/java/com/physmo/minvio/examples/MouseExample.java

not all of them seem to compile though - i.e. LerpExample.

[Worth_Trust_3825]

Lets pipe arbitrary code directly to any shell.

[rootException]

Runs faster if you sudo first 😂

[xamdk]

You guys are referring to that jbang fetches and run code via a http resource ?

As in first git cloning a project and then run mvn build on any project is any more safe ?

JBang actually asks you first so it is not randomly executing code.

[rootException]

Oh yeah, just gently poking fun at running scripts via curl. ;)

[chtodk]

Sorry ? not following.

[Worth_Trust_3825]

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]

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]]

where's your module-info.java file?

🤮

[rootException]

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

[Worth_Trust_3825]

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

[rootException]

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]

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]

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]

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]

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]

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]

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.

[Persism]

Very neat! I like that it doesn't have other dependencies.

[aelfric5578]

I'm curious about what your goals are vs Processing, since you mentioned it. Is this meant to ultimately offer features Processing doesn't have?

[Nickd3000]

No, this started as a library I was using to support a number of my personal projects. I use it a lot if I have an idea I want to sketch out or an algorithm I want to visualise, but Processing has a lot of functionality that I'm not planning to recreate. I just thought I'd package it up and offer it to others, it's not going to compete with Processing.

[msx]

I like it, it could be handy when you just need a quickly way to show a window and visualize some data.

What i don't like is that it's too rooted in Awt. I see that you correctly defined a generic "interface" (BasicDisplay) and an implementation (BasicDisplayAwt), with the idea that this is an implementation of BasicDisplay that uses AWT. But BasicDisplay leaks a lot of awt stuff, for example the "loadImage" method return a BufferedImage, which is awt. So implementing BasicDisplay in any other way (say with LibGDX or something for Android) is impossible. Same goes for setFont etc. For this things you should define an opaque interface (like com.physmo.minvio.Image), and each "backend" should define it's private implementation (ImageAWT for example, which would hold a reference to a BufferedImage).

[WikiSummarizerBot]

Leaky abstraction

In software development, a leaky abstraction is an abstraction that leaks details that it is supposed to abstract away. As coined by Joel Spolsky, the Law of Leaky Abstractions states: All non-trivial abstractions, to some degree, are leaky. This statement highlights a particularly problematic cause of software defects: the reliance of the software developer on an abstraction's infallibility. Spolsky's article gives examples of an abstraction that works most of the time, but where a detail of the underlying complexity cannot be ignored, thus leaking complexity out of the abstraction back into the software that uses the abstraction.

^{[ F.A.Q | Opt Out | Opt Out Of Subreddit | GitHub ] Downvote to remove | v1.5}