TrapezoidProfile methods (somewhat) incompatible with new API

[chauser]

Describe the bug
Several of the methods in TrapezoidProfile have surprising behavior in some cases when used with the new (non-deprecated, single-argument) constructor because member variables they depend on are not initialized by the new constructor.

Java:
timeLeftUntil uses m_current -- it will get a null pointer exception if called before calculate is called.
totalTime uses m_endDeccel -- it will return zero if called before calculate is called.
isFinished uses totalTime() -- it will return true if called before calculate is called.
If calculate has been called, totalTime and timeLeftUntil return (I think) the times for a profile starting at the current state of the last call to calculate and ending at its goal state.

C++:
Essentially the same issues when any of these methods is called before calculate.
Since m_current isn't a reference it probably won't segfault, but m_current and m_endDeccel are uninitialized in the same cases and the actual behavior may be less predictable than for Java.

It is not clear to me how useful any of these stateful methods are when using the new API. Should they be deprecated as well? And if that were done, couldn't the whole API be boiled down to a single stateless method
calculate(Constraints constraints, double t, State current, State goal)?

[calcmogul]

Java should be initializing the member variables to default objects. C++ already does the correct thing because the default constructor is implicitly called.

The new TrapezoidProfile API is intended to be like a stateful filter. There's a calculate() function that returns the next state, and the constructor takes required state that's shared across calculate() calls. If the constraints weren't stored, we would have written it as a collection of free functions instead.

[chauser]

In the java code m_current is not initialized so will be null and uninitialized (in code) scalars will be initialized to zero. (edit) Oh I see you were saying the code should be changed to do those initializations. I misunderstood.

The only object state (member variable) that seems to matter in the new calculate method is the Constraints. Since the new calculate takes a time, current state, and goal state, nothing besides the Constraints are needed to derive the new state, is it?

So if you don't have totalTime, timeLeftUntil, and isFinished -- whose use cases I don't really understand in the new API -- you're left only needing m_constraints at which point, indeed, calculate could be a free function.

(further edit)
Ahhh. If totalTime and timeLeftUntil are defined similarly to new calculate they become
double totalTime(State current, State goal)
double timeUntil(State current, State goal, double target)
for which I see clear, concise semantics and use cases. Use and meaning of isFinished in this kind of context (where current and goal states are both supplied) is still unclear to me.