Changes to JEP 453

[Attila Kelemen]

>
> So, what does "Subtask" mean when there is no "Task"?
>
>
> Personally, I would go with either just "Task" or "StructuredScopeTask" as "Subtask" is sort of inventing new terminology.
>
> If you renamed "StructuredTaskScope" to just "Task" then "Subtask" would make more sense as it is something spawned from a Task. This would be my preferred choice. Shorter names for common things... in particular things that should become common.
>
> However, what is the relationship to "Task" with all those other things called "...Task..." Maybe just "ConcurrentTask" and "ConcurrentSubtask" are more meaningful, but "java.util.concurrent.Task" and "java.util.concurrent.Subtask" are probably clear enough.
>
> In a sense, we would be saying that all Concurrent Tasks should be Structured.

`StructuredTaskScope` is not a task though, but it is really a scope
(besides, a simple name like `Task` would conflict with a lot of
existing things, which would be horrible, even if others shouldn't
have given such a simple name as well).

The way I imagine it is that the "task" you are looking for is the
block between the creation and closing of `StructuredTaskScope`.
Still, obviously naming this is difficult, because it is also not
exactly a task (I mean it has a task() method for confusion, and that
is not the parent, but actually the action of the `Subtask`, but I
believe the `task()` method should be removed, as it is harmful). As
far as usage goes, this wants to be a reference to the result of the
task, but the existence of `state()` would make it awkward to call it
some kind of result (also then `get` would return the result of a
result, which is also awkward). So yeah, it should be
`ResultReferenceWithStateOfComputation` :). Though, on a second note,
it could be called result, and you could think of state as the state
the result is in (since you are not really expected to rely on this
changing, and should not use it before `join`).