_old_dude_

The support for M1 is backported at least by Azul, so you can get a Java 8 version which works on a M1

https://www.azul.com/downloads/?version=java-8-lts&os=macos&...

I'm using java almanac [1] for that.

[1] https://javaalmanac.io/jdk/

Here the list of all modules on Maven Central https://github.com/sormuras/modules/blob/main/com.github.sor...

> Everyone still downloads and runs an entire JVM

Nope, we (i know anecdote) use jlink in docker containers, mostly to avoid useless dependencies. The problem of GraalVM native image is that it comes with a subpar GC.

> which broke plenty of Java applications

yes, i agree, modules did not worth the trouble.

Modules fix two issues that plagues Java for a long time, classpath resolution and monkey patching using reflection.

For the former, the classpath is a colon separated list of jars (a zip containing the classes). At runtime the VM tries to find a class by scanning linearly all the jars, when needed or panic with a NoClassDefFoundError. The modulepath is a colon separated list of directories that contains some jars. At runtime, the VM revolves the dependencies (stored in the module descriptor of each jar) before starting the application.

For the later, when you define a module you have to explicitly export packages and open them to reflection

It's similar to the way V8 works.

This idea has a huge drawback. An instance, can have different shapes depending on the order you discover the fields, by example, if you have a point(x,y), the shape is different if you assign @x first or @y first.

So even if a code is not polymorphic for a human, it is polymorphic at runtime.

In practice, doing a static analysis of the code (maybe only the constructors of the hierarchy) is still needed to alleviate this issue.

What OOP is good at is maintenance over the time by making clear what is API and what is implementation.

My point is that when you develop an application, you only need strawman OOP i.e. calling methods.

You don't need class inheritance if you can pass functions as parameters, you don't need encapsulation given all your pieces co-evolve at the same time (if it's not split than part into a library).

It's not what i've said, OOP is great for creating APIs like WinUI, not great for writing applications

Am i the only one to think that the 'id' trick is a plain Chrome devtool bug ?

Either the ids should be queried without side effect or not queried at all without a user action.

The second idea, using 'toString()' is well know and also works in other OO languages, Java, C#, etc.

OOP is great when you write APIs/libraries (your examples), but is useless or even counter productive when writing applications, where encapsulation or inheritance just obfuscate everything.

My main grip with Java is that everything is by default a library.

But there is hope, recent changes in Java, records and pattern matching move away from that idea.

It's changing now https://wiki.openjdk.java.net/display/lilliput

For me, preemption by the Java scheduler is not currently supported but may be added in the future, after all the goroutine were not preempted at the beginning in Go.

The whole quote

> Second, Loom's virtual threads can also be forcibly preempted by the scheduler at any safepoint to implement time sharing. Currently, this capability isn't exposed because we're yet to find a use-case for it

I believe it's a reference to [1] but i may be wrong.

[1] https://download.java.net/java/early_access/loom/docs/api/ja...

By the OS, not by the scheduler see https://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part2....

Unlike go routine, Loom virtual threads are not preempted by the scheduler. I believe you may be able to explicitly preempt a virtual thread but the last time i checked it was not part of the public API

You can actually debug the code you write because you get a real stacktrace, not few frames that shows the underlying implementation.

Or use Spring Native (in beta)

https://docs.spring.io/spring-native/docs/current/reference/...

The two pain points of using a Jupyter Notebook are, cell dependencies, not being able to partially re-compute only what's needed when you change something like Excel does, and missing a concept of library/immutable codes.

JetBrain is specialized in listening devs, code mining and smooth integration. It seems like a good match, at least in my head :)

When you want to output values in the same order as the user give it to you e.g. when you read then write JSON or TOML files and those files can be written by a real human. Changing the order feel arbitrary.

When you have a language that support keyword arguments (kwargs) like Ruby or Python more recently.

It's like a fire drill. The government wants to desensitize people.

They want people be to used to the fact that cutting internet is something mundane so the next time they do it because of a protest, nobody will care.

I don't know LLVM well enough, but you can play with godbolt

By example, with https://godbolt.org/z/9Kv7oo9oK you can see that values goes into registers (and that thank to 'lea' there is not many registers used).

And if you remove the option -O2, values are spilled on stack.

In a compiled language, this is true for a local variable in general, it costs nothing because the compiler uses a register for it (or at worst spill it on stack but the stack frame size is reserved once for all stack allocated variables when the function is called).

The story is different, if the variable is captured by a closure/lambda, the current stack frame or part of it may be allocated on heap, leading to perf issues.

java -XX:+PrintCompilation prints all methods/loops generated to native code

The reflection API has two issues, a security check each time you call a method and the arguments being transformed to objects. The code is still generated to assembly code but the assembly code is slower because of that overhead.

Recent GC algorithms slow down the application, either by not scheduling coroutines that allocate too much memory or by forcing them to do the marking or the evacuation (helping the GC) when running (or both).

With that, STW pause time does not depend on the heap size or on the root set size (the stack size). In practice, it means pause < 1ms, at that point the OS becomes the bottleneck, not the GC.

So latency is good but throughput can be reduced by 30%.

The problem is that Java 7 is 10 years old, it means that you are missing 10 years of optimization. For GCs that's a lot.

GCs before ~2010 have been optimized for throughput more than for latency. Since then, you can choose.

Since 10 years, G1 let you set your maximum pause time and you get a huge warning if it miss that target, ZGC or Shenandoah are from the beginning latency first, throughput second.

The whole section on how GCs work is far from accurate. It only describes how one GC, CMS, works or worked because it had been removed. The permanent generation does not exist anymore since Java 8, etc

And i'm far from being an expert in GCs, but the basics are just wrong.

Tuning GCs like it was 2014 again.

It's a little bit sad that they did not hire an expert.

You still have PEBKAC but it's easy to find because a null can not cross the method boundary, so no snowball effect.

I never get why people have trouble with NPE.

If you stick to two rules, you're out of misery

  - never store null in a field, a collection, etc
  - checks all parameters that are not nullable (most of them) with Objects.requireNonNull
    (it's what Kotlin does automatically BTW)

It's easy to forget that programming is an art and being soul crushed by the business side of it.

Space bar is our chisel, to craft beautiful codes and reassure our mammal brain that being in the zone make us closest to god

Pattern matching does not work if you use an enum

  List<String> list = cons("a", nil());
  switch(list) {
    case Cons<String>(var car, var cdr) -> ...
    case Nil -> ...
  }

Nil is typed List<Void> which is not compatible with List<String>.

You may be able to use extractors as the inverse of the static methods cons() and nil() but that adds more boilerplate.

Disjunctive enums like in Rust or Scala 3 is a simpler way to define ADT.

Ok, it's perhaps a true Scotsman argument but saying that Java as a syntax for ADT is like saying JS (pre 2015) has classes because it can be simulated by function + prototype or that Java (pre 8) has lambdas because it can be simulated by anonymous classes.

Java misses the syntactic sugar to define ADT in one place like in Standard ML, OCaml or F#.

The closest you get is to declare records inside a sealed interface, but once you add generics in the mix, it starts to get messy.

I was not able to define a classical list with cons and nil in Java.

  sealed interface List<T> {
    record Cons<T>(T car, List<T> cdr) implements List<T> {}
    record Nil() implements List {} 
  }

The compiler give you warnings, Cons<T> or Nil are not a top level type and you can create several instances of Nil.