From brent.christian at oracle.com Thu Aug 1 11:22:23 2013 From: brent.christian at oracle.com (Brent Christian) Date: Thu, 01 Aug 2013 11:22:23 -0700 Subject: Java 8 RFR 8011194: Apps launched via double-clicked .jars have file.encoding value of US-ASCII on Mac OS X In-Reply-To: <51F84C28.3050209@oracle.com> References: <51F2B781.1050104@oracle.com> <51F5FA02.9020909@oracle.com> <51F6C860.4020000@oracle.com> <51F72EAD.7040201@oracle.com>

<8CC8FA32-26C3-47D3-B6A3-33AA4BEC7D12@devrx.org> <4DB36382-0D2A-492F-8472-C198D2AB1568@apple.com> <51F84C28.3050209@oracle.com> Message-ID: <51FAA75F.7040205@oracle.com> On 7/30/13 4:28 PM, Naoto Sato wrote: > On 7/30/13 4:06 PM, David DeHaven wrote: >> >> I was about to chime in that UTF-8 has been the preferred encoding for >> (stored) text on Mac OS X as long as I've been hacking on it (think >> "Rhapsody"), so why is this even an issue? >> >> Judging from the docs, nl_langinfo seems like a Unix portability >> function (something more likely to be happier with ASCII in a >> terminal), not something to be used by a native Cocoa application. >> >> >> >> Set it to UTF-8 and forget about it >> > > +1. Naoto, would you be able to push this for me? Thanks, -Brent From naoto.sato at oracle.com Thu Aug 1 11:26:20 2013 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 01 Aug 2013 11:26:20 -0700 Subject: Java 8 RFR 8011194: Apps launched via double-clicked .jars have file.encoding value of US-ASCII on Mac OS X In-Reply-To: <51FAA75F.7040205@oracle.com> References: <51F2B781.1050104@oracle.com> <51F5FA02.9020909@oracle.com> <51F6C860.4020000@oracle.com> <51F72EAD.7040201@oracle.com>

<8CC8FA32-26C3-47D3-B6A3-33AA4BEC7D12@devrx.org> <4DB36382-0D2A-492F-8472-C198D2AB1568@apple.com> <51F84C28.3050209@oracle.com> <51FAA75F.7040205@oracle.com> Message-ID: <51FAA84C.4030704@oracle.com> Sure. Send me the final diff to me. Naoto On 8/1/13 11:22 AM, Brent Christian wrote: > On 7/30/13 4:28 PM, Naoto Sato wrote: >> On 7/30/13 4:06 PM, David DeHaven wrote: >>> >>> I was about to chime in that UTF-8 has been the preferred encoding for >>> (stored) text on Mac OS X as long as I've been hacking on it (think >>> "Rhapsody"), so why is this even an issue? >>> >>> Judging from the docs, nl_langinfo seems like a Unix portability >>> function (something more likely to be happier with ASCII in a >>> terminal), not something to be used by a native Cocoa application. >>> >>> >>> >>> Set it to UTF-8 and forget about it >>> >> >> +1. > > Naoto, would you be able to push this for me? > > Thanks, > -Brent From brent.christian at oracle.com Fri Aug 2 16:59:43 2013 From: brent.christian at oracle.com (Brent Christian) Date: Fri, 02 Aug 2013 16:59:43 -0700 Subject: JDK 1.7.0_25: apps launched via double click .app with incorrect file.encoding=US-ASCII In-Reply-To: References: Message-ID: <51FC47EF.9030006@oracle.com> Hi, Fabrizio On 7/31/13 6:03 AM, Fabrizio Giudici wrote: > This sounds to be a similar issue to "Java 8 RFR 8011194: Apps launched > via double-clicked .jars have file.encoding value of US-ASCII on Mac OS > X": that discussion actually helped me in sorting out the problem. > > In short, I have a Mac OS X .app which is created with an embedded JRE. > When launched by means of "open .../App.app" by terminal all is fine. I > suppose this happens because I have in my termnal env: > > LC_ALL=en_US.UTF-8 > LANG=en_US.UTF-8 > > When launched by double-clicking on the icon, the file.encoding is set > to US-ASCII and problems happen. Yes, this is almost certainly the same problem as 8011194. > How should I quickly fix the problem? Setting file.encoding and > sun.jnu.encoding to UTF-8 in the Info.plist? I think that's a good plan, yes. -Brent From Fabrizio.Giudici at tidalwave.it Fri Aug 2 23:48:20 2013 From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici) Date: Sat, 03 Aug 2013 08:48:20 +0200 Subject: JDK 1.7.0_25: apps launched via double click .app with incorrect file.encoding=US-ASCII In-Reply-To: <51FC47EF.9030006@oracle.com> References: <51FC47EF.9030006@oracle.com> Message-ID: On Sat, 03 Aug 2013 01:59:43 +0200, Brent Christian wrote: > Hi, Fabrizio > > On 7/31/13 6:03 AM, Fabrizio Giudici wrote: >> This sounds to be a similar issue to "Java 8 RFR 8011194: Apps launched >> via double-clicked .jars have file.encoding value of US-ASCII on Mac OS >> X": that discussion actually helped me in sorting out the problem. >> >> In short, I have a Mac OS X .app which is created with an embedded JRE. >> When launched by means of "open .../App.app" by terminal all is fine. I >> suppose this happens because I have in my termnal env: >> >> LC_ALL=en_US.UTF-8 >> LANG=en_US.UTF-8 >> >> When launched by double-clicking on the icon, the file.encoding is set >> to US-ASCII and problems happen. > > Yes, this is almost certainly the same problem as 8011194. > >> How should I quickly fix the problem? Setting file.encoding and >> sun.jnu.encoding to UTF-8 in the Info.plist? > > I think that's a good plan, yes. It works. Thanks. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. "We make Java work. Everywhere." http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it From jose.cornado at gmail.com Wed Aug 7 17:56:06 2013 From: jose.cornado at gmail.com (=?ISO-8859-1?Q?Jos=E9_Cornado?=) Date: Wed, 7 Aug 2013 18:56:06 -0600 Subject: "-implicit:none" flag is ignored Message-ID: Hello! I am running into the following problem in the latest 1.6 and 1.7 (1.7.0_25-b15): I have a jvm in the background that uses the built-in compiler: it builds some code dynamically and it uses the "-implicit:none" flag to speed up the task. For a relatively long time it worked. Now, it seems to fail. The only difference is that now I am importing a class already created using a previous call to this builder. The verbose runs of the task show the correct paths being included. A listing of the bin dirs shows *.class are in place. Has anybody seen this? Thanks a lot!!! -- Jos? Cornado -- home: http://www.efekctive.com blog: http://blogging.efekctive.com ---------------------- Everything has been said before, but since nobody listens we have to keep going back and beginning all over again. Andre Gide From jose.cornado at gmail.com Wed Aug 7 18:26:27 2013 From: jose.cornado at gmail.com (=?ISO-8859-1?Q?Jos=E9_Cornado?=) Date: Wed, 7 Aug 2013 19:26:27 -0600 Subject: "-implicit:none" flag is ignored In-Reply-To: References: Message-ID: The end of the story: The recently created class does not have a corresponding source file. This causes the task run to fail. There is an obvious work-around but it would reduce the task to a crawl. On Wed, Aug 7, 2013 at 6:56 PM, Jos? Cornado wrote: > Hello! > > I am running into the following problem in the latest 1.6 and 1.7 > (1.7.0_25-b15): > > I have a jvm in the background that uses the built-in compiler: it builds > some code dynamically and it uses the "-implicit:none" flag to speed up the > task. > > For a relatively long time it worked. Now, it seems to fail. > > The only difference is that now I am importing a class already created > using a previous call to this builder. > > The verbose runs of the task show the correct paths being included. A > listing of the bin dirs shows *.class are in place. > > Has anybody seen this? > > Thanks a lot!!! > > -- > Jos? Cornado > > -- > > home: http://www.efekctive.com > blog: http://blogging.efekctive.com > ---------------------- > > Everything has been said before, but since nobody listens we have to keep > going back and beginning all over again. > > Andre Gide > -- Jos? Cornado -- home: http://www.efekctive.com blog: http://blogging.efekctive.com ---------------------- Everything has been said before, but since nobody listens we have to keep going back and beginning all over again. Andre Gide From jose.cornado at gmail.com Thu Aug 8 07:15:56 2013 From: jose.cornado at gmail.com (=?ISO-8859-1?Q?Jos=E9_Cornado?=) Date: Thu, 8 Aug 2013 08:15:56 -0600 Subject: "-implicit:none" flag is ignored In-Reply-To: References: Message-ID: The other point of info is: When "-implicit:none" used to work the implicit class was located in a different folder from the one where the class being generated. It is failing when the implicit class resides in the same folder as the injected class. Thanks a lot in advance!!! On Wed, Aug 7, 2013 at 7:26 PM, Jos? Cornado wrote: > The end of the story: > > The recently created class does not have a corresponding source file. This > causes the task run to fail. > > There is an obvious work-around but it would reduce the task to a crawl. > > > On Wed, Aug 7, 2013 at 6:56 PM, Jos? Cornado wrote: > >> Hello! >> >> I am running into the following problem in the latest 1.6 and 1.7 >> (1.7.0_25-b15): >> >> I have a jvm in the background that uses the built-in compiler: it builds >> some code dynamically and it uses the "-implicit:none" flag to speed up the >> task. >> >> For a relatively long time it worked. Now, it seems to fail. >> >> The only difference is that now I am importing a class already created >> using a previous call to this builder. >> >> The verbose runs of the task show the correct paths being included. A >> listing of the bin dirs shows *.class are in place. >> >> Has anybody seen this? >> >> Thanks a lot!!! >> >> -- >> Jos? Cornado >> >> -- >> >> home: http://www.efekctive.com >> blog: http://blogging.efekctive.com >> ---------------------- >> >> Everything has been said before, but since nobody listens we have to keep >> going back and beginning all over again. >> >> Andre Gide >> > > > > -- > Jos? Cornado > > -- > > home: http://www.efekctive.com > blog: http://blogging.efekctive.com > ---------------------- > > Everything has been said before, but since nobody listens we have to keep > going back and beginning all over again. > > Andre Gide > -- Jos? Cornado -- home: http://www.efekctive.com blog: http://blogging.efekctive.com ---------------------- Everything has been said before, but since nobody listens we have to keep going back and beginning all over again. Andre Gide From jose.cornado at gmail.com Thu Aug 8 08:55:38 2013 From: jose.cornado at gmail.com (=?ISO-8859-1?Q?Jos=E9_Cornado?=) Date: Thu, 8 Aug 2013 09:55:38 -0600 Subject: "-implicit:none" flag is ignored In-Reply-To: References: Message-ID: So, this is the last time I bring this thread (it turns out that after the java/apple/mac issues were cleared up this is not mac specific) the question is: Is it possible to instruct javac to "implicit:ignore" classes on the same folder as the class being built? Or do we need to place the source files in the directory? On Thu, Aug 8, 2013 at 8:15 AM, Jos? Cornado wrote: > The other point of info is: > > > When "-implicit:none" used to work the implicit class was located in a > different folder from the one where the class being generated. It is > failing when the implicit class resides in the same folder as the injected > class. > > Thanks a lot in advance!!! > > > On Wed, Aug 7, 2013 at 7:26 PM, Jos? Cornado wrote: > >> The end of the story: >> >> The recently created class does not have a corresponding source file. >> This causes the task run to fail. >> >> There is an obvious work-around but it would reduce the task to a crawl. >> >> >> On Wed, Aug 7, 2013 at 6:56 PM, Jos? Cornado wrote: >> >>> Hello! >>> >>> I am running into the following problem in the latest 1.6 and 1.7 >>> (1.7.0_25-b15): >>> >>> I have a jvm in the background that uses the built-in compiler: it >>> builds some code dynamically and it uses the "-implicit:none" flag to speed >>> up the task. >>> >>> For a relatively long time it worked. Now, it seems to fail. >>> >>> The only difference is that now I am importing a class already created >>> using a previous call to this builder. >>> >>> The verbose runs of the task show the correct paths being included. A >>> listing of the bin dirs shows *.class are in place. >>> >>> Has anybody seen this? >>> >>> Thanks a lot!!! >>> >>> -- >>> Jos? Cornado >>> >>> -- >>> >>> home: http://www.efekctive.com >>> blog: http://blogging.efekctive.com >>> ---------------------- >>> >>> Everything has been said before, but since nobody listens we have to >>> keep going back and beginning all over again. >>> >>> Andre Gide >>> >> >> >> >> -- >> Jos? Cornado >> >> -- >> >> home: http://www.efekctive.com >> blog: http://blogging.efekctive.com >> ---------------------- >> >> Everything has been said before, but since nobody listens we have to keep >> going back and beginning all over again. >> >> Andre Gide >> > > > > -- > Jos? Cornado > > -- > > home: http://www.efekctive.com > blog: http://blogging.efekctive.com > ---------------------- > > Everything has been said before, but since nobody listens we have to keep > going back and beginning all over again. > > Andre Gide > -- Jos? Cornado -- home: http://www.efekctive.com blog: http://blogging.efekctive.com ---------------------- Everything has been said before, but since nobody listens we have to keep going back and beginning all over again. Andre Gide From jonathan.gibbons at oracle.com Thu Aug 8 09:16:12 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 08 Aug 2013 09:16:12 -0700 Subject: "-implicit:none" flag is ignored In-Reply-To: References: Message-ID: <5203C44C.4020901@oracle.com> If this is the "-implicit:none" flag in JDK javac, and if you think it is not working, you should have this discussion on compiler-dev at openjdk.java.net. -- Jon On 08/08/2013 07:15 AM, Jos? Cornado wrote: > The other point of info is: > > > When "-implicit:none" used to work the implicit class was located in a > different folder from the one where the class being generated. It is > failing when the implicit class resides in the same folder as the injected > class. > > Thanks a lot in advance!!! > > > On Wed, Aug 7, 2013 at 7:26 PM, Jos? Cornado wrote: > >> The end of the story: >> >> The recently created class does not have a corresponding source file. This >> causes the task run to fail. >> >> There is an obvious work-around but it would reduce the task to a crawl. >> >> >> On Wed, Aug 7, 2013 at 6:56 PM, Jos? Cornado wrote: >> >>> Hello! >>> >>> I am running into the following problem in the latest 1.6 and 1.7 >>> (1.7.0_25-b15): >>> >>> I have a jvm in the background that uses the built-in compiler: it builds >>> some code dynamically and it uses the "-implicit:none" flag to speed up the >>> task. >>> >>> For a relatively long time it worked. Now, it seems to fail. >>> >>> The only difference is that now I am importing a class already created >>> using a previous call to this builder. >>> >>> The verbose runs of the task show the correct paths being included. A >>> listing of the bin dirs shows *.class are in place. >>> >>> Has anybody seen this? >>> >>> Thanks a lot!!! >>> >>> -- >>> Jos? Cornado >>> >>> -- >>> >>> home: http://www.efekctive.com >>> blog: http://blogging.efekctive.com >>> ---------------------- >>> >>> Everything has been said before, but since nobody listens we have to keep >>> going back and beginning all over again. >>> >>> Andre Gide >>> >> >> >> -- >> Jos? Cornado >> >> -- >> >> home: http://www.efekctive.com >> blog: http://blogging.efekctive.com >> ---------------------- >> >> Everything has been said before, but since nobody listens we have to keep >> going back and beginning all over again. >> >> Andre Gide >> > > From jose.cornado at gmail.com Thu Aug 8 17:21:55 2013 From: jose.cornado at gmail.com (=?ISO-8859-1?Q?Jos=E9_Cornado?=) Date: Thu, 8 Aug 2013 18:21:55 -0600 Subject: "-implicit:none" flag is ignored In-Reply-To: <5203C44C.4020901@oracle.com> References: <5203C44C.4020901@oracle.com> Message-ID: Thanks! Sorry. I am kind of lost: the lastest update from apple was not good and I couldn't figure out if the problem was the jdk's, mine or what. On Thu, Aug 8, 2013 at 10:16 AM, Jonathan Gibbons < jonathan.gibbons at oracle.com> wrote: > If this is the "-implicit:none" flag in JDK javac, and if you think it is > not working, > you should have this discussion on compiler-dev at openjdk.java.net. > > -- Jon > > > > On 08/08/2013 07:15 AM, Jos? Cornado wrote: > >> The other point of info is: >> >> >> When "-implicit:none" used to work the implicit class was located in a >> different folder from the one where the class being generated. It is >> failing when the implicit class resides in the same folder as the injected >> class. >> >> Thanks a lot in advance!!! >> >> >> On Wed, Aug 7, 2013 at 7:26 PM, Jos? Cornado >> wrote: >> >> The end of the story: >>> >>> The recently created class does not have a corresponding source file. >>> This >>> causes the task run to fail. >>> >>> There is an obvious work-around but it would reduce the task to a crawl. >>> >>> >>> On Wed, Aug 7, 2013 at 6:56 PM, Jos? Cornado >> >wrote: >>> >>> Hello! >>>> >>>> I am running into the following problem in the latest 1.6 and 1.7 >>>> (1.7.0_25-b15): >>>> >>>> I have a jvm in the background that uses the built-in compiler: it >>>> builds >>>> some code dynamically and it uses the "-implicit:none" flag to speed up >>>> the >>>> task. >>>> >>>> For a relatively long time it worked. Now, it seems to fail. >>>> >>>> The only difference is that now I am importing a class already created >>>> using a previous call to this builder. >>>> >>>> The verbose runs of the task show the correct paths being included. A >>>> listing of the bin dirs shows *.class are in place. >>>> >>>> Has anybody seen this? >>>> >>>> Thanks a lot!!! >>>> >>>> -- >>>> Jos? Cornado >>>> >>>> -- >>>> >>>> home: http://www.efekctive.com >>>> blog: http://blogging.efekctive.com >>>> ---------------------- >>>> >>>> Everything has been said before, but since nobody listens we have to >>>> keep >>>> going back and beginning all over again. >>>> >>>> Andre Gide >>>> >>>> >>> >>> -- >>> Jos? Cornado >>> >>> -- >>> >>> home: http://www.efekctive.com >>> blog: http://blogging.efekctive.com >>> ---------------------- >>> >>> Everything has been said before, but since nobody listens we have to keep >>> going back and beginning all over again. >>> >>> Andre Gide >>> >>> >> >> > -- Jos? Cornado -- home: http://www.efekctive.com blog: http://blogging.efekctive.com ---------------------- Everything has been said before, but since nobody listens we have to keep going back and beginning all over again. Andre Gide From tim.bell at oracle.com Tue Aug 13 12:49:51 2013 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 13 Aug 2013 12:49:51 -0700 Subject: RFR: 8019470 "Changes needed to compile JDK8 on MacOS with clang compiler" In-Reply-To: <51F0AD1D.1080907@oracle.com> References: <51EF006D.3060805@oracle.com> <51EFBDC9.4070200@oracle.com> <51EFC56C.6040304@oracle.com> <51F059A3.3080403@oracle.com> <51F0AD1D.1080907@oracle.com> Message-ID: <520A8DDF.9020206@oracle.com> On 07/24/13 09:44 PM, David Holmes wrote: > On 25/07/2013 8:48 AM, Tim Bell wrote: >> Christian: >> >>> That's not true. I've added Mac OS X support with the same change. >> >> For building hotspot only, perhaps. I want to build the entire product, >> start to finish, using clang. >> >> That's why I needed to touch these files: >> >> common/autoconf/hotspot-spec.gmk.in >> common/autoconf/toolchain.m4 >> make/jprt.properties > > Yes but that doesn't explain the change now needed to os_bsd.cpp in > hotspot. I take it back. After syncing up with jdk8/master, the change to os_bsd.cpp is not required, so I removed that. I believe the MAX_PATH issues were resolved in an earlier fix. New webrev (hotspot only): http://cr.openjdk.java.net/~tbell/8019470/hotspot.01/ The change in make/bsd/makefiles/gcc.make is required to link the adlc tool which is used early in the hotspot build. Full webrev (OpenJDK): http://cr.openjdk.java.net/~tbell/8019470/webrev.01/ Thanks in advance - we would like to get these changes checked in this week. Tim > David > ----- > >> >> Tim >> >> >> On 07/24/13 02:59 PM, Christian Thalinger wrote: >>> On Jul 24, 2013, at 5:15 AM, Tim Bell wrote: >>> >>>> On 07/24/13 04:43 AM, David Holmes wrote: >>>>> Hi Tim, >>>>> >>>>> On 24/07/2013 8:15 AM, Tim Bell wrote: >>>>>> Hello everyone- >>>>>> >>>>>> This is a small set of changes to switch from gcc to clang when >>>>>> building >>>>> So we already added support for clang as the compiler for hotspot - >>>>> is this just extending things to allow configure to select clang? >>>> The earlier clang/hotspot activity was centered around Linux >>>> x86/x86_64. >>> That's not true. I've added Mac OS X support with the same change. >>> >>> -- Chris >>> >>>>>> on MacOS, and also enable building on MacOS 8.x >>>>> Have we already updated all the JPRT queues to have 10.8 macs versus >>>>> 10.7 ones? >>>> Yes, all the queues have 10.8 Macs, which have been test-only up >>>> until now. >>>> >>>>>> Here is the bug report: >>>>>> >>>>>> http://bugs.sun.com/view_bug.do?bug_id=8019470 >>>>>> >>>>>> Here are the webrevs: >>>>>> >>>>>> Hotspot only: >>>>>> >>>>>> http://cr.openjdk.java.net/~tbell/8019470/hotspot/webrev.00/ >>>>> src/os/bsd/vm/os_bsd.cpp >>>>> >>>>> Again I'm confused. We already allowed building via clang so why >>>>> wasn't this change needed before? >>>> This file is not used when building on Linux. >>>> >>>> Tim >>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> All of the changes: >>>>>> >>>>>> http://cr.openjdk.java.net/~tbell/8019470/webrev.00/ >>>>> >>>>>> Thanks in advance. >>>>>> >>>>>> Tim >>>>>> >> From tim.bell at oracle.com Tue Aug 13 15:00:50 2013 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 13 Aug 2013 15:00:50 -0700 Subject: RFR: 8019470 "Changes needed to compile JDK8 on MacOS with clang compiler" In-Reply-To: <520A8DDF.9020206@oracle.com> References: <51EF006D.3060805@oracle.com> <51EFBDC9.4070200@oracle.com> <51EFC56C.6040304@oracle.com> <51F059A3.3080403@oracle.com> <51F0AD1D.1080907@oracle.com> <520A8DDF.9020206@oracle.com> Message-ID: <520AAC92.7090405@oracle.com> I wrote: > Thanks in advance - we would like to get these changes checked in this > week. Let me clarify this a bit - there are some bugs open against the MacOS/clang hotspot build that need to be resolved before considering a change-over to clang: http://bugs.sun.com/view_bug.do?bug_id=8021954 http://bugs.sun.com/view_bug.do?bug_id=8022140 I would like to get the hotspot side of these changes checked in as soon as possible (need a sponsor for this...): http://cr.openjdk.java.net/~tbell/8019470/hotspot.01/ This change will do nothing unless USE_CLANG is defined to true. I'd like to get the hotspot side ready early so it has time to meet up with the next JDK8 promotion. Thanks- Tim On 08/13/13 12:49 PM, Tim Bell wrote: > On 07/24/13 09:44 PM, David Holmes wrote: >> On 25/07/2013 8:48 AM, Tim Bell wrote: >>> Christian: >>> >>>> That's not true. I've added Mac OS X support with the same change. >>> >>> For building hotspot only, perhaps. I want to build the entire >>> product, >>> start to finish, using clang. >>> >>> That's why I needed to touch these files: >>> >>> common/autoconf/hotspot-spec.gmk.in >>> common/autoconf/toolchain.m4 >>> make/jprt.properties >> >> Yes but that doesn't explain the change now needed to os_bsd.cpp in >> hotspot. > > I take it back. After syncing up with jdk8/master, the change to > os_bsd.cpp is not required, so I removed that. I believe the MAX_PATH > issues were resolved in an earlier fix. > > New webrev (hotspot only): > > http://cr.openjdk.java.net/~tbell/8019470/hotspot.01/ > > The change in make/bsd/makefiles/gcc.make is required to link the adlc > tool which is used early in the hotspot build. > > Full webrev (OpenJDK): > > http://cr.openjdk.java.net/~tbell/8019470/webrev.01/ > > > Thanks in advance - we would like to get these changes checked in this > week. > > Tim > > >> David >> ----- >> >>> >>> Tim >>> >>> >>> On 07/24/13 02:59 PM, Christian Thalinger wrote: >>>> On Jul 24, 2013, at 5:15 AM, Tim Bell wrote: >>>> >>>>> On 07/24/13 04:43 AM, David Holmes wrote: >>>>>> Hi Tim, >>>>>> >>>>>> On 24/07/2013 8:15 AM, Tim Bell wrote: >>>>>>> Hello everyone- >>>>>>> >>>>>>> This is a small set of changes to switch from gcc to clang when >>>>>>> building >>>>>> So we already added support for clang as the compiler for hotspot - >>>>>> is this just extending things to allow configure to select clang? >>>>> The earlier clang/hotspot activity was centered around Linux >>>>> x86/x86_64. >>>> That's not true. I've added Mac OS X support with the same change. >>>> >>>> -- Chris >>>> >>>>>>> on MacOS, and also enable building on MacOS 8.x >>>>>> Have we already updated all the JPRT queues to have 10.8 macs versus >>>>>> 10.7 ones? >>>>> Yes, all the queues have 10.8 Macs, which have been test-only up >>>>> until now. >>>>> >>>>>>> Here is the bug report: >>>>>>> >>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8019470 >>>>>>> >>>>>>> Here are the webrevs: >>>>>>> >>>>>>> Hotspot only: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~tbell/8019470/hotspot/webrev.00/ >>>>>> src/os/bsd/vm/os_bsd.cpp >>>>>> >>>>>> Again I'm confused. We already allowed building via clang so why >>>>>> wasn't this change needed before? >>>>> This file is not used when building on Linux. >>>>> >>>>> Tim >>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> All of the changes: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~tbell/8019470/webrev.00/ >>>>>> >>>>>>> Thanks in advance. >>>>>>> >>>>>>> Tim >>>>>>> >>> > From leonid.romanov at oracle.com Wed Aug 14 09:44:04 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Wed, 14 Aug 2013 20:44:04 +0400 Subject: [8] Review request for 8022997: [macosx] Remaining duplicated key events Message-ID: <9E34DB6A-C9C9-4DE6-B664-959E38BFD995@oracle.com> Hello, Please review a one line fix for 8022997: [macosx] Remaining duplicated key events. NsCharToJavaChar() we call at CMenuItem.m:92 translates NSCarriageReturnCharacter (which is the key code generated by OS X when user presses "enter" key) into NSNewlineCharacter. So, in order to filter out the duplicate event at line 101, menuKey has to be NSNewlineCharacter as well. This is what the fix does. Bug: http://bugs.sun.com/view_bug.do?bug_id=8022997 (might not be available yet) webrev: http://cr.openjdk.java.net/~leonidr/8022997/webrev.00/ Thanks, Leonid. From paul_t100 at fastmail.fm Wed Aug 14 09:49:14 2013 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Wed, 14 Aug 2013 17:49:14 +0100 Subject: Cannot build with AppBunder and the latest early access release of 1.7.0_40 Message-ID: <520BB50A.8040003@fastmail.fm> I just updated from build 1.7.0_40-ea (24.0-b48) to the latest build 1.7.0_40-ea (24.0-b55) and now when I try to use the fork of AppBundler at https://bitbucket.org/infinitekind/appbundler its failing Ive double checked and don't think Im doing anything stupid, has something significant changed between versions /Users/paul/code/jthink/SongKong/build.xml:20: java.nio.file.NoSuchFileException: /Users/paul/code/jthink/SongKong/MacOS at sun.nio.fs.UnixException.translateToIOException(UnixException.java:86) at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102) at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107) at sun.nio.fs.UnixCopyFile.copy(UnixCopyFile.java:520) at sun.nio.fs.UnixFileSystemProvider.copy(UnixFileSystemProvider.java:253) at java.nio.file.Files.copy(Files.java:1225) at com.oracle.appbundler.AppBundlerTask.copy(AppBundlerTask.java:712) at com.oracle.appbundler.AppBundlerTask.copyRuntime(AppBundlerTask.java:406) at com.oracle.appbundler.AppBundlerTask.execute(AppBundlerTask.java:336) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.Target.execute(Target.java:392) at org.apache.tools.ant.helper.ProjectHelper2.parse(ProjectHelper2.java:180) at org.apache.tools.ant.ProjectHelper.configureProject(ProjectHelper.java:82) at org.apache.tools.ant.Main.runBuild(Main.java:795) at org.apache.tools.ant.Main.startAnt(Main.java:217) at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280) at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109) thanks Paul From anthony.petrov at oracle.com Wed Aug 14 09:50:38 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 14 Aug 2013 20:50:38 +0400 Subject: [8] Review request for 8022997: [macosx] Remaining duplicated key events In-Reply-To: <9E34DB6A-C9C9-4DE6-B664-959E38BFD995@oracle.com> References: <9E34DB6A-C9C9-4DE6-B664-959E38BFD995@oracle.com> Message-ID: <520BB55E.1000506@oracle.com> The fix looks good to me. -- best regards, Anthony On 08/14/2013 08:44 PM, Leonid Romanov wrote: > Hello, > Please review a one line fix for 8022997: [macosx] Remaining duplicated key events. NsCharToJavaChar() we call at CMenuItem.m:92 translates NSCarriageReturnCharacter (which is the key code generated by OS X when user presses "enter" key) into NSNewlineCharacter. So, in order to filter out the duplicate event at line 101, menuKey has to be NSNewlineCharacter as well. This is what the fix does. > > Bug: http://bugs.sun.com/view_bug.do?bug_id=8022997 (might not be available yet) > webrev: http://cr.openjdk.java.net/~leonidr/8022997/webrev.00/ > > Thanks, > Leonid. > From Sergey.Bylokhov at oracle.com Wed Aug 14 09:59:36 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 14 Aug 2013 20:59:36 +0400 Subject: [8] Review request for 8022997: [macosx] Remaining duplicated key events In-Reply-To: <9E34DB6A-C9C9-4DE6-B664-959E38BFD995@oracle.com> References: <9E34DB6A-C9C9-4DE6-B664-959E38BFD995@oracle.com> Message-ID: <520BB778.8040604@oracle.com> Hi, Leonid. Fix looks fine. On 14.08.2013 20:44, Leonid Romanov wrote: > Hello, > Please review a one line fix for 8022997: [macosx] Remaining duplicated key events. NsCharToJavaChar() we call at CMenuItem.m:92 translates NSCarriageReturnCharacter (which is the key code generated by OS X when user presses "enter" key) into NSNewlineCharacter. So, in order to filter out the duplicate event at line 101, menuKey has to be NSNewlineCharacter as well. This is what the fix does. > > Bug: http://bugs.sun.com/view_bug.do?bug_id=8022997 (might not be available yet) > webrev: http://cr.openjdk.java.net/~leonidr/8022997/webrev.00/ > > Thanks, > Leonid. > -- Best regards, Sergey. From marko.asplund at gmail.com Wed Aug 14 13:48:50 2013 From: marko.asplund at gmail.com (Marko Asplund) Date: Wed, 14 Aug 2013 23:48:50 +0300 Subject: Building JDK8 on OS X 10.8.4 Message-ID: hi, I'm having trouble building the latest JDK8 version using instructions found in wiki (https://wiki.openjdk.java.net/display/MacOSXPort/Main). After cloning the repositories when I try to start the build I get the following error: bash-3.2$ CPATH="/usr/X11/include" LANG=C make ALLOW_DOWNLOADS=true ALT_BOOTDIR=`/usr/libexec/java_home -v 1.7+` No configurations found for /Users/aspluma/projects/openjdk/jdk8/! Please run configure to create a configuration. NewMakefile.gmk:57: *** Cannot continue. Stop. Running configure fixes this, but it's not currently mentioned on the wiki page. After that, the build still fails at a later phase: cc1plus: warnings being treated as errors /Users/aspluma/projects/openjdk/jdk8/hotspot/src/os/bsd/vm/attachListener_bsd.cpp: In static member function 'static void AttachListener::vm_start()': /Users/aspluma/projects/openjdk/jdk8/hotspot/src/os/bsd/vm/attachListener_bsd.cpp:455: warning: 'stat64' is deprecated (declared at /usr/include/sys/stat.h:466) /Users/aspluma/projects/openjdk/jdk8/hotspot/src/os/bsd/vm/attachListener_bsd.cpp:455: warning: 'stat64' is deprecated (declared at /usr/include/sys/stat.h:466) make[8]: *** [attachListener_bsd.o] Error 1 make[8]: *** Waiting for unfinished jobs.... make[7]: *** [the_vm] Error 2 make[6]: *** [product] Error 2 make[5]: *** [generic_build2] Error 2 make[4]: *** [product] Error 2 make[3]: *** [all_product_universal] Error 2 make[2]: *** [universal_product] Error 2 make[1]: *** [/Users/aspluma/projects/openjdk/jdk8/build/macosx-x86_64-normal-server-release/hotspot/_hotspot.timestamp] Error 2 make: *** [hotspot-only] Error 2 There was discussion about this issue on the OpenJDK Hotspot mailing list, but apparently the fix has not yet been applied to the code base? Also, get_source.sh runs pretty slowly on my laptop (2 cores, 8 GB memory) taking about 55 minutes to complete. Is this normal? Any way to speed it up? marko From leonid.romanov at oracle.com Wed Aug 14 14:38:46 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Thu, 15 Aug 2013 01:38:46 +0400 Subject: Building JDK8 on OS X 10.8.4 In-Reply-To: References: Message-ID: <45A25BF8-EF53-4D98-BCD4-E9B831865CAF@oracle.com> Hello, The instructions on wiki are for building JDK 7. JDK 8 has a newer and better build system, so, as you've discovered, you only have to type "./configure; make". As for Hotspot building error, use "make WARNINGS_ARE_ERRORS=" command as a workaround. Regards, Leonid. On Aug 15, 2013, at 12:48 AM, Marko Asplund wrote: > hi, > > I'm having trouble building the latest JDK8 version using instructions > found in wiki > (https://wiki.openjdk.java.net/display/MacOSXPort/Main). > > After cloning the repositories when I try to start the build I get the > following error: > > bash-3.2$ CPATH="/usr/X11/include" LANG=C make ALLOW_DOWNLOADS=true > ALT_BOOTDIR=`/usr/libexec/java_home -v 1.7+` > No configurations found for /Users/aspluma/projects/openjdk/jdk8/! Please > run configure to create a configuration. > NewMakefile.gmk:57: *** Cannot continue. Stop. > > Running configure fixes this, but it's not currently mentioned on the wiki > page. > > After that, the build still fails at a later phase: > > cc1plus: warnings being treated as errors > /Users/aspluma/projects/openjdk/jdk8/hotspot/src/os/bsd/vm/attachListener_bsd.cpp: > In static member function 'static void AttachListener::vm_start()': > /Users/aspluma/projects/openjdk/jdk8/hotspot/src/os/bsd/vm/attachListener_bsd.cpp:455: > warning: 'stat64' is deprecated (declared at /usr/include/sys/stat.h:466) > /Users/aspluma/projects/openjdk/jdk8/hotspot/src/os/bsd/vm/attachListener_bsd.cpp:455: > warning: 'stat64' is deprecated (declared at /usr/include/sys/stat.h:466) > make[8]: *** [attachListener_bsd.o] Error 1 > make[8]: *** Waiting for unfinished jobs.... > make[7]: *** [the_vm] Error 2 > make[6]: *** [product] Error 2 > make[5]: *** [generic_build2] Error 2 > make[4]: *** [product] Error 2 > make[3]: *** [all_product_universal] Error 2 > make[2]: *** [universal_product] Error 2 > make[1]: *** > [/Users/aspluma/projects/openjdk/jdk8/build/macosx-x86_64-normal-server-release/hotspot/_hotspot.timestamp] > Error 2 > make: *** [hotspot-only] Error 2 > > There was discussion about this issue on the OpenJDK Hotspot mailing list, > but apparently the fix has not yet been applied to the code base? > > Also, get_source.sh runs pretty slowly on my laptop (2 cores, 8 GB memory) > taking about 55 minutes to complete. > Is this normal? Any way to speed it up? > > marko From david.dehaven at oracle.com Wed Aug 14 14:52:03 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Wed, 14 Aug 2013 14:52:03 -0700 Subject: Building JDK8 on OS X 10.8.4 In-Reply-To: References: Message-ID: <67A68F2E-51DB-4D4F-8318-DCF8AFBDF8E9@oracle.com> > I'm having trouble building the latest JDK8 version using instructions > found in wiki > (https://wiki.openjdk.java.net/display/MacOSXPort/Main). > > After cloning the repositories when I try to start the build I get the > following error: > > bash-3.2$ CPATH="/usr/X11/include" LANG=C make ALLOW_DOWNLOADS=true > ALT_BOOTDIR=`/usr/libexec/java_home -v 1.7+` That's the old way of building, no longer relevant (see below). > No configurations found for /Users/aspluma/projects/openjdk/jdk8/! Please > run configure to create a configuration. > NewMakefile.gmk:57: *** Cannot continue. Stop. > > Running configure fixes this, but it's not currently mentioned on the wiki > page. The Wiki is outdated, follow the instructions in README-builds.html located in the top level directory. They're up to date for JDK 8. You shouldn't have to do much more than "sh ./configure && make" assuming you have all the prerequisites installed. > Also, get_source.sh runs pretty slowly on my laptop (2 cores, 8 GB memory) > taking about 55 minutes to complete. > Is this normal? Any way to speed it up? Hg can be slow depending on your network and storage speed. This is not unusual for such a large mass of files. -DrD- From paul_t100 at fastmail.fm Thu Aug 15 03:09:57 2013 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Thu, 15 Aug 2013 11:09:57 +0100 Subject: Cannot build with AppBunder and the latest early access release of 1.7.0_40 In-Reply-To: <520BB50A.8040003@fastmail.fm> References: <520BB50A.8040003@fastmail.fm> Message-ID: <520CA8F5.9040007@fastmail.fm> On 14/08/2013 17:49, Paul Taylor wrote: > I just updated from build 1.7.0_40-ea (24.0-b48) to the latest build > 1.7.0_40-ea (24.0-b55) and now when I try to use the fork of > AppBundler at https://bitbucket.org/infinitekind/appbundler its failing > Ive double checked and don't think Im doing anything stupid, has > something significant changed between versions > > /Users/paul/code/jthink/SongKong/build.xml:20: > java.nio.file.NoSuchFileException: /Users/paul/code/jthink/SongKong/MacOS > at > sun.nio.fs.UnixException.translateToIOException(UnixException.java:86) > at > sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102) > at > sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107) > at sun.nio.fs.UnixCopyFile.copy(UnixCopyFile.java:520) > at > sun.nio.fs.UnixFileSystemProvider.copy(UnixFileSystemProvider.java:253) > at java.nio.file.Files.copy(Files.java:1225) > at com.oracle.appbundler.AppBundlerTask.copy(AppBundlerTask.java:712) > at > com.oracle.appbundler.AppBundlerTask.copyRuntime(AppBundlerTask.java:406) > at > com.oracle.appbundler.AppBundlerTask.execute(AppBundlerTask.java:336) > at > org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at > org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) > at org.apache.tools.ant.Task.perform(Task.java:348) > at org.apache.tools.ant.Target.execute(Target.java:392) > at > org.apache.tools.ant.helper.ProjectHelper2.parse(ProjectHelper2.java:180) > at > org.apache.tools.ant.ProjectHelper.configureProject(ProjectHelper.java:82) > at org.apache.tools.ant.Main.runBuild(Main.java:795) > at org.apache.tools.ant.Main.startAnt(Main.java:217) > at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280) > at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109) > > thanks Paul > FYI:I thought I should double check this by downgrading to the earlier build, so i downloaded build29 (which equates to Server VM 24.0.b48) which is not listed but is still available at http://jdk7.java.net/archive/7u40-b29.html and I still get the same error. Eventually I solved the issue I don't remember making any modification to JAVA_HOME but doing export JAVA_HOME=`/usr/libexec/java_home` fixed the issue Paul From dalibor.topic at oracle.com Thu Aug 15 06:06:19 2013 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Thu, 15 Aug 2013 15:06:19 +0200 Subject: Building JDK8 on OS X 10.8.4 In-Reply-To: References: Message-ID: <520CD24B.8020402@oracle.com> On 8/14/13 10:48 PM, Marko Asplund wrote: > After that, the build still fails at a later phase: > > cc1plus: warnings being treated as errors > /Users/aspluma/projects/openjdk/jdk8/hotspot/src/os/bsd/vm/attachListener_bsd.cpp: > In static member function 'static void AttachListener::vm_start()': > /Users/aspluma/projects/openjdk/jdk8/hotspot/src/os/bsd/vm/attachListener_bsd.cpp:455: > warning: 'stat64' is deprecated (declared at /usr/include/sys/stat.h:466) > /Users/aspluma/projects/openjdk/jdk8/hotspot/src/os/bsd/vm/attachListener_bsd.cpp:455: > warning: 'stat64' is deprecated (declared at /usr/include/sys/stat.h:466) > make[8]: *** [attachListener_bsd.o] Error 1 > make[8]: *** Waiting for unfinished jobs.... > make[7]: *** [the_vm] Error 2 > make[6]: *** [product] Error 2 > make[5]: *** [generic_build2] Error 2 > make[4]: *** [product] Error 2 > make[3]: *** [all_product_universal] Error 2 > make[2]: *** [universal_product] Error 2 > make[1]: *** > [/Users/aspluma/projects/openjdk/jdk8/build/macosx-x86_64-normal-server-release/hotspot/_hotspot.timestamp] > Error 2 > make: *** [hotspot-only] Error 2 > > There was discussion about this issue on the OpenJDK Hotspot mailing list, > but apparently the fix has not yet been applied to the code base? That's http://bugs.sun.com/view_bug.do?bug_id=8021771 . The fix has been pushed 7 days ago to hotspot-rt: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/log?rev=8021771 and will take a week or few to propagate to jdk8/jdk8/hotspot. cheers, dalibor topic -- Oracle Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Gesch?ftsf?hrer: J?rgen Kunz Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Green Oracle Oracle is committed to developing practices and products that help protect the environment From daniel.daugherty at oracle.com Thu Aug 15 06:48:33 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 15 Aug 2013 07:48:33 -0600 Subject: Building JDK8 on OS X 10.8.4 In-Reply-To: <520CD24B.8020402@oracle.com> References: <520CD24B.8020402@oracle.com> Message-ID: <520CDC31.6070604@oracle.com> On 8/15/13 7:06 AM, Dalibor Topic wrote: > On 8/14/13 10:48 PM, Marko Asplund wrote: >> After that, the build still fails at a later phase: >> >> cc1plus: warnings being treated as errors >> /Users/aspluma/projects/openjdk/jdk8/hotspot/src/os/bsd/vm/attachListener_bsd.cpp: >> In static member function 'static void AttachListener::vm_start()': >> /Users/aspluma/projects/openjdk/jdk8/hotspot/src/os/bsd/vm/attachListener_bsd.cpp:455: >> warning: 'stat64' is deprecated (declared at /usr/include/sys/stat.h:466) >> /Users/aspluma/projects/openjdk/jdk8/hotspot/src/os/bsd/vm/attachListener_bsd.cpp:455: >> warning: 'stat64' is deprecated (declared at /usr/include/sys/stat.h:466) >> make[8]: *** [attachListener_bsd.o] Error 1 >> make[8]: *** Waiting for unfinished jobs.... >> make[7]: *** [the_vm] Error 2 >> make[6]: *** [product] Error 2 >> make[5]: *** [generic_build2] Error 2 >> make[4]: *** [product] Error 2 >> make[3]: *** [all_product_universal] Error 2 >> make[2]: *** [universal_product] Error 2 >> make[1]: *** >> [/Users/aspluma/projects/openjdk/jdk8/build/macosx-x86_64-normal-server-release/hotspot/_hotspot.timestamp] >> Error 2 >> make: *** [hotspot-only] Error 2 >> >> There was discussion about this issue on the OpenJDK Hotspot mailing list, >> but apparently the fix has not yet been applied to the code base? > That's http://bugs.sun.com/view_bug.do?bug_id=8021771 . The fix has been pushed 7 days ago > to hotspot-rt: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/log?rev=8021771 and will take a week > or few to propagate to jdk8/jdk8/hotspot. > > cheers, > dalibor topic The fix for 8021771 was pushed from hsx/hotspot-rt/hotspot to hsx/hotspot-main/hotspot yesterday. It will be included in the HSX-25-B46 snapshot on Friday (08.16). The snapshot will be PIT tested over the weekend and, if all goes well, the snapshot will be pushed to jdk8/jdk8/hotspot on Tuesday or so next week. Dan From marko.asplund at gmail.com Thu Aug 15 12:10:49 2013 From: marko.asplund at gmail.com (Marko Asplund) Date: Thu, 15 Aug 2013 22:10:49 +0300 Subject: Building JDK8 on OS X 10.8.4 In-Reply-To: <67A68F2E-51DB-4D4F-8318-DCF8AFBDF8E9@oracle.com> References: <67A68F2E-51DB-4D4F-8318-DCF8AFBDF8E9@oracle.com> Message-ID: Hi, Thanks Leonid and David. There were quite a few warnings and some test failures, but I managed to build OpenJDK 8 after adding the WARNINGS_ARE_ERRORS argument to make. Here're some notes and suggestions related to the build process and web site content / documentation from a newbie perspective. For someone new to OpenJDK, the build instructions in the wiki can appear to be a bit confusing: https://wiki.openjdk.java.net/display/MacOSXPort/Main It would be good to mention more explicitly that the instructions on this page apply to JDK 7. Also, there are references to JDK 8 on the page. For example the clone command line seems to be cloning JDK 8 sources. Being new to OpenJDK I found it a bit difficult to actually locate the build instructions on openjdk.java.net. The "build and hack" link looks promising in "Hack on the JDK itself" section, but it's more about NetBeans and doesn't include info or links to resources describing the JDK build process. For an impatient newbie it might be helpful to mention that get_source.sh can take a _very_ long time to execute, as one can start doubting whether the process has hung somehow. Are there any plans for speeding this up in the future? Would it make sense to mention the WARNINGS_ARE_ERRORS argument in README-builds.html somewhere (either general or Mac OS X specific instructions section). marko On 15 August 2013 00:52, David DeHaven wrote: > > > I'm having trouble building the latest JDK8 version using instructions > > found in wiki > > (https://wiki.openjdk.java.net/display/MacOSXPort/Main). > > > > After cloning the repositories when I try to start the build I get the > > following error: > > > > bash-3.2$ CPATH="/usr/X11/include" LANG=C make ALLOW_DOWNLOADS=true > > ALT_BOOTDIR=`/usr/libexec/java_home -v 1.7+` > > That's the old way of building, no longer relevant (see below). > > > > No configurations found for /Users/aspluma/projects/openjdk/jdk8/! Please > > run configure to create a configuration. > > NewMakefile.gmk:57: *** Cannot continue. Stop. > > > > Running configure fixes this, but it's not currently mentioned on the > wiki > > page. > > The Wiki is outdated, follow the instructions in README-builds.html > located in the top level directory. They're up to date for JDK 8. You > shouldn't have to do much more than "sh ./configure && make" assuming you > have all the prerequisites installed. > > > > Also, get_source.sh runs pretty slowly on my laptop (2 cores, 8 GB > memory) > > taking about 55 minutes to complete. > > Is this normal? Any way to speed it up? > > Hg can be slow depending on your network and storage speed. This is not > unusual for such a large mass of files. > > -DrD- > > From david.dehaven at oracle.com Mon Aug 19 19:49:03 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Mon, 19 Aug 2013 19:49:03 -0700 Subject: RFR: 8016096: [macosx] jawt_md.h shipped with jdk is outdated Message-ID: [CC'ing build-dev for comments on the build system changes] Finally took the ten minutes to do this backport of JDK-7181710 for JDK 8. Please review my changeset for JDK-8016096: http://cr.openjdk.java.net/~ddehaven/8016096/jdk.0/ Issue: http://bugs.sun.com/view_bug.do?bug_id=8016096 7u issue (more info): http://bugs.sun.com/view_bug.do?bug_id=7181710 Basically an almost direct backport of the 7u changeset, modified for the new build system (much simpler). I also removed X11 toolkit support as Artem (I think?) mentioned we will not be shipping with an X11 toolkit for JDK 8. I did not touch the old build system as it's slated for removal anyways. Mac build was fine, submitting a JPRT run to ensure other platforms are not affected. I'll need a sponsor for this one too. -DrD- From david.dehaven at oracle.com Mon Aug 19 20:53:15 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Mon, 19 Aug 2013 20:53:15 -0700 Subject: RFR: 8016096: [macosx] jawt_md.h shipped with jdk is outdated In-Reply-To: References: Message-ID: <7B578D9B-98BA-4904-9A7D-C402C9711321@oracle.com> > [CC'ing build-dev for comments on the build system changes] > > > Finally took the ten minutes to do this backport of JDK-7181710 for JDK 8. > > Please review my changeset for JDK-8016096: > http://cr.openjdk.java.net/~ddehaven/8016096/jdk.0/ Oops, I missed a few files in that changeset, namely the updates to AWT source that still used JavaVM headers. Will update when done testing. -DrD- From david.dehaven at oracle.com Tue Aug 20 19:18:31 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 20 Aug 2013 19:18:31 -0700 Subject: [Withdrawn] Re: RFR: 8016096: [macosx] jawt_md.h shipped with jdk is outdated In-Reply-To: <7B578D9B-98BA-4904-9A7D-C402C9711321@oracle.com> References: <7B578D9B-98BA-4904-9A7D-C402C9711321@oracle.com> Message-ID: <3DE3A5EB-9392-481A-96A9-AFE03CD791FD@oracle.com> >> [CC'ing build-dev for comments on the build system changes] >> >> >> Finally took the ten minutes to do this backport of JDK-7181710 for JDK 8. >> >> Please review my changeset for JDK-8016096: >> http://cr.openjdk.java.net/~ddehaven/8016096/jdk.0/ > > Oops, I missed a few files in that changeset, namely the updates to AWT source that still used JavaVM headers. Will update when done testing. > > -DrD- I'm withdrawing this request for the moment. I think JDK-8003900 (X11 toolkit should be removed from Mac OS build) needs to be done first, which I'm working on now. I may revise that decision as I progress but for now that's the plan. -DrD- From alexandr.scherbatiy at oracle.com Thu Aug 22 07:28:14 2013 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 22 Aug 2013 18:28:14 +0400 Subject: [8] Review request for 8022401 [macosx] javax/swing/text/JTextComponent/5074573/bug5074573.java fails Message-ID: <52161FFE.8050402@oracle.com> Hello, Could you review the fix: bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8022401 webrev: http://cr.openjdk.java.net/~alexsch/8022401/webrev.00 The nsToJavaChar method from AWTEvent.m has char type (1 byte) for the nsChar parameter instead of jchar. Thanks, Alexandr. From anthony.petrov at oracle.com Fri Aug 23 03:19:58 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 23 Aug 2013 14:19:58 +0400 Subject: [8] Review request for 8022401 [macosx] javax/swing/text/JTextComponent/5074573/bug5074573.java fails In-Reply-To: <52161FFE.8050402@oracle.com> References: <52161FFE.8050402@oracle.com> Message-ID: <5217374E.7020502@oracle.com> Hi Alexander, The fix looks fine to me. However, please correct the year in the copyright notice in the test before pushing your fix, since currently it lists 2011 instead of 2013. -- best regards, Anthony On 08/22/2013 06:28 PM, Alexander Scherbatiy wrote: > > Hello, > > Could you review the fix: > bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8022401 > webrev: http://cr.openjdk.java.net/~alexsch/8022401/webrev.00 > > The nsToJavaChar method from AWTEvent.m has char type (1 byte) for the > nsChar parameter instead of jchar. > > Thanks, > Alexandr. > From jost0x2c at gmail.com Wed Aug 28 02:23:32 2013 From: jost0x2c at gmail.com (jost) Date: Wed, 28 Aug 2013 11:23:32 +0200 Subject: Fullscreen button freezes application when started with -splash Message-ID: Hi, this can easily be reproduced by 1. Creating a simple hello world app like http://docs.oracle.com/javase/tutorial/uiswing/examples/start/HelloWorldSwingProject/src/start/HelloWorldSwing.java 2. Adding the fullscreen button via com.apple.eawt.FullScreenUtilities.setWindowCanFullScreen(Window, boolean) Now, when the application is started without -splash, the frame correctly animates into fullscreen state after clicking the fullscreen button. Doing the same with -splash specified on the command line renders the application completely unresponsive. I tried against jdk8 b103. I think this might be related to http://bugs.sun.com/view_bug.do?bug_id=8006420, maybe someone could comment if I should file a separate bug or if it should be added to 8006420. --jost From anthony.petrov at oracle.com Wed Aug 28 03:44:40 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 28 Aug 2013 14:44:40 +0400 Subject: Fullscreen button freezes application when started with -splash In-Reply-To: References: Message-ID: <521DD498.1030008@oracle.com> Hi jost, This issue might or might not be related to the bug that you mention. So I suggest you to file a new bug at http://bugs.sun.com/ anyway. -- best regards, Anthony On 08/28/2013 01:23 PM, jost wrote: > Hi, > > this can easily be reproduced by > > 1. Creating a simple hello world app like > http://docs.oracle.com/javase/tutorial/uiswing/examples/start/HelloWorldSwingProject/src/start/HelloWorldSwing.java > 2. Adding the fullscreen button via > com.apple.eawt.FullScreenUtilities.setWindowCanFullScreen(Window, boolean) > > Now, when the application is started without -splash, the frame correctly > animates into fullscreen state after clicking the fullscreen button. Doing > the same with -splash specified on the command line renders the application > completely unresponsive. I tried against jdk8 b103. > > I think this might be related to > http://bugs.sun.com/view_bug.do?bug_id=8006420, maybe someone could comment > if I should file a separate bug or if it should be added to 8006420. > > --jost > From jost0x2c at gmail.com Wed Aug 28 05:15:48 2013 From: jost0x2c at gmail.com (jost) Date: Wed, 28 Aug 2013 14:15:48 +0200 Subject: Fullscreen button freezes application when started with -splash In-Reply-To: <521DD498.1030008@oracle.com> References: <521DD498.1030008@oracle.com> Message-ID: Filed under Bug Id: 9006309 On Wed, Aug 28, 2013 at 12:44 PM, Anthony Petrov wrote: > Hi jost, > > This issue might or might not be related to the bug that you mention. So I > suggest you to file a new bug at http://bugs.sun.com/ anyway. > > -- > best regards, > Anthony > > > On 08/28/2013 01:23 PM, jost wrote: > >> Hi, >> >> this can easily be reproduced by >> >> 1. Creating a simple hello world app like >> http://docs.oracle.com/javase/**tutorial/uiswing/examples/** >> start/HelloWorldSwingProject/**src/start/HelloWorldSwing.java >> 2. Adding the fullscreen button via >> com.apple.eawt.**FullScreenUtilities.**setWindowCanFullScreen(Window, >> boolean) >> >> Now, when the application is started without -splash, the frame correctly >> animates into fullscreen state after clicking the fullscreen button. Doing >> the same with -splash specified on the command line renders the >> application >> completely unresponsive. I tried against jdk8 b103. >> >> I think this might be related to >> http://bugs.sun.com/view_bug.**do?bug_id=8006420, >> maybe someone could comment >> if I should file a separate bug or if it should be added to 8006420. >> >> --jost >> >> From andrewbass at gmail.com Fri Aug 30 23:30:42 2013 From: andrewbass at gmail.com (Andrew ``Bass'' Shcheglov) Date: Sat, 31 Aug 2013 10:30:42 +0400 Subject: Building JDK7 on OS X 10.6.8 Message-ID: <52218D92.7090502@gmail.com> Hello, I've created a patch which enables building OpenJDK 1.7 on Mac OS X 10.6.8. So far, I've got AWT and JFC/Swing applications successfully running on Snow Leopard. The patch is currently available here: . The original discussion is here: . 4 Objective-C files are affected: * in sun/awt/AWTView.m, 10.7+ code is simply reimplemented with 10.6-only API * in sun/awt/CGraphicsDevice.m, 10.7+ code is simply stripped out: as far as I understand, it's not that important. * in sun/java2d/opengl/CGLLayer.m, an UnsupportedOperationException is thrown from the native code. I have no idea what the correct 10.6 replacement should be. * finally, sun/osxapp/ThreadUtilities.h features a minor 10.6-specific correction. The decision of which code branch to include at compile time is based on the __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ preprocessor macro. I'm asking Objective-C experts who read this list to review the patch and propose any corrections/enhancements. Any feedback is appreciated. Also, once the patch looks good to you, would it be possible to merge it into the main code tree? Regards, Andrew. From swingler at apple.com Sat Aug 31 11:00:34 2013 From: swingler at apple.com (Mike Swingler) Date: Sat, 31 Aug 2013 20:00:34 +0200 Subject: Building JDK7 on OS X 10.6.8 In-Reply-To: <52218D92.7090502@gmail.com> References: <52218D92.7090502@gmail.com> Message-ID: On Aug 31, 2013, at 8:30 AM, Andrew ``Bass'' Shcheglov wrote: > Hello, > > I've created a patch which enables building OpenJDK 1.7 on Mac OS X > 10.6.8. So far, I've got AWT and JFC/Swing applications successfully > running on Snow Leopard. The patch is currently available here: > . > > The original discussion is here: > . > > 4 Objective-C files are affected: > > * in sun/awt/AWTView.m, 10.7+ code is simply reimplemented with > 10.6-only API Probably not important on 10.6, since it does not support HiDPI/Retina. > * in sun/awt/CGraphicsDevice.m, 10.7+ code is simply stripped out: as > far as I understand, it's not that important. This breaks full screen which takes over the whole display and resets it in a specific mode. Might not be a big deal to you. > * in sun/java2d/opengl/CGLLayer.m, an UnsupportedOperationException is > thrown from the native code. I have no idea what the correct 10.6 > replacement should be. Doesn't matter, because 10.6 doesn't support HiDPI/Retina. > * finally, sun/osxapp/ThreadUtilities.h features a minor 10.6-specific > correction. A fine correction. > The decision of which code branch to include at compile time is based on > the __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ preprocessor macro. > > I'm asking Objective-C experts who read this list to review the patch > and propose any corrections/enhancements. Any feedback is appreciated. > > Also, once the patch looks good to you, would it be possible to merge it > into the main code tree? These changes on their own, do not appear to damage the OpenJDK that is built on 10.7 or higher. However, an OpenJDK build on 10.6 would not be acceptable for including in a product that is expected to run on 10.7 or higher, since it would be missing these code chunks that were excised. If these changes are accepted, there is no guarantee that future development work (in OpenJDK 8 and beyond) will not require additional workarounds. Regards, Mike Swingler Apple Inc.