samus

You can go with a lot less code if you don't care about proper cleanup of resources.

The argument was not about stopping Chrome from becoming integrated into Android.

> It's easier maintaining a fork of Blink than an entirely different engine. Google being the primary maintainer doesn't mean that browsers can't make large forks.

Maintaining a fork is not fun as taking patches from the origin repo becomes more complicated the longer the fork exists and the bigger the divergence becomes.

> How is having N engine developers implement some new addition to the EMCAScript or CSS standard for each of their engines not duplicated work?

It would be duplicated only if they all maintained, say, a Blink fork.

Except one does since Google is the primary maintainer. Anyway, work on other browser engines is not duplicated or wasted.

And that market share is maintained by integration with Android and low-key sabotage of others browsers, especially Firefox. Similar to how Microsoft maintained its monopoly decades ago.

Sanctions

Nah, withers are generally useful.

I mean, it's a smaller issue in a K8s environment as it will just spin up a fresh pod.

Yes, that's what they do. The brine is stored in huge pools next to the extraction site.

> And thousands of manual get/set functions don't?

My statement doesn't apply to mere data carrier classes. Anyway, getters and setters are an antipattern as well since one can just as well make all the fields public.

> Thousands of lines of builders don't?

With withers most of these will go away. And a class will be able to choose which things can be set, which is not the case for initializers.

> But it's not synchronous code, is it? It's easily dozens of lines wrangling Futures, and Thread initialisers, and Executors, and..

That code won't look that much different with async/await.

With withers they will become less verbose. In the best case you'll only need to define a value type and a constructor taking an instance of that.

That's highly unlikely since it's standard practice in the industry, thus it's unnecessary to state it. Also, they didn't hack a hobby developer's website, but a prospective business partner who has enough money to sue them into oblivion. No way this wasn't announced.

Announcing that their agent restrained itself even though it got hold of a live token is necessary to convince prospective clients. You don't want a pentester that doesn't show this kind of reserve!

IMHO, Dex is a historical artifact. In the past it was thought that the format provides benefits for JIT compilation because it's register based, which turned out to not be case.

That's important since this capability has been removed from OpenJDK a long time ago.

Dynamic runtime agents are deprecated functionality. In a few releases agents have to be specified at JVM startup. Mockito (I bet it's the most common user of that feature) and current JVMs already warn about it.

Another issue with Lombok is that it requires IDEs and other tools to be aware of it. Missing integration with other annotation processors only causes "definition of external element not found"-style errors.

Annotation processors were actually carefully designed to prohibit what Lombok does. Lombok hacks into javac and manipulates the AST. Unsurprisingly, there is breakage with every Java release and with other tools that work similarly, like Google Error Prone, which gets a pass since it's read-only and the build will still work if you turn it off.

Class loader and reflection shenanigans can be shut down with the module system.

Garbage collection matters when you stress the JVM to its limits. Don't do that.

> avoid other kinds of "sloppy" coding encouraged by checked exception such as catching exceptions locally without doing the right thing globally.

That's a code style and code review issue; each project has so set standards regarding how errors are dealt with and enforce them throughput the codebase.

The problem with array out of bounds is that you'd need to reason about arithmetic expressions over natural numbers. However, in general that's a very thorny problem since one runs squarely into [Gödel's incompleteness theorems](https://en.wikipedia.org/wiki/G%C3%B6del%27s_incompleteness_...). Working around it requires painful restrictions or cause uncertainty over whether the compiler will apply certain optimizations.

That one works pretty much the same way as NullAway, which is kinda unsurprising because of the name and because of who made it.

So the whole webserver dies instead of just a worker thread unwinding its stack?

> Congratulations. You've added another build tool and sprinkled your code with ugly annotations and ifs and Optional Optional.of(x).map(y) all over the place to get the same thing you'd get by moving to Kotlin.

You deserve the strawman award of the year.

NullAway and JSpecify encourage making as many types non-nullable as possible, thus they can actually also advice about removing redundant null checks. Nullable types become the painful exception that visibly spreads through the codebase, which discourages writing code that relies on null.

Optional doesn't enter the picture at all. NullAway kills their usecase within ones own code. They are anyway only recommend as return types to force others to check for an emoty case, but I think Optional will become fully optional when the Java platform gets nullable types on its own.

Google Error Prone is a code linting tool that's very useful in its own right, and NullAway is just another plugin.

> I also don't see the case for stability. Yes, if you're still on JDK 8, it would probably chug on for a couple of years. But we were talking about greenfield projects and newer JDK go EOL much faster. If you want patches, you'll have to run your app to a newer JDK, which may break a couple of things. Rust (within the same edition) or Go (within the same major version) break less than that.

Java also breaks very few things. Breaking binary compatibility is a no-go since it's a core promise of the platform. The only thing in the surface language that has ever been changed is the meaning of the underscore as an identifier, as well as the behavior of == in upcoming Project Valhalla.

> As far as runtime compatibility goes, Rust and Go apps ship with the runtime.

Java applications can also be shipped together with the runtime.

> Productivity is something that is dead if you are AI-heavy.

Nevertheless, making constructs available to express intent more clearly should also help LLMs to not go off the rails.

> Some of those ways come from just plain object initialisers. Which are amazing and sorely needed in Java.

They really aren't, and they are IMHO an antipattern since they break encapsulation. One might argue that encapsulation doesn't matter with mere data classes, but Java will cater to that use case by introducing withers.

I'm sure that there is a tool like Checkstyle that can be used to ban features.

I read nine JEPs. Sure, some are re-Previews, but they are important since they often contain improvements from community feedback. Specifically, it would be quite unwise to finalize the Vector API before Project Valhalla. Apart from that, I'm sure that there are lots of minor visible changes that didn't get a JEP.

Anyway, not every release can be filled to the brim with new features, and people were also kinda busy whipping Project Valhalla into shape. INHO it's still preferable to stick to a predictable schedule instead of creating uncertainty in the community.

> - object initialisers

Probably not a good idea since they break encapsulation by exposing internals of the class. There is work on withers, which should make defining builders far simpler.

> - extension methods.

They make code harder to understand. If they ever come they would have to be declared at the top of each source file.

> - null coalescing operator

Maybe we'll get it, maybe not, but they want to first introduce proper nullable types, lest there is a risk of painting themselves into a corner.

> - async/await

There is a fork in the road, and Java has gone into the direction that leads to virtual threads and Structured Concurrency, for the simple reason that there is no simpler syntax than plain old synchronous code.

> - ... generics metadata in runtime

There are plans to add a kind of reified generics, so maybe we'll get it.

For the simple reason that class files with JVM bytecode are the standardized intermediate representation. Therefore, duplicating the frontend is wasted effort.

They probably negotiated a "permission to attack" before letting Strix off the leash, as pentesters usually do.

It might very well be possible that there were API endpoints that exposed way too much information. I also think that this wouldn't qualify as "scraping".

That's basically what I said...