From henri.gomez at gmail.com Wed Nov 2 00:00:37 2011 From: henri.gomez at gmail.com (Henri Gomez) Date: Wed, 2 Nov 2011 08:00:37 +0100 Subject: Rhino source code (Was: Rhino build support) In-Reply-To: <4EAF76CE.9080907@oracle.com> References: <20111031145356.80545DD3@eggemoggin.niobe.net> <4EAF76CE.9080907@oracle.com> Message-ID: Hi Sunder Will you also explain how to get Rhino built into OpenJDK, ie what should be done in makefile's and parameters, to get it loaded and compiled in JDK ? Cheers 2011/11/1 A. Sundararajan : > Hi, > > Yes, we are working on updating the release note to point people to the > CloseJDK Rhino changes. > > Thanks, > -Sundar > > > mark.reinhold at oracle.com wrote: >> >> 2011/10/31 4:51 -0700, mark at klomp.org: >> >>> >>> This might have slipped through with all the excitement around JavaFX >>> being liberated and all the new JEPs. But it would really help us if you >>> could take a quick peek and point us in the right direction. >>> >>> It would be good for us to make sure we all distribute the same >>> javax.script javascript support, whether it is ClosedJDK, OpenJDK, >>> IcedTea or the MacOSX port. Users probably would like to be sure it is >>> all compatible and supports the same features. >>> >> >> Sundar -- Could you please summarize the changes you made to the Rhino >> code when you last updated the copy used in the Oracle builds? ?Thanks. >> >> >>> >>> Maybe it is already in the distribution legal notes somewhere, but we >>> looked and cannot find it (maybe we looked in the wrong place). Assuming >>> you are redistributing Rhino under the GPL/MPL there really should at >>> least be a conspicuous notice stating where to find the modifications >>> used to make the binary Oracle is distributing (MPL section 3.6 and/or >>> GPL section 3). >>> >> >> That should be in the Oracle JDK 7 release notes, but I don't see it, >> so I'll ask someone to take care of it. >> >> - Mark >> > > From mark at klomp.org Wed Nov 2 01:37:51 2011 From: mark at klomp.org (Mark Wielaard) Date: Wed, 2 Nov 2011 09:37:51 +0100 Subject: Rhino source code (Was: Rhino build support) In-Reply-To: <4EAF76CE.9080907@oracle.com> References: <20111031145356.80545DD3@eggemoggin.niobe.net> <4EAF76CE.9080907@oracle.com> Message-ID: <20111102083751.GB25788@hermans.wildebeest.org> On Tue, Nov 01, 2011 at 10:04:22AM +0530, A. Sundararajan wrote: > mark.reinhold at oracle.com wrote: > >2011/10/31 4:51 -0700, mark at klomp.org: > >>Maybe it is already in the distribution legal notes somewhere, but we > >>looked and cannot find it (maybe we looked in the wrong place). Assuming > >>you are redistributing Rhino under the GPL/MPL there really should at > >>least be a conspicuous notice stating where to find the modifications > >>used to make the binary Oracle is distributing (MPL section 3.6 and/or > >>GPL section 3). > > > >That should be in the Oracle JDK 7 release notes, but I don't see it, > >so I'll ask someone to take care of it. > > Yes, we are working on updating the release note to point people to > the CloseJDK Rhino changes. That is really appreciated. Easiest for us would be just a repository with the current code, as you use it in your integration builds. Or a diff against the upstream release you made the changes to and how it integrates with the rest of the build. Thanks, Mark From glewis at eyesbeyond.com Wed Nov 2 20:01:46 2011 From: glewis at eyesbeyond.com (Greg Lewis) Date: Wed, 2 Nov 2011 20:01:46 -0700 Subject: bsd-port still in b147 In-Reply-To: <20111031215324.GE10762@rivendell.middle-earth.co.uk> References: <20111031215324.GE10762@rivendell.middle-earth.co.uk> Message-ID: <20111103030146.GA95883@misty.eyesbeyond.com> On Mon, Oct 31, 2011 at 09:53:24PM +0000, Dr Andrew John Hughes wrote: > On 09:16 Mon 31 Oct , Henri Gomez wrote: > > Hi guys > > > > bsd-port seems to be still in b147 whereas macosx-port is allready b215. > > > > Is it planned to put it in sync ? > > > > OpenJDK7 only goes up to b147: > > http://hg.openjdk.java.net/jdk7/jdk7/ Exactly. > The numerous jdk7ux trees seem to continue but with new versioning (jdk7u2-b10 at present): > > http://hg.openjdk.java.net/jdk7u/jdk7u-dev/ Buth these are not GPL'ed correct? So I don't see how we can integrate changes from them into bsd-port. > The Google results for b215 suggest to me it's unique to the Mac OS X port. I don't > know whether the BSD port is pulling from there. It's always seemed odd to me that the > two are separate anyway. The other way around. MacOS X was pulling from bsd-port. I'm not quite sure where the build numbers are coming from now. I'm also not sure that we can pull from the other way (i.e. from macosx-port to bsd-port). -- Greg Lewis Email : glewis at eyesbeyond.com Eyes Beyond Web : http://www.eyesbeyond.com Information Technology FreeBSD : glewis at FreeBSD.org From luchsh at linux.vnet.ibm.com Wed Nov 9 00:01:51 2011 From: luchsh at linux.vnet.ibm.com (Jonathan Lu) Date: Wed, 09 Nov 2011 16:01:51 +0800 Subject: Patch to expand tz checking scope in TimeZone_md.c In-Reply-To: <4EB37782.9010507@oracle.com> References: <4EB105D1.9020401@linux.vnet.ibm.com> <4EB106E5.9060706@linux.vnet.ibm.com> <4EB122BE.5090302@oracle.com> <4EB12BF4.9010805@linux.vnet.ibm.com> <4EB15356.9080209@oracle.com> <4EB23FD5.60108@linux.vnet.ibm.com> <4EB3664C.1050908@oracle.com> <4EB36FD3.3030306@oracle.com> <4EB37782.9010507@oracle.com> Message-ID: <4EBA336F.9060004@linux.vnet.ibm.com> On 11/04/2011 01:26 PM, David Holmes wrote: > On 4/11/2011 2:53 PM, David Holmes wrote: >> On 4/11/2011 2:13 PM, Masayoshi Okutsu wrote: >>> Probably the difference isn't documented. I tried Solaris 10 and Ubuntu >>> 10.03. The difference still exists. >>> >>> Solaris 10: >>> $ unset TZ >>> $ date >>> Fri Nov 4 13:04:45 JST 2011 >>> $ TZ="" date >>> Fri Nov 4 13:04:53 JST 2011 >>> >>> Ubuntu 10.04: >>> $ unset TZ >>> $ date >>> Fri Nov 4 13:05:50 JST 2011 >>> $ TZ="" date >>> Fri Nov 4 04:05:55 UTC 2011 >>> >>> When the TZ value is an empty string, Ubuntu uses UTC while Solaris >>> still looks up the system default. >> >> I have to take back my comment regarding this not seeming to be platform >> specific code - it is highly platform specific! It seems that on Linux >> we are happy to report a TZ of "" but not so on Solaris. I presume this >> is an attempt to keep Java's use of TZ consistent with how other apps >> handle it on that platform. (environ(5) gives a little insight on >> Solaris as to how TZ is used.) >> >> So the key thing here is to not disturb the existing behaviour on either >> linux or Solaris - which suggests the original patch. That said I'm not >> convinced - given this is so platform specific - that simply treating >> non-linux the same as Solaris is a reasonable thing to do. I think it >> would be useful to see what the BSD/OSX port(s) had to do with this code >> - if anything. > > To answer my own queries BSD/OSX does > > 511 #if defined(__linux__) || defined(_ALLBSD_SOURCE) > 512 if (tz == NULL) { > 513 #else > 514 #ifdef __solaris__ > 515 if (tz == NULL || *tz == '\0') { > 516 #endif > 517 #endif > > so the suggested patch would at least not interfere. > > Anyway this needs input from other core-libs folk. I didn't intend to > get quite so heavily involved. ;-) > > David > ----- > > > >> David >> ----- >> >> >>> Thanks, >>> Masayoshi >>> >>> On 11/3/2011 4:16 PM, Jonathan Lu wrote: >>>> Hi Masayoshi, >>>> >>>> I did find some references about date-time related functions / TZ >>>> variables on Linux but got only a few about Solaris, so could not see >>>> any differences between those two platforms about the changes >>>> described in my patch. Have you got any links or references about >>>> these differences? I'm interested in it and may update the patch again >>>> after reading them. >>>> >>>> Thanks a lot! >>>> - Jonathan >>>> >>>> On 11/02/2011 10:27 PM, Masayoshi Okutsu wrote: >>>>> Hi Jonathan, >>>>> >>>>> IIRC, the difference came from some behavioral difference between the >>>>> Linux and Solaris libc date-time functions and/or the date command, >>>>> and TimeZone_md.c tries to follow the difference. But the code was >>>>> written looooong ago. The difference may no longer exist. >>>>> >>>>> Thanks, >>>>> Masayoshi >>>>> >>>>> On 11/2/2011 8:39 PM, Jonathan Lu wrote: >>>>>> On 11/02/2011 07:00 PM, David Holmes wrote: >>>>>>> On 2/11/2011 7:01 PM, Jonathan Lu wrote: >>>>>>>> On 11/02/2011 04:56 PM, Jonathan Lu wrote: >>>>>>>>> Hi core-libs-dev, >>>>>>>>> >>>>>>>>> In jdk/src/solaris/native/java/util/TimeZone_md.c, starting from >>>>>>>>> line >>>>>>>>> 626, I found that the scope of "#ifdef __solaris__" might be too >>>>>>>>> narrow, since it also works for some kind of OS which I'm >>>>>>>>> currently >>>>>>>>> working on, such as AIX. >>>>>>>>> So I suggest to just remove the '#ifdef __solaris__' and leave >>>>>>>>> the >>>>>>>>> "#else" to accommodate more conditions, see attachment >>>>>>>>> 'patch.diff'. I >>>>>>>>> think this may enhance the cross-platform ability, any ideas >>>>>>>>> about >>>>>>>>> this modification? >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> - Jonathan Lu >>>>>>>> I'm not sure why the attachment got filtered, here paste it to the >>>>>>>> mail >>>>>>>> content directly. >>>>>>>> >>>>>>>> diff -r 4788745572ef src/solaris/native/java/util/TimeZone_md.c >>>>>>>> --- a/src/solaris/native/java/util/TimeZone_md.c Mon Oct 17 >>>>>>>> 19:06:53 >>>>>>>> 2011 -0700 >>>>>>>> +++ b/src/solaris/native/java/util/TimeZone_md.c Thu Oct 20 >>>>>>>> 13:43:47 >>>>>>>> 2011 +0800 >>>>>>>> @@ -626,10 +626,8 @@ >>>>>>>> #ifdef __linux__ >>>>>>>> if (tz == NULL) { >>>>>>>> #else >>>>>>>> -#ifdef __solaris__ >>>>>>>> if (tz == NULL || *tz == '\0') { >>>>>>>> #endif >>>>>>>> -#endif >>>>>>>> tz = getPlatformTimeZoneID(); >>>>>>>> freetz = tz; >>>>>>>> } >>>>>>> >>>>>>> I'm unclear why any of that code needs to be platform specific - is >>>>>>> an empty TZ string somehow valid on linux? I would have thought the >>>>>>> following would be platform neutral: >>>>>>> >>>>>>> if (tz == NULL || *tz == '\0') { >>>>>>> tz = getPlatformTimeZoneID(); >>>>>>> freetz = tz; >>>>>>> } >>>>>>> >>>>>> Hi David, >>>>>> >>>>>> getenv("TZ") returns NULL when TZ environment variable is not set at >>>>>> all and returns '\0' when TZ was exported as empty string. After >>>>>> more checking for both cases, I agree with you, nothing useful can >>>>>> be retrieved from that environment variable. >>>>>> So I changed the patch to this, >>>>>> >>>>>> diff -r 7ab0d613cd1a src/solaris/native/java/util/TimeZone_md.c >>>>>> --- a/src/solaris/native/java/util/TimeZone_md.c Thu Oct 20 10:32:47 >>>>>> 2011 -0700 >>>>>> +++ b/src/solaris/native/java/util/TimeZone_md.c Wed Nov 02 19:34:51 >>>>>> 2011 +0800 >>>>>> @@ -623,13 +623,7 @@ >>>>>> >>>>>> tz = getenv("TZ"); >>>>>> >>>>>> -#ifdef __linux__ >>>>>> - if (tz == NULL) { >>>>>> -#else >>>>>> -#ifdef __solaris__ >>>>>> if (tz == NULL || *tz == '\0') { >>>>>> -#endif >>>>>> -#endif >>>>>> tz = getPlatformTimeZoneID(); >>>>>> freetz = tz; >>>>>> } >>>>>> >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>>> Regards >>>>>>>> - Jonathan Lu >>>>>> Regards >>>>>> >>>>>> - Jonathan >>>>>> >>>> Copy to bsd-port-dev and macosx-port-dev lists to see if anybody here has some ideas about this issue. -Jonathan From kurt at intricatesoftware.com Wed Nov 9 19:09:22 2011 From: kurt at intricatesoftware.com (Kurt Miller) Date: Wed, 09 Nov 2011 22:09:22 -0500 Subject: Patch to expand tz checking scope in TimeZone_md.c In-Reply-To: <4EBA336F.9060004@linux.vnet.ibm.com> References: <4EB105D1.9020401@linux.vnet.ibm.com> <4EB106E5.9060706@linux.vnet.ibm.com> <4EB122BE.5090302@oracle.com> <4EB12BF4.9010805@linux.vnet.ibm.com> <4EB15356.9080209@oracle.com> <4EB23FD5.60108@linux.vnet.ibm.com> <4EB3664C.1050908@oracle.com> <4EB36FD3.3030306@oracle.com> <4EB37782.9010507@oracle.com> <4EBA336F.9060004@linux.vnet.ibm.com> Message-ID: <4EBB4062.8050403@intricatesoftware.com> On 11/09/11 03:01, Jonathan Lu wrote: > On 11/04/2011 01:26 PM, David Holmes wrote: >> On 4/11/2011 2:53 PM, David Holmes wrote: >>> On 4/11/2011 2:13 PM, Masayoshi Okutsu wrote: >>>> Probably the difference isn't documented. I tried Solaris 10 and Ubuntu >>>> 10.03. The difference still exists. >>>> >>>> Solaris 10: >>>> $ unset TZ >>>> $ date >>>> Fri Nov 4 13:04:45 JST 2011 >>>> $ TZ="" date >>>> Fri Nov 4 13:04:53 JST 2011 >>>> >>>> Ubuntu 10.04: >>>> $ unset TZ >>>> $ date >>>> Fri Nov 4 13:05:50 JST 2011 >>>> $ TZ="" date >>>> Fri Nov 4 04:05:55 UTC 2011 >>>> >>>> When the TZ value is an empty string, Ubuntu uses UTC while Solaris >>>> still looks up the system default. >>> >>> I have to take back my comment regarding this not seeming to be platform >>> specific code - it is highly platform specific! It seems that on Linux >>> we are happy to report a TZ of "" but not so on Solaris. I presume this >>> is an attempt to keep Java's use of TZ consistent with how other apps >>> handle it on that platform. (environ(5) gives a little insight on >>> Solaris as to how TZ is used.) >>> >>> So the key thing here is to not disturb the existing behaviour on either >>> linux or Solaris - which suggests the original patch. That said I'm not >>> convinced - given this is so platform specific - that simply treating >>> non-linux the same as Solaris is a reasonable thing to do. I think it >>> would be useful to see what the BSD/OSX port(s) had to do with this code >>> - if anything. >> >> To answer my own queries BSD/OSX does >> >> 511 #if defined(__linux__) || defined(_ALLBSD_SOURCE) >> 512 if (tz == NULL) { >> 513 #else >> 514 #ifdef __solaris__ >> 515 if (tz == NULL || *tz == '\0') { >> 516 #endif >> 517 #endif >> >> so the suggested patch would at least not interfere. >> >> Anyway this needs input from other core-libs folk. I didn't intend to >> get quite so heavily involved. ;-) >> >> David >> ----- >> >> >> >>> David >>> ----- >>> >>> >>>> Thanks, >>>> Masayoshi >>>> >>>> On 11/3/2011 4:16 PM, Jonathan Lu wrote: >>>>> Hi Masayoshi, >>>>> >>>>> I did find some references about date-time related functions / TZ >>>>> variables on Linux but got only a few about Solaris, so could not see >>>>> any differences between those two platforms about the changes >>>>> described in my patch. Have you got any links or references about >>>>> these differences? I'm interested in it and may update the patch again >>>>> after reading them. >>>>> >>>>> Thanks a lot! >>>>> - Jonathan >>>>> >>>>> On 11/02/2011 10:27 PM, Masayoshi Okutsu wrote: >>>>>> Hi Jonathan, >>>>>> >>>>>> IIRC, the difference came from some behavioral difference between the >>>>>> Linux and Solaris libc date-time functions and/or the date command, >>>>>> and TimeZone_md.c tries to follow the difference. But the code was >>>>>> written looooong ago. The difference may no longer exist. >>>>>> >>>>>> Thanks, >>>>>> Masayoshi >>>>>> >>>>>> On 11/2/2011 8:39 PM, Jonathan Lu wrote: >>>>>>> On 11/02/2011 07:00 PM, David Holmes wrote: >>>>>>>> On 2/11/2011 7:01 PM, Jonathan Lu wrote: >>>>>>>>> On 11/02/2011 04:56 PM, Jonathan Lu wrote: >>>>>>>>>> Hi core-libs-dev, >>>>>>>>>> >>>>>>>>>> In jdk/src/solaris/native/java/util/TimeZone_md.c, starting from >>>>>>>>>> line >>>>>>>>>> 626, I found that the scope of "#ifdef __solaris__" might be too >>>>>>>>>> narrow, since it also works for some kind of OS which I'm >>>>>>>>>> currently >>>>>>>>>> working on, such as AIX. >>>>>>>>>> So I suggest to just remove the '#ifdef __solaris__' and leave >>>>>>>>>> the >>>>>>>>>> "#else" to accommodate more conditions, see attachment >>>>>>>>>> 'patch.diff'. I >>>>>>>>>> think this may enhance the cross-platform ability, any ideas >>>>>>>>>> about >>>>>>>>>> this modification? >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> - Jonathan Lu >>>>>>>>> I'm not sure why the attachment got filtered, here paste it to the >>>>>>>>> mail >>>>>>>>> content directly. >>>>>>>>> >>>>>>>>> diff -r 4788745572ef src/solaris/native/java/util/TimeZone_md.c >>>>>>>>> --- a/src/solaris/native/java/util/TimeZone_md.c Mon Oct 17 >>>>>>>>> 19:06:53 >>>>>>>>> 2011 -0700 >>>>>>>>> +++ b/src/solaris/native/java/util/TimeZone_md.c Thu Oct 20 >>>>>>>>> 13:43:47 >>>>>>>>> 2011 +0800 >>>>>>>>> @@ -626,10 +626,8 @@ >>>>>>>>> #ifdef __linux__ >>>>>>>>> if (tz == NULL) { >>>>>>>>> #else >>>>>>>>> -#ifdef __solaris__ >>>>>>>>> if (tz == NULL || *tz == '\0') { >>>>>>>>> #endif >>>>>>>>> -#endif >>>>>>>>> tz = getPlatformTimeZoneID(); >>>>>>>>> freetz = tz; >>>>>>>>> } >>>>>>>> >>>>>>>> I'm unclear why any of that code needs to be platform specific - is >>>>>>>> an empty TZ string somehow valid on linux? I would have thought the >>>>>>>> following would be platform neutral: >>>>>>>> >>>>>>>> if (tz == NULL || *tz == '\0') { >>>>>>>> tz = getPlatformTimeZoneID(); >>>>>>>> freetz = tz; >>>>>>>> } >>>>>>>> >>>>>>> Hi David, >>>>>>> >>>>>>> getenv("TZ") returns NULL when TZ environment variable is not set at >>>>>>> all and returns '\0' when TZ was exported as empty string. After >>>>>>> more checking for both cases, I agree with you, nothing useful can >>>>>>> be retrieved from that environment variable. >>>>>>> So I changed the patch to this, >>>>>>> >>>>>>> diff -r 7ab0d613cd1a src/solaris/native/java/util/TimeZone_md.c >>>>>>> --- a/src/solaris/native/java/util/TimeZone_md.c Thu Oct 20 10:32:47 >>>>>>> 2011 -0700 >>>>>>> +++ b/src/solaris/native/java/util/TimeZone_md.c Wed Nov 02 19:34:51 >>>>>>> 2011 +0800 >>>>>>> @@ -623,13 +623,7 @@ >>>>>>> >>>>>>> tz = getenv("TZ"); >>>>>>> >>>>>>> -#ifdef __linux__ >>>>>>> - if (tz == NULL) { >>>>>>> -#else >>>>>>> -#ifdef __solaris__ >>>>>>> if (tz == NULL || *tz == '\0') { >>>>>>> -#endif >>>>>>> -#endif >>>>>>> tz = getPlatformTimeZoneID(); >>>>>>> freetz = tz; >>>>>>> } >>>>>>> >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>>> Regards >>>>>>>>> - Jonathan Lu >>>>>>> Regards >>>>>>> >>>>>>> - Jonathan >>>>>>> >>>>> > Copy to bsd-port-dev and macosx-port-dev lists to see if anybody here > has some ideas about this issue. Hi Jonathan, The above email is a bit hard to follow due to the mixture of top and bottom replies. I can confirm that OpenBSD and Mac OS X 10.5.8 follow the Linux behavior which confirms the need for platform ifdef's in this code. Seems like you need to make the following change: -#ifdef __solaris__ +#if defined(__solaris__) || defined(__AIX__) or something similar to maintain compatibility. In general the approach taken for adding BSD support was to never assume you can change other supported code paths. If your architecture follows an existing code path behavior add it like I did above. Otherwise just create a #ifdef myarch section for it. Unifying or changing another architecture's code path requires access to the arch, research and confirmation that the change is ok. Typically this may be done by writing independent test programs and running them on each arch. Regards, -Kurt From sundararajan.athijegannathan at oracle.com Wed Nov 9 19:46:11 2011 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Thu, 10 Nov 2011 09:16:11 +0530 Subject: Rhino source code (Was: Rhino build support) In-Reply-To: <4EAF76CE.9080907@oracle.com> References: <20111031145356.80545DD3@eggemoggin.niobe.net> <4EAF76CE.9080907@oracle.com> Message-ID: <4EBB4903.90902@oracle.com> Hi All, We have posted CloseJDK changes to Rhino to java.net site. The Oracle modified Rhino sources can be downloaded from http://jdk7.java.net/rhino/ The jdk7 release notes will be shortly updated to point to the aforementioned URL. Thanks, -Sundar A. Sundararajan wrote: > Hi, > > Yes, we are working on updating the release note to point people to > the CloseJDK Rhino changes. > > Thanks, > -Sundar > > > mark.reinhold at oracle.com wrote: >> 2011/10/31 4:51 -0700, mark at klomp.org: >> >>> This might have slipped through with all the excitement around JavaFX >>> being liberated and all the new JEPs. But it would really help us if >>> you >>> could take a quick peek and point us in the right direction. >>> >>> It would be good for us to make sure we all distribute the same >>> javax.script javascript support, whether it is ClosedJDK, OpenJDK, >>> IcedTea or the MacOSX port. Users probably would like to be sure it is >>> all compatible and supports the same features. >>> >> >> Sundar -- Could you please summarize the changes you made to the Rhino >> code when you last updated the copy used in the Oracle builds? Thanks. >> >> >>> Maybe it is already in the distribution legal notes somewhere, but we >>> looked and cannot find it (maybe we looked in the wrong place). >>> Assuming >>> you are redistributing Rhino under the GPL/MPL there really should at >>> least be a conspicuous notice stating where to find the modifications >>> used to make the binary Oracle is distributing (MPL section 3.6 and/or >>> GPL section 3). >>> >> >> That should be in the Oracle JDK 7 release notes, but I don't see it, >> so I'll ask someone to take care of it. >> >> - Mark >> > > From henri.gomez at gmail.com Thu Nov 10 01:02:49 2011 From: henri.gomez at gmail.com (Henri Gomez) Date: Thu, 10 Nov 2011 10:02:49 +0100 Subject: Rhino source code (Was: Rhino build support) In-Reply-To: <4EBB4903.90902@oracle.com> References: <20111031145356.80545DD3@eggemoggin.niobe.net> <4EAF76CE.9080907@oracle.com> <4EBB4903.90902@oracle.com> Message-ID: Very good news. Questions : - Could these CloseJDK changes be used in OpenJDK builds ? - Advices/directions on how to tweak current build to include them ? Cheers 2011/11/10 A. Sundararajan : > Hi All, > > We have posted CloseJDK changes to Rhino to java.net site. ?The Oracle > modified Rhino sources can be downloaded from http://jdk7.java.net/rhino/ > > The jdk7 release notes will be shortly updated to point to the > aforementioned URL. > > Thanks, > -Sundar > > A. Sundararajan wrote: >> >> Hi, >> >> Yes, we are working on updating the release note to point people to the >> CloseJDK Rhino changes. >> >> Thanks, >> -Sundar >> >> >> mark.reinhold at oracle.com wrote: >>> >>> 2011/10/31 4:51 -0700, mark at klomp.org: >>> >>>> >>>> This might have slipped through with all the excitement around JavaFX >>>> being liberated and all the new JEPs. But it would really help us if you >>>> could take a quick peek and point us in the right direction. >>>> >>>> It would be good for us to make sure we all distribute the same >>>> javax.script javascript support, whether it is ClosedJDK, OpenJDK, >>>> IcedTea or the MacOSX port. Users probably would like to be sure it is >>>> all compatible and supports the same features. >>>> >>> >>> Sundar -- Could you please summarize the changes you made to the Rhino >>> code when you last updated the copy used in the Oracle builds? ?Thanks. >>> >>> >>>> >>>> Maybe it is already in the distribution legal notes somewhere, but we >>>> looked and cannot find it (maybe we looked in the wrong place). Assuming >>>> you are redistributing Rhino under the GPL/MPL there really should at >>>> least be a conspicuous notice stating where to find the modifications >>>> used to make the binary Oracle is distributing (MPL section 3.6 and/or >>>> GPL section 3). >>>> >>> >>> That should be in the Oracle JDK 7 release notes, but I don't see it, >>> so I'll ask someone to take care of it. >>> >>> - Mark >>> >> >> > > From sundararajan.athijegannathan at oracle.com Thu Nov 10 08:15:00 2011 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Thu, 10 Nov 2011 21:45:00 +0530 Subject: Rhino source code (Was: Rhino build support) In-Reply-To: References: <20111031145356.80545DD3@eggemoggin.niobe.net> <4EAF76CE.9080907@oracle.com> <4EBB4903.90902@oracle.com> Message-ID: <4EBBF884.1070401@oracle.com> Hi Henri, The sources are self contained - no external dependencies apart from jdk code itself. The "javax.script" API classes and other "com.sun.script" implementation classes are already part of OpenJDK. It should be possible expand contents of src directory under $jdk/src/share/classes and adjust makefiles to add "sun/org" package (pls note that sun/org is the package prefix of the modified Rhino sources). -Sundar Henri Gomez wrote: > Very good news. > > Questions : > > - Could these CloseJDK changes be used in OpenJDK builds ? > - Advices/directions on how to tweak current build to include them ? > > Cheers > > 2011/11/10 A. Sundararajan : > >> Hi All, >> >> We have posted CloseJDK changes to Rhino to java.net site. The Oracle >> modified Rhino sources can be downloaded from http://jdk7.java.net/rhino/ >> >> The jdk7 release notes will be shortly updated to point to the >> aforementioned URL. >> >> Thanks, >> -Sundar >> >> A. Sundararajan wrote: >> >>> Hi, >>> >>> Yes, we are working on updating the release note to point people to the >>> CloseJDK Rhino changes. >>> >>> Thanks, >>> -Sundar >>> >>> >>> mark.reinhold at oracle.com wrote: >>> >>>> 2011/10/31 4:51 -0700, mark at klomp.org: >>>> >>>> >>>>> This might have slipped through with all the excitement around JavaFX >>>>> being liberated and all the new JEPs. But it would really help us if you >>>>> could take a quick peek and point us in the right direction. >>>>> >>>>> It would be good for us to make sure we all distribute the same >>>>> javax.script javascript support, whether it is ClosedJDK, OpenJDK, >>>>> IcedTea or the MacOSX port. Users probably would like to be sure it is >>>>> all compatible and supports the same features. >>>>> >>>>> >>>> Sundar -- Could you please summarize the changes you made to the Rhino >>>> code when you last updated the copy used in the Oracle builds? Thanks. >>>> >>>> >>>> >>>>> Maybe it is already in the distribution legal notes somewhere, but we >>>>> looked and cannot find it (maybe we looked in the wrong place). Assuming >>>>> you are redistributing Rhino under the GPL/MPL there really should at >>>>> least be a conspicuous notice stating where to find the modifications >>>>> used to make the binary Oracle is distributing (MPL section 3.6 and/or >>>>> GPL section 3). >>>>> >>>>> >>>> That should be in the Oracle JDK 7 release notes, but I don't see it, >>>> so I'll ask someone to take care of it. >>>> >>>> - Mark >>>> >>>> >>> >> From henri.gomez at gmail.com Thu Nov 10 10:27:47 2011 From: henri.gomez at gmail.com (Henri Gomez) Date: Thu, 10 Nov 2011 19:27:47 +0100 Subject: Rhino source code (Was: Rhino build support) In-Reply-To: <4EBBF884.1070401@oracle.com> References: <20111031145356.80545DD3@eggemoggin.niobe.net> <4EAF76CE.9080907@oracle.com> <4EBB4903.90902@oracle.com> <4EBBF884.1070401@oracle.com> Message-ID: > Hi Henri, > The sources are self contained - no external dependencies apart from jdk > code itself. ?The "javax.script" API classes and other "com.sun.script" > implementation classes are already part of OpenJDK. ?It should be possible > expand contents of src directory under $jdk/src/share/classes and adjust > makefiles to add "sun/org" package (pls note that sun/org is the package > prefix of the modified Rhino sources). Hello Sundar. Since it still unclear about licence (and including this modified Rhino sources), I'll stick for now with RH way. Everything should works : script support is built into rt.jar testing: com/sun/script/javascript/ExternalScriptable.class OK testing: com/sun/script/javascript/JSAdapter.class OK testing: com/sun/script/javascript/JavaAdapter.class OK testing: com/sun/script/javascript/RhinoClassShutter.class OK testing: com/sun/script/javascript/RhinoCompiledScript.class OK testing: com/sun/script/javascript/RhinoScriptEngine$1.class OK testing: com/sun/script/javascript/RhinoScriptEngine$2.class OK testing: com/sun/script/javascript/RhinoScriptEngine.class OK testing: com/sun/script/javascript/RhinoScriptEngineFactory.class OK testing: com/sun/script/javascript/RhinoTopLevel.class OK testing: com/sun/script/javascript/RhinoWrapFactory$RhinoJavaObject.class OK testing: com/sun/script/javascript/RhinoWrapFactory.class OK testing: com/sun/script/util/BindingsBase.class OK testing: com/sun/script/util/BindingsEntrySet$BindingsEntry.class OK testing: com/sun/script/util/BindingsEntrySet$BindingsIterator.class OK testing: com/sun/script/util/BindingsEntrySet.class OK testing: com/sun/script/util/BindingsImpl.class OK testing: com/sun/script/util/InterfaceImplementor$InterfaceImplementorInvocationHandler$1.class OK testing: com/sun/script/util/InterfaceImplementor$InterfaceImplementorInvocationHandler.class OK testing: com/sun/script/util/InterfaceImplementor.class OK testing: com/sun/script/util/ScriptEngineFactoryBase.class OK Mozilla rhino.jar is also installed under jre/lib (ie: classes renamed) : testing: META-INF/ OK testing: META-INF/MANIFEST.MF OK testing: sun/ OK testing: sun/org/ OK testing: sun/org/mozilla/ OK testing: sun/org/mozilla/classfile/ OK testing: sun/org/mozilla/classfile/ByteCode.class OK testing: sun/org/mozilla/classfile/ClassFileField.class OK testing: sun/org/mozilla/classfile/ClassFileMethod.class OK testing: sun/org/mozilla/classfile/ClassFileWriter$ClassFileFormatException.class OK testing: sun/org/mozilla/classfile/ClassFileWriter$StackMapTable.class OK testing: sun/org/mozilla/classfile/ClassFileWriter.class OK testing: sun/org/mozilla/classfile/ConstantPool.class OK testing: sun/org/mozilla/classfile/ExceptionTableEntry.class OK But jrunscript still complains about missing sun/org/mozilla/javascript/ContextFactory imac-hgomez-exo:workspace henri$ build/macosx-universal/j2sdk-image/1.7.0.jdk/Contents/Home/bin/jrunscript Exception in thread "main" java.lang.NoClassDefFoundError: sun/org/mozilla/javascript/ContextFactory at com.sun.script.javascript.RhinoScriptEngine.(RhinoScriptEngine.java:67) at com.sun.script.javascript.RhinoScriptEngineFactory.getScriptEngine(RhinoScriptEngineFactory.java:74) at javax.script.ScriptEngineManager.getEngineByName(ScriptEngineManager.java:243) at com.sun.tools.script.shell.Main.getScriptEngine(Main.java:411) at com.sun.tools.script.shell.Main.processOptions(Main.java:169) at com.sun.tools.script.shell.Main.main(Main.java:44) strange, os.cpp has been modified to include rhino.jar From henri.gomez at gmail.com Thu Nov 10 11:54:56 2011 From: henri.gomez at gmail.com (Henri Gomez) Date: Thu, 10 Nov 2011 20:54:56 +0100 Subject: Rhino source code (Was: Rhino build support) In-Reply-To: References: <20111031145356.80545DD3@eggemoggin.niobe.net> <4EAF76CE.9080907@oracle.com> <4EBB4903.90902@oracle.com> <4EBBF884.1070401@oracle.com> Message-ID: > > imac-hgomez-exo:workspace henri$ > build/macosx-universal/j2sdk-image/1.7.0.jdk/Contents/Home/bin/jrunscript > Exception in thread "main" java.lang.NoClassDefFoundError: > sun/org/mozilla/javascript/ContextFactory > ? ? ? ?at com.sun.script.javascript.RhinoScriptEngine.(RhinoScriptEngine.java:67) > ? ? ? ?at com.sun.script.javascript.RhinoScriptEngineFactory.getScriptEngine(RhinoScriptEngineFactory.java:74) > ? ? ? ?at javax.script.ScriptEngineManager.getEngineByName(ScriptEngineManager.java:243) > ? ? ? ?at com.sun.tools.script.shell.Main.getScriptEngine(Main.java:411) > ? ? ? ?at com.sun.tools.script.shell.Main.processOptions(Main.java:169) > ? ? ? ?at com.sun.tools.script.shell.Main.main(Main.java:44) > > strange, os.cpp has been modified to include rhino.jar Problem fixed, a clean build produced a correct jrunscript : mbp:workspace henri$ build/macosx-universal/j2sdk-image/1.7.0.jdk/Contents/Home/bin/jrunscript js> I'll apply change to my current build script to include rhino support in openjdk-osx-build packages. Stay tuned :) From dalibor.topic at oracle.com Fri Nov 11 03:47:26 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Fri, 11 Nov 2011 12:47:26 +0100 Subject: Rhino build support In-Reply-To: References: Message-ID: <4EBD0B4E.2050403@oracle.com> On 10/17/11 7:06 PM, Henri Gomez wrote: > 1) Did there is any reason why Rhino is not included in bsd-port (and > so macosx-port) like licence problems ? Rhino is not necessary for OpenJDK to build & run, so it doesn't really belong in the OpenJDK code base. cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From dalibor.topic at oracle.com Fri Nov 11 03:48:44 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Fri, 11 Nov 2011 12:48:44 +0100 Subject: Rhino on bsd-port/osx-port OpenJDK 7 In-Reply-To: References: <4E539643.2070301@oracle.com> <4E539EF4.5070607@oracle.com> <4E53AAAB.9030700@oracle.com> <4E54ED99.7090001@oracle.com> Message-ID: <4EBD0B9C.2050902@oracle.com> On 10/10/11 7:33 PM, Henri Gomez wrote: > 2011/10/10 Henri Gomez : >> Question about Rhino included in JDK 7. >> >> Do you know version of Rhino from Mozilla.org used ? > > Readme reports 1.7R3 > > > But digging in js.jar from Rhino 1.7R3, I could see 443 classes > whereas jdk 1.7.0 for Linux came with 316 classes > See README.TXT. cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From henri.gomez at gmail.com Fri Nov 11 07:55:41 2011 From: henri.gomez at gmail.com (Henri Gomez) Date: Fri, 11 Nov 2011 16:55:41 +0100 Subject: Rhino on bsd-port/osx-port OpenJDK 7 In-Reply-To: <4EBD0B9C.2050902@oracle.com> References: <4E539643.2070301@oracle.com> <4E539EF4.5070607@oracle.com> <4E53AAAB.9030700@oracle.com> <4E54ED99.7090001@oracle.com> <4EBD0B9C.2050902@oracle.com> Message-ID: >> But digging in js.jar from Rhino 1.7R3, I could see 443 classes >> whereas jdk 1.7.0 for Linux came with 316 classes >> > > See README.TXT. There is a mention in THIRD_PARTY_README : %% This notice is provided with respect to Mozilla Rhino v1.7R3, which is included with JRE 7, JDK 7, and OpenJDK 7 Mozilla Rhino is included in JRE/JDK and OpenJDK 7. It's now included in latest openjdk-osx-build packages From henri.gomez at gmail.com Fri Nov 11 07:56:49 2011 From: henri.gomez at gmail.com (Henri Gomez) Date: Fri, 11 Nov 2011 16:56:49 +0100 Subject: Rhino build support In-Reply-To: <4EBD0B4E.2050403@oracle.com> References: <4EBD0B4E.2050403@oracle.com> Message-ID: > Rhino is not necessary for OpenJDK to build & run, so it doesn't really > belong in the OpenJDK code base. jrunscript require it (and is built in OpenJDK 7). And Mozilla Rhino is mentioned to be included also. From luchsh at linux.vnet.ibm.com Mon Nov 14 00:40:01 2011 From: luchsh at linux.vnet.ibm.com (Jonathan Lu) Date: Mon, 14 Nov 2011 16:40:01 +0800 Subject: Patch to expand tz checking scope in TimeZone_md.c In-Reply-To: <4EBB4062.8050403@intricatesoftware.com> References: <4EB105D1.9020401@linux.vnet.ibm.com> <4EB106E5.9060706@linux.vnet.ibm.com> <4EB122BE.5090302@oracle.com> <4EB12BF4.9010805@linux.vnet.ibm.com> <4EB15356.9080209@oracle.com> <4EB23FD5.60108@linux.vnet.ibm.com> <4EB3664C.1050908@oracle.com> <4EB36FD3.3030306@oracle.com> <4EB37782.9010507@oracle.com> <4EBA336F.9060004@linux.vnet.ibm.com> <4EBB4062.8050403@intricatesoftware.com> Message-ID: <4EC0D3E1.6080807@linux.vnet.ibm.com> Hi Kurt, On 11/10/2011 11:09 AM, Kurt Miller wrote: > On 11/09/11 03:01, Jonathan Lu wrote: >> On 11/04/2011 01:26 PM, David Holmes wrote: >>> On 4/11/2011 2:53 PM, David Holmes wrote: >>>> On 4/11/2011 2:13 PM, Masayoshi Okutsu wrote: >>>>> Probably the difference isn't documented. I tried Solaris 10 and Ubuntu >>>>> 10.03. The difference still exists. >>>>> >>>>> Solaris 10: >>>>> $ unset TZ >>>>> $ date >>>>> Fri Nov 4 13:04:45 JST 2011 >>>>> $ TZ="" date >>>>> Fri Nov 4 13:04:53 JST 2011 >>>>> >>>>> Ubuntu 10.04: >>>>> $ unset TZ >>>>> $ date >>>>> Fri Nov 4 13:05:50 JST 2011 >>>>> $ TZ="" date >>>>> Fri Nov 4 04:05:55 UTC 2011 >>>>> >>>>> When the TZ value is an empty string, Ubuntu uses UTC while Solaris >>>>> still looks up the system default. >>>> I have to take back my comment regarding this not seeming to be platform >>>> specific code - it is highly platform specific! It seems that on Linux >>>> we are happy to report a TZ of "" but not so on Solaris. I presume this >>>> is an attempt to keep Java's use of TZ consistent with how other apps >>>> handle it on that platform. (environ(5) gives a little insight on >>>> Solaris as to how TZ is used.) >>>> >>>> So the key thing here is to not disturb the existing behaviour on either >>>> linux or Solaris - which suggests the original patch. That said I'm not >>>> convinced - given this is so platform specific - that simply treating >>>> non-linux the same as Solaris is a reasonable thing to do. I think it >>>> would be useful to see what the BSD/OSX port(s) had to do with this code >>>> - if anything. >>> To answer my own queries BSD/OSX does >>> >>> 511 #if defined(__linux__) || defined(_ALLBSD_SOURCE) >>> 512 if (tz == NULL) { >>> 513 #else >>> 514 #ifdef __solaris__ >>> 515 if (tz == NULL || *tz == '\0') { >>> 516 #endif >>> 517 #endif >>> >>> so the suggested patch would at least not interfere. >>> >>> Anyway this needs input from other core-libs folk. I didn't intend to >>> get quite so heavily involved. ;-) >>> >>> David >>> ----- >>> >>> >>> >>>> David >>>> ----- >>>> >>>> >>>>> Thanks, >>>>> Masayoshi >>>>> >>>>> On 11/3/2011 4:16 PM, Jonathan Lu wrote: >>>>>> Hi Masayoshi, >>>>>> >>>>>> I did find some references about date-time related functions / TZ >>>>>> variables on Linux but got only a few about Solaris, so could not see >>>>>> any differences between those two platforms about the changes >>>>>> described in my patch. Have you got any links or references about >>>>>> these differences? I'm interested in it and may update the patch again >>>>>> after reading them. >>>>>> >>>>>> Thanks a lot! >>>>>> - Jonathan >>>>>> >>>>>> On 11/02/2011 10:27 PM, Masayoshi Okutsu wrote: >>>>>>> Hi Jonathan, >>>>>>> >>>>>>> IIRC, the difference came from some behavioral difference between the >>>>>>> Linux and Solaris libc date-time functions and/or the date command, >>>>>>> and TimeZone_md.c tries to follow the difference. But the code was >>>>>>> written looooong ago. The difference may no longer exist. >>>>>>> >>>>>>> Thanks, >>>>>>> Masayoshi >>>>>>> >>>>>>> On 11/2/2011 8:39 PM, Jonathan Lu wrote: >>>>>>>> On 11/02/2011 07:00 PM, David Holmes wrote: >>>>>>>>> On 2/11/2011 7:01 PM, Jonathan Lu wrote: >>>>>>>>>> On 11/02/2011 04:56 PM, Jonathan Lu wrote: >>>>>>>>>>> Hi core-libs-dev, >>>>>>>>>>> >>>>>>>>>>> In jdk/src/solaris/native/java/util/TimeZone_md.c, starting from >>>>>>>>>>> line >>>>>>>>>>> 626, I found that the scope of "#ifdef __solaris__" might be too >>>>>>>>>>> narrow, since it also works for some kind of OS which I'm >>>>>>>>>>> currently >>>>>>>>>>> working on, such as AIX. >>>>>>>>>>> So I suggest to just remove the '#ifdef __solaris__' and leave >>>>>>>>>>> the >>>>>>>>>>> "#else" to accommodate more conditions, see attachment >>>>>>>>>>> 'patch.diff'. I >>>>>>>>>>> think this may enhance the cross-platform ability, any ideas >>>>>>>>>>> about >>>>>>>>>>> this modification? >>>>>>>>>>> >>>>>>>>>>> Regards >>>>>>>>>>> - Jonathan Lu >>>>>>>>>> I'm not sure why the attachment got filtered, here paste it to the >>>>>>>>>> mail >>>>>>>>>> content directly. >>>>>>>>>> >>>>>>>>>> diff -r 4788745572ef src/solaris/native/java/util/TimeZone_md.c >>>>>>>>>> --- a/src/solaris/native/java/util/TimeZone_md.c Mon Oct 17 >>>>>>>>>> 19:06:53 >>>>>>>>>> 2011 -0700 >>>>>>>>>> +++ b/src/solaris/native/java/util/TimeZone_md.c Thu Oct 20 >>>>>>>>>> 13:43:47 >>>>>>>>>> 2011 +0800 >>>>>>>>>> @@ -626,10 +626,8 @@ >>>>>>>>>> #ifdef __linux__ >>>>>>>>>> if (tz == NULL) { >>>>>>>>>> #else >>>>>>>>>> -#ifdef __solaris__ >>>>>>>>>> if (tz == NULL || *tz == '\0') { >>>>>>>>>> #endif >>>>>>>>>> -#endif >>>>>>>>>> tz = getPlatformTimeZoneID(); >>>>>>>>>> freetz = tz; >>>>>>>>>> } >>>>>>>>> I'm unclear why any of that code needs to be platform specific - is >>>>>>>>> an empty TZ string somehow valid on linux? I would have thought the >>>>>>>>> following would be platform neutral: >>>>>>>>> >>>>>>>>> if (tz == NULL || *tz == '\0') { >>>>>>>>> tz = getPlatformTimeZoneID(); >>>>>>>>> freetz = tz; >>>>>>>>> } >>>>>>>>> >>>>>>>> Hi David, >>>>>>>> >>>>>>>> getenv("TZ") returns NULL when TZ environment variable is not set at >>>>>>>> all and returns '\0' when TZ was exported as empty string. After >>>>>>>> more checking for both cases, I agree with you, nothing useful can >>>>>>>> be retrieved from that environment variable. >>>>>>>> So I changed the patch to this, >>>>>>>> >>>>>>>> diff -r 7ab0d613cd1a src/solaris/native/java/util/TimeZone_md.c >>>>>>>> --- a/src/solaris/native/java/util/TimeZone_md.c Thu Oct 20 10:32:47 >>>>>>>> 2011 -0700 >>>>>>>> +++ b/src/solaris/native/java/util/TimeZone_md.c Wed Nov 02 19:34:51 >>>>>>>> 2011 +0800 >>>>>>>> @@ -623,13 +623,7 @@ >>>>>>>> >>>>>>>> tz = getenv("TZ"); >>>>>>>> >>>>>>>> -#ifdef __linux__ >>>>>>>> - if (tz == NULL) { >>>>>>>> -#else >>>>>>>> -#ifdef __solaris__ >>>>>>>> if (tz == NULL || *tz == '\0') { >>>>>>>> -#endif >>>>>>>> -#endif >>>>>>>> tz = getPlatformTimeZoneID(); >>>>>>>> freetz = tz; >>>>>>>> } >>>>>>>> >>>>>>>>> David >>>>>>>>> ----- >>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> - Jonathan Lu >>>>>>>> Regards >>>>>>>> >>>>>>>> - Jonathan >>>>>>>> >> Copy to bsd-port-dev and macosx-port-dev lists to see if anybody here >> has some ideas about this issue. > Hi Jonathan, > > The above email is a bit hard to follow due to the mixture of top and > bottom replies. > > I can confirm that OpenBSD and Mac OS X 10.5.8 follow the Linux behavior > which confirms the need for platform ifdef's in this code. > > Seems like you need to make the following change: > > -#ifdef __solaris__ > +#if defined(__solaris__) || defined(__AIX__) > > or something similar to maintain compatibility. > > In general the approach taken for adding BSD support was to never > assume you can change other supported code paths. If your architecture > follows an existing code path behavior add it like I did above. > Otherwise just create a #ifdef myarch section for it. > But for this case, I think it is a good idea to leave a default code path here. Since in src/solaris/native/java/util/TimeZone_md.c starting from line 624, the return value of getenv("TZ"); has to be tested afterward on any platforms. So to improve portability for OpenJDK, how about leaving Solaris style checking as the default approach? > Unifying or changing another architecture's code path requires access > to the arch, research and confirmation that the change is ok. Typically > this may be done by writing independent test programs and running them > on each arch. > > Regards, > -Kurt > > > From kurt at intricatesoftware.com Mon Nov 14 10:22:39 2011 From: kurt at intricatesoftware.com (Kurt Miller) Date: Mon, 14 Nov 2011 14:22:39 -0400 Subject: Patch to expand tz checking scope in TimeZone_md.c In-Reply-To: <4EC0D3E1.6080807@linux.vnet.ibm.com> References: <4EB105D1.9020401@linux.vnet.ibm.com> <4EBB4062.8050403@intricatesoftware.com> <4EC0D3E1.6080807@linux.vnet.ibm.com> Message-ID: <201111141322.40010.kurt@intricatesoftware.com> On Monday 14 November 2011 03:40:01 am Jonathan Lu wrote: > Hi Kurt, > > On 11/10/2011 11:09 AM, Kurt Miller wrote: > > On 11/09/11 03:01, Jonathan Lu wrote: > >> On 11/04/2011 01:26 PM, David Holmes wrote: > >>> On 4/11/2011 2:53 PM, David Holmes wrote: > >>>> On 4/11/2011 2:13 PM, Masayoshi Okutsu wrote: > >>>>> Probably the difference isn't documented. I tried Solaris 10 and Ubuntu > >>>>> 10.03. The difference still exists. > >>>>> > >>>>> Solaris 10: > >>>>> $ unset TZ > >>>>> $ date > >>>>> Fri Nov 4 13:04:45 JST 2011 > >>>>> $ TZ="" date > >>>>> Fri Nov 4 13:04:53 JST 2011 > >>>>> > >>>>> Ubuntu 10.04: > >>>>> $ unset TZ > >>>>> $ date > >>>>> Fri Nov 4 13:05:50 JST 2011 > >>>>> $ TZ="" date > >>>>> Fri Nov 4 04:05:55 UTC 2011 > >>>>> > >>>>> When the TZ value is an empty string, Ubuntu uses UTC while Solaris > >>>>> still looks up the system default. > >>>> I have to take back my comment regarding this not seeming to be platform > >>>> specific code - it is highly platform specific! It seems that on Linux > >>>> we are happy to report a TZ of "" but not so on Solaris. I presume this > >>>> is an attempt to keep Java's use of TZ consistent with how other apps > >>>> handle it on that platform. (environ(5) gives a little insight on > >>>> Solaris as to how TZ is used.) > >>>> > >>>> So the key thing here is to not disturb the existing behaviour on either > >>>> linux or Solaris - which suggests the original patch. That said I'm not > >>>> convinced - given this is so platform specific - that simply treating > >>>> non-linux the same as Solaris is a reasonable thing to do. I think it > >>>> would be useful to see what the BSD/OSX port(s) had to do with this code > >>>> - if anything. > >>> To answer my own queries BSD/OSX does > >>> > >>> 511 #if defined(__linux__) || defined(_ALLBSD_SOURCE) > >>> 512 if (tz == NULL) { > >>> 513 #else > >>> 514 #ifdef __solaris__ > >>> 515 if (tz == NULL || *tz == '\0') { > >>> 516 #endif > >>> 517 #endif > >>> > >>> so the suggested patch would at least not interfere. > >>> > >>> Anyway this needs input from other core-libs folk. I didn't intend to > >>> get quite so heavily involved. ;-) > >>> > >>> David > >>> ----- > >>> > >>> > >>> > >>>> David > >>>> ----- > >>>> > >>>> > >>>>> Thanks, > >>>>> Masayoshi > >>>>> > >>>>> On 11/3/2011 4:16 PM, Jonathan Lu wrote: > >>>>>> Hi Masayoshi, > >>>>>> > >>>>>> I did find some references about date-time related functions / TZ > >>>>>> variables on Linux but got only a few about Solaris, so could not see > >>>>>> any differences between those two platforms about the changes > >>>>>> described in my patch. Have you got any links or references about > >>>>>> these differences? I'm interested in it and may update the patch again > >>>>>> after reading them. > >>>>>> > >>>>>> Thanks a lot! > >>>>>> - Jonathan > >>>>>> > >>>>>> On 11/02/2011 10:27 PM, Masayoshi Okutsu wrote: > >>>>>>> Hi Jonathan, > >>>>>>> > >>>>>>> IIRC, the difference came from some behavioral difference between the > >>>>>>> Linux and Solaris libc date-time functions and/or the date command, > >>>>>>> and TimeZone_md.c tries to follow the difference. But the code was > >>>>>>> written looooong ago. The difference may no longer exist. > >>>>>>> > >>>>>>> Thanks, > >>>>>>> Masayoshi > >>>>>>> > >>>>>>> On 11/2/2011 8:39 PM, Jonathan Lu wrote: > >>>>>>>> On 11/02/2011 07:00 PM, David Holmes wrote: > >>>>>>>>> On 2/11/2011 7:01 PM, Jonathan Lu wrote: > >>>>>>>>>> On 11/02/2011 04:56 PM, Jonathan Lu wrote: > >>>>>>>>>>> Hi core-libs-dev, > >>>>>>>>>>> > >>>>>>>>>>> In jdk/src/solaris/native/java/util/TimeZone_md.c, starting from > >>>>>>>>>>> line > >>>>>>>>>>> 626, I found that the scope of "#ifdef __solaris__" might be too > >>>>>>>>>>> narrow, since it also works for some kind of OS which I'm > >>>>>>>>>>> currently > >>>>>>>>>>> working on, such as AIX. > >>>>>>>>>>> So I suggest to just remove the '#ifdef __solaris__' and leave > >>>>>>>>>>> the > >>>>>>>>>>> "#else" to accommodate more conditions, see attachment > >>>>>>>>>>> 'patch.diff'. I > >>>>>>>>>>> think this may enhance the cross-platform ability, any ideas > >>>>>>>>>>> about > >>>>>>>>>>> this modification? > >>>>>>>>>>> > >>>>>>>>>>> Regards > >>>>>>>>>>> - Jonathan Lu > >>>>>>>>>> I'm not sure why the attachment got filtered, here paste it to the > >>>>>>>>>> mail > >>>>>>>>>> content directly. > >>>>>>>>>> > >>>>>>>>>> diff -r 4788745572ef src/solaris/native/java/util/TimeZone_md.c > >>>>>>>>>> --- a/src/solaris/native/java/util/TimeZone_md.c Mon Oct 17 > >>>>>>>>>> 19:06:53 > >>>>>>>>>> 2011 -0700 > >>>>>>>>>> +++ b/src/solaris/native/java/util/TimeZone_md.c Thu Oct 20 > >>>>>>>>>> 13:43:47 > >>>>>>>>>> 2011 +0800 > >>>>>>>>>> @@ -626,10 +626,8 @@ > >>>>>>>>>> #ifdef __linux__ > >>>>>>>>>> if (tz == NULL) { > >>>>>>>>>> #else > >>>>>>>>>> -#ifdef __solaris__ > >>>>>>>>>> if (tz == NULL || *tz == '\0') { > >>>>>>>>>> #endif > >>>>>>>>>> -#endif > >>>>>>>>>> tz = getPlatformTimeZoneID(); > >>>>>>>>>> freetz = tz; > >>>>>>>>>> } > >>>>>>>>> I'm unclear why any of that code needs to be platform specific - is > >>>>>>>>> an empty TZ string somehow valid on linux? I would have thought the > >>>>>>>>> following would be platform neutral: > >>>>>>>>> > >>>>>>>>> if (tz == NULL || *tz == '\0') { > >>>>>>>>> tz = getPlatformTimeZoneID(); > >>>>>>>>> freetz = tz; > >>>>>>>>> } > >>>>>>>>> > >>>>>>>> Hi David, > >>>>>>>> > >>>>>>>> getenv("TZ") returns NULL when TZ environment variable is not set at > >>>>>>>> all and returns '\0' when TZ was exported as empty string. After > >>>>>>>> more checking for both cases, I agree with you, nothing useful can > >>>>>>>> be retrieved from that environment variable. > >>>>>>>> So I changed the patch to this, > >>>>>>>> > >>>>>>>> diff -r 7ab0d613cd1a src/solaris/native/java/util/TimeZone_md.c > >>>>>>>> --- a/src/solaris/native/java/util/TimeZone_md.c Thu Oct 20 10:32:47 > >>>>>>>> 2011 -0700 > >>>>>>>> +++ b/src/solaris/native/java/util/TimeZone_md.c Wed Nov 02 19:34:51 > >>>>>>>> 2011 +0800 > >>>>>>>> @@ -623,13 +623,7 @@ > >>>>>>>> > >>>>>>>> tz = getenv("TZ"); > >>>>>>>> > >>>>>>>> -#ifdef __linux__ > >>>>>>>> - if (tz == NULL) { > >>>>>>>> -#else > >>>>>>>> -#ifdef __solaris__ > >>>>>>>> if (tz == NULL || *tz == '\0') { > >>>>>>>> -#endif > >>>>>>>> -#endif > >>>>>>>> tz = getPlatformTimeZoneID(); > >>>>>>>> freetz = tz; > >>>>>>>> } > >>>>>>>> > >>>>>>>>> David > >>>>>>>>> ----- > >>>>>>>>> > >>>>>>>>>> Regards > >>>>>>>>>> - Jonathan Lu > >>>>>>>> Regards > >>>>>>>> > >>>>>>>> - Jonathan > >>>>>>>> > >> Copy to bsd-port-dev and macosx-port-dev lists to see if anybody here > >> has some ideas about this issue. > > Hi Jonathan, > > > > The above email is a bit hard to follow due to the mixture of top and > > bottom replies. > > > > I can confirm that OpenBSD and Mac OS X 10.5.8 follow the Linux behavior > > which confirms the need for platform ifdef's in this code. > > > > Seems like you need to make the following change: > > > > -#ifdef __solaris__ > > +#if defined(__solaris__) || defined(__AIX__) > > > > or something similar to maintain compatibility. > > > > In general the approach taken for adding BSD support was to never > > assume you can change other supported code paths. If your architecture > > follows an existing code path behavior add it like I did above. > > Otherwise just create a #ifdef myarch section for it. > > > > But for this case, I think it is a good idea to leave a default code > path here. > Since in src/solaris/native/java/util/TimeZone_md.c starting from line > 624, the return value of getenv("TZ"); has to be tested afterward on any > platforms. > So to improve portability for OpenJDK, how about leaving Solaris style > checking as the default approach? Ah I see what you're getting at now. As a bsd-port only committer my opinion has limited value, but for what its worth I can give you my perspective on the issue. The code base is large and there are many places like this where unifying the behavior of different archs is the goal. Keeping with the non-configure approach where ifdef __MYARCH__ is used for differing behaviors then I see the ideal situation being that the porter/developer is required to make the correct choice for the new __MYARCH__ and no default be assumed. If a default behavior is assumed, which one do you pick? Also what happens when your done porting but many of the defaults don't match your new arch? I can tell you it is a lot of work to find the bits of code embedded into the jdk code base to fix when the TCK fails tests. I rather do that work up front and be forced to pick the correct behavior due to a failure to compile. For example, had this code compiled for you it is quite posible you would not have know that there are different behaviors to pick from and to select the correct one for you. Regards, -Kurt From dalibor.topic at oracle.com Wed Nov 23 05:30:51 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Wed, 23 Nov 2011 14:30:51 +0100 Subject: bsd-port still in b147 In-Reply-To: <20111103030146.GA95883@misty.eyesbeyond.com> References: <20111031215324.GE10762@rivendell.middle-earth.co.uk> <20111103030146.GA95883@misty.eyesbeyond.com> Message-ID: <4ECCF58B.3000307@oracle.com> On 11/3/11 4:01 AM, Greg Lewis wrote: >> The numerous jdk7ux trees seem to continue but with new versioning (jdk7u2-b10 at present): >> >> http://hg.openjdk.java.net/jdk7u/jdk7u-dev/ > > Buth these are not GPL'ed correct? They are. JDK 7 Updates are now done in OpenJDK in the JDK 7 Updates Project, as Oracle JDK 7 is based on OpenJDK 7. See the Q&A at http://openjdk.java.net/projects/jdk7u/qanda.html for more details, or feel free to ask on jdk7u-dev! cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From henri.gomez at gmail.com Wed Nov 23 07:36:28 2011 From: henri.gomez at gmail.com (Henri Gomez) Date: Wed, 23 Nov 2011 16:36:28 +0100 Subject: bsd-port still in b147 In-Reply-To: <4ECCF58B.3000307@oracle.com> References: <20111031215324.GE10762@rivendell.middle-earth.co.uk> <20111103030146.GA95883@misty.eyesbeyond.com> <4ECCF58B.3000307@oracle.com> Message-ID: 2011/11/23 Dalibor Topic : > On 11/3/11 4:01 AM, Greg Lewis wrote: >>> The numerous jdk7ux trees seem to continue but with new versioning (jdk7u2-b10 at present): >>> >>> http://hg.openjdk.java.net/jdk7u/jdk7u-dev/ >> >> Buth these are not GPL'ed correct? > > They are. JDK 7 Updates are now done in OpenJDK in the JDK 7 Updates Project, as Oracle JDK 7 > is based on OpenJDK 7. See the Q&A at http://openjdk.java.net/projects/jdk7u/qanda.html for > more details, or feel free to ask on jdk7u-dev! What about adding bsd in mainstream ? It will help providing OpenJDK 7 (u2/u4) and OpenJDK 8 for OSX for example. For now, I can build bsd-port and macosx-port of OpenJDK 7 and OpenJDK 8 with MLVM (with bsd patches), but can build u2/u4 or OpenJDK 8 Lamba for OSX since bsd support (minimal for OS/X) is lacking from there ;( From glewis at eyesbeyond.com Mon Nov 28 19:36:37 2011 From: glewis at eyesbeyond.com (Greg Lewis) Date: Mon, 28 Nov 2011 19:36:37 -0800 Subject: bsd-port still in b147 In-Reply-To: References: <20111031215324.GE10762@rivendell.middle-earth.co.uk> <20111103030146.GA95883@misty.eyesbeyond.com> <4ECCF58B.3000307@oracle.com> Message-ID: <20111129033637.GA89227@misty.eyesbeyond.com> On Wed, Nov 23, 2011 at 04:36:28PM +0100, Henri Gomez wrote: > 2011/11/23 Dalibor Topic : > > On 11/3/11 4:01 AM, Greg Lewis wrote: > >>> The numerous jdk7ux trees seem to continue but with new versioning (jdk7u2-b10 at present): > >>> > >>> http://hg.openjdk.java.net/jdk7u/jdk7u-dev/ > >> > >> Buth these are not GPL'ed correct? > > > > They are. JDK 7 Updates are now done in OpenJDK in the JDK 7 Updates Project, as Oracle JDK 7 > > is based on OpenJDK 7. See the Q&A at http://openjdk.java.net/projects/jdk7u/qanda.html for > > more details, or feel free to ask on jdk7u-dev! Thanks Dalibor, that's good to know! > What about adding bsd in mainstream ? > > It will help providing OpenJDK 7 (u2/u4) and OpenJDK 8 for OSX for example. > > For now, I can build bsd-port and macosx-port of OpenJDK 7 and OpenJDK > 8 with MLVM (with bsd patches), but can build u2/u4 or OpenJDK 8 Lamba > for OSX since bsd support (minimal for OS/X) is lacking from there ;( I'm going to try and pull this into my local copy of the bsd-port repo and see how that goes. If it goes well I'll merge and push. Then we'll be in much better shape in terms of security, etc. -- Greg Lewis Email : glewis at eyesbeyond.com Eyes Beyond Web : http://www.eyesbeyond.com Information Technology FreeBSD : glewis at FreeBSD.org From dalibor.topic at oracle.com Wed Nov 30 06:12:43 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Wed, 30 Nov 2011 15:12:43 +0100 Subject: bsd-port still in b147 In-Reply-To: <20111129033637.GA89227@misty.eyesbeyond.com> References: <20111031215324.GE10762@rivendell.middle-earth.co.uk> <20111103030146.GA95883@misty.eyesbeyond.com> <4ECCF58B.3000307@oracle.com> <20111129033637.GA89227@misty.eyesbeyond.com> Message-ID: <4ED639DB.4000901@oracle.com> On 11/29/11 4:36 AM, Greg Lewis wrote: > I'm going to try and pull this into my local copy of the bsd-port repo and > see how that goes. If it goes well I'll merge and push. Then we'll be in > much better shape in terms of security, etc. > Great to hear! I think this should be easier to follow (and sync with) then OpenJDK 6 was. I'd suggest syncing up with release (i.e. phase 2) branches, as they get turned into actual update releases - so syncing with jdk7u/jdk7u2 right now, and switching over with jdk7u/jdk7u4 once that gets created when we enter phase 2 of 7u4. cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 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 henri.gomez at gmail.com Wed Nov 30 06:36:04 2011 From: henri.gomez at gmail.com (Henri Gomez) Date: Wed, 30 Nov 2011 15:36:04 +0100 Subject: bsd-port still in b147 In-Reply-To: <4ED639DB.4000901@oracle.com> References: <20111031215324.GE10762@rivendell.middle-earth.co.uk> <20111103030146.GA95883@misty.eyesbeyond.com> <4ECCF58B.3000307@oracle.com> <20111129033637.GA89227@misty.eyesbeyond.com> <4ED639DB.4000901@oracle.com> Message-ID: > Great to hear! I think this should be easier to follow (and sync with) then > OpenJDK 6 was. I'd suggest syncing up with release (i.e. phase 2) branches, > as they get turned into actual update releases - so syncing with jdk7u/jdk7u2 > right now, and switching over with jdk7u/jdk7u4 once that gets created when > we enter phase 2 of 7u4. And a wish, sync with OpenJDK 8 :-) From dalibor.topic at oracle.com Wed Nov 30 07:23:12 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Wed, 30 Nov 2011 16:23:12 +0100 Subject: bsd-port still in b147 In-Reply-To: References: <20111031215324.GE10762@rivendell.middle-earth.co.uk> <20111103030146.GA95883@misty.eyesbeyond.com> <4ECCF58B.3000307@oracle.com> Message-ID: <4ED64A60.5080109@oracle.com> On 11/23/11 4:36 PM, Henri Gomez wrote: > 2011/11/23 Dalibor Topic : >> On 11/3/11 4:01 AM, Greg Lewis wrote: >>>> The numerous jdk7ux trees seem to continue but with new versioning (jdk7u2-b10 at present): >>>> >>>> http://hg.openjdk.java.net/jdk7u/jdk7u-dev/ >>> >>> Buth these are not GPL'ed correct? >> >> They are. JDK 7 Updates are now done in OpenJDK in the JDK 7 Updates Project, as Oracle JDK 7 >> is based on OpenJDK 7. See the Q&A at http://openjdk.java.net/projects/jdk7u/qanda.html for >> more details, or feel free to ask on jdk7u-dev! > > What about adding bsd in mainstream ? As I said over on the macosx-port-dev list [0], I think it would better to get the Mac OS X port into jdk7u first, and then once that's all working like a charm, for the BSD porters to integrate the changes back, and start looking at what (else) would need to be done to get the BSD port on one of the different *BSDs to pass the TCK. So I would expect the BSD port to quite happily continue for a while on its own while the Mac OS X port gets pulled into jdk7u forests. cheers, dalibor topic [0] http://mail.openjdk.java.net/pipermail/macosx-port-dev/2011-November/001562.html -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 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 henri.gomez at gmail.com Wed Nov 30 07:27:16 2011 From: henri.gomez at gmail.com (Henri Gomez) Date: Wed, 30 Nov 2011 16:27:16 +0100 Subject: bsd-port still in b147 In-Reply-To: <4ED64A60.5080109@oracle.com> References: <20111031215324.GE10762@rivendell.middle-earth.co.uk> <20111103030146.GA95883@misty.eyesbeyond.com> <4ECCF58B.3000307@oracle.com> <4ED64A60.5080109@oracle.com> Message-ID: > As I said over on the macosx-port-dev list [0], I think it would better to get the Mac OS X port > into jdk7u first, and then once that's all working like a charm, for the BSD porters to integrate > the changes back, and start looking at what (else) would need to be done to get the BSD port on one > of the different *BSDs to pass the TCK. So I would expect the BSD port to quite happily continue for > a while on its own while the Mac OS X port gets pulled into jdk7u forests. Of course, better stock OSX for OSX packages. Let's wait 2012 (u4 roadmap). :) From rensato at hotmail.com Tue Nov 8 05:54:01 2011 From: rensato at hotmail.com (Ren Sato) Date: Tue, 08 Nov 2011 13:54:01 -0000 Subject: LIB_JPEG_UNDEFINED openjdk build from ports Message-ID: I am getting "LIB_JPEG_UNDEFINED" on a "make install clean" from openjdk7 port on freebsd 9.0 rc1. i notice that my /usr/local/lib/libjpeg is 8 (iirc). and guess/understand openjdk7 is looking for 6.2. (or libjpeg-devel) from snippets i have found on the internet. is this correct? if so can i force it to use 8? or do i need to compile the 6.2 lib (as there is no port). I am away from build machine so I do not have more specific details and some details may not be 100% correct but I hope to hear from anyone if they are familiar with this. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20111108/e7fdb21c/attachment.html