From mandy.chung at oracle.com Sun Sep 1 14:51:23 2013 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Sun, 01 Sep 2013 21:51:23 +0000 Subject: hg: jigsaw/jake/jdk: update modules.config and the generated resources list Message-ID: <20130901215141.F125362485@hg.openjdk.java.net> Changeset: cccc62489d4d Author: mchung Date: 2013-09-01 14:46 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/cccc62489d4d update modules.config and the generated resources list ! make/modules/modules.config ! make/modules/tools/src/com/sun/tools/classanalyzer/ClassFileReader.java ! make/modules/tools/src/com/sun/tools/classanalyzer/ClassPath.java ! make/modules/tools/src/com/sun/tools/classanalyzer/ModuleBuilder.java ! make/modules/tools/src/com/sun/tools/classanalyzer/Resource.java - make/modules/tools/src/com/sun/tools/classanalyzer/filelist ! make/modules/tools/src/com/sun/tools/classanalyzer/resources/classanalyzer.properties From alan.bateman at oracle.com Mon Sep 2 10:24:22 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 02 Sep 2013 17:24:22 +0000 Subject: hg: jigsaw/jake: Add jdk.jigsaw.module to ct.sym Message-ID: <20130902172423.2DCC3624AB@hg.openjdk.java.net> Changeset: b91cff14f611 Author: alanb Date: 2013-09-02 18:21 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/b91cff14f611 Add jdk.jigsaw.module to ct.sym ! common/makefiles/javadoc/NON_CORE_PKGS.gmk From mandy.chung at oracle.com Tue Sep 3 15:11:26 2013 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 03 Sep 2013 22:11:26 +0000 Subject: hg: jigsaw/jake/jdk: include only packages containing classes Message-ID: <20130903221223.97C5C624F4@hg.openjdk.java.net> Changeset: c5655ef4c496 Author: mchung Date: 2013-09-03 15:10 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c5655ef4c496 include only packages containing classes ! make/modules/modules.properties ! make/modules/tools/src/com/sun/tools/classanalyzer/ClassFileReader.java ! make/modules/tools/src/com/sun/tools/classanalyzer/JigsawModules.java ! make/modules/tools/src/com/sun/tools/classanalyzer/Module.java ! make/modules/tools/src/com/sun/tools/classanalyzer/Package.java ! makefiles/GenerateModules.gmk From mark.reinhold at oracle.com Wed Sep 4 13:36:05 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 04 Sep 2013 20:36:05 +0000 Subject: hg: jigsaw/jake-gate/jdk: 3 new changesets Message-ID: <20130904203646.A186862572@hg.openjdk.java.net> Changeset: e55f1e7e39f0 Author: alanb Date: 2013-08-30 16:17 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake-gate/jdk/rev/e55f1e7e39f0 Initial push of prototype changes to extend access control ! makefiles/mapfiles/libjava/mapfile-vers ! src/share/classes/java/lang/ClassLoader.java ! src/share/classes/sun/misc/VM.java ! src/share/javavm/export/jvm.h ! src/share/native/sun/misc/VM.c + test/java/lang/ClassLoader/setPackageAccess/TEST.properties + test/java/lang/ClassLoader/setPackageAccess/org/openjdk/jigsaw/accesscontrol/SetPackageAccess.java + test/java/lang/ClassLoader/setPackageAccess/org/openjdk/jigsaw/accesscontrol/internal/Secret.java + test/java/lang/ClassLoader/setPackageAccess/org/openjdk/jigsaw/accesscontrol/p1/C1.java + test/java/lang/ClassLoader/setPackageAccess/org/openjdk/jigsaw/accesscontrol/p2/C2.java Changeset: 61e595a79917 Author: mchung Date: 2013-09-01 14:46 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake-gate/jdk/rev/61e595a79917 update modules.config and the generated resources list ! make/modules/modules.config ! make/modules/tools/src/com/sun/tools/classanalyzer/ClassFileReader.java ! make/modules/tools/src/com/sun/tools/classanalyzer/ClassPath.java ! make/modules/tools/src/com/sun/tools/classanalyzer/ModuleBuilder.java ! make/modules/tools/src/com/sun/tools/classanalyzer/Resource.java - make/modules/tools/src/com/sun/tools/classanalyzer/filelist ! make/modules/tools/src/com/sun/tools/classanalyzer/resources/classanalyzer.properties Changeset: 819a6f22dcda Author: mchung Date: 2013-09-03 15:10 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake-gate/jdk/rev/819a6f22dcda include only packages containing classes ! make/modules/modules.properties ! make/modules/tools/src/com/sun/tools/classanalyzer/ClassFileReader.java ! make/modules/tools/src/com/sun/tools/classanalyzer/JigsawModules.java ! make/modules/tools/src/com/sun/tools/classanalyzer/Module.java ! make/modules/tools/src/com/sun/tools/classanalyzer/Package.java ! makefiles/GenerateModules.gmk From mark.reinhold at oracle.com Wed Sep 4 13:44:04 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 04 Sep 2013 20:44:04 +0000 Subject: hg: jigsaw/jake/jdk: Add jdk.jre and jdk modules back to modules.group Message-ID: <20130904204417.91C3462573@hg.openjdk.java.net> Changeset: 34628c24e41d Author: mr Date: 2013-09-04 13:39 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/34628c24e41d Add jdk.jre and jdk modules back to modules.group ! make/modules/modules.group From mark.reinhold at oracle.com Wed Sep 4 13:44:17 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 04 Sep 2013 20:44:17 +0000 Subject: hg: jigsaw/jake-gate/jdk: Add jdk.jre and jdk modules back to modules.group Message-ID: <20130904204431.57D1762574@hg.openjdk.java.net> Changeset: 34628c24e41d Author: mr Date: 2013-09-04 13:39 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake-gate/jdk/rev/34628c24e41d Add jdk.jre and jdk modules back to modules.group ! make/modules/modules.group From mark.reinhold at oracle.com Wed Sep 4 13:52:39 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 04 Sep 2013 13:52:39 -0700 Subject: hg: jigsaw/jake-gate/jdk: 3 new changesets In-Reply-To: <20130904203646.A186862572@hg.openjdk.java.net> References: <20130904203646.A186862572@hg.openjdk.java.net> Message-ID: <20130904135239.919885@eggemoggin.niobe.net> FYI, that push redid the last few changesets in order to remove some trailing whitespace that crept in. I've enabled jcheck (laxly) for jake. All pushes should now go to the gate forest: ssh://_mr at hg.openjdk.java.net/jigsaw/jake-gate . - Mark From mark.reinhold at oracle.com Wed Sep 4 14:00:32 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 04 Sep 2013 21:00:32 +0000 Subject: hg: jigsaw/jake/jdk: Comparable<{Module, ServiceDependence, View, ViewDependence}> Message-ID: <20130904210044.F21CE62577@hg.openjdk.java.net> Changeset: a5c932fcc583 Author: mr Date: 2013-09-04 13:59 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a5c932fcc583 Comparable<{Module,ServiceDependence,View,ViewDependence}> ! src/share/classes/jdk/jigsaw/module/Module.java ! src/share/classes/jdk/jigsaw/module/ServiceDependence.java ! src/share/classes/jdk/jigsaw/module/View.java ! src/share/classes/jdk/jigsaw/module/ViewDependence.java From mark.reinhold at oracle.com Wed Sep 4 14:00:45 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 04 Sep 2013 21:00:45 +0000 Subject: hg: jigsaw/jake-gate/jdk: Comparable<{Module, ServiceDependence, View, ViewDependence}> Message-ID: <20130904210058.0D82A62578@hg.openjdk.java.net> Changeset: a5c932fcc583 Author: mr Date: 2013-09-04 13:59 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake-gate/jdk/rev/a5c932fcc583 Comparable<{Module,ServiceDependence,View,ViewDependence}> ! src/share/classes/jdk/jigsaw/module/Module.java ! src/share/classes/jdk/jigsaw/module/ServiceDependence.java ! src/share/classes/jdk/jigsaw/module/View.java ! src/share/classes/jdk/jigsaw/module/ViewDependence.java From mark.reinhold at oracle.com Wed Sep 4 13:35:28 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 04 Sep 2013 20:35:28 +0000 Subject: hg: jigsaw/jake/jdk: 3 new changesets Message-ID: <20130904203605.9630062570@hg.openjdk.java.net> Changeset: e55f1e7e39f0 Author: alanb Date: 2013-08-30 16:17 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e55f1e7e39f0 Initial push of prototype changes to extend access control ! makefiles/mapfiles/libjava/mapfile-vers ! src/share/classes/java/lang/ClassLoader.java ! src/share/classes/sun/misc/VM.java ! src/share/javavm/export/jvm.h ! src/share/native/sun/misc/VM.c + test/java/lang/ClassLoader/setPackageAccess/TEST.properties + test/java/lang/ClassLoader/setPackageAccess/org/openjdk/jigsaw/accesscontrol/SetPackageAccess.java + test/java/lang/ClassLoader/setPackageAccess/org/openjdk/jigsaw/accesscontrol/internal/Secret.java + test/java/lang/ClassLoader/setPackageAccess/org/openjdk/jigsaw/accesscontrol/p1/C1.java + test/java/lang/ClassLoader/setPackageAccess/org/openjdk/jigsaw/accesscontrol/p2/C2.java Changeset: 61e595a79917 Author: mchung Date: 2013-09-01 14:46 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/61e595a79917 update modules.config and the generated resources list ! make/modules/modules.config ! make/modules/tools/src/com/sun/tools/classanalyzer/ClassFileReader.java ! make/modules/tools/src/com/sun/tools/classanalyzer/ClassPath.java ! make/modules/tools/src/com/sun/tools/classanalyzer/ModuleBuilder.java ! make/modules/tools/src/com/sun/tools/classanalyzer/Resource.java - make/modules/tools/src/com/sun/tools/classanalyzer/filelist ! make/modules/tools/src/com/sun/tools/classanalyzer/resources/classanalyzer.properties Changeset: 819a6f22dcda Author: mchung Date: 2013-09-03 15:10 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/819a6f22dcda include only packages containing classes ! make/modules/modules.properties ! make/modules/tools/src/com/sun/tools/classanalyzer/ClassFileReader.java ! make/modules/tools/src/com/sun/tools/classanalyzer/JigsawModules.java ! make/modules/tools/src/com/sun/tools/classanalyzer/Module.java ! make/modules/tools/src/com/sun/tools/classanalyzer/Package.java ! makefiles/GenerateModules.gmk From mark.reinhold at oracle.com Wed Sep 4 15:27:46 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 04 Sep 2013 15:27:46 -0700 Subject: Jigsaw prototype, take 2 In-Reply-To: <5220F076.701@redhat.com> References: <20130828092751.449385@eggemoggin.niobe.net>, <5220F076.701@redhat.com> Message-ID: <20130904152746.356683@eggemoggin.niobe.net> 2013/8/30 5:20 -0700, david.lloyd at redhat.com: > ... In addition, many best practices have emerged > that (partially or wholly) contradict the original design intent of > these systems (OSGi also falls into this category). Do you have links to any good descriptions of these best practices? That'd be helpful. - Mark From mark.reinhold at oracle.com Wed Sep 4 15:35:38 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 04 Sep 2013 15:35:38 -0700 Subject: Jigsaw prototype, take 2 In-Reply-To: References: <20130828092751.449385@eggemoggin.niobe.net>, Message-ID: <20130904153538.276977@eggemoggin.niobe.net> 2013/8/30 0:35 -0700, david.bosschaert at gmail.com: > My understanding is that JEP 161 (http://openjdk.java.net/jeps/161) already > addresses many requirements for modularizing the Java runtime. JEP 161 > should address the concerns around creating a scalable platform and improve > performance. > > I would like to understand what requirements in addition to JEP 161 this > prototype aims to address. JEP 161 is an interim solution to the problem of scaling the platform. It "modularizes" the platform in only the crudest sense, defining just three modules. If an application uses just one API from the largest profile and otherwise requires only the smallest profile then there is no choice but to use an implementation of the largest profile. As to performance, JEP 161 doesn't address that at all. The kinds of performance improvements we've always aimed to enable with Jigsaw involve transforming module content during installation. - Mark From david.lloyd at redhat.com Wed Sep 4 17:50:34 2013 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 04 Sep 2013 19:50:34 -0500 Subject: Jigsaw prototype, take 2 In-Reply-To: <20130904152746.356683@eggemoggin.niobe.net> References: <20130828092751.449385@eggemoggin.niobe.net>, <5220F076.701@redhat.com> <20130904152746.356683@eggemoggin.niobe.net> Message-ID: <5227D55A.3020702@redhat.com> On 09/04/2013 05:27 PM, mark.reinhold at oracle.com wrote: > 2013/8/30 5:20 -0700, david.lloyd at redhat.com: >> ... In addition, many best practices have emerged >> that (partially or wholly) contradict the original design intent of >> these systems (OSGi also falls into this category). > > Do you have links to any good descriptions of these best practices? > That'd be helpful. Not a lot as links, as mostly they are "community knowledge" among our various teams, but here's a couple for each that I can find relatively quickly: For Maven: * Version ranges considered harmful [1] [2] [3] [4] (and probably more); we disallow them within our own products for stability reasons * Transitive-by-default causes problems in mid to large projects due to extensive conflicts [can't find the discussion...]; fix is to use and verify exclusions, specify "provided" scope, and use maven-enforcer-plugin [5] to ban transitive dependencies For OSGi: * Using the full capabilities of range dependencies can cause resolution to be NP-complete; best practice is to use ranges in a more restricted manner [6] * Require-Bundle not recommended due to lack of hiding non-public packages among other things [no link] (however, to be fair this is only due to the way Require-Bundle was designed; it's not an inherent flaw, but it is a best practice not to use it, hence it fits the criteria) As with many so-called "best practices" there are those who disagree with some or all of them; I'm not going to argue the finer points of each one. I'm just pointing out that just copying a given mechanism and adapting it straight to a somewhat similar but also somewhat different use case is doubly dangerous - on one hand, it is hard to know what went into the design of these mechanisms; and on the other hand, there is a considerable base of knowledge that comes from third parties (or just the general public) that sheds additional light on the pros and cons of these mechanisms as well. [1] http://maven.40175.n5.nabble.com/Version-ranges-not-working-td5723909i40.html [2] http://stackoverflow.com/a/7169847/2033093 [3] http://stackoverflow.com/a/3882490/2033093 [4] http://grokbase.com/p/maven/users/129vwgkd1c/version-ranges-not-working [5] http://maven.apache.org/enforcer/enforcer-rules/banTransitiveDependencies.html [6] http://wiki.apidesign.org/wiki/RangeDependenciesAnalysed -- - DML From njbartlett at gmail.com Wed Sep 4 19:44:22 2013 From: njbartlett at gmail.com (Neil Bartlett) Date: Thu, 5 Sep 2013 03:44:22 +0100 Subject: Jigsaw prototype, take 2 In-Reply-To: <20130904153538.276977@eggemoggin.niobe.net> References: <20130828092751.449385@eggemoggin.niobe.net> <20130904153538.276977@eggemoggin.niobe.net> Message-ID: And yet, JEP 161 addresses the most pressing requirement from Java developers: a smaller, more embeddable JRE. Furthermore it actually seems to be deliverable within a reasonable time scale (JDK8) rather than a continually slipping, indeterminate future. - Neil On Wed, Sep 4, 2013 at 11:35 PM, wrote: > 2013/8/30 0:35 -0700, david.bosschaert at gmail.com: >> My understanding is that JEP 161 (http://openjdk.java.net/jeps/161) already >> addresses many requirements for modularizing the Java runtime. JEP 161 >> should address the concerns around creating a scalable platform and improve >> performance. >> >> I would like to understand what requirements in addition to JEP 161 this >> prototype aims to address. > > JEP 161 is an interim solution to the problem of scaling the platform. > It "modularizes" the platform in only the crudest sense, defining just > three modules. If an application uses just one API from the largest > profile and otherwise requires only the smallest profile then there is > no choice but to use an implementation of the largest profile. > > As to performance, JEP 161 doesn't address that at all. The kinds of > performance improvements we've always aimed to enable with Jigsaw > involve transforming module content during installation. > > - Mark From greggwon at cox.net Wed Sep 4 21:33:58 2013 From: greggwon at cox.net (Gregg Wonderly) Date: Wed, 04 Sep 2013 23:33:58 -0500 Subject: Jigsaw prototype, take 2 In-Reply-To: References: <20130828092751.449385@eggemoggin.niobe.net> <20130904153538.276977@eggemoggin.niobe.net> Message-ID: <522809B6.70000@cox.net> Indeed! An incremental improvement over time is the best way to provide something, get feedback, adjust, and continue. In the end, there is not enough time in the day for perfect, and there is little change that perfect will last for very long. So compromise and delivery of something to start with, might be the best choice. Ultimately, if Oracle would just allow developers to "prune" the jars to what we need, and/or remake the binary part of what we are using to have exactly and only what we need, that would make for the best approach. The fact of the matter is that few people are actually deploying Java as a "platform". They are deploying it as a "runtime environment", and that means that they know the extent of the feature set that they need. Java as a generic platform has failed because Sun and Oracle now, have failed to understand the importance of supporting the desktop environment with something that was "library" like, and instead, staying focused on the Jave-EE platform world where "new content" is deployed into the runtime environment and thus requires the "totality" of the platform, because you just never know what might be deployed. On the desktop and most "applications" that aren't tied to Java-EE, Java is used like a library, and thus people really don't understand why they can't just use what they need, and pull the reset "out". There is no benefit that Sun/Oracle receive from disallowing this in licensing. Instead, they've managed to make sure that Java is not desirable for anything other than large scale application deployment. Gregg Wonderly On 9/4/2013 9:44 PM, Neil Bartlett wrote: > And yet, JEP 161 addresses the most pressing requirement from Java > developers: a smaller, more embeddable JRE. > > Furthermore it actually seems to be deliverable within a reasonable > time scale (JDK8) rather than a continually slipping, indeterminate > future. > > - Neil > > On Wed, Sep 4, 2013 at 11:35 PM, wrote: >> 2013/8/30 0:35 -0700, david.bosschaert at gmail.com: >>> My understanding is that JEP 161 (http://openjdk.java.net/jeps/161) already >>> addresses many requirements for modularizing the Java runtime. JEP 161 >>> should address the concerns around creating a scalable platform and improve >>> performance. >>> >>> I would like to understand what requirements in addition to JEP 161 this >>> prototype aims to address. >> JEP 161 is an interim solution to the problem of scaling the platform. >> It "modularizes" the platform in only the crudest sense, defining just >> three modules. If an application uses just one API from the largest >> profile and otherwise requires only the smallest profile then there is >> no choice but to use an implementation of the largest profile. >> >> As to performance, JEP 161 doesn't address that at all. The kinds of >> performance improvements we've always aimed to enable with Jigsaw >> involve transforming module content during installation. >> >> - Mark From jaroslav.tulach at oracle.com Thu Sep 5 00:26:44 2013 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Thu, 05 Sep 2013 09:26:44 +0200 Subject: Transitive deps was: Jigsaw prototype, take 2 In-Reply-To: <5227D55A.3020702@redhat.com> References: <20130828092751.449385@eggemoggin.niobe.net> <20130904152746.356683@eggemoggin.niobe.net> <5227D55A.3020702@redhat.com> Message-ID: <1490871.zO0yRBcP4C@logouticek> Dne St 4. z??? 2013 19:50:34, David M. Lloyd napsal(a): > * Transitive-by-default causes problems in mid to large projects due to > extensive conflicts [can't find the discussion...]; We run into this all the time. Just recently I was trying to use maven-antrun- plugin which depends on (and exposes) Ant 1.7.1 while using features of Ant 1.8. Conflicts everywhere. Resolution fragile. But it seems to run at the end. > fix is to use and > verify exclusions, specify "provided" scope, Provided scope is good for "compile only dependency" - e.g. one that is not used during runtime. I use it for APIs with annotation processors that just generate something and are no longer needed during runtime. However I've noticed that grizzly used the "provided" scope for optional runtime dependency. E.g. I could use grizzly-http-server, and add in optional support for websockets - but it was a nightmare to find out all the JARs that were needed (like javax.servlet-3.0 API) and I got a lot for NoClassDefFoundErrors before I collected them all. I double this is a practice to follow. > and use > maven-enforcer-plugin [5] to ban transitive dependencies That might work. Explicitly specify what you compile against is a good idea. NetBeans Platform (Ant based) build system is using it for a decade (after switching from the previously transitive mode) and there are no problems with it as far as I can tell. > * range dependencies can cause resolution > to be NP-complete; best practice is to use ranges in a more restricted > manner [6] Thanks for the quote. Btw. the article's final suggestion is somewhat similar to what the maven-enforcer-plugin does. The write up suggest to record the exact versions of libraries we compile against - either specified directly as a compile dependency, or inferred by the compiler for the (hidden) transitive ones. -jt > [6] http://wiki.apidesign.org/wiki/RangeDependenciesAnalysed From njbartlett at gmail.com Thu Sep 5 03:39:16 2013 From: njbartlett at gmail.com (Neil Bartlett) Date: Thu, 5 Sep 2013 11:39:16 +0100 Subject: Transitive deps was: Jigsaw prototype, take 2 In-Reply-To: <1490871.zO0yRBcP4C@logouticek> References: <20130828092751.449385@eggemoggin.niobe.net> <20130904152746.356683@eggemoggin.niobe.net> <5227D55A.3020702@redhat.com> <1490871.zO0yRBcP4C@logouticek> Message-ID: On Thu, Sep 5, 2013 at 8:26 AM, Jaroslav Tulach wrote: > Dne St 4. z??? 2013 19:50:34, David M. Lloyd napsal(a): >> * Transitive-by-default causes problems in mid to large projects due to >> extensive conflicts [can't find the discussion...]; > > We run into this all the time. Just recently I was trying to use maven-antrun- > plugin which depends on (and exposes) Ant 1.7.1 while using features of Ant > 1.8. Conflicts everywhere. Resolution fragile. But it seems to run at the end. > >> fix is to use and >> verify exclusions, specify "provided" scope, > > Provided scope is good for "compile only dependency" - e.g. one that is not > used during runtime. I use it for APIs with annotation processors that just > generate something and are no longer needed during runtime. > > However I've noticed that grizzly used the "provided" scope for optional > runtime dependency. E.g. I could use grizzly-http-server, and add in optional > support for websockets - but it was a nightmare to find out all the JARs that > were needed (like javax.servlet-3.0 API) and I got a lot for > NoClassDefFoundErrors before I collected them all. I double this is a practice > to follow. > >> and use >> maven-enforcer-plugin [5] to ban transitive dependencies > > That might work. Explicitly specify what you compile against is a good idea. > NetBeans Platform (Ant based) build system is using it for a decade (after > switching from the previously transitive mode) and there are no problems with > it as far as I can tell. I continue to believe that the root of this problem is that the Maven dependency model cannot work for runtime dependencies. "Whole module" dependencies such as used in Maven, in previous Jigsaw/JSR277 prototypes, and in OSGi's discouraged Require-Bundle instruction always lead to excessive fanout and version clashes. > >> * range dependencies can cause resolution >> to be NP-complete; best practice is to use ranges in a more restricted >> manner [6] > > Thanks for the quote. Btw. the article's final suggestion is somewhat similar > to what the maven-enforcer-plugin does. The write up suggest to record the > exact versions of libraries we compile against - either specified directly as a > compile dependency, or inferred by the compiler for the (hidden) transitive > ones. Although David quoted you in the context of OSGi resolution, your article is not really considered OSGi best practice. In fact we do use wide ranges according to the rules of Semantic Versioning[1]. While NP-complete resolutions can technically occur, the problem rarely arises in realistic scenarios -- if they do ever occur then the solution is to narrow the search space and/or pre-resolve and persist the resolution state. However, I really feel there is no point in rehashing all these arguments yet again, since we don't have a clue about the requirements of the rebooted Jigsaw project other than Mark's vague implication that it will be "simpler". Oracle needs to clarify the purpose and goals of the project before any progress can be made. [1] http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf > -jt > >> [6] http://wiki.apidesign.org/wiki/RangeDependenciesAnalysed > > From Alan.Bateman at oracle.com Thu Sep 5 04:10:44 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 05 Sep 2013 12:10:44 +0100 Subject: Jigsaw prototype, take 2 In-Reply-To: <522809B6.70000@cox.net> References: <20130828092751.449385@eggemoggin.niobe.net> <20130904153538.276977@eggemoggin.niobe.net> <522809B6.70000@cox.net> Message-ID: <522866B4.4020303@oracle.com> On 05/09/2013 05:33, Gregg Wonderly wrote: > : > > Ultimately, if Oracle would just allow developers to "prune" the jars > to what we need, and/or remake the binary part of what we are using to > have exactly and only what we need, that would make for the best > approach. The EDR for JSR 337 (Java SE 8) includes a proposal for Stripped Implementations, see: http://cr.openjdk.java.net/~mr/se/8/java-se-8-edr-spec.html#s9 From jaroslav.tulach at oracle.com Thu Sep 5 04:34:37 2013 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Thu, 05 Sep 2013 13:34:37 +0200 Subject: Transitive deps In-Reply-To: References: <20130828092751.449385@eggemoggin.niobe.net> <1490871.zO0yRBcP4C@logouticek> Message-ID: <3397381.PVR0WdMbYF@logouticek> Dne ?t 5. z??? 2013 11:39:16, Neil Bartlett napsal(a): > >> and use > >> maven-enforcer-plugin [5] to ban transitive dependencies > > > > That might work. Explicitly specify what you compile against is a good > > idea. NetBeans Platform (Ant based) build system is using it for a decade > > (after switching from the previously transitive mode) and there are no > > problems with it as far as I can tell. > > I continue to believe that the root of this problem is that the Maven > dependency model cannot work for runtime dependencies. "Whole module" > dependencies such as used in Maven, in previous Jigsaw/JSR277 > prototypes, and in OSGi's discouraged Require-Bundle instruction > always lead to excessive fanout and version clashes. As splitted packages are rare (and maybe even unsupported in some versions of OSGI), then a package import basically means non-transitive dependency. You may realize that your belief is a specialization of my general observation. As such it is of no surprise, that if non-transitive JAR (compilation) dependencies work sufficiently, import package works for you in OSGi. Import-Package seems to be a solution of the transtivity issues, but a bit too narrow and certainly not the only one. -jt From Alan.Bateman at oracle.com Thu Sep 5 05:01:06 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 05 Sep 2013 13:01:06 +0100 Subject: Jigsaw prototype, take 2 In-Reply-To: References: <20130828092751.449385@eggemoggin.niobe.net> <20130904153538.276977@eggemoggin.niobe.net> Message-ID: <52287282.3000507@oracle.com> On 05/09/2013 03:44, Neil Bartlett wrote: > And yet, JEP 161 addresses the most pressing requirement from Java > developers: a smaller, more embeddable JRE. > > Furthermore it actually seems to be deliverable within a reasonable > time scale (JDK8) rather than a continually slipping, indeterminate > future. > > - Neil > Compact Profiles are just an interim step before we have a more modular platform. I like to think of it as set menu vs. the ? la carte. Also just to say that the engineering effort to do the Compact Profiles was relatively small because it is based on the static modularization effort that we have been chipping away at for several years. It also primarily just having the build generate alternative runtimes, there isn't a language, runtime or other elements to the solution. One final thing to say about the Compact Profiles is it was an explicit goal to take account future migration to modules. The finer grain modules are mostly obvious in the proposed contents and one could envisage aggregator modules corresponding to compact1, compact2 and compact3 when we get to modules. -Alan From njbartlett at gmail.com Thu Sep 5 05:15:21 2013 From: njbartlett at gmail.com (Neil Bartlett) Date: Thu, 5 Sep 2013 13:15:21 +0100 Subject: Transitive deps In-Reply-To: <3397381.PVR0WdMbYF@logouticek> References: <20130828092751.449385@eggemoggin.niobe.net> <1490871.zO0yRBcP4C@logouticek> <3397381.PVR0WdMbYF@logouticek> Message-ID: On Thu, Sep 5, 2013 at 12:34 PM, Jaroslav Tulach wrote: >> [...] > As splitted packages are rare (and maybe even unsupported in some versions of > OSGI), then a package import basically means non-transitive dependency. > > You may realize that your belief is a specialization of my general > observation. As such it is of no surprise, that if non-transitive JAR > (compilation) dependencies work sufficiently, import package works for you in > OSGi. > > Import-Package seems to be a solution of the transtivity issues, but a bit too > narrow and certainly not the only one. > -jt Stepping back a bit, I feel that the underlying failure in Maven is to distinguish between build and runtime dependencies. They require different approaches. I think we are in broad agreement about how to manage build dependencies. They are not required to be transitive -- to compile each module we only need visibility of the modules it directly imports. They should not use ranges because this results in non-repeatable builds; for my customers it is important to be able to reproduce a build precisely, even many years into the future. In the bnd build system we can go beyond fixed module identity+version and actually depend on the SHA hash of a module. Admittedly we also made the mistake of using dependency ranges at build time but now strongly discourage it. Runtime dependencies are unavoidably transitive. The key is therefore to find ways to minimise the transitive dependency graph, which is the purpose of the OSGi Import-Package instruction, since it creates opportunities to refactor module contents and/or find alternative providers. Neil > > > From sven.reimers at gmail.com Thu Sep 5 05:23:23 2013 From: sven.reimers at gmail.com (Sven Reimers) Date: Thu, 5 Sep 2013 14:23:23 +0200 Subject: Transitive deps In-Reply-To: References: <20130828092751.449385@eggemoggin.niobe.net> <1490871.zO0yRBcP4C@logouticek> <3397381.PVR0WdMbYF@logouticek> Message-ID: "I think we are in broad agreement about how to manage build dependencies. They are not required to be transitive -- to compile each module we only need visibility of the modules it directly imports." I am sure that javac sometimes disagrees and wants to look a bit deeper into the implementation inheritance (may be bad design/architecture, butis valid Java) -Sven On Thu, Sep 5, 2013 at 2:15 PM, Neil Bartlett wrote: > On Thu, Sep 5, 2013 at 12:34 PM, Jaroslav Tulach > wrote: > >> [...] > > As splitted packages are rare (and maybe even unsupported in some > versions of > > OSGI), then a package import basically means non-transitive dependency. > > > > You may realize that your belief is a specialization of my general > > observation. As such it is of no surprise, that if non-transitive JAR > > (compilation) dependencies work sufficiently, import package works for > you in > > OSGi. > > > > Import-Package seems to be a solution of the transtivity issues, but a > bit too > > narrow and certainly not the only one. > > -jt > > > Stepping back a bit, I feel that the underlying failure in Maven is to > distinguish between build and runtime dependencies. They require > different approaches. > > I think we are in broad agreement about how to manage build > dependencies. They are not required to be transitive -- to compile > each module we only need visibility of the modules it directly > imports. They should not use ranges because this results in > non-repeatable builds; for my customers it is important to be able to > reproduce a build precisely, even many years into the future. In the > bnd build system we can go beyond fixed module identity+version and > actually depend on the SHA hash of a module. Admittedly we also made > the mistake of using dependency ranges at build time but now strongly > discourage it. > > Runtime dependencies are unavoidably transitive. The key is therefore > to find ways to minimise the transitive dependency graph, which is the > purpose of the OSGi Import-Package instruction, since it creates > opportunities to refactor module contents and/or find alternative > providers. > > Neil > > > > > > > > -- Sven Reimers * Senior Expert Software Architect * NetBeans Dream Team Member: http://dreamteam.netbeans.org * Community Leader NetBeans: http://community.java.net/netbeans Desktop Java: http://community.java.net/javadesktop * Duke's Choice Award Winner 2009 * Blog: http://nbguru.blogspot.com * XING: https://www.xing.com/profile/Sven_Reimers8 * LinkedIn: http://www.linkedin.com/in/svenreimers Join the NetBeans Groups: * XING: http://www.xing.com/group-20148.82db20 * NUGM: http://haug-server.dyndns.org/display/NUGM/Home * LinkedIn: http://www.linkedin.com/groups?gid=1860468 http://www.linkedin.com/groups?gid=107402 http://www.linkedin.com/groups?gid=1684717 * Oracle: https://mix.oracle.com/groups/18497 From njbartlett at gmail.com Thu Sep 5 05:35:38 2013 From: njbartlett at gmail.com (Neil Bartlett) Date: Thu, 5 Sep 2013 13:35:38 +0100 Subject: Transitive deps In-Reply-To: References: <20130828092751.449385@eggemoggin.niobe.net> <1490871.zO0yRBcP4C@logouticek> <3397381.PVR0WdMbYF@logouticek> Message-ID: On Thu, Sep 5, 2013 at 1:23 PM, Sven Reimers wrote: > "I think we are in broad agreement about how to manage build > dependencies. They are not required to be transitive -- to compile > each module we only need visibility of the modules it directly > imports." > > I am sure that javac sometimes disagrees and wants to look a bit deeper into > the implementation inheritance (may be bad design/architecture, butis valid > Java) Yes, sorry I was sloppy with my wording. At build time we need visibility of the direct dependencies, which may go somewhat beyond the literal set of import clauses in the Java code. In either case, the build system should allow the developer to list those direct dependencies and is not required to pull in transitives. The developer quickly discovers whether she has missed any "implicit" (e.g. superclass) dependencies because javac will return errors. > > -Sven > > > On Thu, Sep 5, 2013 at 2:15 PM, Neil Bartlett wrote: >> >> On Thu, Sep 5, 2013 at 12:34 PM, Jaroslav Tulach >> wrote: >> >> [...] >> > As splitted packages are rare (and maybe even unsupported in some >> > versions of >> > OSGI), then a package import basically means non-transitive dependency. >> > >> > You may realize that your belief is a specialization of my general >> > observation. As such it is of no surprise, that if non-transitive JAR >> > (compilation) dependencies work sufficiently, import package works for >> > you in >> > OSGi. >> > >> > Import-Package seems to be a solution of the transtivity issues, but a >> > bit too >> > narrow and certainly not the only one. >> > -jt >> >> >> Stepping back a bit, I feel that the underlying failure in Maven is to >> distinguish between build and runtime dependencies. They require >> different approaches. >> >> I think we are in broad agreement about how to manage build >> dependencies. They are not required to be transitive -- to compile >> each module we only need visibility of the modules it directly >> imports. They should not use ranges because this results in >> non-repeatable builds; for my customers it is important to be able to >> reproduce a build precisely, even many years into the future. In the >> bnd build system we can go beyond fixed module identity+version and >> actually depend on the SHA hash of a module. Admittedly we also made >> the mistake of using dependency ranges at build time but now strongly >> discourage it. >> >> Runtime dependencies are unavoidably transitive. The key is therefore >> to find ways to minimise the transitive dependency graph, which is the >> purpose of the OSGi Import-Package instruction, since it creates >> opportunities to refactor module contents and/or find alternative >> providers. >> >> Neil >> >> > >> > >> > > > > > > -- > Sven Reimers > > * Senior Expert Software Architect > * NetBeans Dream Team Member: http://dreamteam.netbeans.org > * Community Leader NetBeans: http://community.java.net/netbeans > Desktop Java: > http://community.java.net/javadesktop > * Duke's Choice Award Winner 2009 > * Blog: http://nbguru.blogspot.com > > * XING: https://www.xing.com/profile/Sven_Reimers8 > * LinkedIn: http://www.linkedin.com/in/svenreimers > > Join the NetBeans Groups: > * XING: http://www.xing.com/group-20148.82db20 > * NUGM: http://haug-server.dyndns.org/display/NUGM/Home > * LinkedIn: http://www.linkedin.com/groups?gid=1860468 > http://www.linkedin.com/groups?gid=107402 > http://www.linkedin.com/groups?gid=1684717 > * Oracle: https://mix.oracle.com/groups/18497 From david.lloyd at redhat.com Thu Sep 5 08:00:26 2013 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 05 Sep 2013 10:00:26 -0500 Subject: Transitive deps was: Jigsaw prototype, take 2 In-Reply-To: References: <20130828092751.449385@eggemoggin.niobe.net> <20130904152746.356683@eggemoggin.niobe.net> <5227D55A.3020702@redhat.com> <1490871.zO0yRBcP4C@logouticek> Message-ID: <52289C8A.5080201@redhat.com> On 09/05/2013 05:39 AM, Neil Bartlett wrote: > On Thu, Sep 5, 2013 at 8:26 AM, Jaroslav Tulach > wrote: >> Dne St 4. z??? 2013 19:50:34, David M. Lloyd napsal(a): >>> * Transitive-by-default causes problems in mid to large projects due to >>> extensive conflicts [can't find the discussion...]; >> >> We run into this all the time. Just recently I was trying to use maven-antrun- >> plugin which depends on (and exposes) Ant 1.7.1 while using features of Ant >> 1.8. Conflicts everywhere. Resolution fragile. But it seems to run at the end. >> >>> fix is to use and >>> verify exclusions, specify "provided" scope, >> >> Provided scope is good for "compile only dependency" - e.g. one that is not >> used during runtime. I use it for APIs with annotation processors that just >> generate something and are no longer needed during runtime. >> >> However I've noticed that grizzly used the "provided" scope for optional >> runtime dependency. E.g. I could use grizzly-http-server, and add in optional >> support for websockets - but it was a nightmare to find out all the JARs that >> were needed (like javax.servlet-3.0 API) and I got a lot for >> NoClassDefFoundErrors before I collected them all. I double this is a practice >> to follow. >> >>> and use >>> maven-enforcer-plugin [5] to ban transitive dependencies >> >> That might work. Explicitly specify what you compile against is a good idea. >> NetBeans Platform (Ant based) build system is using it for a decade (after >> switching from the previously transitive mode) and there are no problems with >> it as far as I can tell. > > I continue to believe that the root of this problem is that the Maven > dependency model cannot work for runtime dependencies. "Whole module" > dependencies such as used in Maven, in previous Jigsaw/JSR277 > prototypes, and in OSGi's discouraged Require-Bundle instruction > always lead to excessive fanout and version clashes. We use whole module dependencies all the time in JBoss Modules without such problems; however we don't always transitively pull in all imports either, which might be a critical difference, and we also provide mechanisms to limit what is exported from the source module as well. All the OSGi arguments I can find seem to stem from only having two levels of granularity: packages, or *everything*. Really I guess it's probably more fair to say that our "whole module" dependencies are really a midway point between OSGi's per-package and whole-bundle dependencies; they really mean "the exported subgroup of all of the module's packages". In any case this has worked better than package granularity for us because it allows APIs to grow new packages without having to repackage every dependent (something that happens a lot with rapidly developing projects like ours), while still allowing us to hide packages and transitive imports that should not be imported into the target. This is one of those fine details that would make for an interesting discussion on its own, but doesn't really relate much to the original topic :) But the #1 reason Maven dependencies don't work in practice is simply that they're designed for a flat class path. More than one of my colleagues have naively tried to come up with a mechanism that automatically just maps Maven dependencies on to JBoss Modules, using the exact literal dependency resolution from Aether or whatever mechanism they try (both with multiple versions and flattened versions), and frequently they have run into NCDFE/CNFE and other linkage errors, CCE, etc. The dependencies in the existing repository are not adequate (let alone deterministic [version ranges!]), and the dependency specification language is not expressive enough to accommodate even the most common use cases we have found (e.g. establishing what packages are non-public). Being transitive by default is a big part of the reason why this space is "poisoned", in my opinion, but also the side-effects of a flat class path (i.e. forgotten dependencies magically still work through luck) will always prevent this database from working in an isolated module system until/unless Maven itself moves to an isolated system. >>> * range dependencies can cause resolution >>> to be NP-complete; best practice is to use ranges in a more restricted >>> manner [6] >> >> Thanks for the quote. Btw. the article's final suggestion is somewhat similar >> to what the maven-enforcer-plugin does. The write up suggest to record the >> exact versions of libraries we compile against - either specified directly as a >> compile dependency, or inferred by the compiler for the (hidden) transitive >> ones. > > Although David quoted you in the context of OSGi resolution, your > article is not really considered OSGi best practice. In fact we do use > wide ranges according to the rules of Semantic Versioning[1]. While > NP-complete resolutions can technically occur, the problem rarely > arises in realistic scenarios -- if they do ever occur then the > solution is to narrow the search space and/or pre-resolve and persist > the resolution state. In any case though, the way OSGi uses version constraints to dynamically wire up dependencies (and verify compatibility) works in a container (where you don't actually know what's going to come in and from where) but in a static environment like Jigsaw and the default JBoss Modules loader, you want all those questions to be answered up front (much like in an OS distribution), so while version ranges can be useful to help ensure correctness in your original module repository, I think making them part of the runtime resolver is a mistake. This is where the OSGi people talk how OSGi can pre-cache resolution results, and yes I acknowledge this is a solution, but only if you actually *do* it. :-) Using this information to build the static module repository in the first place essentially gives the same result though. But in any case, for a Java SE module system, I still maintain that modules should always load in constant time (algorithmically speaking), and that means no version ranges at run time, period (other than perhaps for run time verification purposes, if the integrity of the original repository is in doubt for some reason; this might be a core assumption though if we're talking about using a Maven repository as a source for modules). > However, I really feel there is no point in rehashing all these > arguments yet again, since we don't have a clue about the requirements > of the rebooted Jigsaw project other than Mark's vague implication > that it will be "simpler". Oracle needs to clarify the purpose and > goals of the project before any progress can be made. Indeed, once again we don't know what worked and what didn't work and why, and what Oracle is *really* after. Instead we are expected to be lulled by the disclaimer that "this is just another prototype [that you know nothing about]". -- - DML From alan.bateman at oracle.com Thu Sep 5 08:17:14 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 05 Sep 2013 15:17:14 +0000 Subject: hg: jigsaw/jake/jdk: Update module config to put all of sun.misc in base module. Message-ID: <20130905151759.24E81625A6@hg.openjdk.java.net> Changeset: d050e294b708 Author: alanb Date: 2013-09-05 16:09 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d050e294b708 Update module config to put all of sun.misc in base module. Moved basic test for setPackageAccess to more sensible location. Add support methods to launcher to set access control (not used yet). ! make/modules/modules.config ! src/share/classes/sun/launcher/LauncherHelper.java ! src/share/classes/sun/misc/Launcher.java - test/java/lang/ClassLoader/setPackageAccess/org/openjdk/jigsaw/accesscontrol/SetPackageAccess.java - test/java/lang/ClassLoader/setPackageAccess/org/openjdk/jigsaw/accesscontrol/internal/Secret.java - test/java/lang/ClassLoader/setPackageAccess/org/openjdk/jigsaw/accesscontrol/p1/C1.java - test/java/lang/ClassLoader/setPackageAccess/org/openjdk/jigsaw/accesscontrol/p2/C2.java + test/java/lang/ClassLoader/setPackageAccess/test/SetPackageAccess.java + test/java/lang/ClassLoader/setPackageAccess/test/internal/Secret.java + test/java/lang/ClassLoader/setPackageAccess/test/p1/C1.java + test/java/lang/ClassLoader/setPackageAccess/test/p2/C2.java From alan.bateman at oracle.com Thu Sep 5 08:17:59 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 05 Sep 2013 15:17:59 +0000 Subject: hg: jigsaw/jake-gate/jdk: Update module config to put all of sun.misc in base module. Message-ID: <20130905151859.92F48625A7@hg.openjdk.java.net> Changeset: d050e294b708 Author: alanb Date: 2013-09-05 16:09 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake-gate/jdk/rev/d050e294b708 Update module config to put all of sun.misc in base module. Moved basic test for setPackageAccess to more sensible location. Add support methods to launcher to set access control (not used yet). ! make/modules/modules.config ! src/share/classes/sun/launcher/LauncherHelper.java ! src/share/classes/sun/misc/Launcher.java - test/java/lang/ClassLoader/setPackageAccess/org/openjdk/jigsaw/accesscontrol/SetPackageAccess.java - test/java/lang/ClassLoader/setPackageAccess/org/openjdk/jigsaw/accesscontrol/internal/Secret.java - test/java/lang/ClassLoader/setPackageAccess/org/openjdk/jigsaw/accesscontrol/p1/C1.java - test/java/lang/ClassLoader/setPackageAccess/org/openjdk/jigsaw/accesscontrol/p2/C2.java + test/java/lang/ClassLoader/setPackageAccess/test/SetPackageAccess.java + test/java/lang/ClassLoader/setPackageAccess/test/internal/Secret.java + test/java/lang/ClassLoader/setPackageAccess/test/p1/C1.java + test/java/lang/ClassLoader/setPackageAccess/test/p2/C2.java From david.bosschaert at gmail.com Thu Sep 5 08:31:49 2013 From: david.bosschaert at gmail.com (David Bosschaert) Date: Thu, 5 Sep 2013 16:31:49 +0100 Subject: Fwd: Jigsaw prototype, take 2 In-Reply-To: References: <20130828092751.449385@eggemoggin.niobe.net> <20130904153538.276977@eggemoggin.niobe.net> <522809B6.70000@cox.net> Message-ID: I always thought that JEP 161 was a great start for as much modularization as the JRE itself needs (which was always the root requirement of Jigsaw). I know it currently has 3 profiles, but we could always add more going forward. As regards to performance. It should definitely improve performance somewhat since you don't always load the whole rt.jar. I'm not sure I fully understand the 'transform module content during installation' piece but I question why you would need an actual module system for this. Could the Java runtime not do this under the hood as an internal optimization? I know JEP 161 isn't a 'real' module system, but I question why the JRE itself would actually need a full blown module system for it's own purposes. For people building on top of Java SE there are other module systems already available such as OSGi and JBoss Modules. Best regards, David On 5 September 2013 05:33, Gregg Wonderly wrote: > Indeed! An incremental improvement over time is the best way to provide > something, get feedback, adjust, and continue. In the end, there is not > enough time in the day for perfect, and there is little change that perfect > will last for very long. So compromise and delivery of something to start > with, might be the best choice. > > Ultimately, if Oracle would just allow developers to "prune" the jars to > what we need, and/or remake the binary part of what we are using to have > exactly and only what we need, that would make for the best approach. > > The fact of the matter is that few people are actually deploying Java as a > "platform". They are deploying it as a "runtime environment", and that > means that they know the extent of the feature set that they need. > > Java as a generic platform has failed because Sun and Oracle now, have > failed to understand the importance of supporting the desktop environment > with something that was "library" like, and instead, staying focused on the > Jave-EE platform world where "new content" is deployed into the runtime > environment and thus requires the "totality" of the platform, because you > just never know what might be deployed. > > On the desktop and most "applications" that aren't tied to Java-EE, Java > is used like a library, and thus people really don't understand why they > can't just use what they need, and pull the reset "out". > > There is no benefit that Sun/Oracle receive from disallowing this in > licensing. Instead, they've managed to make sure that Java is not > desirable for anything other than large scale application deployment. > > Gregg Wonderly > > > On 9/4/2013 9:44 PM, Neil Bartlett wrote: > >> And yet, JEP 161 addresses the most pressing requirement from Java >> developers: a smaller, more embeddable JRE. >> >> Furthermore it actually seems to be deliverable within a reasonable >> time scale (JDK8) rather than a continually slipping, indeterminate >> future. >> >> - Neil >> >> On Wed, Sep 4, 2013 at 11:35 PM, wrote: >> >>> 2013/8/30 0:35 -0700, david.bosschaert at gmail.com: >>> >>>> My understanding is that JEP 161 (http://openjdk.java.net/jeps/**161) >>>> already >>>> addresses many requirements for modularizing the Java runtime. JEP 161 >>>> should address the concerns around creating a scalable platform and >>>> improve >>>> performance. >>>> >>>> I would like to understand what requirements in addition to JEP 161 this >>>> prototype aims to address. >>>> >>> JEP 161 is an interim solution to the problem of scaling the platform. >>> It "modularizes" the platform in only the crudest sense, defining just >>> three modules. If an application uses just one API from the largest >>> profile and otherwise requires only the smallest profile then there is >>> no choice but to use an implementation of the largest profile. >>> >>> As to performance, JEP 161 doesn't address that at all. The kinds of >>> performance improvements we've always aimed to enable with Jigsaw >>> involve transforming module content during installation. >>> >>> - Mark >>> >> > From mark.reinhold at oracle.com Thu Sep 5 20:51:06 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 05 Sep 2013 20:51:06 -0700 Subject: Fwd: Jigsaw prototype, take 2 In-Reply-To: References: <20130828092751.449385@eggemoggin.niobe.net>, , <20130904153538.276977@eggemoggin.niobe.net>, <522809B6.70000@cox.net>, , Message-ID: <20130905205107.64@eggemoggin.niobe.net> 2013/9/5 1:31 -0700, david.bosschaert at gmail.com: > I always thought that JEP 161 was a great start for as much modularization > as the JRE itself needs (which was always the root requirement of Jigsaw). > I know it currently has 3 profiles, but we could always add more going > forward. The profile model is inherently limited, since each profile is a self-contained runtime. If we keep adding more over time then it's going to become burdensome to keep track of them all, and to know which APIs are in which profiles. Wouldn't it be easier to be able to think about the platform as a set of modules from which you can pick and choose as needed? Kind of like all those handy libraries you find in /usr/lib. > As regards to performance. It should definitely improve performance > somewhat since you don't always load the whole rt.jar. I'm not sure I fully > understand the 'transform module content during installation' piece but I > question why you would need an actual module system for this. You don't absolutely need one, but it can help. Some ahead-of-time performance optimizations can be more effective when it is known that one class will only ever be able to refer to a limited number of other classes, rather than any arbitrary class on the class path. In a modular system the number of classes to which a class can refer is limited to those in the same module and in those in modules upon which that module depends. > I know JEP 161 isn't a 'real' module system, but I question why the JRE > itself would actually need a full blown module system for it's own > purposes. See above. - Mark From mark.reinhold at oracle.com Thu Sep 5 21:21:53 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 05 Sep 2013 21:21:53 -0700 Subject: Jigsaw prototype, take 2 In-Reply-To: <5227D55A.3020702@redhat.com> References: <20130828092751.449385@eggemoggin.niobe.net>, <20130904152746.356683@eggemoggin.niobe.net>, <5227D55A.3020702@redhat.com> Message-ID: <20130905212153.684742@eggemoggin.niobe.net> 2013/9/4 10:50 -0700, david.lloyd at redhat.com: > On 09/04/2013 05:27 PM, mark.reinhold at oracle.com wrote: >> Do you have links to any good descriptions of these best practices? >> That'd be helpful. > > Not a lot as links, as mostly they are "community knowledge" among our > various teams, but here's a couple for each that I can find relatively > quickly: > > For Maven: > > * Version ranges considered harmful [1] [2] [3] [4] (and probably more); > we disallow them within our own products for stability reasons > * Transitive-by-default causes problems in mid to large projects due to > extensive conflicts [can't find the discussion...]; fix is to use and > verify exclusions, specify "provided" scope, and use > maven-enforcer-plugin [5] to ban transitive dependencies Thanks. These observations match my own understanding of how Maven and similar tools (Ivy, Gradle) are used in practice. As far as I can tell one of the primary functions of these tools is to allow developers to correct broken version information in the artifacts they're trying to use, and of course to resolve conflicts. One developer I know put it this way: Nobody actually uses version constraints, and the actual version numbers in pom.xml files might as well be hash codes. > For OSGi: > > * Using the full capabilities of range dependencies can cause resolution > to be NP-complete; best practice is to use ranges in a more restricted > manner [6] Yes, though the degree to which this is a problem in practice seems unclear. > * Require-Bundle not recommended due to lack of hiding non-public > packages among other things [no link] (however, to be fair this is only > due to the way Require-Bundle was designed; it's not an inherent flaw, > but it is a best practice not to use it, hence it fits the criteria) Right. - Mark From mark.reinhold at oracle.com Thu Sep 5 21:31:59 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 05 Sep 2013 21:31:59 -0700 Subject: Transitive deps was: Jigsaw prototype, take 2 In-Reply-To: <52289C8A.5080201@redhat.com> References: <20130828092751.449385@eggemoggin.niobe.net>, <20130904152746.356683@eggemoggin.niobe.net>, <5227D55A.3020702@redhat.com>, <1490871.zO0yRBcP4C@logouticek>, , <52289C8A.5080201@redhat.com> Message-ID: <20130905213159.870598@eggemoggin.niobe.net> 2013/9/5 1:00 -0700, david.lloyd at redhat.com: > ... > > Indeed, once again we don't know what worked and what didn't work and > why, and what Oracle is *really* after. Instead we are expected to be > lulled by the disclaimer that "this is just another prototype [that you > know nothing about]". Just to be clear, I don't expect anybody to be lulled. I'm working on a longer writeup, which I hope to post soon, and I will welcome all (calm and rational) comments and questions in response. (In retrospect perhaps we should've started work on the new prototype in a private repository -- but then, no doubt, someone would later accuse us of working behind closed doors in a different way. Sigh.) - Mark From alan.bateman at oracle.com Fri Sep 6 06:31:44 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 06 Sep 2013 13:31:44 +0000 Subject: hg: jigsaw/jake-gate/hotspot: Improve +TracePackageAccess option Message-ID: <20130906133201.A470762606@hg.openjdk.java.net> Changeset: 6ffe731d2b50 Author: alanb Date: 2013-09-06 14:26 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake-gate/hotspot/rev/6ffe731d2b50 Improve +TracePackageAccess option Allow package access to be set on the unnamed package ! src/share/vm/classfile/classLoaderExports.cpp From alan.bateman at oracle.com Fri Sep 6 06:31:53 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 06 Sep 2013 13:31:53 +0000 Subject: hg: jigsaw/jake/jdk: Add -mods option to launcher Message-ID: <20130906133222.E7A3862607@hg.openjdk.java.net> Changeset: c85c96f85f2a Author: alanb Date: 2013-09-06 14:27 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c85c96f85f2a Add -mods option to launcher Allow package access to be set on the unnamed package ! src/share/bin/emessages.h ! src/share/bin/java.c ! src/share/classes/java/lang/ClassLoader.java ! src/share/classes/sun/launcher/LauncherHelper.java ! src/share/classes/sun/misc/VM.java + test/java/lang/ClassLoader/setPackageAccess/Unnamed.java From alan.bateman at oracle.com Fri Sep 6 06:31:37 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 06 Sep 2013 13:31:37 +0000 Subject: hg: jigsaw/jake/hotspot: Improve +TracePackageAccess option Message-ID: <20130906133144.EC28362605@hg.openjdk.java.net> Changeset: 6ffe731d2b50 Author: alanb Date: 2013-09-06 14:26 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/6ffe731d2b50 Improve +TracePackageAccess option Allow package access to be set on the unnamed package ! src/share/vm/classfile/classLoaderExports.cpp From alan.bateman at oracle.com Fri Sep 6 06:32:22 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 06 Sep 2013 13:32:22 +0000 Subject: hg: jigsaw/jake-gate/jdk: Add -mods option to launcher Message-ID: <20130906133319.9164F62608@hg.openjdk.java.net> Changeset: c85c96f85f2a Author: alanb Date: 2013-09-06 14:27 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake-gate/jdk/rev/c85c96f85f2a Add -mods option to launcher Allow package access to be set on the unnamed package ! src/share/bin/emessages.h ! src/share/bin/java.c ! src/share/classes/java/lang/ClassLoader.java ! src/share/classes/sun/launcher/LauncherHelper.java ! src/share/classes/sun/misc/VM.java + test/java/lang/ClassLoader/setPackageAccess/Unnamed.java From njbartlett at gmail.com Fri Sep 6 06:57:53 2013 From: njbartlett at gmail.com (Neil Bartlett) Date: Fri, 6 Sep 2013 14:57:53 +0100 Subject: Transitive deps was: Jigsaw prototype, take 2 In-Reply-To: <20130905213159.870598@eggemoggin.niobe.net> References: <20130828092751.449385@eggemoggin.niobe.net> <20130904152746.356683@eggemoggin.niobe.net> <5227D55A.3020702@redhat.com> <1490871.zO0yRBcP4C@logouticek> <52289C8A.5080201@redhat.com> <20130905213159.870598@eggemoggin.niobe.net> Message-ID: It's not a problem that your developers started work on the new prototype, and I'm glad they are doing so in the open. Clearly they must be working to *some* kind of requirements, even if only informally specified within your team. My concern was that the requirements would not be published, or that your brief email that kicked off this thread was all we were going to get. So, thanks for clarifying that a longer write-up is in the works. Neil On Fri, Sep 6, 2013 at 5:31 AM, wrote: > 2013/9/5 1:00 -0700, david.lloyd at redhat.com: >> ... >> >> Indeed, once again we don't know what worked and what didn't work and >> why, and what Oracle is *really* after. Instead we are expected to be >> lulled by the disclaimer that "this is just another prototype [that you >> know nothing about]". > > Just to be clear, I don't expect anybody to be lulled. I'm working on a > longer writeup, which I hope to post soon, and I will welcome all (calm > and rational) comments and questions in response. > > (In retrospect perhaps we should've started work on the new prototype in > a private repository -- but then, no doubt, someone would later accuse > us of working behind closed doors in a different way. Sigh.) > > - Mark From niftiness at gmail.com Fri Sep 6 07:33:33 2013 From: niftiness at gmail.com (Tim Boudreau) Date: Fri, 6 Sep 2013 10:33:33 -0400 Subject: Modularization [was: Jigsaw prototype, take 2] Message-ID: I think there are two very different things which a "module system" addresses, and it seems like folks on this list have differing views of which is important or even if both of them are: 1. Carving up the JDK into smaller chunks for performance 2. Defining how Java software can be componentized in general and providing discovery and enforcement mechanisms, to increase the efficiency of Java developers and decrease the maintenance cost of what they write. The most straightforward way to do 1. for the JDK team will result in doing at least some of 2. - add at least minimal dependency management. Sure, that could be done as a one-off, ad-hoc kind of thing - but it's going to be about the same amount of work as to create a more generalized mechanism which other things can use. And because Java licensees will need to use the result, it has to be documented and not terribly crufty. So the desire to do a very scoped back "module system" to solve just that problem is understandable. There are a lot of degrees of "modularity", and probably a lot of different definitions of what that is on this list. My background is a lot of work with the NetBeans module system when I was at Sun, which does quite a few things: - Fail fast on startup if a dependency is missing, or disable functionality - Discover and validate dependencies at runtime, including checking versions - Forbid circular dependencies - Require all dependencies to be declared explicitly (no transient closure) - Enforce that a module may only reference classes from its dependencies with hierarchical classloaders - Extend the Java visibility rules to make possible "jar-private" public classes (non-public packages) - Provide a mechanism for a module to specify that it needs *some* implementation of a spec but doesn't care which one (similar to a program needing a mailer but not caring if it's sendmail, postfix or exim) - Allow modules to be installed and uninstalled dynamically at runtime All of these things are useful; a few of them are difficult to do without others, but Many are fairly orthogonal and could stand alone. You could probably meet most people's test of modularity with only some of them. Not modular with a capital-M, but the bare minimum. I often find when there is a lot of iteration without a lot of progress (or with a lot of argument), usually people are using the same words for different things. When somebody says "modular", in fact, they could be talking about any of, or any subset of, the list above. Re the JDK: You could probably just do "fails fast if a dependency is missing", claim "we modularized the JDK" and declare victory (which seemed to be the proposal in the last few messages). All you'd have to implement is a classloader which fails if any JAR it expects is missing, and a way to say what JARs should be there. That's hardly worth a JSR - it's an evening or two's coding (and a lot more testing). But as an incremental starting step, if it leaves the door open for the other things in the above list, it might be a pretty good start. The problems which need to be solved are larger than breaking up the JDK into more JARs + a spec to specify them. The last ten years have been about our entire industry discovering that directed graphs of dependencies are really, really important. You can't write software or use computers the way a developer does without tripping over somebody's dependency management system every few minutes - maven dependencies, netbeans module dependencies, Gentoo Linux ebuild dependencies, SmartOS pkgsrc dependencies, RPMs, Debian packages, NodeJS modules, Bower client-side javascript dependencies, RequireJS lazy loading - *everyone* has discovered they have the same problem and invented things that all converge on the same patterns of solution (yet are incompatible :-)). Another way of saying this is that it turns out, everything is system software - or benefits by pretending to be - and there is no class of software developer that benefits long-term from the freedom to be sloppy. There is an annoying hubris among framework authors that goes something like "I'm writing a big important framework. People who use my framework are writing sloppy little tinkertoy apps and couldn't possibly need the tools to solve the problems big important frameworks have!" It leads to solutions which are just naive enough not to be usable. The JDK has been guilty of this (ServiceLoader, anyone?), but *everybody* does it unless they're on guard for it. The problems the list above solves are fundamental to distributed software development and large teams. I compile my OS from source - and it's safe to say that most of the people who wrote the software on my computer have never met. Nobody's going to get everybody who works on Linux in a room or on a call, and if you could it would be wildly unproductive. Modularity and it's enforcement - whether as OS-level packages or Java modules - makes it possible for people not co-located in space or time to work independently and be productive. With our entire industry discovering and dealing with those problems, because solving it is critical to getting stuff done, it seems unlikely that Java gets a pass to ignore it without bad consequences. Which is why just writing a classloader and a spec for dependencies and saying "Done! It's modular!" is a good start, but isn't actually going to help enough to matter. I get that many people are clamoring for a leaner JDK. Is it the "most pressing concern"? It depends whom you talk to. Certainly, looking at V8's startup performance, it's clear there's room for improvement. In my post-Sun consulting life, aside from fixing people's threading, the thing I often get hired to do is to detangle someone's dependencies, inject some discipline into how their codebase is architected - by small-m modularizing it; teach them how to think about software design so that they won't end up back in a similar mess later; and add some enforcement mechanisms to their build process so that the wrong thing stops being the easiest thing. Nobody sets out to end up with a codebase their own people don't understand - yet routinely that's where software shops end up - really, really often. The value of medium-m to capital-M modularity isn't that it makes things pretty. I'm a pragmatist. It's that it improves quality and productivity (I can back up that assertion, but this email is already long). The value is that you get better parallelism from developers if the software is less coupled and has natural areas - modules - in which developers can work independently. Things like API package enforcement further improve that because it is easier to predict the effect of changes in components with well-defined, tightly scoped contracts. The value of modularity, to me, is all about people, not architecture for architecture's sake. All of that is to say, there is another pressing requirement from Java developers (one fewer know they have, but which keeps me employed): Make it harder to write broken things and easier to write maintainable things. It's the difference between trying to invent the world's best ice scraper for car windshields versus inventing the remote control that lets you start your car from in the house so it can defrost itself. I don't think it's an all or nothing proposition. A lot of the things on that list above are orthagonal. I don't think they're deserving of individual JSRs, but it would make sense to carve them up as separate deliverables. -Tim From eric at tibco.com Fri Sep 6 09:30:50 2013 From: eric at tibco.com (Eric Johnson) Date: Fri, 6 Sep 2013 09:30:50 -0700 Subject: Modularization [was: Jigsaw prototype, take 2] In-Reply-To: References: Message-ID: <522A033A.3030003@tibco.com> On 9/6/13 7:33 AM, Tim Boudreau wrote: > A lot of the things on > that list above are orthagonal. Yes. Eric From niftiness at gmail.com Fri Sep 6 20:22:27 2013 From: niftiness at gmail.com (Tim Boudreau) Date: Fri, 6 Sep 2013 23:22:27 -0400 Subject: Jigsaw prototype, take 2 In-Reply-To: <5220A2A5.9010700@cox.net> References: <20130828092751.449385@eggemoggin.niobe.net> <5220A2A5.9010700@cox.net> Message-ID: Gregg, We've worked together and I respect your judgement. That said, I have to disagree pretty strongly with the idea of *not* enforcing that dependencies be a directed acyclic graph as the default. Fundamentally, if you are developing two things, and there is a circular dependency between them, you do not have *two* things - you have one thing which you enjoy pretending is two. If neither can exist without the other, their independence is in illusion. I agree that sometimes you need that sort of thing, dealing with legacy software and so forth. Not too long ago, I did some detangling of a project for a company that could only compile their software if they compiled against (and shipped) two historical versions of their own product, and not a soul there actually knew what got loaded and linked at runtime. Terrifying but true. But that being the default is the source of a *lot* of problems. And having to understand dependencies teaches understanding of dependencies, which affects how developers think about designing software. And explicit, non-cyclical dependencies make possible - trivial, even - very useful sorts of static analysis. I've developed a similar attitude toward Maven. Flexibility can be harmful, especially when there's no obvious right way to do things - it gives you enough rope to hang yourself. I've seen so many Make and Ant based projects where there was only one person in the organization who understood how their build system worked. Maven is inflexible in the extreme - there's a lot I really dislike about it. But it is utterly unambiguous. Managed dependencies are like that. You *want* inflexibility as a default. Sure, you also want the ability to write your own classloader (IMO, bytecode-over-the-wire is still one of the actually interesting things about Java) and do what you want - the occasions are rare, but when you need it, you need it. But even when you *do* need it, what are you loading those classes *from*? If it's non-trivial and you want it to work, you need...its dependencies! So I suspect even when you're doing wild-west classloading, there are still benefits to having this stuff be explicit and unambiguous. I understand that for a lot of people, this JSR is about making the JDK leaner and meaner. But I think there are opportunities here to do things that dramatically reduce the maintenance cost of new software written in Java, and it would be a pity not to seize the opportunity to kill two birds with one stone. -Tim From alan.bateman at oracle.com Sat Sep 7 03:33:34 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sat, 07 Sep 2013 10:33:34 +0000 Subject: hg: jigsaw/jake: 15 new changesets Message-ID: <20130907103336.CC3E862648@hg.openjdk.java.net> Changeset: f8405a0fa69c Author: erikj Date: 2013-08-26 13:43 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/f8405a0fa69c 8023216: Feedback on README-builds.html Reviewed-by: anthony, robilad, tbell ! README-builds.html Changeset: 5166118c5917 Author: katleman Date: 2013-08-26 17:34 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/5166118c5917 Merge Changeset: 246cdbaa6c62 Author: cl Date: 2013-08-29 09:41 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/246cdbaa6c62 Added tag jdk8-b105 for changeset 5166118c5917 ! .hgtags Changeset: c8da1b6a9762 Author: mduigou Date: 2013-08-20 17:44 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/c8da1b6a9762 8023433: Improve 'make help' Reviewed-by: tbell ! NewMakefile.gmk Changeset: f643fee2b40f Author: mduigou Date: 2013-08-26 10:09 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/f643fee2b40f 8023491: Remove target names from test/Makefile and defer to sub-repo makefiles. Reviewed-by: erikj ! common/makefiles/Main.gmk ! test/Makefile Changeset: 163091288aeb Author: lana Date: 2013-08-26 14:49 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/163091288aeb Merge ! common/makefiles/Main.gmk Changeset: 51a61778a99d Author: mduigou Date: 2013-08-29 16:04 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/51a61778a99d 8023892: test/Makefile shouldn't try to tell langtools/test/Makefile where to put output. Reviewed-by: erikj, vromero, henryjen ! test/Makefile Changeset: 4ac867c44467 Author: lana Date: 2013-08-29 16:18 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/4ac867c44467 Merge Changeset: 21198f51bc7e Author: erikj Date: 2013-08-29 15:47 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/21198f51bc7e 8003162: build-infra: Improve suggestions for missing packages on linux Reviewed-by: tbell, omajid ! common/autoconf/generated-configure.sh ! common/autoconf/help.m4 ! common/autoconf/libraries.m4 Changeset: 92facce22941 Author: erikj Date: 2013-08-30 10:13 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/92facce22941 8023957: Lock down version of autoconf Reviewed-by: chegar, dsamersoff, tbell, dholmes ! README-builds.html ! common/autoconf/autogen.sh ! common/autoconf/configure.ac ! common/autoconf/generated-configure.sh Changeset: 2aacc7080d36 Author: katleman Date: 2013-09-03 13:48 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/2aacc7080d36 Merge Changeset: 0f6dde6231bd Author: ihse Date: 2013-09-04 10:15 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/0f6dde6231bd 8024155: Fix 'make CONF= ' Reviewed-by: erikj, tbell ! NewMakefile.gmk ! common/makefiles/Main.gmk Changeset: 8e7b4d9fb00f Author: erikj Date: 2013-09-04 10:37 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/8e7b4d9fb00f Merge ! NewMakefile.gmk ! common/makefiles/Main.gmk Changeset: 58f1b6f32b47 Author: cl Date: 2013-09-05 02:45 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/58f1b6f32b47 Added tag jdk8-b106 for changeset 8e7b4d9fb00f ! .hgtags Changeset: 172563926359 Author: alanb Date: 2013-09-07 08:56 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/172563926359 Merge ! common/autoconf/configure.ac ! common/autoconf/generated-configure.sh From alan.bateman at oracle.com Sat Sep 7 03:35:29 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sat, 07 Sep 2013 10:35:29 +0000 Subject: hg: jigsaw/jake/jaxws: 6 new changesets Message-ID: <20130907103546.E94926264B@hg.openjdk.java.net> Changeset: 01be6f93d0a4 Author: cl Date: 2013-08-29 09:41 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/01be6f93d0a4 Added tag jdk8-b105 for changeset 88390df7ed2c ! .hgtags Changeset: b99d7e355d4b Author: mkos Date: 2013-08-23 09:57 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/b99d7e355d4b 8022885: Update JAX-WS RI integration to 2.2.9-b14140 8013016: Rebase 8009009 against the latest jdk8/jaxws Reviewed-by: alanb, chegar ! src/share/jaxws_classes/com/sun/istack/internal/tools/ParallelWorldClassLoader.java ! src/share/jaxws_classes/com/sun/org/glassfish/external/probe/provider/annotations/Probe.java ! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/impl/AverageRangeStatisticImpl.java ! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/impl/BoundaryStatisticImpl.java ! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/impl/BoundedRangeStatisticImpl.java ! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/impl/CountStatisticImpl.java ! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/impl/RangeStatisticImpl.java ! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/impl/StatisticImpl.java ! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/impl/StringStatisticImpl.java ! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/impl/TimeStatisticImpl.java ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_de.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_es.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_fr.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_it.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_ja.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_ko.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_pt_BR.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_zh_CN.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_zh_TW.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/AttributesImpl.java ! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/Classes.java ! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/Config.java ! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/NGCCEventReceiver.java ! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/NGCCEventSource.java ! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/NGCCHandler.java ! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/NGCCInterleaveFilter.java ! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/NGCCRuntime.java ! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/Schema.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/version.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_de.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_es.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_fr.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_it.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_ja.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_ko.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_pt_BR.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_zh_CN.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_zh_TW.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/SchemaCache.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlAccessorOrderWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlAccessorTypeWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlAnyAttributeWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlAnyElementWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlAttachmentRefWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlAttributeWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlElementDeclWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlElementRefWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlElementRefsWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlElementWrapperWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlElementWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlElementsWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlEnumValueWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlEnumWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlIDREFWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlIDWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlInlineBinaryDataWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlJavaTypeAdapterWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlListWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlMimeTypeWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlMixedWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlNsWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlRegistryWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlRootElementWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlSchemaTypeWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlSchemaTypesWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlSchemaWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlSeeAlsoWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlTransientWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlTypeWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlValueWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/bean/MessageBundle.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/model/CPropertyInfo.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/model/CTypeRef.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/model/package-info.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/internalizer/AbstractReferenceFinderImpl.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/internalizer/DOMForest.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/Util.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/Messages.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/Messages.properties ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/Init.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlAttributeQuick.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlElementDeclQuick.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlElementQuick.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlElementRefQuick.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlElementRefsQuick.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlEnumQuick.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlRootElementQuick.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlSchemaQuick.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlSchemaTypeQuick.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlTransientQuick.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlTypeQuick.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlValueQuick.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/core/package-info.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeBuiltinLeafInfoImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/package-info.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/BridgeAdapter.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/Coordinator.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/XMLSerializer.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/PrimitiveArrayListerBoolean.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/PrimitiveArrayListerCharacter.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/PrimitiveArrayListerDouble.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/PrimitiveArrayListerFloat.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/PrimitiveArrayListerInteger.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/PrimitiveArrayListerLong.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/PrimitiveArrayListerShort.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Boolean.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Character.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Double.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Float.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Integer.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Long.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Short.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Boolean.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Character.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Double.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Float.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Integer.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Long.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Short.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_field_Double.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_field_Float.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_field_Long.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_field_Short.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_method_Boolean.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_method_Double.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_method_Float.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_method_Long.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_method_Short.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/Loader.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/Messages.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/Messages.properties ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/SAXConnector.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/UnmarshallingContext.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/XsiTypeLoader.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Annotated.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Annotation.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Any.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Appinfo.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/AttrDecls.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/AttributeType.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/ComplexContent.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/ComplexExtension.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/ComplexRestriction.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/ComplexType.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/ComplexTypeHost.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/ComplexTypeModel.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Documentation.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Element.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/ExplicitGroup.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/ExtensionType.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/FixedOrDefault.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Import.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/List.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/LocalAttribute.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/LocalElement.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/NestedParticle.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/NoFixedFacet.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Occurs.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Redefinable.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Schema.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/SchemaTop.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/SimpleContent.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/SimpleDerivation.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/SimpleExtension.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/SimpleRestriction.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/SimpleRestrictionModel.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/SimpleType.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/SimpleTypeHost.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/TopLevelAttribute.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/TopLevelElement.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/TypeDefParticle.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/TypeHost.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Union.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Wildcard.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/util/EditDistance.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/util/XmlFactory.java ! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/DTDEventListener.java ! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/DTDHandlerBase.java ! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/DTDParser.java ! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/EndOfInputException.java ! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/EntityDecl.java ! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/ExternalEntity.java ! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/InputEntity.java ! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/InternalEntity.java ! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/MessageCatalog.java ! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/Resolver.java ! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/SimpleHashtable.java ! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/XmlChars.java ! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/XmlNames.java ! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/XmlReader.java ! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/package.html ! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/resources/Messages.properties ! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/AbstractCreatorProcessor.java ! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/AbstractProcessor.java ! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/AttributesHolder.java ! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/FragmentedArray.java ! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/MutableXMLStreamBuffer.java ! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/XMLStreamBuffer.java ! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/XMLStreamBufferException.java ! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/XMLStreamBufferMark.java ! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/XMLStreamBufferResult.java ! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/XMLStreamBufferSource.java ! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/sax/DefaultWithLexicalHandler.java ! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/sax/Features.java ! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/sax/Properties.java ! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/sax/SAXBufferCreator.java ! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/stax/StreamBufferCreator.java ! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/stax/StreamReaderBufferCreator.java ! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/stax/StreamReaderBufferProcessor.java ! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/stax/StreamWriterBufferCreator.java ! src/share/jaxws_classes/com/sun/xml/internal/txw2/output/XMLWriter.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/message/Packet.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/Container.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/ThreadLocalContainerResolver.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/streaming/XMLStreamReaderFactory.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/wsdl/writer/WSDLGeneratorExtension.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/commons/xmlutil/Converter.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/MtomCodec.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/StreamSOAP11Codec.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/StreamSOAP12Codec.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/StreamSOAPCodec.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/TagInfoset.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/message/AbstractMessageImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/message/jaxb/JAXBHeader.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/message/jaxb/JAXBMessage.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/message/saaj/SAAJMessage.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/message/stream/StreamMessage.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/StreamingMessages.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/streaming.properties ! src/share/jaxws_classes/com/sun/xml/internal/ws/server/SDDocumentImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/spi/db/BindingContext.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/pipe/AbstractSchemaValidationTube.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/resources/Messages_en.properties ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/version.properties ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/xml/XmlUtil.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/WSDLGenerator.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/Messages.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/Messages.properties ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/SAXParserFactoryAdaptor.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/Schema.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/SimpleType_List.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/SimpleType_Restriction.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/SimpleType_Union.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/annotation.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/attributeDeclBody.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/attributeGroupDecl.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/attributeUses.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/complexType.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/complexType_complexContent_body.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/elementDeclBody.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/erSet.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/ersSet.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/facet.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/group.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/identityConstraint.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/importDecl.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/includeDecl.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/modelGroupBody.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/notation.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/occurs.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/particle.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/qname.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/redefine.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/simpleType.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/wildcardBody.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/xpath.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/parser/JAXPParser.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/parser/XSOMParser.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/util/DomAnnotationParserFactory.java ! src/share/jaxws_classes/javax/xml/bind/Binder.java ! src/share/jaxws_classes/javax/xml/bind/ContextFinder.java ! src/share/jaxws_classes/javax/xml/bind/DataBindingException.java ! src/share/jaxws_classes/javax/xml/bind/DatatypeConverter.java ! src/share/jaxws_classes/javax/xml/bind/DatatypeConverterImpl.java ! src/share/jaxws_classes/javax/xml/bind/DatatypeConverterInterface.java ! src/share/jaxws_classes/javax/xml/bind/Element.java ! src/share/jaxws_classes/javax/xml/bind/GetPropertyAction.java ! src/share/jaxws_classes/javax/xml/bind/JAXB.java ! src/share/jaxws_classes/javax/xml/bind/JAXBContext.java ! src/share/jaxws_classes/javax/xml/bind/JAXBElement.java ! src/share/jaxws_classes/javax/xml/bind/JAXBException.java ! src/share/jaxws_classes/javax/xml/bind/JAXBIntrospector.java ! src/share/jaxws_classes/javax/xml/bind/JAXBPermission.java ! src/share/jaxws_classes/javax/xml/bind/MarshalException.java ! src/share/jaxws_classes/javax/xml/bind/Messages.java ! src/share/jaxws_classes/javax/xml/bind/Messages.properties ! src/share/jaxws_classes/javax/xml/bind/NotIdentifiableEvent.java ! src/share/jaxws_classes/javax/xml/bind/ParseConversionEvent.java ! src/share/jaxws_classes/javax/xml/bind/PrintConversionEvent.java ! src/share/jaxws_classes/javax/xml/bind/PropertyException.java ! src/share/jaxws_classes/javax/xml/bind/SchemaOutputResolver.java ! src/share/jaxws_classes/javax/xml/bind/TypeConstraintException.java ! src/share/jaxws_classes/javax/xml/bind/UnmarshalException.java ! src/share/jaxws_classes/javax/xml/bind/Unmarshaller.java ! src/share/jaxws_classes/javax/xml/bind/UnmarshallerHandler.java ! src/share/jaxws_classes/javax/xml/bind/ValidationEvent.java ! src/share/jaxws_classes/javax/xml/bind/ValidationEventHandler.java ! src/share/jaxws_classes/javax/xml/bind/ValidationEventLocator.java ! src/share/jaxws_classes/javax/xml/bind/ValidationException.java ! src/share/jaxws_classes/javax/xml/bind/Validator.java ! src/share/jaxws_classes/javax/xml/bind/WhiteSpaceProcessor.java ! src/share/jaxws_classes/javax/xml/bind/annotation/DomHandler.java ! src/share/jaxws_classes/javax/xml/bind/annotation/W3CDomHandler.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlAccessOrder.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlAccessType.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlAccessorOrder.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlAccessorType.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlAnyAttribute.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlAnyElement.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlAttachmentRef.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlAttribute.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlElement.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlElementDecl.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlElementRef.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlElementRefs.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlElementWrapper.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlElements.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlEnum.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlEnumValue.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlID.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlIDREF.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlList.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlMixed.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlNs.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlNsForm.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlRegistry.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlRootElement.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlSchema.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlSchemaType.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlSchemaTypes.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlSeeAlso.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlTransient.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlType.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlValue.java ! src/share/jaxws_classes/javax/xml/bind/annotation/adapters/CollapsedStringAdapter.java ! src/share/jaxws_classes/javax/xml/bind/annotation/adapters/HexBinaryAdapter.java ! src/share/jaxws_classes/javax/xml/bind/annotation/adapters/NormalizedStringAdapter.java ! src/share/jaxws_classes/javax/xml/bind/annotation/adapters/XmlJavaTypeAdapter.java ! src/share/jaxws_classes/javax/xml/bind/annotation/adapters/XmlJavaTypeAdapters.java ! src/share/jaxws_classes/javax/xml/bind/annotation/adapters/package.html ! src/share/jaxws_classes/javax/xml/bind/annotation/package.html ! src/share/jaxws_classes/javax/xml/bind/attachment/AttachmentMarshaller.java ! src/share/jaxws_classes/javax/xml/bind/attachment/AttachmentUnmarshaller.java ! src/share/jaxws_classes/javax/xml/bind/attachment/package.html ! src/share/jaxws_classes/javax/xml/bind/helpers/AbstractMarshallerImpl.java ! src/share/jaxws_classes/javax/xml/bind/helpers/AbstractUnmarshallerImpl.java ! src/share/jaxws_classes/javax/xml/bind/helpers/DefaultValidationEventHandler.java ! src/share/jaxws_classes/javax/xml/bind/helpers/Messages.java ! src/share/jaxws_classes/javax/xml/bind/helpers/Messages.properties ! src/share/jaxws_classes/javax/xml/bind/helpers/NotIdentifiableEventImpl.java ! src/share/jaxws_classes/javax/xml/bind/helpers/ParseConversionEventImpl.java ! src/share/jaxws_classes/javax/xml/bind/helpers/PrintConversionEventImpl.java ! src/share/jaxws_classes/javax/xml/bind/helpers/ValidationEventImpl.java ! src/share/jaxws_classes/javax/xml/bind/helpers/ValidationEventLocatorImpl.java ! src/share/jaxws_classes/javax/xml/bind/helpers/package.html ! src/share/jaxws_classes/javax/xml/bind/package.html ! src/share/jaxws_classes/javax/xml/bind/util/JAXBResult.java ! src/share/jaxws_classes/javax/xml/bind/util/JAXBSource.java ! src/share/jaxws_classes/javax/xml/bind/util/Messages.java ! src/share/jaxws_classes/javax/xml/bind/util/Messages.properties ! src/share/jaxws_classes/javax/xml/bind/util/ValidationEventCollector.java ! src/share/jaxws_classes/javax/xml/bind/util/package.html Changeset: d8593d8581df Author: mkos Date: 2013-08-23 11:10 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/d8593d8581df 8023636: Missing files from 8022885 Reviewed-by: alanb, chegar + src/share/jaxws_classes/com/sun/xml/internal/ws/api/message/StreamingSOAP.java + src/share/jaxws_classes/com/sun/xml/internal/ws/util/xml/NamespaceContextExAdaper.java + src/share/jaxws_classes/com/sun/xml/internal/ws/util/xml/XMLReaderComposite.java Changeset: 533c1032337c Author: lana Date: 2013-08-26 14:50 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/533c1032337c Merge Changeset: 6908370afe83 Author: lana Date: 2013-08-29 16:18 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/6908370afe83 Merge Changeset: e3c9328f7563 Author: cl Date: 2013-09-05 02:45 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/e3c9328f7563 Added tag jdk8-b106 for changeset 6908370afe83 ! .hgtags From alan.bateman at oracle.com Sat Sep 7 03:34:23 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sat, 07 Sep 2013 10:34:23 +0000 Subject: hg: jigsaw/jake/jaxp: 2 new changesets Message-ID: <20130907103435.F22A162649@hg.openjdk.java.net> Changeset: d3be8e3b429d Author: cl Date: 2013-08-29 09:41 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/d3be8e3b429d Added tag jdk8-b105 for changeset 09a46ec11f88 ! .hgtags Changeset: d6a32e3831aa Author: cl Date: 2013-09-05 02:45 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/d6a32e3831aa Added tag jdk8-b106 for changeset d3be8e3b429d ! .hgtags From alan.bateman at oracle.com Sat Sep 7 03:33:59 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sat, 07 Sep 2013 10:33:59 +0000 Subject: hg: jigsaw/jake/langtools: 23 new changesets Message-ID: <20130907103521.928EB6264A@hg.openjdk.java.net> Changeset: e431c9bfb171 Author: cl Date: 2013-08-29 09:42 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/e431c9bfb171 Added tag jdk8-b105 for changeset 375834b5cf08 ! .hgtags Changeset: 7de231613e4a Author: jjg Date: 2013-08-21 16:13 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/7de231613e4a 8023515: import type-annotations updates Reviewed-by: jjg Contributed-by: wdietl at gmail.com ! src/share/classes/com/sun/source/tree/MethodTree.java ! src/share/classes/com/sun/source/tree/TypeParameterTree.java ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! test/tools/javac/annotations/typeAnnotations/classfile/CombinationsTargetTest2.java + test/tools/javac/annotations/typeAnnotations/failures/DummyProcessor.java + test/tools/javac/annotations/typeAnnotations/failures/T8020715.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/Constructors.java + test/tools/javac/tree/TypeAnnotationsPretty.java Changeset: 2068190f8ac2 Author: emc Date: 2013-08-21 20:23 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/2068190f8ac2 7118412: Shadowing of type-variables vs. member types 4987840: What is the scope of an annotation? Summary: Fixed issue with shadowing of type names. Reviewed-by: jjg, abuckley, mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Resolve.java Changeset: 57e1266527dd Author: jjg Date: 2013-08-21 17:26 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/57e1266527dd 8022287: javac.sym.Profiles uses a static Map when it should not Reviewed-by: ksrini ! src/share/classes/com/sun/tools/javac/sym/Profiles.java + test/tools/javac/profiles/ProfileTest.java Changeset: eebb29618f50 Author: emc Date: 2013-08-21 20:41 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/eebb29618f50 8023520: Add missing test for JDK-7118412 Summary: The test for JDK-7118412 was dropped from the changeset in a merging accident. Reviewed-by: jjg + test/tools/javac/7118412/ShadowingTest.java Changeset: 7a4717f3ea7b Author: vromero Date: 2013-08-22 10:22 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/7a4717f3ea7b 8022316: Generic throws, overriding and method reference Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/T8022316/CompilerErrorGenericThrowPlusMethodRefTest.java + test/tools/javac/T8022316/CompilerErrorGenericThrowPlusMethodRefTest.out Changeset: 25aaff78d754 Author: vromero Date: 2013-08-22 13:12 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/25aaff78d754 8023112: javac should not use lazy constant evaluation approach for method references Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java + test/tools/javac/T8023112/SkipLazyConstantCreationForMethodRefTest.java Changeset: 1ab22e60a738 Author: emc Date: 2013-08-22 12:47 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/1ab22e60a738 8020745: Suspicious MethodParameters attribute generated for local classes capturing local variables Summary: Corrected an error in a previous patch that caused captured locals to be added to the beginning, not the end of a parameter list. Reviewed-by: jjg, mcimadamore, ksrini, abuckley ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java - test/tools/javac/8015701/AnonymousParameters.java + test/tools/javac/MethodParameters/CaptureTest.java Changeset: b77381d99056 Author: jjg Date: 2013-08-22 12:41 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/b77381d99056 8022173: Relax some warnings in doclint Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclint/HtmlTag.java ! test/tools/doclint/html/ListTagsTest.java ! test/tools/doclint/html/OtherTagsTest.java ! test/tools/doclint/html/OtherTagsTest.out ! test/tools/doclint/html/TableTagsTest.java Changeset: 60f156c653d3 Author: jjg Date: 2013-08-26 11:48 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/60f156c653d3 8023701: Fix badly named test Reviewed-by: bpatel - test/com/sun/javadoc/testNavagation/TestNavagation.java - test/com/sun/javadoc/testNavagation/pkg/A.java - test/com/sun/javadoc/testNavagation/pkg/C.java - test/com/sun/javadoc/testNavagation/pkg/E.java - test/com/sun/javadoc/testNavagation/pkg/I.java + test/com/sun/javadoc/testNavigation/TestNavigation.java + test/com/sun/javadoc/testNavigation/pkg/A.java + test/com/sun/javadoc/testNavigation/pkg/C.java + test/com/sun/javadoc/testNavigation/pkg/E.java + test/com/sun/javadoc/testNavigation/pkg/I.java Changeset: 7bf6313e1ced Author: jjg Date: 2013-08-26 15:55 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/7bf6313e1ced 8023768: Use the unannotatedType in cyclicity checks. Reviewed-by: jjg Contributed-by: wdietl at gmail.com ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/annotations/typeAnnotations/failures/TypeVariableCycleTest.java Changeset: 00ca54ceca1b Author: lana Date: 2013-08-26 14:54 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/00ca54ceca1b Merge Changeset: cc3fb73f5e08 Author: lana Date: 2013-08-26 22:18 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/cc3fb73f5e08 Merge Changeset: 7fb27bc201cc Author: bpatel Date: 2013-08-27 11:41 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/7fb27bc201cc 7052170: javadoc -charset option generates wrong meta tag Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlAttr.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java + test/com/sun/javadoc/testCharset/TestCharset.java + test/com/sun/javadoc/testCharset/pkg/Foo.java Changeset: 662a5188bded Author: darcy Date: 2013-08-27 11:58 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/662a5188bded 8023826: Typo in warning about obsolete source / target values Reviewed-by: jjg, wmdietl ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java Changeset: 7de7100c30ce Author: henryjen Date: 2013-08-28 10:17 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/7de7100c30ce 8014566: Remove @ignore tags from MethodReference66 and InInterface when 8013875 is fixed Reviewed-by: briangoetz, jjg ! test/tools/javac/lambda/MethodReference66.java ! test/tools/javac/lambda/lambdaExecution/InInterface.java Changeset: 189942cdf585 Author: jjg Date: 2013-08-28 15:40 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/189942cdf585 8010310: [javadoc] Error processing sources with -private Reviewed-by: vromero, mcimadamore ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javadoc/JavadocMemberEnter.java + test/tools/javadoc/nonConstExprs/Test.java Changeset: 0e6577980181 Author: jjg Date: 2013-08-29 11:41 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/0e6577980181 8001669: javadoc internal DocletAbortException should set cause when appropriate Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/AllClassesFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/DeprecatedListWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/FrameOutputWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HelpWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageTreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ProfileIndexFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageIndexFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SingleIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SplitIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/TreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/Comment.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/DocType.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocument.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/RawHtml.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/StringContent.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Content.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/LayoutParser.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/SerializedFormBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ValueTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassUseMapper.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocFile.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocletAbortException.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/PackageListWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/PathDocFileFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/SimpleDocFileFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/StandardDocFileFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java Changeset: b0b25c1f6cbd Author: jjg Date: 2013-08-29 11:57 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/b0b25c1f6cbd 8023522: tools/javac/tree/TypeAnnotationsPretty.java test cases with @TA newline fail on windows only Reviewed-by: darcy ! test/tools/javac/tree/TypeAnnotationsPretty.java Changeset: 9c0e192c0926 Author: jjg Date: 2013-08-29 12:03 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/9c0e192c0926 8013384: Potential infinite loop in javadoc Reviewed-by: darcy ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java Changeset: 96b6865eda94 Author: jjg Date: 2013-08-29 12:11 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/96b6865eda94 8022744: javac -Xpkginfo command's documentation is sparse Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/main/Option.java Changeset: fcd768844b99 Author: lana Date: 2013-08-29 16:34 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/fcd768844b99 Merge - test/com/sun/javadoc/testNavagation/TestNavagation.java - test/com/sun/javadoc/testNavagation/pkg/A.java - test/com/sun/javadoc/testNavagation/pkg/C.java - test/com/sun/javadoc/testNavagation/pkg/E.java - test/com/sun/javadoc/testNavagation/pkg/I.java - test/tools/javac/8015701/AnonymousParameters.java Changeset: 3f274927ec18 Author: cl Date: 2013-09-05 02:46 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/3f274927ec18 Added tag jdk8-b106 for changeset fcd768844b99 ! .hgtags From alan.bateman at oracle.com Sat Sep 7 03:37:01 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sat, 07 Sep 2013 10:37:01 +0000 Subject: hg: jigsaw/jake/nashorn: 26 new changesets Message-ID: <20130907103726.139946264E@hg.openjdk.java.net> Changeset: 824d33e678f2 Author: cl Date: 2013-08-29 09:42 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/824d33e678f2 Added tag jdk8-b105 for changeset f484bfb624dd ! .hgtags Changeset: dbb0a20a6f27 Author: attila Date: 2013-08-21 13:39 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/dbb0a20a6f27 8023373: allow super invocation for adapters Reviewed-by: lagergren, sundar ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator.java + test/script/basic/JDK-8023373.js + test/script/basic/JDK-8023373.js.EXPECTED Changeset: dc322503ce36 Author: attila Date: 2013-08-21 13:39 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/dc322503ce36 8022903: Enhance for-in and for-each for Lists and Maps Reviewed-by: lagergren, sundar ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java + test/script/basic/JDK-8022903.js + test/script/basic/JDK-8022903.js.EXPECTED Changeset: b7c04b3b01a7 Author: sundar Date: 2013-08-21 17:28 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/b7c04b3b01a7 8023368: Instance __proto__ property should exist and be writable. Reviewed-by: attila, hannesw ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! src/jdk/nashorn/internal/objects/NativeObject.java ! src/jdk/nashorn/internal/runtime/PropertyListener.java ! src/jdk/nashorn/internal/runtime/PropertyListenerManager.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java ! src/jdk/nashorn/internal/runtime/ScriptEnvironment.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/resources/Messages.properties ! src/jdk/nashorn/internal/runtime/resources/Options.properties ! src/jdk/nashorn/internal/runtime/resources/mozilla_compat.js + test/script/basic/JDK-8023368.js + test/script/basic/JDK-8023368.js.EXPECTED + test/script/basic/JDK-8023368_2.js + test/script/basic/JDK-8023368_2.js.EXPECTED + test/script/basic/circular_proto.js + test/script/basic/circular_proto.js.EXPECTED + test/script/basic/mirror_proto_assign.js + test/script/basic/mirror_proto_assign.js.EXPECTED + test/script/basic/nonextensible_proto_assign.js + test/script/basic/nonextensible_proto_assign.js.EXPECTED Changeset: 54f60d91024c Author: sundar Date: 2013-08-22 18:46 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/54f60d91024c 8023551: Mirror functions can not be invoked using invokeMethod, invokeFunction Reviewed-by: attila, jlaskey, lagergren ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java + test/script/basic/JDK-8023551.js + test/script/basic/JDK-8023551.js.EXPECTED ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java Changeset: 8ad9bcb04e6d Author: hannesw Date: 2013-08-22 17:23 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/8ad9bcb04e6d 8023531: new RegExp('').toString() should return '/(?:)/' Reviewed-by: sundar, jlaskey ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/WithObject.java ! src/jdk/nashorn/internal/runtime/regexp/RegExp.java + test/script/basic/JDK-8023531.js Changeset: c5c5ab3f420a Author: jlaskey Date: 2013-08-22 13:51 -0300 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/c5c5ab3f420a 8023228: Debugger information gather is too slow. Reviewed-by: sundar, lagergren Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/runtime/Context.java + src/jdk/nashorn/internal/runtime/DebuggerSupport.java Changeset: 5a1e07b9a3cd Author: sundar Date: 2013-08-22 22:32 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/5a1e07b9a3cd 8023560: Arbitrary javax.script.Bindings objects as ENGINE_SCOPE objects are not handled as expected. Reviewed-by: jlaskey, lagergren, hannesw ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/internal/runtime/ScriptEnvironment.java ! src/jdk/nashorn/internal/runtime/resources/Options.properties ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java ! test/src/jdk/nashorn/internal/runtime/TrustedScriptEngineTest.java Changeset: d82ac93aa55c Author: sundar Date: 2013-08-23 16:10 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/d82ac93aa55c 8023631: engine.js init script should be loaded into every global instance created by engines Reviewed-by: attila, hannesw ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/resources/engine.js + test/src/jdk/nashorn/api/scripting/InvocableTest.java + test/src/jdk/nashorn/api/scripting/ScopeTest.java ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java + test/src/jdk/nashorn/api/scripting/ScriptObjectMirrorTest.java Changeset: 6b6a8fc714a9 Author: lagergren Date: 2013-08-23 12:43 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/6b6a8fc714a9 8023453: --log=attr did not unindent identNodes Reviewed-by: attila, jlaskey ! src/jdk/nashorn/internal/codegen/Attr.java Changeset: 4dcd5a22fdd3 Author: lagergren Date: 2013-08-23 12:44 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/4dcd5a22fdd3 Merge Changeset: f18f2ce1b2dc Author: attila Date: 2013-08-23 13:10 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/f18f2ce1b2dc 8023630: Implement Java.super() as the preferred way to call super methods Reviewed-by: jlaskey, lagergren, sundar ! src/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk/nashorn/internal/runtime/JSType.java ! src/jdk/nashorn/internal/runtime/linker/Bootstrap.java ! src/jdk/nashorn/internal/runtime/linker/BoundDynamicMethodLinker.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterClassLoader.java + src/jdk/nashorn/internal/runtime/linker/JavaSuperAdapter.java + src/jdk/nashorn/internal/runtime/linker/JavaSuperAdapterLinker.java + test/script/basic/JDK-8023630.js + test/script/basic/JDK-8023630.js.EXPECTED ! test/script/basic/NASHORN-397.js Changeset: 2ce55025a37d Author: sundar Date: 2013-08-23 16:44 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/2ce55025a37d Merge Changeset: a18f92a0a910 Author: lana Date: 2013-08-26 14:54 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/a18f92a0a910 Merge Changeset: badc919cd621 Author: lagergren Date: 2013-08-23 14:16 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/badc919cd621 8023550: -d option was broken for any dir but '.'. Fixed Java warnings. Reviewed-by: jlaskey, sundar ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ConstructorGenerator.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ScriptClassInstrumentor.java ! src/jdk/internal/dynalink/ChainedCallSite.java ! src/jdk/internal/dynalink/DefaultBootstrapper.java ! src/jdk/internal/dynalink/beans/AbstractJavaLinker.java ! src/jdk/internal/dynalink/beans/OverloadedDynamicMethod.java ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk/nashorn/internal/objects/NativeRegExp.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/DebuggerSupport.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/regexp/joni/ArrayCompiler.java ! src/jdk/nashorn/internal/runtime/regexp/joni/BitSet.java ! src/jdk/nashorn/internal/runtime/regexp/joni/ByteCodeMachine.java ! src/jdk/nashorn/internal/runtime/regexp/joni/CodeRangeBuffer.java ! src/jdk/nashorn/internal/runtime/regexp/joni/Lexer.java ! src/jdk/nashorn/internal/runtime/regexp/joni/Parser.java ! src/jdk/nashorn/internal/runtime/regexp/joni/Region.java ! src/jdk/nashorn/internal/runtime/regexp/joni/ScannerSupport.java ! src/jdk/nashorn/internal/runtime/regexp/joni/SearchAlgorithm.java ! src/jdk/nashorn/internal/runtime/regexp/joni/StackMachine.java ! src/jdk/nashorn/internal/runtime/regexp/joni/WarnCallback.java ! src/jdk/nashorn/internal/runtime/regexp/joni/ast/EncloseNode.java ! src/jdk/nashorn/internal/runtime/regexp/joni/ast/Node.java ! src/jdk/nashorn/internal/runtime/regexp/joni/ast/QuantifierNode.java ! src/jdk/nashorn/internal/runtime/regexp/joni/exception/ErrorMessages.java ! tools/fxshell/jdk/nashorn/tools/FXShell.java Changeset: e2d94d032760 Author: jlaskey Date: 2013-08-23 09:56 -0300 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/e2d94d032760 8020946: TokenType#toString returned null Reviewed-by: hannesw, lagergren Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/parser/TokenType.java Changeset: eb7b8340ce3a Author: lagergren Date: 2013-08-23 15:46 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/eb7b8340ce3a 8023454: Updated DEVELOPER_README and command line flags, ensuring that undocumented flags that aren't guaranteed to work (disabled by default) and that are work in progress show up with an EXPERIMENTAL tag. Reviewed-by: attila, jlaskey ! docs/DEVELOPER_README ! src/jdk/nashorn/internal/runtime/resources/Options.properties Changeset: 12820c8d0a5d Author: jlaskey Date: 2013-08-23 12:20 -0300 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/12820c8d0a5d 8019987: String trimRight and trimLeft could be defined Reviewed-by: sundar Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/objects/NativeString.java + test/script/basic/JDK-8019987.js Changeset: c19c66e661a9 Author: hannesw Date: 2013-08-26 15:59 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/c19c66e661a9 8023650: Regexp m flag does not recognize CRNL or CR Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/runtime/regexp/joni/ByteCodeMachine.java ! src/jdk/nashorn/internal/runtime/regexp/joni/Config.java ! src/jdk/nashorn/internal/runtime/regexp/joni/EncodingHelper.java ! src/jdk/nashorn/internal/runtime/regexp/joni/Lexer.java ! src/jdk/nashorn/internal/runtime/regexp/joni/Matcher.java ! src/jdk/nashorn/tools/Shell.java + test/script/basic/JDK-8023650.js Changeset: 99e48c76d11f Author: jlaskey Date: 2013-08-26 15:33 -0300 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/99e48c76d11f 8023721: Simplify eval in DebuggerSupport. Reviewed-by: sundar, lagergren, hannesw Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/runtime/DebuggerSupport.java Changeset: 3bd077423a08 Author: sundar Date: 2013-08-27 15:54 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/3bd077423a08 8022773: ScriptEngineTest.printManyTest fails Reviewed-by: lagergren, attila ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java Changeset: 47f0a4c4b729 Author: attila Date: 2013-08-27 13:17 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/47f0a4c4b729 8023780: Gracefully handle @CS methods while binding bean properties Reviewed-by: jlaskey, lagergren, sundar ! src/jdk/nashorn/internal/objects/NativeObject.java + test/script/basic/JDK-8023780.js + test/script/basic/JDK-8023780.js.EXPECTED Changeset: bda0e89f88ae Author: sundar Date: 2013-08-27 18:57 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/bda0e89f88ae 8023784: Object.prototype.toString should contain the class name for all instances Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! src/jdk/nashorn/internal/objects/NativeArrayBuffer.java ! src/jdk/nashorn/internal/objects/NativeFloat32Array.java ! src/jdk/nashorn/internal/objects/NativeFloat64Array.java ! src/jdk/nashorn/internal/objects/NativeInt16Array.java ! src/jdk/nashorn/internal/objects/NativeInt32Array.java ! src/jdk/nashorn/internal/objects/NativeInt8Array.java ! src/jdk/nashorn/internal/objects/NativeUint16Array.java ! src/jdk/nashorn/internal/objects/NativeUint32Array.java ! src/jdk/nashorn/internal/objects/NativeUint8Array.java ! src/jdk/nashorn/internal/objects/NativeUint8ClampedArray.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java + test/script/basic/JDK-8023784.js + test/script/basic/JDK-8023784.js.EXPECTED ! test/script/basic/NASHORN-377.js.EXPECTED Changeset: 101606d3eb84 Author: sundar Date: 2013-08-27 19:26 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/101606d3eb84 Merge Changeset: bf70cbd2c836 Author: lana Date: 2013-08-29 16:34 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/bf70cbd2c836 Merge Changeset: f35e1255024b Author: cl Date: 2013-09-05 02:46 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/f35e1255024b Added tag jdk8-b106 for changeset bf70cbd2c836 ! .hgtags From alan.bateman at oracle.com Sat Sep 7 03:38:26 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sat, 07 Sep 2013 10:38:26 +0000 Subject: hg: jigsaw/jake/hotspot: 36 new changesets Message-ID: <20130907103949.A3C556264F@hg.openjdk.java.net> Changeset: b649cfa58604 Author: cl Date: 2013-08-29 09:41 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b649cfa58604 Added tag jdk8-b105 for changeset acac3bde66b2 ! .hgtags Changeset: 73921c720b94 Author: amurillo Date: 2013-08-23 03:14 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/73921c720b94 8023635: new hotspot build - hs25-b48 Reviewed-by: jcoomes ! make/hotspot_version Changeset: c6ec0a97b30a Author: sla Date: 2013-08-21 13:18 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c6ec0a97b30a 8022808: Kitchensink hangs on macos Summary: Use pthread_mach_thread_np() instead of mach_thread_self() to avoid leaking resources Reviewed-by: dholmes, rbackman ! src/os/bsd/vm/os_bsd.cpp Changeset: 3a57fa7a4cd0 Author: hseigel Date: 2013-08-22 11:52 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/3a57fa7a4cd0 7121403: [TESTBUG] runtime/7051189/Xchecksig.sh fails on 64bit solaris 8023393: Need to suppress info message if -Xcheck:jni used with libjsig.dylab on Mac OSX Summary: Rewrite 7051189 test in Java, port Linux fix for 7051189 to Mac OSX. Reviewed-by: coleenp, dholmes, mseledtsov, ccheung ! src/os/bsd/vm/os_bsd.cpp - test/runtime/7051189/Xchecksig.sh + test/runtime/XCheckJniJsig/XCheckJSig.java Changeset: e37ab280bbce Author: allwin Date: 2013-07-23 14:32 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e37ab280bbce 8011888: sa.js: TypeError: [object JSAdapter] has no such function "__has__" Reviewed-by: sla, sundar, kmo Contributed-by: yunda.mly at taobao.com ! agent/src/share/classes/sun/jvm/hotspot/utilities/soql/sa.js Changeset: 669d9a235486 Author: sla Date: 2013-08-22 14:56 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/669d9a235486 Merge Changeset: c062a6e1fa33 Author: iklam Date: 2013-08-22 10:20 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c062a6e1fa33 8023406: make/windows/build_vm_def.sh takes too long even when BUILD_WIN_SA != 1 Summary: Avoid dumping C++ vtable when BUILD_WIN_SA != 1 Reviewed-by: dcubed, sla, tbell ! make/windows/build_vm_def.sh ! make/windows/makefiles/debug.make ! make/windows/makefiles/fastdebug.make ! make/windows/makefiles/product.make ! make/windows/makefiles/projectcreator.make ! make/windows/makefiles/vm.make Changeset: 811aea34d5e7 Author: iklam Date: 2013-08-22 13:53 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/811aea34d5e7 Merge Changeset: ff2520b97b00 Author: jiangli Date: 2013-08-22 19:27 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/ff2520b97b00 8023547: com/sun/jdi/RedefineMulti.sh fails with IllegalArgumentException after JDK-8021948 . Summary: Need to check if the constant pool mapping returns 0. Reviewed-by: coleenp, sspitsyn ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: 887db75613f8 Author: jiangli Date: 2013-08-22 17:21 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/887db75613f8 Merge Changeset: a70566600baf Author: poonam Date: 2013-08-21 22:12 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a70566600baf 8020530: Non heap memory size calculated incorrectly Reviewed-by: coleenp, sla Contributed-by: vladimir.kempik at oracle.com ! src/share/vm/services/management.cpp Changeset: 730210728146 Author: poonam Date: 2013-08-22 18:09 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/730210728146 Merge - test/runtime/7051189/Xchecksig.sh Changeset: 817e46dd5864 Author: poonam Date: 2013-08-22 21:23 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/817e46dd5864 Merge Changeset: 739c309fd729 Author: mgronlun Date: 2013-08-23 10:36 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/739c309fd729 8023457: Event based tracing framework needs a mutex for thread groups Reviewed-by: acorn, sla ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp Changeset: cacc421f39d7 Author: dcubed Date: 2013-08-23 10:39 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/cacc421f39d7 Merge - test/runtime/7051189/Xchecksig.sh Changeset: badf4244ceae Author: hseigel Date: 2013-08-25 21:21 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/badf4244ceae 8022183: GCC 4.6 change sdefault setting for omit-frame-pointer which breaks hotspot stack walking Summary: Explicitly specify -fno-omit-frame-pointer. Reviewed-by: coleenp, dholmes, dcubed ! make/linux/makefiles/amd64.make ! make/linux/makefiles/gcc.make Changeset: faf2631b9334 Author: dsimms Date: 2013-08-26 09:33 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/faf2631b9334 8022683: JNI GetStringUTFChars should return NULL on allocation failure not abort the VM Summary: Return NULL on OOM from GetStringChars, GetStringUTFChars and GetArrayElements family of functions. Reviewed-by: dholmes, coleenp ! src/share/vm/memory/allocation.hpp ! src/share/vm/prims/jni.cpp Changeset: 4c84d351cca9 Author: stefank Date: 2013-08-16 13:22 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/4c84d351cca9 8007074: SIGSEGV at ParMarkBitMap::verify_clear() Summary: Replace the broken large pages implementation on Linux. New flag: -XX:+UseTransparentHugePages - Linux specific flag to turn on transparent huge page hinting with madvise(..., MAP_HUGETLB). Changed behavior: -XX:+UseLargePages - tries to use -XX:+UseTransparentHugePages before trying other large pages implementations (on Linux). Changed behavior: -XX:+UseHugeTLBFS - Use upfront allocation of Large Pages instead of using the broken implementation to dynamically committing large pages. Changed behavior: -XX:LargePageSizeInBytes - Turned off the ability to use this flag on Linux and provides warning to user if set to a value different than the OS chosen large page size. Changed behavior: Setting no large page size - Now defaults to use -XX:UseTransparentHugePages if the OS supports it. Previously, -XX:+UseHugeTLBFS was chosen if the OS was configured to use large pages. Reviewed-by: tschatzl, dcubed, brutisso ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/globals_linux.hpp ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/virtualspace.cpp ! src/share/vm/runtime/virtualspace.hpp ! src/share/vm/services/memTracker.hpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 21ffbaa691b5 Author: stefank Date: 2013-08-26 07:01 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/21ffbaa691b5 Merge ! src/share/vm/prims/jni.cpp Changeset: 1bb10d3170fa Author: jmasa Date: 2013-08-16 06:12 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/1bb10d3170fa 8022817: CMS should not shrink if compaction was not done Reviewed-by: ysr, mgerdin ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp Changeset: f7d3b4387a16 Author: brutisso Date: 2013-08-21 22:35 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f7d3b4387a16 8022872: G1: Use correct GC cause for young GC triggered by humongous allocations Reviewed-by: tonyp, tschatzl ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/vm_operations_g1.cpp Changeset: c31eb8c86a50 Author: brutisso Date: 2013-08-22 04:14 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c31eb8c86a50 Merge Changeset: ec145d04eda8 Author: jmasa Date: 2013-08-23 15:59 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/ec145d04eda8 Merge Changeset: 1624a68007bd Author: jmasa Date: 2013-08-27 18:55 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/1624a68007bd Merge ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: f92b82d454fa Author: bpittore Date: 2013-08-23 20:33 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f92b82d454fa 8014135: The JVMTI specification does not conform to recent changes in JNI specification Summary: Added support for statically linked agents Reviewed-by: sspitsyn, bobv, coleenp ! src/os/posix/vm/os_posix.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/prims/jvmti.xml ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/thread.cpp Changeset: 5fd8e2fbafd4 Author: cjplummer Date: 2013-08-23 12:36 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5fd8e2fbafd4 8020829: JT_HS: 2 runtime NMT tests fail on platforms if NMT detail is not supported Summary: Make tests query a new WhiteBox API to see if NMT detail is supported, and behave properly if it is not supported. Reviewed-by: dholmes, coleenp ! src/share/vm/prims/whitebox.cpp ! test/runtime/NMT/ThreadedVirtualAllocTestType.java ! test/runtime/NMT/VirtualAllocTestType.java ! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java Changeset: 7aa0c1fb6fdb Author: dholmes Date: 2013-08-27 22:05 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/7aa0c1fb6fdb 8006164: [TESTBUG] compact profile hotspot test issues Summary: Define profile-based test groups. Reviewed-by: dcubed, mchung ! test/TEST.ROOT + test/TEST.groups Changeset: 1fedf3c7f923 Author: bpittore Date: 2013-08-28 14:44 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/1fedf3c7f923 8023580: Add jtreg test for 8004051 and 8005722 Summary: Tests checks an assertion dealing with the number of args passed in registers Reviewed-by: mseledtsov, kvn + test/compiler/8004051/Test8004051.java Changeset: b1fb293d92c4 Author: jiangli Date: 2013-08-28 12:01 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b1fb293d92c4 Merge Changeset: 2b113b65a051 Author: dholmes Date: 2013-08-28 19:25 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/2b113b65a051 8023900: [TESTBUG] Initial compact profile test groups need adjusting Reviewed-by: dcubed, mchung, hseigel ! test/TEST.groups Changeset: 54dfd798deaf Author: dholmes Date: 2013-08-28 21:42 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/54dfd798deaf Merge Changeset: 62f527c674d2 Author: dholmes Date: 2013-08-29 00:22 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/62f527c674d2 Merge ! src/os/windows/vm/os_windows.cpp ! src/share/vm/runtime/os.hpp Changeset: 18b4798adbc4 Author: amurillo Date: 2013-08-30 00:19 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/18b4798adbc4 Merge - test/runtime/7051189/Xchecksig.sh Changeset: aed585cafc0d Author: amurillo Date: 2013-08-30 00:19 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/aed585cafc0d Added tag hs25-b48 for changeset 18b4798adbc4 ! .hgtags Changeset: 3f4392035ec7 Author: cl Date: 2013-09-05 02:45 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/3f4392035ec7 Added tag jdk8-b106 for changeset aed585cafc0d ! .hgtags Changeset: 7444c00afcfe Author: alanb Date: 2013-09-07 08:30 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/7444c00afcfe Merge ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp - test/runtime/7051189/Xchecksig.sh From alan.bateman at oracle.com Sat Sep 7 03:46:07 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sat, 07 Sep 2013 10:46:07 +0000 Subject: hg: jigsaw/jake/jdk: Allow duplicate bugids so that specific patches can be imported Message-ID: <20130907104708.1390C62650@hg.openjdk.java.net> Changeset: a6ffcc1eebe5 Author: alanb Date: 2013-09-07 11:43 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a6ffcc1eebe5 Allow duplicate bugids so that specific patches can be imported ! .jcheck/conf From alan.bateman at oracle.com Sat Sep 7 03:36:22 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sat, 07 Sep 2013 10:36:22 +0000 Subject: hg: jigsaw/jake/corba: 2 new changesets Message-ID: <20130907103625.62D786264C@hg.openjdk.java.net> Changeset: 2e3a056c84a7 Author: cl Date: 2013-08-29 09:41 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/2e3a056c84a7 Added tag jdk8-b105 for changeset 4e38de7c767e ! .hgtags Changeset: 23fc34133152 Author: cl Date: 2013-09-05 02:45 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/23fc34133152 Added tag jdk8-b106 for changeset 2e3a056c84a7 ! .hgtags From greggwon at cox.net Sat Sep 7 07:55:40 2013 From: greggwon at cox.net (Gregg Wonderly) Date: Sat, 7 Sep 2013 09:55:40 -0500 Subject: Jigsaw prototype, take 2 In-Reply-To: References: <20130828092751.449385@eggemoggin.niobe.net> <5220A2A5.9010700@cox.net> Message-ID: <8C20378D-7A0B-49A0-9D8F-30D84C2E76FD@cox.net> Tim, I appreciate a non-circular dependency graph. But, that should be my decision to want that, not something that tools demand. What happens typically, is that it forces you to actually make the wrong decision about how to create that graph and then requires extra work to build a non-circular view which eventually deteriorates into a huge mess because there are too many branches that attempt to introduce an interface to decouple the circular dependency for compiling, but you still have to create a circular dependency in class loading because that's how the beast fits together. The JVM is indeed a great example of how it's inseparable because of inter package dependencies. A dependency analysis tool can help you draw the picture, and I use one to create downloadable jars with minimal content to reduce download and disk storage overhead. Drawing the dependency graph to understand how separation works at interface boundaries is a fine idea. The reality is that there is never a non-circular dependency situation in mature software from a class loading perspective. Collections are the typical implementation that is everywhere. Well, things like logging are also everywhere. Just because logging uses collections to hold records of loggers, properties, handlers etc., and collections uses logging to allow insight into it's behaviors doesn't mean that they need to always be in the same package. Indeed, interfaces could allow them to be independent, yet, they are not because there are not interfaces that describe all the behaviors that each uses from the other. If we had interfaces everywhere, it would be nightmarish to keep up with all of the interface definitions and use those when there isn't any real ability to do that because of construction not being done with factories everywhere. But then you'd have dependencies on factory classes and it would still not work. So in the end, it's pointless to use the circular dependency concept as a problem statement. It's unsolvable! The right answer is to actually make tools which can deal with the concept of incomplete dependency graphs so that you can move on. The fact that Java doesn't deep resolve all class dependencies on the first class loaded is partially a solution to incomplete dependency graphs. It allows all kinds of flexibility it what can happen to resolve classes. There are so many other tooling issues that Java needs to address to be able to be fully exploited for the power that the class loading mechanisms really provide. Why isn't there a mechanism in the platform for the jar to define invisible dependencies (classes loaded with Class.forName(), or otherwise invisible dependencies)? Why isn't there a dependency tool set that builds minimal sized jar files? Why aren't nested jars possible so that I could just put everything I needed into one jar and use jar:jar:jar:? urls to load them? Why has the entire java industry prolifically dictated that their jars (by licensing) can not be pulled apart into just the needed components? What is most frustrating is that the monolithic assembly of Java-EE has caused people to focus on all of the wrong solutions to creating a Java "application". OSGi tries to solve the packaging problem by introducing so many bits and pieces of the system, replicated over and over in multiple places. It's supposed to make tooling be the mechanism for solving dependency problems, yet its not part of the development process in such a way that the dependency graph is always visible. That's what is actually needed. Dependencies should be a primary thing as part of the development process, and development time dependencies should not become the deployment time dependencies. Gregg Wonderly On Sep 6, 2013, at 10:22 PM, Tim Boudreau wrote: > Gregg, > > We've worked together and I respect your judgement. That said, I have to disagree pretty strongly with the idea of *not* enforcing that dependencies be a directed acyclic graph as the default. > > Fundamentally, if you are developing two things, and there is a circular dependency between them, you do not have *two* things - you have one thing which you enjoy pretending is two. If neither can exist without the other, their independence is in illusion. > > I agree that sometimes you need that sort of thing, dealing with legacy software and so forth. Not too long ago, I did some detangling of a project for a company that could only compile their software if they compiled against (and shipped) two historical versions of their own product, and not a soul there actually knew what got loaded and linked at runtime. Terrifying but true. > > But that being the default is the source of a *lot* of problems. And having to understand dependencies teaches understanding of dependencies, which affects how developers think about designing software. > > And explicit, non-cyclical dependencies make possible - trivial, even - very useful sorts of static analysis. > > I've developed a similar attitude toward Maven. Flexibility can be harmful, especially when there's no obvious right way to do things - it gives you enough rope to hang yourself. I've seen so many Make and Ant based projects where there was only one person in the organization who understood how their build system worked. Maven is inflexible in the extreme - there's a lot I really dislike about it. But it is utterly unambiguous. > > Managed dependencies are like that. You *want* inflexibility as a default. Sure, you also want the ability to write your own classloader (IMO, bytecode-over-the-wire is still one of the actually interesting things about Java) and do what you want - the occasions are rare, but when you need it, you need it. But even when you *do* need it, what are you loading those classes *from*? If it's non-trivial and you want it to work, you need...its dependencies! So I suspect even when you're doing wild-west classloading, there are still benefits to having this stuff be explicit and unambiguous. > > I understand that for a lot of people, this JSR is about making the JDK leaner and meaner. But I think there are opportunities here to do things that dramatically reduce the maintenance cost of new software written in Java, and it would be a pity not to seize the opportunity to kill two birds with one stone. > > -Tim From david.lloyd at redhat.com Sun Sep 8 09:32:44 2013 From: david.lloyd at redhat.com (David M. Lloyd) Date: Sun, 08 Sep 2013 11:32:44 -0500 Subject: Jigsaw prototype, take 2 In-Reply-To: References: <20130828092751.449385@eggemoggin.niobe.net> <5220A2A5.9010700@cox.net> Message-ID: <522CA6AC.5030900@redhat.com> On 09/06/2013 10:22 PM, Tim Boudreau wrote: > Gregg, > > We've worked together and I respect your judgement. That said, I have to > disagree pretty strongly with the idea of *not* enforcing that dependencies > be a directed acyclic graph as the default. > > Fundamentally, if you are developing two things, and there is a circular > dependency between them, you do not have *two* things - you have one thing > which you enjoy pretending is two. If neither can exist without the other, > their independence is in illusion. Our experiences with JBoss Modules has shown that there's a significant difference between cyclic dependencies at compile time and at run time. At run time, it is often convenient (for various reasons) to add an implementation to its corresponding API's import list. In fact whenever a class loader is used as a reference or start point for loading things (particularly via ServiceLoader and its kin), it is useful to be able to tie things together this way. This is only one (of many) reasons why build-time dependencies and run-time dependencies (and test-time dependencies) should be considered separate. > I agree that sometimes you need that sort of thing, dealing with legacy > software and so forth. Not too long ago, I did some detangling of a > project for a company that could only compile their software if they > compiled against (and shipped) two historical versions of their own > product, and not a soul there actually knew what got loaded and linked at > runtime. Terrifying but true. > > But that being the default is the source of a *lot* of problems. And > having to understand dependencies teaches understanding of dependencies, > which affects how developers think about designing software. > > And explicit, non-cyclical dependencies make possible - trivial, even - > very useful sorts of static analysis. Unfortunately run time dependencies are anything but static. A run-time module environment may include different implementations of things depending on who built the environment. Just to give one example, we provide an "org.apache.commons.logging" module at run-time, however it is actually an alias for "org.slf4j.jcl-over-slf4j". A different packager might make a different choice. But it is highly unlikely that a module which uses commons-logging built against anything other than the actual commons-logging JAR from Apache. > I've developed a similar attitude toward Maven. Flexibility can be > harmful, especially when there's no obvious right way to do things - it > gives you enough rope to hang yourself. I've seen so many Make and Ant > based projects where there was only one person in the organization who > understood how their build system worked. Maven is inflexible in the > extreme - there's a lot I really dislike about it. But it is utterly > unambiguous. Except for when it is not. On at least one - maybe more than one - occasion, Maven changed their dependency resolution algorithm such that transitive dependency resolution behavior could change subtly. > Managed dependencies are like that. You *want* inflexibility as a default. > Sure, you also want the ability to write your own classloader (IMO, > bytecode-over-the-wire is still one of the actually interesting things > about Java) and do what you want - the occasions are rare, but when you > need it, you need it. But even when you *do* need it, what are you loading > those classes *from*? If it's non-trivial and you want it to work, you > need...its dependencies! So I suspect even when you're doing wild-west > classloading, there are still benefits to having this stuff be explicit and > unambiguous. Again build time is not run time. > I understand that for a lot of people, this JSR is about making the JDK > leaner and meaner. But I think there are opportunities here to do things > that dramatically reduce the maintenance cost of new software written in > Java, and it would be a pity not to seize the opportunity to kill two birds > with one stone. > > -Tim > -- - DML From jaroslav.tulach at oracle.com Sun Sep 8 11:43:20 2013 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Sun, 08 Sep 2013 20:43:20 +0200 Subject: Runtime vs . compile time cyclic dep was: Jigsaw prototype, take 2 In-Reply-To: <522CA6AC.5030900@redhat.com> References: <20130828092751.449385@eggemoggin.niobe.net> <522CA6AC.5030900@redhat.com> Message-ID: <2193442.qUJqZCe6Wu@logouticek> Dne Ne 8. z??? 2013 11:32:44, David M. Lloyd napsal(a): > > Fundamentally, if you are developing two things, and there is a circular > > dependency between them, you do not have *two* things - you have one thing > > which you enjoy pretending is two. If neither can exist without the > > other, > > their independence is in illusion. > > Our experiences with JBoss Modules has shown that there's a significant > difference between cyclic dependencies at compile time and at run time. > At run time, it is often convenient (for various reasons) to add an > implementation to its corresponding API's import list. In fact whenever > a class loader is used as a reference or start point for loading things > (particularly via ServiceLoader and its kin), it is useful to be able to > tie things together this way. Hello David, just to make sure I understand. There is no cyclic depenedency during compile time, yet there may be a cyclic dependency during runtime. That must mean one of the modules is using Class.forName(...) and you want it to succeed, right? Such kind of runtime cyclic dependency is certainly OK. We use it in NetBeans (via ServiceLoader-like approach) and Jigsaw was supposed to support it via "require service" as well. -jt PS: Using Class.forName(...) to have a runtime cyclic dependency is possible in NetBeans as well, but we try to avoid it as it involves mangling with classloaders (in our case), which is a bit too low-level... From alan.bateman at oracle.com Tue Sep 10 00:57:50 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 10 Sep 2013 07:57:50 +0000 Subject: hg: jigsaw/jake/jdk: 54 new changesets Message-ID: <20130910081056.A84E4626B2@hg.openjdk.java.net> Changeset: 0417358184a1 Author: omajid Date: 2013-08-22 16:00 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0417358184a1 8023480: Create a jvm.cfg for zero on 32 bit architectures Reviewed-by: dholmes, erikj ! makefiles/CopyFiles.gmk Changeset: 1fe211ae3d2b Author: katleman Date: 2013-08-26 17:36 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1fe211ae3d2b Merge Changeset: 1a2a8d143583 Author: cl Date: 2013-08-29 09:42 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1a2a8d143583 Added tag jdk8-b105 for changeset 1fe211ae3d2b ! .hgtags Changeset: eb18a483e772 Author: alanb Date: 2013-08-21 09:59 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/eb18a483e772 8023351: Add TEST.groups in preparation to simplify rules in jdk/test/Makefile Reviewed-by: lancea, mduigou ! test/TEST.ROOT + test/TEST.groups Changeset: 68be998c2596 Author: egahlin Date: 2013-08-19 12:57 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/68be998c2596 6358357: Division by zero in Threads tab when shrinking jconsole window Reviewed-by: mchung, leifs, jbachorik ! src/share/classes/sun/tools/jconsole/Plotter.java Changeset: bddf55211ed8 Author: egahlin Date: 2013-08-19 16:21 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/bddf55211ed8 6417721: Thread list should not allow multiple selection Reviewed-by: alanb, jbachorik, sjiang ! src/share/classes/sun/tools/jconsole/ThreadTab.java Changeset: 2636d337a1ed Author: egahlin Date: 2013-08-19 16:41 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2636d337a1ed 6800801: NPE in JConsole when using Nimbus L&F Reviewed-by: alanb, sjiang ! src/share/classes/sun/tools/jconsole/ConnectDialog.java ! src/share/classes/sun/tools/jconsole/VMPanel.java Changeset: ba943fc47fc8 Author: egahlin Date: 2013-08-19 13:11 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ba943fc47fc8 7042707: Un-needed mnemonic in JConsole resource file Reviewed-by: mfang, jbachorik ! src/share/classes/sun/tools/jconsole/Messages.java ! src/share/classes/sun/tools/jconsole/resources/messages.properties ! src/share/classes/sun/tools/jconsole/resources/messages_ja.properties ! src/share/classes/sun/tools/jconsole/resources/messages_zh_CN.properties Changeset: 3b8fed46b2a8 Author: dholmes Date: 2013-08-21 05:56 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3b8fed46b2a8 8023460: OPENJDK build fails due to missing jfr.jar Reviewed-by: alanb ! makefiles/Profiles.gmk Changeset: 8996f47f738d Author: sla Date: 2013-08-21 17:19 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8996f47f738d 8023485: Remove com/sun/jdi/DoubleAgentTest.java and com/sun/jdi/FieldWatchpoints.java from ProblemList.txt Reviewed-by: chegar, mgronlun ! test/ProblemList.txt Changeset: fad3b6673159 Author: mduigou Date: 2013-08-21 12:03 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fad3b6673159 8023306: Add replace() implementations to TreeMap Reviewed-by: psandoz, alanb, chegar, bpb ! src/share/classes/java/util/TreeMap.java Changeset: 91a31c77be5b Author: mduigou Date: 2013-08-21 12:03 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/91a31c77be5b 8023395: Remove sun.misc.Sort and sun.misc.Compare Reviewed-by: alanb, smarks, darcy, mr - src/share/classes/sun/misc/Compare.java - src/share/classes/sun/misc/Sort.java Changeset: 60891d90327f Author: henryjen Date: 2013-08-20 14:23 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/60891d90327f 8016846: Pattern.splitAsStream tests required Reviewed-by: alanb, psandoz Contributed-by: Ben Evans + test/java/util/regex/PatternTest.java Changeset: ec827a62070a Author: xuelei Date: 2013-08-21 19:44 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ec827a62070a 8022228: Intermittent test failures in sun/security/ssl/javax/net/ssl/NewAPIs Reviewed-by: weijun ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SessionCacheSizeTests.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SessionTimeOutTests.java ! test/sun/security/ssl/templates/SSLSocketTemplate.java Changeset: a0896634ab46 Author: sla Date: 2013-08-22 08:28 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a0896634ab46 8023101: java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java fails Reviewed-by: ysr ! test/java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java Changeset: b7c4094be729 Author: darcy Date: 2013-08-22 09:40 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b7c4094be729 8023587: Fix lone remaining doclint issue in java.util.regex Reviewed-by: jjg ! src/share/classes/java/util/regex/Pattern.java Changeset: 8a7d9cc2f41c Author: dxu Date: 2013-08-22 11:43 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8a7d9cc2f41c 8023430: Replace File.mkdirs with Files.createDirectories to get MaxPathLength.java failure details Reviewed-by: alanb ! test/ProblemList.txt ! test/java/io/File/MaxPathLength.java Changeset: 2281a7f79738 Author: plevart Date: 2013-08-20 14:13 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2281a7f79738 8022721: AnnotationTypeDeadlockTest.java throws java.lang.IllegalStateException: unexpected condition Reviewed-by: alanb, jfranck ! test/java/lang/annotation/AnnotationType/AnnotationTypeDeadlockTest.java Changeset: 7496ec8bab76 Author: smarks Date: 2013-08-22 15:54 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7496ec8bab76 8022445: fix RMISocketFactory example to avoid using localhost Reviewed-by: chegar, alanb ! src/share/classes/java/rmi/server/RMISocketFactory.java Changeset: 7b6211cd8d76 Author: egahlin Date: 2013-08-21 17:15 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7b6211cd8d76 6417649: -interval=0 is accepted and jconsole doesn't update window content at all Reviewed-by: alanb, jbachorik ! src/share/classes/sun/tools/jconsole/JConsole.java Changeset: 77a32e5df365 Author: egahlin Date: 2013-08-21 17:17 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/77a32e5df365 6359971: Threads tab: Simple text to explain that one can click on a thread to get stack trace Reviewed-by: alanb, jbachorik ! src/share/classes/sun/tools/jconsole/Messages.java ! src/share/classes/sun/tools/jconsole/ThreadTab.java ! src/share/classes/sun/tools/jconsole/resources/messages.properties Changeset: 223be1d3494f Author: bpb Date: 2013-08-22 13:32 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/223be1d3494f 6470700: Math.random() / Math.initRNG() uses "double checked locking" Summary: Replace class Random variable with a static final holder class Reviewed-by: alanb, mduigou, chegar Contributed-by: Brian Burkhalter ! src/share/classes/java/lang/Math.java ! src/share/classes/java/lang/StrictMath.java Changeset: 4ef82445ea20 Author: dfuchs Date: 2013-08-23 20:59 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4ef82445ea20 8005899: Logger.getLogger(name, null) should not allow to reset a non-null resource bundle Reviewed-by: mchung, lancea ! src/share/classes/java/util/logging/Logger.java + test/java/util/logging/Logger/getLogger/TestLogger.java + test/java/util/logging/Logger/getLogger/testlogger/MyResource.java Changeset: 216a4b93cee8 Author: bpb Date: 2013-08-23 14:15 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/216a4b93cee8 6378503: In java.math.BigDecimal, division by one returns zero 6446965: Using BigDecimal.divideToIntegralValue with extreme scales can lead to an incorrect result Summary: Fix overflow of ints and ensure appropriate values passed to checkScaleNonZero() Reviewed-by: darcy, martin Contributed-by: Brian Burkhalter ! src/share/classes/java/math/BigDecimal.java ! src/share/classes/java/math/BigInteger.java ! test/java/math/BigDecimal/IntegralDivisionTests.java Changeset: 0ee3b995d63b Author: alanb Date: 2013-08-26 10:01 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0ee3b995d63b 8023139: java/nio/file/WatchService/SensitivityModifier.java failing intermittently (win8) Reviewed-by: alanb Contributed-by: yiming.wang at oracle.com ! test/java/nio/file/WatchService/SensitivityModifier.java Changeset: 67a1a031876a Author: igerasim Date: 2013-08-25 23:20 +0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/67a1a031876a 7129312: BufferedInputStream calculates negative array size with large streams and mark Reviewed-by: alanb ! src/share/classes/java/io/BufferedInputStream.java + test/java/io/BufferedInputStream/LargeCopyWithMark.java Changeset: 6917c114b197 Author: jfranck Date: 2013-08-26 13:38 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6917c114b197 8022343: j.l.Class.getAnnotatedSuperclass() doesn't return null in some cases Reviewed-by: darcy, vromero, psandoz ! src/share/classes/java/lang/Class.java ! test/java/lang/annotation/TypeAnnotationReflection.java + test/java/lang/annotation/typeAnnotations/GetAnnotatedSuperclass.java Changeset: 8a36fc7f494c Author: shade Date: 2013-08-26 17:50 +0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8a36fc7f494c 8023234: StampedLock serializes readers on writer unlock Summary: Sync-up the fix from jsr166 CVS, signal more readers on writer unlock Reviewed-by: martin, shade Contributed-by: Doug Lea
! src/share/classes/java/util/concurrent/locks/StampedLock.java + test/java/util/concurrent/locks/StampedLock/ReadersUnlockAfterWriteUnlock.java Changeset: 07585a2483fa Author: rriggs Date: 2013-08-26 11:46 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/07585a2483fa 8011944: Sort fails with ArrayIndexOutOfBoundsException Summary: Increase the size of pending stack and add test cases Reviewed-by: alanb ! src/share/classes/java/util/ComparableTimSort.java ! src/share/classes/java/util/TimSort.java + test/java/util/Arrays/TimSortStackSize.java Changeset: 92a66af7f834 Author: igerasim Date: 2013-08-26 18:26 +0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/92a66af7f834 8016018: Typo in AbstractStringBuilder#indexOf and #lastIndexOf descriptions Reviewed-by: alanb, chegar ! src/share/classes/java/lang/AbstractStringBuilder.java Changeset: 5ce9025c9e1a Author: psandoz Date: 2013-08-26 22:55 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5ce9025c9e1a 8020292: j.u.SplittableRandom Reviewed-by: mduigou Contributed-by: Guy Steele , Doug Lea
, Brian Goetz , Paul Sandoz + src/share/classes/java/util/SplittableRandom.java + test/java/util/SplittableRandom/SplittableRandomTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/SplittableRandomTest.java Changeset: 35c1609d9488 Author: henryjen Date: 2013-08-09 09:05 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/35c1609d9488 8023681: Fix raw type warning caused by Sink Reviewed-by: mduigou, briangoetz ! src/share/classes/java/util/stream/Collectors.java ! src/share/classes/java/util/stream/DistinctOps.java ! src/share/classes/java/util/stream/DoublePipeline.java ! src/share/classes/java/util/stream/IntPipeline.java ! src/share/classes/java/util/stream/LongPipeline.java ! src/share/classes/java/util/stream/ReferencePipeline.java ! src/share/classes/java/util/stream/Sink.java ! src/share/classes/java/util/stream/SliceOps.java ! src/share/classes/java/util/stream/SortedOps.java Changeset: 9586ca82bd8b Author: bpittore Date: 2013-08-26 11:27 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9586ca82bd8b 8014135: The JVMTI specification does not conform to recent changes in JNI specification Summary: Added support for statically linked agents Reviewed-by: alanb, sspitsyn, bobv, coleenp ! src/share/classes/com/sun/tools/attach/VirtualMachine.java Changeset: c58e39bb5d62 Author: lana Date: 2013-08-26 14:53 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c58e39bb5d62 Merge Changeset: 6cdc679e3412 Author: lana Date: 2013-08-26 22:18 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6cdc679e3412 Merge Changeset: ca53110f1c74 Author: weijun Date: 2013-08-27 17:50 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ca53110f1c74 8015669: KerberosPrincipal::equals should ignore name-type Reviewed-by: mullan ! src/share/classes/javax/security/auth/kerberos/KerberosPrincipal.java + test/sun/security/krb5/auto/KPEquals.java Changeset: 4bddc344848e Author: weijun Date: 2013-08-27 17:50 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4bddc344848e 8022761: regression: SecurityException is NOT thrown while trying to pack a wrongly signed Indexed Jar file Reviewed-by: sherman ! src/share/classes/java/util/jar/JarVerifier.java + test/sun/security/tools/jarsigner/jvindex.sh Changeset: 134283a88499 Author: mullan Date: 2013-08-27 10:46 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/134283a88499 8023769: JDK-8016850 broke the old build Summary: remove files that were moved/removed from com/sun/security/auth/FILES_java.gmk Reviewed-by: chegar, xuelei ! make/com/sun/security/auth/FILES_java.gmk Changeset: 6a1bfcde4d4d Author: mullan Date: 2013-08-27 12:04 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6a1bfcde4d4d 8019830: Add com.sun.media.sound to the list of restricted package Reviewed-by: vinnie ! src/share/lib/security/java.security-linux ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows ! test/java/lang/SecurityManager/CheckPackageAccess.java Changeset: 3575263eefab Author: mullan Date: 2013-08-27 12:27 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3575263eefab Merge - src/share/classes/com/sun/security/auth/PolicyParser.java - src/share/classes/com/sun/security/auth/SubjectCodeSource.java - src/share/classes/sun/misc/Compare.java - src/share/classes/sun/misc/Sort.java Changeset: 51151b440e95 Author: darcy Date: 2013-08-27 11:46 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/51151b440e95 8023827: Fix doclint issues in javax.net.ssl Reviewed-by: wetmore, xuelei ! src/share/classes/javax/net/ssl/SNIHostName.java ! src/share/classes/javax/net/ssl/X509KeyManager.java Changeset: ade440668f94 Author: henryjen Date: 2013-08-26 22:32 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ade440668f94 8023275: Wrapping collections should override default methods Reviewed-by: mduigou, psandoz ! src/share/classes/java/util/Collections.java + test/java/util/Collections/Wrappers.java Changeset: 3f6777cbfe69 Author: sherman Date: 2013-08-27 12:54 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3f6777cbfe69 8023647: "abc1c".matches("(\\w)+1\\1")) returns false Summary: to correct the wrong GroupCurly group index backoff code Reviewed-by: alanb ! src/share/classes/java/util/regex/Pattern.java ! test/java/util/regex/RegExTest.java Changeset: be2d25a277a7 Author: henryjen Date: 2013-08-21 20:41 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/be2d25a277a7 8023528: Rename Comparator combinators to disambiguate overloading methods Reviewed-by: mduigou, smarks ! src/share/classes/java/util/Comparator.java ! test/java/util/Comparator/BasicTest.java ! test/java/util/Map/EntryComparators.java ! test/java/util/function/BinaryOperator/BasicTest.java Changeset: 2efa310226f7 Author: alanb Date: 2013-08-28 14:07 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2efa310226f7 8023717: (process) ProcessBuilder should catch SecurityException rather than AccessControlException Reviewed-by: wetmore, alanb Contributed-by: martinrb at google.com ! src/share/classes/java/lang/ProcessBuilder.java Changeset: 378acd4d03c8 Author: alanb Date: 2013-08-28 15:50 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/378acd4d03c8 8022594: Potential deadlock in of sun.nio.ch.Util/IOUtil Reviewed-by: chegar ! src/macosx/classes/sun/nio/ch/KQueueArrayWrapper.java ! src/macosx/classes/sun/nio/ch/KQueueSelectorImpl.java ! src/share/classes/sun/nio/ch/AbstractPollSelectorImpl.java ! src/share/classes/sun/nio/ch/DatagramChannelImpl.java ! src/share/classes/sun/nio/ch/FileChannelImpl.java ! src/share/classes/sun/nio/ch/IOUtil.java ! src/share/classes/sun/nio/ch/Net.java ! src/share/classes/sun/nio/ch/ServerSocketChannelImpl.java ! src/share/classes/sun/nio/ch/SocketChannelImpl.java ! src/share/classes/sun/nio/ch/Util.java ! src/solaris/classes/sun/nio/ch/DatagramDispatcher.java ! src/solaris/classes/sun/nio/ch/DevPollArrayWrapper.java ! src/solaris/classes/sun/nio/ch/DevPollSelectorImpl.java ! src/solaris/classes/sun/nio/ch/EPoll.java ! src/solaris/classes/sun/nio/ch/EPollArrayWrapper.java ! src/solaris/classes/sun/nio/ch/EPollPort.java ! src/solaris/classes/sun/nio/ch/EPollSelectorImpl.java ! src/solaris/classes/sun/nio/ch/FileDispatcherImpl.java ! src/solaris/classes/sun/nio/ch/InheritedChannel.java ! src/solaris/classes/sun/nio/ch/KQueue.java ! src/solaris/classes/sun/nio/ch/KQueuePort.java ! src/solaris/classes/sun/nio/ch/NativeThread.java ! src/solaris/classes/sun/nio/ch/PollArrayWrapper.java ! src/solaris/classes/sun/nio/ch/SinkChannelImpl.java ! src/solaris/classes/sun/nio/ch/SolarisEventPort.java ! src/solaris/classes/sun/nio/ch/SourceChannelImpl.java ! src/solaris/classes/sun/nio/ch/UnixAsynchronousServerSocketChannelImpl.java ! src/solaris/classes/sun/nio/ch/UnixAsynchronousSocketChannelImpl.java ! src/solaris/classes/sun/nio/ch/sctp/SctpChannelImpl.java ! src/solaris/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java ! src/solaris/classes/sun/nio/ch/sctp/SctpServerChannelImpl.java ! src/windows/classes/sun/nio/ch/DatagramDispatcher.java ! src/windows/classes/sun/nio/ch/FileDispatcherImpl.java ! src/windows/classes/sun/nio/ch/FileKey.java ! src/windows/classes/sun/nio/ch/Iocp.java ! src/windows/classes/sun/nio/ch/PipeImpl.java ! src/windows/classes/sun/nio/ch/SocketDispatcher.java ! src/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java ! src/windows/classes/sun/nio/ch/WindowsAsynchronousServerSocketChannelImpl.java ! src/windows/classes/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.java ! src/windows/classes/sun/nio/ch/WindowsSelectorImpl.java Changeset: 690b2931baef Author: sherman Date: 2013-08-28 09:46 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/690b2931baef 8023713: ZipFileSystem crashes on old zip file Summary: to handle extra data field copy correctly even the extra data does not follow the spec Reviewed-by: alanb, martin, chegar ! src/share/classes/java/util/zip/ZipOutputStream.java ! test/java/util/zip/TestExtraTime.java Changeset: b1f41565b806 Author: psandoz Date: 2013-08-28 22:11 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b1f41565b806 8023155: Ensure functional consistency across Random, ThreadLocalRandom, SplittableRandom Reviewed-by: mduigou Contributed-by: Doug Lea
, Paul Sandoz ! src/share/classes/java/util/Random.java ! src/share/classes/java/util/concurrent/ThreadLocalRandom.java ! test/java/util/Random/RandomStreamTest.java + test/java/util/Random/RandomTest.java ! test/java/util/SplittableRandom/SplittableRandomTest.java + test/java/util/concurrent/ThreadLocalRandom/ThreadLocalRandomTest.java Changeset: 779ff9f3b2e3 Author: sla Date: 2013-08-29 11:22 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/779ff9f3b2e3 8023786: (jdk) setjmp/longjmp changes the process signal mask on OS X Reviewed-by: dholmes ! src/share/back/SDE.c ! src/share/native/common/check_code.c Changeset: 5bf4f2eeee85 Author: dxu Date: 2013-08-29 10:43 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5bf4f2eeee85 4792059: test/java/io/pathNames/GeneralSolaris.java fails on symbolic links Summary: Exclude the possible usage of linked files or directories in the test Reviewed-by: alanb ! test/java/io/pathNames/General.java Changeset: c817276bd870 Author: lana Date: 2013-08-29 16:26 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c817276bd870 Merge - src/share/classes/sun/misc/Compare.java - src/share/classes/sun/misc/Sort.java Changeset: aafc0f332658 Author: cl Date: 2013-09-05 02:46 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/aafc0f332658 Added tag jdk8-b106 for changeset c817276bd870 ! .hgtags Changeset: bcc9d9c9e066 Author: alanb Date: 2013-09-07 08:31 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/bcc9d9c9e066 Merge - src/share/classes/sun/misc/Compare.java - src/share/classes/sun/misc/Sort.java Changeset: d0c7841babf6 Author: alanb Date: 2013-09-07 11:45 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d0c7841babf6 Merge From alan.bateman at oracle.com Tue Sep 10 06:57:32 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 10 Sep 2013 13:57:32 +0000 Subject: hg: jigsaw/jake/hotspot: Add support to extend the access control after it has been set Message-ID: <20130910135739.42444626C0@hg.openjdk.java.net> Changeset: efa042a88227 Author: alanb Date: 2013-09-10 14:54 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/efa042a88227 Add support to extend the access control after it has been set ! make/bsd/makefiles/mapfile-vers-debug ! make/bsd/makefiles/mapfile-vers-product ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! make/solaris/makefiles/mapfile-vers ! src/share/vm/classfile/classLoaderExports.cpp ! src/share/vm/classfile/classLoaderExports.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h From alan.bateman at oracle.com Tue Sep 10 06:59:03 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 10 Sep 2013 13:59:03 +0000 Subject: hg: jigsaw/jake/jdk: Extend access to the bytecode implementation generated for reflection Message-ID: <20130910135951.13458626C1@hg.openjdk.java.net> Changeset: d48b939f6e74 Author: alanb Date: 2013-09-10 14:17 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d48b939f6e74 Extend access to the bytecode implementation generated for reflection ! makefiles/mapfiles/libjava/mapfile-vers ! src/share/classes/sun/launcher/LauncherHelper.java ! src/share/classes/sun/misc/VM.java ! src/share/classes/sun/reflect/MethodAccessorGenerator.java ! src/share/javavm/export/jvm.h ! src/share/native/sun/misc/VM.c From mandy.chung at oracle.com Tue Sep 10 11:27:47 2013 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 10 Sep 2013 18:27:47 +0000 Subject: hg: jigsaw/jake/jdk: Post-process step to create jmod files Message-ID: <20130910182817.D428B626D3@hg.openjdk.java.net> Changeset: e22ee404dbfe Author: mchung Date: 2013-09-10 11:26 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e22ee404dbfe Post-process step to create jmod files ! make/modules/modules.config ! make/modules/modules.group ! make/modules/tools/src/com/sun/tools/classanalyzer/ClassAnalyzer.java ! make/modules/tools/src/com/sun/tools/classanalyzer/ClassFileReader.java ! make/modules/tools/src/com/sun/tools/classanalyzer/ClassPath.java ! make/modules/tools/src/com/sun/tools/classanalyzer/Dependence.java ! make/modules/tools/src/com/sun/tools/classanalyzer/JigsawModules.java + make/modules/tools/src/com/sun/tools/classanalyzer/Modularizer.java ! make/modules/tools/src/com/sun/tools/classanalyzer/ModuleBuilder.java + make/modules/tools/src/com/sun/tools/classanalyzer/Task.java ! makefiles/BuildJdk.gmk ! makefiles/CompileNativeLibraries.gmk ! makefiles/CopyFiles.gmk ! makefiles/CreateJars.gmk + makefiles/CreateJmods.gmk ! makefiles/GenerateModules.gmk + makefiles/HotspotSetup.gmk ! makefiles/Images.gmk ! makefiles/Import.gmk + makefiles/Modules.gmk - makefiles/ModulesCommon.gmk + makefiles/PolicyJars.gmk From mandy.chung at oracle.com Tue Sep 10 11:27:48 2013 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 10 Sep 2013 18:27:48 +0000 Subject: hg: jigsaw/jake: Post-process step to create jmod files Message-ID: <20130910182749.55091626D2@hg.openjdk.java.net> Changeset: 80abe3cb308c Author: mchung Date: 2013-09-10 11:25 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/80abe3cb308c Post-process step to create jmod files ! common/makefiles/Main.gmk From alan.bateman at oracle.com Wed Sep 11 07:50:19 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 11 Sep 2013 14:50:19 +0000 Subject: hg: jigsaw/jake/jdk: Add launcher option to list modules Message-ID: <20130911145055.57B4D6270E@hg.openjdk.java.net> Changeset: ad4e5b56cbda Author: alanb Date: 2013-09-11 15:45 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ad4e5b56cbda Add launcher option to list modules ! src/share/bin/java.c ! src/share/classes/sun/launcher/LauncherHelper.java ! src/share/classes/sun/launcher/resources/launcher.properties From mandy.chung at oracle.com Wed Sep 11 12:34:06 2013 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 11 Sep 2013 19:34:06 +0000 Subject: hg: jigsaw/jake/jdk: Modifier.PUBLIC missing in the view dependence Message-ID: <20130911193440.B090362731@hg.openjdk.java.net> Changeset: 0c2e79967f5e Author: mchung Date: 2013-09-11 12:32 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0c2e79967f5e Modifier.PUBLIC missing in the view dependence ! make/modules/modules.properties ! make/modules/tools/src/com/sun/tools/classanalyzer/Dependence.java ! make/modules/tools/src/com/sun/tools/classanalyzer/ModuleBuilder.java ! test/jdk/jigsaw/module/JdkModules.java