From quanah at zimbra.com Thu Nov 12 03:42:23 2015 From: quanah at zimbra.com (Quanah Gibson-Mount) Date: Wed, 11 Nov 2015 19:42:23 -0800 Subject: Coherent release process Message-ID: <72EC8BBA6F43AD603B3286DF@[192.168.1.9]> Hi, I was wondering if/when the OpenJDK project may develop a more coherent release plan? Right now, there seems to be no consistent strategy, which makes it very difficult for downstream consumers of OpenJDK to be able to reliably build out new OpenJDK releases. While I appreciate that the process has become easier with OpenJDK 8 vs the prior OpenJDK versions, right now the build process for new releases, particularly critical security updates, seems quite the mess. For example: To build OpenJDK 1.8u66, you have to use the jdk8u (JDK 8 Updates Master) branch (doesn't make sense) To build OpenJDK 1.8u60, you use the jdk8u60 release branch (makes sense) To build OpenJDK 1.8u51, you use the jdk8u60-dev branch (doesn't make sense) The lack of consistency among branches for different releases makes it extremely hard to create a well defined build process for OpenJDK. In addition the fact that the bug system is locked down makes it extremely hard to report issues back upstream, such as the fact that the hgforest.sh script doesn't correctly honor command arguments, meaning that it has to be patched to get a consistent build of the downstream modules that get checked out. The following patch fixes this rather significant problem. As we rely heavily on being able to provide up to date, consistent, secure OpenJDK builds to our customers, having the process to build new releases be reliable is of significant importance. I imagine that is the case for many others as well. Thanks for your time and consideration, Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration From dalibor.topic at oracle.com Thu Nov 12 14:53:18 2015 From: dalibor.topic at oracle.com (dalibor topic) Date: Thu, 12 Nov 2015 15:53:18 +0100 Subject: Coherent release process In-Reply-To: <72EC8BBA6F43AD603B3286DF@[192.168.1.9]> References: <72EC8BBA6F43AD603B3286DF@[192.168.1.9]> Message-ID: <5644A7DE.2020605@oracle.com> On 12.11.2015 04:42, Quanah Gibson-Mount wrote: > if/when the OpenJDK project may develop a more coherent release plan? You can find the plans for JDK 9 at http://openjdk.java.net/projects/jdk9/ . The plans for JDK 8 Updates are linked off the Project page of the corresponding JDK 8 Updates Project in the OpenJDK Community at http://openjdk.java.net/projects/jdk8u/ . The corresponding Project's mailing list, jdk8u-dev, is the right place to ask questions about JDK 8 Updates in OpenJDK. The JDK 8 Project has completed its work with the JDK 8 GA a while ago, so this list is largely dormant. > The lack of consistency among branches for different releases makes > it extremely hard to create a well defined build process for OpenJDK. The separate Mercurial forests existed for the convenience of developing multiple releases with a large number of changes and features in parallel within a single OpenJDK Project (just as was the case for the JDK 7 Updates Project, fwiw). For reasons discussed back in July, the JDK 8 Updates Project in OpenJDK no longer needs to do that. Accordingly, the jdk8u master and dev forests are adequate for our current needs. Please see http://mail.openjdk.java.net/pipermail/jdk8u-dev/2015-July/003985.html for details. If for some reason you strive to create your own build process for JDK 8 Updates, I'd suggest subscribing at least to the jdk8u-dev, jdk9-dev and build-dev mailing lists. Instructions for checking out the code for the latest release developed within the JDK 8 Updates Project in OpenJDK can be found on the Project's web page. Please keep in mind that CPU releases like 8u51 are not developed within OpenJDK Projects. > In addition the fact that the bug system is locked down Please consult the "Account Eligibility" section of https://wiki.openjdk.java.net/display/general/JBS+Overview for the facts. If you are not eligible for an account on JBS, because you're not an OpenJDK developer with an adequate role, you may still file issues through the web interface at bugs.java.com. > The following patch fixes this Please see http://openjdk.java.net/contribute/ for how to contribute to OpenJDK Projects, and note in particular the requirements spelled out in section 0. Of particular note for the contribution flow to the JDK 8 Updates Project is that changes to it will typically go through JDK 9 first. So once your organization meets the requirements spelled out in the guide above, I'd suggest adjusting, testing and sending your proposed patch as plain text within an e-mail to the build-dev mailing list for JDK 9 first. Once it has been reviewed and pushed there, then you can follow up with a backport for the JDK 8 Updates Project. Details on the backport process can be found at the JDK 8 Updates page linked above. > As we rely heavily on being able to provide up to date, consistent, > secure OpenJDK builds to our customers Unfortunately, I don't see your organization listed at http://www.oracle.com/technetwork/community/oca-486395.html so I'd like to again refer you to the guide for contributing to OpenJDK linked above. cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 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 Oracle is committed to developing practices and products that help protect the environment From cdelunasaenz at yahoo.com.mx Thu Nov 12 15:18:44 2015 From: cdelunasaenz at yahoo.com.mx (Carlos de Luna Saenz) Date: Thu, 12 Nov 2015 15:18:44 +0000 (UTC) Subject: Coherent release process In-Reply-To: <5644A7DE.2020605@oracle.com> References: <5644A7DE.2020605@oracle.com> Message-ID: <341172378.3868280.1447341524085.JavaMail.yahoo@mail.yahoo.com> I'm sure this topic has arise sooner here... but PPAPI is being considered... lot of oraganizations relies on Java applets for key based authentication and is a very important deal... If you can clear me on what's the future of applets fron open JDK perspective i will appreciate it.Greetings De: dalibor topic Para: jdk8-dev at openjdk.java.net Enviado: Jueves, 12 de noviembre, 2015 8:53:18 Asunto: Re: Coherent release process On 12.11.2015 04:42, Quanah Gibson-Mount wrote: > if/when the OpenJDK project may develop a more coherent release plan? You can find the plans for JDK 9 at http://openjdk.java.net/projects/jdk9/ . The plans for JDK 8 Updates are linked off the Project page of the corresponding JDK 8 Updates Project in the OpenJDK Community at http://openjdk.java.net/projects/jdk8u/ . The corresponding Project's mailing list, jdk8u-dev, is the right place to ask questions about JDK 8 Updates in OpenJDK. The JDK 8 Project has completed its work with the JDK 8 GA a while ago, so this list is largely dormant. > The lack of consistency among branches for different releases makes > it extremely hard to create a well defined build process for OpenJDK. The separate Mercurial forests existed for the convenience of developing multiple releases with a large number of changes and features in parallel within a single OpenJDK Project (just as was the case for the JDK 7 Updates Project, fwiw). For reasons discussed back in July, the JDK 8 Updates Project in OpenJDK no longer needs to do that. Accordingly, the jdk8u master and dev forests are adequate for our current needs. Please see http://mail.openjdk.java.net/pipermail/jdk8u-dev/2015-July/003985.html for details. If for some reason you strive to create your own build process for JDK 8 Updates, I'd suggest subscribing at least to the jdk8u-dev, jdk9-dev and build-dev mailing lists. Instructions for checking out the code for the latest release developed within the JDK 8 Updates Project in OpenJDK can be found on the Project's web page. Please keep in mind that CPU releases like 8u51 are not developed within OpenJDK Projects. > In addition the fact that the bug system is locked down Please consult the "Account Eligibility" section of https://wiki.openjdk.java.net/display/general/JBS+Overview for the facts. If you are not eligible for an account on JBS, because you're not an OpenJDK developer with an adequate role, you may still file issues through the web interface at bugs.java.com. > The following patch fixes this Please see http://openjdk.java.net/contribute/ for how to contribute to OpenJDK Projects, and note in particular the requirements spelled out in section 0. Of particular note for the contribution flow to the JDK 8 Updates Project is that changes to it will typically go through JDK 9 first. So once your organization meets the requirements spelled out in the guide above, I'd suggest adjusting, testing and sending your proposed patch as plain text within an e-mail to the build-dev mailing list for JDK 9 first. Once it has been reviewed and pushed there, then you can follow up with a backport for the JDK 8 Updates Project. Details on the backport process can be found at the JDK 8 Updates page linked above. > As we rely heavily on being able to provide up to date, consistent, > secure OpenJDK builds to our customers Unfortunately, I don't see your organization listed at http://www.oracle.com/technetwork/community/oca-486395.html so I'd like to again refer you to the guide for contributing to OpenJDK linked above. cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 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 Oracle is committed to developing practices and products that help protect the environment From dalibor.topic at oracle.com Thu Nov 12 18:21:45 2015 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Thu, 12 Nov 2015 19:21:45 +0100 Subject: Coherent release process In-Reply-To: <341172378.3868280.1447341524085.JavaMail.yahoo@mail.yahoo.com> References: <5644A7DE.2020605@oracle.com> <341172378.3868280.1447341524085.JavaMail.yahoo@mail.yahoo.com> Message-ID: <5644D8B9.3010801@oracle.com> On 11/12/15 4:18 PM, Carlos de Luna Saenz wrote: > I'm sure this topic has arise sooner here... but PPAPI is being considered... lot of oraganizations relies on Java applets for key based authentication and is a very important deal... > If you can clear me on what's the future of applets fron open JDK perspective i will appreciate it.Greetings >From the mention of PPAPI I assume that this question is about a browser plugin. There is no implementation of a browser plugin in OpenJDK. cheers, dalibor topic -- Oracle Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 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 gnu.andrew at redhat.com Fri Nov 20 03:34:57 2015 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 19 Nov 2015 22:34:57 -0500 (EST) Subject: Coherent release process In-Reply-To: <72EC8BBA6F43AD603B3286DF@[192.168.1.9]> References: <72EC8BBA6F43AD603B3286DF@[192.168.1.9]> Message-ID: <447666547.12112509.1447990497599.JavaMail.zimbra@redhat.com> [Adding in the 8u mailing list] ----- Original Message ----- > Hi, > > I was wondering if/when the OpenJDK project may develop a more coherent > release plan? Right now, there seems to be no consistent strategy, which > makes it very difficult for downstream consumers of OpenJDK to be able to > reliably build out new OpenJDK releases. While I appreciate that the > process has become easier with OpenJDK 8 vs the prior OpenJDK versions, > right now the build process for new releases, particularly critical > security updates, seems quite the mess. +1. I've said pretty much the same before and it's only got worse of late. The number of people I have to explain it to, even people who actively work on OpenJDK on a daily basis, suggests it's far from obvious. It's nice to know I'm not the only one who feels this way. > > For example: > > To build OpenJDK 1.8u66, you have to use the jdk8u (JDK 8 Updates Master) > branch (doesn't make sense) > To build OpenJDK 1.8u60, you use the jdk8u60 release branch (makes sense) > To build OpenJDK 1.8u51, you use the jdk8u60-dev branch (doesn't make sense) > Actually, that won't get you u66 unless you explicitly check out a tag. The current tip of 8u is currently receiving fixes people are pushing for u76, which I believe is due to be released next April, at the same time as the u75 security update, which will be based on u72. As far as I've been able to grasp, this is the current 8u schedule: October 2015: u65 (security update based on u60) & u66 (feature release) January 2016: u71 (security update based on u66) & u72 (feature release) April 2016: u75 (security update based on u72) & u76 (feature release) July 2016: u81 (security update based on u76) & u82 (feature release) You should be able to get all versions from the 8u tree by checking out appropriate tags. Only 8u65 onwards will be up to date with the latest security fixes. > The lack of consistency among branches for different releases makes it > extremely hard to create a well defined build process for OpenJDK. Moreover, the recent changes, as I've mentioned before, also make it virtually impossible to test something like u72 before it is released. What I witnessed with u66 was the first few builds being pushed to the 8u tree, but later builds did not appear until u66 was released in late October. When I raised this before, it was pointed out that the build could be reconstructed by finding bugs in the bug database that had been tagged as added to the release and backporting them to a checkout of the latest u66 tag myself [0]. Not only is this incredibly time consuming and error prone, but there is no guarantee that the result is the same as what Oracle are testing. I really don't think the OpenJDK project as a whole should suffer because Oracle change their internal processes. > > In addition the fact that the bug system is locked down makes it extremely > hard to report issues back upstream, such as the fact that the hgforest.sh > script doesn't correctly honor command arguments, meaning that it has to be > patched to get a consistent build of the downstream modules that get > checked out. The following patch fixes this rather significant problem. > > > > As we rely heavily on being able to provide up to date, consistent, secure > OpenJDK builds to our customers, having the process to build new releases > be reliable is of significant importance. I imagine that is the case for > many others as well. Another problem I've also observed. I'm happy for you to ping me if you have a patch and need a bug opening (I've done this for colleagues at Red Hat), but as Dalibor mentions in response, the OCA needs to be sorted first. There's not much point opening a bug with a patch if the patch can't be committed for legal reasons. > > Thanks for your time and consideration, > Quanah > > -- > > Quanah Gibson-Mount > Platform Architect > Zimbra, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration > [0] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2015-September/004212.html Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From gnu.andrew at redhat.com Fri Nov 20 03:39:35 2015 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 19 Nov 2015 22:39:35 -0500 (EST) Subject: Coherent release process In-Reply-To: <5644A7DE.2020605@oracle.com> References: <72EC8BBA6F43AD603B3286DF@[192.168.1.9]> <5644A7DE.2020605@oracle.com> Message-ID: <498111152.12112954.1447990775779.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On 12.11.2015 04:42, Quanah Gibson-Mount wrote: > > if/when the OpenJDK project may develop a more coherent release plan? > > You can find the plans for JDK 9 at > http://openjdk.java.net/projects/jdk9/ . The plans for JDK 8 Updates are > linked off the Project page of the corresponding JDK 8 Updates Project > in the OpenJDK Community at http://openjdk.java.net/projects/jdk8u/ . > > The corresponding Project's mailing list, jdk8u-dev, is the right place > to ask questions about JDK 8 Updates in OpenJDK. The JDK 8 Project has > completed its work with the JDK 8 GA a while ago, so this list is > largely dormant. > Is there a good reason for this practice? Having seen this happen with both 7/7u and 8/8u mailing lists, it would seem to make sense to keep one mailing list instead when 9 goes GA, to avoid this confusion. It's things like this that make OpenJDK confusing to new users and I don't see the necessity for it myself. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From quanah at zimbra.com Fri Nov 20 03:45:51 2015 From: quanah at zimbra.com (Quanah Gibson-Mount) Date: Thu, 19 Nov 2015 19:45:51 -0800 Subject: Coherent release process In-Reply-To: <447666547.12112509.1447990497599.JavaMail.zimbra@redhat.com> References: <72EC8BBA6F43AD603B3286DF@[192.168.1.9]> <447666547.12112509.1447990497599.JavaMail.zimbra@redhat.com> Message-ID: --On Thursday, November 19, 2015 10:34 PM -0500 Andrew Hughes wrote: > [Adding in the 8u mailing list] > > ----- Original Message ----- >> Hi, Hi Andrew, Thanks for the follow up! > Actually, that won't get you u66 unless you explicitly check out a tag. > The current tip of 8u is currently receiving fixes people are pushing for > u76, which I believe is due to be released next April, at the same time > as the u75 security update, which will be based on u72. Yes, I use a tag for building. However, that process is completely unreliable UNLESS you use my patch, because the tag is not passed down when pulling out the sub modules, which means you get mismatched code. I.e., without my patch, you cannot build a consistent OpenJDK release against a specific tag. >> >> >> As we rely heavily on being able to provide up to date, consistent, >> secure OpenJDK builds to our customers, having the process to build new >> releases be reliable is of significant importance. I imagine that is >> the case for many others as well. > > Another problem I've also observed. I'm happy for you to ping me if you > have a patch and need a bug opening (I've done this for colleagues at Red > Hat), but as Dalibor mentions in response, the OCA needs to be sorted > first. There's not much point opening a bug with a patch if the patch > can't be committed for legal reasons. I can't see why it'd be a problem to have the patch committed. It's literally modifying hgforest.sh to include the ${command_args} command line options that were originally passed get_source.sh. Again, without this patch, there is literally no way to build OpenJDK where all portions of the checkout from mercurial are fixed to a given tag. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration From david.holmes at oracle.com Fri Nov 20 03:51:51 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 20 Nov 2015 13:51:51 +1000 Subject: Coherent release process In-Reply-To: References: <72EC8BBA6F43AD603B3286DF@[192.168.1.9]> <447666547.12112509.1447990497599.JavaMail.zimbra@redhat.com> Message-ID: <564E98D7.9050504@oracle.com> Trivial patches can be accepted without the provider being an OCA signatory. However the patch must be provided using OpenJDK technology so it can't be taken from an external website, but if small enough should be included inline in an email message. Thanks, David On 20/11/2015 1:45 PM, Quanah Gibson-Mount wrote: > > --On Thursday, November 19, 2015 10:34 PM -0500 Andrew Hughes > wrote: > >> [Adding in the 8u mailing list] >> >> ----- Original Message ----- >>> Hi, > > Hi Andrew, > > Thanks for the follow up! > > >> Actually, that won't get you u66 unless you explicitly check out a tag. >> The current tip of 8u is currently receiving fixes people are pushing for >> u76, which I believe is due to be released next April, at the same time >> as the u75 security update, which will be based on u72. > > Yes, I use a tag for building. However, that process is completely > unreliable UNLESS you use my patch, because the tag is not passed down > when pulling out the sub modules, which means you get mismatched code. > I.e., without my patch, you cannot build a consistent OpenJDK release > against a specific tag. > >>> >>> >>> As we rely heavily on being able to provide up to date, consistent, >>> secure OpenJDK builds to our customers, having the process to build new >>> releases be reliable is of significant importance. I imagine that is >>> the case for many others as well. >> >> Another problem I've also observed. I'm happy for you to ping me if you >> have a patch and need a bug opening (I've done this for colleagues at Red >> Hat), but as Dalibor mentions in response, the OCA needs to be sorted >> first. There's not much point opening a bug with a patch if the patch >> can't be committed for legal reasons. > > I can't see why it'd be a problem to have the patch committed. It's > literally modifying hgforest.sh to include the ${command_args} command > line options that were originally passed get_source.sh. Again, without > this patch, there is literally no way to build OpenJDK where all > portions of the checkout from mercurial are fixed to a given tag. > > --Quanah > > -- > > Quanah Gibson-Mount > Platform Architect > Zimbra, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration From quanah at zimbra.com Fri Nov 20 03:56:24 2015 From: quanah at zimbra.com (Quanah Gibson-Mount) Date: Thu, 19 Nov 2015 19:56:24 -0800 Subject: Coherent release process In-Reply-To: <564E98D7.9050504@oracle.com> References: <72EC8BBA6F43AD603B3286DF@[192.168.1.9]> <447666547.12112509.1447990497599.JavaMail.zimbra@redhat.com> <564E98D7.9050504@oracle.com> Message-ID: <371DE40DAE08D273FAA2D3CD@[192.168.1.9]> --On Friday, November 20, 2015 1:51 PM +1000 David Holmes wrote: > Trivial patches can be accepted without the provider being an OCA > signatory. However the patch must be provided using OpenJDK technology so > it can't be taken from an external website, but if small enough should be > included inline in an email message. --- jdk8u60/common/bin/hgforest.sh.orig 2015-08-10 16:29:42.271352215 +0000 +++ jdk8u60/common/bin/hgforest.sh 2015-08-10 16:36:53.427337849 +0000 @@ -334,8 +334,8 @@ done fi # run the clone command. - echo "hg${global_opts} clone ${clone_newrepo} ${i}" > ${status_output} - (PYTHONUNBUFFERED=true hg${global_opts} clone ${clone_newrepo} ${i}; echo "$?" > ${tmp}/${repopidfile}.pid.rc ) 2>&1 & + echo "hg${global_opts} clone ${command_args} ${clone_newrepo} ${i}" > ${status_output} + (PYTHONUNBUFFERED=true hg${global_opts} clone ${command_args} ${clone_newrepo} ${i}; echo "$?" > ${tmp}/${repopidfile}.pid.rc ) 2>&1 & else # run the command. echo "cd ${i} && hg${global_opts} ${command} ${command_args}" > ${status_output} -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration From souvik1997 at gmail.com Tue Nov 24 06:11:37 2015 From: souvik1997 at gmail.com (Souvik Banerjee) Date: Tue, 24 Nov 2015 00:11:37 -0600 Subject: Handling file:/ URLs with queries on Windows References: Message-ID: <7B18FD2E-C512-451A-9240-F75A1623E4EB@gmail.com> On Windows, opening file:/ URLs with question marks in their name does not work as expected. On Unix-like operating systems, a URL like "file:///var/www/index.html?search=query" would open the file "/var/www/index.html". But on Windows the equivalent URL (using drive letters instead) would open "index.html?search=query" which does not exist. I expect "index.html" to be opened on Windows. I think I have traced this issue to the following file: https://github.com/openjdk-mirror/jdk7u-jdk/blob/f4d80957e89a19a29bb9f9807d2a28351ed7f7df/src/windows/classes/sun/net/www/protocol/file/Handler.java On line 79 the getFile() method is called and is decoded with ParseUtil.decode(). According to line 808 of src/share/classes/java/net/URL.java getFile() returns the concatenation of getURL() and getQuery(). However, in src/solaris/classes/sun/net/www/protocol/file/Handler.java at line 80, getPath() is used instead (which removes the query part of the URL). I think getPath() should be used in the Windows file handler as well. I tried checking the Java Bug Database to see if this issue had been reported, but I could not find any similar issues. Please let me know if this is actually what is supposed to happen. Souvik Banerjee From dalibor.topic at oracle.com Fri Nov 27 11:59:47 2015 From: dalibor.topic at oracle.com (dalibor topic) Date: Fri, 27 Nov 2015 12:59:47 +0100 Subject: Coherent release process In-Reply-To: <498111152.12112954.1447990775779.JavaMail.zimbra@redhat.com> References: <72EC8BBA6F43AD603B3286DF@[192.168.1.9]> <5644A7DE.2020605@oracle.com> <498111152.12112954.1447990775779.JavaMail.zimbra@redhat.com> Message-ID: <565845B3.7080802@oracle.com> On 20.11.2015 04:39, Andrew Hughes wrote: >> The corresponding Project's mailing list, jdk8u-dev, is the right place >> to ask questions about JDK 8 Updates in OpenJDK. The JDK 8 Project has >> completed its work with the JDK 8 GA a while ago, so this list is >> largely dormant. >> > > Is there a good reason for this practice? Yes. A JDK Release Project like JDK 8 is very different from a JDK 8 Updates Project, even though one provides the source code necessary to seed the other. As a trivial example of the differences, a JDK Release Project works towards a single release, and then it's done. A JDK Updates Project tends to work on multiple releases in parallel, provided at a higher frequency. Accordingly, the processes, the development life cycle, etc. are quite different. It's much simpler to start from a clean slate in a new Project, then to retrofit an existing one for a new purpose. > Having seen this happen with > both 7/7u and 8/8u mailing lists, it would seem to make sense to keep > one mailing list instead when 9 goes GA, to avoid this confusion. No. Please see http://openjdk.java.net/projects/ : "A Project may have web content, one or more file repositories, and one or more mailing lists" Mailing lists are Project-specific. Once a Project finishes its work, its mailing list(s) eventually gets dormant and archived, rather than reused for other Projects. See http://mail.openjdk.java.net/pipermail/coin-dev/2015-April/003487.html for an example. cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 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 Oracle is committed to developing practices and products that help protect the environment