samus

3 ms·

31.
by samus 10d ago
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 G
32.
by samus 10d ago
> 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 standard
33.
by samus 10d ago
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 theore
34.
by samus 10d ago
That one works pretty much the same way as NullAway, which is kinda unsurprising because of the name and because of who made it.
35.
by samus 10d ago
So the whole webserver dies instead of just a worker thread unwinding its stack?
36.
by samus 10d ago
> 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
37.
by samus 10d ago
> 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
38.
by samus 10d ago
> 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 does
39.
by samus 10d ago
I'm sure that there is a tool like Checkstyle that can be used to ban features.
40.
by samus 10d ago
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,
41.
by samus 10d ago
> - 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 harde
42.
by samus 10d ago
For the simple reason that class files with JVM bytecode are the standardized intermediate representation. Therefore, duplicating the frontend is wasted effort.
43.
by samus 11d ago
They probably negotiated a "permission to attack" before letting Strix off the leash, as pentesters usually do.
44.
by samus 12d ago
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".
45.
by samus 12d ago
That's basically what I said...
46.
by samus 13d ago
Stock Dark Reader browser extension works well for me.
47.
by samus 13d ago
Not really; `-type app-image` merely runs jlink and is intended to let you edit the bundle before calling jpackage again and create the installer. You need the tools from appimage.org for the final step.
48.
by samus 13d ago
Java has many dynamic features where runtime optimization is required to remove the overhead. Virtual method calls are opt-out instead of opt-in, and there is an open world assumption. The possibility of doing stack allocation of objects de
49.
by samus 13d ago
Accessibility apps naturally require privileged access to other applications. Using the clipboard for accessibility is a hack though, as its intended purpose is occasional generalized data transfer. Also, Zoom isn't an accessibility
50.
by samus 13d ago
Unix systems were initially designed to be multi-user systems (as in multiple meatbags accessing a mainframe across terminals), in an era before it was common to indiscriminately download and run applications from the internet. Files requir
51.
by samus 13d ago
That's very telling about the quality of the security audit.
52.
by samus 13d ago
It's not about Linux.
53.
by samus 13d ago
Unfortunately making software easy to install also makes it easier for Malware to be installed. It's a classic dilemma that is only fixable by making the user think twice about running stuff from the internet: Unix requires making the
54.
by samus 13d ago
> I thought Apple's tool was ridiculous though. It's like "oh, some trash blew into our yards from the neighbor's trashcan" so Apple replies "oh, don't worry, I destroyed it with my orbital ion cannon&q
55.
by samus 13d ago
Unless you have to run the meeting.
56.
by samus 13d ago
Quite hard because on Linux there is no concept of "apps". There is a (very flimsy) separation between processes, but the strongest actual security boundaries are between kernel and user space as well as between users. Namespaces
57.
by samus 14d ago
There is no install time in Java. If you want something to happen at install time you'd have to ship a shell script with the installer that does a brief training run when the application is first started.
58.
by samus 14d ago
Even if you can gather that PGO metadata a running application won't be able to adapt to changes in that data.
59.
by samus 14d ago
Jpackage or jlink should be extended to support creating AppImages.
60.
by samus 15d ago
How much of these 3s is javac? JEP 544 will only help reduce javac's overhead, not that of the compiled program.

More ›