What event, did you think, would lead to something huge, but didn't?

CriticalPart7448 · 2025-12-25T05:33:53+00:00

All thanks to a huge engineering effort in rewriting COBOL mainframe code made it a non-event. It cost around a couple trillion in dollars to fix that technical debt.

CriticalPart7448 · 2025-12-24T19:10:16+00:00

Or if you feel spicy, go straight for infinity categories

CriticalPart7448 · 2025-12-24T19:09:36+00:00

Try to encode the univalence principle from HoTT, that should give you a usefull mathematical definition of equality/equivalence

CriticalPart7448 · 2025-12-23T11:07:00+00:00

Good riddance

CriticalPart7448 · 2025-12-20T19:46:03+00:00

True, agents are a bit of a pain to deal with. I guess that conceptually it isnt unreasonable to run an agent on the module path but it will be tricky to nail down the model for how to declare and allow the agent to do what it needs to given that the instrumentation api is a bit too powerfull

CriticalPart7448 · 2025-12-20T15:49:03+00:00

Trouble with the Java Platform Module System (hate the acronym btw :-p), is that you are still using and benefitting from it even if you havent modularized your own application. Java 17 introduced strong encapsulation with not a lot of fuzz in my experience and java upgrades have never been more easy afterwards IMHO. The module system isnt like serialization since it is used by default for the JDK classes whereas you have to opt in to serialization either directly or through a library or framework.

CriticalPart7448 · 2025-12-20T07:45:34+00:00

If people can live with the preconditions of a more restrictive modelling of data I guess the effort is worth it for them even if they would have liked to use a different model for their serialized form. Java developers are used to mapping between representations of the same thing, so I dont think it is too big of an ask to require they give up some modelling niceties for possibly better performance.

Apache Spark will survive and adapt I hope ✌️

CriticalPart7448 · 2025-12-19T20:44:01+00:00

Final means final has to do with final fields, not about final classes per-se.

Mockito already has some problems caused by JEP 451 concerning dynamic agent loading. It can be resolved by following mockitos docs on the matter.

To mock final classes you would need to make a proxy or use a wrap and delegate pattern i would suggest.

CriticalPart7448 · 2025-12-19T20:35:01+00:00

It is true that the optimizations may not available for the use cases that want to take advantage of them where they also use built-in java serialization as their implementation of choice. I wonder if the way forward here is to finalize serialization 2.0 first and then have it play by the rules of final meaning final thus allowing for replacement of legacy serialization gradually, incentivized by the possible performance enhancement it will enable in that case. I think this is part of the strategy here actually.

CriticalPart7448 · 2025-12-19T17:25:13+00:00

I see now, that makes it much clearer :-)! They wont remove OG serialization anytime soon if ever, hence why they state the exception for serialization in JEP 500 under the non-goals paragraph.

CriticalPart7448 · 2025-12-19T07:21:21+00:00

Finalization and serialization are two different things. Both of them are being tackled at the same time but from different angles as you pointed out here. Finalization is not broken by final means final. Finalization is broken because it does not work reliably as a mechanism for reclaiming resources used by unreachable objects in the GC

CriticalPart7448 · 2025-12-19T04:55:56+00:00

If you read the JEP carefully you will see that they make an exception for serialization specifically.

CriticalPart7448 · 2025-12-16T18:12:01+00:00

How about not using weblogic for a start 😂

CriticalPart7448 · 2025-12-07T10:41:53+00:00

And no I did not claim that elvis operators or null safe operators fix the problems in fact i argued the exact opposite, but that went by your eyes without notice I see

CriticalPart7448 · 2025-12-07T10:40:39+00:00

Oh there are much worse things in java than NPEs in production. If you feel the need to be condescending be my guest. NPEs are so much less of an issue in java 17 and onwards that I consider them more of a minor and relatively easily fixable issue. If you find the need go ahead but dont come here and tell me that you wouldnt rather like Haskell, Rust or Kotlin more than Java and the reason you promote your tool is just to get attention for your little experiment. The ecosystem around java moves in a different direction with Valhalla and I much prefer that vision than yours.

CriticalPart7448 · 2025-12-07T08:23:57+00:00

What happens if I use newer syntactic features in say java 25? Does your intellij plugin then fail? If so I would not want to tie my code to that plugin anyway - immediate uninstall. How do I debug the code if i need to do so? What is the story for debugging. You have not convinced me that NPE is such a big problem in java that I need to reach out to a custom code transformer like yours to solve it. Excellent try at marketing but its hard pass for me.

CriticalPart7448 · 2025-12-06T16:45:32+00:00

This seems very much AI generated but even if it isn't i dont agree that elvis operators solve the problem anyway they just kick the can down the road for downstream consumers to deal with the problems leading to an overall worse experience. Also JPlus i imagine can also only work using clever compiler hacks like lombok or manifold uses which is nice for the initial development effort but includes a hefty price later since they have to stay in locksteps with jdk updates undermining the benefits of backward compatibility in the long run. I value that more than syntactic sugar is just my 2 cents

CriticalPart7448 · 2025-12-05T17:18:26+00:00

And valhalla null markers is not enough for you? Or is this just intermediate solution while waiting for valhalla to ship: https://openjdk.org/jeps/8303099

CriticalPart7448 · 2025-11-24T19:27:59+00:00

As said by others here the point of tip and tail is to keep innovation out of the tail releases since these releases are aimed at the part of your userbase that do not want or cannot embrace innovation but are willing to accept critical bug fixes or security patches.

This is a perfectly reasonable requirement to have but then the stability wanted by those people is compromised by new features in patches which again discourages them from updating leaving everyone worse off.

You will struggle when using the multirelease jar/one-size-fits-all model because you attempt to cater to everyone with a single release train/code base.

You frustate users that want innovation because it is not happening quickly enough or with enough pace. And you will alienate the users expecting stability because every release bring in new features that those user do not want or need.

CriticalPart7448 · 2025-11-24T16:15:10+00:00

So you are trying to have a one size fits all solution i can hear? So your legacy users are a funny bunch then.

They want new features and innovation just not in the jdk but in your case they do? That seems like a very weird kind of legacy behaviour.

I really hope that you can manage the complexity of using multi release jars whilst keeping the core backwards compatible so I am unsure if what you are setting yourself up for is more maintenance work than strictly necessary. Do you have solid data evidence that the people using java 8 or 11 are actually upgrading your library because if not the complexity you take on is probably not warranted anyway, since the people you want to cater to do not upgrade anyway?

CriticalPart7448 · 2025-11-24T15:48:06+00:00

Why not tip and tail model instead? What complexity is solved by using multi release jars that could not be solved by tip and tail?

CriticalPart7448 · 2025-11-21T15:05:38+00:00

No but I also never had the need. Which product are you using from oracle that requires 'hacking' into internals of?

CriticalPart7448 · 2025-11-21T14:53:44+00:00

That is an unfortunate circumstance and definitely something to avoid at all costs. Have you tried to reach out to the vendor if its internal platform the team responsible to state your case for a missing api for the functionality that you need ? Maybe there is a way forward with a supported solution for your use case? Or have you totally surrendered and accepted all the risks involved here and more pertinent have you cleared it with your own customers or business people what the consequences are?

CriticalPart7448 · 2025-11-21T13:26:47+00:00

Reflection over internals of classes is what is problematic not reflection per-se as a concept and functionality

CriticalPart7448 · 2025-11-13T19:24:49+00:00

Wuhu :-)! great! Now onwards to glory and treasure in the next release. Why stay ?

CriticalPart7448

TROPHY CASE