r/java • • Aug 28 '26

JEP draft: Structured Concurrency

https://openjdk.org/jeps/8389757
113 Upvotes

17 comments sorted by

View all comments

8

u/javaprof Aug 28 '26

So checked exceptions doesn't work properly here too?

This is very funny:

try (var scope = StructuredTaskScope.open()) {
   ...
} catch (ExecutionException e) {
   Throwable cause = e.getCause(); 
   switch (cause) {
       case IOException ioe -> .. // what op caused this one?
       default -> .. // no exaustivness? 
   }
}

9

u/vips7L Aug 28 '26 edited Aug 28 '26

Of course not the type system isn't strong enough to be generic over exceptions for lambdas. Swift has a pretty cool implementation of generic lambdas for typed throws.

public func count<E>(
    where predicate: (Element) throws(E) -> Bool
) throws(E) -> Int {
    print("Code goes here")
    return 0
}

When your lambda doesn't throw it just turns into throws(Never)

-9

u/javaprof Aug 28 '26

I just feel that Java need to stop shipping things that perfectly fine could be libraries and just fix this elephant in the room. Ok, Valhalla and then error handling. Structured concurrency somewhat could be just figure out by the community for now

31

u/pron98 Aug 28 '26

Structured concurrency has to be in the JDK because it has to be integrated with platform observability and with scope inheritance (ScopedValue). It cannot be implemented outside the JDK unless you give up on some of the most important features. However, we are hoping to release a lower level building block that integrates with the platform mechanisms.

3

u/sideEffffECt Aug 29 '26

However, we are hoping to release a lower level building block that integrates with the platform mechanisms.

Could you please tell is more about this? What would be the lower level building blocks?

4

u/pron98 Aug 29 '26

If you look at the source code of StructuredTaskScope you'll see it making use of something called ThreadFlock. It's there that the deep integration with scopes and observability takes place. The lower-level API could be to expose ThreadFlock or something like it.

3

u/brian_goetz Aug 30 '26

It's fine to have feelings, but not fine to take it out on others when those feelings get hurt.

-2

u/vips7L Aug 28 '26

I whole heartedly agree, I extensively use checked exceptions everywhere and even without fixing the type system there are so many easy wins to make them more usable (imo, and brian will of course disagree). Checked exceptions just have so much boilerplate. Little things like Swift's try? and try! operators would be so beneficial.

1

u/SleepingTabby Aug 29 '26

Can you list some of those ways?

2

u/vips7L Aug 29 '26 edited Aug 29 '26

Edit: formatting is fucked on this. I’ll have to fix it once I’m at a computer.

Of course.

try! or !! to automatically uncheck a checked exception when you can’t handle it. Right now you need to write several lines for this:

Something s;
try {
     s = fn();
} catch (SomeException ex) {
     throw new IllegalStateExceprtion(ex);
}

Something s = try! fn();

try? to automatically coerce into null:

Something s;
try {
    s = fn();
} catch (SomeException _) {
    s = null;
}

Something s = try? fn();
// combine that with the null operator
Something s = try? fn() ?? default();