kodebach

No it doesn't, but it also doesn't need it. Whereas in Java you write:

  if (obj instanceof Point(double x, double y)) {
      foo(x,y)
  }

Kotlin with its smart cast feature lets you do

  if (obj is Point) {
    foo(obj.x, obj.y);
  }

Spring is slow because it scans the classpath, uses reflection and generates proxy classes all at startup. You can avoid some of that using the Spring AOT feature in newer versions.

Or you can just use a different framework like Micronaut which does none of that and uses an annotation processor at compile time instead. (Similar to Spring AOT, with fewer limitations)

What wasn't "good enough" for you in Kotlin?

Sure, Java is slowly getting most of the features and sometimes even in a better form because they control the runtime (virtual threads arguably just work). But IMO Java is still incredibly verbose, Kotlin's type system is just better and I've genuinely never come across anything that would be easier to do in Java. Even virtual threads can be used from Kotlin.

Most importantly IMO the JVM ecosystem has lots of solid, battle-tested, enterprise-grade frameworks like Spring and Quarkus, which do all the heavy lifting for those kinds of applications. The code can still be verbose, but that is solved by LLMs, as you said.

Rust has all the individual bits you need as libraries (web server, database access, etc.) but you have to wire it all together yourself. Sure LLMs can do that too, but how do you know the LLM did it correctly? There could be complex interactions between the individual libraries.

Using a complete framework solves that, you know its bits will work together correctly. It also makes the code structure of different applications look more similar, which probably helps LLMs understand it better too.

I'm no expert, but wouldn't a basic hardware firewall that allows incoming, but not outgoing connections solve the issue? Wouldn't even basic VLAN isolation achieve the same? The humans can still open a TCP connection, SSH tunnel, etc. from the outside to remotely get data out of the training environment. But the agents cannot reach anything outside their isolated network.

I can't prove it, but I still think this is (partly) due to a recent EU regulation majorly backfiring. I can't remember which one it was, but one of the recent regulations mandates that devices get updates for a certain period. Within that period a manufacturer must provide each update for all their devices in a short timeframe. The intention was to prevent flagships getting updates immediately and lower end devices having to wait months. However, due to some (also well intentioned) wording about open source, the release of the source code is counted as the first release of an update and starts the timer. I'm pretty sure Google is delaying public AOSP updates to give their partners (mainly Samsung I suppose) more time to finish building their updates on top of AOSP.

Who says inserting those NOPs didn't break other behaviour that OP isn't using. And then there's also Hyrum's law. This whole thing could be very non-trivial.

Fixing a bug for everyone is very different from fixing the bug just for yourself

And Apple platforms will use Swift until Apple invents a new language, Android still uses Kotlin, C++ will stick around for decades in automotive and aerospace where you need loads of expensive certifications and who knows if we'll ever be rid of COBOL (even with AI rewrites execs might not wanna risk the switch).

Do you have an example of where "the ideas don't combine well"? Or where an imperative approach is truly better?

In my experience the solution is often to use the appropriate architecture underneath your UI layer. Basically you build a data structure that represents your UI and always hand this entire structure to the declarative UI layer. Underneath the UI layer, you can still use imperative code to manipulate the data structures. The benefit of the reactive/declarative approach is that you don't have to think about how changes in the data need to be reflected in the UI. That's the framework's job.

Note: With "data structure" I don't mean "build a shadow DOM". I mean something specialized to your use case.

The goal of the reactive/declarative approach was never to be more performant than imperative code. The goal is to more easily build UI that is performant enough and functions correctly. With imperative UI code it is incredibly easy to forget an edge case in your update logic.

Well if the cookie comes from a third party it implicitly allows tracking.

Also AFAIK the Google Fonts question (is the IP alone already PII, if Google has no way of tying the IP to a person) has not been decided by the ECJ yet. There've only been decisions by lower level German courts that are still in dispute.

Based on my understanding of the GPDR, this scheme wouldn't be anonymous, if the salt is stored anywhere. Using the salt(s) and the full list of all your users emails, you could find out which one matches the hash, thereby linking the analytics to the original PII. Of course that's a rather ridiculous idea, but AFAIK the GDPR doesn't put any qualifiers or limits on "it's not anonymous if the PII can be recovered with extra data".

Google already announced the "Advanced Flow" that lets users override the verification. Yes, it's quite complicated, but it shows Google isn't trying to completely close down Android (yet). All this outcry is just lead to a boy who cried wolf situation. ADV is gonna become active, 90% people won't notice the rest will (begrudgingly) use the Advanced Flow. If Google then changes their mind actually does what F-Droid claims right now, nobody's gonna listen.

IMHO F-Droid is just mad because their store model of "developer publishes source code, F-Droid builds and signs the APK" would put immense liability on F-Droid. After all with that model F-Droid owns the private signing keys and now has to register them with Google. If they let a single malware app slide through, Google might designate F-Droid as a malware provider and block everything ever published on F-Droid. (Sidenote: Last I checked F-Droid had nothing in their policies that forbids publishing malware, just that it has to be open source) If you ask me this store model was always stupid and completely missed the point of having signed APKs. I think they also have a newer model where they don't own the private keys anymore, but there's still tons of legacy apps.

Of course Google might have been open to talks about some kind of verified app store program allowing F-Droid to operate under different terms. But that's certainly out the window after all the fear mongering, hyperbole and straight up propaganda F-Droid has put out in recent months.

Since Apples App Store is DMA compliant, the EU won't do anything against this far less restrictive change from Google.

If you're building the APK, you're probably installing via ADB, in which case none of the changes apply

There actually is in some regions. For example in Germany any publication must include an Impressum with details about the author and publisher. This requirement also applies to websites

It's actually worse. I just signed up with a dummy email and the page says they need your email to create an account so, they can store the icon kits you've created. That kinda makes sense. But at no point do they ask you whether you want to subscribe to any form of newsletter. AFAICT not even the privacy policy mentions anything about that. You're just subscribed automatically. So by definition anything not crucial for creating the account is literal spam. I'm not even sure that's legal under GDPR.

But the thing that might actually be killing their reputation is that their mails seemingly come from different emails all looking like bounces+18741050-ecba-jopudmulwqqsumjwub=nespj.com@email.fontawesome.com. But even worse than that, the "confirm your email" email and the following "finish account setup" email came from two different sub-domains. Maybe this is just a new attempt to get around Google's spam filter, but it seems like the worst thing you could possibly do when sending emails.

As strange as it is, but Austria is quite far ahead in terms of eIDAS since we've had Handysignatur for more than a decade. I wouldn't be surprised, if the Germans are planning to support hardware tokens, but haven't had the time yet.

I agree, you should be able to run anything you want, root your device, etc., but you also have to accept the consequences of that. If an app can no longer verify its own integrity, certain features are simply impossible to implement securely.

Think of it this way: A physical ID (which is what we're trying to replace here) also has limitations, it looks a certain way, has a certain size, etc. Just because somebody wants a smaller ID or one with a larger font or a passport in a different colour or whatever, doesn't mean that this should be allowed or possible. Some limitations exist for a good reason

Simply because the law was written that way. But also the whole idea of identity verification becomes pretty useless, if there is no chain of trust. You could run a modified client that lets you assume any identity you choose, exactly the opposite of what eIDAS is trying to achieve.

Starting from their first announcement of this, Google has explicitly asked for comments and feedback from affected developers. They have a Google Form for exactly that linked on all the announcement pages.

The exceptions for students/hobbyist were always promised, but the "advanced flow" came later based on this feedback. AFAICT Google has, so far, only made things better after the initial announcement. I don't see why we shouldn't give them the benefit of doubt, at least until we have some specifics.

Pushing this open letter out just days/weeks before Google promised the next major update just seems off.

It is a non-sensical ruling. But IIRC the reason was basically that while Apple and Google did basically the same shit, only Google kept a written record of their monopolistic behaviour, so only Google was found guilty.

However, there is a relevant court case here. The one about Samsung's "Auto Blocker" (https://arstechnica.com/gadgets/2025/07/samsung-and-epic-gam...). Epic Games sued because Samsung made it too hard to install apps from "untrusted" sources. This may be a reason why Google is now trying to make the process more difficult on the developer side instead.

My guess is that Android 17 will show the registered name of the developer of the app you're trying to install. With stolen IDs you can only get accounts for individual developers not for organisations.

When a scammer pretending to be your bank tells you to install an app for verification and it says "This app was created by John Smith" even grandma will get suspicious and ask why it doesn't show the bank's name.

Like you said, for years now they have added more and more restrictions to address various scams. So far none of them had any effect, other than annoying users of legitimate apps, because all the new restrictions were on the user side. This new approach restricts developers, but is actually a complete non-issue for most, since the vast majority of apps is distributed via Google Play already.

In the section "Existing Measures Are Sufficient." your letter also mentions

> Developer signing certificates that establish software provenance

without any explanation of how that would be the case. With the current system, yes, every app has to be signed. But that's it. There's no certificate chain required, no CA-checks are performed and self-signed certificates are accepted without issue. How is that supposed to establish any form of provenance?

If you really think there is a better solution to this, I would suggest you propose some viable alternative. So far all I've heard for the opponents of this change is, either "everything is fine" or "this is not the way", while conveniently ignoring the fact that there is an actual problem that needs a solution.

That said, I do generally agree, with you that mandatory verification for *all* apps would be overkill. But that is not what Google has announced in their latest blog posts. Yes, the flow to disable verification and the exemptions for hobbyists and students are just vague promises for now. But the public timeline (https://developer.android.com/developer-verification#timelin...) states developer verification will be generally available in March 2026. Why publish this letter now and not wait a few weeks so we can see what Google actually is planning before getting everybody outraged about it?