+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 written into the file.
JBS: https://bugs.openjdk.java.net/browse/JDK-8209576
webrevs: http://cr.openjdk.java.net/~joehw/jdk1
Hi,
Please review a fix for a condition where a code conversion was skipped
incorrectly resulting in a wrong byte array being written into the file.
JBS: https://bugs.openjdk.java.net/browse/JDK-8209576
webrevs: http://cr.openjdk.java.net/~joehw/jdk12/8209576/webrev/
Thanks,
Joe
Hi Max (I only just realised that you gave your first name in your original
email!),
I'm still unclear on what you meant earlier by "no more kid games", and
also what you mean by "I am not here to adjust maturity in channel. Agree
to get along here like adults is what". Did any earlier communicat
Hi Mr Rupplin,
I can't speak for anyone else, but I'm personally puzzled by your email.
Could you clarify what you mean by "There will be no more kid games. If you
are asked, please answer fully and promptly. Debugging a long compile
stack can be complicated."? I ask because it came across as ant
This list is for discussions related to the development of the JDK's
core libraries.
It is not a no-cost support or engineering services offering and should
be treated accordingly.
-Joe
Hello.
I have been contacted by someone who has stated that there are complaints that
we ask the channel about debug questions. I have 12+ years in Software and a
Masters Degree in Computer Science.
There will be no more kid games. If you are asked, please answer fully and
promptly. Debugg
On 08/17/2018 10:25 AM, 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;
...
old = (tio.c_lflag& ECHO);
..
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;
> ...
> old = (tio.c_lflag & ECHO);
> ...
> return old;
> }
>
> The
Hi Volker,
This may be more of a hotspot question than core-libs.
This seems like a practical feature of the implementation and a convenience
to match the conventions of C/C++ with JNI.
It might be worth adding a test to verify the assumptions between Java
and Native.
$.02, Roger
On 8/17/1
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
You made MethodType(s) and WeakEntry(s) holding them equal,
respecting the equals()/hashCode() contract. When WeakEntry lo
Hi Peter, Jason, Joe,
Thanks for the pointers. I have missed the use of
serialPersistentFields (thanks to Peter for calling this out). I read
the javadoc and serialization spec but that didn't come clearly to me.
It'd be good to include an example in the javadoc (will file a JBS issue).
W.r.t.
Hi,
we've recently discovered a problem with Console.readPassword() which
failed to restore the correct echo mode on Linux/s390x [1]. We could
finally track this down to a "bug" [2] in the s390x template
interpreter which failed to call the "result handler" after a native
call. For jboolean return
Thank you Roger and Stuart for the detailed reply. Comments inline.
On 17/08/18 7:27 AM, Stuart Marks wrote:
>
>
> Note that while this is changing javadoc and doc comments the task is
> quite a bit more rigorous than merely updating documentation. The
> javadoc for public Java SE APIs is a *sp
Hi Mandy,
This what we were doing in the past and has examples of removing fields with
expected tests:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-February/051339.html
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/017594.html
However, this case is a little differen
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.
thanks!
You made MethodType(s) and WeakEntry(s) holding them equal,
respecting the equals()/hashCode() contract. When WeakEntry looses
the referent it is left equal to
Hi Peter,
On 2018-08-17 16:04, Peter Levart wrote:
Hi Claes,
Nice trick.
thanks!
You made MethodType(s) and WeakEntry(s) holding them equal, respecting
the equals()/hashCode() contract. When WeakEntry looses the referent
it is left equal to itself only, which is enough for expunging it fro
Hi Claes,
Nice trick. You made MethodType(s) and WeakEntry(s) holding them equal,
respecting the equals()/hashCode() contract. When WeakEntry looses the
referent it is left equal to itself only, which is enough for expunging
it from map.
Regards, Peter
On 08/17/2018 12:56 PM, Claes Redestad
Hi David,
Exceptions should have a detail message that is useful.
For EIIE, all of the salient information is in the message of the cause and
is much more useful that something generic that just echos the EIIE's type.
Without a stacktrace EIIE, with a generic message is nearly useless.
Generally
Hi,
a small improvement can be seen on startup tests that exercise lambdas
and ISC if we change the interning mechanism of MethodTypes slightly so
that lookup can be done without wrapping the lookup key in a WeakEntry.
Bug: https://bugs.openjdk.java.net/browse/JDK-8209633
Webrev: http://cr.op
Hi Mandy,
The extra space is fine.
In hindsight, you could probably rename "loaderone" to just "loader" too.
Thanks for helping with this. :)
Best Regards
Adam Farley
OpenJDK Team
Runtimes
IBM
mandy chung wrote on 16/08/2018 18:57:01:
> From: mandy chung
> To: Adam Farley8
> Cc: core
On 08/17/2018 01:54 AM, mandy chung wrote:
On 8/16/18 4:48 PM, joe darcy wrote:
Just a question. Why does "private Throwable exception" field in
ExceptionInInitializerError exist? Was it there before there was a
"cause" in Throwable and later still remained there because of
serialization
21 matches
Mail list logo
