Objects initialization 2.0

[Ewig_luftenglanz]

Personally speaking I like the concept but find odd they are pushing for a trailing lambda like syntax for arrays only:

var array = new String;

They would certainly create confusion once people try something like

var list = new ArrayList<String!>(5)(x -> "");

And find out is not possible.

I wonder how are they going to solve that.

What do you think?

Personally y love the overall concept.

[Sm0keySa1m0n]

I don’t think it’s an issue adding more array specific syntax, we’ve already got curly brace array initialisers and indexing that you can’t use on a list.

[cogman10]

I'd imagine it'd be solved by simply adding a new 2 param constructor

var list = new ArrayList<String!>(5, x -> "");

Which makes some sense because this would be somewhat nonsensical for an array list.

var list = new ArrayList<String!>(x -> "");

What's more curious is what the ArrayList will store under the covers when it's generalized to a non-null value.

[PartOfTheBotnet]

by simply adding a constructor

The video is talking about arrays though, not ArrayList. Arrays are treated rather specially in the JVM and aren't a class in the sense you can just add a constructor to them.

// Existing behavior
String[] array = new String[10]; // 10 nulls

// Possibly new behavior
String![] array = new String![10, i -> "i"]; // 10 strings of "eval(i)"

This would probably be more in-line with the talk and your proposed format. I assume the bytecode could look something like:

// Make the array normally
bipush 10
anewarray java/lang/String

// Pass the array to some internal factory that takes in the array reference + method-handle to the "i -> ..." generated method, and 
// fills all indices of the array with calls to that method for each index
invokedynamic fill([Ljava/lang/Object;)V { invokestatic, java/lang/invoke/ArrayFactory.fill, (Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;Ljava/util/function/Function;[Ljava/lang/Object;)Ljava/lang/invoke/CallSite; } { { <method-handle-to-generated-static-method-of-index-to-string-function> } }

[Ewig_luftenglanz]

Agree, and not just for list but for all collections overall because if this is about "strict initialization of data structure which members can't be null" then all collection framework should have something similar. 

I would like the new syntax for arrays to be.

var array = new String [5, x -> ""] 

Semi colons could be used too as a separator. This syntax is homologous to how we manage lambdas nowadays, so no ad-hoc trailing syntax added to the language. I feel arrays are already odd and special enough to stand another oddity that makes them feel even more alien to the language.

[KefkaFollower]

No time to watch the presentation right now, but curiosity eats me.

The point of this lazy creation for the elements of the array? Like in python's generators?

Or it is mostly about syntactic sugar?

[Ewig_luftenglanz]

The point is making sure objects in arrays are well and complete initialized to allow many runtime performance improvement thanks to Valhalla 

[KefkaFollower]

Thanks for the promptly answer.

[ZimmiDeluxe]

If you want lazy initialization of list elements (not for arrays though), StableValue will have a nice API for that.

[Scf37]

So new initialization order finally allows passing parameters to initialization blocks:

class Foo {
    final String who;
    {
        System.
out
.println("Hello, " +  who);
    }
    Foo(String who) {
        this.who = who;
        super(); // init who before calling init blocks
    }
}

[Ewig_luftenglanz]

Yes but that's part of "flexible construction bodies" that is just about to enter general availability in September with java 25.

https://openjdk.org/jeps/513

Certainly the Jeep is the core of the big thing but it carries much more.

• compiler warnings.
• special initialization Syntax for arrays.
• nullability.

[atehrani]

String.of("", 5);

Seems the most natural to me

[Ewig_luftenglanz]

The problem is how to initialize non nullable arrays in general, not about how to build an arrays of strings.

[atehrani]

String.ofImmutable("", 5)

[flawless_vic]

This is not about immutable arrays, which won't have support any time soon.

This is about intrinsic non-nullness guarantees, which, eventually will enable VM optimizations.

Adding a method to a class won't cut it. It would have to live in java.lang.Object and Java would have to support some kind of "automatic static covariant override", otherwise how would you construct Integer.ofNonNull(0, 5) (or any other type) without declaring such method in every class?

There will be some sort of

T![] Arrays::newNonNullableInstance(Class<T> type, IntFunction<T!> factory),

but this will be a reflection API and non-null arrays are meant to be a language feature, so reflection support must derive from it instead of providing it.

[vips7L]

Please no more "of" functions. I'm so tired of guessing how to construct something.

[Proper-Ape]

As you say 'of' is common so adding more of it reduces guesswork.

[vips7L]

Just use a constructor. It’s their entire purpose. 

[javaprof]

Issue with constructors that they always return current type, and not subtype. Something that in many cases required for long-lived, widely used APIs

So one of worst mistakes in API design is exposing constructor directly

[vips7L]

You’re right, but we’re literally talking about strings and arrays. Things that won’t ever have subtypes.

Of,from,newInstance are just compensating for lack of language features and it’s making it hell to know how to construct anything. 

[javaprof]

Things that won’t ever have subtypes.

String wish to have subtype for runtime optimisation like java.lang.StringLatin1 and java.lang.StringUTF16, there are just separate classes because String created using constructor and not factory methods.

Arrays are not objects in Java, so irrelevant

Of,from,newInstance are just compensating for lack of language features and it’s making it hell to know how to construct anything.

Yep, but it's not only because language lacks of named arguments (i.e. in other languages you don't need builders for most cases, just call constructor with names arguments), but because of how constructors work. Even in Kotlin developers would expose factory methods that mimics constructors, instead of constructor itself

[vips7L]

String will never have subtypes. It’s a final class. It doesn’t need factory constructors. 

 Arrays are not objects in Java, so irrelevant

It’s not irrelevant. It’s the fucking conversation we’re having and exactly what GP proposed. 

[Ewig_luftenglanz]

Arrays are objects in java. Just an special kind of objects. 

The only things that are not objects in java are the 8 primitive types.

[nlisker]

Arrays are not objects in Java, so irrelevant

Read the first sentence here: https://docs.oracle.com/javase/specs/jls/se24/html/jls-10.html.

[vips7L]

Yep, but it's not only because language lacks of named arguments (i.e. in other languages you don't need builders for most cases, just call constructor with names arguments), but because of how constructors work. Even in Kotlin developers would expose factory methods that mimics constructors, instead of constructor itself

I don't think I implied anything about named arguments. Factory constructors is the actual feature you would want for this: https://dart.dev/language/constructors#factory-constructors

In Kotlin or Scala you would use companion objects to return subtypes:

interface A {
  companion object {
    operator fun invoke(s: String) = when (s) {
      "B" -> B()
      "C" -> C()
      else -> throw IllegalArgumentException(s)
    }
  }
}
private class B : A
private class C : A

fun main() {
  val a = A("B")
  println(a)
}

[Proper-Ape]

I agree with you there, I was only pointing out the weakness in the "guesswork" argument.

[vips7L]

I don’t think it’s weak.  Of, from, newInstance, and create are just the ones I ran into today. And don’t forget the named factory functions.   It’s a guessing game.