MaterialKolor Dev Bricks Their Own Library by Forcing Java 17 Like a Clueless Amateur

[SpoilerRules]

2 months ago I upgraded to MaterialKolor 3 thinking I was making a smart move. I wasted 2 months integrating this junk into my Compose Multiplatform for Desktop project. I used Java 21 locally and everything seemed fine. Then I built an MVP JAR to share with friends and tested it with Java 11 before sharing it with them.

The result was this masterpiece of incompetence:

Exception in thread "main" java.lang.UnsupportedClassVersionError: com/materialkolor/PaletteStyle has been compiled by a more recent version of the Java Runtime (class file version 61.0), this version of the Java Runtime only recognizes class file versions up to 55.0

That means the library was compiled for Java 17. And for what? There is nothing in this library that needs Java 17. This is a color palette library, not some space-age neural network framework. The only reason to do this is pure carelessness.

The maintainer silently bumped the target from Java 11 to Java 17 without warning, without explanation, without a single note in the repository. Not even a lazy sentence in the README. Nothing. They just dropped the change in and acted like nobody would notice. That is NOT bold. That is stupid.

Any competent library maintainer keeps compatibility as wide as possible unless there is a clear technical reason to raise the requirement. This is day-one knowledge. This is the kind of thing you learn before you even know how to publish an artifact. Failing to understand that means you have no business running an open-source project.

MaterialKolor 3 is a textbook example of how to alienate users, waste their time, and show the world you have no idea how real developers actually work. If you cannot manage basic build configuration, maybe stop pretending you are a serious developer and stick to hobby projects nobody relies on.

[jordond]

First off, I'd like to say thank you for your honest feedback, and I understand your frustration.

However it's a very heated message, and a little unfair to someone who is developing and maintaining this project for free in my spare time. Creating an issue, or better yet opening a PR perhaps would have been a more constructive.

As you mentioned, yes. I am an amateur, my full time job for the past years has been Android development, with KMP as a hobby. Going so far as to insult me isn't very productive, and perhaps could have just been omitted.

If you don't like my libraries, or all the free effort I put in. You are free to fork and maintain your own version, as all my libraries are licences MIT.

As for the actual issue with the Java version. Yes, bumping to 17 probably wasn't the smartest move, and I'm open and willing to rectify that. As for:

And for what? There is nothing in this library that needs Java 17. This is a color palette library, not some space-age neural network framework.

The upstream material-color-utilities actually does use Java 14 features. So while it isn't Java 17, and the ported Kotlin code doesn't need it. It turns out saying: "This is a color palette library, not some space-age neural network framework." isn't really true 😆 .

Again, thank you for your (brutally) honest feedback, even if the language was a bit uncalled for and harsh. I will look into downgrading the target Java version. But again, this is not my full time job. So if you feel so inclined, open a PR and I will gladly accept it. And hopefully we can all be a little bit more friendly from here on out.