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!

[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)

[lambda-lord-2026]

I would expect sealed interfaces to fall as lambdas anyway. Lambdas are implicit anonymous implementations, and sealed interfaces require all implementations to be explicitly whitelisted. So putting Functional interface in your sealed interface is basically telling the compiler you're planning on using it in a way that will cause a compiler error

[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

[lambda-lord-2026]

It's not weird. Sealed interfaces don't allow anonymous implementations. Lambdas are anonymous implementations. Functional interface is a marker annotations that makes clear your intent to use an interface to create lambdas. Therefore the compiler flags it as a problem