P.S. To see the proposed JSR 292 spec changes only (no code, rendered
javadoc), see:
http://cr.openjdk.java.net/~jrose/pres/201309-jsr292/1-specdiff-meth-info-8008688
http://cr.openjdk.java.net/~jrose/pres/201309-jsr292/2-specdiff-meth-arity-8019417
http://cr.openjdk.java.net/~jrose/pres/201309-
On Sep 12, 2013, at 5:44 PM, David Chase wrote:
> Do these sibling bugs have numbers?
Yes, 8022701. I just updated the bug to explain their common genesis.
> And I take it you would like to see
>
> 1) a test enhanced with ASM to do all 3 variants of this
Yes, please. The case of "no such fi
Please review this change for a change to the JSR 292 implementation:
http://cr.openjdk.java.net/~jrose/8001110/webrev.00/
Summary: promote an existing private method; make unit tests on all argument
positions to arity 10 with mixed types
The change is to javadoc and unit tests, documenting and
Please review this change for a change to the JSR 292 implementation:
http://cr.openjdk.java.net/~jrose/8024599/webrev.00/
Summary: Align MH semantic with bytecode behavior of constructor and static
member accesses, regarding invocation.
The change is to javadoc and unit tests, documenting and
Please review this change for a change to the JSR 292 implementation:
http://cr.openjdk.java.net/~jrose/8001108/webrev.00
Summary: add an explicit check for leading "<", upgrade the unit tests
The change is mostly to javadoc and unit tests, documenting and testing some
corner cases of JSR 292 A
Please review this change for a change to the JSR 292 implementation:
http://cr.openjdk.java.net/~jrose/8024761/webrev.00/
Bug description: The performance of MethodHandle.invoke is very slow when the
call site type differs from the method handle type. When the types differ, the
invocation is
Please review this change for a change to the JSR 292 implementation:
http://cr.openjdk.java.net/~jrose/8001109/webrev.00/
The change is mostly to javadoc and unit tests, documenting and testing some
corner cases of JSR 292 APIs.
In the RI, the exception-raising code is simplified to throw just
Do these sibling bugs have numbers?
And I take it you would like to see
1) a test enhanced with ASM to do all 3 variants of this
2) DO attach the underlying cause
David
On 2013-09-12, at 5:35 PM, John Rose wrote:
> It looks good. I have three requests.
>
> Regarding this comment:
> + *
On Sep 12, 2013, at 4:34 PM, John Rose wrote:
> Please review this change for a change to the JSR 292 implementation:
>
> http://cr.openjdk.java.net/~jrose/8019417/webrev.00
>
> The change is to javadoc and unit tests, documenting and testing some corner
> cases of JSR 292 APIs.
>
> Since th
Please review this change for a change to the JSR 292 implementation:
http://cr.openjdk.java.net/~jrose/8019417/webrev.00
The change is to javadoc and unit tests, documenting and testing some corner
cases of JSR 292 APIs.
Since the RI is already correct, there are no implementation code changes
It looks good. I have three requests.
Regarding this comment:
+ * See MethodSupplier.java to see how to produce these bytes.
+ * They encode that class, except that method m is private, not public.
The recipe is incomplete, since it does not say which bits to tweak to make m
private. P
The test is adapted from the test in the bug report.
The headline on the bug report is wrong -- because it uses reflection in the
test to do the invocation,
the thrown exception is wrapped with InvocationTargetException, which is
completely correct.
HOWEVER, the exception inside the wrapper is th
On Sep 12, 2013, at 11:28 AM, David Chase wrote:
> New webrev, commented line removed:
> http://cr.openjdk.java.net/~drchase/8022701/webrev.03/
I think the change is good given that the tests work now. Is your test derived
from the test in the bug report?
And it would be good if John could a
+ // err.initCause(ex);
Why is this commented?
-- Chris
On Sep 6, 2013, at 4:59 PM, David Chase wrote:
> new, improved webrev: http://cr.openjdk.java.net/~drchase/8022701/webrev.02/
> Same small changes to the sources, plus a test.
>
> bug: wrong exception was thrown in call of me
I believe it produced extraneous output -- it was not clear to me that it was
either necessary or useful to fully describe all the converted exceptions that
lead to the defined exception being thrown. The commented line should have
just been removed (I think).
On 2013-09-12, at 1:24 PM, Christ
New webrev, commented line removed:
http://cr.openjdk.java.net/~drchase/8022701/webrev.03/
On 2013-09-12, at 1:53 PM, David Chase wrote:
> I believe it produced extraneous output -- it was not clear to me that it was
> either necessary or useful to fully describe all the converted exceptions
>
16 matches
Mail list logo
