RFR: nestmates and methodhandles

[Stas Smirnov]

Oops, thanks for catching it, it is all rsync :)

On 01/03/16 16:27, Maurizio Cimadamore wrote:
>
>
> On 01/03/16 12:42, Stas Smirnov wrote:
>> Hi all,
>>
>> so I decided to use testNG since there are a number of negative tests 
>> that will be easier to track, please take a look.
>> webrev: http://cr.openjdk.java.net/~stsmirno/webrev.02
> Something wrong with the link? I see some C code in there.
>
> Did you mean:
>
> http://cr.openjdk.java.net/~stsmirno/*netsmates*/webrev.02 ?
>
> That one looks good :-)
>
> Maurizio
>>
>> On 25/02/16 20:49, Ryan Schmitt wrote:
>>> If you're using a recent TestNG, just call Assert#assertThrows. Or, 
>>> if you want the thrown exception back, call Assert#expectThrows. 
>>> These methods work even with checked exceptions, and they allow you 
>>> to be much more specific (compared to expectedExceptions) about 
>>> where exactly the exception is supposed to come from, which helps 
>>> prevent false positives in tests.
>>>
>>> On Thu, Feb 25, 2016 at 6:39 AM, Brian Goetz <brian.goetz at oracle.com 
>>> <mailto:brian.goetz at oracle.com>> wrote:
>>>
>>>     Can I suggest doing this in TestNG?  You'll be far more productive
>>>     -- and failures are easier to debug.  You can use sophisticated
>>>     asserts rather than just comparing to a golden file. jtreg
>>>     already supports TestNG tests.
>>>
>>>     For example, each of the negative tests (try-catch-assert
>>>     expected) can be its own test method, and TestNG has a way to mark
>>>     a test method as expected to throw an exception.  So these could
>>>     be written:
>>>
>>>         @Test(expectedExceptions = ClassNotFoundException.class)
>>>         public void testProtectedMethodNeg() {
>>>             inner.getSuperMethodMH(METHOD_NAME_PROTECTED);
>>>         }
>>>
>>>     It's far more clear what's going on, and each one is its own test
>>>     case, meaning that you can pinpoint a failure more easily.
>>>
>>>     Happy to help you get up to speed on TestNG if that helps.
>>>
>>>
>>>     On 2/25/2016 8:12 AM, Stas Smirnov wrote:
>>>
>>>         Hello,
>>>
>>>         please review this set of tests to verify "parent-child"
>>>         access using MethodHandle in terms of nestmates vm exploration.
>>>         1. MethodHandleSubTop class contains methods to verify
>>>         private/protected methods/fields of the "super" class using
>>>         MethodHandle from a single one and double level of nesting
>>>         using access static bridges and direct access in negative and
>>>         positive test cases
>>>         2. MethodHandleInheritTest executes a number of positive and
>>>         negative test cases using MethodHandleSubTop methods
>>>         it will allow us to verify current implementation and future,
>>>         when access bridges will be removed and MethodHandle access
>>>         checks will be modified.
>>>
>>>         webrev:
>>> http://cr.openjdk.java.net/~stsmirno/nestmates/webrev.01
>>> <http://cr.openjdk.java.net/%7Estsmirno/nestmates/webrev.01>
>>>         Testing: RBT
>>>
>>>
>>>
>>
>

-- 
Best regards,
Stanislav