Chances are you forgot to kick it.

The linked article is written by me. It explains how Java streams need a terminating operation in order to start any actions. For more explanations and code examples, do follow the link and read the article. It's free.

Hi everyone,

I'm trying to find out how much people use the "new" features available in java. I would be very thankful, if anyone could participate. (less than one minute required)

In my former projects we neither had the latest java version, nor did we use all the features available. Sometimes i had the feeling, that some of my collegues didn't even know that these features exist. How's your experience?

https://forms.office.com/r/udsj1aUawV

Hi everyone,

I'm trying to find out how much people use the "new" features available in java. I would be very thankful, if anyone could participate. (less than one minute required)

https://forms.office.com/r/udsj1aUawV

Everyone is posting about beans!

Which do you prefer of these two? The goal is the same. If bar is null then make foo null and avoid the exception. In other languages there is the ?. operator to help with this.

foo = bar == null ? null : bar.baz();
foo = bar != null ? bar.baz() : null;

I ask because I feel like the "English" of the first example is easier to read and has less negations so it is more straightforward, but the second one has the meat of the expression (bar.baz()) more prominently.

I've been paying attention to the JEPs, but this includes the general API changes that there aren't jeps for.

virtual threads, sequenced collections, generational ZGC, pattern matching, structured concurrency preview , vector preview, string templates preview

Archived link

Interested in what folks use. I stick to temurin unless guaranteed to deploy in AWS then I use corretto.

I'm curious if there are things in the standard class library that you find useful but not widely used.

Though it is not possible in Java, the JVM can have multiple methods with the same name and parameter types so long as they have different return types. The JVM spec seems to call it "method descriptor" but I called it signature as I think that's more attention grabbing (and I'm showing how the JVM spec and Java spec differ).

No two methods in one class file may have the same name and descriptor

You can experimentally test this yourself with the Jasmin project. Jasmin is a tool that lets you write assembly code to assemble to JVM byte code. I also used this classfileanalyzer project to get some base Jasmin assembly.

For the lazy, here is the Java code I started with,

public class Example {
  public static void main(String[] args) {
    System.out.println(foo());
    System.out.println(fooInt());
  }
  static String foo() {
    return "1";
  }
  static int fooInt() {
    return 1;
  }
}

Then I got this Jasmin code and replaced each fooInt with foo

; Example.j

; Generated by ClassFileAnalyzer (Can)
; Analyzer and Disassembler for Java class files
; (Jasmin syntax 2, http://jasmin.sourceforge.net)
;
; ClassFileAnalyzer, version 0.7.0


.bytecode 63.0
.source Example.java
.class public Example
.super java/lang/Object

.method public <init>()V
  .limit stack 1
  .limit locals 1
  .line 1
  0: aload_0
  1: invokespecial java/lang/Object/<init>()V
  4: return
.end method

.method public static main([Ljava/lang/String;)V
  .limit stack 2
  .limit locals 1
  .line 3
  0: getstatic java/lang/System/out Ljava/io/PrintStream;
  3: invokestatic Example/foo()Ljava/lang/String;
  6: invokevirtual java/io/PrintStream/println(Ljava/lang/String;)V
  .line 4
  9: getstatic java/lang/System/out Ljava/io/PrintStream;
  12: invokestatic Example/foo()I
  15: invokevirtual java/io/PrintStream/println(I)V
  .line 5
  18: return
.end method

.method static foo()Ljava/lang/String;
  .limit stack 1
  .limit locals 0
  .line 7
  0: ldc "1"
  2: areturn
.end method

.method static foo()I
  .limit stack 1
  .limit locals 0
  .line 10
  0: iconst_1
  1: ireturn
.end method

After assembling Example.class with Jasmin and running javap -c Example I get this output,

Compiled from "Example.java"
public class Example {
  public Example();
    Code:
       0: aload_0
       1: invokespecial #28                 // Method java/lang/Object."<init>":()V
       4: return

  public static void main(java.lang.String[]);
    Code:
       0: getstatic     #33                 // Field java/lang/System.out:Ljava/io/PrintStream;
       3: invokestatic  #32                 // Method foo:()Ljava/lang/String;
       6: invokevirtual #10                 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
       9: getstatic     #33                 // Field java/lang/System.out:Ljava/io/PrintStream;
      12: invokestatic  #11                 // Method foo:()I
      15: invokevirtual #24                 // Method java/io/PrintStream.println:(I)V
      18: return

  static java.lang.String foo();
    Code:
       0: ldc           #27                 // String 1
       2: areturn

  static int foo();
    Code:
       0: iconst_1
       1: ireturn
}

And of course, running Example.class outputs

1
1

I hope you've enjoyed this interesting quirk of the JVM. It is a good reminder that while the JVM is primarily for Java, there are other languages that use it and some might even use this in a meaningful way somehow.

A great read for folks wondering why Java uses type erasure instead of "reified" generics. For the unaware, that means that a List<Integer> is a List<Object> at runtime. I had always wondered about it and why they didn't take the alternative route. For context, C# does have reified types so the actual type parameter is available at runtime.

I personally love reading in depth discussions about counter intuitive engineering decisions like this.

Assertions being built into Java is nice and they've been around since version 1.4. They predate type parameters! I have never seen them being used and the reason always seems to be that because you can't count on them being turned on because they're off by default.

The only theoretical use I can think of it for "executable comments", as in something like the example below, but they're annoying as the IDE will usually complain that it is always true (with no way to specifically disable warning for always true assertions, only always true conditions in general).

if (condition) {
  // Very long block of code
} else {
  assert !condition; // Primarily a reminder for when the if condition is not easily seen
}

Here it doesn't matter if the assertion is executed or not because it is just a reminder. The idea being that code sticks out more than a comment.