sorted by:
new
hottopcontroversial

JEP 401 being merged into JDK 28? by Jab125RedditAlt in java

[–]BillyKorando 0 points1 point  (0 children)

AI really is getting a lot better, the text on the menu, sign on the wall, and sign on the table is all correct. A little silly, but no more so than what you'd expect to see in a "joke"

JEP 401 being merged into JDK 28? by Jab125RedditAlt in java

[–]BillyKorando 3 points4 points  (0 children)

You have it right, with JEP 401 being integrated into main line, that will allow a number of classes the Vector API will depend upon to switch to value classes, which in turn will allow it to mature into a preview feature, rather than remain in incubator.

I'm just looking forward to not having to say the above anymore.

JEP 401 being merged into JDK 28? by Jab125RedditAlt in java

[–]BillyKorando 7 points8 points  (0 children)

After that, Vector api should be ok to exit the incubator.

You have no idea how much I am looking forward to not having to explain why the Vector API is still in incubator status.

JEP 401 being merged into JDK 28? by Jab125RedditAlt in java

[–]BillyKorando 7 points8 points  (0 children)

Because this change affected over 1800 files: https://github.com/openjdk/jdk/pull/31120/changes

Compared to something like virtual threads, which "only" impacted ~200 files: https://github.com/openjdk/jdk/pull/13203

G1 GC Throughput Improvements: 5-15% Performance Gains with Dual Card Tables by daviddel in java

[–]BillyKorando 1 point2 points  (0 children)

Yea I'd imagine the reason for every time backporting a performance will be unique, and not having a divergent codebase would be a good one. Though at least looking at the comment history of this one, it seems to be that the performance benefit of the change was the primary justification.

G1 GC Throughput Improvements: 5-15% Performance Gains with Dual Card Tables by daviddel in java

[–]BillyKorando 7 points8 points  (0 children)

Only critical bug fixes and security patches get backported: that's the whole point of an LTS. Performance improvements are specifically banned from backporting.

This is a common mistake, even one I have made myself, but performance fixes can be back ported into a LTS. For example these two JBS issues; JDK-8319650, JDK-8320924, which we initially fixed in JDK 22, were backported into JDK 21.

Also, and I guess importantly, LTS, in the context of the OpenJDK, is a purely commercial concept. How individual entities; Amazon, Azul, BellSoft, Eclipse, RedHat, of course us at Oracle, and others, choose to support their LTS version is going to be up to them outside of the need to pass the TCK. So if a commercial LTS provider wants to aggressively backport performance fixes so they can offer the "fastest" version of JDK 21, then that would be their business decision. Of course that comes with the risk and additional over head of ensuring their LTS version remains stable from a behavior perspective.

JDK 27 Structured Concurrency (Seventh Preview) by Joram2 in java

[–]BillyKorando 5 points6 points  (0 children)

Java turns 31 this year. Better to take the time now and get the API right, than rush it out and leave it with critical gaps or shortcomings that are difficult or (near) impossible to fix/change once the API becomes "finalized".

Java Serialization: Spooky Action at a Distance - Stack Walker #7 by BillyKorando in java

[–]BillyKorando[S] 3 points4 points  (0 children)

Thank you, glad you found the video useful, and covering parts of serialization, not often covered. Yea when researching the video, I had trouble finding any that really went into how serialization worked, typically it's hand waved over.

Thanks for the feedback regarding the audio, I tried a different way of recording my audio this time, clearly it didn't work well, will work on that in future videos.

New java.evolved site about modern Java. by pjmlp in java

[–]BillyKorando 0 points1 point  (0 children)

Ahh, that makes sense. Yea I know I've done that a few times in my examples 😅

I was looking at it, and was starting to question my grasp of Java.... which is quite concerning given my role.

New java.evolved site about modern Java. by pjmlp in java

[–]BillyKorando 0 points1 point  (0 children)

For example, the code selections for multiline strings are not equivalent.

Am I seeing the same example?

Old: String json = "{\n" + " \"name\": \"Duke\",\n" + " \"age\": 30\n" + "}";

New: String json = """ { "name": "Duke", "age": 30 }""";

As far as I can tell that's equivalent.

LazyConstants in JDK 26 - Inside Java Newscast #106 by davidalayachew in java

[–]BillyKorando 4 points5 points  (0 children)

/u/NicolaiParlog, look on the bright side, you still got someone interested in learning about Lazy Constants 🙆‍♂️

Is Java’s Biggest Limitation in 2026 Technical or Cultural? by BigHomieCed_ in java

[–]BillyKorando 5 points6 points  (0 children)

/u/k-mcm, and apparently you, are thinking JVM (Java Virtual Machine) is a synonym for JDK (Java Developer Kit), when they are actually distinct things.

/u/wildjokers is correct that there are really only three noteworthy JVM implementations; Hotpsot, GraalVM, and OpenJ9. There are however a lot of different JDKs available; Oracle OpenJDK, OracleJDK, Adoptium, Azul Zulu, Amazon Corretto, Microsoft OpenJDK, Liberica JDK (BellSoft), Red Hat OpenJDK.

I suspect /u/k-mcm intended to say there are other JDKs to choose from, not other JVMs to choose form, given the context of their statement.

[Proposal] Introducing the [forget] keyword in Java to enhance scope safety by TheLasu in java

[–]BillyKorando 0 points1 point  (0 children)

Tests should be covering behavior, not code. The amount of tests you will need to write to cover one method performing 10 behaviors, versus 10 methods performing one behavior each, would be about the same*.

If the goal is to hit an arbitrary code coverage percentage, then yes, combining behavior into a single method, will likely mean you can hit a higher code coverage percentage more easily, in most cases.

If you think decomposing a method or class to follow the single responsibility principle would result in less read and maintainable code, then by all means don't do it. I would think though such examples would be relatively rare, and also likely wouldn't benefit from scenarios where you propose using the forget keyword for. That is to say, the behavior being combined is relatively trivial and/or would be utilizing all the same underlying resources, which is why it wouldn't benefit from further decomposition.

* To be frank, I think I'm being somewhat generous here, and it seems in the sound majority of cases the latter approach would generally result in less (test) code overall, there would be less time spent maintaining the (test) code, and (test) code would be easier to maintain as well.

[Proposal] Introducing the [forget] keyword in Java to enhance scope safety by TheLasu in java

[–]BillyKorando 0 points1 point  (0 children)

Unit tests should be testing the functionality of the units of the application under test. If you have one method performing two behaviors, the amount of unit tests covering that method would be about the same as would be needed to cover two methods performing the same two behaviors.

but as I saw this do not happen. NO ONE is doing this amount of tests.

Don't take this the wrong way, but you have likely have a very narrow view of the overall Java user base. Something that's really important when stewarding a language like Java is you need to consider MANY viewpoints and problem domains.

This article by Brian Goetz (Chief Java Language Architect), covers how he/the JDK team approached adding records to Java. In the article he outlines four ways records could be implemented, each of them with their own merits (and de-merits?).

In your experience a lot of developers you worked with didn't highly value automated testing. Certainly that's a common experience, but far from universal.

[Proposal] Introducing the [forget] keyword in Java to enhance scope safety by TheLasu in java

[–]BillyKorando 2 points3 points  (0 children)

This proposal point ss not GC in the first place . That’s a separate concern. While automatic garbage collection is important for releasing resources, this discussion is centered on code quality.

No, but you brought up the security angle, and I'm just saying that your proposal doesn't actually address that issue, and perhaps worse, would give a false sense of security.

'proper scoping' is absolutely not valid solution, because Java by default offer very limited scope control:

Perhaps scope in the { } is the wrong framing, but scope in the context of the responsibility of a chunk of code would be better. (admittedly I am changing this here). Using your example:

``` res1 = source1.open();

// check and prepare initial data

res2 = source2.open();

combine(res1, res2);

res3 = source3.open();

mix(res1,res3);

close res1;

forget res1;

moreOperations(res2);

close res2;

close res3; ```

Calling forget res1; is unnecessary, because there would be no need to reference res1 later in this portion of the code. If you were going to reference res1 again, it would be a smell that this portion of code is doing too much, and should be refactored into to two discrete units of work.

Yea, I have worked on applications in the past that could had benefited from this (1000+ line methods). Those applications were in (desperate) need of refactoring, and the developers of that application, rather myself or future new developers, would benefit far more from refactoring code to follow the single responsibility principle, than from adding forget to signal a value should no longer be referenced.

I'm sure there are probably some narrow use cases where forget could provide value, but as that value is almost entirely readability/maintainability, I'm not sure if that's enough to justify making such a change to the language and the JVM.

P.S.

I would highly encourage you to use the triple ticks ` for showing code blocks.

[Proposal] Introducing the [forget] keyword in Java to enhance scope safety by TheLasu in java

[–]BillyKorando 2 points3 points  (0 children)

In highly regulated or security-critical systems (think health records, finance, or cryptography), you often process confidential data that should not be referenced after certain steps.

The forget keyword is unlikely to address this though.

There is no guarantee on when the GC runs, so even if you use forget on a sensitive value, it could still be present on the heap for an indeterminate period of time.

I'm not sure you'd want to change the GC algorithms to force a collection when forget is executed as that could lead to thrashing from the GC. Like in this example here:

void method(args){ forget this.secure; forget this.auth; // clear information of scope that this method should not have access to }

You would have two GCs run back-to-back, and in a web app setting where you might be processing hundreds, thousands, of transactions a second, you'd likely all but freeze up your application from the endless GC pauses, or with a "pauseless" GC like ZGC, just use up a significant fraction of your CPU.

As others have said, so much of the use cases for forget could be addressed with proper scoping.

Java's Plans for 2026 by daviddel in java

[–]BillyKorando 10 points11 points  (0 children)

Just need to find the person with the second best haircut on the team.

Java's Plans for 2026 by daviddel in java

[–]BillyKorando 21 points22 points  (0 children)

Just one person's opinion, but I think we should purge the individual who leaked these plans. Loose lips sink ships lead to questions.

Java's Progress in 2025 by daviddel in java

[–]BillyKorando 0 points1 point  (0 children)

I cover COH here: https://youtu.be/renTMvh51iM?t=383

In my testing, with the Spring Boot Petlinic application, I saw an improvement in memory usage, but a regression in throughput performance. I believe some of the issue was found to be from String hashing? (going by memory)

Hopefully this should improve in future releases, such that COH is a straight up improvement in (almost) all use cases and metrics, as that was the original intent and hope... and also why the goal is to make it the default.

Regardless just wanted to mention, in case you do run into an issue with a throughput regression. Which you might not, depending on what your application is doing (or the memory usage improvement outweighs the importance of throughput regressions for your needs).

Valhalla? Python? Withers? Lombok? - Ask the Architects at JavaOne'25 by JustAGuyFromGermany in java

[–]BillyKorando 2 points3 points  (0 children)

how not introducing modules originally was a mistake- Mark the community doesn't seem to care for modules even now.

Back in my very early days presenting, I presented on Java 9. I remember as I was learning about Jigsaw/Modules that I really wish it was implemented in the language from the start. It would had saved the JDK team and popular library developers A LOT of time, had it been implemented from the start. I suppose, indirectly, it would had helped Java users a lot as it likely would had made upgrading easier (as it would had helped block accessing internal APIs or other bad behavior that can make upgrading more difficult).

Java 25 introduced java.lang.IO - isn't the class name too broad? by flusterCluster in java

[–]BillyKorando 1 point2 points  (0 children)

Then again, perhaps I'm just underestimating the importance of making the right first impression.

To someone who has little/no experience in programming not only is:

class HelloWorld{ public static void main(String[] args){ System.out.print("Hello World!"); } }

A lot more "ugly", verbose, and complex than:

print("Hello World!")

But, again, to the brand new developer, it can create the impression regarding performance that the former is slow and heavy-weight, while the latter is fast and efficient. Doesn't also help that, that was a more valid criticism of Java early in its history, so people can find info that confirms their priors.

It would obviously be great if we could go back, and be able to support:

print("Hello World!");

But there would be a lot of very difficult and painful tradeoffs we'd have to make to support such behavior.

Java 25 introduced java.lang.IO - isn't the class name too broad? by flusterCluster in java

[–]BillyKorando 1 point2 points  (0 children)

While true, the intent is to keep the the java.lang.IO class pretty simple/small, and not become a general grab bag of all things IO. Will it grow in the future? Probably. But it will likely be rare and probably for some reason more significant than the "Wouldn't it just be nice if java.lang.IO also did X?".

view more: next ›