Hello!
The spec of the constructors
StringBuilder(String)/StringBuilder(CharSequence) states that the
initial capacity of the builder will be set to the length of the
argument plus 16.
This causes them to throw confusing NegativeArraySizeException when the
argument's length is close to
Hi Magnus,
http://cr.openjdk.java.net/~almatvee/8217317/webrev.01/
Moved files to libjpackage and remove JPACKAGELIB_SRC.
Old wmain() was in jpackage.cpp line 461.
Thanks,
Alexander
On 2/1/2019 3:39 AM, Magnus Ihse Bursie wrote:
Hi Alexander,
On 2019-02-01 05:22, Alexander Matveev wrote:
Hi Andy,
Looks good.
Thanks,
Alexander
On 2/1/2019 6:54 AM, 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).
RFR: JDK-8217751: jpackage messages and failures
This is a fix to
Hi Roger,
Looks good to me - although it might hide bugs in Process.waitFor ?
best regards,
-- daniel
On 01/02/2019 16:47, Roger Riggs wrote:
Please review the addition of diagnostic output to the test library
ProcessTools.executeProcess
to aid in diagnosing several unexplained timeouts.
Hi Igor,
ok, no need to add useless code.
And yes there might be timing issue; but the output is purely
diagnostic and
it does not throw an exception so by itself would not cause the test to
misbehave.
Roger
On 02/01/2019 12:19 PM, Igor Ignatyev wrote:
Hi Roger,
it looks like we might
Hi Roger,
it looks like we might get false-positive "Process terminated unexpectedly" w/
this patch and as JDK-8218197 seems to better explain the evidence, I don't
think we need this patch at all.
Thanks,
-- Igor
> On Feb 1, 2019, at 8:47 AM, Roger Riggs wrote:
>
> Please review the
Please review the addition of diagnostic output to the test library
ProcessTools.executeProcess
to aid in diagnosing several unexplained timeouts.
It adds a second check for process being aliev using ProcessHandle and
prints
information about the current process and its descendents and all
Looks good.
/Erik
On 2019-02-01 02:50, Magnus Ihse Bursie wrote:
The CLDR data is, since Jigsaw, used in two different modules --
java.base and jdk.localedata. Unfortunately, the split between these
two modules were not fully finished as part of the Jigsaw project.
This patch aims to
This looks good once Magnus's concerns are addressed.
/Andy
On 2/1/2019 6:39 AM, Magnus Ihse Bursie wrote:
Hi Alexander,
On 2019-02-01 05:22, 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
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).
RFR: JDK-8217751: jpackage messages and failures
This is a fix to Error and Warning processing and Error message content.
[1] JDK-8217751
Hi Magnus,
I am assuming that the generated resource bundles are exactly the same
as before this fix, correct?
Naoto
On 2/1/19 2:50 AM, Magnus Ihse Bursie wrote:
The CLDR data is, since Jigsaw, used in two different modules --
java.base and jdk.localedata. Unfortunately, the split between
On 01/02/2019 10:52, Volker Simonis wrote:
:
As I wrote in my previous mail - this information has proved very
valuable for both, our support engineers as well as our developers.
What do you mean by "start with a summary"? The feature is trivial -
you get exact, per thread IO information in the
Hi Alan,
Are you referring to this?
8148188: Enhance the security libraries to record events of interest
http://hg.openjdk.java.net/jdk/jdk12/rev/f7309a1491d9
Which, presumably, needed this
8203629: Produce events in the JDK without a dependency on jdk.jfr
Hi Alexander,
On 2019-02-01 05:22, 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).
- jpackage launcher will now build same as Linux and OS X using
SetupBuildLauncher.
-
On 01/02/2019 11:19, Lindenmaier, Goetz wrote:
:
To kick in here, too:
The existing solution tells you which threads spend a lot of time
in IO operations. This is a good hint to problems in the infrastructure.
You might just write a few bytes, but still get long delays because the
disc is too
Hi,
> These features are orthogonal. Please read Gunter's answer about the
> difference in his previous mail
> (https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-
> January/058030.html)
> repeated here for your convenience:
>
> "The existing events are triggered only if the time the IO
On Wed, Jan 23, 2019 at 5:44 PM Alan Bateman wrote:
>
> On 23/01/2019 15:59, Haug, Gunter wrote:
> > :
> >
> > As Volker writes, we still think that the overhead of the up-calls is
> > acceptable but it would be possible to introduce a switch which is based on
> > a system property.
> >
> There
The CLDR data is, since Jigsaw, used in two different modules --
java.base and jdk.localedata. Unfortunately, the split between these two
modules were not fully finished as part of the Jigsaw project.
This patch aims to resolving most of this. The CLDRConverter build tool
is now called from
Hello,
The JavaDoc for some of the setBinary/ASCII... methods of PS say something
about „more practical“ but it is not clear if it means this method is more
practical than another method, or if this method should not be used in favor of
another.
When a very large binary value is input to
19 matches
Mail list logo
