Hi Tagir,
Thanks for working on this. This looks really cool! And thanks Peter for
agreeing to sponsor it.
I can help out with the CSR. My first bit of advice about the CSR process is to
hold off until the specification is complete. :-)
I think the intent of the API is fine, but I think som
On 8/20/18 6:06 PM, David Holmes wrote:
If EIIE must have a detail message then that should just be something
explicit like:
Caused by :
This is of course what you actually propose by using cause.toString() -
for some reason I was thinking you were just using the cause's detail
message
I note that the only place that R appears is in the output of the
merger. So the "? extends" is not needed there; it can be just
BiFunction.
On 8/20/2018 4:48 AM, Tagir Valeev wrote:
Hello!
A CSR is created:
https://bugs.openjdk.java.net/browse/JDK-8209685
(this is my first CSR, hopefully I
Hi Mandy,
A correction on my part ...
On 17/08/2018 8:22 AM, David Holmes wrote:
On 17/08/2018 1:18 AM, mandy chung wrote:
On 8/15/18 11:00 PM, David Holmes wrote:
Hi Mandy,
Not a review - sorry :)
On 16/08/2018 7:46 AM, mandy chung wrote:
ExceptionInInitializerError(Throwable cause) sets
> On Aug 20, 2018, at 12:23 PM, Andrew Haley wrote:
>
> On 08/20/2018 04:14 PM, Jason Greene wrote:
>
>> IMO departing from C semantics (non-zero = TRUE, zero = false)
>> offers little gain and will likely just lead to hard to catch
>> bugs. Even if the JNI developer knows the rules, it will b
Looks fine.
-Brent
On 8/20/18 11:29 AM, Igor Ignatyev wrote:
http://cr.openjdk.java.net/~iignatyev//8209740/webrev.00/index.html
1 line changed: 0 ins; 0 del; 1 mod;
Hi all,
could you please review this trivial fix for the typo in SkippedException.java
? Thank Martin B for reporting the ty
http://cr.openjdk.java.net/~iignatyev//8209740/webrev.00/index.html
> 1 line changed: 0 ins; 0 del; 1 mod;
Hi all,
could you please review this trivial fix for the typo in SkippedException.java
? Thank Martin B for reporting the typo.
JBS: https://bugs.openjdk.java.net/browse/JDK-8209740
webre
Thanks Volker! I hadn't been following new development much and this is
great!
I just checked the latest HS sources [1] and my old code is still there.
I'll prepare a webrev to remove that workaround code.
Thanks,
Kris
[1]:
http://hg.openjdk.java.net/jdk/jdk/file/8dfed4387312/src/hotspot/share/c1
On 08/20/2018 04:14 PM, Jason Greene wrote:
> IMO departing from C semantics (non-zero = TRUE, zero = false)
> offers little gain and will likely just lead to hard to catch
> bugs. Even if the JNI developer knows the rules, it will be quite
> easy for surprises to show up. For example, a developer
Thanks Sherman!
All tests in core were passed. The patch is now pushed.
-Joe
On 8/17/18, 2:49 PM, Xueming Shen wrote:
+1
On 08/17/2018 02:39 PM, Joe Wang wrote:
Hi,
Please review a fix for a condition where a code conversion was
skipped incorrectly resulting in a wrong byte array being wri
On Mon, Aug 20, 2018 at 6:09 PM, Krystal Mok wrote:
> Hi guys,
>
> Haha this is fun. I actually hit this issue the hard way and had to tweak a
> bit of my code to accommodate that: I had to return a jint from a function
> that I wanted to return a jbool at first:
> http://hg.openjdk.java.net/hsx/h
Hi guys,
Haha this is fun. I actually hit this issue the hard way and had to tweak a
bit of my code to accommodate that: I had to return a jint from a function
that I wanted to return a jbool at first:
http://hg.openjdk.java.net/hsx/hsx25/hotspot/diff/8f37087fc13f/src/share/vm/c1/c1_Runtime1.cpp
On 8/20/2018 4:19 PM, Chris Hegarty wrote:
On 19 Aug 2018, at 12:51, vyom tewari wrote:
Hi,
Please review the below code change.
Webrev : http://cr.openjdk.java.net/~vtewari/8176553/webrev0.0/index.html
bugid: https://bugs.openjdk.java.net/browse/JDK-8176553
Our all internal tests
On Mon, Aug 20, 2018 at 4:55 PM, Aleksey Shipilev wrote:
> On 08/20/2018 12:22 PM, Volker Simonis wrote:
>> So to summarize, my current view on this topic is:
>> - JNI functions returning a jboolean are only allowed to return
>> JNI_TRUE/JNI_FALSE (or 1/0) according to the current JNI spcificatio
Hi Alan,
Round 4:
I have redrafted the JEP and updated the implementation in the light of
your last feedback:
JEP JIRA: https://bugs.openjdk.java.net/browse/JDK-8207851
Formatted JEP: http://openjdk.java.net/jeps/8207851
New webrev: http://cr.openjdk.java.net/~adinn/pmem/webrev.04/
n.b.
> On Aug 20, 2018, at 9:55 AM, Aleksey Shipilev wrote:
>
> On 08/20/2018 12:22 PM, Volker Simonis wrote:
>> So to summarize, my current view on this topic is:
>> - JNI functions returning a jboolean are only allowed to return
>> JNI_TRUE/JNI_FALSE (or 1/0) according to the current JNI spcificat
On 08/20/2018 12:22 PM, Volker Simonis wrote:
> So to summarize, my current view on this topic is:
> - JNI functions returning a jboolean are only allowed to return
> JNI_TRUE/JNI_FALSE (or 1/0) according to the current JNI spcification.
Now *I* am having trouble seeing where exactly the JNI spec
Hi,
I think this is a very good addition to the Collectors API. Whereas somehow
specific, it will come in very handy when needed.
But the name... well, honestly, teeingAndThen doesn't tell me anything from
the perspective of an user of the API. What is 'teeing'? What does 'tee'
actually mean? Or
Hello everyone,
I'm requesting a review of a documentation change which was discussed in
a recent thread[1][2]. Here's an initial proposed draft, for a better
documentation of Arrays.asList method:
/**
* Returns a fixed-size list backed by the specified array. The passed
* array is
Ok, will do.
On 2018-08-20 13:31, Peter Levart wrote:
Hi Claes,
That's ok. You could also add @see tag to WeakEntry.equals pointing to
MethodType.equals. The other way around is not possible, but you could
spell-out the same: "See also WeakEntry.equals()"
Hi Claes,
That's ok. You could also add @see tag to WeakEntry.equals pointing to
MethodType.equals. The other way around is not possible, but you could
spell-out the same: "See also WeakEntry.equals()"
Regards, Peter
On 08/20/2018 12:56 PM, Claes Redestad wrote:
Yes, perhaps just pointers
Hi Mandy,
On 2018-08-17 19:07, mandy chung wrote:
On 8/17/18 7:38 AM, Peter Levart wrote:
On 08/17/2018 04:32 PM, Claes Redestad wrote:
Hi Peter,
On 2018-08-17 16:04, Peter Levart wrote:
Hi Claes,
Nice trick.
+1
thanks!
You made MethodType(s) and WeakEntry(s) holding them equal,
> On 19 Aug 2018, at 12:51, vyom tewari wrote:
>
> Hi,
>
> Please review the below code change.
>
> Webrev : http://cr.openjdk.java.net/~vtewari/8176553/webrev0.0/index.html
>
> bugid: https://bugs.openjdk.java.net/browse/JDK-8176553
>
> Our all internal tests are clean, this patch is
On Fri, Aug 17, 2018 at 7:25 PM, Aleksey Shipilev wrote:
> On 08/17/2018 05:12 PM, Volker Simonis wrote:
>> The offending code in Console_md.c looks as follows:
>>
>> #define ECHO8
>>
>> JNIEXPORT jboolean JNICALL
>> Java_java_io_Console_echo(...) {
>>
>> jboolean old;
>> ...
>> ol
Hi, Roger
Sorry for the late response since I was on vacation and thank you for the
comments, inline and update webrev as below
http://cr.openjdk.java.net/~xyin/8200151/webrev.03/
> On 11 Aug 2018, at 1:47 AM, Roger Riggs wrote:
>
> Hi Chris,
>
> There seems to be a lot of repetition in test
Hello!
A CSR is created:
https://bugs.openjdk.java.net/browse/JDK-8209685
(this is my first CSR, hopefully I did it correctly)
With best regards,
Tagir Valeev.
On Mon, Aug 20, 2018 at 2:06 PM Peter Levart wrote:
>
> Hi Tagir,
>
> I think this looks very good. It just needs a CSR. Will you file i
Hi Chris,
Latest webrev(.02) looks good to me. One minor comment i will suggest
you to expand "setContext" as you did for other JNDI tests.
Thanks,
Vyom
On Friday 10 August 2018 02:34 PM, Chris Yin wrote:
Sorry... another minor revision to handle @Override line and imports place, new
web
Hi Tagir,
I think this looks very good. It just needs a CSR. Will you file it?
Regards, Peter
On 08/19/2018 11:24 AM, Tagir Valeev wrote:
Hello, Brian!
Of the three phases, teeing is the most important and least obvious, so
I think something that includes that in the name is going to be
help
28 matches
Mail list logo
