RFR JDK-8198253: ThreadInfo.from(CompositeData) assigning fields incorrectly in JDK 9

mandy chung mandy.chung at oracle.com
Tue Feb 27 18:55:22 UTC 2018


Good point, Jeremy.  I notice some strange-ness when I wrote it but
wasn't able to pin point the error.  Daniel also suggests to clarify
MonitorInfo as well.

Does this version look better?
  

      * Returns a {@code ThreadInfo} object represented by the
      * given {@code CompositeData}.
      * <a id="attributes"></a>
      * A {@code CompositeData} representing a {@code ThreadInfo} of
      * version <em>N</em> must contain all of the attributes defined
      * in version ≤ <em>N</em> unless specified otherwise.
      * Same rule applies transitively to attributes whose type or
      * component type is {@code CompositeType}.
      * <p>
      * A {@code CompositeData} representing {@code ThreadInfo} of version
      * <em>N</em> contains {@code "stackTrace"} attribute representing
      * an array of {@code StackTraceElement} of version <em>N</em>.
      * The {@code "lockedMonitors"} attribute represents
      * an array of {@link MonitorInfo} of version <em>N</em>
      * which implies that its {@code "lockedStackFrame"} attribute also
      * represents {@code StackTraceElement} of the same version, <em>N</em>.
      * Otherwise, this method will throw {@code IllegalArgumentException}.


Mandy

On 2/27/18 9:56 AM, Jeremy Manson wrote:
> Comment on new doc wording:
>
>
> * A {@code CompositeData} representing a {@code ThreadInfo} of
> * version <em>N</em> must contain all the attributes defined
> * since <em>N</em> or earlier unless specified otherwise.
>
> Wouldn't "all of the attributes defined since N or earlier" just mean 
> "all of the attributes"?  "Since" is basically the same as "after".  
> Would "must contain all of the attributes for every version up to and 
> including N" work?
>
> Jeremy
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20180227/076cec82/attachment-0001.html>


More information about the serviceability-dev mailing list