_old_dude_

If you can, you can give a try to Quarkus, while the doc is not up to the level of Spring, in term of ergonomics, configuration, hot reload, test containers, this is closer to what .NET does, by example annotations are optional and are resolved at compilation not at the execution.

I've recently used rewrite that comes with YAML recipes [1] for the common refactoring

[1] https://docs.openrewrite.org/reference/yaml-format-reference

prettier [1] and google-java-format [2]

[1] https://prettier.io/ [2] https://github.com/google/google-java-format

The two main advantages of using classes are:

a class is also a type (if you have a typed language),

a class is also a module, you group together values that makes sense together (the x and the y of a point) with the functions (methods) that interact with it.

When you have a lot of codes flying around, you can add encapsulation (private/public thingy) so the user of a code does not see the implementation which helps to create libraries that can evolve independently from the applications using them.

Also compared to an associative array, a class is more compact in memory (granted JavaScript runtimes see dictionaries as hidden classes).

The problem with the add types later approach is that in the end you have half baked .ts files left and right. And it becomes increasingly difficult to know when something compiles if it's because it's correct or because there is an any somewhere.

Oracle did not open sourced Java, Sun did before dying.

But you are right that Oracle unified all paid/free versions of Java under the OpenJDK banner, even Android is using the OpenJDK now.

The "dynamic" keyword [1] is my favorite blunder in C#. It's great if you are use it for COM interropt but it's awful otherwise.

The code compiles but from time to time it fails at runtime and performance are sometimes Ok, sometimes not depending on the call stack.

[1] https://docs.microsoft.com/en-us/dotnet/csharp/programming-g...

That why the next step is to introduce move-only types to have the same defaults as Rust.

I believe JEP 401 has not yet been updated to the new model, there is no .val anymore, instead there are nullable value types and non nullable primitive types, only the latter has a .ref box because the former is a reference.

Optional will be retrofitted to a value class not a primitive class, you get flattening but only on stack (parameter type or return type) not on heap (field).

I don't really understand the end of the part3 (the VM model), so i may be wrong.

> it means that the entire compile time set of problems is also lifted into runtime

It's what Swift does if inlining is defeated, the type arguments are passed at runtime as a classical argument on stack.

You don't need full reflection as you suggest, only to be able to materialize the types as structs + an interface at runtime. Yes, it's a little slower but most of the overhead comes from the function not be inlined.

You can try reason first, it's a frontend for OCaml with a C-like syntax

https://medium.com/@asankhaya/reason-with-ocaml-b75697a6c00b

More realistically, this code is 20 years old, several generations of maintainers worked on it, accumulating patches over patches over patches and nobody wanted to be the guy that say No / we should remove that feature.

You can see the discussions on HN about Gnome removing features as a good example about how hard it is.

The idea of having different declarative security realms is fine but it's not what the Java Security Manager is.

The Java Security Manager is an API that allows to intercept and run codes, so devs use it as a Trojan Horse to patch code instead of fixing the root of the issue.

The Java Security Manager should die.

10 years ago, with DDOS attacks using hash table collision [1]. It was a sad Christmas, lot of RoR servers to patch.

[1] https://www.securityweek.com/hash-table-collision-attacks-co...

Every time i see her, i see Anya Taylor-Joy in the Queen Gambit ...

Very true, Java was late in the game in term of SIMD loop optimizations compared to C#.

Oracle engineers did the first implementation for Java 7, more recently it's mostly contributions from Intel, AMD and ARM [1].

[1] https://cr.openjdk.java.net/~vlivanov/talks/2019_CodeOne_MTE...

It has nothing to do with the language but with the API / VM capabilities.

Both those restrictions are fixed, granted that this is not yet in the offical API, it's an incubation module (the equivalent of from __future__ of Python).

https://docs.oracle.com/en/java/javase/17/docs/api/jdk.incub...

This trick does not work with Java 11+, you can not peek and poke the JDK internals anymore.

It's the reason why the transition from Java 8 to 11 has been painful.

One of the issue with structural types is compiler error messages. By example, C++ templates are structural types and error messages are really hard to decipher.

Recent versions of Java (Java 8+) avoid structural types but provide structural conversions + inference.

We will see with the recent introduction of named records/tuples goes in the same direction or not.

There are interoperable since Java 8, using the operator ::

  com.google.common.base.Predicate<String> guavaPredicate = ...
  java.util.function.Predicate<String> predicate = guavaPredicate::apply;

1. imitate to understand the rules

2. create following the rules

3. break the rules

The idea is to let users of a language, here CLOS, to be able to intercept meta-messages like instance creation, method call, property access, etc to provide their own implementations.

It's like the doesNotUnderstand in SmallTalk, method_missing in Ruby or more recently .Net Dynamic Language Runtime or invokedynamic in Java.

I will show my age, but is there a turbo button [1] ?

[1] https://en.wikipedia.org/wiki/Turbo_button

I expect Java to be slower, Optional was introduced as an afterthought not as a native construct like in Rust.

Sadly, the two benchmarks are not equivalent, the Rust version loop over ints, the Java version loop over longs.

Looping over longs is notoriously slow in Java, because there is no vectorisation and the JIT insert insert a GC checks because looping over longs may take a long of time.

Also one of the codes uses Optional<Long> instead of OptionalLong, so the code does a double boxing long -> Long -> OptionalLong.

Browsers are good at caching JavaScript files, so it depends if the scripts are already cached or not.

Here is the related research paper https://duckduckgo.com/?q=Cross-Component+Garbage+Collection

Implementing coroutine requires to change to the code generator, the runtime and the garbage collectors and there is no general consensus on the way to implement them efficiently => this requires a huge investment in engineering.

For Rust, one of the feature of Rust is to have a minimal runtime, so using a compiler transformation seems a good fit.

For C#, Microsoft has a limited number of people working on the runtime of DotNet. Async/await was developed at the same time DotNet was transitioning to DotNet Core which also requires massive engineering, so it was about priority. The future will tell if at some point coroutine will be added to DotNet.

This FAQ is about Java SE builds, not the OpenJDK builds.

Java is Still Free (2019) https://medium.com/@javachampions/java-is-still-free-2-0-0-6...

I don't know if there is a more recent version

You can use the Spring AOT plugin [1] without enabling the support of GraalVM native image

[1] https://docs.spring.io/spring-native/docs/current/reference/...

You mean Spring native [1], i think it's not ready yet.

[1] https://docs.spring.io/spring-native/docs/current/reference/...