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 co
Looks good
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] https://bugs.openj
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] https://bugs.openjdk.java.net/browse/JDK-8231858
[2] http://cr.openjdk.java.ne
Hi, Vladimir
On 10/8/19 3:18 PM, Vladimir Yaroslavskiy wrote:
The following renaming changes are important
and should be kept. My explanation is here
> ...
Thanks for the explanation - much appreciated.
* Other changes, like failed -> fail, i++ -> ++i,
and TypeConverter, FloatBuilder, Doubl
On 10/7/19 1:12 AM, Alan Bateman wrote:
On 7/10/2019 4:43 pm, Alan Bateman wrote:
On 07/10/2019 04:35, David Holmes wrote:
You can temporarily workaround with
-XX:+ClassForNameDeferLinking, but your code needs to be
updated to deal with LinkageErrors from Class.forName. >>>
I suspect this
Hi Andy,
Looks good.
Thanks,
Alexander
On 10/8/2019 3:29 PM, Alexey Semenyuk wrote:
Looks good.
- Alexey
On 10/8/2019 6:09 PM, Andy Herrick wrote:
Minor revision after some discussion:
[3]: http://cr.openjdk.java.net/~herrick/8231910/webrev.02
/Andy
On 10/8/2019 3:06 PM, Andy Herrick wr
Looks good.
- Alexey
On 10/8/2019 6:09 PM, Andy Herrick wrote:
Minor revision after some discussion:
[3]: http://cr.openjdk.java.net/~herrick/8231910/webrev.02
/Andy
On 10/8/2019 3:06 PM, Andy Herrick wrote:
Please review the jpackage fix for bug [1] at [2].
This is a fix for the JDK-8200
Hi Brent,
Thank you for review, see my comments inline:
>Oct 8, 2019, 1:53 +03:00 от Brent Christian :
>
>Hi, Vladimir
>
>I've read through the changes[1]. I have the following comments:
>
>---
>src/java.base/share/classes/java/util/Arrays.java
>
>* Regarding the indentation changes in the equal
Minor revision after some discussion:
[3]: http://cr.openjdk.java.net/~herrick/8231910/webrev.02
/Andy
On 10/8/2019 3:06 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).
Th
On 10/8/2019 4:27 PM, Alexey Semenyuk wrote:
Anyway - the code to get the wix tools version only once is not
really a part of this fix, just triggered by your desire to print out
all of the usage text from candle and light when getting their
version with --verbose option.
So I can remove
On 10/8/2019 4:21 PM, Andy Herrick wrote:
On 10/8/2019 3:33 PM, Alexey Semenyuk wrote:
Andy,
AbstractAppImageBuilder.java: is extra ` + File.separator` by intention?
this was just trying to be consistent - doesn't matter to native code
who is only one to see this value - but I should proba
On 10/8/2019 3:33 PM, Alexey Semenyuk wrote:
Andy,
AbstractAppImageBuilder.java: is extra ` + File.separator` by intention?
this was just trying to be consistent - doesn't matter to native code
who is only one to see this value - but I should probably change back.
WinMsiBundler.java: static
yes - $ROOTDIR now means what $APPDIR used to, and this method gets
$ROOTDIR/app/ , so getCfgAppDir() is still the right name.
/Andy
On 10/8/2019 3:23 PM, Philip Race wrote:
protected String getCfgAppDir() {
- return Path.of("$APPDIR").resolve(
- ApplicationLayout.linuxAppImage().appDire
Andy,
AbstractAppImageBuilder.java: is extra ` + File.separator` by intention?
WinMsiBundler.java: static cache will be a potential problem if jpackage
will be used as tool provider, i.e. in scenario when jpackage will be
called multiple times per jvm session.
- Alexey
On 10/8/2019 3:06 PM,
On 10/8/19 6:31 AM, Claes Redestad wrote:
Hi,
webrev.02 looks good to me.
webrev.02 looks fine to me as well.
I think the performance results makes sense since avoiding a volatile
store (and the potentially expensive store barriers this involves)
should be the main benefit. Adding a bran
protected String getCfgAppDir() {
-return Path.of("$APPDIR").resolve(
-ApplicationLayout.linuxAppImage().appDirectory()).toString() +
File.separator;
+return Path.of("$ROOTDIR").resolve(
+ApplicationLayout.linuxAppImage().appDirectory()).toStri
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 is to Expose the macro $APPDIR for use in --java-options
value, to rename macros to mean what they are called, and to eliminate
several un
On 10/8/2019 1:53 PM, Sverre Moe wrote:
tir. 8. okt. 2019 kl. 19:19 skrev Alexey Semenyuk
mailto:alexey.semen...@oracle.com>>:
On 10/8/2019 12:43 PM, Sverre Moe wrote:
> Some comments about the jpackage+1-49 update.
>
> 1) It has become a lot more verbose since jpackage+1-3
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 better as a follow-up, since there might exist
tir. 8. okt. 2019 kl. 19:19 skrev Alexey Semenyuk <
alexey.semen...@oracle.com>:
>
>
> On 10/8/2019 12:43 PM, Sverre Moe wrote:
> > Some comments about the jpackage+1-49 update.
> >
> > 1) It has become a lot more verbose since jpackage+1-35. Makes using the
> > verbose argument difficult to actua
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 :https://bugs.openjdk.j
On 10/8/2019 12:43 PM, Sverre Moe wrote:
Some comments about the jpackage+1-49 update.
1) It has become a lot more verbose since jpackage+1-35. Makes using the
verbose argument difficult to actually see relevant output, like the actual
rpmbuild/dpkg command output.
It seems to be running rpm
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?
Regards,
Ogata
Claes Redestad wrote on 2019/10/08 22:31:29:
> From: Claes Redestad
> To: Kazunori Ogata , cor
Some comments about the jpackage+1-49 update.
1) It has become a lot more verbose since jpackage+1-35. Makes using the
verbose argument difficult to actually see relevant output, like the actual
rpmbuild/dpkg command output.
It seems to be running rpmbuild --version twice
Running [rpmbuild --vers
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 :https://bugs.openjdk.java.net/browse/JDK-8231770
Webrev :https://cr.
Build changes look good.
/Erik
On 2019-10-08 08:27, Jan Lahoda wrote:
Thanks for the new code Erik!
A new webrev/patch that includes this better way of copying is here:
http://cr.openjdk.java.net/~jlahoda/8226585/webrev.01/
Any feedback is welcome!
Thanks,
Jan
On 03. 10. 19 18:06, Erik
Hi Roger,
Thank you for the review. In fact, Joe commented about the validity of
zero on the CSR, so I will need to modify the method description such as:
diff -r 9576895d0f9a
src/java.base/share/classes/java/text/DecimalFormat.java
--- a/src/java.base/share/classes/java/text/DecimalFormat.j
Thanks for the new code Erik!
A new webrev/patch that includes this better way of copying is here:
http://cr.openjdk.java.net/~jlahoda/8226585/webrev.01/
Any feedback is welcome!
Thanks,
Jan
On 03. 10. 19 18:06, Erik Joelsson wrote:
Hello Jan,
The build change looks ok, but I would recom
Hi Alan,
Removing jobjc will require changes to a bunch of files. If there's
support for it, I can do the work, but we should split it into a seperate
bug.
So the questions are:
1) Can I get a second opinion on the complete removal of everything jobjc
(in a seperate bug)?
2) What are peoples
Hi Naoto,
DecimalFormat.java: 2776: "Invalid value, i.e.," -> "Values that are".
Otherwise looks fine. No need for another webrev.
Thanks, Roger
On 10/4/19 6:54 PM, naoto.s...@oracle.com wrote:
Hello,
Please review the fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK
Hi,
webrev.02 looks good to me.
I think the performance results makes sense since avoiding a volatile
store (and the potentially expensive store barriers this involves)
should be the main benefit. Adding a branch to avoid storing null would
help partially, but not hot Methods.
Pre-existing issu
Hi all,
I posted two changes and got reply that performance evaluation is needed.
I found that making Method.methodAccessor non-volatile (webrev.02) is
better than avoid copying methodAccessor value when it is null
(webrev.01), as shown below.
So I'd like to ask review of the former change. I
On 07/10/2019 19:38, Claes Redestad wrote:
Hi,
please review this patch which removes unused methods and redundant
aliases from jni_util and friends in libjava.
There's one affected call site in the hotspot runtime code, otherwise
this is mainly a java.base-internal cleanup.
Bug: https://bu
33 matches
Mail list logo
