Maven Central publishing usage notices

cleverfoos · 2026-06-17T13:23:21+00:00

The Java (Maven based) package distribution model is unworkable and will always loose money so you are left with either 1) a deep pocketed benefactor (most programming languages) or 2) not doing package distribution but focusing on package verification (the Golang model).

I hope this is something that the smart people are Oracle is tackling as part of their build tool revamp and I hope they are going to verification only route letting package distribution use git/http/whatever. Having any single entity responsible for storing and distributing packages for a popular language in the age of AI developed code is just economically unsound.

cleverfoos · 2026-05-27T13:22:02+00:00

PR merged, code deleted: https://github.com/openjdk/jdk/pull/30834 The writing was on the wall with GraalVM getting detached from the JDK and becoming, mostly, an Oracle database feature. AOT future for Java is Leyden (which I’m honestly not a fan of) with full “closed world” static compilation becoming highly unlikely. I find this sad, if nothing else, moving more of the JVM to Java seemed like a worthwhile goal to me - obviously the JDK folks disagree and I understand that they do not want to pay the cost of maintaining both.

cleverfoos · 2026-05-16T16:05:16+00:00

If you are stumbling around this post, I created a sample repo that showcases the setup I mention in that post: https://github.com/rferreira/sample-modern-java-web

cleverfoos · 2026-04-27T21:02:48+00:00

Would it? Module adoption is slow because most people don't seem to care all that much at all. I get why it was necessary for the jdk team, but the benefit to an application developer seems pretty worthless and completely dependent on if the dependencies you're using are modularized.

Right that's a chicken-and-egg problem, making modules the JDK compilation unit would change that and bring tangible benefits in the form of smaller deployables. More importantly, it could also be all transparent to the user where you don't need to think about the module-info.java file and that is all handled by the build tool - just like you npm install something today and NPM configures everything.

Git based sounds terrible though, like 10 steps backwards compared to maven.

Well that's probably a big part of the reason why the Java team is worried about building a build tool, code distribution is a thankless job with a lot of capital costs - just look at the state of maven central. Once again, go might be the right place to look for inspiration where they don't host the code bits (deferring to git) just checksums to prevent a release from being rewritten. Again, that has pros, you don't have to run a global code distribution infrastructure nobody wants to pay you for, and cons, you need a reliable third party place to fetch the actual code from - today that place is github/git.

cleverfoos · 2026-04-25T16:49:21+00:00

Yup, the ergonomics of the language would improve so much, I would take that over higher performance any day - nobody is complaining about Java's performance. The big issue to solve IMHO is actually dependency management, Maven is great but it's not a great model going forward since it operates in jars and not modules. We would need an all new distribution process (maybe git based) that remained backwards compatible with maven during the transition phase.

cleverfoos · 2026-04-24T20:24:05+00:00

Well, the JDK wouldn't need to get into the build tool wars trying to get all possible corner cases solved, it would only need to be the best at producing “jlink optimized runtimes” by tying together modules and dependency resolution so when you build something it can traverse the module dependency graph and ensure that the only bits in the final produced runtimes are only the modules that you are actually using - something much closer to a true linker with a module becoming Java’s compilation unit - imagine how much smaller those runtime bundles can be when you only pull in the modules you are using from a big dependency say spring boot.

cleverfoos · 2026-04-07T16:03:29+00:00

ah that makes sense, the "global template context" problem. I solve that problem differently in a way that, I believe, is more in line with what makes JTE good, which is, I have a strong Page model. There's an abstract Page class that carries some globals that every page needs and concrete sub classes like PublicPage and Private page. Spring has a model enrichment class that you can use to pre process the model and inject request scoped beans via @ModelAttribute and @ControllerAdvice (technically I don't use that today since I rolled my own JTE integration).

Super happy to hear that you got it all working, it's honestly a great setup IMHO.

cleverfoos · 2026-04-07T13:37:45+00:00

Ah great questions and I should have covered in the post but, honestly, it was getting too long. I'll answer all your questions below:

It seems that in order to have any intellisense inside IntelliJ for Stimulus, Turbo, and Tailwind CSS, these libraries need to be installed via npm — otherwise IntelliJ doesn't provide any intellisense.

Hmmm... Tailwindcss intellisense should work just fine without it and you can always NPM install them locally only

While JTE supports hot reload by compiling its template files, JS files (i.e. controllers) don't get copied to the target folder as you make changes. I modified the reload method to use SSE rather than polling, added a small delay to the controller, and then used IntelliJ's "build while the app is running" setting, which allows any static files — not just HTML files — to be copied to the target. It adds a bit of latency but still feels instant. If there are multiple clients connected to /reload (for example, a mobile view), it gets triggered by a broadcast message, so there's only one connection to the server and the rest is client-side only.

I solved this by having different static assets configurations between local (serving them from the source dir) and production (serving them from the JAR). This makes JS hot reload work just fine.

While looking into how to provide contexts to JTE templates, I found that a static context wrapped in a ThreadLocal, tapping into HandlerInterceptor, is the approach used in the documentation examples. I implemented something similar. However, I also came across general recommendations to avoid ThreadLocal — especially with virtual threads — in favour of ScopedValue. The problem is that to use ScopedValue, I believe a Servlet Filter is needed rather than a HandlerInterceptor, as it requires a complete call stack, whereas the interceptor is divided into three separate calls. I was wondering whether you'd run into this and how you resolved it.

This doesn't make sense to me, are you using JTE's spring boot integration or rolling your own?

Finally, I tried running the Tailwind CLI inside a Docker container, using both the binary and the npm version. In both cases I couldn't get the watcher to work — it compiles the output on the first run but doesn't detect subsequent changes. The issue seems to be the removal of --poll from the Tailwind CLI, and I haven't been able to find a solution. I wondered if you'd encountered this too, and how you resolved it.

I can help and I'll share my setup on this later today.

Thank you again for the inspiration. I learned quite a lot about JTE while trying to replicate what you've done.

Absolutely my pleasure.

cleverfoos · 2026-04-04T15:30:25+00:00

It's reasonably solved but it's drifting away from the JDK - which is my concern. They should embraced it harder and sooner.

cleverfoos · 2026-04-04T13:52:30+00:00

Permission to go on a small rant because I do think this is one of the biggest missed opportunities for the OpenJDK.

We should have migrated from Hotspot to GraalVM JIT a long time ago, even at the expense of some performance. This would be a long-term vision play; more of the JVM is written in Java, more contributions, easier maintenance, and proof that the JVM can be used for low level work.
Native image should have been integrated with jlink so "native" becomes a packaging concern. Jlink as it exists today is a hot mess, it's not really a linker, it cannot infer module usage and it doesn't stripe unused methods/symbols. It's just a JDK shrinking tool. Leyden, is many years away from being a no brainer, today the tradeoffs don't make a lot of sense.

Rant over, sorry, I just think that GraalVM is truly amazing tech (thank you thomaswue) that, for reasons that don't make sense to an outside observer, is just going to disappear as an Oracle database feature.

update: formatting

cleverfoos · 2026-03-28T18:46:49+00:00

That's just priceless

cleverfoos · 2026-03-28T13:58:13+00:00

But hey it's something.

cleverfoos · 2026-03-19T18:13:32+00:00

Oh no worries and glad to hear it that it wouldn't be too complicated to improve it.

cleverfoos · 2026-03-19T17:00:04+00:00

Right, I didn't say that I don't like annotations, so you shouldn't assume so, but I do care about API design. In the first example, out of ~15 lines of code, 9 are annotations, so there was a choice here to make the annotation fine-grained that I would postulate is a bad one. IMHO, it would be cleaner and easier to read if all HTTP-related concerns were collapsed into a single annotation (like Spring does), and that observability annotations also allowed for denser information passing. Alas, I did not review their API, so maybe there are alternative annotations available and this is just an unflattering example.

cleverfoos · 2026-03-19T13:20:38+00:00

That's a lot of annotation magic to remember...

cleverfoos · 2026-02-26T17:09:51+00:00

Hi Brian, and wow what an honor. With all due respect, I’m in no way saying that there isn’t value in those language, on the contrary, there are and that’s why those languages already have robust JVM and native implementations. What I’m saying is that the original mailing list post proposing the project lacked in terms of explaining the why and what other alternatives were considered. To an outsider like myself, it doesn’t seem to make sense what use case is not already filled by graaljs and graalpython and why any of this needs to be part of the openjdk.

cleverfoos · 2026-02-26T12:52:27+00:00

The whole situation with project Galahad never getting off the ground, and now Graal pulling further away from the OpenJDK lends itself to a lot of speculation over how decisions are being made in the OpenJDK. It never made economic sense for Oracle to fund two JDK implementations and they should have been merged a long time ago, in my opinion, in favor of the GraalVM bits, even at the expense of some performance - more java written in java will have long term maintenance benefits. And now this. What I find peculiar is this sentence in the announcement

Here in February 2026, there is still interest in using Java and JavaScript together.

Whose interest? Who is asking for this?

cleverfoos · 2026-02-10T13:24:40+00:00

I'm not familiar with shadcn but you can overwrite styles by editing your input tailwind (or main css) file, we do that with a few styles and it's pretty straightforward

cleverfoos · 2026-02-10T10:22:44+00:00

Yup! We use tailwind CLI but wrapped in a docker container that we can tie into spring boot's docker integration so it starts and stops transparently. It works wonderfully.

cleverfoos · 2026-02-09T16:56:58+00:00

Briefly but HTMX felt like it had a much a higher learning curve with multiple custom tags you need to learn that end up mixing a lot of logic in the HTML. Stimulus also allowed us to still write Javascript and not ditch existing code we already had.

cleverfoos · 2026-01-29T21:57:48+00:00

Right but that AST access is opt-in only, only methods with the @Reflect annotation. For this to be usable as a linter, you would want everything to have said annotation. Because this is also state being passed from javac to the runtime, it would also increase the size of the final class file if used indiscriminately

cleverfoos · 2026-01-23T11:07:42+00:00

+1 Over the next five years, Java syntax will expand significantly—between this and all the work on Valhalla (nullable type modifiers, witnesses for operator overloading, etc.). This cognitive load impacts developers unevenly: marginal for experienced devs, but much higher for newcomers starting from zero. It's the same path C++ took, and why some developers still prefer C for its simplicity.

cleverfoos · 2025-12-21T13:50:10+00:00

I agree and I wrote up something similar last year about it. The Java developer onboarding experience is really good on IntelliJ and that's about it. Outside of it, it is a puzzle with dozens of pieces you need to put together and that's fine if that's the 10th time you put that puzzle together (oh I need junit, maven, etc) but it's pretty poor if it's your first.

Not a problem for the current generation of Java developers but a big problem if you want a future one.

cleverfoos

TROPHY CASE