On 10/9/19 9:24 AM, Anton Kozlov wrote:
Updated webrev with fixes:
http://cr.openjdk.java.net/~akozlov/8231584/webrev.03/
I like this version. Some minor comments:
2014 static synchronized void initLibraryPaths() { This does not need
synchronized since it's still during phase 1 before
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).
- Patch is based on JDK-8231856 fix.
- Fixed by using URI to escape URLs. URLEncoder.encode() encodes form
data and it will use "+" for space. pkg
Looks OK Joe
> On Oct 9, 2019, at 6:37 PM, Joe Darcy wrote:
>
> Hello,
>
> The serialization review continues, this time a few fields in the java.naming
> module:
>
> http://cr.openjdk.java.net/~darcy/8232076.0/
>
> Patch below; thanks,
>
> -Joe
>
> ---
>
Hi,
Please review the fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8225435
The proposed changeset is located at:
https://cr.openjdk.java.net/~naoto/8225435/webrev.00/
The change is to upgrade the data file to the latest (dated 2019-09-16).
A relevant test case is
Hi,
Please review the fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8231273
The proposed changeset is located at:
https://cr.openjdk.java.net/~naoto/8231273/webrev.00/
The webrev is huge, but majority of the changes is just to replace the
CLDR source locale data from
Hello,
The serialization review continues, this time a few fields in the
java.naming module:
http://cr.openjdk.java.net/~darcy/8232076.0/
Patch below; thanks,
-Joe
---
old/src/java.naming/share/classes/com/sun/jndi/toolkit/ctx/Continuation.java
2019-10-09 15:32:45.25800 -0700
+++
I revised the fix, incorporating the clarification of the value zero as
the grouping size, which has separate JIRA issue and CSR as follows:
https://bugs.openjdk.java.net/browse/JDK-8231984
https://bugs.openjdk.java.net/browse/JDK-8232012
The merged changeset is as follows:
Looks fine.
Roger
On 10/9/19 1:10 PM, Joe Darcy wrote:
Thanks for the reviews.
Running some final checks, I'd also like to include two more
@SuppressWarnings to clear the issues in java.base outside of
java.util.concurrent; patch below.
Thanks,
-Joe
diff -r 6e017b301287
Thanks for the reviews.
Running some final checks, I'd also like to include two more
@SuppressWarnings to clear the issues in java.base outside of
java.util.concurrent; patch below.
Thanks,
-Joe
diff -r 6e017b301287
On 10/9/2019 10:58 AM, Andrey Volkov wrote:
Hello.
Can you give a hint or en example how to use --resource-dir option for
jpackage?
According to the help, it is possible to override jpackage's resources
(icons, logos, etc. that are shown in installers). Is it right?
generally yes, if the
Hello.
Can you give a hint or en example how to use --resource-dir option for
jpackage?
According to the help, it is possible to override jpackage's resources
(icons, logos, etc. that are shown in installers). Is it right?
--
Best regards,
Andrey Volkov
Hi Mandy,
thanks for the review!
Updated webrev with fixes:
http://cr.openjdk.java.net/~akozlov/8231584/webrev.03/
Few notes below:
On 08.10.2019 01:20, Mandy Chung wrote:
> I think another way doing it is to initialize ClassLoader.sys_paths and
> usr_paths fields at System::initPhase1. These
Oh, you are absolutely correct, the dependency is missing.
We need something like this inside "define SetupInterimModule":
$$(BUILD_$1.interim): $(COPY_PREVIEW_FEATURES)
/Erik
On 2019-10-09 01:42, Magnus Ihse Bursie wrote:
I can’t see how the compilation is dependent on the copy being
looks good.
/Andy
On 10/8/2019 10:24 PM, Alexander Matveev 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).
- Fixed by adding read permissions to all jars during installation.
[1]
+1
On 10/9/19 7:56 AM, Chris Hegarty wrote:
Joe,
On 05/10/2019 04:04, Joe Darcy wrote:
Hello,
Please review the revised fix:
http://cr.openjdk.java.net/~darcy/8231202.1/
Given the prior discussion in this thread, then I think this version
looks fine ( which consists solely of
Joe,
On 05/10/2019 04:04, Joe Darcy wrote:
Hello,
Please review the revised fix:
http://cr.openjdk.java.net/~darcy/8231202.1/
Given the prior discussion in this thread, then I think this version
looks fine ( which consists solely of warning suppressions ).
-Chris.
On 08/10/2019 17:17, Kiran Ravikumar wrote:
Hi Guys,
I am a new hire with the Oracle Java Platform Group and will be working
mainly on JDK Update releases. Below is my first contribution. Looking
forward to contribute more to the community.
Please review the fix:
Bug
I can’t see how the compilation is dependent on the copy being finished. Since
Erik contributed this it will probably be correct :) but I’d appreciate an
explanation on how this dependency is guaranteed.
Or maybe I’m misunderstanding what this is supposed to do?
/Magnus
> 8 okt. 2019 kl.
On 10/8/19 8:37 PM, Claes Redestad wrote:
On 2019-10-08 18:57, Kazunori Ogata wrote:
Hi Claes,
Thank you for your review and comment.
I was also wondering why only these two fields aren't initialized in the
constructor. Shall I also make the change you mentioned?
I think it might be
Hi Ogata,
May I just add that volatile field ensured that MethodAccessor object
was correctly published. DelegatingMethodAccessortImpl is not safe to be
published via data race because it contains plain `delegate` field
initialized in the constructor. In addition, the object that is first
Looks good Kiran. I'll sponsor this for you.
regards,
Sean.
On 08/10/2019 17:17, Kiran Ravikumar wrote:
Hi Guys,
I am a new hire with the Oracle Java Platform Group and will be
working mainly on JDK Update releases. Below is my first contribution.
Looking forward to contribute more to the
21 matches
Mail list logo
