Hacker News new | past | comments | ask | show | jobs | submit login

I absolutely disagree. Lambdas has in many ways revolutionized Java and put it back on its feet. Java 8 has seen faster adoption than any other major Java version because of this. Compare it with Java 11 or indeed with absolute non-adoption of Java 14.

Streams are not very well designed IMHO. That's why their usage remains limited. Much more useful and robust libraries are possible on top of Java lambdas support.

Since everyone is now on Java 11 (and many on Java 8 still), we will only really see the records used widely in five years or so.

The modules stuff was a huge mistake in my opinion. Some people tend to like them in theory, but in practice they absolutely destroyed the adoption of newer Java versions and set Java 11 back by 10 years (literally).




Modules system was a necessary evil: it’s Hyrum’s law with the back then slowed down development of the JVM — every observable behavior of the system was hardcoded against, so the JVM devs had to build a wall against the changing internals to have any chance of continuing the evolution of the platform. Libraries that use never-agreed upon functionality are the ones in the bad here.


> the ones in the bad here

Never blame people who try to solve real problems with your stuff. Better get your ego out of their way.


My issue with lambdas in Java is the complexity of types in defining interfaces that receive generic Functions as an argument. Really seems like a better definition could be used there, new language syntax possibly.

On the topic of Streams, the big issue that always crops up is exceptions. Streams and Exceptions are nearly incompatible with tacked on constructs that are painful to use. Any IO oriented program will have to face the issue of what happens to the Stream if an Exception is thrown.


Agreed. If the type of the lambda can be inferred, then they are great to work with. But if you want to define one upfront and use it later, having to spell out the type of it is almost prohibitively annoying (what do I need in this situation, is it a Function or a Consumer or Supplier or Bifunction or BiConsumer or BinaryOperator or Predicate or BiPredicate or IntUnaryOperator or ObjDoubleConsumer or LongToDoubleFunction or .........). Most of the time I'll just avoid it if I can. I think I"m the only one on my team who would ever create a local function rather than a private method, for instance.

An other thing is java's lack of tuples. All the time I'm reaching for some kind of ad-hoc grouping/touple but have to resort to using something from Apache or Spring or (perhaps abusing) Map.Entry<K,V>


> An other thing is java's lack of tuples. All the time I'm reaching for some kind of ad-hoc grouping/touple but have to resort to using something from Apache or Spring or (perhaps abusing) Map.Entry<K,V>

Record types does make that a lot easier. They aren't quite as ad-hoc as in other languages, but this:

  record Foo(int a, String b) {}
is a lot less to type than

  static final class Foo {
    private final int a;
    private final String b;
    public final Foo(int a, String b) {
      this.a = a;
      this.b = b;
    }
    public int a() {
      return a;
    }
    public String b() {
      return b;
    }
    public int hashCode() {
      return Objects.hashCode(a, b);
    }
    public boolean equals(Object o) {
      if (o == null) return false;
      if (o == this) return true;
      if (o instanceof Foo f) {
        return a == f.a && Objects.equals(b, f.b);
      }
      return false;
    }
    public String toString() {
      return getClass().getSimpleName() + "[ a = " + a + ", " + "b = " + b + "]";
    }
  }


The modules system is not a blocker for migration at all. At this point, it is completely optional to enable it.

What indeed caused breakage was the encapsulation effort that blocks unrestricted access to JVM internals, and that one was not even fully and forcibly turned on until Java 17.


Well it requires users of your code to put a half dozen extra JVM args just to get your code (such as Java-based database like Apache Ignite) to run.

You can see how such features are not super popular to the extent of widespread non-adoption of Java 11 even 10 years after its release.


Oracle offers extended support for JDK 8 until the end 2030, which is more than four years longer than for JDK 11. I'd say this is the more likely reason that Java 11 is not adopted more. Spending a few hours to fire up an application to figure out the right --add-opens call really does not seem like such a big imposition to me.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: