Yes. So '2013' -> '2014'.
Dan
On 12/5/14 3:17 PM, Chris Plummer wrote:
Is the copyright rule/policy to leave the oldest date and update the
most recent date to the current year?
Chris
On 12/5/14 1:48 PM, Daniel D. Daugherty wrote:
> http://cr.openjdk.java.net/~cjplummer/8066508/webrev.00/
Is the copyright rule/policy to leave the oldest date and update the
most recent date to the current year?
Chris
On 12/5/14 1:48 PM, Daniel D. Daugherty wrote:
> http://cr.openjdk.java.net/~cjplummer/8066508/webrev.00/
test/Makefile
No comments.
Thumbs up. Please fix the Copyright year b
Hi Jon,
On 12/05/2014 01:52 PM, Jonathan Gibbons wrote:
On 12/05/2014 11:46 AM, Staffan Friberg wrote:
Hi,
On 12/04/2014 10:23 PM, joe darcy wrote:
Hello,
On 12/4/2014 4:34 PM, David Holmes wrote:
Hi Staffan,
On 2/12/2014 10:08 AM, Staffan Friberg wrote:
Hi,
Hopefully this is the right
On 12/05/2014 11:46 AM, Staffan Friberg wrote:
Hi,
On 12/04/2014 10:23 PM, joe darcy wrote:
Hello,
On 12/4/2014 4:34 PM, David Holmes wrote:
Hi Staffan,
On 2/12/2014 10:08 AM, Staffan Friberg wrote:
Hi,
Hopefully this is the right list for this discussion.
As part of adding Microbenchm
> http://cr.openjdk.java.net/~cjplummer/8066508/webrev.00/
test/Makefile
No comments.
Thumbs up. Please fix the Copyright year before you push.
Dan
On 12/4/14 4:52 PM, David Holmes wrote:
Hi Chris,
Sorry I mis-directed you to send this one to build-dev, as it is a
hotspot test/Makefile
On 12/5/14 6:05 AM, Daniel D. Daugherty wrote:
On 12/5/14 2:45 AM, David Holmes wrote:
On 5/12/2014 7:22 PM, David Holmes wrote:
On 5/12/2014 6:11 PM, Staffan Larsen wrote:
Running with longer timeouts on fast machines makes the testing less
responsive (if a test is on its way to timeout it ta
On Tue, Oct 28, 2014 at 11:40:49AM +0100, Erik Joelsson wrote:
> Hello,
>
> Please review this small fix when using sjavac. When using a bootjdk
> that was built at a later date than when the source tree was
> initially cloned, there is a risk that sjavac will pick up classes
> from the boot class
Hi,
On 12/04/2014 10:23 PM, joe darcy wrote:
Hello,
On 12/4/2014 4:34 PM, David Holmes wrote:
Hi Staffan,
On 2/12/2014 10:08 AM, Staffan Friberg wrote:
Hi,
Hopefully this is the right list for this discussion.
As part of adding Microbenchmarks to the OpenJDK source tree, I'm
trying
to un
Hi,
We would like to stay on the heels of OpenJDK GA Releases. Such as current
jdk8u20 and later jdk8u40. Is there any recommendation on how to go about it?
Options that I can think of include:
1- A SOAP API portal would be nice, but I don't think it exists today.
2- How about mercurial itself?
On Fri, Dec 5, 2014 at 7:43 PM, Chris Hegarty wrote:
> On 5 Dec 2014, at 18:14, Volker Simonis wrote:
>
>> On Fri, Dec 5, 2014 at 7:09 PM, Chris Hegarty
>> wrote:
>>> Volker,
>>>
>>> Personally I would use the more verbose version,
>>> Files.setPosixFilePermissions, so we can see any failures.
On 5 Dec 2014, at 18:14, Volker Simonis wrote:
> On Fri, Dec 5, 2014 at 7:09 PM, Chris Hegarty
> wrote:
>> Volker,
>>
>> Personally I would use the more verbose version,
>> Files.setPosixFilePermissions, so we can see any failures. But as Alan
>> pointed out, this is a temporary build tool,
On Fri, Dec 5, 2014 at 7:09 PM, Chris Hegarty wrote:
> Volker,
>
> Personally I would use the more verbose version,
> Files.setPosixFilePermissions, so we can see any failures. But as Alan
> pointed out, this is a temporary build tool, and I live with it either way.
> Is there any reason why
Volker,
Personally I would use the more verbose version, Files.setPosixFilePermissions,
so we can see any failures. But as Alan pointed out, this is a temporary build
tool, and I live with it either way. Is there any reason why you cannot use
the NIO API ?
-Chris.
On 5 Dec 2014, at 16:50, V
On 04.12.2014 20:11, Alan Bateman wrote:
We've now moved to world where the runtime images are created from a
set of modules and this should give a lot of flexibility once. We're
just not there yet with locale data so we have to temporarily link in
the big jdk.localedata module so that the prof
On Fri, Dec 5, 2014 at 6:37 PM, Alan Bateman wrote:
> On 05/12/2014 17:34, Alan Bateman wrote:
>>
>> On 05/12/2014 17:26, Volker Simonis wrote:
>>>
>>> But why do we need an exception if setting the executable flags fails
>>> on 'jspawnhelper' and don't need on if it fails on the executables.
>>>
On 05/12/2014 17:34, Alan Bateman wrote:
On 05/12/2014 17:26, Volker Simonis wrote:
But why do we need an exception if setting the executable flags fails
on 'jspawnhelper' and don't need on if it fails on the executables.
We'll actually never notice that 'jspawnhelper' isn't executable if we
can
On 05/12/2014 17:26, Volker Simonis wrote:
But why do we need an exception if setting the executable flags fails
on 'jspawnhelper' and don't need on if it fails on the executables.
We'll actually never notice that 'jspawnhelper' isn't executable if we
can't execute 'java', right?
It is consiste
On Fri, Dec 5, 2014 at 6:00 PM, Alan Bateman wrote:
> On 05/12/2014 16:50, Volker Simonis wrote:
>>
>> Hi Chris,
>>
>> thanks for the fast response.
>>
>> I saw that code in ImageBuilder, but it looked overly complicated to
>> me. What about cleaning that up as well:
>>
>> http://cr.openjdk.java.n
On 05/12/2014 16:50, Volker Simonis wrote:
Hi Chris,
thanks for the fast response.
I saw that code in ImageBuilder, but it looked overly complicated to
me. What about cleaning that up as well:
http://cr.openjdk.java.net/~simonis/webrevs/8066766.v2/
I've just checked that on Solaris 'jspawnhel
Hi Chris,
thanks for the fast response.
I saw that code in ImageBuilder, but it looked overly complicated to
me. What about cleaning that up as well:
http://cr.openjdk.java.net/~simonis/webrevs/8066766.v2/
I've just checked that on Solaris 'jspawnhelper' still has the right
execution bits set a
On 2014-12-01 14:27, Erik Joelsson wrote:
Hello,
New webrev, which addresses Magnus' concern below, and various fixes
in Hotspot for incompatibilities with errexit.
Webrev: http://cr.openjdk.java.net/~erikj/8065576/webrev.02/
Bug: https://bugs.openjdk.java.net/browse/JDK-8065576
For the LOG
Thanks Volker,
I agree with your change, or you can take the code from ImageBuilder.
Either is fine with me.
private void setExecutable(Path file) {
try {
Set perms =
Files.getPosixFilePermissions(file);
perms.add(PosixFilePermission.OWNER_EXECUTE);
Hi,
after the integration of the modular changes into jdk9-dev the
executable commands in jdk/bin and jre/bin images are only executable
by the file owner. This means that only the user who built the images
can execute the programs.
This can be easily fixed with the following trivial change:
htt
On 12/5/14 2:45 AM, David Holmes wrote:
On 5/12/2014 7:22 PM, David Holmes wrote:
On 5/12/2014 6:11 PM, Staffan Larsen wrote:
Running with longer timeouts on fast machines makes the testing less
responsive (if a test is on its way to timeout it takes longer for us
to detect it). Ideally the tim
Looks good to me.
/Erik
On 2014-12-05 13:40, Magnus Ihse Bursie wrote:
JDK-8049367 (Modular Run-Time Images) contained large pieces of
heavily changed build logic. Getting such a thing in place is not easy.
A few, non-critical, merge errors crept up:
* Whitespace cleanup disappaeard
* Improve
JDK-8049367 (Modular Run-Time Images) contained large pieces of heavily
changed build logic. Getting such a thing in place is not easy.
A few, non-critical, merge errors crept up:
* Whitespace cleanup disappaeard
* Improvements in compare.sh were lost.
Bug: https://bugs.openjdk.java.net/browse/
On 5/12/2014 7:22 PM, David Holmes wrote:
On 5/12/2014 6:11 PM, Staffan Larsen wrote:
Running with longer timeouts on fast machines makes the testing less
responsive (if a test is on its way to timeout it takes longer for us
to detect it). Ideally the timeout factor should be tuned according to
> On 5 dec 2014, at 10:22, David Holmes wrote:
>
> On 5/12/2014 6:11 PM, Staffan Larsen wrote:
>> Running with longer timeouts on fast machines makes the testing less
>> responsive (if a test is on its way to timeout it takes longer for us to
>> detect it). Ideally the timeout factor should be
On 5/12/2014 6:11 PM, Staffan Larsen wrote:
Running with longer timeouts on fast machines makes the testing less responsive
(if a test is on its way to timeout it takes longer for us to detect it).
Ideally the timeout factor should be tuned according to the machine type we are
running on. I’m
Hello Volker,
Are these the only conditions for when sa-jdi.jar is not built? If so,
then I suppose this is fine.
The old Import.gmk would only copy sa-jdi.jar if it existed, and I think
we can keep that behavior, so just an existence check on sa-jdi.jar is
good enough in Import.gmk. In Gens
Running with longer timeouts on fast machines makes the testing less responsive
(if a test is on its way to timeout it takes longer for us to detect it).
Ideally the timeout factor should be tuned according to the machine type we are
running on. I’m not sure that is possible, though?
> On 5 dec
31 matches
Mail list logo
