I can only think the reason why they did this was to compete with python, as our scripting languages that do not require a main/Main entry point.

Personally, it just feels wrong for compiled-based languages.

I think they could improve on C# with their namespace. Rather, for example, a typical C# file looking like:-

  using EFG;
  namespace ABC
  {
    public class XYZ
    {
     
    }
  }

  using EFG;
  using namespace ABC;
  public class XYZ
  {
    
  }

That's so 2010. I would avoid Scala like plague. It is a soup of all features imagined and some more. Java is difficult for novice. With Scala even experienced senior devs can look into a snippet and be befuddled. It is designed by academicians who thought clever looking choice is better.

  class MyClass {
    {
      System.out.println("Hello World!");
    }
  }

(It's also pretty poor style, but occasionally useful in a pinch, like when instantiating an anonymous inner class, which has no constructors that take arguments)

It’s okay if you’re only writing a single file, and it really seems intended for beginners or micro applications, but for those of us writing anything besides the most trivial, it’s merely “cute” and just adds inconsistency.

https://openjdk.org/jeps/8323335

1. https://github.com/manifold-systems/manifold

[0]: https://github.com/openjdk/jextract

[0] https://github.com/microsoft/win32metadata

1. Pointers to the same (and not just references to objects).

2. Unions (via explicit-layout structs)

3. Function pointers.

4. C-style varargs.

To be fair, not all of these have been exposed in C# historically even though CLR had them all along. Most notably, unmanaged function pointers took over 20 years. And since most people look at CLR through the prism of C#, they aren't necessarily aware of these features.

Still, one way or the other, we're at the point where pretty much any C program can be transpiled to C# in a one-to-one mapping of almost every construct (setjmp/longjmp has to be emulated with exceptions), and a very similar performance profile of the resulting code.

Java 8 is still under Extended Support until 2030 (and indefinite sustaining support). Java 11 left Premier Support September 2023.

"Java SE 8 has gone through the End of Public Updates process for legacy releases. Oracle will continue to provide free public updates and auto updates of Java SE 8 indefinitely for Personal, Development and other Users via java.com".

https://www.oracle.com/java/technologies/java-se-support-roa...

It wasn't ever part of the public API that's promised to never break, and JDK developers were annoyed that it being used meant Java got perceived as unstable, and it's gone in more recent versions.

As for the changes in 8->9, there was a stagnation period in the last year of Sun, and many people overfitted their libs to 8, by e.g. making use of internal APIs made accessible through reflection. This was never a good idea, and all that is happening now is that you have to explicitly state at invocation what kinds of non-future-proof modules you make use of, so that you are made aware of what could potentially change, plus it disincentivizes libraries from accessing these non-public APIs.

If by green threads you mean virtual threads in JDK 21 could you please elaborate why they are a mistake? I'm not a Java developer but from what I see new concurrency model allows to write much more efficient network software - OS threads are expensive (in terms of RAM/CPU) and to handle many thousands of network connections (C10k problem) you have to either throw a lot of hardware or use NIO (New/Non-blocking I/O) which is hard to code.

One of reasons why Go become popular - gorutines look like normal threads (relatively easy to code) but more efficient.

1. Applets ( Advertise the JVM capability "Applets".)

2.BundledApp ( Advertise the JVM capability "BundledApp". This is required by some java-based app bundles to recognize and use the JVM.)

3. JNI ( Advertise the JVM capability "JNI". This is required by some java-based app bundles to recognize and use the JVM.)

4. WebStart ( Advertise the JVM capability "WebStart".)

- what the heck? I think I am better off without Java. :)