From david.holmes at oracle.com Mon Jan 12 11:26:37 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 12 Jan 2015 21:26:37 +1000 Subject: De-universalizing hotspot in jdk8u In-Reply-To: <54B3A4D0.3080604@oracle.com> References: <54B300FE.2000804@oracle.com> <54B3A4D0.3080604@oracle.com> Message-ID: <54B3AF6D.20607@oracle.com> cc'ing macosx-port-dev and hotspot-dev On 12/01/2015 8:41 PM, Erik Joelsson wrote: > > On 2015-01-12 00:02, David Holmes wrote: >> Hi David, >> >> On 10/01/2015 2:00 AM, David DeHaven wrote: >>> >>> We have this nice little comment in common/autoconf/jdk-options.m4: >>> # On Macosx universal binaries are produced, but they only contain >>> # 64 bit intel. This invalidates control of which jvms are built >>> # from configure, but only server is valid anyway. Fix this >>> # when hotspot makefiles are rewritten. >>> if test "x$MACOSX_UNIVERSAL" = xtrue; then >>> HOTSPOT_TARGET=universal_${HOTSPOT_EXPORT} >>> fi >>> >>> >>> So.. I turned it off: >>> if test "x$OPENJDK_TARGET_OS" = "xmacosx"; then >>> # MACOSX_UNIVERSAL="true" >>> MACOSX_UNIVERSAL="false" >>> fi >>> >>> And in hotspot/make/bsd/makefiles/defs.make: >>> # Universal build settings >>> ifeq ($(OS_VENDOR), Darwin) >>> # Build universal binaries by default on Mac OS X >>> # MACOSX_UNIVERSAL = true >>> MACOSX_UNIVERSAL = false >>> ifneq ($(ALT_MACOSX_UNIVERSAL),) >>> >>> hotspot still seems to build happily (I'm kicking off tests now). Is >>> there are particular reason this hasn't been done yet? I'd like to >>> know before I pursue this as a means of eliminating our dependency on >>> lipo which is causing an inordinate amount of grief when trying to >>> build on 10.9 and later when Xcode 5+ is coinstalled. I have some >>> logic to work around using the broken /usr/bin/lipo, but it doesn't >>> help later in some "other" build target that ends up using '-arch >>> i386 -arch x86_64'. It does not explicitly run lipo, it relies on gcc >>> to do the fattening itself and so it fails even though I've gone to >>> the effort of working around the broken lipo (and it isn't necessary >>> anyways because it doesn't even build the i386 binaries even though >>> it's supposed to be "universal"). >> >> The hotspot makefiles still haven't been rewritten (though Magnus had >> been working on it). >> >> Also I was under the impression that we used the universal stuff >> because we had to deliver in a particular way on OSX. But I don't know >> the details and the people who dealt with the original OSX port effort >> are no longer here. >> > I don't know why Hotspot is packaged as a universal binary. In the jdk, > only libJObjC was built as a universal binary and that lib was removed > before JDK 8 shipped. What part of Macosx would need to interact > directly with libjvm.dylib in a way that required a (fake) universal > format, but no other libs in the jdk? I would say go ahead and change it. In the spirit of "never take down a fence until you know why it was put up in the first place" I've cc'd macosx-port-dev to see if there is anyone around who recalls why hotspot is using the universal binary feature. David H. ------- > /Erik > >> David H. >> >>> >>> Quite frankly I'd rather just remove all the universal binary stuff >>> from hotspot, but I'm trying my best to minimize the changes there... >>> the "other" problem I can handle easily. >>> >>> -DrD- >>> > From david.dehaven at oracle.com Mon Jan 12 15:17:30 2015 From: david.dehaven at oracle.com (David DeHaven) Date: Mon, 12 Jan 2015 07:17:30 -0800 Subject: De-universalizing hotspot in jdk8u In-Reply-To: <54B3AF6D.20607@oracle.com> References: <54B300FE.2000804@oracle.com> <54B3A4D0.3080604@oracle.com> <54B3AF6D.20607@oracle.com> Message-ID: <825EBFC2-6DE1-4550-842B-217C06532C9B@oracle.com> >>>> We have this nice little comment in common/autoconf/jdk-options.m4: >>>> # On Macosx universal binaries are produced, but they only contain >>>> # 64 bit intel. This invalidates control of which jvms are built >>>> # from configure, but only server is valid anyway. Fix this >>>> # when hotspot makefiles are rewritten. >>>> if test "x$MACOSX_UNIVERSAL" = xtrue; then >>>> HOTSPOT_TARGET=universal_${HOTSPOT_EXPORT} >>>> fi >>>> >>>> >>>> So.. I turned it off: >>>> if test "x$OPENJDK_TARGET_OS" = "xmacosx"; then >>>> # MACOSX_UNIVERSAL="true" >>>> MACOSX_UNIVERSAL="false" >>>> fi >>>> >>>> And in hotspot/make/bsd/makefiles/defs.make: >>>> # Universal build settings >>>> ifeq ($(OS_VENDOR), Darwin) >>>> # Build universal binaries by default on Mac OS X >>>> # MACOSX_UNIVERSAL = true >>>> MACOSX_UNIVERSAL = false >>>> ifneq ($(ALT_MACOSX_UNIVERSAL),) >>>> >>>> hotspot still seems to build happily (I'm kicking off tests now). Is >>>> there are particular reason this hasn't been done yet? I'd like to >>>> know before I pursue this as a means of eliminating our dependency on >>>> lipo which is causing an inordinate amount of grief when trying to >>>> build on 10.9 and later when Xcode 5+ is coinstalled. I have some >>>> logic to work around using the broken /usr/bin/lipo, but it doesn't >>>> help later in some "other" build target that ends up using '-arch >>>> i386 -arch x86_64'. It does not explicitly run lipo, it relies on gcc >>>> to do the fattening itself and so it fails even though I've gone to >>>> the effort of working around the broken lipo (and it isn't necessary >>>> anyways because it doesn't even build the i386 binaries even though >>>> it's supposed to be "universal"). >>> >>> The hotspot makefiles still haven't been rewritten (though Magnus had >>> been working on it). >>> >>> Also I was under the impression that we used the universal stuff >>> because we had to deliver in a particular way on OSX. But I don't know >>> the details and the people who dealt with the original OSX port effort >>> are no longer here. >>> >> I don't know why Hotspot is packaged as a universal binary. In the jdk, >> only libJObjC was built as a universal binary and that lib was removed >> before JDK 8 shipped. What part of Macosx would need to interact >> directly with libjvm.dylib in a way that required a (fake) universal >> format, but no other libs in the jdk? I would say go ahead and change it. > > In the spirit of "never take down a fence until you know why it was put up in the first place" I've cc'd macosx-port-dev to see if there is anyone around who recalls why hotspot is using the universal binary feature. I hear you. My best guess is we'd initially planned on supporting 32 bit but (???) and the easiest way to deliver is in a universal binary. Note that we don't actually deliver universal binaries as the JVM is 64 bit only, or at least there are not nearly enough components there to run a full 32 bit JVM. -DrD- From daniel.daugherty at oracle.com Mon Jan 12 18:54:55 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 12 Jan 2015 11:54:55 -0700 Subject: De-universalizing hotspot in jdk8u In-Reply-To: <825EBFC2-6DE1-4550-842B-217C06532C9B@oracle.com> References: <54B300FE.2000804@oracle.com> <54B3A4D0.3080604@oracle.com> <54B3AF6D.20607@oracle.com> <825EBFC2-6DE1-4550-842B-217C06532C9B@oracle.com> Message-ID: <54B4187F.5060608@oracle.com> On 1/12/15 8:17 AM, David DeHaven wrote: >>>>> We have this nice little comment in common/autoconf/jdk-options.m4: >>>>> # On Macosx universal binaries are produced, but they only contain >>>>> # 64 bit intel. This invalidates control of which jvms are built >>>>> # from configure, but only server is valid anyway. Fix this >>>>> # when hotspot makefiles are rewritten. >>>>> if test "x$MACOSX_UNIVERSAL" = xtrue; then >>>>> HOTSPOT_TARGET=universal_${HOTSPOT_EXPORT} >>>>> fi >>>>> >>>>> >>>>> So.. I turned it off: >>>>> if test "x$OPENJDK_TARGET_OS" = "xmacosx"; then >>>>> # MACOSX_UNIVERSAL="true" >>>>> MACOSX_UNIVERSAL="false" >>>>> fi >>>>> >>>>> And in hotspot/make/bsd/makefiles/defs.make: >>>>> # Universal build settings >>>>> ifeq ($(OS_VENDOR), Darwin) >>>>> # Build universal binaries by default on Mac OS X >>>>> # MACOSX_UNIVERSAL = true >>>>> MACOSX_UNIVERSAL = false >>>>> ifneq ($(ALT_MACOSX_UNIVERSAL),) >>>>> >>>>> hotspot still seems to build happily (I'm kicking off tests now). Is >>>>> there are particular reason this hasn't been done yet? I'd like to >>>>> know before I pursue this as a means of eliminating our dependency on >>>>> lipo which is causing an inordinate amount of grief when trying to >>>>> build on 10.9 and later when Xcode 5+ is coinstalled. I have some >>>>> logic to work around using the broken /usr/bin/lipo, but it doesn't >>>>> help later in some "other" build target that ends up using '-arch >>>>> i386 -arch x86_64'. It does not explicitly run lipo, it relies on gcc >>>>> to do the fattening itself and so it fails even though I've gone to >>>>> the effort of working around the broken lipo (and it isn't necessary >>>>> anyways because it doesn't even build the i386 binaries even though >>>>> it's supposed to be "universal"). >>>> The hotspot makefiles still haven't been rewritten (though Magnus had >>>> been working on it). >>>> >>>> Also I was under the impression that we used the universal stuff >>>> because we had to deliver in a particular way on OSX. But I don't know >>>> the details and the people who dealt with the original OSX port effort >>>> are no longer here. >>>> >>> I don't know why Hotspot is packaged as a universal binary. In the jdk, >>> only libJObjC was built as a universal binary and that lib was removed >>> before JDK 8 shipped. What part of Macosx would need to interact >>> directly with libjvm.dylib in a way that required a (fake) universal >>> format, but no other libs in the jdk? I would say go ahead and change it. >> In the spirit of "never take down a fence until you know why it was put up in the first place" I've cc'd macosx-port-dev to see if there is anyone around who recalls why hotspot is using the universal binary feature. > I hear you. > > My best guess is we'd initially planned on supporting 32 bit but (???) and the easiest way to deliver is in a universal binary. Note that we don't actually deliver universal binaries as the JVM is 64 bit only, or at least there are not nearly enough components there to run a full 32 bit JVM. > > -DrD- We (Jim Melvin did the work) included universal support in HotSpot to not preclude someone else from doing the 32-bit MacOS X port and providing it via OpenJDK channels. The rest of the JDK did not include universal support, but the hotspot code would have served as an example way forward... However, we never heard from anyone willing to do the 32-bit port... Dan From david.dehaven at oracle.com Mon Jan 12 19:06:30 2015 From: david.dehaven at oracle.com (David DeHaven) Date: Mon, 12 Jan 2015 11:06:30 -0800 Subject: De-universalizing hotspot in jdk8u In-Reply-To: <54B4187F.5060608@oracle.com> References: <54B300FE.2000804@oracle.com> <54B3A4D0.3080604@oracle.com> <54B3AF6D.20607@oracle.com> <825EBFC2-6DE1-4550-842B-217C06532C9B@oracle.com> <54B4187F.5060608@oracle.com> Message-ID: >>>> I don't know why Hotspot is packaged as a universal binary. In the jdk, >>>> only libJObjC was built as a universal binary and that lib was removed >>>> before JDK 8 shipped. What part of Macosx would need to interact >>>> directly with libjvm.dylib in a way that required a (fake) universal >>>> format, but no other libs in the jdk? I would say go ahead and change it. >>> In the spirit of "never take down a fence until you know why it was put up in the first place" I've cc'd macosx-port-dev to see if there is anyone around who recalls why hotspot is using the universal binary feature. >> I hear you. >> >> My best guess is we'd initially planned on supporting 32 bit but (???) and the easiest way to deliver is in a universal binary. Note that we don't actually deliver universal binaries as the JVM is 64 bit only, or at least there are not nearly enough components there to run a full 32 bit JVM. > > We (Jim Melvin did the work) included universal support in HotSpot > to not preclude someone else from doing the 32-bit MacOS X port and > providing it via OpenJDK channels. The rest of the JDK did not > include universal support, but the hotspot code would have served > as an example way forward... > > However, we never heard from anyone willing to do the 32-bit port... Thanks for the explanation Daniel. I'm preserving what's there in the same spirit, but turning off universal by default since it's unnecessary. It sounds to me like this is the correct approach. -DrD- From astrange at apple.com Mon Jan 12 19:20:09 2015 From: astrange at apple.com (Alex Strange) Date: Mon, 12 Jan 2015 11:20:09 -0800 Subject: De-universalizing hotspot in jdk8u In-Reply-To: <54B3AF6D.20607@oracle.com> References: <54B300FE.2000804@oracle.com> <54B3A4D0.3080604@oracle.com> <54B3AF6D.20607@oracle.com> Message-ID: <9B1E95A7-8496-4E59-9B00-FCC1F4B780FA@apple.com> > On Jan 12, 2015, at 3:26 AM, David Holmes wrote: > > cc'ing macosx-port-dev and hotspot-dev > > On 12/01/2015 8:41 PM, Erik Joelsson wrote: >> >> On 2015-01-12 00:02, David Holmes wrote: >>> Hi David, >>> >>> On 10/01/2015 2:00 AM, David DeHaven wrote: >>>> >>>> We have this nice little comment in common/autoconf/jdk-options.m4: >>>> # On Macosx universal binaries are produced, but they only contain >>>> # 64 bit intel. This invalidates control of which jvms are built >>>> # from configure, but only server is valid anyway. Fix this >>>> # when hotspot makefiles are rewritten. >>>> if test "x$MACOSX_UNIVERSAL" = xtrue; then >>>> HOTSPOT_TARGET=universal_${HOTSPOT_EXPORT} >>>> fi >>>> >>>> >>>> So.. I turned it off: >>>> if test "x$OPENJDK_TARGET_OS" = "xmacosx"; then >>>> # MACOSX_UNIVERSAL="true" >>>> MACOSX_UNIVERSAL="false" >>>> fi >>>> >>>> And in hotspot/make/bsd/makefiles/defs.make: >>>> # Universal build settings >>>> ifeq ($(OS_VENDOR), Darwin) >>>> # Build universal binaries by default on Mac OS X >>>> # MACOSX_UNIVERSAL = true >>>> MACOSX_UNIVERSAL = false >>>> ifneq ($(ALT_MACOSX_UNIVERSAL),) >>>> >>>> hotspot still seems to build happily (I'm kicking off tests now). Is >>>> there are particular reason this hasn't been done yet? I'd like to >>>> know before I pursue this as a means of eliminating our dependency on >>>> lipo which is causing an inordinate amount of grief when trying to >>>> build on 10.9 and later when Xcode 5+ is coinstalled. I have some >>>> logic to work around using the broken /usr/bin/lipo, but it doesn't >>>> help later in some "other" build target that ends up using '-arch >>>> i386 -arch x86_64'. It does not explicitly run lipo, it relies on gcc >>>> to do the fattening itself and so it fails even though I've gone to >>>> the effort of working around the broken lipo (and it isn't necessary >>>> anyways because it doesn't even build the i386 binaries even though >>>> it's supposed to be "universal"). >>> >>> The hotspot makefiles still haven't been rewritten (though Magnus had >>> been working on it). >>> >>> Also I was under the impression that we used the universal stuff >>> because we had to deliver in a particular way on OSX. But I don't know >>> the details and the people who dealt with the original OSX port effort >>> are no longer here. >>> >> I don't know why Hotspot is packaged as a universal binary. In the jdk, >> only libJObjC was built as a universal binary and that lib was removed >> before JDK 8 shipped. What part of Macosx would need to interact >> directly with libjvm.dylib in a way that required a (fake) universal >> format, but no other libs in the jdk? I would say go ahead and change it. > > In the spirit of "never take down a fence until you know why it was put up in the first place" I've cc'd macosx-port-dev to see if there is anyone around who recalls why hotspot is using the universal binary feature. > > David H. > ------- I did the original universal binary work for hotspot when bringing up macosx-port. At the time we were building and testing JDK 7 as universal (i386+x86-64) since e.g. some apps had JNI code that was only built 32-bit. The other jdk components didn't need any makefile work, because the compiler can build them universal by itself, but hotspot autogenerates a lot of arch-specific code and it was easier to build it twice and glue them together in the makefile. As long as Java is only been shipped 64-bit these days, I personally don't see a reason to keep it. > /Erik >> >>> David H. >>> >>>> >>>> Quite frankly I'd rather just remove all the universal binary stuff >>>> from hotspot, but I'm trying my best to minimize the changes there... >>>> the "other" problem I can handle easily. >>>> >>>> -DrD- >>>> >> From david.holmes at oracle.com Tue Jan 13 01:40:33 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 13 Jan 2015 11:40:33 +1000 Subject: De-universalizing hotspot in jdk8u In-Reply-To: <9B1E95A7-8496-4E59-9B00-FCC1F4B780FA@apple.com> References: <54B300FE.2000804@oracle.com> <54B3A4D0.3080604@oracle.com> <54B3AF6D.20607@oracle.com> <9B1E95A7-8496-4E59-9B00-FCC1F4B780FA@apple.com> Message-ID: <54B47791.2040301@oracle.com> On 13/01/2015 5:20 AM, Alex Strange wrote: > >> On Jan 12, 2015, at 3:26 AM, David Holmes wrote: >> >> cc'ing macosx-port-dev and hotspot-dev >> >> On 12/01/2015 8:41 PM, Erik Joelsson wrote: >>> >>> On 2015-01-12 00:02, David Holmes wrote: >>>> Hi David, >>>> >>>> On 10/01/2015 2:00 AM, David DeHaven wrote: >>>>> >>>>> We have this nice little comment in common/autoconf/jdk-options.m4: >>>>> # On Macosx universal binaries are produced, but they only contain >>>>> # 64 bit intel. This invalidates control of which jvms are built >>>>> # from configure, but only server is valid anyway. Fix this >>>>> # when hotspot makefiles are rewritten. >>>>> if test "x$MACOSX_UNIVERSAL" = xtrue; then >>>>> HOTSPOT_TARGET=universal_${HOTSPOT_EXPORT} >>>>> fi >>>>> >>>>> >>>>> So.. I turned it off: >>>>> if test "x$OPENJDK_TARGET_OS" = "xmacosx"; then >>>>> # MACOSX_UNIVERSAL="true" >>>>> MACOSX_UNIVERSAL="false" >>>>> fi >>>>> >>>>> And in hotspot/make/bsd/makefiles/defs.make: >>>>> # Universal build settings >>>>> ifeq ($(OS_VENDOR), Darwin) >>>>> # Build universal binaries by default on Mac OS X >>>>> # MACOSX_UNIVERSAL = true >>>>> MACOSX_UNIVERSAL = false >>>>> ifneq ($(ALT_MACOSX_UNIVERSAL),) >>>>> >>>>> hotspot still seems to build happily (I'm kicking off tests now). Is >>>>> there are particular reason this hasn't been done yet? I'd like to >>>>> know before I pursue this as a means of eliminating our dependency on >>>>> lipo which is causing an inordinate amount of grief when trying to >>>>> build on 10.9 and later when Xcode 5+ is coinstalled. I have some >>>>> logic to work around using the broken /usr/bin/lipo, but it doesn't >>>>> help later in some "other" build target that ends up using '-arch >>>>> i386 -arch x86_64'. It does not explicitly run lipo, it relies on gcc >>>>> to do the fattening itself and so it fails even though I've gone to >>>>> the effort of working around the broken lipo (and it isn't necessary >>>>> anyways because it doesn't even build the i386 binaries even though >>>>> it's supposed to be "universal"). >>>> >>>> The hotspot makefiles still haven't been rewritten (though Magnus had >>>> been working on it). >>>> >>>> Also I was under the impression that we used the universal stuff >>>> because we had to deliver in a particular way on OSX. But I don't know >>>> the details and the people who dealt with the original OSX port effort >>>> are no longer here. >>>> >>> I don't know why Hotspot is packaged as a universal binary. In the jdk, >>> only libJObjC was built as a universal binary and that lib was removed >>> before JDK 8 shipped. What part of Macosx would need to interact >>> directly with libjvm.dylib in a way that required a (fake) universal >>> format, but no other libs in the jdk? I would say go ahead and change it. >> >> In the spirit of "never take down a fence until you know why it was put up in the first place" I've cc'd macosx-port-dev to see if there is anyone around who recalls why hotspot is using the universal binary feature. >> >> David H. >> ------- > > I did the original universal binary work for hotspot when bringing up macosx-port. > > At the time we were building and testing JDK 7 as universal (i386+x86-64) since e.g. some apps had JNI code that was only built 32-bit. > The other jdk components didn't need any makefile work, because the compiler can build them universal by itself, but hotspot autogenerates a lot of arch-specific code and it was easier to build it twice and glue them together in the makefile. > > As long as Java is only been shipped 64-bit these days, I personally don't see a reason to keep it. Thanks for the info Alex. Based on that and Dan's response this proposed change seems good to go ahead. David H. > >> /Erik >>> >>>> David H. >>>> >>>>> >>>>> Quite frankly I'd rather just remove all the universal binary stuff >>>>> from hotspot, but I'm trying my best to minimize the changes there... >>>>> the "other" problem I can handle easily. >>>>> >>>>> -DrD- >>>>> >>> > From pslack at wavedna.com Thu Jan 15 15:15:37 2015 From: pslack at wavedna.com (Peter J Slack) Date: Thu, 15 Jan 2015 10:15:37 -0500 Subject: De-universalizing hotspot in jdk8u In-Reply-To: <54B47791.2040301@oracle.com> References: <54B300FE.2000804@oracle.com> <54B3A4D0.3080604@oracle.com> <54B3AF6D.20607@oracle.com> <9B1E95A7-8496-4E59-9B00-FCC1F4B780FA@apple.com> <54B47791.2040301@oracle.com> Message-ID: Apologies in advance, I felt necessary to send up some smoke signals on this 32 bit feature decision. I am grateful for this hard working and diligent Java community and for Java itself, I'm a staunch Java supporter and long time Java programmer. If one considers marketing and product placement of Java, the removal of 32 bit Java for Mac OSX creates a perceived limitation of a platform that is supposed to be write once, run anywhere, and a real limitation for developers who rely on the Java platform to integrate with libraries that are used in other applications. The removal of a 32 bit option seems to be counter culture to the Java community and "write once, run anywhere" brand. Java 1.9 is the only version that works properly for us on Mac OSX at the moment, the migration of 32 bit Java to legacy has been a sales killer for our little company, so these types of decisions are never without any consequences. Instead of designing killer apps Mac OSX using Java, I have to write installer code and spend time helping upset customers navigate through these moving goal posts. Whew!! .. OK rant complete the smoke is starting to clear and we will make it through this ;-) PJ On Mon, Jan 12, 2015 at 8:40 PM, David Holmes wrote: > On 13/01/2015 5:20 AM, Alex Strange wrote: > >> >> On Jan 12, 2015, at 3:26 AM, David Holmes >>> wrote: >>> >>> cc'ing macosx-port-dev and hotspot-dev >>> >>> On 12/01/2015 8:41 PM, Erik Joelsson wrote: >>> >>>> >>>> On 2015-01-12 00:02, David Holmes wrote: >>>> >>>>> Hi David, >>>>> >>>>> On 10/01/2015 2:00 AM, David DeHaven wrote: >>>>> >>>>>> >>>>>> We have this nice little comment in common/autoconf/jdk-options.m4: >>>>>> # On Macosx universal binaries are produced, but they only contain >>>>>> # 64 bit intel. This invalidates control of which jvms are built >>>>>> # from configure, but only server is valid anyway. Fix this >>>>>> # when hotspot makefiles are rewritten. >>>>>> if test "x$MACOSX_UNIVERSAL" = xtrue; then >>>>>> HOTSPOT_TARGET=universal_${HOTSPOT_EXPORT} >>>>>> fi >>>>>> >>>>>> >>>>>> So.. I turned it off: >>>>>> if test "x$OPENJDK_TARGET_OS" = "xmacosx"; then >>>>>> # MACOSX_UNIVERSAL="true" >>>>>> MACOSX_UNIVERSAL="false" >>>>>> fi >>>>>> >>>>>> And in hotspot/make/bsd/makefiles/defs.make: >>>>>> # Universal build settings >>>>>> ifeq ($(OS_VENDOR), Darwin) >>>>>> # Build universal binaries by default on Mac OS X >>>>>> # MACOSX_UNIVERSAL = true >>>>>> MACOSX_UNIVERSAL = false >>>>>> ifneq ($(ALT_MACOSX_UNIVERSAL),) >>>>>> >>>>>> hotspot still seems to build happily (I'm kicking off tests now). Is >>>>>> there are particular reason this hasn't been done yet? I'd like to >>>>>> know before I pursue this as a means of eliminating our dependency on >>>>>> lipo which is causing an inordinate amount of grief when trying to >>>>>> build on 10.9 and later when Xcode 5+ is coinstalled. I have some >>>>>> logic to work around using the broken /usr/bin/lipo, but it doesn't >>>>>> help later in some "other" build target that ends up using '-arch >>>>>> i386 -arch x86_64'. It does not explicitly run lipo, it relies on gcc >>>>>> to do the fattening itself and so it fails even though I've gone to >>>>>> the effort of working around the broken lipo (and it isn't necessary >>>>>> anyways because it doesn't even build the i386 binaries even though >>>>>> it's supposed to be "universal"). >>>>>> >>>>> >>>>> The hotspot makefiles still haven't been rewritten (though Magnus had >>>>> been working on it). >>>>> >>>>> Also I was under the impression that we used the universal stuff >>>>> because we had to deliver in a particular way on OSX. But I don't know >>>>> the details and the people who dealt with the original OSX port effort >>>>> are no longer here. >>>>> >>>>> I don't know why Hotspot is packaged as a universal binary. In the >>>> jdk, >>>> only libJObjC was built as a universal binary and that lib was removed >>>> before JDK 8 shipped. What part of Macosx would need to interact >>>> directly with libjvm.dylib in a way that required a (fake) universal >>>> format, but no other libs in the jdk? I would say go ahead and change >>>> it. >>>> >>> >>> In the spirit of "never take down a fence until you know why it was put >>> up in the first place" I've cc'd macosx-port-dev to see if there is anyone >>> around who recalls why hotspot is using the universal binary feature. >>> >>> David H. >>> ------- >>> >> >> I did the original universal binary work for hotspot when bringing up >> macosx-port. >> >> At the time we were building and testing JDK 7 as universal (i386+x86-64) >> since e.g. some apps had JNI code that was only built 32-bit. >> The other jdk components didn't need any makefile work, because the >> compiler can build them universal by itself, but hotspot autogenerates a >> lot of arch-specific code and it was easier to build it twice and glue them >> together in the makefile. >> >> As long as Java is only been shipped 64-bit these days, I personally >> don't see a reason to keep it. >> > > Thanks for the info Alex. Based on that and Dan's response this proposed > change seems good to go ahead. > > David H. > > > >> /Erik >>> >>>> >>>> David H. >>>>> >>>>> >>>>>> Quite frankly I'd rather just remove all the universal binary stuff >>>>>> from hotspot, but I'm trying my best to minimize the changes there... >>>>>> the "other" problem I can handle easily. >>>>>> >>>>>> -DrD- >>>>>> >>>>>> >>>> >> -- Senior Software Developer / IT Administrator Work: (416) 466-9283 Fax : (866) 855-2605 From weijun.wang at oracle.com Thu Jan 22 10:46:06 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 22 Jan 2015 18:46:06 +0800 Subject: RFR 8071313: krb5.conf not read if SCDynamicStore krb5 config is empty Message-ID: <7FCE4119-D6AA-4380-891C-C9350523AA30@oracle.com> Hi All Please review the fix at http://cr.openjdk.java.net/~weijun/8071313/webrev.00 On a Mac OS X, when Open Directory is installed but disabled, Java should be able to use other Kerberos settings. Noreg-hard but I added a comment [1] to describe how to test the change. Thanks Max [1] https://bugs.openjdk.java.net/browse/JDK-8071313 From Sergey.Bylokhov at oracle.com Fri Jan 23 09:49:14 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 23 Jan 2015 12:49:14 +0300 Subject: Ending the need for apple.laf.useScreenMenuBar In-Reply-To: <005866A6-DB52-46BB-B6A7-43B046333DD8@apple.com> References: <98E2D45C-7931-4C41-A6C5-5B76DBA97C01@oracle.com> <22C17734-371C-460C-8234-BC25C249DB27@gmail.com> <8D244E52-D8CF-428F-B7F2-54A4889DF730@apple.com> <39C5D568-7A78-498D-B62D-ECEB4885AA89@oracle.com> <4EDCA550.6080402@oracle.com> <005866A6-DB52-46BB-B6A7-43B046333DD8@apple.com> Message-ID: <54C2191A.8070406@oracle.com> On 05.12.2011 21:29, Mike Swingler wrote: > On Dec 5, 2011, at 6:49 AM, Scott Palmer wrote: > >> On Mon, Dec 5, 2011 at 6:04 AM, Artem Ananiev wrote: >> >>> On 12/3/2011 4:23 AM, Scott Kovatch wrote: >>> >>>> On Dec 2, 2011, at 2:57 PM, Mike Swingler wrote: >>>> >>>> On Dec 2, 2011, at 2:28 PM, Mario Torre wrote: >>>>> Il giorno 02/dic/2011, alle ore 23:25, Scott Kovatch ha scritto: >>>>>>> Folks, >>>>>>> >>>>>>> This may be a better question for Artem and the AWT/Swing team, >>>>>>> but it affects the Mac so I'm starting here. >>>>>>> >>>>>>> Now that it's 2011, can we please get rid of >>>>>>> apple.laf.useScreenMenuBar and just allow menu bars in the Aqua >>>>>>> L&F to be enabled by default? I believe JavaFx doesn't force >>>>>>> Mac menu bars into the window (but if it does, I will make my >>>>>>> displeasure known to Richard Bair on Monday.) >>>>>>> >>>>>>> I ask, because today I was looking at the changes to Web Start >>>>>>> and the plugin to allow this property as a 'safe' one that can >>>>>>> be defined in a JNLP file, and I decided now is the time to get >>>>>>> rid of it once and for all. It's not that I object to adding it >>>>>>> to Web Start; I object to the necessity of having to define it >>>>>>> in the first place. >>>>>>> >>>>>>> -- Scott >>>>>>> >>>>>> I think you're right, I'm in favor of this change too. >>>>>> >>>>>> Cheers, Mario >>>>>> >>>>> I'd be the first one to advocate for this, but isn't the key >>>>> problem that he semantics of the Screen Menu bar violate certain >>>>> rules in the JCK? Implementing arbitrary Java drawing into >>>>> NSView-based menu items might even be possible post-Leopard, but is >>>>> that really something the AWT team would want to implement? >>>>> >> JMenuItem is a JComponent... as such Java developers are rightfully going >> to assume that the painting pipeline for JComponents applies. >> Wanting (or not) to implement it isn't really an argument :-) >> There are lots of UI guidelines that are platform specific and a general UI >> framework may support things that aren't typical or desirable on a specific >> platform. E.g. I believe on OS X icons on menu items are generally >> discouraged, even though they are possible such as is seen in Safari's >> Bookmarks menu. >> >> I'm not saying that I'm against this by the way. If the Aqua L&F >> automatically uses the screen menu bar that's fine with me. So long as >> code that does unusual things with JMenuItems doesn't crash. It wouldn't >> be the first time a particular look and feel was slightly incompatible with >> the cross-platform look and feel. Perhaps though, just in case, the Java >> Preference app could be used to toggle the default menu behaviour for the >> Aqua L&F? At least that would give people a workaround for things that >> break. > The current situation is the ScreenMenuBar is not default, but virtually every app that has an explicit deployment for the Mac sets this property. Apps that don't even bother to test or deploy for Mac OS X get cross platform behavior and a cross platform user experience. > > I don't see the harm of letting developers continue opt-up into a less compatible, but more Mac-like experience. This is just like using Meta instead of Ctrl based keyboard accelerators when on a Mac. I suppose nobody object to enable this property by default in jdk9? The possibility to switch it off will exist. > > Regards, > Mike Swingler > Apple Inc. > -- Best regards, Sergey. From swpalmer at gmail.com Fri Jan 23 21:39:06 2015 From: swpalmer at gmail.com (Scott Palmer) Date: Fri, 23 Jan 2015 16:39:06 -0500 Subject: Ending the need for apple.laf.useScreenMenuBar In-Reply-To: <54C2191A.8070406@oracle.com> References: <98E2D45C-7931-4C41-A6C5-5B76DBA97C01@oracle.com> <22C17734-371C-460C-8234-BC25C249DB27@gmail.com> <8D244E52-D8CF-428F-B7F2-54A4889DF730@apple.com> <39C5D568-7A78-498D-B62D-ECEB4885AA89@oracle.com> <4EDCA550.6080402@oracle.com> <005866A6-DB52-46BB-B6A7-43B046333DD8@apple.com> <54C2191A.8070406@oracle.com> Message-ID: The default LaF on OS X is not Metal/Ocean, but Aqua... so there is already precedent in having the user experience be tailored to Mac for those that don't explicitly set it. I think it would be reasonable to set this by default. Scott On Fri, Jan 23, 2015 at 4:49 AM, Sergey Bylokhov wrote: > On 05.12.2011 21:29, Mike Swingler wrote: > >> On Dec 5, 2011, at 6:49 AM, Scott Palmer wrote: >> >> On Mon, Dec 5, 2011 at 6:04 AM, Artem Ananiev >>> wrote: >>> >>> On 12/3/2011 4:23 AM, Scott Kovatch wrote: >>>> >>>> On Dec 2, 2011, at 2:57 PM, Mike Swingler wrote: >>>>> >>>>> On Dec 2, 2011, at 2:28 PM, Mario Torre wrote: >>>>> >>>>>> Il giorno 02/dic/2011, alle ore 23:25, Scott Kovatch ha scritto: >>>>>> >>>>>>> Folks, >>>>>>>> >>>>>>>> This may be a better question for Artem and the AWT/Swing team, >>>>>>>> but it affects the Mac so I'm starting here. >>>>>>>> >>>>>>>> Now that it's 2011, can we please get rid of >>>>>>>> apple.laf.useScreenMenuBar and just allow menu bars in the Aqua >>>>>>>> L&F to be enabled by default? I believe JavaFx doesn't force >>>>>>>> Mac menu bars into the window (but if it does, I will make my >>>>>>>> displeasure known to Richard Bair on Monday.) >>>>>>>> >>>>>>>> I ask, because today I was looking at the changes to Web Start >>>>>>>> and the plugin to allow this property as a 'safe' one that can >>>>>>>> be defined in a JNLP file, and I decided now is the time to get >>>>>>>> rid of it once and for all. It's not that I object to adding it >>>>>>>> to Web Start; I object to the necessity of having to define it >>>>>>>> in the first place. >>>>>>>> >>>>>>>> -- Scott >>>>>>>> >>>>>>>> I think you're right, I'm in favor of this change too. >>>>>>> >>>>>>> Cheers, Mario >>>>>>> >>>>>>> I'd be the first one to advocate for this, but isn't the key >>>>>> problem that he semantics of the Screen Menu bar violate certain >>>>>> rules in the JCK? Implementing arbitrary Java drawing into >>>>>> NSView-based menu items might even be possible post-Leopard, but is >>>>>> that really something the AWT team would want to implement? >>>>>> >>>>>> JMenuItem is a JComponent... as such Java developers are rightfully >>> going >>> to assume that the painting pipeline for JComponents applies. >>> Wanting (or not) to implement it isn't really an argument :-) >>> There are lots of UI guidelines that are platform specific and a general >>> UI >>> framework may support things that aren't typical or desirable on a >>> specific >>> platform. E.g. I believe on OS X icons on menu items are generally >>> discouraged, even though they are possible such as is seen in Safari's >>> Bookmarks menu. >>> >>> I'm not saying that I'm against this by the way. If the Aqua L&F >>> automatically uses the screen menu bar that's fine with me. So long as >>> code that does unusual things with JMenuItems doesn't crash. It wouldn't >>> be the first time a particular look and feel was slightly incompatible >>> with >>> the cross-platform look and feel. Perhaps though, just in case, the Java >>> Preference app could be used to toggle the default menu behaviour for the >>> Aqua L&F? At least that would give people a workaround for things that >>> break. >>> >> The current situation is the ScreenMenuBar is not default, but virtually >> every app that has an explicit deployment for the Mac sets this property. >> Apps that don't even bother to test or deploy for Mac OS X get cross >> platform behavior and a cross platform user experience. >> >> I don't see the harm of letting developers continue opt-up into a less >> compatible, but more Mac-like experience. This is just like using Meta >> instead of Ctrl based keyboard accelerators when on a Mac. >> > > I suppose nobody object to enable this property by default in jdk9? The > possibility to switch it off will exist. > > > >> Regards, >> Mike Swingler >> Apple Inc. >> >> > > -- > Best regards, Sergey. > > From ashesfall at gmail.com Fri Jan 23 22:48:00 2015 From: ashesfall at gmail.com (Mike Murray) Date: Fri, 23 Jan 2015 22:48:00 +0000 Subject: Ending the need for apple.laf.useScreenMenuBar References: <98E2D45C-7931-4C41-A6C5-5B76DBA97C01@oracle.com> <22C17734-371C-460C-8234-BC25C249DB27@gmail.com> <8D244E52-D8CF-428F-B7F2-54A4889DF730@apple.com> <39C5D568-7A78-498D-B62D-ECEB4885AA89@oracle.com> <4EDCA550.6080402@oracle.com> <005866A6-DB52-46BB-B6A7-43B046333DD8@apple.com> <54C2191A.8070406@oracle.com> Message-ID: Just fyi and my two cents, dealing with the screen menubar is potentially problematic for multiframe swing apps. We needed special code for our app as the menu would frequently dissappear. -m On 1:41pm, Fri, Jan 23, 2015 Scott Palmer wrote: > The default LaF on OS X is not Metal/Ocean, but Aqua... so there is already > precedent in having the user experience be tailored to Mac for those that > don't explicitly set it. I think it would be reasonable to set this by > default. > > Scott > > On Fri, Jan 23, 2015 at 4:49 AM, Sergey Bylokhov < > Sergey.Bylokhov at oracle.com > > wrote: > > > On 05.12.2011 21:29, Mike Swingler wrote: > > > >> On Dec 5, 2011, at 6:49 AM, Scott Palmer wrote: > >> > >> On Mon, Dec 5, 2011 at 6:04 AM, Artem Ananiev < > artem.ananiev at oracle.com> > >>> wrote: > >>> > >>> On 12/3/2011 4:23 AM, Scott Kovatch wrote: > >>>> > >>>> On Dec 2, 2011, at 2:57 PM, Mike Swingler wrote: > >>>>> > >>>>> On Dec 2, 2011, at 2:28 PM, Mario Torre wrote: > >>>>> > >>>>>> Il giorno 02/dic/2011, alle ore 23:25, Scott Kovatch ha scritto: > >>>>>> > >>>>>>> Folks, > >>>>>>>> > >>>>>>>> This may be a better question for Artem and the AWT/Swing team, > >>>>>>>> but it affects the Mac so I'm starting here. > >>>>>>>> > >>>>>>>> Now that it's 2011, can we please get rid of > >>>>>>>> apple.laf.useScreenMenuBar and just allow menu bars in the Aqua > >>>>>>>> L&F to be enabled by default? I believe JavaFx doesn't force > >>>>>>>> Mac menu bars into the window (but if it does, I will make my > >>>>>>>> displeasure known to Richard Bair on Monday.) > >>>>>>>> > >>>>>>>> I ask, because today I was looking at the changes to Web Start > >>>>>>>> and the plugin to allow this property as a 'safe' one that can > >>>>>>>> be defined in a JNLP file, and I decided now is the time to get > >>>>>>>> rid of it once and for all. It's not that I object to adding it > >>>>>>>> to Web Start; I object to the necessity of having to define it > >>>>>>>> in the first place. > >>>>>>>> > >>>>>>>> -- Scott > >>>>>>>> > >>>>>>>> I think you're right, I'm in favor of this change too. > >>>>>>> > >>>>>>> Cheers, Mario > >>>>>>> > >>>>>>> I'd be the first one to advocate for this, but isn't the key > >>>>>> problem that he semantics of the Screen Menu bar violate certain > >>>>>> rules in the JCK? Implementing arbitrary Java drawing into > >>>>>> NSView-based menu items might even be possible post-Leopard, but is > >>>>>> that really something the AWT team would want to implement? > >>>>>> > >>>>>> JMenuItem is a JComponent... as such Java developers are rightfully > >>> going > >>> to assume that the painting pipeline for JComponents applies. > >>> Wanting (or not) to implement it isn't really an argument :-) > >>> There are lots of UI guidelines that are platform specific and a > general > >>> UI > >>> framework may support things that aren't typical or desirable on a > >>> specific > >>> platform. E.g. I believe on OS X icons on menu items are generally > >>> discouraged, even though they are possible such as is seen in Safari's > >>> Bookmarks menu. > >>> > >>> I'm not saying that I'm against this by the way. If the Aqua L&F > >>> automatically uses the screen menu bar that's fine with me. So long as > >>> code that does unusual things with JMenuItems doesn't crash. It > wouldn't > >>> be the first time a particular look and feel was slightly incompatible > >>> with > >>> the cross-platform look and feel. Perhaps though, just in case, the > Java > >>> Preference app could be used to toggle the default menu behaviour for > the > >>> Aqua L&F? At least that would give people a workaround for things that > >>> break. > >>> > >> The current situation is the ScreenMenuBar is not default, but virtually > >> every app that has an explicit deployment for the Mac sets this > property. > >> Apps that don't even bother to test or deploy for Mac OS X get cross > >> platform behavior and a cross platform user experience. > >> > >> I don't see the harm of letting developers continue opt-up into a less > >> compatible, but more Mac-like experience. This is just like using Meta > >> instead of Ctrl based keyboard accelerators when on a Mac. > >> > > > > I suppose nobody object to enable this property by default in jdk9? The > > possibility to switch it off will exist. > > > > > > > >> Regards, > >> Mike Swingler > >> Apple Inc. > >> > >> > > > > -- > > Best regards, Sergey. > > > > > From dcommander at users.sourceforge.net Thu Jan 29 00:35:36 2015 From: dcommander at users.sourceforge.net (DRC) Date: Wed, 28 Jan 2015 18:35:36 -0600 Subject: java2d performance java7 / java8 In-Reply-To: <479011BB-C625-4E65-99AB-9C065466B1BA@tagtraum.com> References: <53DFA95C.6040507@3kraft.com> <53E0DE0F.5070507@oracle.com> <53F20819.2020300@3kraft.com> <023FA89F-A112-49A8-B234-18F97785969F@tagtraum.com> <479011BB-C625-4E65-99AB-9C065466B1BA@tagtraum.com> Message-ID: <54C98058.4070208@users.sourceforge.net> I discovered in my own testing that, at least for my application (which is drawing large BufferedImages to the screen), using a TYPE_INT_ARGB_PRE BufferedImage is in some cases 4-5x as fast as using a TYPE_INT_RGB BufferedImage. The reason is because, if the pixel format isn't alpha-enabled, then OGLBlitSwToSurface() will call glPixelTransferf() to set the alpha scale and bias. This is basically instructing glDrawPixels() to set the alpha components to a particular value, which can be incredibly slow (probably not even hardware-accelerated on a lot of platforms.) It's much faster to set the alpha components to opaque in my source image. On my 2009 Mac Mini, the difference this makes is about 4x (80 Mpixels/sec vs. 20.) On my Linux machine with a high-end nVidia card, using ARGB_PRE with -Dsun.java2d.opengl=true increases the performance from 300 Mixels/sec to 400. On my MacBook Pro, the performance increase is also about 1/3. So I think that, in general, using ARGB_PRE BufferedImages is best when using OpenGL Java2d blitting. The Mac performance with Java 1.7 or 1.8 is still not as good as it was under Apple Java 1.6 (which was about 120 Mpixels/sec on the Mac Mini), but it's at least a lot better. On 10/7/14 12:01 PM, Hendrik Schreiber wrote: > On Aug 22, 2014, at 11:59, Hendrik Schreiber wrote: > >> On Aug 18, 2014, at 16:05, Florian Bruckner (3kraft) wrote: >> >> [...] >> >> Thanks for coming up with some sort of test. >> >> Hopefully the folks at Oracle find the time to look into this, perhaps do their own performance testing, and find ways to improve the 2D pipeline. > > Looks like we have something to look forward to: > > http://mail.openjdk.java.net/pipermail/2d-dev/2014-October/004870.html > > -hendrik From puybaret at eteks.com Fri Jan 30 22:00:29 2015 From: puybaret at eteks.com (Emmanuel Puybaret) Date: Fri, 30 Jan 2015 23:00:29 +0100 Subject: JRELoadError Message-ID: Hi, I developed a sandboxed version of Sweet Home 3D that comes with its own copy of JRE 7. Miserably, a few users reported recently that they got a "JRELoadError" when they launch the application. I tried to update from JRE 7u72 to JRE 7u76, tried to replace JavaAppLauncher by the launcher generated by javafxpackager, and also tried to replace the JRE 7 copy by a JRE 8 copy, but these users reported to me it didn't fix this issue. Would have any of you encounter this problem and/or have an idea how to fix it? Best regards, -- Emmanuel PUYBARET Email : puybaret at eteks.com Web : http://www.eteks.com http://www.sweethome3d.com From mik3hall at gmail.com Sat Jan 31 01:43:26 2015 From: mik3hall at gmail.com (Michael Hall) Date: Fri, 30 Jan 2015 19:43:26 -0600 Subject: JRELoadError In-Reply-To: References: Message-ID: On Jan 30, 2015, at 4:00 PM, Emmanuel Puybaret wrote: > Hi, > > I developed a sandboxed version of Sweet Home 3D that comes with its own copy of JRE 7. > Miserably, a few users reported recently that they got a "JRELoadError" when they launch the application. > I tried to update from JRE 7u72 to JRE 7u76, tried to replace JavaAppLauncher by the launcher generated by javafxpackager, and also tried to replace the JRE 7 copy by a JRE 8 copy, but these users reported to me it didn't fix this issue. > > Would have any of you encounter this problem and/or have an idea how to fix it? A number of apps seem to have had the issue if you search on the subject error. This post?. http://jedit.9.x6.nabble.com/jEdit-users-JRELoadError-launching-jEdit-5-2pre1-after-mavericks-upgrade-but-no-java-version-or-JAVAe-td5005300.html had a lot of mail list noise but ended up with some valid enough suggestions as to what the possible conflicts might be. Use of JAVA_HOME conflicting with the browser installed JRE version some sort of embedded symlink back to an apple JRE the possibilities that I remember. It suggested a work around of using a 3rd party package for running an app configuration that would work with both Apple and Oracle JRE?s. There might be some information of use to you in that one. There were a number of apps that appeared to have the issue. Michael Hall trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter From pslack at wavedna.com Sat Jan 31 16:45:29 2015 From: pslack at wavedna.com (Peter J Slack) Date: Sat, 31 Jan 2015 11:45:29 -0500 Subject: JRELoadError In-Reply-To: References: Message-ID: The Mac version JRE 1.6 uses different symbols than 1.7 and 1.8 for the 2 key functions used by a launcher to load and run JVM in order to remedy this I've searched both symbols in case one fails when launching a JVM in my own launcher Launchers have to load the library into memory and then wrap 2 key functions. Apple names these functions differently here's a code snippet in C illustrating how I've adapted setting up to launch the JVM by loading in memory, if the Apple naming fails I revert to openjdk naming //first see if the apple naming is active WRAPPED_JNI_CreateJavaVM my_JNI_CreateJavaVM = (WRAPPED_JNI_CreateJavaVM) dlsym(handle,"JNI_CreateJavaVM_Impl"); //we need to try the possibility that this is not Apple JVM where they mangle the names by appending _impl if(my_JNI_CreateJavaVM == NULL){ //this is the case for openjdk 1.7 + where they use the traditional symbols in jvm.dll my_JNI_CreateJavaVM = (WRAPPED_JNI_CreateJavaVM) dlsym(handle,"JNI_CreateJavaVM"); } WRAPPED_JNI_GetCreatedJavaVMs my_JNI_GetCreatedJavaVMs = (WRAPPED_JNI_GetCreatedJavaVMs)dlsym(handle,"JNI_GetCreatedJavaVMs_Impl"); if(my_JNI_GetCreatedJavaVMs == NULL){ my_JNI_GetCreatedJavaVMs = (WRAPPED_JNI_GetCreatedJavaVMs)dlsym(handle,"JNI_GetCreatedJavaVMs"); } On Fri, Jan 30, 2015 at 8:43 PM, Michael Hall wrote: > On Jan 30, 2015, at 4:00 PM, Emmanuel Puybaret wrote: > > > Hi, > > > > I developed a sandboxed version of Sweet Home 3D that comes with its own > copy of JRE 7. > > Miserably, a few users reported recently that they got a "JRELoadError" > when they launch the application. > > I tried to update from JRE 7u72 to JRE 7u76, tried to replace > JavaAppLauncher by the launcher generated by javafxpackager, and also > tried to replace the JRE 7 copy by a JRE 8 copy, but these users reported > to me it didn't fix this issue. > > > > Would have any of you encounter this problem and/or have an idea how to > fix it? > > A number of apps seem to have had the issue if you search on the subject > error. > This post?. > > > http://jedit.9.x6.nabble.com/jEdit-users-JRELoadError-launching-jEdit-5-2pre1-after-mavericks-upgrade-but-no-java-version-or-JAVAe-td5005300.html > > had a lot of mail list noise but ended up with some valid enough > suggestions as to what the possible conflicts might be. > Use of JAVA_HOME > conflicting with the browser installed JRE version > some sort of embedded symlink back to an apple JRE > the possibilities that I remember. > It suggested a work around of using a 3rd party package for running an app > configuration that would work with both Apple and Oracle JRE?s. > There might be some information of use to you in that one. There were a > number of apps that appeared to have the issue. > > Michael Hall > > trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz > > HalfPipe Java 6/7 shell app > http://www195.pair.com/mik3hall/index.html#halfpipe > > AppConverter convert Apple jvm to openjdk apps > http://www195.pair.com/mik3hall/index.html#appconverter > > > > > -- Senior Software Developer / IT Administrator Work: (416) 466-9283 Fax : (866) 855-2605