There is 2 softwares I will buy for myself if I still use Windows: WinRAR and Internet Download Manager. In fact, I will buy them in the future regardless the Windows usage.
IMO compile-time annotation processors such as Lombok and MapStruct are far from the most magic part of Java. They're straightforward code generators. Their impacts is localized to where they get applied and you can actually see the code that's generated. They're very good for diminishing boilerplate. They're no worse than Rust's very standard #[derive(xyz)] proc macros.
Having the code being generated on the fly (instead of a one-shot) means it follows the rest of the structure it's derived from i.e. equals() and hashCode() don't risk to be forgotten when adding a field to a class (hello maddening Map<> lookup errors)
Also, yes, Lombok is _funky_ in how it works but there are "pure" alternatives like AutoBuilder and AutoValue if one cares.
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.
Reporters who only capture pictures on an iPhone and not a "real" camera, and who also never need to edit the photo to crop off or obscure identifying information, innocent bystanders/victims, gory violence or nudity, etc...
The problem is real, but this solution seems to not really solve it in any practical sense.
Reporters who only capture pictures on an iPhone and not a "real" camera, and who also never need to edit the photo to crop off or obscure identifying information, innocent bystanders/victims, gory violence or nudity, etc...
So, 90% of photojournalism outside of the major cities, then.
You want to do all that, then still can prove the picture is authentic. The editing history show what had been changed compare to the previous version, from the color adjustment to blur areas... it's not about preventing editing, it's about proving the authenticity when needed.
> The editing history show what had been changed compare to the previous version, from the color adjustment to blur areas...
That's not a thing. Straight from Apple:
"When a photo is taken in the new Reference mode, the camera captures signed sensor data that Private Cloud Compute develops into an unalterable reference image. Reference images can be viewed in the Photos app alongside the main image"
So this only helps prove anything if you can share the original, unedited image. You can share it alongside an edited one, but you must also be comfortable sharing the unedited original if you want to prove you own an iPhone 18 Pro. Er, I mean prove it's "authentic"
Now I think C2PA had allowances for what you're talking about, but that also ended up resulting in it being easier to break.
You don't need to share the original image with everyone, just like how journalists don't share their audio recordings from interviews with everyone. You share with an editor. Or a court.
Yes, which is why this doesn't really do much. Readers still have to primarily rely on trust for whether or not they believe the news and who is reporting it.
reply