Hi Brent,
$ make test TEST="micro:java.lang.StackWalkBench"
It took very long that I killed the job. Does this happen to you?
Mandy
On 9/13/19 3:07 PM, Brent Christian wrote:
Hi,
Please review these StackWalker and Throwable benchmarks for addition
into the JDK microbenchmarks.
Bug:
Hi, Julia
I found one more empty .diff:
http://cr.openjdk.java.net/~jboes/webrevs/8231186/webrev.02/src/java.base/share/classes/java/util/regex/Matcher.java.sdiff.html
In the .patch file, I see that there are changes to:
ResourceBundle.java, Calendar.java, and SecurityManager.java
so it
Hi Michael,
If you specified --temp to jpackage it will contain config folder with
background image and script we running to arrange icons in DMG, so you
can convert created DMG to be writable, re-run script and convert it
back to read-only.
Currently no plans to add CLI to provide
If you don't use audio or video, you will probably not need it.
Have a look here: https://ffmpeg.org/
Message: 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:
Hi Alexey,
Looks good.
Thanks,
Alexander
On 9/18/2019 8:23 AM, Alexey Semenyuk 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 fix:
- Move common deb and rpm packaging code in the
On Wed, Sep 18, 2019 at 10:32 PM Aleksey Shipilev wrote:
> On 9/18/19 10:23 PM, Evgeny Mandrikov wrote:
> > So AFAIU from the above wiki page - first 8142543 should be closed as
> dup of 8073347,
>
> For this case, I would comment in JDK-8142543 that JDK-8073347 fixes the
> same thing, without
It seems many of the RPM Requires comes from me adding the JavaFX jmods to
the application image.
--add-modules javafx.base javafx.controls javafx.graphics javafx.fxml
javafx.media javafx.web javafx.swing
Without the JavaFX jmods added to runtime image I get only these Requires.
Hi,
that explains it. I just wanted to make sure that you do not see any
scrollbars in the normal case.
Will it be possible to provide your own image to be used by the
packager? Some people like
to do some branding here.
Michael
Am 18.09.19 um 23:14 schrieb Alexander Matveev:
Hi Michael,
I
Hi Michael,
I did screenshot with show hidden files enabled in Finder (Shift +
Command + .). We have hidden files with background image, icon in DMG
moved away, so if show hidden files enabled you will see scrollbars and
can scroll to hidden files, if it is disabled then no scrollbars are
It is actually the javafx-web module that requires these.
Anyone know what part of the Web module that needs the libavcodec and
libavcoded-ffmpeg?
We are using a small part of the web module, just WebView for Tooltip with
HTML. No Video or Audio.
/Sverre
ons. 18. sep. 2019 kl. 23:30 skrev
Hello,
As background, I'm working on a number of serialization-related
compile-time checks with the goal of enabling stricter javac lint
checking in the JDK build (and elsewhere).
One check is tracked by
JDK-8160675: Issue lint warning for non-serializable non-transient
instance fields
Where does the Requires for libavcodec-ffmpeg and libavcodec.so come from?
Is it javafx-media which requires these.
The first one of these two requires I cannot find an RPM package for on
www.rpmfind.net.
Actually we are not using the javafx-media in our application. I could
remove that jmods,
On 9/18/19 10:23 PM, Evgeny Mandrikov wrote:
> So AFAIU from the above wiki page - first 8142543 should be closed as dup of
> 8073347,
For this case, I would comment in JDK-8142543 that JDK-8073347 fixes the same
thing, without closing
as dup yet. Then finish the backport, then maybe close as
On Wed, Sep 18, 2019 at 9:38 PM Aleksey Shipilev wrote:
> On 9/18/19 9:29 PM, Evgeny Mandrikov wrote:
> > Hello,
> >
> > Please review this 8u backport [1] of JDK-8073347 [2] that resolves
> > JDK-8142543 [3].
>
> Wait, that's not how it works, sorry. Please read this:
>
On 9/18/19 9:29 PM, Evgeny Mandrikov wrote:
> Hello,
>
> Please review this 8u backport [1] of JDK-8073347 [2] that resolves
> JDK-8142543 [3].
Wait, that's not how it works, sorry. Please read this:
https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix
Since you are
Hello,
Please review this 8u backport [1] of JDK-8073347 [2] that resolves
JDK-8142543 [3].
With best regards,
Evgeny
[1] http://cr.openjdk.java.net/~godin/8142543/webrev.00/
[2] https://bugs.openjdk.java.net/browse/JDK-8073347
[3] https://bugs.openjdk.java.net/browse/JDK-8142543
I recall thinking that many of the should actually be changed
to @link since use of suggested ancient times before @link became
available.
But "Perfect is the enemy of good".
/**
- * A BufferedInputStream adds
+ * A {@code BufferedInputStream} adds
* functionality to another input
Thanks.
Years ago I did this same cleanup on a subset of java.base that I
maintained.
I expected occurrences of '' would need changes as well, but it appears
there aren't any in java.base (some previous effort cleaned this up, I
guess).
I wrote this emacs command to help me:
(defun tt-code ()
FWIW, I also noticed this for
http://cr.openjdk.java.net/~jboes/webrevs/8231186/webrev.02/src/java.base/share/classes/java/lang/SecurityManager.java.sdiff.html
-B
On 9/18/19 11:32 AM, naoto.s...@oracle.com wrote:
Hi Julia,
This is not a comment to changes you've made, but the webrev seems
Thanks, Mandy!
/Claes
Mandy Chung skrev: (18 september 2019 11:09:25
GMT-07:00)
>Looks fine to me.
>
>Mandy
>
>On 9/18/19 11:05 AM, Claes Redestad wrote:
>> Hi,
>>
>> please review this patch to remove @Stable from two arrays in
>> MethodTypeForm. These were marked as @Stable in an earlier
>>
Hi Julia,
This is not a comment to changes you've made, but the webrev seems
missing some diffs, e.g.,
http://cr.openjdk.java.net/~jboes/webrevs/8231186/webrev.02/src/java.base/share/classes/java/util/Calendar.java.sdiff.html
> On Sep 18, 2019, at 11:05 AM, Severin Gehwolf wrote:
>
> On Wed, 2019-09-18 at 10:15 -0700, Bob Vandette wrote:
>> These internal methods were implemented in order to expose container metrics
>> to
>> via a public API. I’ve filed JDK-8203359 and JDK-8199944 to add an MBean
>> and JFR
Looks fine to me.
Mandy
On 9/18/19 11:05 AM, Claes Redestad wrote:
Hi,
please review this patch to remove @Stable from two arrays in
MethodTypeForm. These were marked as @Stable in an earlier
incarnation of the code when the contents was not SoftReference,
but @Stable does not make sense for
On Wed, 2019-09-18 at 10:15 -0700, Bob Vandette wrote:
> These internal methods were implemented in order to expose container metrics
> to
> via a public API. I’ve filed JDK-8203359 and JDK-8199944 to add an MBean
> and JFR events that will expose these values.
>
> JDK-8203359: Java Flight
It appears that many of the metrics we make available are in cgroupv2 although
they
are located in different files. The TCP memory allocations many not be split
out. In the
case of V2 you could just return the not available error return or we could
talk about
removing this metric.
Hi,
please review this patch to remove @Stable from two arrays in
MethodTypeForm. These were marked as @Stable in an earlier
incarnation of the code when the contents was not SoftReference,
but @Stable does not make sense for SoftReferences and might even
be detrimental.
I also did some
Hi Naoto and Martin,
Thank you very much for your reviews.
Hi Martin,
Naoto is correct, the jdk build will fail for the update releases when using
vanguard format, since the fix from JDK-8212970 is not yet backported.
Since, jdk14 has this fix, my current patch uses vanguard format tzdata.
I am
These internal methods were implemented in order to expose container metrics to
via a public API. I’ve filed JDK-8203359 and JDK-8199944 to add an MBean
and JFR events that will expose these values.
JDK-8203359: Java Flight Recorder (JFR) improvements for containers
JDK-8199944: Add
Looks ok to me!
/Claes
On 2019-09-18 12:01, Langer, Christoph wrote:
Hi,
please review the backport for JDK-8229773: Resolve permissions for code source
URLs lazily to OpenJDK11 updates.
Bug: https://bugs.openjdk.java.net/browse/JDK-8229773
Webrev:
Hi Bob,
As you probably know, I'm looking at cgroups v2 support[0] in OpenJDK.
When looking at Metrics.java[1] I see that many methods aren't used
anywhere. Neither in tests nor in actual code. It looks like as if the
interface has been modelled along the lines of the cgroups v1
implementation.
Hi,
This change replaces the HTML code tag with the equivalent javadoc tag
in the java.base module as such:
foo becomes {@code foo}
Ignored are any code tags that enclose other HTML or javadoc tags or
that contain HTML entities, e.g. character codes.
Examples (after change):
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 fix:
- Move common deb and rpm packaging code in the new class
(jdk.jpackage.internal.LinuxPackageBundler).
- Implement Java runtime packaging
Hi Daniel,
That sounds good, thank you. The copyright year update is made. Please
note that there are a few cases where the whitespace after the @throws
tag is less than three to align it with its neighboring tags, e.g.
BufferedOutputStream line 65.
Changeset:
Hi Hamlin,
Sorry for the protracted delay.
This looks ok.
Roger
On 9/4/19 3:16 AM, Hamlin Li wrote:
Would you please review the following patch?
bug: https://bugs.openjdk.java.net/browse/JDK-8209824
webrev: http://cr.openjdk.java.net/~mli/8209824/webrev.00/
Thank you
-Hamlin
Yes - looks good.
/Andy
On 9/18/19 9:00 AM, Alexey Semenyuk wrote:
Looks good.
- Alexey
On 9/17/2019 10:42 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).
- Added
Hi Pavel
Sure. Here is the incremental change:
http://cr.openjdk.java.net/~mmimica/8228580/webrev.03/
What actually bothers me from the beginning is the truncated response.
The TXT attribute, a String, prints "A very popular h", but does not
equals("A very popular h"), because of some stray
Looks good.
- Alexey
On 9/17/2019 10:42 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).
- Added link to "/Application" folder to DMG for drag and drop app to
this
Hi Julia,
I will be sponsoring this change, since you got a positive review
from both Lance and Pavel I believe we can now push it.
Can you prepare a changeset that can be hg-imported, including
the copyright year updates that were asked for? I'll try to push
it later today - unless there's any
Hi,
please review the backport for JDK-8229773: Resolve permissions for code source
URLs lazily to OpenJDK11 updates.
Bug: https://bugs.openjdk.java.net/browse/JDK-8229773
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8229773.11u-dev.0/
Original Change:
Hi Remi,
> in bytecodeUtils.cpp, in print_local_var(),
> i believe that the code
> if (!method->is_static() && (slot == 0)) {
> os->print("this");
> }
> ...
> is only true if the bytecode is generated by javac and ecj, tools like
> proguard
> that tries to obfuscate the code will
Hi,
why are there scrollbars in the image on JBS? When you normally
open a DMG you do not get scrollbars.
Michael
Message: 6
Date: Tue, 17 Sep 2019 19:42:01 -0700
From: Alexander Matveev
To: core-libs-dev
Subject: RFR: JDK-8230654: jpackage package-type dmg on macOS
Message-ID:
41 matches
Mail list logo