With the work I'm doing at the moment at creating a Reactive Streams
equivalent to java.util.stream, I've often wondered why Stream.concat is a
static method, rather than an instance method concating the given stream
onto this. But I think the reason has just dawned on me, and I wanted to
confirm
Do we have a plan to move away from the deprecated methods? Is there a flag I
can set to check how many classes are using them?
--Max
> On Sep 30, 2018, at 11:00 PM, Alan Bateman wrote:
>
> On 27/09/2018 00:38, Igor Ignatyev wrote:
>> here is the webrevs w/ JarUtils from default package
b/c this will make test library modularization[1] somewhat troublesome, also I
ain't sure if ModuleTargetHelper really needs to be placed into the top-level
library regardless of its dependency on non-public API. "promoting" test
library class to the top-level library comes w/ increased
Hi Igor,
Would you please clarify your concern further? I mean why
ModuleTargetHelper can be put to top level when it use non-public APIs
e.g. jdk.internal.module.*?
Thank you
-Hamlin
On 2018/10/11 11:08 AM, Igor Ignatyev wrote:
Hi Hamlin,
as ModuleTargetHelper uses non-public API, I'd
Hi Hamlin,
as ModuleTargetHelper uses non-public API, I'd prefer not to have in a common
test library, and 8211976 suggests moving it closer to tests. could you please
explain why you decided to put it into the library instead?
Thanks,
-- Igor
- Original Message -
From:
Would you please review the following patch?
bug:
https://bugs.openjdk.java.net/browse/JDK-8186610
https://bugs.openjdk.java.net/browse/JDK-8211976
webrev: http://cr.openjdk.java.net/~mli/8186610/
Thank you
-Hamlin
Looks fine Brian; thanks,
-Joe
On 10/1/2018 2:31 PM, Brian Burkhalter wrote:
Please review at your convenience:
https://bugs.openjdk.java.net/browse/JDK-8152910
JMH benchmarks do show a slight but measurable performance improvement with the
below patch applied.
Thanks,
Brian
---
Thanks, Alan. This is very helpful.
On 10/10/18 9:53 AM, Alan Bateman wrote:
On 10/10/2018 16:37, Richard Hillegas wrote:
:
java.lang.invoke.MethodHandles.lookup().defineClass(generatedClassBytes)
This approach does indeed put the generated class where I want it:
inside the Derby engine
On 10/10/18 1:41 PM, Alan Bateman wrote:
On 10/10/2018 21:38, Mandy Chung wrote:
:
This assertion is not strictly necessary and
test/jdk/java/lang/invoke/DefineClassTest.java verifies these
properties of the resulting Class. I propose to remove this
assertion.
An alternative is to just
On 10/10/2018 21:38, Mandy Chung wrote:
:
This assertion is not strictly necessary and
test/jdk/java/lang/invoke/DefineClassTest.java verifies these
properties of the resulting Class. I propose to remove this
assertion.
An alternative is to just drop the PD check from the assertion, the
The assertion in Lookup::defineClass ensures that the resulting
Class is defined with the same loader in the same package in
the same protection domain as the lookup class. When a class
is defined to the boot loader, its protection domain is set to
null which implies AllPermission but
+1
On 10/10/18, 10:22 AM, Ivan Gerasimov wrote:
Hello!
The javadoc refers to the enum values as
java.text.Normalizer.Form.NFC, while it should be
java.text.Normalizer.Form#NFC.
Also an unpaired parenthesis was removed.
Would you please help review the trivial fix?
BUGURL:
Looks good to me.
-- Jon
On 10/10/18 10:22 AM, Ivan Gerasimov wrote:
Hello!
The javadoc refers to the enum values as
java.text.Normalizer.Form.NFC, while it should be
java.text.Normalizer.Form#NFC.
Also an unpaired parenthesis was removed.
Would you please help review the trivial fix?
Hello!
The javadoc refers to the enum values as java.text.Normalizer.Form.NFC,
while it should be java.text.Normalizer.Form#NFC.
Also an unpaired parenthesis was removed.
Would you please help review the trivial fix?
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8211396
WEBREV:
On 10/10/18 8:44 AM, Daniel Fuchs wrote:
Hi Mandy,
On 10/10/2018 16:32, Mandy Chung wrote:
Alternatively, this can link to java.util.Formatter class as the text
is "format string". It seems that Formatter class fits better with
the SimpleFormatter class description than String.format.
On 10/10/2018 16:37, Richard Hillegas wrote:
:
java.lang.invoke.MethodHandles.lookup().defineClass(generatedClassBytes)
This approach does indeed put the generated class where I want it:
inside the Derby engine module. Unfortunately, the ClassLoader of the
generated class is the application
Looks OK to me.
Naoto
On 10/9/18 11:19 PM, Ying Zhou wrote:
Hello,
test/java/util/Locale/LocaleCategory.sh
test/java/util/Locale/LocaleProviders.sh
Please review this patch to refactor above shell script tests to java.
bug: https://bugs.openjdk.java.net/browse/JDK-8210403
webrev:
Hi Mandy,
On 10/10/2018 16:32, Mandy Chung wrote:
On 10/10/18 3:39 AM, Daniel Fuchs wrote:
Hi,
Please find below a doc-only fix for:
8211960: broken links in java.util.logging
https://bugs.openjdk.java.net/browse/JDK-8211960
webrev:
Thanks again to Rémi and Alan for their advice. Unfortunately, I have
not been able to make either approach work, given another complexity of
Derby's class loading. Let me explain that additional issue.
Derby lets users load jar files into the database. There they live as
named blobs of
On 10/10/18 3:39 AM, Daniel Fuchs wrote:
Hi,
Please find below a doc-only fix for:
8211960: broken links in java.util.logging
https://bugs.openjdk.java.net/browse/JDK-8211960
webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8211960/webrev.00/index.html
Alternatively, this can link to
On 10/10/18 11:39, Daniel Fuchs wrote:
Hi,
Please find below a doc-only fix for:
8211960: broken links in java.util.logging
https://bugs.openjdk.java.net/browse/JDK-8211960
webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8211960/webrev.00/index.html
Looks good.
-Chris.
Hi,
Please find below a doc-only fix for:
8211960: broken links in java.util.logging
https://bugs.openjdk.java.net/browse/JDK-8211960
webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8211960/webrev.00/index.html
The original link was intended to refer to java.util.Formatter#syntax,
which is
Hi Langer,
Here are some of my comments.
ZipEntry:
Optional> getPosixPermissions()
(1) Is "Optional" really necessary here. it's a little inconsistent
compared to the rest of
methods in the class. a "null" return might be just fine?
(2) Needs a to separate the first line of
Hej Joe,
New version looks good!
Thanks for the explanations, makes sense to me.
Cheers
/Joel
On Wed, 10 Oct 2018 at 08:27, joe darcy wrote:
> Hi Joel,
>
> Thanks for the review; slightly revised version at
>
> http://cr.openjdk.java.net/~darcy/8058202.3/
>
> Comments below.
>
>
> On
Hi Joel,
Thanks for the review; slightly revised version at
http://cr.openjdk.java.net/~darcy/8058202.3/
Comments below.
On 10/9/2018 11:00 AM, Joel Borggrén-Franck wrote:
Hi Joe,
Good to see this happening. In general looks good to me, a few nits below.
AnnotatedTypeBaseImpl contains
Hello,
test/java/util/Locale/LocaleCategory.sh
test/java/util/Locale/LocaleProviders.sh
Please review this patch to refactor above shell script tests to java.
bug: https://bugs.openjdk.java.net/browse/JDK-8210403
webrev: http://cr.openjdk.java.net/~dzhou/8210403/webrev.00/
26 matches
Mail list logo
