Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
samus
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
20 ms
·
451.
▲
by
samus
2y ago
It is totally fine to use locking with virtual threads. Of course you don't need it if you don't have to restrict access to shared resources in the first place (for example a connection pool or a datastructure with internal inva
452.
▲
by
samus
2y ago
In the long term native calls will require a command line flag to be permitted. No matter whether they are done via FFI or JNA. By then, libraries better figure out a way to document them or to reduce using them as much as possible. A lot o
453.
▲
by
samus
2y ago
No, it's the only sane technique to do dependency injection. And it still doesn't force you to do autowiring; you can also write a @Bean factory method for all components in the application if you really want.
454.
▲
by
samus
2y ago
Classpath scanning is completely optional.
455.
▲
by
samus
2y ago
The name is quite tongue-in-cheek it seems. But when we reach it it will be glorious. Pieces of it are landing. Flexible constructor bodies will be finalized. Generics over primitive types might become part of Java 25. https://op
456.
▲
by
samus
2y ago
In a codebase heavily reliant on Optional it can be worthwhile to install NullAway just for the benefit of banishing that particular source of null. That doesn't help with dependencies of course (unless you are certain they also use a
457.
▲
by
samus
2y ago
Spring is perfectly usable without `@Autowired`, at least outside of test classes. SonarQube has a rule that helps avoiding it. Just use constructor injection instead.
458.
▲
by
samus
2y ago
Android Java is almost identical to mainline Java nowadays.
459.
▲
by
samus
2y ago
Switching `synchronized` for `ReentrantLock` is possible in principle, but it makes the code harder to read and opens the door to subtle concurrency bugs. Library authors really don't want this kind of code churn for an issue that is n
460.
▲
by
samus
2y ago
The Security Manager was dead as soon as applets ceased to be relevant (which happened a long time before WASM appeared btw.). Deploying the Security Manager requires designing the application up front for it as well as maintaining policy f
461.
▲
by
samus
2y ago
Indeed, the relief is great. However, there are relatively few users of virtual threads yet. Even fewer are keeping up with the releases. Those using it in production already managed to work around the issues or have given up on it. We will
462.
▲
by
samus
2y ago
It's just a coincidence. There are two releases per year. JDK 27 will be released in September 2026.
463.
▲
by
samus
2y ago
That was always possible and the whole point of virtual threads. This concerns reliability. So far there was this annoying papercut of virtual threads not freeing up their carrier thread when they were waiting to enter a `synchronized` lock
464.
▲
by
samus
2y ago
- If you're using virtual threads you must have been pining (pun intended) for freeing up the carrier thread when a virtual thread waits for a `synchronized` lock. - Stabilized FFI library - Unnamed variables and patterns - Always impr
465.
▲
by
samus
2y ago
Forgive me if I answer with a counter-question, but why would you use the Oracle distribution without paying for Oracle support too?
466.
▲
by
samus
2y ago
That's good news, I was highly impressed already by what that model could do, even under heavy quantization.
467.
▲
by
samus
2y ago
Most of these are header files. I suspect most of its contents are constants and blobs autogenerated with some tool by AMD.
468.
▲
by
samus
2y ago
Because they can and will be ignored on a large scale unless the false positive rate is pleasantly low. And more importantly there is a large amount of existing code that simply doesn't yet pass.
469.
▲
by
samus
2y ago
For many other use cases it is not. Imagine a smartphone randomly turning itself off. Nobody can possibly debug this.
470.
▲
by
samus
2y ago
Static analysis has the big disadvantage that it can and will be ignored .
471.
▲
by
samus
2y ago
Sometimes there were reasons, but they were not necessarily good ones. Like these: - time pressure, leading to just making it work and not caring about edge cases, which were bolted on later. Or maybe never at all. And naturally, there is n
472.
▲
by
samus
2y ago
In important regards, you sometimes become a different person :-)
473.
▲
by
samus
2y ago
That's like popping your tires to figure out that you need them for driving, and then discovering there is only one spare in the trunk.
474.
▲
by
samus
2y ago
It would still be easier to track the progress (or lack thereof) with a proper ticketing system.
475.
▲
by
samus
2y ago
They "just" need to settle on a platform. GitLab sounds good and is used by a lot of important Open Source projects.
476.
▲
by
samus
2y ago
Which sounds inefficient and exactly the sort of problem that doesn't happen with a Github issue/PR.
477.
▲
by
samus
2y ago
People just think "that's Linux, it's buggy and we have to live with it"
478.
▲
by
samus
2y ago
The provider of the index is usually not the same entity as the fund manager. Although the fund is actually quite free in the choice of securities that it can use to track the index. It depends on the fine print of the prospectus. It could
479.
▲
by
samus
2y ago
Shouldn't matter if you invest larger sums or with a savings plan.
480.
▲
by
samus
2y ago
Having voting rights kind of goes against the point of tracking an index though. Better invest in ESG funds or something like that. And for funds that use synthetic replication there is nothing to vote on in the first place.
More ›