Aside from the easiest code, you might want to consider correct and robust code.
Assume following input:
[ param=40.2] [foobar =20] junk [=1500]. Your code will actually parse this, even though that is likely to be wrong. You have to test if the input actually conforms to a certain format. During parsing, you throw away the information from the labels like
param, and rather rely on the order. If you don't check for validity, and the format changes unexpectedly, you'll have hard to trace bugs.
I would suggest you parse the data into a
Map<String, Double>. The parsing can easily be done by regexes, e.g. the pattern
\G \s*\[\s* ([^=]+) \s*=\s* ([^\]]*) \s*\]\s* (spaces are insignificant – use the
Pattern.COMMENTS flag). This is laxer than your
substr parsing, but is able to reject malformed input. This also asserts that the matches are adjacent, so no junk will be in between.
Next, you iterate through all matches, updating the
Map each time. The regex does not attempt to parse valid doubles – I'd let possible
Double.parseDouble(...) bubble up. Likewise, you should complain when the parsed data does not contain
indicator fields. Note that this is a semantic constraint that should be tested after the parsing.
I won't show a reimplementation taking these points into consideration because BjoernH's answer already implements the relevant points.