Testing Java on BeagleBoards with ARM and RISC-V processors. @frankdelporte.be shows how these single-board computers handle Java applications.
foojay.io/today/first-...
#Java #ARM #RISCV #BeagleBoard
The people tackling "real unsolved problems" aren't accrediting AI/LLMs with any success they have. A fancy auto-complete isn't a detail worth discussing in such cases, because without it they'd still solve the problem, maybe just a bit slower.
I remember that thread on twitter ๐
I used to have a circular indicator when waiting on the decompiler to finish in Recaf but swapped it out for something else. Reintroduced the circle indicator in the project summary screen while it was generating content.
JavaFX is missing a native Switch control โ every major UI framework has one except JavaFX.
I've implemented a SwitchButton with full theme support. Hope to contribute to OpenJFX.
Thanks @dlemmermann.bsky.social for his help!
github.com/leewyatt/Swi...
#JavaFX
OpenJDK is faster than GraalVM*
It's around twice as fast in one particular area. Read more in my latest tiny blog post at mostlynerdless.de/blog/2026/01...
Looking at the skin impl for the control, it looks like intended usage of RotateTransition. So based on this and the GC root information, I'm inclined to say its a problem of the transition. This is on JavaFX 23.0.2 - Don't see any memory leak notes in 24/25 releases for this case.
So I debugged where that rotate transition was coming from that is caching the node... Its a neat little component I use from AtlantaFX, RingProgressIndicator with the value set to INDETERMINATE_PROGRESS. If I don't use it, or reset the progress value, then the leak goes away...
I *could* play wack-a-mole and null out references when the UI elements are removed, but it feels weird having to manually wire up logic to free this if the node is no longer part of the scene graph.
There's got to be a more efficient route, right?
Any #JavaFX people experience removed nodes being stuck around in memory after they've been removed from the scene graph?
If I have a node that has a ~500 MB byte array, and then I remove it, I should be able to expect that to be freeable right?
Heap dump GC root for reference
I reverse engineered DexProtector, the security solution protecting applications like Revolut and other banking apps.
From custom ELF loaders to vtable hooking, here is an insight into how these protections work and their limitations.
www.romainthomas.fr/post/26-01-d...
As an old and somewhat inactive Mockito maintainer I'd like to congratulate Tim for these past years keeping the light on the Mockito project. He his now stepping down.
Thank you Tim.
github.com/mockito/mock...
I spent about two days learning and implementing atmosphere rendering for planetary views from space. The tutorials and other sources I found on it were prettty lacking in implementation details but I got there in the end. Too late now, but does anyone have any recommends? Should I write an article?
Big box Tux Racer!!!! Wooooo!!!!
another excellent eBay acquisition
I interviewed @mattcoley.bsky.social about #Recaf and his #JavaFX libraries. But unexpectedly, I got a deep-dive course on #Java byte code, obfuscated code, and how JARs can be (ab)used to hide their real code...!
www.youtube.com/watch?v=6NIJ...
More info: webtechie.be/post/2025-10...
If you're using the JavaFX "Flowless" library for virtualized controls and are observing sluggish performance, do not add stylesheets to the Virtualized Node. Add them to the Scene. I observed an immediate 10x performance boost by doing this.
The good news is, they reverted that 404 -> 403 option, and *some* of our projects updated to use Artifactory first instead of last.
Artifactory: IT was instructed to prevent crawling, so one thing they did was change Artifactory replying 404 for missing artifacts to replying with 403 (like all other urls on other services they ran)
Result: 403 kills gradle builds, so nobody used artifactory and if they did, they put it last.
I love reading these articles and thinking "Yup, that's us on the job. We're part of the industrial inefficiency complex"
Artifactory set up but nobody uses it? ๐
CI jobs with zero caching? ๐
+ they can recursively spawn other jobs? ๐
+ they can trigger from simple "fix typo" commits? ๐
Now Recaf 4X can inline return values of simple static methods (like a xor string decryption call in this case)
Recaf's interactive deobfuscation window now lets you specify how many passes to run. For some obfuscation patterns that can't be one-shot in one linear pass (opaque control flow leading to more opaque control flow repeated N times) increasing the pass count to N+1 reduces it completely.
JavaFX now has a Headless platform.
bugs.openjdk.org/browse/JDK-8... is now Resolved!
Pfew, that took me 1 year, 5 months and 29 days. Goodnight!
#JavaFX #Java
Australia's decision to require age/identity verification, including facial scans, in order to do a Google search is dystopian.
We're watching the death of an open, anonymous internet, and the gradual takeover of information online by the state โ under the guise of protecting children.
And from my last ๐งต here's the sample that had attributes lying about their lengths being patched automatically (amongst many other tricks).
Updates to how some of the transformers work has cleaned up the output on most obfuscated samples I have. Here's a demo on a Minecraft server plugin getting optimized back to almost perfectly legible source.
The class file, being patched by CafeDude is not able to be loaded into Recaf
Anyways, Recaf will soon support loading these classes so you don't have to go through any of this pain like I did.
A screenshot of classfile/classFileParser.cpp - line 2394 This shows the parser ignoring discrepancies in a Code attribute's reported size when verification is disabled. Showing the git blame for this line shows that it belongs to the first commit in the project.
The exact line in the Hotspot class file parser responsible for supporting this can be found here: github.com/openjdk/jdk/...
The code is so old it predates OpenJDK's git history. No, not moving to GitHub. Git. This code has been around since before they migrated to using VCS/Git. At least 18 y/o.
The AttributeReader for a "Code" attribute shows its expected content length is 163 bytes
A hex view of the class. A red rectangle shows where the Code attribute begins. An orange rectangle shows where the Code attribute reports it will end at (but is wrong). A blue rectangle shows where the Code attribute actually ends (26 bytes after the reported end). This discrepancy is supported because Hotspot's JVM source 'classfile/classFileParser.cpp' ignores the reported length for methods when launching Java with -noverify or -Xverify:none.
Here's the reported length in the attribute vs a hex viewer annotated with the relevant locations showing the discrepancy.
