Hi Christoph,
I looked at the changes. Mostly good - true to the original change.
At various places
(e.g. src/java.base/share/classes/java/lang/ClassLoader.java) one could
remove the extra brackets, but since we want to keep the diff to head at a
minimum where possible I would not do this.
Howev
Hi Guy,
This looks really good, a couple of quick questions and comments.
1)
I think a natural home for this would be java.math?
2)
Couldn't we use default methods and skip all of the abstract classes?
I assume all the abstract classes are stateless. Don't know if there
would be performance pena
Hi,
On 2019-06-24 09:27, Thomas Stüfe wrote:
However, your patch (and the original one) contained the following part I
do not understand:
http://cr.openjdk.java.net/~clanger/webrevs/8215281.11u/src/java.base/windows/classes/sun/nio/ch/FileDispatcherImpl.java.udiff.html
static boolean is
On 21/06/2019 21:20, Joe Wang wrote:
Full webrev (for the record)
http://cr.openjdk.java.net/~joehw/jdk13/8224157/webrev_02/
A short version of webrev_02 that includes the only files mentioned in
this review:
http://cr.openjdk.java.net/~joehw/jdk13/8224157/webrev_02_short/
Thanks Joe!
The
Hi,
thanks, Claes for chiming in and explaining. I also went through the code and
concur - behavior should not have changed and code is cleaned up nicely.
So I think this backport has received enough reviewer attention. Will push it
then as regression tests seem all good, too. 😊
Thanks to all
Ship it.
Cheers, Thomas
On Mon, Jun 24, 2019 at 11:27 AM Langer, Christoph
wrote:
> Hi,
>
> thanks, Claes for chiming in and explaining. I also went through the code
> and concur - behavior should not have changed and code is cleaned up nicely.
>
> So I think this backport has received enough r
HI Claes,
On Mon, Jun 24, 2019 at 10:22 AM Claes Redestad
wrote:
> Hi,
>
>
> On 2019-06-24 09:27, Thomas Stüfe wrote:
> > However, your patch (and the original one) contained the following part I
> > do not understand:
> >
> >
> http://cr.openjdk.java.net/~clanger/webrevs/8215281.11u/src/java.ba
Hi Alan,
I have uploaded a webrev which I believe answers all outstanding review
comments:
JIRA: https://bugs.openjdk.java.net/browse/JDK-8224974
webrev: http://cr.openjdk.java.net/~adinn/8224974/webrev.08/
This includes the changes Joe Darcy highlighted in his code review of
the implement
Hi,
Could I please get reviews for this 8u only change? The JDK 8u build
logic for launcher files includes linker version script files (a.k.a
mapfiles). The script file for x86 (32bit) marks symbol _IO_stdin_used
as local. When the symbol is not visible to the dynamic loader, glibc
will use a lega
Hi,
please help me reviewing the backport of "JDK-8211122: Reduce the number of
internal classes made accessible to jdk.unsupported". The main reason for
backporting this item is that it'll ease further backports which base on that
changeset. The patch is quite extensive and hence doesn't fully
* Severin Gehwolf:
> Could I please get reviews for this 8u only change? The JDK 8u build
> logic for launcher files includes linker version script files (a.k.a
> mapfiles). The script file for x86 (32bit) marks symbol _IO_stdin_used
> as local. When the symbol is not visible to the dynamic loader
> Perhaps someone should do some more benchmarks. But
> that seems like an advantage of using addAll.
Hello,
I've done benchmarking for all JDK 12 basic Collections eligeable for
post-creation modification.
Benchmark is available here:
https://github.com/stsypanov/benchmarks/blob/master/benchm
On 24/06/2019 14:54, Florian Weimer wrote:
> * Severin Gehwolf:
>
>> Could I please get reviews for this 8u only change? The JDK 8u build
>> logic for launcher files includes linker version script files (a.k.a
>> mapfiles). The script file for x86 (32bit) marks symbol _IO_stdin_used
>> as local
On 24/06/2019 14:48, Severin Gehwolf wrote:
> Hi,
>
> Could I please get reviews for this 8u only change? The JDK 8u build
> logic for launcher files includes linker version script files (a.k.a
> mapfiles). The script file for x86 (32bit) marks symbol _IO_stdin_used
> as local. When the symbol
On 6/24/19 2:51 PM, Langer, Christoph wrote:
> please help me reviewing the backport of “JDK-8211122: Reduce the
> number of internal classes made accessible to jdk.unsupported”. The
> main reason for backporting this item is that it’ll ease further
> backports which base on that changeset. The pa
> I'm nervous. Although I expect this won't cause any JCK compatibility
> issues, it is a behavioural change. I wonder if we should consider
> referring this one to the CSR team.
+1
The original issues didn't have CSRs attached but it really feels CSRish. Let
me know whether I shall create CSR
On 6/24/19 3:23 PM, Langer, Christoph wrote:
> The original issues didn't have CSRs attached but it really feels CSRish. Let
> me know whether I shall create CSRs as you're still sorting out the process.
Please go ahead. This is a small change that'll be a good test of the process.
--
Andrew Ha
* Andrew John Hughes:
> On 24/06/2019 14:54, Florian Weimer wrote:
>> * Severin Gehwolf:
>>
>>> Could I please get reviews for this 8u only change? The JDK 8u build
>>> logic for launcher files includes linker version script files (a.k.a
>>> mapfiles). The script file for x86 (32bit) marks symbol
On 24/06/2019 15:52, Florian Weimer wrote:
> * Andrew John Hughes:
>
>> On 24/06/2019 14:54, Florian Weimer wrote:
>>> * Severin Gehwolf:
>>>
Could I please get reviews for this 8u only change? The JDK 8u build
logic for launcher files includes linker version script files (a.k.a
On 24/06/2019 15:23, Langer, Christoph wrote:
:
The original issues didn't have CSRs attached but it really feels CSRish. Let
me know whether I shall create CSRs as you're still sorting out the process.
The sun.applet package was JDK internal so no CSR required to change or
remove anything in t
On Mon, 2019-06-24 at 16:52 +0200, Florian Weimer wrote:
> * Andrew John Hughes:
>
> > On 24/06/2019 14:54, Florian Weimer wrote:
> > > * Severin Gehwolf:
> > >
> > > > Could I please get reviews for this 8u only change? The JDK 8u build
> > > > logic for launcher files includes linker version sc
I just realised I sent my last reply to Anthony only... apologies. Please
see below.
Cheers,
Abraham
El mié., 19 jun. 2019 a las 17:43, Abraham Marin-Perez (<
abraham.marin.pe...@gmail.com>) escribió:
> Hi Anthony,
>
> There is code before and after compareIfPresent, but yeah, we could have
> r
On Jun 20, 2019, at 12:12 AM, Ioi Lam wrote:
> ...
> I have a rough idea -- let's have a higher-level representation of the
> bytecode stream than byte[] or ByteBuffer, to make optimization possible.
Template classes will need something similar, so maybe there is a common design
point in here.
On 6/24/19, 2:23 AM, Daniel Fuchs wrote:
On 21/06/2019 21:20, Joe Wang wrote:
Full webrev (for the record)
http://cr.openjdk.java.net/~joehw/jdk13/8224157/webrev_02/
A short version of webrev_02 that includes the only files mentioned
in this review:
http://cr.openjdk.java.net/~joehw/jdk13/
The next EA build of JPackage is available at https://jdk.java.net/jpackage/
This build ( jdk-14-jpackage+1-8 ) is the first early access release
based on JDK-14
This release contains fixes to the following issues:
JDK-8225428: CLI change to remove "mode", rename to "package", and build
only
On 24/06/2019 18:24, Joe Wang wrote:
Keeping the code in sync with the BCEL (not perfect) source is in our
interest to produce smaller changeset in any future updates. Would you
be okay with the current webrevs?
Yes. This was just a remark that maybe the inconsistency should
be reported upstre
On 6/24/19, 12:00 PM, Daniel Fuchs wrote:
On 24/06/2019 18:24, Joe Wang wrote:
Keeping the code in sync with the BCEL (not perfect) source is in our
interest to produce smaller changeset in any future updates. Would
you be okay with the current webrevs?
Yes. This was just a remark that may
> On Jun 24, 2019, at 3:46 AM, Kasper Nielsen wrote:
>
> Hi Guy,
>
> This looks really good, a couple of quick questions and comments.
>
> 1)
> I think a natural home for this would be java.math?
Good suggestion; but others have suggested making a new package
java.util.random.
One advantage
I found a bug in Inet6Adress.isIPv4CompatibleAddress(). While parsing
correctly uses the ::: format, isIPv4CompatibleAddress()
checks for :: instead. An example:
Inet6Address address = (Inet6Address)
InetAddress.getByName("::192.168.1.13");
System.out.printf("%s: %b%n", address,
a
Please review the jpackage fix for bug [1] at [2].
This is a fix for the JDK-8200758-branch branch of the open sandbox
repository (jpackage).
- Duplicated Java options were not read correctly from OrderedMap,
instead we read only unique from map. Fixed by reading duplicated Java
options.
[
Please review fix for [1], at [2]. The implementation of method
MethodTypeDesc.resolveConstantDes is not in sync with its specification.
In particular where it says [3]:
Resolves this descriptor reflectively, emulating the resolution behavior
of JVMS 5.4.3 and the access control behavior of JV
Hello!
Would someone volunteer to review this extra-small doc-only fix?
Thanks in advance!
With kind regards,
Ivan
On 5/28/19 9:33 AM, Ivan Gerasimov wrote:
Hello!
When the fix for JDK-7039066 (which added support for the flag
UNICODE_CHARACTER_CLASS and corresponding embedded expression
On 24/06/2019 21:57, Rob Spoor wrote:
I found a bug in Inet6Adress.isIPv4CompatibleAddress(). While parsing
correctly uses the ::: format, isIPv4CompatibleAddress()
checks for :: instead.
The notion "IPv4-compatible IPv6 address" is different to "IPv4-mapped
IPv6 address". I think the RFCs
33 matches
Mail list logo
