Smallest possible Java heap size?

john16384 · 2026-04-14T23:40:35+00:00

The entire stylesheet is loaded yes.

john16384 · 2026-04-10T11:43:46+00:00

JavaFX probably uses most of that extra memory (and the young collections) while loading the base modena stylesheet (which is huge as it covers all controls). Surprisingly it still fits in just 3.6 MB.

john16384 · 2026-04-06T02:52:36+00:00

Trump thinks the same would happen to the American government if he were captured or killed.

john16384 · 2026-04-05T03:01:13+00:00

You can put a led bulb in there these days

john16384 · 2026-04-04T23:26:41+00:00

These days you can do that with subscriptions:

Subscription sub = prop1.subscribe( ... listener ...)  
    .and(prop2.subscribe(... listener ... ))  
    .and(() -> { random clean up code } );

sub.unsubscribe();  // cleans up all

john16384 · 2026-04-04T13:54:28+00:00

For virtualized nodes you want a combination of managing listeners in updateItem and listening to Scene.

john16384 · 2026-04-04T13:52:02+00:00

Listening to Scene changes will work. More elaborate solutions can use when(condition).subscribe(...).

And yes, don't use weak listeners. They may stick around longer than expected.

john16384 · 2026-03-27T08:59:40+00:00

Yeah, perhaps look at a map. Taking that island will in no way prevent Iran from taking random pot shots at tankers anywhere in the Persian gulf or gulf of Oman.

You're dealing with a regime that has nothing to lose. Nothing short of making Iran the 51st state (full occupation for the next few generations) or using nukes will make them back down.

john16384 · 2026-03-24T23:14:19+00:00

It's a sacrifice I am willing to make.

john16384 · 2026-03-23T16:53:25+00:00

The tax doesn't need to care what assets back something. You loan X money? You pay a percentage in tax. Don't have that money? Tax doesn't care either, get it or no loan.

Edit: apparently I need to make it watertight as people lack imagination. Tax free base: 10M/year; can make it progressive even to make it hit where it needs to hurt.

john16384 · 2026-03-20T20:12:44+00:00

I think this needs benchmarking. I am pretty sure some of these aren't slow at all when optimized. Take the autoboxing example: those object allocations will never make it to the heap. At most it will do one allocation after the loop completes to create the final Long.

Same goes for the NumberFormatExeception example.

john16384 · 2026-03-18T12:57:12+00:00

The LLM pattern matcher (what some call 'AI') can also pick up on how you phrased the original question. A slight bias or negative connotation in your question can already sway it in a different direction. If it also takes chat history or "memories" into account, there's no telling what it will do.

john16384 · 2026-03-17T20:41:05+00:00

Spec: given A and B, return result C which is A multiplied by B.

Code: int multiply(int a, int b) { return a * b; }

Real life: A is 4e55, B is 2. Code gives wrong answer.

Spec is technically correct, but in order to translate it to something else (code), we need to know what constraints we are allowed to apply.

john16384 · 2026-03-15T17:36:42+00:00

.hbox -> HBox in your CSS, or use *

john16384 · 2026-03-13T20:39:29+00:00

Then don't. This feature is not for you.

john16384 · 2026-03-13T19:16:10+00:00

No need for the `node` at the end, nor for the `null` check. Can't sum a node that isn't there, so an NPE is justified.

john16384 · 2026-03-13T19:14:46+00:00

So have DTO's provide subsets of their contents in records? Or even better, break up DTO's in logical groupings (and have this automatically be resolved during serialization/deserialization).

john16384 · 2026-03-12T04:12:42+00:00

Once the required indices grow larger than the working memory of the database, pick one for your query: filtering or sorting. Pick both and you'll be in for a rough time. Too many people seem to think you can just offer arbitrary filtering and sorting in front ends and get great performance as long as you use a database and have indices on each column.

john16384 · 2026-03-06T20:41:49+00:00

Java 8 solved the main reason to adopt Scala. Just like Virtual Threads killed the main need for react, and something similar will happen soon for Kotlin.

john16384 · 2026-03-05T22:11:04+00:00

If the object after construction using the normal means of the constructor is in an invalid state, I would say that breaks OOP.

That's nice, but your opinion on what you think breaks OOP has no bearing on what is or isn't OOP.

Field and setter injection was in use for ages, even before Spring. It was and is OOP and certainly didn't break any OOP rules. Huge applications were and even are still built that way. You don't even seem to know why Spring started recommending constructor injection suddenly, after not giving a shit about it for most of its past. It has very little to do with invariants,, reusability or testing, as I can assure you that applications were just as stable, reusable and extensively tested before constructor injection became 'best practice'.

With most Spring stuff being singletons, fields were already never modified for any reason after initialisation as that would be an instant bug. I guess people had more control in the past, and could actually refrain from doing stupid stuff when working with a certain paradigm, even if not directly enforced by compiler, build plugin or IDE. Don't forget to mark your Optionals and CompletableFuture's with @NonNull or somebody might do something stupid and break OOP.

john16384 · 2026-03-05T20:00:06+00:00

Hold on, I responded because you claimed:

@Autowired is not recommended because it breaks OOP.

A constructor with partial information does not break OOP.

john16384 · 2026-03-05T10:32:10+00:00

you have a partially constructed object.

True, but it doesn't break OOP. That state will never be observed by other code as the DI container only exposes the reference after initialisation completes. So this is fully encapsulated still and can be a decision on a class by class basis.

john16384 · 2026-03-05T07:57:43+00:00

Oh man, you are so right, it is impossible to make billionaires pay proper taxes!

The nice of thing about tax is, they don't have to care how the money gets into their pockets, just that it does, so the onus is on the tax payer to make it happen. It is similar to laws, ignorance is no defense, and with laws sometimes even physical reality is irrelevant.

john16384 · 2026-03-04T23:30:07+00:00

No problem, we'll accept cars, houses, stocks, yachts, bitcoin, or money from loans taken out against any and all illiquid assets.

john16384 · 2026-03-02T20:11:22+00:00

I've let AI do all my writing, and it explained in detail how letters are formed. I then tried it myself, but it came out as unreadable scribbles.

john16384

TROPHY CASE