I've been trying Java recently with IntelliJ and it's been funny watching Java's evolution from the IDE's suggestions.

In Java a lot of code looks like this

    void foo(Bar bar);

where Bar is an interface, and in many cases it only has one single method, so it looks like a callback that must be wrapped inside a class. Fortunately, Java lets you create anonymous classes to use these methods.

    void foo(new Bar { @override boolean baz(Fish fish) { return false; } });

I assume because this paradigm is so common somewhere along the way Java introduced "lambdas" that look like this (I learned this from an IDE hint)

    foo((Fish fish) -> false);

But what if you have a class that has Bar.baz method signature but it's called something else like fries()? Turns out you can do this (another IntelliJ hint):

    foo(this::fries);

This feels like a complicated way to declare a callback, but it means that if you do implement a method with the same name, you can just pass the instance, otherwise you can use the syntax sugar, e.g.

   saveMenuItem.registerMenuClickListener(myMenuClickHandler);
   saveButton.registerClickListener(myMenuClickHandler::onMenuClick);

There is a lot in Java that just feels weird, though. From the top of my head:

1. No unsigned integers. "byte" is -127 to 128. I believe this means it's not straightforward to make a 32-bit RGBA structure since you options are either using a signed "red" or using a 16-bit integer to store the 8-bit values. by the way I tried to benchmark how slow Java was compared to C in a simple test (I had arr1[] with indexes of arr2[] which contained values and I created arr3[] by resolving them) and it seems to be only half the speed of C which is probably fast enough for some basic low-level 2D graphics.

2. String.split takes a regex argument and there is no standard way to split without a regex. This was really confusing to me, but fortunately it's very easy to write your own .split, so it's not that much of a big deal.

3. You can call a different constructor with this(), but it has to be the first statement in the constructor. This one is pretty crazy! It would make sense if you couldn't access member fields before calling the constructor, but having to be first statement means if you want to calculate the argument for one constructor based on an argument passed to another constructor you need to do it inside the parentheses.

So far there is only 2 things I wish Java had. First the ability to implement methods in interfaces so you could use them if you have an interface instead of using a static method. Second I wish @NotNull was the default. This is a problem that Kotlin fixes so I think if you like Typescript for tis type-safety learning Kotlin would be a good idea.

▲ ludovicianul 2 days ago | parent | next [-]

Java is really fast: https://github.com/gunnarmorling/1brc

▲ mnembrini 3 days ago | parent | prev | next [-]

2 yes, although if you are splitting only one regular character the implementation doesn't use a Regen internally

3 is not an issue anymore since java 22 https://blog.jetbrains.com/idea/2024/02/constructor-makeover...

▲ thfuran 3 days ago | parent | prev | next [-]

Doesn't java now let you have both private methods in interfaces and default implementations of the interface methods?

▲ mdaniel 2 days ago | parent [-]

    $ cat Foo.java
    interface Foo {
        private String jimbo() {
            return "yup";
        }
    }

    $ javap -c -private Foo
    Compiled from "Foo.java"
    interface Foo {
      private java.lang.String jimbo();
        Code:
           0: ldc           #1                  // String yup
           2: areturn
    }

and

    interface Bar {
      default boolean isAwesome() {
        return true;
      }
    }

▲ ohdeargodno 2 days ago | parent | prev [-]

[dead]