+1
-phil
On 8/14/20, 7:05 AM, Andy Herrick wrote:
Please review revised webrev [3] that does not check for client jvm
are (always use server)
/Andy
[3] - http://cr.openjdk.java.net/~herrick/8250611/webrev.02
On 8/13/2020 6:03 PM, Philip Race wrote:
Do I understand correctly that you
Do I understand correctly that you are checking if the client VM is
being specified ?
I didn't think we had client VMs any more ..
-phil.
On 8/13/20, 12:35 PM, Andy Herrick wrote:
Please review this jpackage fix for issue [1] at [2].
In order to show splash screen from statically linked
+1
-phil
On 7/13/20, 1:26 PM, Andy Herrick wrote:
please review trivial jpackage fix to issue [1] at [2]
[1] https://bugs.openjdk.java.net/browse/JDK-8248687
[2] http://cr.openjdk.java.net/~herrick/8248687/webrev.01/
/Andy
Kim,
Until it says in "the JDK" and not "in HotSpot" you have not addressed
my main point.
Please rename the JEP.
-phil.
On 6/13/20, 8:48 PM, Kim Barrett wrote:
On Jun 10, 2020, at 2:26 AM, Kim Barrett wrote:
On Jun 8, 2020, at 4:07 PM, Philip Race wrote
Hi Kim,
Can we amend the JEP itself to be not solely about hotspot.
Since it affects other areas I think that
1) They may need to be compiled with C++14 enabled whether they use new
features or not
2) They may want - or need - to adopt C++11 or C++14 features too.
You already know that soon
+1
-phil.
On 5/8/20, 4:34 PM, Andy Herrick wrote:
Revised webrev at [3] - this fixes the test problem that was caused by
the test assuming wix tools are on all systems.
/Andy
[3] - http://cr.openjdk.java.net/~herrick/8244620/webrev.02/
On 5/7/2020 4:23 PM, Andy Herrick wrote:
please
What's the failure look like ? I don't see it in the bug report.
-phil.
On 5/7/20, 1:23 PM, Andy Herrick wrote:
please review fix for issue [1] at [2].
/Andy
[1] - https://bugs.openjdk.java.net/browse/JDK-8244620
[2] - http://cr.openjdk.java.net/~herrick/8244620/webrev.01/
report as
well.
- Alexey
On 5/1/2020 6:21 PM, Philip Race wrote:
It may be self-evident but I really like to see a RFR include an
evaluation
and explanation of the fix and the same in the bug report.
Please do both.
-phil.
On 5/1/20, 1:00 PM, Alexey Semenyuk wrote:
Please review fix [2
It may be self-evident but I really like to see a RFR include an evaluation
and explanation of the fix and the same in the bug report.
Please do both.
-phil.
On 5/1/20, 1:00 PM, Alexey Semenyuk wrote:
Please review fix [2] for jpackage bug [1].
Fix vs2019 compliation error.
- Alexey
[1]
Hi,
I don't understand what you are doing here.
It is like you are copying around an application
which has dependent libraries but not copying those libraries.
Copying bits out of the JDK to some other location isn't something you
can expect to work.
And why does your application need
+1
-phil.
On 1/29/20, 10:34 AM, Andy Herrick wrote:
Please review trivial jpackage fix to [1] at [2]
[1] https://bugs.openjdk.java.net/browse/JDK-8238168
[2] http://cr.openjdk.java.net/~herrick/8238168/webrev.01/
/Andy
That didn't answer all my questions, at least not in a way that I can
understand.
How is this useful given that we disable jtreg failure handlers for the
headful tests ?
-phil.
On 12/30/19, 11:33 AM, Sergey Bylokhov wrote:
On 12/23/19 9:15 pm, Phil Race wrote:
I am not sure what the right
Have you verified this with VS 2017 ?
Not that I can see a problem but I doubt we want to trade breaking 2017
to fix 2013 ...
-phil.
On 12/23/19, 3:52 PM, Alex Kashchenko wrote:
Hi,
Please review this minor change to jpackage, that is required for
successful compilation with VS2013
Code looks fine, I did not run the tests, but +1 assuming this has been run
through a mach5 test job already. If not please submit one first.
-phil.
On 12/18/19, 6:38 AM, Andy Herrick wrote:
Code looks good - ran tests locally and all passed.
/Andyu
On 12/17/2019 8:31 PM, Alexey Semenyuk
+1
Please add an appropriate noreg-* label to the bug.
-phil
On 12/16/19, 8:29 AM, Alexey Semenyuk wrote:
Looks good.
- Alexey
On 12/16/2019 10:32 AM, Andy Herrick wrote:
Please review this jpackage fix to [1] at [2]
the change just adds quotes around the Argument element's value in
WIX
+1
-phil.
On 12/9/19, 5:26 PM, Andy Herrick wrote:
On 12/9/2019 6:53 PM, Phil Race wrote:
> [2] http://cr.openjdk.java.net/~herrick/8235601/webrev.01/
This does not bring up the expected webrev
My apologies - I uploaded the wrong webrev - It should be fixed now.
/Andy
-phil.
On
+1
-phil
On 12/9/19, 6:33 AM, Andy Herrick wrote:
Please review this revised fix at [3].
This fix only adds "@modules jdk.incubator.jpackage" to junit.jar.
[3] http://cr.openjdk.java.net/~herrick/8235453/webrev.02/ /Andy
On 12/6/2019 1:33 PM, Andy Herrick wrote:
Please review this
Yes, since only a (relatively) small number of tests needed to be updated
this is fine with me at least for now. So +1
-phil.
On 12/7/19, 5:48 AM, Andy Herrick wrote:
Phil - are you approving this change ? - I think you are the only
registered Reviewer.
/Andy
On 12/6/2019 8:11 PM, Phil Race
I don't understand the relationship between these two bugs.
-phil
On 12/5/19, 2:47 PM, Alexey Semenyuk wrote:
Please review fixes for [1] and [2]. Both target jpackage tool.
The webrev is at [3].
[1] https://bugs.openjdk.java.net/browse/JDK-8233270
[2]
+1 (Approved).
I think we are now just waiting on the CSR to be approved :
https://bugs.openjdk.java.net/browse/JDK-8213087
-phil.
On 12/3/19, 12:31 PM, Kevin Rushforth wrote:
Updated version (with the one change mentioned in reply to Phil) looks
good.
+1
-- Kevin
On 12/3/2019 11:35 AM,
> I believe otherwise it is an accurate incremental webrev of the
jpackage changes since EA-5.
It is also not very incremental.
*
*src/jdk.incubator.jpackage/share/classes/jdk/incubator/jpackage/main/Main.java
is definitely not "new" ...
-phil.
On 11/26/19, 2:17 PM, Andy Herrick wrote:
yes,
I noticed this problem when creating various demo scenarios so +1 to the
change, but
+\ Pass on --bind-seervices option to jlink (which will link in \n\
typo here
-phil
On 11/5/19, 3:36 PM, Andy Herrick wrote:
Please review the jpackage fix for bug [1] at [2].
This is a fix for
protected String getCfgAppDir() {
-return Path.of("$APPDIR").resolve(
-ApplicationLayout.linuxAppImage().appDirectory()).toString() +
File.separator;
+return Path.of("$ROOTDIR").resolve(
+
+// Get indetifier from app image if user
provided app image and
+// does not provided identifier via CLI.
+String indentifier =
extractBundleIdentifier(params);
+if (indentifier != null) {
+
2
Date: Wed, 18 Sep 2019 23:44:19 +0200
From: Sverre Moe
To: Philip Race
Cc: core-libs-dev@openjdk.java.net
Subject: Re: Comments on jpackage (JEP 343)
Message-ID:
qakvdetirxlfcny0cvh4poezg...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
It is actually the javaf
dump
a bunch of unfamiliar files.
-phil.
On 9/16/19, 8:13 PM, Philip Race wrote:
I've been thinking about this.
output is nicely symmetrical with input and in the case of a default
app-image it is more than a single item
and personally I'd much rather it not clutter my working directory and
again you
I've been thinking about this.
output is nicely symmetrical with input and in the case of a default
app-image it is more than a single item
and personally I'd much rather it not clutter my working directory and
again you get symmetry with input
which you really want to specify but I'd concede
Please see https://bugs.openjdk.java.net/browse/JDK-8211182
IIRC there were also concerns that jpackage was not the right place to
be defining this,
and also I think Andy wrote some boiler plate code that demonstrated it
was not needed
for at least some of these use cases. Andy (?)
So not
Hi,
Regarding all the touches on the desktop module
1) awt-dev isn't the only list, you should have included swing-dev and
2d-dev at least
2) I am wondering what client testing you propose to do to verify this ?
3) I've spent spare time over a number of months trying to decrease
unnecessary
On 5/23/19, 4:10 PM, Brent Christian wrote:
Looks fine. I guess you'll want to update/add the Copyright year in
JDKSecurityProperties.java.
Why ? What are you copyrighting ? There is nothing being added or
modified, only a line deleted.
Copyright is held in created content, not the act
On 5/7/19, 7:47 PM, Sergey Bylokhov wrote:
Hi, Phil.
Looks fine, but probably it will be worth to rename
PlatformGraphicsInfo to PlatformInfo?
I don't want (or intend) to do that. I already knew I was going
to re-use this class for this purpose when I created it and adjusted
the classname
On 5/6/19, 3:11 PM, Phil Race wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8212700
CSR: https://bugs.openjdk.java.net/browse/JDK-8223417
Webrev: https://cr.openjdk.java.net/~prr/8212700
Please review this bug + CSR to remove the awt.headless system property.
That would be
Adding build-dev for the build changes. I don't know if these were
previously reviewed there,
but I am not sure what the changes in NativeCompilation.gmk have to do
with jpackage.
-phil.
On 4/24/19, 5:47 PM, Andy Herrick wrote:
On 4/24/2019 8:44 PM, Andy Herrick wrote:
Please review
Sorry, meant to include core-libs on this !
-phil.
On 4/25/19, 1:12 PM, Phil Race wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8130266
CSR: https://bugs.openjdk.java.net/browse/JDK-
Webrev: http://cr.openjdk.java.net/~prr/8130266/
Please review this fix + the CSR which eliminates the
And the complete CSR link is this :
https://bugs.openjdk.java.net/browse/JDK-8222990
On 4/25/19, 1:31 PM, Philip Race wrote:
Sorry, meant to include core-libs on this !
-phil.
On 4/25/19, 1:12 PM, Phil Race wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8130266
CSR: https
JDK 11 runs on older versions.
I don't see where that message would come from in the jpackage code but
I could just be missing it.
It may be more to do with you having run jpackage on 10.13 and the
question is can it target an earlier version of MacOS than the one on
which the .pkg is created ?
awt-dev.
But try including the exact jdk version + a test case when you do
since I am not sure that exact issue has been seen.
Problems with needing to allow accessibility is the mojave specific
issue I can recall.
-phil.
On 4/3/19, 10:56 PM, David Holmes wrote:
Hi Kusti,
The folks on
Wrong list. You want 2d-dev.
-phil.
On 2/27/19, 3:26 PM, Bernd Eckenfels wrote:
Hello,
(please let me know in case I picked the wrong list.)
Since OpenJDK does not ship Default *.ttf font files the change that a JRE is
installed in a way that no System Fonts can be found is quite high.
In
Here is an update with a Java-only test, using ProcessBuilder.
http://cr.openjdk.java.net/~prr/8212703.1/index.html
-phil.
On 12/1/18, 9:27 AM, Alan Bateman wrote:
On 30/11/2018 23:11, Roger Riggs wrote:
Hi Phil,
That looks fine.
Too bad it introduces a new shell test, we're trying to get
On 11/13/18, 12:52 PM, Roger Riggs wrote:
Hi,
There are enough files unique to each platform to put them in separate
packages
otherwise you get too many (IMHO) files in a single package/directory and
its harder to tell which go with which. There isn't much of a problem
with
classes
rrent process"
There may be more like that.
and as I mentioned offline, I think the correct word is "deregister" not
"unregister"
both in comments and method names.
-phill
On 11/12/18, 2:38 PM, Andy Herrick wrote:
On 11/12/2018 4:54 PM, Philip Race wrote:
On 11/12/
On 11/12/18, 1:45 PM, Andy Herrick wrote:
On 11/12/2018 3:22 PM, Philip Race wrote:
Adding build-dev back ..
I noticed that module jdk.jpackager.runtime requires java.desktop on
all platforms
So far as I can tell this is for a Mac-only support for receiving and
handling file open events
nt storage location then default to the "unix"
location if there's no match .. although I am not sure it makes sense
on platforms that aren't targeted by jpackager.
-phil.
-phil.
On 11/12/18, 12:22 PM, Philip Race wrote:
Adding build-dev back ..
I noticed that module jdk.jpackager.runtime r
where the parameter list of the new
* activation in conflict with the existing activation
-phil.
On 11/12/18, 12:22 PM, Philip Race wrote:
Adding build-dev back ..
I noticed that module jdk.jpackager.runtime requires java.desktop on
all platforms
So far as I can tell
Adding build-dev back ..
I noticed that module jdk.jpackager.runtime requires java.desktop on all
platforms
So far as I can tell this is for a Mac-only support for receiving and
handling file open events. Probably it only makes sense or gets used
when the API is used from a running desktop
Wrong list. Try over on sound-dev,
-phil.
On 10/9/18, 4:17 PM, Kim Barrett wrote:
[I'm not sure whether core-libs is the right list for java.desktop changes.]
Please review this trivial fix of a build failure on MacOSX when
compiling with C++11/14 enabled. An int value is being used in an
On 9/21/18 1:13 PM, Philip Race wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8211031
webrev: http://cr.openjdk.java.net/~prr/8211031/
Removing some obsolete code which is the reason for a qualified export
from java.base to java.desktop. I also cleaned up some commented out
debugging code
Bug: https://bugs.openjdk.java.net/browse/JDK-8211031
webrev: http://cr.openjdk.java.net/~prr/8211031/
Removing some obsolete code which is the reason for a qualified export
from java.base to java.desktop. I also cleaned up some commented out
debugging code.
See the bug evaluation for more
It was exported in the past .. and it was publicly documented ..
http://www.oracle.com/technetwork/articles/javase/appletwarning-135102.html
.. so I think Sergey was correct in his "JDK" scope.
Implementation would be for something entirely internal.
+1
-phil.
On 9/13/18, 7:20 PM, mandy
Were people mis-reading this as java.desktop ?
Yes, its fine, this was added under
https://bugs.openjdk.java.net/browse/JDK-8055206
and we should have removed that when jdk.desktop was backed out
under https://bugs.openjdk.java.net/browse/JDK-8173409
-phil.
On 9/14/18, 11:41 AM, Sean Mullan
Some day, I'd like to replace a lot of medialib functionality with something
like the proposed Vector API. But that is far enough away that medialib
needs
to be maintained, and unlike a previous discussion about a similar issue in
the JPEG library, we are on the hook for maintaining medialib.
font change .. and all the rest look fine to me.
-phil.
On 7/13/18, 8:40 AM, Lindenmaier, Goetz wrote:
Hi Roger,
Thanks for looking at this!
Since the assignment is done in both branches of the if, it could be
moved up.
You're right, that's better. Done.
Best regards,
Goetz.
The DnD & clipboard cases on such a desktop are the only possible use I
can think of
for this charset, so if it were to exist anywhere it would be in the
desktop module,
since it depends on all the X decoders that were moved there.
But since MToolkit is gone so we don't have direct need for it.
Ok by me too ... it would not have crossed my mind to look at ProcessBuilder
but I suppose it was trying to support the now deleted behaviours.
-phil.
On 7/27/17, 6:29 AM, Alan Bateman wrote:
On 26/07/2017 22:20, Martin Buchholz wrote:
1. JDK-8185365
On 3/12/17, 3:07 AM, Andrew Haley wrote:
I guess "difficulty in properly triggering GC for non-memory resource
exhaustion" is closest to what I just described.
This has long been an issue in the Java client area where native desktop
resources or the like need to be managed carefully, but it
Alan,
See the comment here :
http://mail.openjdk.java.net/pipermail/awt-dev/2016-June/011478.html
Probably you should chime in directly on that discussion with such input ..
-phil.
On 6/13/16, 12:47 PM, Alan Bateman wrote:
On 13/06/2016 20:26, Philip Race wrote:
PS .. also you probably
PS .. also you probably should just suppress lint on the jdk.jsobject
module
The change you propose to JSObject is going to cause a potential conflict
with the ongoing review discussion about this here :-
http://mail.openjdk.java.net/pipermail/awt-dev/2016-June/011472.html
-phil.
On
Changeset: 8b4309cbd999
Author:prr
Date: 2012-03-05 09:33 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8b4309cbd999
7078053: Solaris JDK build: C compiler writing tmp files into the make tree
Reviewed-by: ohair, alanb
! make/java/nio/Makefile
! make/sun/xawt/Makefile
58 matches
Mail list logo
