Hi Serguei,
thanks for the review.
The patch successfully ran through our nightly test system which covers all
these tests on several platforms.
Best regards
Christoph
> -Original Message-
> From: serguei.spit...@oracle.com
> Sent: Mittwoch, 20. November 2019 03:21
> To: Langer,
Hi Christoph,
The fix looks good to me.
I'd recommend to run the jdk_instrument and vmTestbase_nsk_jvmti tests.
Also, it can be safe to run:
open/test/hotspot/jtreg/serviceability/jvmti
open/test/hotspot/jtreg/runtime/cds/appcds
open/test/hotspot/jtreg/runtime/BootClassAppendProp
Thanks,
Good point. Looks good to me once this is fixed.
-- Kevin
On 11/19/2019 6:00 PM, Alexey Semenyuk wrote:
Andy,
I guess
http://cr.openjdk.java.net/~herrick/8234402/webrev.02/test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JavaTool.java.sdiff.html
can be reverted to its initial state now:
Andy,
I guess
http://cr.openjdk.java.net/~herrick/8234402/webrev.02/test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JavaTool.java.sdiff.html
can be reverted to its initial state now:
---
public ToolProvider asToolProvider() {
return ToolProvider.findFirst(name).orElse(null);
}
---
-
Looks good.
On 11/19/19 4:00 PM, Andy Herrick wrote:
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).
This change restores JPackageToolProvider and gets rid of the
temporary factory class.
[1]
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).
This change restores JPackageToolProvider and gets rid of the temporary
factory class.
[1] https://bugs.openjdk.java.net/browse/JDK-8234402
[2]
On 11/18/19 7:36 AM, Alan Bateman wrote:
>
Yes, bad values are now ignored, bringing an end to an effort on the
run-time over multiple releases to fix the problems this area.
JDK-8224253[1] is the JDK 13 release note to announce this change and I
see you've found the system property that you
On Mon, Nov 18, 2019 at 9:37 AM Alan Bateman wrote:
>
> On 18/11/2019 15:01, Jaikiran Pai wrote:
> > :
> >
> > So this Class-Path entry is being ignored starting Java 13.
> >
> Yes, bad values are now ignored, bringing an end to an effort on the
> run-time over multiple releases to fix the
Hi Christoph,
Thank you for the follow up.
> On Nov 19, 2019, at 5:37 PM, Langer, Christoph
> wrote:
>
> ModulesInCustomFileSystem
At line 71:
—
/**
* Test exploded modules in a JAR file system.
*/
———
I will look at the rest of the changes tomorrow
Best
Lance
Hi Lance,
> If you look at MultiReleaseJarTest.java, it explicitly references JAR FS in a
> comment. Same for JFSTester.java in the @Summary. These should
> definitely be updated. There are comments
> in ModulesInCustomFileSystem.java as well.
Ok, agreed for MultiReleaseJarTest and JFSTester.
Hi Joe,
The clarification looks fine to me.
Roger
On 11/19/19 1:21 PM, Joe Darcy wrote:
Hello,
Please review this small doc changes to more explicitly discuss the
special handling of enum types by serialization:
JDK-8234381: API docs should mention special handling of enums in
2019/11/19 11:17:22 -0800, john.r.r...@oracle.com:
> On Nov 19, 2019, at 4:00 AM, Lance Andersen wrote:
>> Seems to be a “your milage varies”. I am fine with whatever the
>> final decision is. However, I do believe the comment above reads
>> better and aligns the methods better.
>
> FWIW, and
Hi Christoph,
If you look at MultiReleaseJarTest.java, it explicitly references JAR FS in a
comment. Same for JFSTester.java in the @Summary. These should definitely be
updated. There are comments in ModulesInCustomFileSystem.java as well.
As far as variable names, I think this is nice to
Hi Lance,
I’m actually not so sure about this. While my cleanup change would remove the
implementation detail of zipfs to use a class named “JarFileSystem” for
multi-release jar peculiarities, I think a user of a FileSystem object upon a
jar file is not wrong if he names the variable like
On 19/11/2019 20:22, David Lloyd wrote:
:
Where can the updated specification be found? It has in the past been
clearly specified and well understood that class path entries are
interpreted as relative URLs. If that has changed then this will
definitely break Quarkus and perhaps other
> On Nov 19, 2019, at 3:22 PM, David Lloyd wrote:
>
> On Mon, Nov 18, 2019 at 9:37 AM Alan Bateman wrote:
>>
>> On 18/11/2019 15:01, Jaikiran Pai wrote:
>>> :
>>>
>>> So this Class-Path entry is being ignored starting Java 13.
>>>
>> Yes, bad values are now ignored, bringing an end to an
On Mon, Nov 18, 2019 at 9:37 AM Alan Bateman wrote:
>
> On 18/11/2019 15:01, Jaikiran Pai wrote:
> > :
> >
> > So this Class-Path entry is being ignored starting Java 13.
> >
> Yes, bad values are now ignored, bringing an end to an effort on the
> run-time over multiple releases to fix the
I took the "git diff" patch [5] that you uploaded yesterday, applied it,
and verified that it is the same as what is in the JDK-8200758-branch
branch of the sandbox. It builds and runs fine for me.
I ran jcheck and it found the following three files with whitespace
errors that will need to be
On 11/18/19 6:26 AM, Jim Laskey wrote:
http://cr.openjdk.java.net/~jlaskey/8233116/webrev.04/index.html
OK, thanks.
The changes in:
src/java.base/share/classes/java/lang/String.java
test/jdk/java/lang/String/TranslateEscapes.java
look fine.
-Brent
On Nov 19, 2019, at 4:00 AM, Lance Andersen wrote:
>
> Seems to be a “your milage varies”. I am fine with whatever the final
> decision is. However, I do believe the comment above reads better and aligns
> the methods better.
FWIW, and as author of many of the lines being changed, I prefer
Hi Christoph,
Something else that should probably be done as part of this proposed change is
to clean up tests such as NodeCostDumpUtil.java and
ModulesInCustomFileSystem.java and a few others as they have methods/fields
etc... that make reference to the Jar File System. While it does not
It's a design constraint that the "single source file mode" does not and
should not support javac-specific command-line options beyond those that
are also runtime options (for example, --class-path).
That being said, since one of the use cases is for beginners learning
Java, it seems
+1
> On Nov 19, 2019, at 10:12 AM, Vladimir Ivanov
> wrote:
>
> Thanks, Paul.
>
>> CallSite:
>> public class CallSite {
>> - // The actual payload of this call site:
>> + // The actual payload of this call site.
>> + // Can be modified using {@link
>>
Hello,
Please review this small doc changes to more explicitly discuss the
special handling of enum types by serialization:
JDK-8234381: API docs should mention special handling of enums in
serialization
http://cr.openjdk.java.net/~darcy/8234381.0/
Patch below; thanks,
-Joe
---
Thanks, Paul.
CallSite:
public class CallSite {
- // The actual payload of this call site:
+ // The actual payload of this call site.
+ // Can be modified using {@link
MethodHandleNatives#setCallSiteTargetNormal} or {@link
MethodHandleNatives#setCallSiteTargetVolatile}.
Thank you for the suggestions, Mandy and David. I've pushed the change.
-Brent
Much better :-)
I accumulated some more questions while I was looking further.
CallSite:
public class CallSite {
-// The actual payload of this call site:
+// The actual payload of this call site.
+// Can be modified using {@link
MethodHandleNatives#setCallSiteTargetNormal} or
Subtle, so I could be misunderstanding something, did you intend to remove the
assignment of isFrozen in the ConstantCallSite constructor?
Oh, good catch. It is my fault: the update should be there. (The
barriers are added just to preserve final field semantics for isFrozen.)
Published
Ah the perils of partial construction :-)
Subtle, so I could be misunderstanding something, did you intend to remove the
assignment of isFrozen in the ConstantCallSite constructor?
ConstantCallSite:
protected ConstantCallSite(MethodType targetType, MethodHandle
createTargetHook) throws
Hi Julia
> On Nov 19, 2019, at 5:06 AM, Julia Boes wrote:
>
> Hi Roger, Lance,
>
>>> If we're putting "public" on the same line as the method then
>>> it seems useful to put the /* non-public */ on the same line too.
>>> Though I don't know we have style guidance for that.
>>> (And elsewhere
It occurred to me that jshell is yet another area where we might want to
turn better NPE messages on by default.
Maurizio
On 19/11/2019 09:24, Maurizio Cimadamore wrote:
I like this suggestion a lot.
Maurizio
On 19/11/2019 08:34, Gunnar Morling wrote:
Hi,
I've been exploring the new
Hi Roger, Lance,
Can you recheck the edit to java/lang/invoke/ClassSpecializer.java: 544
I would think the line should be broken at the "..."
* class TopClass { ... * private static final class Species_LLI
extends TopClass {
That's right, there was also a closing brace missing.
Guten Tag Thorsten Schöning,
am Dienstag, 19. November 2019 um 10:30 schrieben Sie:
> Please notice that Windows has ERROR_TOO_MANY_OPEN_FILES for that, so
> in my opinion this is another strong hint that ERROR_NO_MORE_FILES
> really is some kind of success. Only undocumented/unepxected, but that
On 18.11.2019 16:56, Jaikiran Pai wrote:
Quarkus is a relatively new project and furthermore this specific code
is very new too (a few months old I think). So I think this never got
covered as part of the outreach efforts.
Yeah, Quarkus is not on the OpenJDK Quality Outreach list yet. I've
Guten Tag Ioi Lam,
am Montag, 18. November 2019 um 22:21 schrieben Sie:
> https://bugs.openjdk.java.net/browse/JDK-8234363
Thanks for doing that!
> I have not investigated the issue in detail yet. How often do you see
> ERROR_NO_MORE_FILES happening?
It's difficult to say currently because my
I like this suggestion a lot.
Maurizio
On 19/11/2019 08:34, Gunnar Morling wrote:
Hi,
I've been exploring the new helpful NPE feature a bit.
It's a very welcomed improvement, but I noticed one potential usability
issue in conjunction with the single source file mode (JEP 330): as debug
info
Hello, please review this small change .
JLI_StrTok is only used in one function, so the define can be replaced,
probably we should use the "safer" strtok_r (the MT safety might not be a big
deal in the launcher however).
Bug/webrev :
https://bugs.openjdk.java.net/browse/JDK-8234339
- Mail original -
> De: "Gunnar Morling"
> À: "core-libs-dev"
> Envoyé: Mardi 19 Novembre 2019 09:34:41
> Objet: JEP 358 (Helpful NPEs) and single source file mode
> Hi,
>
> I've been exploring the new helpful NPE feature a bit.
>
> It's a very welcomed improvement, but I noticed one
Hi,
I've been exploring the new helpful NPE feature a bit.
It's a very welcomed improvement, but I noticed one potential usability
issue in conjunction with the single source file mode (JEP 330): as debug
info is missing in that case, e.g. local variables are rendered as
"" in the exception
39 matches
Mail list logo
