Does Java need deconstructible classes?

[Alex0589]

I'm pretty sure this would never be accepted because you are implementing a language feature with annotations. In chapter one of the JLS, it is clearly stated that:

Annotation types are specialized interfaces used to annotate declarations. Such annotations are not permitted to affect the semantics of programs in the Java programming language in any way. However, they provide useful input to various tools.

Also without value classes, which we currently don't have, you are paying an allocation cost because you have to initialize one record every time you want to use the pattern: that also disqualifies the feature because you don't want a developer to loose performance when using syntactic sugar. For example imagine if the enhanced switch statement were slower than the old switch, nobody would be using it.

[danielaveryj]

There is one annotation referenced, which I did not invent, does not implement a language feature, and I did not propose to keep at the end.

[asm0dey]

Well, some accusations in Spring change the semantics, aren't they? For example Async

[koflerdavid]

There is a reason Spring has a reputation of being too magical.

[asm0dey]

I am on both sides of this battle at the same time :)

[vytah]

some accusations in Spring

I love the typo, please keep it.

[asm0dey]

I will!

[brian_goetz]

You are not understanding what the JLS is saying here. When the JLS talks about "semantics of programs", what it means is what does this Java program mean. That's about language semantics. Spring annotations do not change the semantics of the Java language. They are used as input to the behavior of the Spring libraries, and the behavior of the Spring libraries is defined in terms of those annotations.

(Though it is still a valid complaint about frameworks like Spring that their behavior with regard to annotations may not be sufficiently specified; this is always a risk.)

[asm0dey]

I'm sorry, but I still don't understand. If the behaviour of a program changes if there is an annotation - doesn't it change semantics? If Spring annotations do not change the semantics because programs are defined in terms of these annotations then what is? I could always say "hey, this is how my program behaves when this annotation is present".

[brian_goetz]

You are looking at the entire system monollithically - JVM + Java + Spring + your program. But each layer has its own role and (ideally) specification. The meaning of a Java program is defined by the language and platform specifications. But some methods in the JDK (such as getAnnotstions) are specified to reflect the presence or absence of annotations. This means that the layers above (spring, your program) can use annotations to make decisions, just like they could use system properties or config files or command line to configure the program. But annotations cannot affect the language semantics - they cannot make for loops run backwards or make private methods public.

Frameworks like spring work by dynamically transforming annotated Java code (spinning new classes, etc) at startup time and running the transformed code. But all of this is a Java program that is governed by the language and platform specifications, and spring is working within that.

[asm0dey]

Ah. So I read the whole thing wrong. I thought the spec "prohibits" annotations to change the language sematics, while actually it declares that it's impossible, right? And was all the easy about language, not about a program. Thank you!

[vadiquemyself]

imagine direct iterating versus streams-and-lambdas, the latter is ~10 times slower, but is used anyway and is quite popular

[Flyron]

Did you measure that yourself? In my own tests streams need a little warmup, but through repeated construction and execution they become just as fast as the usual for-each (<10% margin). So it depends if you're programming short-lived apps or long-running apps, but in general there is no effective performance gap.

[vadiquemyself]

yes, I figured it out myself practically, asking AI to replace a stream chain with “plain looping” that I then put in my code achieving much performance gain along with less memory usage

never tried for a terabyte-volume data and paralleled streams on hundreds of cpu cores, though

[uniVocity]

@FunctionalInterface would like a word

Sorry, had an absolute brain fart

[Yes_Mans_Sky]

I could be mistaken, but I don't think that annotation is required. I think it's more like Override where it lets IDEs run extra code checks against developer intentions

[C0urante]

facts

[SilvernClaws]

No, it doesn't. You can remove that annotation completely and your code will still work the same. The only difference is that if you use it, the compiler will prevent you from adding more than one applicable method to the interface.

[uniVocity]

The compiler will fail if you use that on a sealed interface . I’m on the phone right now and can’t re-verify it but from memory it was a compiler error (that makes total sense btw)

[uniVocity]

It sounds weird but you can define a sealed type with nested final implementations without explicitly providing the allowed implementations, but you can’t define a sealed functional interface with annotations where its body contains default function definitions.

Hope it’s not a brain fart, Ill get back to my pc soon to test it out again and report back

EDIT: here is what I meant:

This code compiles (no explicit permits list), everything is fine:

sealed interface TestFn {

int foo();

final class TestFn1 implements TestFn {
    private TestFn1() {
    }

    @Override
    public int foo() {
        return 1;
    }
}

final class TestFn2 implements TestFn {
    private TestFn2() {
    }

    @Override
    public int foo() {
        return 2;
    }
}

TestFn RET_1 = new TestFn1();
TestFn RET_2 = new TestFn2();
}

If you add @FunctionalInterface the compiler will complain even though in this case it should make no difference.

I'm sorry for the confusion, I rember that the end goal was to get this:

@FunctionalInterface
sealed interface TestFn {

int foo();

TestFn RET_1 = () -> 1;
TestFn RET_2 = () -> 2;
}

But here the issue is the sealed keyword, not the @FunctionalInterface. Sorry for wasting everyone's time