Hello, please review this small fix for the windows 32bit build .
Currently we run into this compile error on Windows :
./src/jdk.incubator.jpackage/windows/native/libjpackage/VersionInfo.cpp(123):
error C2220: warning treated as error - no 'object' file generated
./src/jdk.incubator.jpackage
Thanks Andy.
I moved all the icons from input folder to a separate folder and that did
the trick (if it helps someone)
In all, I am able to create and set icons for both windows and Mac.
Thank you!
--
Sent from: http://openjdk.5641.n7.nabble.com/OpenJDK-Core-Libraries-f45829.html
Thanks Andy;
Re done, after 'saw your comment; Windows worked with .ico (had to redo the
png to ico -format corruption)
Any ideas for the Mac? Thanks in advance.
--
Sent from: http://openjdk.5641.n7.nabble.com/OpenJDK-Core-Libraries-f45829.html
Hi Calvin, this looks good to me, too.
Thanks
- Ioi
On 4/27/20 12:21 PM, Calvin Cheung wrote:
JBS: https://bugs.openjdk.java.net/browse/JDK-8241815
webrev: http://cr.openjdk.java.net/~ccheung/jdk15/8241815/webrev.00/
This change is to avoid java up call of definePackage() while loading
a shar
Hi Tagir,
A few quick thoughts on this.
There does seem to be a conceptual hole here. Most collections implementations
have an obvious interface that provides a reasonable abstraction of that
implementation. However, one is "missing" for LinkedHashSet, since there's no
interface more speciali
On 28/04/2020 10:01 am, David Holmes wrote:
On 28/04/2020 9:37 am, Ioi Lam wrote:
Hi David & Jiangli,
Thanks for your comments.
I thought about using a system property, but the user can also specify
it like
java -Djdk.xshare.dump.salt=0 MyProgram
There's a way to pass properties from
Hi Thomas,
Thanks for looking into this in detail.
Actually the problem is not as bad as you think (I hope ). First of
all, this patch is intended for -Xshare:dump only (aka static CDS
archive). Dynamic CDS archive (-XX:ArchiveClassesAtExit) is much harder
to make deterministic because of
On 28/04/2020 9:37 am, Ioi Lam wrote:
Hi David & Jiangli,
Thanks for your comments.
I thought about using a system property, but the user can also specify
it like
java -Djdk.xshare.dump.salt=0 MyProgram
There's a way to pass properties from the VM that the user can't
override. I'll n
Hi David & Jiangli,
Thanks for your comments.
I thought about using a system property, but the user can also specify
it like
java -Djdk.xshare.dump.salt=0 MyProgram
This would circumvent the calculation of ImmutableCollections.SALT32L
for normal execution. I am not sure if this is desir
Hi Lois,
Thanks for your review!
Calvin
On 4/27/20 3:22 PM, Lois Foltan wrote:
Looks good Calvin.
Lois
On 4/27/2020 3:21 PM, Calvin Cheung wrote:
JBS: https://bugs.openjdk.java.net/browse/JDK-8241815
webrev: http://cr.openjdk.java.net/~ccheung/jdk15/8241815/webrev.00/
This change is to avoi
On 4/27/20 2:42 PM, Remi Forax wrote:
Hi Maurizio, Mandy,
In
https://cr.openjdk.java.net/~mcimadamore/8243491_v2/webrev/src/java.base/share/classes/java/lang/invoke/MemoryAccessVarHandleGenerator.java.udiff.html,
using a condy inside a static init make me sad,
using a late loading constant t
Looks good Calvin.
Lois
On 4/27/2020 3:21 PM, Calvin Cheung wrote:
JBS: https://bugs.openjdk.java.net/browse/JDK-8241815
webrev: http://cr.openjdk.java.net/~ccheung/jdk15/8241815/webrev.00/
This change is to avoid java up call of definePackage() while loading
a shared app/platform class origin
Hi Mandy,
Thanks for your review!
Calvin
On 4/27/20 2:39 PM, Mandy Chung wrote:
On 4/27/20 12:21 PM, Calvin Cheung wrote:
JBS: https://bugs.openjdk.java.net/browse/JDK-8241815
webrev: http://cr.openjdk.java.net/~ccheung/jdk15/8241815/webrev.00/
This change is to avoid java up call of define
I do, however, see two problems.
1.) If the --icon option value points to a non-existent file - jpackage
will use the default icon without any warning, even if --verbose is used.
2.) If a dmg is created with a non default icns file (at least some, may
be size dependent) , the Applications fol
Hi Maurizio, Mandy,
In
https://cr.openjdk.java.net/~mcimadamore/8243491_v2/webrev/src/java.base/share/classes/java/lang/invoke/MemoryAccessVarHandleGenerator.java.udiff.html,
using a condy inside a static init make me sad,
using a late loading constant to early load it in the static init seems co
On 4/27/20 3:41 PM, Andy Herrick wrote:
I can see this problem on Mac using .icns file, but I don't see any
similar problem on windows, using .ico format.
my mistake - was testing the wrong app (one without --icon option)
I cannot reproduce this even on Mac - can you show your complete
jpa
On 4/27/20 12:21 PM, Calvin Cheung wrote:
JBS: https://bugs.openjdk.java.net/browse/JDK-8241815
webrev: http://cr.openjdk.java.net/~ccheung/jdk15/8241815/webrev.00/
This change is to avoid java up call of definePackage() while loading
a shared app/platform class originated from the module ima
Looks OK to me. Thanks for the update.
Naoto
On 4/27/20 11:19 AM, Kiran Ravikumar wrote:
Hi Martin and Andrew,
Thanks for the review and providing a direction towards updating the
translations.
Here is an updated webrev with the changes:
http://cr.openjdk.java.net/~kravikumar/8243541/web
I can see this problem on Mac using .icns file, but I don't see any
similar problem on windows, using .ico format.
/Andy
On 4/27/2020 3:03 PM, jjk wrote:
Tried various forms of
--icon Iconfile.icns
--resource-folder folder_name
etc, but 'am still getting default images for dmg and app (java s
JBS: https://bugs.openjdk.java.net/browse/JDK-8241815
webrev: http://cr.openjdk.java.net/~ccheung/jdk15/8241815/webrev.00/
This change is to avoid java up call of definePackage() while loading a
shared app/platform class originated from the module image since the
packages from module image are
Tried various forms of
--icon Iconfile.icns
--resource-folder folder_name
etc, but 'am still getting default images for dmg and app (java snowman)
and same for windows version jdk.
What is the right way to change this behavior of jpackage (tried both open
jdk-15 EA and Jdk-14.1)
Thanks in
Thanks. This looks good.
How the tzdata updates get done has always been a mystery to me.
If you've written any helper scripts or process docs, checking those
in as well (but which directory?) might be useful.
(I maintain such things at Google, but they are not very useful for
you - too full of G
Hi Martin and Andrew,
Thanks for the review and providing a direction towards updating the
translations.
Here is an updated webrev with the changes:
http://cr.openjdk.java.net/~kravikumar/8243541/webrev/
All associated tests pass. Please let me know if they look alright.
Thanks,
Kiran
+1.
Indeed, the resulting javadoc was fine :-)
Best,
Joe
On 4/27/2020 9:36 AM, naoto.s...@oracle.com wrote:
Hello,
Please review this small doc fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8243664
Here is the diff:
---
--- old/src/java.base/share/classes/java/tex
+1
On 4/27/20 12:36 PM, naoto.s...@oracle.com wrote:
Hello,
Please review this small doc fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8243664
Here is the diff:
---
--- old/src/java.base/share/classes/java/text/CompactNumberFormat.java
2020-04-27 09:09:14.0 -
On 27/04/2020 12:13, Kiran Ravikumar wrote:
> Hello All,
>
>
> Please review the patch for tzdata2020a integration into jdk.
>
> Release details can be found here:
>
> http://mm.icann.org/pipermail/tz-announce/2020-April/58.html
>
>
> Webrev: http://cr.openjdk.java.net/~kravikumar/8243
Hello,
Please review this small doc fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8243664
Here is the diff:
---
--- old/src/java.base/share/classes/java/text/CompactNumberFormat.java
2020-04-27 09:09:14.0 -0700
+++ new/src/java.base/share/classes/java/text/Compa
On 2020-04-27 17:16, Lance Andersen wrote:
Hi Claes,
The changes and the performance bump all look good and with the minor
change below helps the readability.
Thanks! Pushed.
/Claes
Thank you for using your performance expertise to improve this area.
Best
Lance
On Apr 27, 2020, at 6:11
Hi Claes,
The changes and the performance bump all look good and with the minor change
below helps the readability.
Thank you for using your performance expertise to improve this area.
Best
Lance
> On Apr 27, 2020, at 6:11 AM, Claes Redestad wrote:
>
>
>
> On 2020-04-27 11:49, Volker Simon
Hi Kiran,
Thanks for working on this update so promptly.
The innocent renaming of America/Godthab to America/Nuuk is causing much
trouble.
Since it's a renaming, both names remain and I expected them to have the
same metadata.
So I expected the entries in TimeZoneNames.java and the translations i
Another iteration, which addresses the following issues:
* wrong copyright headers in certain tests
* issue with TestNative when running in debug mode caused by mismatched
malloc/os::free (contributed by Jorn)
* clarify javadoc of MemoryHandles::withStride
* improved implementation of MemoryAcc
Hello All,
Please review the patch for tzdata2020a integration into jdk.
Release details can be found here:
http://mm.icann.org/pipermail/tz-announce/2020-April/58.html
Webrev: http://cr.openjdk.java.net/~kravikumar/8243541/webrev.00/
Bug: https://bugs.openjdk.java.net/browse/JDK-824354
Thank you, Sundar.
On Mon, Apr 27, 2020 at 6:49 PM wrote:
>
> Hi,
>
> Looks good. I'll sponsor this fix.
>
> Thanks
>
> -Sundar
>
> On 27/04/20 4:15 pm, Ao Qi wrote:
> > Thanks, Sundar!
> >
> > I updated a new webrev (patch is the same, only hg commit info was
> > added): http://cr.openjdk.java.n
Hi,
Looks good. I'll sponsor this fix.
Thanks
-Sundar
On 27/04/20 4:15 pm, Ao Qi wrote:
Thanks, Sundar!
I updated a new webrev (patch is the same, only hg commit info was
added): http://cr.openjdk.java.net/~aoqi/8242846/webrev.02/
Could someone help to sponsor this?
Thanks,
Ao Qi
On Mon,
Thanks, Sundar!
I updated a new webrev (patch is the same, only hg commit info was
added): http://cr.openjdk.java.net/~aoqi/8242846/webrev.02/
Could someone help to sponsor this?
Thanks,
Ao Qi
On Mon, Apr 27, 2020 at 4:52 PM wrote:
>
> Looks good
>
> -Sundar
>
> On 27/04/20 12:24 pm, Ao Qi wro
On 2020-04-27 11:49, Volker Simonis wrote:
On Sun, Apr 26, 2020 at 11:34 PM Claes Redestad
wrote:
Hi again,
On 2020-04-24 21:22, Claes Redestad wrote:
It seems that 'getEntryHitUncached' is getting slightly slower with
your change while all the other variants get significantly faster. I
d
On Sun, Apr 26, 2020 at 11:34 PM Claes Redestad
wrote:
>
> Hi again,
>
> On 2020-04-24 21:22, Claes Redestad wrote:
> >> It seems that 'getEntryHitUncached' is getting slightly slower with
> >> your change while all the other variants get significantly faster. I
> >> don't think that's a problem,
Rethinking this a bit more I realize you need not addresses growing
monotonously but deterministic allocation: given a sequence of Metaspace
allocation operations (Metaspace::allocate(), Metaspace::deallocate(), and
collection of class loaders), the pointers returned
by Metaspace::allocate() should
Looks good
-Sundar
On 27/04/20 12:24 pm, Ao Qi wrote:
On Sun, Apr 26, 2020 at 12:00 AM Alan Bateman wrote:
On 21/04/2020 04:58, Ao Qi wrote:
On 2020/4/20 下午9:27, Alan Bateman wrote:
On 20/04/2020 11:32, sundararajan.athijegannat...@oracle.com wrote:
Hi Alan,
I don't remember it now. Likel
Hi Ioi,
On 2020-04-27 07:22, Ioi Lam wrote:
https://bugs.openjdk.java.net/browse/JDK-8241071
http://cr.openjdk.java.net/~iklam/jdk15/8241071-deterministic-cds-archive.v02/
I can't really comment on the code changes, but I'd like to thank you
for the effort of getting a deterministic classes.j
On Mon, Apr 27, 2020 at 8:23 AM David Holmes
wrote:
> Hi Ioi,
>
> On 27/04/2020 3:22 pm, Ioi Lam wrote:
> > https://bugs.openjdk.java.net/browse/JDK-8241071
> >
> http://cr.openjdk.java.net/~iklam/jdk15/8241071-deterministic-cds-archive.v02/
> >
> >
> > The goal is to for "java -Xshare:dump" to p
Hi Ioi,
Please don't do this :)
First off, how would this work when dumping with UseCompressedClassPointers
off? In that case allocation would be relegated to non-class metaspace
which cannot guarantee that kind of address stability.
Even in class space, I do not think you can guarantee addresse
Hi Alan,
Thank you for the review. May I ask your help for sponsoring this fix?
Best Regards,
Toshio Nakamura
Alan Bateman wrote on 2020/04/24 17:50:39:
> On 24/04/2020 09:33, Toshio 5 Nakamura wrote:
> > Hi all,
> >
> > Please review this fix.
> > Also, I'd like to ask a sponsor of the fix,
43 matches
Mail list logo
