Hi Erik,
On 28/06/2016 1:57 AM, Erik Joelsson wrote:
Hello,
When doing a bootcycle build for a 32bit target, but using a 64bit
bootjdk, the JVM memory arguments found suitable for the 64bit bootjdk
are still used when running the bootcycle part of the build. When using
a 32bit bootjdk, we limit
On 2016-06-28 00:11, Iris Clark wrote:
HI, Claes.
Sorry, uploaded the previous diff again by mistake, updated in-place now.
I see the expected changes for unmodifiableList() now. Your changeset is
ready to go from my point of view.
Thanks!
Pushed.
/Claes
HI, Claes.
> Sorry, uploaded the previous diff again by mistake, updated in-place now.
I see the expected changes for unmodifiableList() now. Your changeset is
ready to go from my point of view.
Regards,
iris
-Original Message-
From: Claes Redestad
Sent: Monday, June 27, 2016 3:07 PM
Sorry, uploaded the previous diff again by mistake, updated in-place now.
On 2016-06-28 00:04, Mandy Chung wrote:
On Jun 27, 2016, at 2:43 PM, Claes Redestad wrote:
To accommodate your change request w.r.t. unmodifiableList above I took the
liberty of cleaning up VersionBuilder.parse() a bi
> On Jun 27, 2016, at 2:43 PM, Claes Redestad wrote:
>
> To accommodate your change request w.r.t. unmodifiableList above I took the
> liberty of cleaning up VersionBuilder.parse() a bit, though. Hope you don't
> mind:
>
> http://cr.openjdk.java.net/~redestad/816/webrev.6/
Moving Collect
On 2016-06-27 22:11, Iris Clark wrote:
Hi, Claes.
[ Sorry for the premature send, my keyboard started interpreting my shortcuts
in unexpected ways. ]
http://cr.openjdk.java.net/~redestad/816/webrev.5/
Nice bugid.
I can hardly believe my luck! :-)
Overall, this change looks good.
Hi, Claes.
[ Sorry for the premature send, my keyboard started interpreting my shortcuts
in unexpected ways. ]
> http://cr.openjdk.java.net/~redestad/816/webrev.5/
Nice bugid.
Overall, this change looks good. I just have a few concerns.
Have you built this forcing alternative build number
Hi Iris,
I've configured and run with various alternative build numbers, such as
--with-version-patch=5, which produces 9.0.0.5, and verified it works.
There was a bug in webrev.4 and earlier versions where a + 1 had slipped
out of the loop, fixed in the latest webrev[1].
What other concern
Hi, Claes.
http://cr.openjdk.java.net/~redestad/816/webrev.4/
Overall, this change looks good. I just have a few concerns.
Have you built this forcing alternative build numbers? I
-Original Message-
From: Claes Redestad
Sent: Sunday, June 26, 2016 12:56 PM
To: core-libs-dev Lib
Hi David, I responded before but didn't realize the response didn't go
to the list.
The problem was that I forgot this on configure:
--with-sdk-name=macosx10.9
Pete
On 6/27/16 10:01 AM, David DeHaven wrote:
> It can't find the SDK.
>
> After installing command line tools, did you run "sudo xcode
Hello,
When doing a bootcycle build for a 32bit target, but using a 64bit
bootjdk, the JVM memory arguments found suitable for the 64bit bootjdk
are still used when running the bootcycle part of the build. When using
a 32bit bootjdk, we limit the mx flag to 1100M while a 64bit bootjdk
gets 16
It can't find the SDK.
After installing command line tools, did you run "sudo xcode-select -switch
/path/to/Xcode.app"?
-DrD-
> On Jun 22, 2016, at 10:09 PM, Pete Brunet wrote:
>
> Installed 6.3.2. Refreshed source. Ran configure. make clean. make
> images. Build failed with
>
> === Out
On 2016-06-27 11:43, Erik Joelsson wrote:
Build changes look good.
Thanks!
Thanks Erik!
/Jesper
Den 27/6/16 kl. 11:37, skrev Erik Joelsson:
I'm not a Netbeans user so can't really verify that this works as intended. I'm
pretty sure the current project files don't work well at all however, so any
change to the better is likely good. Since changing the project files will
On 2016-06-27 01:40, David Holmes wrote:
Hi Tim,
On 25/06/2016 10:52 AM, Tim Bell wrote:
Hello
Please review this added sanity check for the Solaris assembler (as).
'as' is not installed by default on Solaris, and it would be better to
fail fast if missing.
Looks good to me too.
Fix look
Build changes look good.
/Erik
On 2016-06-26 21:55, Claes Redestad wrote:
Hi,
9+119 changed java.util.regex to initialize java.lang.invoke early,
causing a number of easily reproducible startup regressions.
This patch uses the fact that we already maintain the version string
constituents d
I will investigate.
/Erik
On 2016-06-24 12:09, Radosław Smogura wrote:
Dear Erik,
I’ve just run in issue which I wanted to solve by adding "rm -rf"
SetupCopyFiles COPY_CONF
[2] SRC :=
/Users/radek/Dev/Opensource/Java/jdk-experiments/jdk9-experiments.hg/build/macosx-x86_64-normal-server-slo
I'm not a Netbeans user so can't really verify that this works as
intended. I'm pretty sure the current project files don't work well at
all however, so any change to the better is likely good. Since changing
the project files will not affect the product or the build of it
directly, I'm fine wi
On 05/27/2016 12:37 AM, Bradford Wetmore wrote:
Hi Jiri,
This is open issue #2 from JEP-220 [1] that we still need to address for JDK 9,
so your patch will
likely be moot soon. It's possible that the jar will be going away.
If you would like to watch the progress, please add yourself to:
JDK
Hello,
I'm happy with the makefile changes, unless anyone else could come up
with a solution for any of the remaining warnings.
/Erik
On 2016-06-23 09:09, Ajit Ghaisas wrote:
Hi,
Bug :
https://bugs.openjdk.java.net/browse/JDK-8074824
(Resolve disabled warnings for libawt_xawt)
As
> On 26 Jun 2016, at 21:55, Claes Redestad wrote:
>
> Hi,
>
> 9+119 changed java.util.regex to initialize java.lang.invoke early, causing a
> number of easily reproducible startup regressions.
>
> This patch uses the fact that we already maintain the version string
> constituents during buil
21 matches
Mail list logo
