Hello,
I usually build the JDK using 'make clean images', however doing so
with the new build results in the build dying (both on Win8.1 with
make 3.82 or 4 and on Ubuntu 14.04), ie the build ends with no end of
build messages (times and 'Finished building OpenJDK for target
'images''). The resulti
Here are my comments.
- Looks like this change removed the 8055088 fix for BreakIteratorInfo
optimization.
- The langtags field in each *Impl class should be volatile.
- DateFormatProviderImpl has static langtags to be shared by some other
*Impl. But JRE and CLDR have different sets of langu
Oh right, thanks David for remembering for me!
/Erik
On 2014-08-25 02:34, David Holmes wrote:
On 23/08/2014 1:52 AM, Erik Joelsson wrote:
I tried to reproduce this but my build succeeded. I know there was a lot
of trickery to getting the escaping working for all the $$ chars.
This seems to a
It would be nice to have a message indicating that a module build has
been completed as it would make a bit easier to figure out when a
failure occur.
On Mon, Aug 25, 2014 at 2:23 AM, David Holmes wrote:
> On 22/08/2014 1:39 AM, Erik Joelsson wrote:
>>
>> Hello Aleksey,
>>
>> As I have tried to e
On 25/08/2014 01:34, David Holmes wrote:
On 23/08/2014 1:52 AM, Erik Joelsson wrote:
I tried to reproduce this but my build succeeded. I know there was a lot
of trickery to getting the escaping working for all the $$ chars.
This seems to appear with new versions of make, and has been fixed in
I renamed the file make/common/SetupJava.gmk to
make/common/SetupJavaCompilers.gmk. This required changes in both the
root repo and the jdk repo and AFAIK I pushed both more or less at the
same time. I'm guessing you still managed to hit the race condition when
pulling changes.
/Erik
On 2014
On 2014-08-20 11:14, Magnus Ihse Bursie wrote:
On 2014-08-18 16:15, Anthony Petrov wrote:
So I'm not sure if the current set of AWT libraries could be
simplified any further.
Hope this helps.
Thank you for the clarification, it was very helpful!
While the set of AWT libraries probably canno
Hello Ludovic,
The lack of build summary is caused by the clean target deleting the
book keeping files used to create that summary as part of the clean. We
have just not designed this around running with clean in the same
command line. I would also encourage you to not run clean on the same
m
On 2014-08-25 02:23, David Holmes wrote:
On 22/08/2014 1:39 AM, Erik Joelsson wrote:
Hello Aleksey,
As I have tried to explain a couple of times now: The jdk8 build built
each repository in sequence (much like the jdk7 build did). Because of
this it made sense to add messages about which repos
I;m building jdk9/jdk9 - as always (is that not the right forest) and yes
its getting the latest changes from the repo. I can try zapping all the
folders and re-apply getsource.
Cheers,
Mani
On Mon, Aug 25, 2014 at 10:04 AM, Erik Joelsson
wrote:
> I renamed the file make/common/SetupJava.gmk
Thanks Erik, Andreas,
I'll adjust my steps.
On Mon, Aug 25, 2014 at 11:19 AM, Erik Joelsson
wrote:
> Hello Ludovic,
>
> The lack of build summary is caused by the clean target deleting the book
> keeping files used to create that summary as part of the clean. We have just
> not designed this arou
Helo Mani,
I don't think your problem was the same as Martin's. Recloning might be
a good idea still.
/Erik
On 2014-08-25 12:06, Mani Sarkar wrote:
I;m building jdk9/jdk9 - as always (is that not the right forest) and
yes its getting the latest changes from the repo. I can try zapping
all t
Hey Erik,
Build finished successfully, I rarely take this approach so thanks for
confirming.
Can I attribute this to some sort of 'Mercurial changesets not trickling
down to my machine' problem ;)
Cheers
Mani
On Mon, Aug 25, 2014 at 12:05 PM, Erik Joelsson
wrote:
> Helo Mani,
>
> I don't th
On 25/08/2014 7:41 PM, Erik Joelsson wrote:
On 2014-08-25 02:23, David Holmes wrote:
On 22/08/2014 1:39 AM, Erik Joelsson wrote:
Hello Aleksey,
As I have tried to explain a couple of times now: The jdk8 build built
each repository in sequence (much like the jdk7 build did). Because of
this it
I have just sent out a review request for JDK-8043936: "Drop HPROF as demo,
keep as HPROF agent shipped with JDK”.
That change removes hprof completely from the demos which makes the change
below obsolete. So if my change is accepted, the change below is no longer
needed.
Thanks,
/Staffan
On
Please review the following change to remove hprof as part of the demo package.
Instead, the source code has been moved to the jdk.hprof.agent module.
bug: https://bugs.openjdk.java.net/browse/JDK-8043936
webrev: http://cr.openjdk.java.net/~sla/8043936/webrev.00/
Thanks,
/Staffan
Please review this change to remove the legacy JPDA demos. These demos are
quite dated at this point and the included instructions are incomplete. In
addition the example/demo JPDA code does not fit well into the new modular
structure because the source code is used for both jdb and for the demo
On 25/08/2014 14:48, Staffan Larsen wrote:
Please review this change to remove the legacy JPDA demos. These demos are
quite dated at this point and the included instructions are incomplete. In
addition the example/demo JPDA code does not fit well into the new modular
structure because the sour
On 25 aug 2014, at 15:59, Alan Bateman wrote:
> On 25/08/2014 14:48, Staffan Larsen wrote:
>> Please review this change to remove the legacy JPDA demos. These demos are
>> quite dated at this point and the included instructions are incomplete. In
>> addition the example/demo JPDA code does not
On 25/08/2014 14:35, Staffan Larsen wrote:
Please review the following change to remove hprof as part of the demo package.
Instead, the source code has been moved to the jdk.hprof.agent module.
bug: https://bugs.openjdk.java.net/browse/JDK-8043936
webrev: http://cr.openjdk.java.net/~sla/8043936
Build changes look ok to me.
/Erik
On 2014-08-25 15:35, Staffan Larsen wrote:
Please review the following change to remove hprof as part of the demo package.
Instead, the source code has been moved to the jdk.hprof.agent module.
bug: https://bugs.openjdk.java.net/browse/JDK-8043936
webrev: ht
On 25 aug 2014, at 16:15, Alan Bateman wrote:
> On 25/08/2014 14:35, Staffan Larsen wrote:
>> Please review the following change to remove hprof as part of the demo
>> package. Instead, the source code has been moved to the jdk.hprof.agent
>> module.
>>
>> bug: https://bugs.openjdk.java.net/b
On 25/08/2014 15:38, Staffan Larsen wrote:
On 25 aug 2014, at 16:15, Alan Bateman wrote:
:
Having the README and manual in the same directory is probably okay as it has
always lived in the same directory as the source code. One thing is check is
the contents of manual.html as there is at le
Hello,
Please review this little workaround for a current shortcoming in
Sjavac. See bug for more details. With this change, Sjavac will start
acting correctly again and not miss any files that need to be
recompiled. The approximation is course however, we should still fix
https://bugs.openjd
On 22/08/2014 19:46, Naoto Sato wrote:
Hello,
Please review the changes for the following issue:
https://bugs.openjdk.java.net/browse/JDK-8038436
The proposed changes are located at:
http://cr.openjdk.java.net/~naoto/8038436/webrev.3/
The idea is to introduce an SPI so that supported locales
Webrev:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8055230/
This patch renames the class name of attach provider implementation class
to be the same for all platforms. This simplifies the build logic and
removes the need for generating the service config file at build time.
The files re
I like this change! :)
Looks good to me.
Thanks Mandy!
David
-
On 26/08/2014 2:29 PM, Mandy Chung wrote:
Webrev:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8055230/
This patch renames the class name of attach provider implementation class
to be the same for all platforms. This
Ahh. The simplicity!
Looks good!
Thanks,
/Staffan
On 26 aug 2014, at 06:29, Mandy Chung wrote:
> Webrev:
> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8055230/
>
> This patch renames the class name of attach provider implementation class
> to be the same for all platforms. This simplif
28 matches
Mail list logo
