Re: Proposal: java.lang.reflect.Proxy and default methods

[Remi Forax]

Alan,
i think we should update the doc section of j.l.r.Proxy to add a sentence about 
default methods ?

Rémi

- Mail original -
> De: "Alan Bateman" 
> À: "mp911de" , core-libs-dev@openjdk.java.net
> Envoyé: Jeudi 2 Mars 2017 09:28:35
> Objet: Re: Proposal: java.lang.reflect.Proxy and default methods

> On 01/03/2017 21:14, mp911de wrote:
> 
>> Is there any progress on this issue? In the light of Java 9, the workaround
>> with
>> MethodHandles.lookup()/unreflectSpecial does not work anymore because
>> MethodHandles is encapsulated and calling setAccessible(true) on the
>> constructor fails.
>>
>> Resolving method handles inside the same module seems to work with public
>> lookup,
>> but as soon as a module defines an interface with default methods and this
>> interface is called by a proxy handler that comes from a different module,
>> it's
>> no longer possible to resolve the MethodHandle.
>>
>> Is this the appropriate mailing list for this case?
>>
> I assume you are looking for the "Non-abstract methods in interfaces"
> section in JEP 274 [1]. See also John Rose's note to jigsaw-dev about
> using Lookup.findSpecial to access default methods in interfaces [2].
> 
> -Alan
> 
> [1] http://openjdk.java.net/jeps/274
> [2]
> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-January/010741.html

Re: RFR JDK-8176029: Linebreak matcher is not equivalent to the pattern as stated in javadoc

[Xueming Shen]

On 3/2/17, 6:56 PM, Xueming Shen wrote:

Hi,

Please help review the change for JDK-8176029

issue: https://bugs.openjdk.java.net/browse/JDK-8176029
webrev: http://cr.openjdk.java.net/~sherman/8176029/webrev

It appears the API doc for \R is correct, instead the implementation 
is buggy when
dealing with sequence "\r\n" (u+000du+000a). The existing 
implementation fails to
backtrack to match \r and then next.match() when the attempt \r\n + 
next.match()
failed. As a simple obvious sample both following should return true. 
The existing

implementation returns false for the second.

"\r\n".match("\\R")
"\r\n".match("\\R\\n")


"\r\n".matches("\\R")
"\r\n".matches("\\R\\n")



Thanks,
Sherman

RFR JDK-8176029: Linebreak matcher is not equivalent to the pattern as stated in javadoc

[Xueming Shen]

Hi,

Please help review the change for JDK-8176029

issue: https://bugs.openjdk.java.net/browse/JDK-8176029
webrev: http://cr.openjdk.java.net/~sherman/8176029/webrev

It appears the API doc for \R is correct, instead the implementation is 
buggy when
dealing with sequence "\r\n" (u+000du+000a). The existing implementation 
fails to
backtrack to match \r and then next.match() when the attempt \r\n + 
next.match()
failed. As a simple obvious sample both following should return true. 
The existing

implementation returns false for the second.

"\r\n".match("\\R")
"\r\n".match("\\R\\n")

Thanks,
Sherman

Re: RFR: 8176044: (tz) Support tzdata2017a

[Naoto Sato]

Looks fine. Thanks, Ramanand.

Naoto

On 3/2/17 4:45 AM, Ramanand Patil wrote:

Hi all,
Please review the latest TZDATA integration (tzdata2017a) to JDK9.
Bug: https://bugs.openjdk.java.net/browse/JDK-8176044
Webrev: http://cr.openjdk.java.net/~rpatil/8176044/webrev.00/

All the TimeZone related tests are passed after integration.

Regards,
Ramanand.

Re: [NEW BUG]: Avoid allocations in String.replace(CharSequence, CharSequence) in case no replacement happened

[Ulf Zibis]

Am 02.03.2017 um 18:16 schrieb Vitaly Davidovich:
When the optimization applies, there shouldn't be *any* instructions for the null check on the 
path - it's done via signal handling.

Thanks for clarification.

This is Sufficiently Smart Compiler territory.  It's much better to hand-code this properly, 
particularly since nothing is lost in readability or maintainability in this case.

Convinced!

-Ulf

Re: [NEW BUG]: Avoid allocations in String.replace(CharSequence, CharSequence) in case no replacement happened

[Vitaly Davidovich]

On Thu, Mar 2, 2017 at 11:42 AM, Ulf Zibis  wrote:

>
> Am 02.03.2017 um 14:55 schrieb Vitaly Davidovich:
>
>> Implicit null checks ... generally don't cost anything.
>>
> Any additional byte of code in CPU cache prevents other code from staying
> there.

When the optimization applies, there shouldn't be *any* instructions for
the null check on the path - it's done via signal handling.

>
>
>
>> I can't imagine, if any programmer would rely on such contract,
>> instead of doing the check
>> explicitly if of significance.
>>
>> I think it's to have consistent behavior, irrespective of control flow.
>> It can detect bugs early on.
>>
> Yes, serving bug detection almost always has some cost and should be
> pondered, but the issue of this patch is to increase performance. Here I
> suspect the real value of the bug detection help.

Performance by way of removing an allocation.  There's already code in that
method that's much more expensive than a test against a register.  So while
I suggested to move the explicit null check into the if block, I don't
think it'll really matter.  But removing an allocation is always a good
thing.

>
>
> I think, the original reasonable of the contract is to rule out any
>> other exception type or
>> undefined behaviour in case of relevance of the argument. So I would
>> vote for stating the contract
>> more precisely in that way.
>>
>> Also, if I remember correct, if a variable, here replStr, is only
>> referenced later, the
>> compiler can
>> move the execution of here replacement.toString() to a later
>> position, so it is not clear to
>> me, if
>> the original implementation ever fulfilled the contract.
>>
>> Compiler can only do that if it proves a bunch of things, such as no
>> observable side effects as a result of sinking it down.  If
>> CharSequence.toString isn't devirtualized there, eg, it definitely cannot
>> do it.  I wouldn't bet on it.
>>
> For the original code in case of inlining, I guess, the optimizer would
> place the null check before the if block and the allocation of the
> replacement String after. For the new code, the optimizer can detect the
> duplicate null check inside and outside the if block, so can move it before
> the if block. So both java codes could result in the same machine code.
> IMHO the effective optimization should be proved by HS disassembler.
>
This is Sufficiently Smart Compiler territory.  It's much better to
hand-code this properly, particularly since nothing is lost in readability
or maintainability in this case.

>
> There is also the possibility, that an allocation of an intermediate
> String object is never done, because the anyway involved StringBuilder
> perhaps can insert the replacement sequence without before instantiating a
> String object.

I know C2 can remove some intermediate string allocations, but I would be
very impressed if it handled this particular method in the way you describe.

>
>
> -Ulf
>
>

Re: [NEW BUG]: Avoid allocations in String.replace(CharSequence, CharSequence) in case no replacement happened

[Ulf Zibis]

Am 02.03.2017 um 14:55 schrieb Vitaly Davidovich:

Implicit null checks ... generally don't cost anything.

Any additional byte of code in CPU cache prevents other code from staying there.



I can't imagine, if any programmer would rely on such contract, instead of 
doing the check
explicitly if of significance.

I think it's to have consistent behavior, irrespective of control flow.  It can 
detect bugs early on.
Yes, serving bug detection almost always has some cost and should be pondered, but the issue of this 
patch is to increase performance. Here I suspect the real value of the bug detection help.



I think, the original reasonable of the contract is to rule out any other 
exception type or
undefined behaviour in case of relevance of the argument. So I would vote 
for stating the contract
more precisely in that way.

Also, if I remember correct, if a variable, here replStr, is only 
referenced later, the
compiler can
move the execution of here replacement.toString() to a later position, so 
it is not clear to
me, if
the original implementation ever fulfilled the contract.

Compiler can only do that if it proves a bunch of things, such as no observable side effects as a 
result of sinking it down.  If CharSequence.toString isn't devirtualized there, eg, it definitely 
cannot do it.  I wouldn't bet on it.
For the original code in case of inlining, I guess, the optimizer would place the null check before 
the if block and the allocation of the replacement String after. For the new code, the optimizer can 
detect the duplicate null check inside and outside the if block, so can move it before the if block. 
So both java codes could result in the same machine code. IMHO the effective optimization should be 
proved by HS disassembler.


There is also the possibility, that an allocation of an intermediate String object is never done, 
because the anyway involved StringBuilder perhaps can insert the replacement sequence without before 
instantiating a String object.


-Ulf

RE: [NEW BUG]: Avoid allocations in String.replace(CharSequence, CharSequence) in case no replacement happened

[Christoph Dreis]

Hey Vitaly,

Thanks for clearing the way. 

As all things seem to be clarified now, is there someone who is willing to 
sponsor the patch?

Cheers,
Christoph

== PATCH ==

diff --git a/src/java.base/share/classes/java/lang/String.java 
b/src/java.base/share/classes/java/lang/String.jav
--- a/src/java.base/share/classes/java/lang/String.java
+++ b/src/java.base/share/classes/java/lang/String.java
@@ -2177,11 +2177,13 @@
  */
 public String replace(CharSequence target, CharSequence replacement) {
 String tgtStr = target.toString();
-String replStr = replacement.toString();
 int j = indexOf(tgtStr);
 if (j < 0) {
+// Explicit nullcheck of replacement to fulfill NPE contract in 
early out
+Objects.requireNonNull(replacement);
 return this;
 }
+String replStr = replacement.toString();
 int tgtLen = tgtStr.length();
 int tgtLen1 = Math.max(tgtLen, 1);
 int thisLen = length();

Re: [NEW BUG]: Avoid allocations in String.replace(CharSequence, CharSequence) in case no replacement happened

[Jonathan Bluett-Duncan]

Hi Vitaly,


> If there's no early bail out, there's an implicit null check when
> replacement.toString() is called...


Oh apologies! I had missed in the code that NPE does get thrown if
`replacement` is null, no matter if the `if (j < 0) { ... }` block is
entered or not, because `replacement.toString()` gets called immediately
after the if block, which of course executes an implicit null-check.

In that case, the patch LGTM. :)

Kind regards,
Jonathan

Re: [NEW BUG]: Avoid allocations in String.replace(CharSequence, CharSequence) in case no replacement happened

[Vitaly Davidovich]

On Thu, Mar 2, 2017 at 8:32 AM Ulf Zibis  wrote:

> HI,
>
> first sorry for missing the class wide definition.
>
> Am 02.03.2017 um 12:45 schrieb Vitaly Davidovich:
> >
> > On Thu, Mar 2, 2017 at 6:38 AM Ulf Zibis > wrote:
> >
> > In any case, what's the reasonable of checking an argument, which is
> not used in that case?
> >
> > My understanding is contracts like the above (let's assume it still
> called out the NPE in 8) are
> > checked even if the argument isn't used in some cases.  The other case
> where I believe this is
> > done is when passing a Supplier to some method that uses it to obtain a
> default value - even if
> > it's not needed, it's checked for null because most (all?) such methods
> stipulate that it cannot
> > be null.
> On the other hand, the null check is a waste of performance and footprint
> (implicits performance
> cost too).

Implicit null checks aren't always eliminated (e.g. calling an empty
devirtualized method will still test the receiver for null) but generally
don't cost anything.  Explicit null checks can sometimes be folded into the
implicit one by the optimizer, but not always.

>
> I can't imagine, if any programmer would rely on such contract, instead of
> doing the check
> explicitly if of significance.

I think it's to have consistent behavior, irrespective of control flow.  It
can detect bugs early on.  I agree callers can do their own checks, but
this consistency is what I've noticed JDK to prefer.

>
>
> I think, the original reasonable of the contract is to rule out any other
> exception type or
> undefined behaviour in case of relevance of the argument. So I would vote
> for stating the contract
> more precisely in that way.
>
> Also, if I remember correct, if a variable, here replStr, is only
> referenced later, the compiler can
> move the execution of here replacement.toString() to a later position, so
> it is not clear to me, if
> the original implementation ever fulfilled the contract.

Compiler can only do that if it proves a bunch of things, such as no
observable side effects as a result of sinking it down.  If
CharSequence.toString isn't devirtualized there, eg, it definitely cannot
do it.  I wouldn't bet on it.

>
>
> -Ulf
>
> --
Sent from my phone

Re: [NEW BUG]: Avoid allocations in String.replace(CharSequence, CharSequence) in case no replacement happened

[Vitaly Davidovich]

On Thu, Mar 2, 2017 at 8:26 AM, Jonathan Bluett-Duncan <
jbluettdun...@gmail.com> wrote:

> Hi Christoph and Vitaly,
>
> I am struggling to understand why the null-check for `replacement` has
> been moved within the `if (j < 0) { ... }` block. Could one of you explain
> to me the reasoning behind this change?
>
> I ask because, AFAICT, making it so that it only throws an NPE if
> `replacement` is null *and* `j < 0`, rather than throwing NPE at the very
> start of the method, seems to be going against the class-level doc which
> says, "Unless otherwise noted, passing a null argument to a constructor or
> method in this class will cause a NullPointerException to be thrown."
>
If there's no early bail out, there's an implicit null check when
replacement.toString() is called; in fact, if a null is never seen (based
on profile), there won't be any code generated for the null check (sigsegv
handling will be used instead).  If we add an explicit null check at the
top of the method, I'm not confident that the JIT will eliminate it in
cases where the method does not bail out early.  It probably doesn't
matter, really, but I don't see much harm in delaying the explicit null
check until the last moment, so to speak.

>
> Other than that, I am equally happy with `replacement` itself having an
> explicit-nullness-related comment instead of target having an
> implicit-nullness comment - it seems to deliver the same sort of message. :)
>
> Kind regards,
> Jonathan
>
> On 2 March 2017 at 07:26, Christoph Dreis 
> wrote:
>
>> Hey Vitaly and Jonathan,
>>
>> > As mentioned offline, I would move the null check right before "return
>> this".
>>
>> @Vitaly: Thanks again. Adjusted.
>> @Jonathan: Thanks. Thought about that as well, but I'd probably rather go
>> with explaining the explicit nullcheck.
>>
>> See the adjusted patch below. What do you think?
>>
>> = PATCH ==
>> diff --git a/src/java.base/share/classes/java/lang/String.java
>> b/src/java.base/share/classes/java/lang/String.java
>> --- a/src/java.base/share/classes/java/lang/String.java
>> +++ b/src/java.base/share/classes/java/lang/String.java
>> @@ -2177,11 +2177,13 @@
>>   */
>>  public String replace(CharSequence target, CharSequence replacement)
>> {
>>  String tgtStr = target.toString();
>> -String replStr = replacement.toString();
>>  int j = indexOf(tgtStr);
>>  if (j < 0) {
>> +// Explicit nullcheck of replacement to fulfill NPE contract
>> in early out
>> +Objects.requireNonNull(replacement);
>>  return this;
>>  }
>> +String replStr = replacement.toString();
>>  int tgtLen = tgtStr.length();
>>  int tgtLen1 = Math.max(tgtLen, 1);
>>  int thisLen = length();
>>
>>
>

Re: [NEW BUG]: Avoid allocations in String.replace(CharSequence, CharSequence) in case no replacement happened

[Ulf Zibis]

HI,

first sorry for missing the class wide definition.

Am 02.03.2017 um 12:45 schrieb Vitaly Davidovich:


On Thu, Mar 2, 2017 at 6:38 AM Ulf Zibis > wrote:

In any case, what's the reasonable of checking an argument, which is not 
used in that case?

My understanding is contracts like the above (let's assume it still called out the NPE in 8) are 
checked even if the argument isn't used in some cases.  The other case where I believe this is 
done is when passing a Supplier to some method that uses it to obtain a default value - even if 
it's not needed, it's checked for null because most (all?) such methods stipulate that it cannot 
be null.
On the other hand, the null check is a waste of performance and footprint (implicits performance 
cost too).
I can't imagine, if any programmer would rely on such contract, instead of doing the check 
explicitly if of significance.


I think, the original reasonable of the contract is to rule out any other exception type or 
undefined behaviour in case of relevance of the argument. So I would vote for stating the contract 
more precisely in that way.


Also, if I remember correct, if a variable, here replStr, is only referenced later, the compiler can 
move the execution of here replacement.toString() to a later position, so it is not clear to me, if 
the original implementation ever fulfilled the contract.


-Ulf

Re: [NEW BUG]: Avoid allocations in String.replace(CharSequence, CharSequence) in case no replacement happened

[Jonathan Bluett-Duncan]

Hi Christoph and Vitaly,

I am struggling to understand why the null-check for `replacement` has been
moved within the `if (j < 0) { ... }` block. Could one of you explain to me
the reasoning behind this change?

I ask because, AFAICT, making it so that it only throws an NPE if
`replacement` is null *and* `j < 0`, rather than throwing NPE at the very
start of the method, seems to be going against the class-level doc which
says, "Unless otherwise noted, passing a null argument to a constructor or
method in this class will cause a NullPointerException to be thrown."

Other than that, I am equally happy with `replacement` itself having an
explicit-nullness-related comment instead of target having an
implicit-nullness comment - it seems to deliver the same sort of message. :)

Kind regards,
Jonathan

On 2 March 2017 at 07:26, Christoph Dreis 
wrote:

> Hey Vitaly and Jonathan,
>
> > As mentioned offline, I would move the null check right before "return
> this".
>
> @Vitaly: Thanks again. Adjusted.
> @Jonathan: Thanks. Thought about that as well, but I'd probably rather go
> with explaining the explicit nullcheck.
>
> See the adjusted patch below. What do you think?
>
> = PATCH ==
> diff --git a/src/java.base/share/classes/java/lang/String.java
> b/src/java.base/share/classes/java/lang/String.java
> --- a/src/java.base/share/classes/java/lang/String.java
> +++ b/src/java.base/share/classes/java/lang/String.java
> @@ -2177,11 +2177,13 @@
>   */
>  public String replace(CharSequence target, CharSequence replacement) {
>  String tgtStr = target.toString();
> -String replStr = replacement.toString();
>  int j = indexOf(tgtStr);
>  if (j < 0) {
> +// Explicit nullcheck of replacement to fulfill NPE contract
> in early out
> +Objects.requireNonNull(replacement);
>  return this;
>  }
> +String replStr = replacement.toString();
>  int tgtLen = tgtStr.length();
>  int tgtLen1 = Math.max(tgtLen, 1);
>  int thisLen = length();
>
>

RFR: 8176044: (tz) Support tzdata2017a

[Ramanand Patil]

Hi all,
Please review the latest TZDATA integration (tzdata2017a) to JDK9.
Bug: https://bugs.openjdk.java.net/browse/JDK-8176044
Webrev: http://cr.openjdk.java.net/~rpatil/8176044/webrev.00/

All the TimeZone related tests are passed after integration.

Regards,
Ramanand.

Re: [9] RFR: 8176041: Optimize handling of comment lines in Properties$LineReader.readLine

[Paul Sandoz]

> On 2 Mar 2017, at 11:35, Claes Redestad  wrote:
> 
> Hi,
> 
> as this now significantly helps with one of our startup regression, and
> the change is very low risk, I've retargetted to 9.  Any objections?
> 

No objections, +1 for 9.

Paul.

Re: [NEW BUG]: Avoid allocations in String.replace(CharSequence, CharSequence) in case no replacement happened

[Vitaly Davidovich]

On Thu, Mar 2, 2017 at 6:45 AM Claes Redestad 
wrote:

> On 03/02/2017 11:38 AM, Ulf Zibis wrote:
> > Hi Vitaly,
> >
> > I don't see any contract to throw an NPE:
> >
> https://docs.oracle.com/javase/8/docs/api/java/lang/String.html#replace-java.lang.CharSequence-java.lang.CharSequence-
> >
>
> "Unless otherwise noted, passing anullargument to a constructor or
> method in this class will cause a|NullPointerException|
> <
> https://docs.oracle.com/javase/8/docs/api/java/lang/NullPointerException.html
> >to
> be thrown."
>
> /Claes
>
Ah, it was moved to class level docs in 8 - thanks Claes.

As a side comment, I certainly understand the desire to not repeat yourself
for each method's javadoc, but at the same time it's a bit less user
friendly as most people don't read class level docs nearly as frequently as
method level.
-- 
Sent from my phone

RE: [NEW BUG]: Avoid allocations in String.replace(CharSequence, CharSequence) in case no replacement happened

[Christoph Dreis]

Hey Ulf,

> Hi Vitaly,
> 
> I don't see any contract to throw an NPE:
> https://docs.oracle.com/javase/8/docs/api/java/lang/String.html#replace-
> java.lang.CharSequence-java.lang.CharSequence-
> 
> In any case, what's the reasonable of checking an argument, which is not
> used in that case?
> 
> 
> Am 02.03.2017 um 00:18 schrieb Vitaly Davidovich:
> > Seems like a good idea.  You probably want to null check 'replacement'
> > before the bail out as the method is specified as throwing NPE in that case.

It is stated in the class comment.

"Unless otherwise noted, passing a null argument to a constructor or method in 
this class will cause a NullPointerException to be thrown."

Cheers,
Christoph

Re: [NEW BUG]: Avoid allocations in String.replace(CharSequence, CharSequence) in case no replacement happened

[Vitaly Davidovich]

On Thu, Mar 2, 2017 at 6:38 AM Ulf Zibis  wrote:

> Hi Vitaly,
>
> I don't see any contract to throw an NPE:
>
> https://docs.oracle.com/javase/8/docs/api/java/lang/String.html#replace-java.lang.CharSequence-java.lang.CharSequence-

Hmm, I must've looked at java 7 docs, which do call out the NPE:
http://docs.oracle.com/javase/7/docs/api/java/lang/String.html#replace(java.lang.CharSequence,%20java.lang.CharSequence)

Was this changed intentionally in 8?

>
> 
>
> In any case, what's the reasonable of checking an argument, which is not
> used in that case?

My understanding is contracts like the above (let's assume it still called
out the NPE in 8) are checked even if the argument isn't used in some
cases.  The other case where I believe this is done is when passing a
Supplier to some method that uses it to obtain a default value - even if
it's not needed, it's checked for null because most (all?) such methods
stipulate that it cannot be null.

>
>
>
> Am 02.03.2017 um 00:18 schrieb Vitaly Davidovich:
> > Seems like a good idea.  You probably want to null check 'replacement'
> > before the bail out as the method is specified as throwing NPE in that
> case.
>
> --
Sent from my phone

Re: [NEW BUG]: Avoid allocations in String.replace(CharSequence, CharSequence) in case no replacement happened

[Claes Redestad]

On 03/02/2017 11:38 AM, Ulf Zibis wrote:

Hi Vitaly,

I don't see any contract to throw an NPE:
https://docs.oracle.com/javase/8/docs/api/java/lang/String.html#replace-java.lang.CharSequence-java.lang.CharSequence- 



"Unless otherwise noted, passing anullargument to a constructor or 
method in this class will cause a|NullPointerException| 
to 
be thrown."


/Claes

Re: [NEW BUG]: Avoid allocations in String.replace(CharSequence, CharSequence) in case no replacement happened

[Ulf Zibis]

Hi Vitaly,

I don't see any contract to throw an NPE:
https://docs.oracle.com/javase/8/docs/api/java/lang/String.html#replace-java.lang.CharSequence-java.lang.CharSequence-

In any case, what's the reasonable of checking an argument, which is not used 
in that case?


Am 02.03.2017 um 00:18 schrieb Vitaly Davidovich:

Seems like a good idea.  You probably want to null check 'replacement'
before the bail out as the method is specified as throwing NPE in that case.

Re: [9] RFR: 8176041: Optimize handling of comment lines in Properties$LineReader.readLine

[Claes Redestad]

Hi,

as this now significantly helps with one of our startup regression, and
the change is very low risk, I've retargetted to 9.  Any objections?

/Claes

On 03/01/2017 05:17 PM, Aleksey Shipilev wrote:

On 03/01/2017 06:11 PM, Claes Redestad wrote:

Sure, with a bit of fix-up this drops another 170k executed bytecodes
to read in the java.security file (original: 1882k, now: 980k):

http://cr.openjdk.java.net/~redestad/8176041/jdk.02/

Ok, that's fine.

This is slightly more idiomatic, you might want to change before pushing:
   c = (char)(b & 0xFF);

Thanks,
-Aleksey

Re: [10] RFR: 8176041: Optimize handling of comment lines in Properties$LineReader.readLine

[John Rose]

On Mar 1, 2017, at 5:11 PM, Claes Redestad  wrote:
> 
> It seems javac optimizes byte-char comparisons pretty well

This happened because of the JVM's bytecode ISA, which requires that javac must 
"erase" all integer subrange types (boolean, char, byte, short) internally to 
int, when emitting bytecode.  So whether you say true, '\1', (byte)1, (short)1, 
or just 1, javac will emit an "iconst_1" instruction and push 32 bits on the 
stack.  This tends to "smooth out" differences between types of 32 bits or 
less.  This is especially surprising in the case of booleans, which are not 
convertible to ints at the source level.

More JVM trivia:

The only places in the bytecode ISA where subrange types are fully significant 
are (1) field get/set, (2) array element get/set, and (3) the type-checking of 
primitive arrays.

The i2x/x2i conversions and xipush constants can be viewed as always operating 
on ints.  Method descriptor types are "partially significant", in a way that 
has evolved over time and is too complicated to describe here.

— John

Re: Proposal: java.lang.reflect.Proxy and default methods

[Alan Bateman]

On 01/03/2017 21:14, mp911de wrote:


Is there any progress on this issue? In the light of Java 9, the workaround
with
MethodHandles.lookup()/unreflectSpecial does not work anymore because
MethodHandles is encapsulated and calling setAccessible(true) on the
constructor fails.

Resolving method handles inside the same module seems to work with public
lookup,
but as soon as a module defines an interface with default methods and this
interface is called by a proxy handler that comes from a different module,
it's
no longer possible to resolve the MethodHandle.

Is this the appropriate mailing list for this case?

I assume you are looking for the "Non-abstract methods in interfaces" 
section in JEP 274 [1]. See also John Rose's note to jigsaw-dev about 
using Lookup.findSpecial to access default methods in interfaces [2].


-Alan

[1] http://openjdk.java.net/jeps/274
[2] 
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-January/010741.html