From jaroslav.tulach at oracle.com Mon Jan 2 02:02:21 2012 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Mon, 2 Jan 2012 11:02:21 +0100 Subject: Minor incompatible changes was: Comments on the proof In-Reply-To: <4EFA00CC.4000904@oracle.com> References: <20111223202734.4467CF7F@eggemoggin.niobe.net> <201112251530.59525.jaroslav.tulach@oracle.com> <4EFA00CC.4000904@oracle.com> Message-ID: <201201021102.21459.jaroslav.tulach@oracle.com> Hello Jesse. First of all, I don't think incompatible changes should be treated as lightly as you indicate. But even if we follow your example, I don't think we are forced to do something unnatural... >## 27.?12.?2011 18:30:52 ##< > > I am glad avoiding NP-completeness is preferred. It increases my > > enthusiasm to seek for a dependency system that would be powerful enough > > and avoid it. > > An apparent precondition of your proof about complete repositories which > was not adequately emphasized is that a module must declare itself > incompatible if anything it reexports is incompatibly changed. True and correct, but the case below is wrong example. The module should only be marked as incompatible, if it really re-export the incompatibly changed class. > As I have > written before, this is not a restriction to be taken lightly! Consider > that java.beans.PropertyEditor.getCustomEditor() returns a > java.awt.Component, i.e. module java.beans @ 1.8 requires public module > java.awt @ [1.8,2), so anyone with a dep on java.beans [1.8,2) gets an > implicit dep on java.awt @ [1.8,2) as well. Now suppose that later it is > decided to finally just delete java.awt.List.delItems(int,int) which > probably no one calls anyway, and to be on the safe side java.awt is > bumped up to 2.0 accordingly. But now the next release of java.beans must > reexport java.awt @ [2.0,3), meaning by the postulated rule it must also > be marked 2.0. If you look at the definition of complete repository[1], you'll find out this is not necessary. You can release java.beans @ 1.8.3 which requires public module java.awt @ [2.0.3]. The repository will still remain complete and consistent. Of course, it would be beneficial if the system verified that none of the incompatibly changed classes are re-exported - e.g. that java.beans does not export something like "class BetterList extends java.awt.List". A tool like sigtest[2] integrated into jmod would be handy in such verification process. > > And that means that a module with a property editor based > on Swing, never using java.awt.List at all and otherwise happy with > java.awt @ [1.8,3), is forced to drop support for java.beans 1.x. > Indeed a > module using java.beans.Introspector for server configuration from > properties files and never using PropertyEditor or loading any AWT classes > whatsoever will also be forced to drop java.beans 1.x A server-side module(s) without any dependency on java.awt can have dependency on java.beans @ 1.8 and link without any problems with java.beans @ 1.8.3. So this is not an issue. On the other hand, should there be a module "sheet" which is compiled against java.beans @ 1.8 and java.awt @ 1.8.2 and another module "customizer" compiled against java.beans @ 1.8.3 (and thus implicitly against java.awt @ 2.0.3), then it is impossible to turn those modules on at once (if only one version of java.awt may be on). I don't think this is a problem[3] (as the situation seems like an error anyway) and the solution is simple: enough to produce new version of "sheet" recompiled with java.beans @ 1.8.3 > The situation would be more robust if reexports were dropped, modules were > required to explicitly specify all their direct dependencies The proposal for complete repository[1] in fact drops re-export and modifies compiler to explicitly specify all dependencies. Minor (e.g. unrelated) incompatible changes seem to be supported under this scheme. -jt [1] http://wiki.apidesign.org/index.php?title=LibraryWithoutImplicitExportIsPolynomial&useskin=monobook [2] http://sigtest.java.net/ [3] If it is, there is a solution at the cost of more complex dependency specification - still one needs to produce new version of "sheet" anyway. From Alan.Bateman at oracle.com Tue Jan 3 07:15:01 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 03 Jan 2012 15:15:01 +0000 Subject: Problems with JavacTool & -L In-Reply-To: <4EFAEB32.5000000@oracle.com> References: <4EFA6618.2010005@oracle.com> <4EFA80DD.9000602@oracle.com> <4EFAEB32.5000000@oracle.com> Message-ID: <4F031B75.3040706@oracle.com> On 28/12/2011 10:10, Jonathan Gibbons wrote: > : > >> : >> >> Jigsaw JDK is built using jigsaw langtools on top of JDK 7 as the >> boot JDK. So I expect it should work to run on top of JRE 7. How >> do you run it? > > This *may* be a side-effect of the above bug. Mandy is right in what > she says, but that applies to javac as used to build and rebuild JDK. Given that Jesse is trying to use the Jigsaw langtools with jdk7 then it might be worth explaining that this can only be used to the build the JDK. For NetBeans (and probably other IDEs) then I assume that it will require a plugin or some means to talk to a JDK8 server that use the module system. -Alan From jonathan.gibbons at oracle.com Tue Jan 3 07:28:06 2012 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 03 Jan 2012 07:28:06 -0800 Subject: Problems with JavacTool & -L In-Reply-To: <4F031B75.3040706@oracle.com> References: <4EFA6618.2010005@oracle.com> <4EFA80DD.9000602@oracle.com> <4EFAEB32.5000000@oracle.com> <4F031B75.3040706@oracle.com> Message-ID: <4F031E86.2020500@oracle.com> On 01/03/2012 07:15 AM, Alan Bateman wrote: > On 28/12/2011 10:10, Jonathan Gibbons wrote: >> : >> >>> : >>> >>> Jigsaw JDK is built using jigsaw langtools on top of JDK 7 as the >>> boot JDK. So I expect it should work to run on top of JRE 7. How >>> do you run it? >> >> This *may* be a side-effect of the above bug. Mandy is right in what >> she says, but that applies to javac as used to build and rebuild JDK. > Given that Jesse is trying to use the Jigsaw langtools with jdk7 then > it might be worth explaining that this can only be used to the build > the JDK. For NetBeans (and probably other IDEs) then I assume that it > will require a plugin or some means to talk to a JDK8 server that use > the module system. > > -Alan > > Yes, in normal usage, to resolve dependencies between modules, javac needs access to Jigsaw API. To compile Jigsaw JDK, javac and the build are set up to help javac past the bootstrapping phase before the Jigsaw API is available. -- Jon From jesse.glick at oracle.com Tue Jan 3 11:15:25 2012 From: jesse.glick at oracle.com (Jesse Glick) Date: Tue, 03 Jan 2012 14:15:25 -0500 Subject: Minor incompatible changes In-Reply-To: <201201021102.21459.jaroslav.tulach@oracle.com> References: <20111223202734.4467CF7F@eggemoggin.niobe.net> <201112251530.59525.jaroslav.tulach@oracle.com> <4EFA00CC.4000904@oracle.com> <201201021102.21459.jaroslav.tulach@oracle.com> Message-ID: <4F0353CD.7080301@oracle.com> On 01/02/2012 05:02 AM, Jaroslav Tulach wrote: > should there be a module "sheet" which is compiled against > java.beans @ 1.8 and java.awt @ 1.8.2 and another module "customizer" compiled > against java.beans @ 1.8.3 (and thus implicitly against java.awt @ 2.0.3), > then it is impossible to turn those modules on at once (if only one version of > java.awt may be on). I don't think this is a problem This does not seem like a problem to me either - the sheet module simply needs an update to work with newer versions of java.awt. But there seems to be a disconnect between the problem you are analyzing in your proofs and the actual problem here. Jigsaw does not in fact support loading multiple versions of a given module in an app, even if no linker inconsistency would arise as a consequence. That is why my demo program seems to be forcing the Jigsaw resolver to solve 3-SAT even though there is no reexport involved and so the repository is trivially "complete" in your terminology. In other words, valid org.openjdk.jigsaw.Configuration's are much more restricted than the "configurations" in your "Library Versioning Terminology". If f7 at 0 used v3 at 1 internally, i.e. as a utility and not making any mention of v3's types in its own signature, then it is nonetheless a problem for f7 at 1 or f7 at 2 to switch to v3 at 0, because the two versions of v3 cannot both be used at once. Of course the author of v3 could foresee this problem and provide different module names for incompatible releases (e.g. v3_0 at 0, v3_1 at 0, ...), but this puts the burden on the developer to work around a limitation of the module system, and it is ill suited to minor incompatible changes (i.e. those which would only affect a tiny minority of clients). The fix might be for the module system to permit parallel loading of older and newer versions of a single module. This would bring reality into line with your definition of a "configuration"; and making it "complete" should be easy for plain old Java code - there is no inherent problem with "requires public", i.e. implicit reexport, so long as the compiler inlines the transitive dependency when producing module-info.class. The problem would be a module which really cannot be multiply loaded - either because it is used indirectly (e.g. via ServiceLoader), or because it has externally visible state (e.g. AWT, or an HTTP server). You could introduce a "singleton" qualifier for such modules, forcing at most one version to be loaded in a given configuration, but this reintroduces the NP-completeness to the resolver. From jaroslav.tulach at oracle.com Wed Jan 4 01:13:50 2012 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Wed, 4 Jan 2012 10:13:50 +0100 Subject: No isolation was: Minor incompatible changes In-Reply-To: <4F0353CD.7080301@oracle.com> References: <20111223202734.4467CF7F@eggemoggin.niobe.net> <201201021102.21459.jaroslav.tulach@oracle.com> <4F0353CD.7080301@oracle.com> Message-ID: <201201041013.50736.jaroslav.tulach@oracle.com> >## 3.?1.?2012 20:15:25 ##< > But there seems to be a disconnect between the problem you are analyzing in > your proofs and the actual problem here. Jigsaw does not in fact support > loading multiple versions of a given module in an app, even if no linker > inconsistency would arise as a consequence. That is why my demo program > seems to be forcing the Jigsaw resolver to solve 3-SAT even though there > is no reexport involved and so the repository is trivially "complete" in > your terminology. Yes, there is a terminology disconnect. However the concept remains the same. There has been similar proofs (some of them referenced at [1]) and they don't deal with concept of re-export. My proof is unique as it does not need concept of "obsoletes/prevents" dependency which mimics negation in the 3SAT problem. I substituted that with requirement that every class name has to have a unique meaning in each class loader. If Jigsaw decides to support no isolation (e.g. enable just one version of module in the application), then the problem remains the same (as your demo program demonstrates). Basically it means that every usage of a module is counted as re-export (as it prevents any other module in the system to use different incompatible version of that module). Sort of like saying that every class name in the system should represent unique class. > The fix might be for the module system to permit parallel loading of older > and newer versions of a single module. This would bring reality into line > with your definition of a "configuration"; and making it "complete" should > be easy for plain old Java code - there is no inherent problem with > "requires public", i.e. implicit reexport, so long as the compiler inlines > the transitive dependency when producing module-info.class. Right, that sounds like my expectation. However even if Jigsaw sticks with single version of a module per application, having transitive dependencies of each module enumerated by compiler will pay off. > The problem > would be a module which really cannot be multiply loaded - either because > it is used indirectly (e.g. via ServiceLoader), or because it has > externally visible state (e.g. AWT, or an HTTP server). > You could > introduce a "singleton" qualifier for such modules, forcing at most one > version to be loaded in a given configuration, > but this reintroduces the > NP-completeness to the resolver. Singleton module maps to module which every other module with dependency on it "re-exports" (in terminology of [1]). I don't think this brings NP- completeness back. If all transitive dependencies are enumerated by compiler[2], it is polynomial problem to select a version of such module to use (or reject the configuration as inconsistent). -jt [1] http://wiki.apidesign.org/wiki/LibraryReExportIsNPComplete#External_Links [2] http://wiki.apidesign.org/wiki/LibraryWithoutImplicitExportIsPolynomial#Consistency From david.bosschaert at gmail.com Wed Jan 4 05:57:12 2012 From: david.bosschaert at gmail.com (David Bosschaert) Date: Wed, 4 Jan 2012 13:57:12 +0000 Subject: What is a language construct? (was Re: Comment on state of Project Jigsaw) In-Reply-To: <4EF3D3D0.50704@oracle.com> References: <20111221223027.33AD123A6@eggemoggin.niobe.net> <4EF26029.1050700@univ-mlv.fr> <4EF2679F.9050408@oracle.com> <4EF27623.2050501@oracle.com> <4EF2889C.5070707@oracle.com> <4EF3D3D0.50704@oracle.com> Message-ID: On 23 December 2011 01:05, Alex Buckley wrote: > Many presentations on Jigsaw have covered the need for modules to _look_ > familiar to Java programmers, leading to the open requirement: > > "Java-like syntax ? The syntax of module declarations must be similar to > that of declarations of a like nature in the Java programming language." I'd say these presentations represent only a limited section of the community. There have been many arguments made by a variety of people arguing for a DSL or other mechanism which is more suited for storing module declarations. This email trail is an example of that. Just to give one example where it doesn't fit: A module declaration applies to the artifact as a whole, i.e. the module jar file, so it doesn't fit naturally alongside other java classes in any java file - it needs to be in a special file of its own. And that special file will look different from all the other java files so hence it doesn't make sense to make it part of the java syntax as this syntax is only used in this special place, effectively creating a separate language, as Neal mentioned above. Making things worse, having it in a .java file implies that it will be compiled into a .class file which makes thing unnecessarily complex for tools and other module systems to read this thing at runtime. Additionally, having it in a .class file compromises the extensibility of the module metadata, which is needed for module systems that may have more features and need extensions to JSE module metadata. > From that open requirement flows a module declaration built from the > traditional input elements of the Java language, and included under > CompilationUnit in the Java grammar. Yes, the requirement is open, but it's > the current direction of the Jigsaw prototype. Its an open requirement clearly because opinions diverge over this issue. We need to stress that Jigsaw is a prototype and that this aspect of the prototype can't 'just make it' into JSE8 without proper discussion in the upcoming modularity JSR. Best regards, David From forax at univ-mlv.fr Wed Jan 4 06:46:40 2012 From: forax at univ-mlv.fr (=?windows-1252?Q?R=E9mi_Forax?=) Date: Wed, 04 Jan 2012 15:46:40 +0100 Subject: What is a language construct? (was Re: Comment on state of Project Jigsaw) In-Reply-To: References: <20111221223027.33AD123A6@eggemoggin.niobe.net> <4EF26029.1050700@univ-mlv.fr> <4EF2679F.9050408@oracle.com> <4EF27623.2050501@oracle.com> <4EF2889C.5070707@oracle.com> <4EF3D3D0.50704@oracle.com> Message-ID: <4F046650.3030103@univ-mlv.fr> The module descriptor is not the .java but the .class, the .java is a convenient way to specify the module descriptor. This allow to have a readable syntax for the user and a module descriptor that contains synthetized informations by example the module descriptor can contain a set of exported types, having a .java let users to use a * (wildcard) to specify the exported types. I expect all tools will use the jigsaw reflective API or ASM. R?mi On 01/04/2012 02:57 PM, David Bosschaert wrote: > On 23 December 2011 01:05, Alex Buckley wrote: >> Many presentations on Jigsaw have covered the need for modules to _look_ >> familiar to Java programmers, leading to the open requirement: >> >> "Java-like syntax ? The syntax of module declarations must be similar to >> that of declarations of a like nature in the Java programming language." > I'd say these presentations represent only a limited section of the community. > There have been many arguments made by a variety of people arguing for > a DSL or other mechanism which is more suited for storing module > declarations. This email trail is an example of that. > > Just to give one example where it doesn't fit: > A module declaration applies to the artifact as a whole, i.e. the > module jar file, so it doesn't fit naturally alongside other java > classes in any java file - it needs to be in a special file of its > own. And that special file will look different from all the other java > files so hence it doesn't make sense to make it part of the java > syntax as this syntax is only used in this special place, effectively > creating a separate language, as Neal mentioned above. > Making things worse, having it in a .java file implies that it will be > compiled into a .class file which makes thing unnecessarily complex > for tools and other module systems to read this thing at runtime. > Additionally, having it in a .class file compromises the extensibility > of the module metadata, which is needed for module systems that may > have more features and need extensions to JSE module metadata. > >> From that open requirement flows a module declaration built from the >> traditional input elements of the Java language, and included under >> CompilationUnit in the Java grammar. Yes, the requirement is open, but it's >> the current direction of the Jigsaw prototype. > Its an open requirement clearly because opinions diverge over this > issue. We need to stress that Jigsaw is a prototype and that this > aspect of the prototype can't 'just make it' into JSE8 without proper > discussion in the upcoming modularity JSR. > > Best regards, > > David From mcconnell at dpml.net Wed Jan 4 06:50:45 2012 From: mcconnell at dpml.net (Stephen McConnell) Date: Thu, 5 Jan 2012 01:20:45 +1030 Subject: What is a language construct? (was Re: Comment on state ofProject Jigsaw) In-Reply-To: References: <20111221223027.33AD123A6@eggemoggin.niobe.net><4EF26029.1050700@univ-mlv.fr> <4EF2679F.9050408@oracle.com><4EF27623.2050501@oracle.com><4EF2889C.5070707@oracle.com><4EF3D3D0.50704@oracle.com> Message-ID: <841BB6D0B6A04F81826932C631F76F18@GLORIA> Woops - sorry, need clarification. Are your suggesting that the language is frozen and cannot evolve? /SJM -----Original Message----- From: David Bosschaert Sent: Thursday, January 05, 2012 12:27 AM To: jigsaw-dev at openjdk.java.net Subject: Re: What is a language construct? (was Re: Comment on state ofProject Jigsaw) On 23 December 2011 01:05, Alex Buckley wrote: > Many presentations on Jigsaw have covered the need for modules to _look_ > familiar to Java programmers, leading to the open requirement: > > "Java-like syntax ? The syntax of module declarations must be similar to > that of declarations of a like nature in the Java programming language." I'd say these presentations represent only a limited section of the community. There have been many arguments made by a variety of people arguing for a DSL or other mechanism which is more suited for storing module declarations. This email trail is an example of that. Just to give one example where it doesn't fit: A module declaration applies to the artifact as a whole, i.e. the module jar file, so it doesn't fit naturally alongside other java classes in any java file - it needs to be in a special file of its own. And that special file will look different from all the other java files so hence it doesn't make sense to make it part of the java syntax as this syntax is only used in this special place, effectively creating a separate language, as Neal mentioned above. Making things worse, having it in a .java file implies that it will be compiled into a .class file which makes thing unnecessarily complex for tools and other module systems to read this thing at runtime. Additionally, having it in a .class file compromises the extensibility of the module metadata, which is needed for module systems that may have more features and need extensions to JSE module metadata. > From that open requirement flows a module declaration built from the > traditional input elements of the Java language, and included under > CompilationUnit in the Java grammar. Yes, the requirement is open, but > it's > the current direction of the Jigsaw prototype. Its an open requirement clearly because opinions diverge over this issue. We need to stress that Jigsaw is a prototype and that this aspect of the prototype can't 'just make it' into JSE8 without proper discussion in the upcoming modularity JSR. Best regards, David From david.bosschaert at gmail.com Wed Jan 4 07:17:27 2012 From: david.bosschaert at gmail.com (David Bosschaert) Date: Wed, 4 Jan 2012 15:17:27 +0000 Subject: What is a language construct? (was Re: Comment on state ofProject Jigsaw) In-Reply-To: <841BB6D0B6A04F81826932C631F76F18@GLORIA> References: <20111221223027.33AD123A6@eggemoggin.niobe.net> <4EF26029.1050700@univ-mlv.fr> <4EF2679F.9050408@oracle.com> <4EF27623.2050501@oracle.com> <4EF2889C.5070707@oracle.com> <4EF3D3D0.50704@oracle.com> <841BB6D0B6A04F81826932C631F76F18@GLORIA> Message-ID: Not at all! I'm a big fan of the many features that are being worked on for the language. However, I think that specifying the module metadata in a Java source file is the wrong choice and especially having it in a .class file at runtime seems highly limiting and only focused on one particular use-case. This type of information asks for a separate type of file with its own format: a little DSL or something like that. It should not be precompiled as a .class file for one particular use but rather stay in its original format inside the module. Java runtimes can, as a performance optimization, cache their own binary version of it if they wish, but that's really a hidden implementation detail... Best regards, David On 4 January 2012 14:50, Stephen McConnell wrote: > Woops - sorry, need clarification. > Are your suggesting that the language is frozen and cannot evolve? > /SJM > > -----Original Message----- From: David Bosschaert > Sent: Thursday, January 05, 2012 12:27 AM > To: jigsaw-dev at openjdk.java.net > Subject: Re: What is a language construct? (was Re: Comment on state > ofProject Jigsaw) > > > On 23 December 2011 01:05, Alex Buckley wrote: >> >> Many presentations on Jigsaw have covered the need for modules to _look_ >> familiar to Java programmers, leading to the open requirement: >> >> "Java-like syntax ? The syntax of module declarations must be similar to >> that of declarations of a like nature in the Java programming language." > > > I'd say these presentations represent only a limited section of the > community. > There have been many arguments made by a variety of people arguing for > a DSL or other mechanism which is more suited for storing module > declarations. This email trail is an example of that. > > Just to give one example where it doesn't fit: > A module declaration applies to the artifact as a whole, i.e. the > module jar file, so it doesn't fit naturally alongside other java > classes in any java file - it needs to be in a special file of its > own. And that special file will look different from all the other java > files so hence it doesn't make sense to make it part of the java > syntax as this syntax is only used in this special place, effectively > creating a separate language, as Neal mentioned above. > Making things worse, having it in a .java file implies that it will be > compiled into a .class file which makes thing unnecessarily complex > for tools and other module systems to read this thing at runtime. > Additionally, having it in a .class file compromises the extensibility > of the module metadata, which is needed for module systems that may > have more features and need extensions to JSE module metadata. > >> From that open requirement flows a module declaration built from the >> traditional input elements of the Java language, and included under >> CompilationUnit in the Java grammar. Yes, the requirement is open, but >> it's >> the current direction of the Jigsaw prototype. > > > Its an open requirement clearly because opinions diverge over this > issue. We need to stress that Jigsaw is a prototype and that this > aspect of the prototype can't 'just make it' into JSE8 without proper > discussion in the upcoming modularity JSR. > > Best regards, > > David From david.bosschaert at gmail.com Wed Jan 4 07:23:31 2012 From: david.bosschaert at gmail.com (David Bosschaert) Date: Wed, 4 Jan 2012 15:23:31 +0000 Subject: What is a language construct? (was Re: Comment on state of Project Jigsaw) In-Reply-To: <4F046650.3030103@univ-mlv.fr> References: <20111221223027.33AD123A6@eggemoggin.niobe.net> <4EF26029.1050700@univ-mlv.fr> <4EF2679F.9050408@oracle.com> <4EF27623.2050501@oracle.com> <4EF2889C.5070707@oracle.com> <4EF3D3D0.50704@oracle.com> <4F046650.3030103@univ-mlv.fr> Message-ID: On 4 January 2012 14:46, R?mi Forax wrote: > The module descriptor is not the .java but the .class, > the .java is a convenient way to specify the module descriptor. I have nothing against a convenient way of specifying a module description, I actually see that as a requirement :) but that requirement doesn't imply that it needs to be shoe-horned into .java and .class files! > This allow to have a readable syntax for the user and > a module descriptor that contains synthetized informations > by example the module descriptor can contain a set of exported types, > having a .java let users to use a * (wildcard) to specify the exported > types. I don't follow why you would only get this feature if you describe the module metadata in a .java file. You could just as easily define a textual file format that allows the specification of wildcards... > I expect all tools will use the jigsaw reflective API > or ASM. Well, ahem, requiring people to use ASM isn't really user-friendly IMHO... David From forax at univ-mlv.fr Wed Jan 4 08:02:15 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 04 Jan 2012 17:02:15 +0100 Subject: What is a language construct? (was Re: Comment on state of Project Jigsaw) In-Reply-To: References: <20111221223027.33AD123A6@eggemoggin.niobe.net> <4EF26029.1050700@univ-mlv.fr> <4EF2679F.9050408@oracle.com> <4EF27623.2050501@oracle.com> <4EF2889C.5070707@oracle.com> <4EF3D3D0.50704@oracle.com> <4F046650.3030103@univ-mlv.fr> Message-ID: <4F047807.7090507@univ-mlv.fr> On 01/04/2012 04:23 PM, David Bosschaert wrote: > On 4 January 2012 14:46, R?mi Forax wrote: >> The module descriptor is not the .java but the .class, >> the .java is a convenient way to specify the module descriptor. > I have nothing against a convenient way of specifying a module > description, I actually see that as a requirement :) but that > requirement doesn't imply that it needs to be shoe-horned into .java > and .class files! The .class format is already an extensible versioned container format with a dictionnary which is able to store string and class name. No shoehorn here. >> This allow to have a readable syntax for the user and >> a module descriptor that contains synthetized informations >> by example the module descriptor can contain a set of exported types, >> having a .java let users to use a * (wildcard) to specify the exported >> types. > I don't follow why you would only get this feature if you describe the > module metadata in a .java file. You could just as easily define a > textual file format that allows the specification of wildcards... > >> I expect all tools will use the jigsaw reflective API >> or ASM. > Well, ahem, requiring people to use ASM isn't really user-friendly IMHO... Don't ask me if ASM use user friendly :) http://asm.ow2.org/team.html > > David R?mi From jesse.glick at oracle.com Wed Jan 4 08:01:23 2012 From: jesse.glick at oracle.com (Jesse Glick) Date: Wed, 04 Jan 2012 11:01:23 -0500 Subject: No isolation was: Minor incompatible changes In-Reply-To: <201201041013.50736.jaroslav.tulach@oracle.com> References: <20111223202734.4467CF7F@eggemoggin.niobe.net> <201201021102.21459.jaroslav.tulach@oracle.com> <4F0353CD.7080301@oracle.com> <201201041013.50736.jaroslav.tulach@oracle.com> Message-ID: <4F0477D3.8040600@oracle.com> On 01/04/2012 04:13 AM, Jaroslav Tulach wrote: > If Jigsaw decides to support no isolation [...] it means that every usage of a module is > counted as re-export [...]. Sort of like saying that every > class name in the system should represent unique class. Exactly. And while I appreciate the sentiment of trying to solve the 90% use case by omitting support for more advanced scenarios - parallel loading of an older module version - that design decision seems to clash with the requirement of automatically resolving a valid configuration out of a multiversion repository. > Singleton module maps to module which every other module with dependency on it "re-exports" Yes, you can handle it this way and keep the resolver simple. I am still unsure what effect this will have on scenarios like my java.awt <- java.beans example, assuming java.awt is a singleton. (Again I am not _advocating_ an incompatible change in java.awt, but such minor API cleanups are common in the field and the system needs to be robust in the face of them.) Say singleton module java.awt @ 1.8 { // has java.awt.List.delItems(int,int) } singleton module java.awt @ 2.0 { // java.awt.List no longer has delItems(int,int) } module java.beans @ 1.8 { // java.awt.Component in public API, but optional, so: requires optional java.awt @ [1.8,2); } module java.beans @ 1.8.3 { // did not use delItems, so give a lax dep requires optional java.awt @ [1.8,3); } module webserver @ 1 { // does not use java.awt in any way requires java.beans @ [1.8,2); } module webserver @ 2 { // routine dep upgrade requires java.beans @ [1.8.3,2); } module sheet @ 1 { requires java.beans @ [1.8,2); // really uses java.beans.PropertyEditor.getCustomEditor() requires java.awt @ [1.8,2); } module sheet @ 2 { // routine dep upgrade requires java.beans @ [1.8.3,2); // did not use delItems requires java.awt @ [1.8,3); } module app @ 1 { // remote access requires webserver @ 1; // admin GUI requires sheet @ 2; } Clearly sheet at 2 should be fine, and sheet at 1 is out of luck. webserver at 2 should be fine; but what about app at 1? Will java.awt at 2.0 be used, or java.awt at 1.8, or will the system complain about a spurious conflict? From eric at tibco.com Wed Jan 4 12:49:50 2012 From: eric at tibco.com (Eric Johnson) Date: Wed, 4 Jan 2012 21:49:50 +0100 Subject: What is a language construct? (was Re: Comment on state of Project Jigsaw) In-Reply-To: <4F047807.7090507@univ-mlv.fr> References: <20111221223027.33AD123A6@eggemoggin.niobe.net> <4EF26029.1050700@univ-mlv.fr> <4EF2679F.9050408@oracle.com> <4EF27623.2050501@oracle.com> <4EF2889C.5070707@oracle.com> <4EF3D3D0.50704@oracle.com> <4F046650.3030103@univ-mlv.fr> <4F047807.7090507@univ-mlv.fr> Message-ID: <4F04BB6E.4040309@tibco.com> Comment below... On 1/4/12 5:02 PM, R?mi Forax wrote: > On 01/04/2012 04:23 PM, David Bosschaert wrote: >> On 4 January 2012 14:46, R?mi Forax wrote: >>> The module descriptor is not the .java but the .class, >>> the .java is a convenient way to specify the module descriptor. >> I have nothing against a convenient way of specifying a module >> description, I actually see that as a requirement :) but that >> requirement doesn't imply that it needs to be shoe-horned into .java >> and .class files! > > The .class format is already an extensible versioned container format > with a dictionnary which is able to store string and class name. > No shoehorn here. OK, perhaps the format is reusable, but how will existing tools fare with it? Will existing IDEs choke on the file unless modified because it has unexpected content? Will code obfuscation tools obfuscate it by default? Will Ant need to be updated to treat these files specially? Will any ASM client ever written fall over because the module definition file doesn't actually include byte codes? What about tools like "bnd" that introspect ".class" files looking for referenced symbols, so that they can generate OSGi information? I think the notion of reusing a format might work, but I suspect reusing the extension ".class" will cause a lot of churn in downstream tooling, and it doesn't sound like that's been considered here. (And I worry that I've written code that would succumb to that churn.) If you're arguing that it is a useful container format, though, there are plenty of other "container formats" - JSON and XML jump to mind - that can equally well satisfy the requirements that have been stated so far. Since modules must be "installed" (if I've understood what I've read correctly), then any notions of pre-compiling them are likely not essential, because the installation process can do what it wishes, and the files themselves have no "external" dependencies that need to be controlled in a compilation process (unlike, say, the existing Java classes that we compile.) -Eric. From peter.kriens at aqute.biz Thu Jan 5 05:23:55 2012 From: peter.kriens at aqute.biz (Peter Kriens) Date: Thu, 5 Jan 2012 14:23:55 +0100 Subject: What is a language construct? (was Re: Comment on state of Project Jigsaw) In-Reply-To: <4F047807.7090507@univ-mlv.fr> References: <20111221223027.33AD123A6@eggemoggin.niobe.net> <4EF26029.1050700@univ-mlv.fr> <4EF2679F.9050408@oracle.com> <4EF27623.2050501@oracle.com> <4EF2889C.5070707@oracle.com> <4EF3D3D0.50704@oracle.com> <4F046650.3030103@univ-mlv.fr> <4F047807.7090507@univ-mlv.fr> Message-ID: On 4 jan. 2012, at 17:02, R?mi Forax wrote: > The .class format is already an extensible versioned container format > with a dictionnary which is able to store string and class name. > No shoehorn here. Hmmmmm. To me this is the biggest shoehorn I've seen in a long, long time ... Would you ever, ever, use this format if it had not been there before? Is there any reason to use the class file except that it happens already be there? The worst thing is that you could view a class as a container of members, which on a higher level is also true for a module. However, the way the class format is used is ignoring this possibility and only (ab)uses the constant pool and the type's (!) attributes. Further: a) It is not easy readable for inspection c) You have to stopgap mandatory fields like super class, access, class name, etc. d) It will confuse the heck out of any existing class parsers e) It is not easy extendable for other module systems f) There is just no need to use the class file h) It unnecessarily complicates management systems This is an almost perfect example of Conways law pointed out by Gafter. Once you're familiar with a technology you frame solutions in that technology. Kind regards, Peter Kriens > >>> This allow to have a readable syntax for the user and >>> a module descriptor that contains synthetized informations >>> by example the module descriptor can contain a set of exported types, >>> having a .java let users to use a * (wildcard) to specify the exported >>> types. >> I don't follow why you would only get this feature if you describe the >> module metadata in a .java file. You could just as easily define a >> textual file format that allows the specification of wildcards... >> >>> I expect all tools will use the jigsaw reflective API >>> or ASM. >> Well, ahem, requiring people to use ASM isn't really user-friendly IMHO... > > Don't ask me if ASM use user friendly :) > http://asm.ow2.org/team.html > >> >> David > > R?mi > From forax at univ-mlv.fr Thu Jan 5 06:14:21 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Thu, 05 Jan 2012 15:14:21 +0100 Subject: What is a language construct? (was Re: Comment on state of Project Jigsaw) In-Reply-To: References: <20111221223027.33AD123A6@eggemoggin.niobe.net> <4EF26029.1050700@univ-mlv.fr> <4EF2679F.9050408@oracle.com> <4EF27623.2050501@oracle.com> <4EF2889C.5070707@oracle.com> <4EF3D3D0.50704@oracle.com> <4F046650.3030103@univ-mlv.fr> <4F047807.7090507@univ-mlv.fr> Message-ID: <4F05B03D.2090707@univ-mlv.fr> On 01/05/2012 02:23 PM, Peter Kriens wrote: > On 4 jan. 2012, at 17:02, R?mi Forax wrote: >> The .class format is already an extensible versioned container format >> with a dictionnary which is able to store string and class name. >> No shoehorn here. > Hmmmmm. To me this is the biggest shoehorn I've seen in a long, long time ... Would you ever, ever, use this format if it had not been there before? Is there any reason to use the class file except that it happens already be there? > > The worst thing is that you could view a class as a container of members, which on a higher level is also true for a module. However, the way the class format is used is ignoring this possibility and only (ab)uses the constant pool and the type's (!) attributes. Further: > > a) It is not easy readable for inspection javap module-info.class > c) You have to stopgap mandatory fields like super class, access, class name, etc. No, the access_flags will indicate that it's a module descriptor. > d) It will confuse the heck out of any existing class parsers No, the classfile is versioned. It has already changed twice (1.5 and 1.7) > e) It is not easy extendable for other module systems The attribute_info let you store any attributes you want. > f) There is just no need to use the class file a circular argument, sorry my brain overflow. > h) It unnecessarily complicates management systems why ? > > This is an almost perfect example of Conways law pointed out by Gafter. Once you're familiar with a technology you frame solutions in that technology. A module descriptor has to be versioned, extensible, to contains synthetized values (tagged as such), be validated (by at least checking that referenced modules, packages and types exist), in my opinion, that's match what the classfile format is. If you prefer another format, I have no problem but, in my opinion, it will be enough close to the classfile format to not worth to create a new format. > > Kind regards, > > Peter Kriens cheers, R?mi From forax at univ-mlv.fr Thu Jan 5 06:25:35 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Thu, 05 Jan 2012 15:25:35 +0100 Subject: What is a language construct? (was Re: Comment on state of Project Jigsaw) In-Reply-To: <4F04BB6E.4040309@tibco.com> References: <20111221223027.33AD123A6@eggemoggin.niobe.net> <4EF26029.1050700@univ-mlv.fr> <4EF2679F.9050408@oracle.com> <4EF27623.2050501@oracle.com> <4EF2889C.5070707@oracle.com> <4EF3D3D0.50704@oracle.com> <4F046650.3030103@univ-mlv.fr> <4F047807.7090507@univ-mlv.fr> <4F04BB6E.4040309@tibco.com> Message-ID: <4F05B2DF.7090907@univ-mlv.fr> On 01/04/2012 09:49 PM, Eric Johnson wrote: > Comment below... > > On 1/4/12 5:02 PM, R?mi Forax wrote: >> On 01/04/2012 04:23 PM, David Bosschaert wrote: >>> On 4 January 2012 14:46, R?mi Forax wrote: >>>> The module descriptor is not the .java but the .class, >>>> the .java is a convenient way to specify the module descriptor. >>> I have nothing against a convenient way of specifying a module >>> description, I actually see that as a requirement :) but that >>> requirement doesn't imply that it needs to be shoe-horned into .java >>> and .class files! >> >> The .class format is already an extensible versioned container format >> with a dictionnary which is able to store string and class name. >> No shoehorn here. > > OK, perhaps the format is reusable, but how will existing tools fare > with it? > Will existing IDEs choke on the file unless modified because it has > unexpected content? Will code obfuscation tools obfuscate it by > default? Will Ant need to be updated to treat these files specially? > Will any ASM client ever written fall over because the module > definition file doesn't actually include byte codes? What about tools > like "bnd" that introspect ".class" files looking for referenced > symbols, so that they can generate OSGi information? The classfile format is versioned, each time a new version is created, like 1.5 and 1.7 did, you have to update your tools. most of the tools, first check the version and just exit if the version number is unknown. > > I think the notion of reusing a format might work, but I suspect > reusing the extension ".class" will cause a lot of churn in downstream > tooling, and it doesn't sound like that's been considered here. (And I > worry that I've written code that would succumb to that churn.) > > If you're arguing that it is a useful container format, though, there > are plenty of other "container formats" - JSON and XML jump to mind - > that can equally well satisfy the requirements that have been stated > so far. If you use a text format, you introduce several stupid problems like the charset encoding and the fact that a user can update the module descriptor without re-validating it. > Since modules must be "installed" (if I've understood what I've read > correctly), then any notions of pre-compiling them are likely not > essential, because the installation process can do what it wishes, and > the files themselves have no "external" dependencies that need to be > controlled in a compilation process (unlike, say, the existing Java > classes that we compile.) I don't agree. You still need to validate the module descriptor before distributing it so a long time before installing it. And the module descriptor contains references to packages and types that need to be checked. > > -Eric. > R?mi From eric at tibco.com Thu Jan 5 08:05:03 2012 From: eric at tibco.com (Eric Johnson) Date: Thu, 5 Jan 2012 17:05:03 +0100 Subject: What is a language construct? (was Re: Comment on state of Project Jigsaw) In-Reply-To: <4F05B03D.2090707@univ-mlv.fr> References: <20111221223027.33AD123A6@eggemoggin.niobe.net> <4EF26029.1050700@univ-mlv.fr> <4EF2679F.9050408@oracle.com> <4EF27623.2050501@oracle.com> <4EF2889C.5070707@oracle.com> <4EF3D3D0.50704@oracle.com> <4F046650.3030103@univ-mlv.fr> <4F047807.7090507@univ-mlv.fr> <4F05B03D.2090707@univ-mlv.fr> Message-ID: <4F05CA2F.5050901@tibco.com> At the risk of tilting at windmills, I'm going to try two responses here. First this email. Consider an alternate straw-man, wherein the module descriptor uses XML, let's see how the responses change based on what R?mi proposes. Counter responses sprinkled throughout. On 1/5/12 3:14 PM, R?mi Forax wrote: > On 01/05/2012 02:23 PM, Peter Kriens wrote: >> On 4 jan. 2012, at 17:02, R?mi Forax wrote: >>> The .class format is already an extensible versioned container format >>> with a dictionnary which is able to store string and class name. >>> No shoehorn here. >> Hmmmmm. To me this is the biggest shoehorn I've seen in a long, long >> time ... Would you ever, ever, use this format if it had not been >> there before? Is there any reason to use the class file except that >> it happens already be there? >> >> The worst thing is that you could view a class as a container of >> members, which on a higher level is also true for a module. However, >> the way the class format is used is ignoring this possibility and >> only (ab)uses the constant pool and the type's (!) attributes. Further: >> >> a) It is not easy readable for inspection > > javap module-info.class cat module-info.xml (Java classfile tools need not be used - simpler!) > >> c) You have to stopgap mandatory fields like super class, access, >> class name, etc. > > No, the access_flags will indicate that it's a module descriptor. The root element of the XML file will indicate it is a module descriptor. If you add namespaces, a schema-aware XML editor can even validate conformance of the "syntax" of expected elements, if not the semantics. > >> d) It will confuse the heck out of any existing class parsers > > No, the classfile is versioned. It has already changed twice (1.5 and > 1.7) As a separate XML file, no existing class parsers need to be updated at all. > >> e) It is not easy extendable for other module systems > > The attribute_info let you store any attributes you want. The attributes of XML elements can let you store any additional data you want. > >> f) There is just no need to use the class file > > a circular argument, sorry my brain overflow. Your argument seems to be "I have a hammer, therefore this is a nail" - I have a container file format, therefore this module data can fit into it. In other words, the argument is not circular. Peter and I are merely pointing out that the use of a .class file, or even just a .class file format under a different name is not a foregone conclusion based on the requirements stated so far. > >> h) It unnecessarily complicates management systems > > why ? Myriad tools can be used to edit/update an XML format file, not just the specific tools designed to work with Java class files. The fact that you *also* insist that it also end with ".class" means that all tools that look for class files will now have to pay attention to when to ignore these files. Examples include obfuscators, byte-code analysis tools, etc. > >> >> This is an almost perfect example of Conways law pointed out by >> Gafter. Once you're familiar with a technology you frame solutions in >> that technology. > > A module descriptor has to be versioned, extensible, to contains > synthetized values (tagged as such), > be validated (by at least checking that referenced modules, packages > and types exist), > in my opinion, that's match what the classfile format is. An XML file can be versioned, is extensible, can contain synthesized values (which can be tagged as such), can be validated by a schema, and use tools like SchemaTron to further check semantics. In my opinion that's a perfect fit for schema-constrained XML file. > > If you prefer another format, I have no problem but, in my opinion, > it will be enough close to the classfile format to not worth to create > a new format. And in my opinion, you're overloading an existing container format with surprising new content, when an existing meta-format works better for myriad uses. The above isn't all to argue that XML is the best choice here, merely that it seems to work to counter the arguments put forth so far that the classfile is the ideal format. At a minimum, the file deserves a different extension so that existing tools that only care about actual classes don't read it for byte codes. -Eric. From eric at tibco.com Thu Jan 5 08:25:04 2012 From: eric at tibco.com (Eric Johnson) Date: Thu, 5 Jan 2012 17:25:04 +0100 Subject: What is a language construct? (was Re: Comment on state of Project Jigsaw) In-Reply-To: <4F05B2DF.7090907@univ-mlv.fr> References: <20111221223027.33AD123A6@eggemoggin.niobe.net> <4EF26029.1050700@univ-mlv.fr> <4EF2679F.9050408@oracle.com> <4EF27623.2050501@oracle.com> <4EF2889C.5070707@oracle.com> <4EF3D3D0.50704@oracle.com> <4F046650.3030103@univ-mlv.fr> <4F047807.7090507@univ-mlv.fr> <4F04BB6E.4040309@tibco.com> <4F05B2DF.7090907@univ-mlv.fr> Message-ID: <4F05CEE0.7060906@tibco.com> Hi R?mi, On 1/5/12 3:25 PM, R?mi Forax wrote: > On 01/04/2012 09:49 PM, Eric Johnson wrote: >> Comment below... >> >> On 1/4/12 5:02 PM, R?mi Forax wrote: >>> On 01/04/2012 04:23 PM, David Bosschaert wrote: >>>> On 4 January 2012 14:46, R?mi Forax wrote: >>>>> The module descriptor is not the .java but the .class, >>>>> the .java is a convenient way to specify the module descriptor. >>>> I have nothing against a convenient way of specifying a module >>>> description, I actually see that as a requirement :) but that >>>> requirement doesn't imply that it needs to be shoe-horned into .java >>>> and .class files! >>> >>> The .class format is already an extensible versioned container format >>> with a dictionnary which is able to store string and class name. >>> No shoehorn here. >> >> OK, perhaps the format is reusable, but how will existing tools fare >> with it? > >> Will existing IDEs choke on the file unless modified because it has >> unexpected content? Will code obfuscation tools obfuscate it by >> default? Will Ant need to be updated to treat these files specially? >> Will any ASM client ever written fall over because the module >> definition file doesn't actually include byte codes? What about tools >> like "bnd" that introspect ".class" files looking for referenced >> symbols, so that they can generate OSGi information? > > The classfile format is versioned, each time a new version is created, > like 1.5 and 1.7 did, > you have to update your tools. most of the tools, first check the > version and just exit > if the version number is unknown. I understood that. I think you're overlooking my point about how many additional changes tools might need to make. Think of the universe of existing tools that crawl Java .class files for whatever reason. How many of those existing tools need to care about module information (answer 0%)? How many of those tools will need to be updated - beyond accepting the newer version - if the module information is loaded into an existing .class file format, with a .class extension. If I were drawing a picture, I'd have a circle with three pie slices: * tools that need to change merely to accept the new version of the class file format * tools that don't care about the module information but will need to change to work around/ignore said data * tools that actually care about the new module information. Question is, how big are you making that middle slice? If you put the module information into an alternate format, I *know* that the second slice is an empty set. > >> >> I think the notion of reusing a format might work, but I suspect >> reusing the extension ".class" will cause a lot of churn in >> downstream tooling, and it doesn't sound like that's been considered >> here. (And I worry that I've written code that would succumb to that >> churn.) > > > >> >> If you're arguing that it is a useful container format, though, there >> are plenty of other "container formats" - JSON and XML jump to mind - >> that can equally well satisfy the requirements that have been stated >> so far. > > If you use a text format, you introduce several stupid problems like > the charset encoding > and the fact that a user can update the module descriptor without > re-validating it. XML deals quite nicely with character encodings. As for updating, it is merely that the tooling is simpler. Re-validating might be required in either case. > >> Since modules must be "installed" (if I've understood what I've read >> correctly), then any notions of pre-compiling them are likely not >> essential, because the installation process can do what it wishes, >> and the files themselves have no "external" dependencies that need to >> be controlled in a compilation process (unlike, say, the existing >> Java classes that we compile.) > > I don't agree. > You still need to validate the module descriptor before distributing > it so a long time before installing it. > And the module descriptor contains references to packages and types > that need to be checked. My point was that any "compilation" process you can do on a module descriptor can be done on the file itself without reference to those external entities. /Validation/ is a separate problem. For an analogy, a Python file can be compiled to a ".pyc" file without any knowledge of external dependencies. However, it cannot be run unless those external dependencies are satisfied. -Eric. From alex.buckley at oracle.com Thu Jan 5 12:22:42 2012 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 05 Jan 2012 12:22:42 -0800 Subject: What is a language construct? (was Re: Comment on state of Project Jigsaw) In-Reply-To: <4F05CEE0.7060906@tibco.com> References: <20111221223027.33AD123A6@eggemoggin.niobe.net> <4EF26029.1050700@univ-mlv.fr> <4EF2679F.9050408@oracle.com> <4EF27623.2050501@oracle.com> <4EF2889C.5070707@oracle.com> <4EF3D3D0.50704@oracle.com> <4F046650.3030103@univ-mlv.fr> <4F047807.7090507@univ-mlv.fr> <4F04BB6E.4040309@tibco.com> <4F05B2DF.7090907@univ-mlv.fr> <4F05CEE0.7060906@tibco.com> Message-ID: <4F060692.7060105@oracle.com> On 1/5/2012 8:25 AM, Eric Johnson wrote: > If I were drawing a picture, I'd have a circle with three pie slices: > > * tools that need to change merely to accept the new version of the > class file format > * tools that don't care about the module information but will need to > change to work around/ignore said data > * tools that actually care about the new module information. > > Question is, how big are you making that middle slice? If you put the > module information into an alternate format, I *know* that the second > slice is an empty set. (In what follows, I assume 52.0 is the ClassFile version for Java SE 8.) The various ClassFile attributes proposed by Jigsaw (Module, ModuleRequires, etc) should have no impact on tools which only know about pre-52.0 ClassFiles. The JVM Spec has always been very clear that new attributes can be defined and must be silently ignored by parts of the system which pre-date them. We already have two new annotation-related attributes proposed for 52.0 by JSR 308. The worst-case scenario is a pre-52.0 tool ignoring ClassFile version and attempting to interpret a 52.0 ClassFile as if it was an earlier version. This tool is broken (consider an 'invokedynamic' instruction in a 51.0 ClassFile that's interpreted as 50.0) ... but still, new module attributes will just be ignored. What _could_ be a problem is any redefinition of non-attribute artifacts in a 52.0 ClassFile v. 51.0. Is there any such redefinition? I tried to avoid it, but there are two. They take effect only when the new ACC_MODULE flag is set. (I regard a new flag much like a new attribute; it must be safe to add constructs which in and of themselves don't overlap with existing constructs.) They are: 1) Non-setting of ACC_INTERFACE no longer means "this is a class". (Though this is moot because interpreting the ClassFile as a class anyway will reveal a well-formed but very boring class.) 2) Setting of super_class to 0 no longer means "my supertype is an Object". So that's the effect of using the ClassFile structure to reify module information. Tools which properly recognize 52.0 ClassFiles but that don't care about module information will have to work around (2). Since such a tool would already be switching on the presence of ACC_MODULE, (2) is almost trivial. Alex From alex.buckley at oracle.com Thu Jan 5 13:56:22 2012 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 05 Jan 2012 13:56:22 -0800 Subject: What is a language construct? (was Re: Comment on state of Project Jigsaw) In-Reply-To: <4F060692.7060105@oracle.com> References: <20111221223027.33AD123A6@eggemoggin.niobe.net> <4EF26029.1050700@univ-mlv.fr> <4EF2679F.9050408@oracle.com> <4EF27623.2050501@oracle.com> <4EF2889C.5070707@oracle.com> <4EF3D3D0.50704@oracle.com> <4F046650.3030103@univ-mlv.fr> <4F047807.7090507@univ-mlv.fr> <4F04BB6E.4040309@tibco.com> <4F05B2DF.7090907@univ-mlv.fr> <4F05CEE0.7060906@tibco.com> <4F060692.7060105@oracle.com> Message-ID: <4F061C86.3060400@oracle.com> On 1/5/2012 12:22 PM, Alex Buckley wrote: > The various ClassFile attributes proposed by Jigsaw (Module, > ModuleRequires, etc) should have no impact on tools which only know > about pre-52.0 ClassFiles. Actually I can strengthen this sentence: the various attributes should have no impact on tools, period. (Or "full stop", as some would say.) They can be ignored by _any_ ClassFile reader which doesn't care about module information, whether it's from 1996 and reads 45.3 or it's from 2013 and reads 52.0. > 2) Setting of super_class to 0 no longer means "my supertype is an Object". To phrase this better: it no longer means "my superclass is Object (if I'm a class), or my superinterface is represented as Object (if I'm an interface)". Alex From chris.hegarty at oracle.com Fri Jan 6 08:14:18 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 06 Jan 2012 16:14:18 +0000 Subject: native cmds and libs in the module library In-Reply-To: <4EF08C15.7060305@oracle.com> References: <4EE62FE1.70006@oracle.com> <4EEF597F.3030804@oracle.com> <4EEF6518.4060004@oracle.com> <4EF08A20.7030106@oracle.com> <4EF08C15.7060305@oracle.com> Message-ID: <4F071DDA.2040607@oracle.com> Here is an updated webrev incorporating the feedback I received. http://cr.openjdk.java.net/~chegar/jigsaw/libbin_webrev.01/webrev/ 1) '-natlibs' -> '--natlibs', '-natcmds' -> '--natcmds' 2) detect during 'jmod create' if a directory is creatable/writable 3) detect conflicts and rollback changes if there is a conflict 4) track files installed outside of the module directory It would be nice to allow an override of files in the module libraries natlibs or natcmds directories if a newer version of the same module is installed. Currently this will fail due to a conflict on these files. This shouldn't be difficult to add later. -Chris. On 20/12/2011 13:22, Chris Hegarty wrote: > On 12/20/11 01:14 PM, Alan Bateman wrote: >> On 19/12/2011 16:23, Sean Mullan wrote: >>> On most systems, you'll probably also run into file permission issues >>> if you >>> aren't superuser or an administrator. Is this something you are going >>> to detect >>> up-front and warn the user or will the command just fail when it >>> tries to >>> install the files? >>> >>> --Sean >>> >> If the "jmod create" command creates the bin and lib directories and it >> fails then that gives us the error. If it doesn't create the directories >> then it could emit a warning if they aren't writable. In any case, if >> the install fails for any reason then it should rollback all changes. > > Right, I'm in the process of making this change. Currently we only > remove the module directory, we need to track out of module content and > remove it if necessary. This will hopefully be useful for a 'jmod > remove' command in the future too. > > I was planning to use the same rollback strategy if a conflict, a native > library or command already exists with the same name, occurs. I'm also > incorporating your feedback from yesterday. > > -Chris. > >> >> -Alan. From jaroslav.tulach at oracle.com Sun Jan 8 08:44:57 2012 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Sun, 8 Jan 2012 17:44:57 +0100 Subject: (Complete) range dependencies back in the game? was: No isolation In-Reply-To: <4F0477D3.8040600@oracle.com> References: <20111223202734.4467CF7F@eggemoggin.niobe.net> <201201041013.50736.jaroslav.tulach@oracle.com> <4F0477D3.8040600@oracle.com> Message-ID: <201201081744.57845.jaroslav.tulach@oracle.com> >## 4.?1.?2012 17:01:23 ##< > On 01/04/2012 04:13 AM, Jaroslav Tulach wrote: > module java.beans @ 1.8.3 { > // did not use delItems, so give a lax dep > requires optional java.awt @ [1.8,3); > } My original proposal did not allow dependency like [1.8, 3). Only [1.8, 2). I was trying to incorporate the wider range into the proof somehow and at the end I think: maybe a modified version of range dependencies is not that bad (combine with best practices based on semantic versioning). If anyone wants to check (and correct) my thoughts, here is a link to my write up: http://wiki.apidesign.org/wiki/RangeDependenciesAnalysed -jt From Alan.Bateman at oracle.com Mon Jan 9 10:56:48 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 09 Jan 2012 18:56:48 +0000 Subject: native cmds and libs in the module library In-Reply-To: <4F071DDA.2040607@oracle.com> References: <4EE62FE1.70006@oracle.com> <4EEF597F.3030804@oracle.com> <4EEF6518.4060004@oracle.com> <4EF08A20.7030106@oracle.com> <4EF08C15.7060305@oracle.com> <4F071DDA.2040607@oracle.com> Message-ID: <4F0B3870.4090601@oracle.com> On 06/01/2012 16:14, Chris Hegarty wrote: > Here is an updated webrev incorporating the feedback I received. > > http://cr.openjdk.java.net/~chegar/jigsaw/libbin_webrev.01/webrev/ > > 1) '-natlibs' -> '--natlibs', '-natcmds' -> '--natcmds' > 2) detect during 'jmod create' if a directory is creatable/writable > 3) detect conflicts and rollback changes if there is a conflict > 4) track files installed outside of the module directory > > It would be nice to allow an override of files in the module libraries > natlibs or natcmds directories if a newer version of the same module > is installed. Currently this will fail due to a conflict on these > files. This shouldn't be difficult to add later. > > -Chris. > I went through this and I think it's starting to come good. One concern is that ModuleFile now only works with a SimpleLibrary whereas I think it should be able to work with any Library implementation. Also "oomfiles" is a strange name to have in the module library. Something like "otherfiles" or just "files" might be better. For consistency and portability it would be better to have it in UTF8 rather than the platform encoding. It might be worth combining getSubdirOfSection and librarySectionPath into one instance method that returns the location to install the section (be in the module library or elsewhere). Security is a concern where an adversary may include a sequence of ../ in the relative path to a library. I think it would be good to include a couple of tests for this type of issue. Otherwise, I think the approach is okay, just needs clean-up and ensuring that the coding style and naming is consistent. -Alan. From mandy.chung at oracle.com Mon Jan 9 15:02:00 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 09 Jan 2012 15:02:00 -0800 Subject: native cmds and libs in the module library In-Reply-To: <4F071DDA.2040607@oracle.com> References: <4EE62FE1.70006@oracle.com> <4EEF597F.3030804@oracle.com> <4EEF6518.4060004@oracle.com> <4EF08A20.7030106@oracle.com> <4EF08C15.7060305@oracle.com> <4F071DDA.2040607@oracle.com> Message-ID: <4F0B71E8.2010104@oracle.com> On 1/6/2012 8:14 AM, Chris Hegarty wrote: > Here is an updated webrev incorporating the feedback I received. > > http://cr.openjdk.java.net/~chegar/jigsaw/libbin_webrev.01/webrev/ > This is a good start. We can extend this approach for the configuration files section as these files are intended to be edited by the users; otherwise the users would require to know the module library layout to find the config files. The jdk modules in the current jigsaw prototype don't have the "configs" section because it requires changes in the JDK implementation to get the properties file at the new location (possibly add a new API to obtain it) that hasn't happened yet. The properties files currently remains under the $JAVA_HOME/lib directory or its subdirectory as in the legacy image. It also requires changes in the jdk build. It would be good to add the support now to prepare the future transition. It makes sense to me to specify an alternative path for the native cmds and config files when creating the module library but I am not quite sure about the native libraries. Native libraries in a module are typically the implementation to support its own module and not have a dependency on another. There are 7 jdk modules that have native libs but no native cmd nor config files. jdk.sctp is the only module whose native lib (libsctp.so) has dependency on native libs on another module. There are 6 jdk modules that have native libs and also either native cmds or config files. Attached is the matrix I have from the jdk I built with module views prototype. I am wondering what the common use cases are and whether --natlib option should be a per-module base or per-library base? For the per-library base as in your proposal, it's simpler and consistent with other files (native cmds and config files) but modules with native library but no dependency on other module's native library can only support one single version unless the native library uses shared library versioning. Would it make sense to support the --natlib option as per-module base (i.e. jmod install option)? > It would be nice to allow an override of files in the module libraries > natlibs or natcmds directories if a newer version of the same module > is installed. Currently this will fail due to a conflict on these > files. This shouldn't be difficult to add later. In addition, when we remove a module of a specific version, it should restore natcmds/natlibs in the latest version of the same module in the module library, if present. As for my comments to the implementation, I agree with Alan that the filename "oomfiles" is a bit strange and simply naming it "files" seems good to me. Some other comments: ModuleFile.java L129: Rather than passing SimpleLibrary as a parameter to the Reader constructor, perhaps it's better to pass the paths to the readRest method to specify the destination to install section content for different section types. L450-454& 472-476: it might be good to combine the markNativeCodeExecutable and trackOutOfModuleContent methods as both are post-extract steps. L567-587: as Alan also pointed out, this might be worth having a method to return the path of a given section type. SimpleLibrary.java L264: Files.ensureIsDirectory is the same utility method but is private. Perhaps just use the existing one. L287, 302: looks like these lines can just call the ensureDirectory method. Librarian.java L50-51: this can be replaced with Library.systemLibraryPath(). Mandy -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: jdk-modules.txt Url: http://mail.openjdk.java.net/pipermail/jigsaw-dev/attachments/20120109/3e4e8d86/jdk-modules.txt From jesse.glick at oracle.com Fri Jan 13 05:34:23 2012 From: jesse.glick at oracle.com (Jesse Glick) Date: Fri, 13 Jan 2012 08:34:23 -0500 Subject: (Complete) range dependencies back in the game? In-Reply-To: <201201081744.57845.jaroslav.tulach@oracle.com> References: <20111223202734.4467CF7F@eggemoggin.niobe.net> <201201041013.50736.jaroslav.tulach@oracle.com> <4F0477D3.8040600@oracle.com> <201201081744.57845.jaroslav.tulach@oracle.com> Message-ID: <4F1032DF.20402@oracle.com> On 01/08/2012 11:44 AM, Jaroslav Tulach wrote: > http://wiki.apidesign.org/wiki/RangeDependenciesAnalysed "It does not make much sense to have higher upper bound of dependency on C higher than any existing upper bound on C among reused libraries (thus s <= q)" - I disagree that this does not make sense. Let us say that C has both an API and an SPI; the API is kept quite stable but the SPI is frequently rewritten (and the handful of implementations are expected to keep up). So pretend C is DOM, and API clients normally use ranges like [1.2,2) ("DOM 2 or any foreseeable compatible release") whereas SPI implementations normally use ranges like [1.2,1.3) ("DOM 2 but not 3"). Now pretend B is a library for XML persistence of Java objects, and during one serialization mode it creates flyweight org.w3c.dom.Document's. Versions 1.0 through 1.3, written back when DOM 2 ruled the land, declares [1.2,1.3); version 1.4 and later implement DOM 3 so declare [1.3,1.4) but are otherwise fully compatible for callers. Finally say A is an application which uses XML serialization for some preferences storage, and also uses DOM quite independently for dealing with REST clients. So it would like to declare B@[1.0,2) and C@[1.2,2): it uses only the basic initial serialization API, and can work with any known DOM release. The fact that B at 1.0 is incompatible with C at 1.3 does not trouble the author of A; the app would work fine with B at 1.5 and C at 1.3 as well. If the compiler silently converted the dep on C@[1.2,2) to C@[1.2,1.3), it would effectively mean that B at 1.4 could not be used even if it had numerous bug fixes, which is generally not what you want. It could instead just reject A's attempted expression of what its actual dependency ranges are, with some sort of error message TBD, and the author of A would (after some trial and error) eventually give up on supporting older libraries and request B@[1.4,2) and C[1.3,2). This switch would be rather artificial: the originally attempted dependency declaration was logically sound, and a module system using a SAT solver would not have difficulty linking A with either newer or older libraries according to what is available. (An organization which decided it hated the DOM 3 license might forbid it from being installed, in which case you would like to be able to run A with B at 1.3 and C at 1.2.) Indeed if A does not use XML namespaces in its REST API, it could as well declare C@[1.1,2) even knowing that current versions of B require at least C at 1.2; a future version of B might stop needing to implement DOM and (if it did not use namespaces either) might declare C@[1.1,2), in which case B at 1.7 C at 1.1 would be a valid configuration too. Obviously this is a less likely scenario, but it shows that "[t]his definition seems to make sense from the point of lower bound" is not so obvious either. On this topic, I think the definition of complete repository is unnecessarily strict; there is no reason apparent to me why [r,s) must be a subrange of [p,q), though it does at least need to overlap (and probably a version of C in that intersection must actually be present in the repo). Where in the proof is the assumption of subranges used? You only check whether cr is empty, which it would be in the attempted conversion to 3-SAT. It seems that A could express any dependency on C it likes, and trying to compile A would either work or not work, according to whether its dep on C has at least some overlap with that of the earliest versions of its other dependencies. By the way, you do not really discuss selecting a configuration at install time in a complete repository. [1] does not seem to apply to arbitrary range dependencies. Probably you can start with a configuration using the lower bounds of all dependencies as determined during compilation, then iteratively try raising the version of each module individually so long as doing so continues to result in a valid configuration - i.e. pick a locally maximal configuration. This is polynomial. [1] http://wiki.apidesign.org/wiki/LibraryWithoutImplicitExportIsPolynomial#Merge_of_Configurations From dmitry.bessonov at oracle.com Fri Jan 13 09:17:35 2012 From: dmitry.bessonov at oracle.com (Dmitry Bessonov) Date: Fri, 13 Jan 2012 21:17:35 +0400 Subject: a compilation issue caused by the order of two 'requires' directives Message-ID: <4F10672F.5000601@oracle.com> Hello, While playing with the recent JigSaw build I came across a strange compilation issue which exposes the inability to resolve module dependences in case when two 'requires' clauses are listed in particular order. The structure is the following - 3 modules are compiled and installed one after the other. module bar @ 1.0 { } module foo @ 1.0 { requires optional bar @>1.0; } module test @ 1.0 { requires bar; requires foo; } The compilation fails for the last module ('test'). To compile module successfully it is just needed to interchange two 'requires' clauses in module 'test'. Best regards, Dmitry From chris.hegarty at oracle.com Tue Jan 17 06:28:38 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 17 Jan 2012 14:28:38 +0000 Subject: native cmds and libs in the module library In-Reply-To: <4F0B71E8.2010104@oracle.com> References: <4EE62FE1.70006@oracle.com> <4EEF597F.3030804@oracle.com> <4EEF6518.4060004@oracle.com> <4EF08A20.7030106@oracle.com> <4EF08C15.7060305@oracle.com> <4F071DDA.2040607@oracle.com> <4F0B71E8.2010104@oracle.com> Message-ID: <4F158596.2030306@oracle.com> Here is an updated webrev based on the comments and feedback I received on this. - An additional option is added for supporting config files - jdk/jre images are created by installing jmod files ( if available ) - Some code cleanup and style changes http://cr.openjdk.java.net/~chegar/jigsaw/libbin_webrev.03/webrev/ Issues I intend to address separately: - Separate out native libs and config files during the build, so they can be put into the right sections of the jmod file - Investigate the potential for global configuration files versus non-editable per-module config files. Thanks, -Chris. From Alan.Bateman at oracle.com Tue Jan 17 07:26:09 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 17 Jan 2012 15:26:09 +0000 Subject: Module views with exports support In-Reply-To: <4EFDF7F8.7040900@oracle.com> References: <4EFDF7F8.7040900@oracle.com> Message-ID: <4F159311.8060908@oracle.com> On 30/12/2011 17:42, Mandy Chung wrote: > A new webrev for the module views [1] with the exports support: > http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/module-views.01/ > > High-level summary: > - Introduced a new ModuleView class and Service.Dependence > Service.ProviderInfo classes. Each ModuleInfo has one or > more views. > - Renamed ModuleIdQuery to ModuleViewQuery > - Renamed methods in the Catalog class to return ModuleId for > module views. E.g. > gatherLocalModuleIds -> gatherLocalModuleViewIds > listModuleIds -> listModuleViewIds > findModuleIds -> findModuleViewIds > findLatestModuleId -> findLatestModuleViewId > - Linker is updated to link with types that are exported by > its dependence and only exported set of remote packages are > stored in the configuration. > > I also considered renaming ModuleId to ModuleViewId (not done in > the above webrev) but another thought would be to keep ModuleId > to represents a general identifier. I'd like to get your opinion > for this refactoring/renaming before moving forward. > > With exports, a module can access types exported from a module > view that it requires. A configuration has a set of contexts > and each context has a list of local classes and also a map > from a package name to a remote context. Before exports, all > public types are exported. For a simple application that requires > the "jdk" module, the configuration size is reduced by 73% (6.3) > > 8.6M mlib-tip/com.greetings/0.1/config > 2.3M mlib-views/com.greetings/0.1/config > > If it requires jdk.base, the configuration size is much smaller > as jdk.base has fewer public classes than jdk. With exports, > the size is reduced by 8.7% (72K). > > 824K mlib-base-tip/com.greetings/0.1/config > 752K mlib-base-views/com.greetings/0.1/config > > This is the module-info.java requiring the jdk module > (the current default platform module). > ---------------------- > module com.greetings @ 0.1 { > requires org.astro; > class com.greetings.Hello; > } > > module org.astro @ 2.0 { > exports org.astro; > } > ---------------------------- > > For the JDK modules with exports [2], the system module library size > is reduced by 8M (7.6%): > > 105M jigsaw-repo/jdk/build/linux-i586/lib/modules > 97M jigsaw-views/jdk/build/linux-i586/lib/modules > > It is still big in the current prototype and we expect that the fast > configuration work will further reduce the footprint (this is work in > progress). The number here is just to compare the size before and > after with exports support. > > Thanks > Mandy > > [1] > http://mail.openjdk.java.net/pipermail/jigsaw-dev/2011-December/001813.html > [2] > http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/module-views.01/module-info/jdk-modules-with-views.txt > [3] http://cr.openjdk.java.net/~mchung/jigsaw/views-api/ > I've taken a first pass over this, lots of good work. I like views and works really well for the JDK. I'm in two minds on some of the renaming as it forces anyone using the API to have to deal with the concept more than I had expected. For example when one invokes a list or find modules in a Catalog then I think it's debatable as to whether it should return the ModuleIds of the modules or ModuleIds synthesized from the view name and the module's version. I'm also in two minds on the changes to the module library where there is a directory with a copy of the module info. I can see how this is used but it kinda feels that this should be an index (key'ed on view) instead. In ModuleInfo then defaultView and views() make sense (the views method just needs to be clear that the returned set includes the default view). I'm less sure about the view(ModuleId) and view(String) methods as they aren't strictly required. In Service.Dependence I see the constructor takes a boolean to indicate if the dependency is optional. It may be more consistent (with Dependence) to have it take a set of modifiers - if you agree then I can take into the services patch as it's not re-based to your changes. I don't see anything obviously wrong with the exports work although I found ContextView in the linker hard to deal, maybe it just needs another name. What you would think about jmod ls -v printing the exports too? On the configuration size then the exports will reduce the size as you say but the size is a still a problem. I did a quick analysis of a hello world app that has all JDK modules installed. It looks like about 68% of the size is the local class map, and 30% for the remote package map. We can easily index these and it should reduce the size considerably. Minor nit is that I didn't understand the changes to Hi :-) -Alan. From mandy.chung at oracle.com Tue Jan 17 23:03:16 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 17 Jan 2012 23:03:16 -0800 Subject: native cmds and libs in the module library In-Reply-To: <4F158596.2030306@oracle.com> References: <4EE62FE1.70006@oracle.com> <4EEF597F.3030804@oracle.com> <4EEF6518.4060004@oracle.com> <4EF08A20.7030106@oracle.com> <4EF08C15.7060305@oracle.com> <4F071DDA.2040607@oracle.com> <4F0B71E8.2010104@oracle.com> <4F158596.2030306@oracle.com> Message-ID: <4F166EB4.9060108@oracle.com> On 1/17/2012 6:28 AM, Chris Hegarty wrote: > Here is an updated webrev based on the comments and feedback I received > on this. > > - An additional option is added for supporting config files If a relative path is specified as an argument to --natlib, --natbin, or --config option, what is it relative to and what gets recorded in the module library header? I believe the implementation currently uses cwd (i.e. the directory where jmod install is invoked) which means that we can't simply copy the module library and the natlibs to a different location to use?? See my comment for Modules.gmk. > http://cr.openjdk.java.net/~chegar/jigsaw/libbin_webrev.03/webrev/ Modules.gmk L141: --natlib $mlib/.. --natcmd $mlib/../../bin --config $$mlib/.. $mlib is an absolute path. Since these alt paths are recorded in the module library header, if we zip up the jdk-module-image and unzip it at a different location, these paths need fixup in order to install new modules in it. It seems that we should keep these paths relative to the system module library when creating the jdk modules image. Similarly, the realpath of the files are stored in "files" which would need fixup too which is not ideal. SimpleLibrary.java L346-348: I wonder if it's cleaner to initialize these instance variables to the default path, i.e. new File(root, "bin") if the given argument is null so that the null check is not needed in various place. L301: I think this warning should be output in the Librarian implementation rather than in the SimpleLibrary. Instead it should throw an exception if the natlibs is not writeable and when it writes a native library. L1289: it's a good question when we should check the extension. It depends if the specification requires the extension of a module file be a specific value. I think we can leave as it is and get back to it later. ModuleFile.java L199-201: may be cleaner if these variables are initialized to the default path e.g. File(destination, "lib") and the non-null check in the getDirOfSection method will not be needed. L581-585: minor: since they are interested in 3 section types, would it be better to handle each section type in this postExtract method rather than checking the section type in both markNativeCodeExecutable and trackFiles methods. Probably the markNativeCodeExecutable method can be merged with this postExtract method and remove L501-504 as well. Librarian.java L55, 151: this comment line can be removed. hello-native.sh It might be good to verify if the path of the native library is expected. > Issues I intend to address separately: > > - Separate out native libs and config files during the build, so they > can be put into the right sections of the jmod file > - Investigate the potential for global configuration files versus > non-editable per-module config files. That's fine with me. Mandy > > Thanks, > -Chris. From Alan.Bateman at oracle.com Wed Jan 18 11:34:48 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 18 Jan 2012 19:34:48 +0000 Subject: a compilation issue caused by the order of two 'requires' directives In-Reply-To: <4F10672F.5000601@oracle.com> References: <4F10672F.5000601@oracle.com> Message-ID: <4F171ED8.7010603@oracle.com> On 13/01/2012 17:17, Dmitry Bessonov wrote: > Hello, > > While playing with the recent JigSaw build > I came across a strange compilation issue which exposes > the inability to resolve module dependences in case > when two 'requires' clauses are listed in particular order. > > The structure is the following - 3 modules are compiled > and installed one after the other. > > module bar @ 1.0 { } > > module foo @ 1.0 { > requires optional bar @>1.0; > } > > module test @ 1.0 { > requires bar; > requires foo; > } > > The compilation fails for the last module ('test'). > To compile module successfully it is just needed > to interchange two 'requires' clauses in module 'test'. > > Best regards, > Dmitry This is indeed confusing and a reminder that the resolver will need good diagnostics so that javac and install/other time resolution can emit helpful messages. I believe that when the 3 module-info files are compiled together that the resolver will be called with all 3 in the root query set and that it will fail as expected (because bar at 1.0 doesn't satisfy the needs of both foo and test). When compiled individually then it does appear that there is an issue. I believe foo will compile because the configuration for foo will be computed (won't fail because the bar@>1.0 is an optional dependency). However when it comes to test then it does appear that the order changes changes. Jon - is there any possibility that the order issue is due to the Catalog implementation in javac? If not then I guess this means going through the resolver trace to see what is going on. -Alan From jonathan.gibbons at oracle.com Wed Jan 18 11:53:52 2012 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 18 Jan 2012 11:53:52 -0800 Subject: a compilation issue caused by the order of two 'requires' directives In-Reply-To: <4F171ED8.7010603@oracle.com> References: <4F10672F.5000601@oracle.com> <4F171ED8.7010603@oracle.com> Message-ID: <4F172350.5050401@oracle.com> On 01/18/2012 11:34 AM, Alan Bateman wrote: > > When compiled individually then it does appear that there is an issue. > I believe foo will compile because the configuration for foo will be > computed (won't fail because the bar@>1.0 is an optional dependency). > However when it comes to test then it does appear that the order > changes changes. Jon - is there any possibility that the order issue > is due to the Catalog implementation in javac? If not then I guess > this means going through the resolver trace to see what is going on. My initial sense is that this is entirely a resolver issue, and that we need to look at the resolver trace. -- Jon From Alan.Bateman at oracle.com Wed Jan 18 12:25:43 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 18 Jan 2012 20:25:43 +0000 Subject: a compilation issue caused by the order of two 'requires' directives In-Reply-To: <4F172350.5050401@oracle.com> References: <4F10672F.5000601@oracle.com> <4F171ED8.7010603@oracle.com> <4F172350.5050401@oracle.com> Message-ID: <4F172AC7.2060704@oracle.com> On 18/01/2012 19:53, Jonathan Gibbons wrote: > On 01/18/2012 11:34 AM, Alan Bateman wrote: >> >> When compiled individually then it does appear that there is an >> issue. I believe foo will compile because the configuration for foo >> will be computed (won't fail because the bar@>1.0 is an optional >> dependency). However when it comes to test then it does appear that >> the order changes changes. Jon - is there any possibility that the >> order issue is due to the Catalog implementation in javac? If not >> then I guess this means going through the resolver trace to see what >> is going on. > > My initial sense is that this is entirely a resolver issue, and that > we need to look at the resolver trace. You're probably right but I just tried Dmitry's code and I get the expected behavior if I install bar and foo into a module library and compile test specifying that module path. It's only when compiling with bar and foo on the module path that the ordering seems to matter. -Alan. From jonathan.gibbons at oracle.com Thu Jan 19 14:33:07 2012 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 19 Jan 2012 14:33:07 -0800 Subject: Jigsaw spec clarifications Message-ID: <4F189A23.3090101@oracle.com> 1. The uniqueness rule for provides services (It is a compile-time error if more than one |provides| clause in a view indicates the same module name or service name) is somewhat unclear about which of the names must be unique. What about provides service S with S_A; provides service S with S_B; What about provides service S1 with S; provides service S2 with S; Both of these would seem to be reasonable use cases. 2. The same rule for modules, can you provide different versions of a module? provides M @ 1.0; provides M @ 2.0; The spec implies not, which seems surprising for an alias mechanism. 3. I presume, but the spec does not say, that in "provides service S with S_A" S_A should be a subtype of S. -- Jon From jesse.glick at oracle.com Thu Jan 19 15:29:32 2012 From: jesse.glick at oracle.com (Jesse Glick) Date: Thu, 19 Jan 2012 18:29:32 -0500 Subject: Jigsaw spec clarifications In-Reply-To: <4F189A23.3090101@oracle.com> References: <4F189A23.3090101@oracle.com> Message-ID: <4F18A75C.4040503@oracle.com> On 01/19/2012 05:33 PM, Jonathan Gibbons wrote: > I presume, but the spec does not say, that in "provides service S with S_A" S_A should be a subtype of S. Let us not forget that S_A must also be public, concrete, with a public default constructor, not a nested nonstatic class, and neither S nor S_A may have type arguments. Generally that try { S _ = new S_A(); } catch (Exception x) {} must be compilable (without raw/unchecked warnings) from a hypothetical class in the same module but in its own package. From alex.buckley at oracle.com Thu Jan 19 16:30:10 2012 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 19 Jan 2012 16:30:10 -0800 Subject: Jigsaw spec clarifications In-Reply-To: <4F189A23.3090101@oracle.com> References: <4F189A23.3090101@oracle.com> Message-ID: <4F18B592.7020707@oracle.com> The module name in a 'provides' clause (no 'service') is the identifier immediately following 'provides' ... the service name in a 'provides service' clause is the identifier immediately following 'service'. Those are the identifiers which must be unique within a view. I hope Alan can confirm my understanding of services as follows: On 1/19/2012 2:33 PM, Jonathan Gibbons wrote: > provides service S with S_A; > provides service S with S_B; Illegal. Ambiguity in which implementation to use. > provides service S1 with S; > provides service S2 with S; Legal. > 2. The same rule for modules, can you provide different versions of a > module? > provides M @ 1.0; > provides M @ 2.0; > The spec implies not, which seems surprising for an alias mechanism. Illegal. If it was legal, do we want to infer that this module does _not_ provide M @ 1.5? That seems over-complex to me - providing 2.0, which indisputably happens above, usually means matching a requires constraint of >= 1.5. > 3. I presume, but the spec does not say, that in "provides service S > with S_A" S_A should be a subtype of S. Ah, I presume this too. Alex From alex.buckley at oracle.com Thu Jan 19 16:41:50 2012 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 19 Jan 2012 16:41:50 -0800 Subject: Jigsaw spec clarifications In-Reply-To: <4F18B592.7020707@oracle.com> References: <4F189A23.3090101@oracle.com> <4F18B592.7020707@oracle.com> Message-ID: <4F18B84E.60303@oracle.com> On 1/19/2012 4:30 PM, Alex Buckley wrote: > On 1/19/2012 2:33 PM, Jonathan Gibbons wrote: >> provides service S with S_A; >> provides service S with S_B; > > Illegal. Ambiguity in which implementation to use. Actually, scratch that. Legal! It's clear from http://openjdk.java.net/projects/jigsaw/doc/topics/services.html that a module can offer multiple implementations of a service interface. Alex From Alan.Bateman at oracle.com Fri Jan 20 04:28:01 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 20 Jan 2012 12:28:01 +0000 Subject: Jigsaw spec clarifications In-Reply-To: <4F18B592.7020707@oracle.com> References: <4F189A23.3090101@oracle.com> <4F18B592.7020707@oracle.com> Message-ID: <4F195DD1.6000503@oracle.com> On 20/01/2012 00:30, Alex Buckley wrote: > : > > I hope Alan can confirm my understanding of services as follows: > > On 1/19/2012 2:33 PM, Jonathan Gibbons wrote: >> provides service S with S_A; >> provides service S with S_B; > > Illegal. Ambiguity in which implementation to use. I read your subsequent clarification and I agree it has to be legal (and we have a test for this in the current services patch [1]). > >> provides service S1 with S; >> provides service S2 with S; > > Legal. Yes, but probably won't be too common (either S is an interface, or S1 or S2 is a subtype of the other). As to one of Jesse's points, I don't think the current spec mandates that the the service implementation have a public no-arg constructor. javac doesn't check for this currently so it's possible to get a ServiceConfigurationError at runtime for this case with the current patch. An entry point on the other is specified to have a public static void main method. -Alan. [1] http://cr.openjdk.java.net/~alanb/jigsaw-services/webrev/ From jesse.glick at oracle.com Fri Jan 20 06:54:56 2012 From: jesse.glick at oracle.com (Jesse Glick) Date: Fri, 20 Jan 2012 09:54:56 -0500 Subject: Jigsaw spec clarifications In-Reply-To: <4F195DD1.6000503@oracle.com> References: <4F189A23.3090101@oracle.com> <4F18B592.7020707@oracle.com> <4F195DD1.6000503@oracle.com> Message-ID: <4F198040.900@oracle.com> On 01/20/2012 07:28 AM, Alan Bateman wrote: >>> provides service S1 with S; >>> provides service S2 with S; > > probably won't be too common (either S is an interface Impossible; it must be a concrete class. > or S1 or S2 is a subtype of the other) To the contrary I see this pattern all the time in NetBeans (*), without any subtype relationship between the interfaces: module api { exports api; } package api; public interface FrobnitzReader { java.io.Reader parse(java.io.File frobnitz); } package api; public interface FrobnitzWriter { void store(java.io.File frobnitz, java.io.Writer writer); } module impl { requires api; provides service api.FrobnitzReader with impl.FrobnitzHandler; provides service api.FrobnitzWriter with impl.FrobnitzHandler; } package impl; public class FrobnitzHandler implements api.FrobnitzReader, api.FrobnitzWriter { public java.io.Reader parse(java.io.File frobnitz) {...} public void store(java.io.File frobnitz, java.io.Writer writer) {...} } Nothing weird there that I can see; the author of impl merely preferred to keep related code in one source file. (This does lead to a subtle point: currently ServiceProvider.load will always instantiate a fresh copy of each service implementation class every time you call it. This means that nonstatic fields in a S.I. class, or an explicit constructor, are usually signs of a logic error. In the above example, it means that client code would get a different FrobnitzHandler instance for reading vs. for writing. I do not think there is any reason to change this policy when SL is used in a modular environment, but it should at least be documented whether SL may/must/must not cache instances. This is especially true since a system using dependency injection for the same purpose would likely behave differently.) > I don't think the current spec mandates that the the service implementation have a public no-arg constructor. javac doesn't check for this > currently so it's possible to get a ServiceConfigurationError at runtime for this case Seems like a defect in the spec. If there is some problem with the signature of the service that can reliably be detected at compile time, it should be treated as an error. (*) Using the comparable @ServiceProvider, normally paired with Lookup.getDefault but also largely compatible with ServiceLoader. From jaroslav.tulach at oracle.com Fri Jan 20 07:18:39 2012 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Fri, 20 Jan 2012 16:18:39 +0100 Subject: More reliable services was: Jigsaw spec clarifications In-Reply-To: <4F198040.900@oracle.com> References: <4F189A23.3090101@oracle.com> <4F195DD1.6000503@oracle.com> <4F198040.900@oracle.com> Message-ID: <201201201618.39496.jaroslav.tulach@oracle.com> >## 20.?1.?2012 15:54:56 ##< > > I don't think the current spec mandates that the the service > > implementation have a public no-arg constructor. javac doesn't check for > > this currently so it's possible to get a ServiceConfigurationError at > > runtime for this case > > Seems like a defect in the spec. If there is some problem with the > signature of the service that can reliably be detected at compile time, it > should be treated as an error. +1 btw. when at rewriting the spec, could you consider including support for static factory methods as proposed by http://bugs.sun.com/view_bug.do?bug_id=6766540 ? -jt From Alan.Bateman at oracle.com Fri Jan 20 07:26:30 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 20 Jan 2012 15:26:30 +0000 Subject: Jigsaw spec clarifications In-Reply-To: <4F198040.900@oracle.com> References: <4F189A23.3090101@oracle.com> <4F18B592.7020707@oracle.com> <4F195DD1.6000503@oracle.com> <4F198040.900@oracle.com> Message-ID: <4F1987A6.8000701@oracle.com> On 20/01/2012 14:54, Jesse Glick wrote: > On 01/20/2012 07:28 AM, Alan Bateman wrote: >>>> provides service S1 with S; >>>> provides service S2 with S; >> >> probably won't be too common (either S is an interface > > Impossible; it must be a concrete class. There was a typo in my mail, I meant that S1 may be an interface of course. > : > > (This does lead to a subtle point: currently ServiceProvider.load will > always instantiate a fresh copy of each service implementation class > every time you call it. This means that nonstatic fields in a S.I. > class, or an explicit constructor, are usually signs of a logic error. > In the above example, it means that client code would get a different > FrobnitzHandler instance for reading vs. for writing. I do not think > there is any reason to change this policy when SL is used in a modular > environment, but it should at least be documented whether SL > may/must/must not cache instances. This is especially true since a > system using dependency injection for the same purpose would likely > behave differently.) This is something that comes up from time to time and I think we'll need to support singleton services at some point. > >> I don't think the current spec mandates that the the service >> implementation have a public no-arg constructor. javac doesn't check >> for this >> currently so it's possible to get a ServiceConfigurationError at >> runtime for this case > > Seems like a defect in the spec. If there is some problem with the > signature of the service that can reliably be detected at compile > time, it should be treated as an error. Yes, I think so too. -Alan. From chris.hegarty at oracle.com Fri Jan 20 09:56:13 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 20 Jan 2012 17:56:13 +0000 Subject: native cmds and libs in the module library In-Reply-To: <4F166EB4.9060108@oracle.com> References: <4EE62FE1.70006@oracle.com> <4EEF597F.3030804@oracle.com> <4EEF6518.4060004@oracle.com> <4EF08A20.7030106@oracle.com> <4EF08C15.7060305@oracle.com> <4F071DDA.2040607@oracle.com> <4F0B71E8.2010104@oracle.com> <4F158596.2030306@oracle.com> <4F166EB4.9060108@oracle.com> Message-ID: <4F19AABD.90604@oracle.com> Thanks Mandy, You are correct. I was storing absolute paths. Updated webrev: http://cr.openjdk.java.net/~chegar/jigsaw/libbin_webrev.04/webrev/ - Paths to 'jmod create -L lib -natlib ...' are resolved relative to the current working dir, as you would expect. - natlib, natcmd, config, paths are stored relative to the module library root, in the libraries metadata. - The per module 'files' contains paths relative to the modules install directory. - I made most of the specific code suggestions you said, with the exception that natlibs, natcmds, and configs can still be null in SimpleLibrary. I use this to differentiate between a passed path and a per module path. -Chris. On 01/18/12 07:03 AM, Mandy Chung wrote: > On 1/17/2012 6:28 AM, Chris Hegarty wrote: > >> Here is an updated webrev based on the comments and feedback I received >> on this. >> >> - An additional option is added for supporting config files > If a relative path is specified as an argument to --natlib, --natbin, > or --config option, what is it relative to and what gets recorded > in the module library header? I believe the implementation currently > uses cwd (i.e. the directory where jmod install is invoked) which > means that we can't simply copy the module library and the natlibs > to a different location to use?? See my comment for Modules.gmk. > > >> http://cr.openjdk.java.net/~chegar/jigsaw/libbin_webrev.03/webrev/ > Modules.gmk > L141: --natlib $mlib/.. --natcmd $mlib/../../bin --config $$mlib/.. > > $mlib is an absolute path. Since these alt paths are recorded > in the module library header, if we zip up the jdk-module-image and > unzip it at a different location, these paths need fixup in order > to install new modules in it. It seems that we should keep > these paths relative to the system module library when creating > the jdk modules image. > > Similarly, the realpath of the files are stored in "files" > which would need fixup too which is not ideal. > > SimpleLibrary.java > L346-348: I wonder if it's cleaner to initialize these instance > variables to the default path, i.e. new File(root, "bin") if the > given argument is null so that the null check is not needed in > various place. > > L301: I think this warning should be output in the Librarian > implementation rather than in the SimpleLibrary. Instead > it should throw an exception if the natlibs is not writeable > and when it writes a native library. > > L1289: it's a good question when we should check the extension. > It depends if the specification requires the extension of a > module file be a specific value. I think we can leave as it > is and get back to it later. > > ModuleFile.java > L199-201: may be cleaner if these variables are initialized > to the default path e.g. File(destination, "lib") and the > non-null check in the getDirOfSection method will not be needed. > > L581-585: minor: since they are interested in 3 section types, > would it be better to handle each section type in this postExtract > method rather than checking the section type in both > markNativeCodeExecutable and trackFiles methods. Probably the > markNativeCodeExecutable method can be merged with this postExtract > method and remove L501-504 as well. > > Librarian.java > L55, 151: this comment line can be removed. > > hello-native.sh > It might be good to verify if the path of the native library > is expected. > > >> Issues I intend to address separately: >> >> - Separate out native libs and config files during the build, so they >> can be put into the right sections of the jmod file >> - Investigate the potential for global configuration files versus >> non-editable per-module config files. > > That's fine with me. > > Mandy > >> >> Thanks, >> -Chris. From alex.buckley at oracle.com Fri Jan 20 14:16:01 2012 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 20 Jan 2012 14:16:01 -0800 Subject: Jigsaw spec clarifications In-Reply-To: <4F1987A6.8000701@oracle.com> References: <4F189A23.3090101@oracle.com> <4F18B592.7020707@oracle.com> <4F195DD1.6000503@oracle.com> <4F198040.900@oracle.com> <4F1987A6.8000701@oracle.com> Message-ID: <4F19E7A1.2060703@oracle.com> On 1/20/2012 7:26 AM, Alan Bateman wrote: >> Seems like a defect in the spec. If there is some problem with the >> signature of the service that can reliably be detected at compile >> time, it should be treated as an error. > Yes, I think so too. I added compile-time requirements for a service implementation to be non-abstract, public, non-inner, and with a public no-args constructor. The module declarations doc on the Jigsaw project page should refresh soon. Alex From jonathan.gibbons at oracle.com Fri Jan 20 17:39:45 2012 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 20 Jan 2012 17:39:45 -0800 Subject: More jigsaw spec clarifications Message-ID: <4F1A1761.6050709@oracle.com> Thank you for the preceding round of discussion and spec-updates. The compile-time errors are all assertions that can be evaluated by examining an individual module declaration. Do you envisage specifying any compile-time errors arising from examining the set of observable module declarations. For example, the restriction on duplicate views within a module declaration could be extended to be a restriction on duplicate observable views. And, what about different modules trying to export the same package? Separately, in the restrictions on the class names for entry points and service implementations, is it expected that the class names must be declared in the module declaring the entry point or service, or can the class names be found in the (re-)exports of any of the required modules? -- Jon From Alan.Bateman at oracle.com Mon Jan 23 07:50:40 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 23 Jan 2012 15:50:40 +0000 Subject: Jigsaw spec clarifications In-Reply-To: <4F19E7A1.2060703@oracle.com> References: <4F189A23.3090101@oracle.com> <4F18B592.7020707@oracle.com> <4F195DD1.6000503@oracle.com> <4F198040.900@oracle.com> <4F1987A6.8000701@oracle.com> <4F19E7A1.2060703@oracle.com> Message-ID: <4F1D81D0.3060104@oracle.com> On 20/01/2012 22:16, Alex Buckley wrote: > > I added compile-time requirements for a service implementation to be > non-abstract, public, non-inner, and with a public no-args > constructor. The module declarations doc on the Jigsaw project page > should refresh soon. I see the updates - thanks. -Alan. From Alan.Bateman at oracle.com Mon Jan 23 07:56:20 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 23 Jan 2012 15:56:20 +0000 Subject: More jigsaw spec clarifications In-Reply-To: <4F1A1761.6050709@oracle.com> References: <4F1A1761.6050709@oracle.com> Message-ID: <4F1D8324.5030903@oracle.com> On 21/01/2012 01:39, Jonathan Gibbons wrote: > > Separately, in the restrictions on the class names for entry points > and service implementations, is it expected that the class names must > be declared in the module declaring the entry point or service, or can > the class names be found in the (re-)exports of any of the required > modules? I don't think this make a differences for services, unless permits is used. -Alan. From jesse.glick at oracle.com Mon Jan 23 10:04:27 2012 From: jesse.glick at oracle.com (Jesse Glick) Date: Mon, 23 Jan 2012 13:04:27 -0500 Subject: Missing ElementKind.MODULE Message-ID: <4F1DA12B.9080502@oracle.com> It seems that there is TypeKind.MODULE but not ElementKind.MODULE in the language model APIs. Symbol.ModuleSymbol looks like it would return ElementKind.TYPE_PARAMETER. Oversight? From jonathan.gibbons at oracle.com Mon Jan 23 10:10:43 2012 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 23 Jan 2012 10:10:43 -0800 Subject: Missing ElementKind.MODULE In-Reply-To: <4F1DA12B.9080502@oracle.com> References: <4F1DA12B.9080502@oracle.com> Message-ID: <4F1DA2A3.4080106@oracle.com> On 01/23/2012 10:04 AM, Jesse Glick wrote: > It seems that there is TypeKind.MODULE but not ElementKind.MODULE in > the language model APIs. Symbol.ModuleSymbol looks like it would > return ElementKind.TYPE_PARAMETER. Oversight? We've not focussed any on the javax.lang.model aspects of Jigsaw yet, and the contents of a ModuleElement in particular. I'll fix the ElementKind.MODULE for now. -- Jon From jesse.glick at oracle.com Mon Jan 23 10:16:06 2012 From: jesse.glick at oracle.com (Jesse Glick) Date: Mon, 23 Jan 2012 13:16:06 -0500 Subject: SIGSEGV Message-ID: <4F1DA3E6.9000407@oracle.com> Just a note about the version of HotSpot currently in Jigsaw builds: it gives me a SIGSEGV when I try to run NetBeans 7.1 under this VM: SIGSEGV (0xb) at pc=0x00007f195c1d042e, pid=5515, tid=139746790463232 JRE version: 8.0 Java VM: OpenJDK 64-Bit Server VM (23.0-b06 mixed mode linux-amd64 compressed oops) Stack: [0x00007f1955bdd000,0x00007f1955cde000], sp=0x00007f1955cd87e0, free space=1005k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x60f42e] PhaseIdealLoop::build_loop_late_post(Node*)+0x14e V [libjvm.so+0x611023] PhaseIdealLoop::build_and_optimize(bool, bool)+0xab3 V [libjvm.so+0x384eaa] Compile::Optimize()+0x2ea V [libjvm.so+0x387912] Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, int, bool, bool)+0xbb2 V [libjvm.so+0x302a50] C2Compiler::compile_method(ciEnv*, ciMethod*, int)+0xe0 V [libjvm.so+0x38c379] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x2f9 V [libjvm.so+0x38cd9b] CompileBroker::compiler_thread_loop()+0x42b V [libjvm.so+0x7d11b0] JavaThread::thread_main_inner()+0xc0 V [libjvm.so+0x6b2fe2] java_start(Thread*)+0x132 Current CompileTask: C2: 45698 722 org.netbeans.core.startup.layers.BinaryFS::findResource (58 bytes) This goes away with -Xint. Maybe some regression introduced upstream in JDK 8. From Alan.Bateman at oracle.com Mon Jan 23 10:20:44 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 23 Jan 2012 18:20:44 +0000 Subject: SIGSEGV In-Reply-To: <4F1DA3E6.9000407@oracle.com> References: <4F1DA3E6.9000407@oracle.com> Message-ID: <4F1DA4FC.8050205@oracle.com> On 23/01/2012 18:16, Jesse Glick wrote: > Just a note about the version of HotSpot currently in Jigsaw builds: > it gives me a SIGSEGV when I try to run NetBeans 7.1 under this VM: > > SIGSEGV (0xb) at pc=0x00007f195c1d042e, pid=5515, tid=139746790463232 > JRE version: 8.0 > Java VM: OpenJDK 64-Bit Server VM (23.0-b06 mixed mode linux-amd64 > compressed oops) > Stack: [0x00007f1955bdd000,0x00007f1955cde000], > sp=0x00007f1955cd87e0, free space=1005k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, > C=native code) > V [libjvm.so+0x60f42e] > PhaseIdealLoop::build_loop_late_post(Node*)+0x14e > V [libjvm.so+0x611023] PhaseIdealLoop::build_and_optimize(bool, > bool)+0xab3 > V [libjvm.so+0x384eaa] Compile::Optimize()+0x2ea > V [libjvm.so+0x387912] Compile::Compile(ciEnv*, C2Compiler*, > ciMethod*, int, bool, bool)+0xbb2 > V [libjvm.so+0x302a50] C2Compiler::compile_method(ciEnv*, ciMethod*, > int)+0xe0 > V [libjvm.so+0x38c379] > CompileBroker::invoke_compiler_on_method(CompileTask*)+0x2f9 > V [libjvm.so+0x38cd9b] CompileBroker::compiler_thread_loop()+0x42b > V [libjvm.so+0x7d11b0] JavaThread::thread_main_inner()+0xc0 > V [libjvm.so+0x6b2fe2] java_start(Thread*)+0x132 > Current CompileTask: > C2: 45698 722 > org.netbeans.core.startup.layers.BinaryFS::findResource (58 bytes) > > This goes away with -Xint. Maybe some regression introduced upstream > in JDK 8. The stack trace suggests it may be C2 issue. JDK8 is up to hs23-b10 but we will catch up at the next re-sync. -Alan From jesse.glick at oracle.com Mon Jan 23 11:03:14 2012 From: jesse.glick at oracle.com (Jesse Glick) Date: Mon, 23 Jan 2012 14:03:14 -0500 Subject: jigsaw.resolver.error trying to compile hello world Message-ID: <4F1DAEF2.5060609@oracle.com> jigsaw$ ./build/linux-amd64/jdk-module-image/bin/javac -d /tmp jdk/src/solaris/demo/jigsaw/basic/src/module-info.java error: Cannot resolve module dependencies using Jigsaw module resolver org.hello@=1: Cannot resolve 1 error I think you need: jigsaw$ hg -R jdk di diff --git a/src/solaris/demo/jigsaw/basic/src/module-info.java b/src/solaris/demo/jigsaw/basic/src/module-info.java --- a/src/solaris/demo/jigsaw/basic/src/module-info.java +++ b/src/solaris/demo/jigsaw/basic/src/module-info.java @@ -24,7 +24,7 @@ */ module org.hello @ 1 { - requires jdk.base @ 7-ea; + requires jdk.base @ 8-ea; class org.hello.Main; // Main class } though this is pretty poor error reporting. From Alan.Bateman at oracle.com Mon Jan 23 11:07:53 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 23 Jan 2012 19:07:53 +0000 Subject: jigsaw.resolver.error trying to compile hello world In-Reply-To: <4F1DAEF2.5060609@oracle.com> References: <4F1DAEF2.5060609@oracle.com> Message-ID: <4F1DB009.6010107@oracle.com> On 23/01/2012 19:03, Jesse Glick wrote: > jigsaw$ ./build/linux-amd64/jdk-module-image/bin/javac -d /tmp > jdk/src/solaris/demo/jigsaw/basic/src/module-info.java > error: Cannot resolve module dependencies using Jigsaw module resolver > org.hello@=1: Cannot resolve > 1 error > > I think you need: > > jigsaw$ hg -R jdk di > diff --git a/src/solaris/demo/jigsaw/basic/src/module-info.java > b/src/solaris/demo/jigsaw/basic/src/module-info.java > --- a/src/solaris/demo/jigsaw/basic/src/module-info.java > +++ b/src/solaris/demo/jigsaw/basic/src/module-info.java > @@ -24,7 +24,7 @@ > */ > > module org.hello @ 1 { > - requires jdk.base @ 7-ea; > + requires jdk.base @ 8-ea; > class org.hello.Main; // Main class > } > > though this is pretty poor error reporting. The demo/sample was an oversight - thanks. On the diagnostics then we know this requires work, hopefully in the next few months as the rest of the core functionality is added. -Alan. From alex.buckley at oracle.com Mon Jan 23 11:10:27 2012 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 23 Jan 2012 11:10:27 -0800 Subject: More jigsaw spec clarifications In-Reply-To: <4F1A1761.6050709@oracle.com> References: <4F1A1761.6050709@oracle.com> Message-ID: <4F1DB0A3.1070007@oracle.com> On 1/20/2012 5:39 PM, Jonathan Gibbons wrote: > Do you envisage specifying any compile-time errors arising from > examining the set of observable module declarations. For example, the > restriction on duplicate views within a module declaration could be > extended to be a restriction on duplicate observable views. And, what > about different modules trying to export the same package? It would be nice if the module system was responsible for detecting inter-declaration errors while the compiler sticks to intra-declaration errors. The module system already has the logic for finding different modules (within a dependency graph) exporting the same package, so why should a compiler duplicate it for source-form declarations? Perhaps this comes down to the interface between compiler and module system. Will be a sketch of how javac's interaction with the classpath is modified to work with Jigsaw? Alex From jonathan.gibbons at oracle.com Mon Jan 23 11:28:05 2012 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 23 Jan 2012 11:28:05 -0800 Subject: More jigsaw spec clarifications In-Reply-To: <4F1DB0A3.1070007@oracle.com> References: <4F1A1761.6050709@oracle.com> <4F1DB0A3.1070007@oracle.com> Message-ID: <4F1DB4C5.2090101@oracle.com> On 01/23/2012 11:10 AM, Alex Buckley wrote: > It would be nice if the module system was responsible for detecting > inter-declaration errors while the compiler sticks to > intra-declaration errors. > > The module system already has the logic for finding different modules > (within a dependency graph) exporting the same package, so why should > a compiler duplicate it for source-form declarations? Perhaps this > comes down to the interface between compiler and module system. Will > be a sketch of how javac's interaction with the classpath is modified > to work with Jigsaw? It would be nice if the module system had more than one error message: "Cannot resolve". I know it is on the list to fix that, but I was trying to work on the common and easy cases. Anyway, you changed the subject to one of implementation detail. I was asking about the spec :-) Where should I look for specification details about the restrictions on duplicate names in the module graph. -- Jon From alex.buckley at oracle.com Mon Jan 23 11:40:38 2012 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 23 Jan 2012 11:40:38 -0800 Subject: More jigsaw spec clarifications In-Reply-To: <4F1DB4C5.2090101@oracle.com> References: <4F1A1761.6050709@oracle.com> <4F1DB0A3.1070007@oracle.com> <4F1DB4C5.2090101@oracle.com> Message-ID: <4F1DB7B6.4090000@oracle.com> On 1/23/2012 11:28 AM, Jonathan Gibbons wrote: > Anyway, you changed the subject to one of implementation detail. I was > asking about the spec :-) Where should I look for specification details > about the restrictions on duplicate names in the module graph. Doesn't the "big picture" draft on the Jigsaw project page have assertions sprinkled throughout? Or the javadoc for java.lang.module or its org.openjdk.jigsaw counterpart? Alex From jesse.glick at oracle.com Mon Jan 23 11:46:44 2012 From: jesse.glick at oracle.com (Jesse Glick) Date: Mon, 23 Jan 2012 14:46:44 -0500 Subject: JavacTask limitations Message-ID: <4F1DB924.2010301@oracle.com> When passed module-info.java, JavacTask.parse() will return a CompilationUnitTree with a ModuleTree inside it as expected; but analyze() will return an empty list. From jonathan.gibbons at oracle.com Mon Jan 23 11:55:05 2012 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 23 Jan 2012 11:55:05 -0800 Subject: More jigsaw spec clarifications In-Reply-To: <4F1DB7B6.4090000@oracle.com> References: <4F1A1761.6050709@oracle.com> <4F1DB0A3.1070007@oracle.com> <4F1DB4C5.2090101@oracle.com> <4F1DB7B6.4090000@oracle.com> Message-ID: <4F1DBB19.6090502@oracle.com> On 01/23/2012 11:40 AM, Alex Buckley wrote: > On 1/23/2012 11:28 AM, Jonathan Gibbons wrote: >> Anyway, you changed the subject to one of implementation detail. I was >> asking about the spec :-) Where should I look for specification details >> about the restrictions on duplicate names in the module graph. > > Doesn't the "big picture" draft on the Jigsaw project page have > assertions sprinkled throughout? Or the javadoc for java.lang.module > or its org.openjdk.jigsaw counterpart? > > Alex "Big picture" is not intended to be a spec is it? I'll check the javadocs you mention. Presumably, "it is a compile-time error if the set of modules cannot be resolved by ..." By whom? The host system? The system module resolver? The Jigsaw module resolver? -- Jon From alex.buckley at oracle.com Mon Jan 23 12:00:09 2012 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 23 Jan 2012 12:00:09 -0800 Subject: More jigsaw spec clarifications In-Reply-To: <4F1DBB19.6090502@oracle.com> References: <4F1A1761.6050709@oracle.com> <4F1DB0A3.1070007@oracle.com> <4F1DB4C5.2090101@oracle.com> <4F1DB7B6.4090000@oracle.com> <4F1DBB19.6090502@oracle.com> Message-ID: <4F1DBC49.1080207@oracle.com> On 1/23/2012 11:55 AM, Jonathan Gibbons wrote: > Presumably, "it is a compile-time error if the set of modules cannot be > resolved by ..." By whom? The host system? The system module resolver? > The Jigsaw module resolver? Given that the language in SE 8 can assume the presence of a module system, we could distinguish in the JLS between a compiler and a resolver. I don't really expect it will be useful to do so, however. But perhaps experience with how the R.I. compiler talks to the R.I. module system will inform this. Alex From jonathan.gibbons at oracle.com Mon Jan 23 12:25:05 2012 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 23 Jan 2012 12:25:05 -0800 Subject: More jigsaw spec clarifications In-Reply-To: <4F1DBC49.1080207@oracle.com> References: <4F1A1761.6050709@oracle.com> <4F1DB0A3.1070007@oracle.com> <4F1DB4C5.2090101@oracle.com> <4F1DB7B6.4090000@oracle.com> <4F1DBB19.6090502@oracle.com> <4F1DBC49.1080207@oracle.com> Message-ID: <4F1DC221.5080208@oracle.com> On 01/23/2012 12:00 PM, Alex Buckley wrote: > On 1/23/2012 11:55 AM, Jonathan Gibbons wrote: >> Presumably, "it is a compile-time error if the set of modules cannot be >> resolved by ..." By whom? The host system? The system module resolver? >> The Jigsaw module resolver? > > Given that the language in SE 8 can assume the presence of a module > system, we could distinguish in the JLS between a compiler and a > resolver. I don't really expect it will be useful to do so, however. > But perhaps experience with how the R.I. compiler talks to the R.I. > module system will inform this. > > Alex Currently, javac calls org.openjdk.jigsaw.Configurator.configurePaths passing an impl of org.openjdk.jigsaw.Catalog containing the module info known to javac. -- Jon From jonathan.gibbons at oracle.com Mon Jan 23 17:57:18 2012 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 23 Jan 2012 17:57:18 -0800 Subject: spec clarification: empty default view Message-ID: <4F1E0FFE.5040605@oracle.com> In a ModuleProvides_attribute, does there have to be an entry for the default view, even it it would be completely empty? -- Jon From alex.buckley at oracle.com Mon Jan 23 18:15:22 2012 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 23 Jan 2012 18:15:22 -0800 Subject: spec clarification: empty default view In-Reply-To: <4F1E0FFE.5040605@oracle.com> References: <4F1E0FFE.5040605@oracle.com> Message-ID: <4F1E143A.8070906@oracle.com> On 1/23/2012 5:57 PM, Jonathan Gibbons wrote: > In a ModuleProvides_attribute, does there have to be an entry for the > default view, even it it would be completely empty? Attributes should only store what exists. The language and the module system might well say there is logically a default view which is empty, but we traditionally don't "do" dummy attributes with zero-length tables in the ClassFile. (A ClassFile format checker must be able to handle them, but a Java compiler is not obligated to produce it.) So, if a module declaration consists of just 'requires' clauses and exports nothing, has no aliases, no friends, and no entrypoint, then I would say no ModuleProvides attribute is needed at all. Adding one non-default view to that module declaration would prompt a ModuleProvides attribute, but I don't think a default view needs to spring into the physical representation too. Each physical view is standalone in ModuleProvides. Alex From mandy.chung at oracle.com Mon Jan 23 20:16:14 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 23 Jan 2012 20:16:14 -0800 Subject: native cmds and libs in the module library In-Reply-To: <4F19AABD.90604@oracle.com> References: <4EE62FE1.70006@oracle.com> <4EEF597F.3030804@oracle.com> <4EEF6518.4060004@oracle.com> <4EF08A20.7030106@oracle.com> <4EF08C15.7060305@oracle.com> <4F071DDA.2040607@oracle.com> <4F0B71E8.2010104@oracle.com> <4F158596.2030306@oracle.com> <4F166EB4.9060108@oracle.com> <4F19AABD.90604@oracle.com> Message-ID: <4F1E308E.9070408@oracle.com> Thanks, Chris. This looks much better. Modules.gmk L141: I would suggest to replace "$$mlib/.." with "$(MODULE_IMAGES_DIR)/$$image/bin" to make the path explicit and similarly for "$$mlib/../../bin". Perhaps define a new variable for the root "$(MODULE_IMAGES_DIR)/$$image" would help. L191: since the jmod files have been created, do we really need L195-197? SimpleLibrary.java L228-232: should they be final fields? ModuleFile.java L295: extra blank line. Mandy On 1/20/2012 9:56 AM, Chris Hegarty wrote: > Thanks Mandy, > > You are correct. I was storing absolute paths. > > Updated webrev: > http://cr.openjdk.java.net/~chegar/jigsaw/libbin_webrev.04/webrev/ > > - Paths to 'jmod create -L lib -natlib ...' are resolved > relative to the current working dir, as you would expect. > - natlib, natcmd, config, paths are stored relative to the module > library root, in the libraries metadata. > - The per module 'files' contains paths relative to the modules > install directory. > > - I made most of the specific code suggestions you said, with the > exception that natlibs, natcmds, and configs can still be null > in SimpleLibrary. I use this to differentiate between a passed > path and a per module path. > > -Chris. > > On 01/18/12 07:03 AM, Mandy Chung wrote: >> On 1/17/2012 6:28 AM, Chris Hegarty wrote: >> >>> Here is an updated webrev based on the comments and feedback I received >>> on this. >>> >>> - An additional option is added for supporting config files >> If a relative path is specified as an argument to --natlib, --natbin, >> or --config option, what is it relative to and what gets recorded >> in the module library header? I believe the implementation currently >> uses cwd (i.e. the directory where jmod install is invoked) which >> means that we can't simply copy the module library and the natlibs >> to a different location to use?? See my comment for Modules.gmk. >> >> >>> http://cr.openjdk.java.net/~chegar/jigsaw/libbin_webrev.03/webrev/ >> Modules.gmk >> L141: --natlib $mlib/.. --natcmd $mlib/../../bin --config $$mlib/.. >> >> $mlib is an absolute path. Since these alt paths are recorded >> in the module library header, if we zip up the jdk-module-image and >> unzip it at a different location, these paths need fixup in order >> to install new modules in it. It seems that we should keep >> these paths relative to the system module library when creating >> the jdk modules image. >> >> Similarly, the realpath of the files are stored in "files" >> which would need fixup too which is not ideal. >> >> SimpleLibrary.java >> L346-348: I wonder if it's cleaner to initialize these instance >> variables to the default path, i.e. new File(root, "bin") if the >> given argument is null so that the null check is not needed in >> various place. >> >> L301: I think this warning should be output in the Librarian >> implementation rather than in the SimpleLibrary. Instead >> it should throw an exception if the natlibs is not writeable >> and when it writes a native library. >> >> L1289: it's a good question when we should check the extension. >> It depends if the specification requires the extension of a >> module file be a specific value. I think we can leave as it >> is and get back to it later. >> >> ModuleFile.java >> L199-201: may be cleaner if these variables are initialized >> to the default path e.g. File(destination, "lib") and the >> non-null check in the getDirOfSection method will not be needed. >> >> L581-585: minor: since they are interested in 3 section types, >> would it be better to handle each section type in this postExtract >> method rather than checking the section type in both >> markNativeCodeExecutable and trackFiles methods. Probably the >> markNativeCodeExecutable method can be merged with this postExtract >> method and remove L501-504 as well. >> >> Librarian.java >> L55, 151: this comment line can be removed. >> >> hello-native.sh >> It might be good to verify if the path of the native library >> is expected. >> >> >>> Issues I intend to address separately: >>> >>> - Separate out native libs and config files during the build, so they >>> can be put into the right sections of the jmod file >>> - Investigate the potential for global configuration files versus >>> non-editable per-module config files. >> >> That's fine with me. >> >> Mandy >> >>> >>> Thanks, >>> -Chris. From reinier at zwitserloot.com Mon Jan 23 23:38:09 2012 From: reinier at zwitserloot.com (Reinier Zwitserloot) Date: Tue, 24 Jan 2012 08:38:09 +0100 Subject: State of jigsaw: Description of module file format? Message-ID: I noticed this document: http://cr.openjdk.java.net/~mr/jigsaw/notes/jigsaw-big-picture-01 Does not cover the module file format. A friend asked if the module format (insofar as what is planned right now) includes room to put the source (and possibly, javadoc, license, etc) in the module to ease the ability of tools like an IDE to offer utility like popping up javadoc, letting you view the source of a library call, etc. ... and, I can't remember if it does or not. --Reinier Zwitserloot From jesse.glick at oracle.com Tue Jan 24 03:02:20 2012 From: jesse.glick at oracle.com (Jesse Glick) Date: Tue, 24 Jan 2012 06:02:20 -0500 Subject: lib/dt.jar Message-ID: <4F1E8FBC.5080702@oracle.com> This JAR seems to have been dropped from Jigsaw builds, at least mine; perhaps jdk/make/javax/swing/beaninfo/Makefile was never called. Anyway this horrible makefile could probably be replaced with a 269-based processor (*). Where should classes like javax.swing.JTableBeanInfo go? More generally, how will java.beans.Introspector's search path work under Jigsaw, especially in "design-time" mode? (*) Which leads me to another question which I will post separately. From jesse.glick at oracle.com Tue Jan 24 03:02:37 2012 From: jesse.glick at oracle.com (Jesse Glick) Date: Tue, 24 Jan 2012 06:02:37 -0500 Subject: -processorpath & META-INF/services/javax.annotation.processing.Processor Message-ID: <4F1E8FCD.5070604@oracle.com> I have not seen any mention of how Jigsaw will load 269-compliant annotation processors. First of all, if the processor is bundled with the annotation(s) it processes, which is common, and registered in ServiceLoader fashion, then you would expect that just requiring that module would suffice to run the processor on your code. This in fact works today in JDK 6 and 7 if you use javac. Frustratingly, the Processor Javadoc is evasive on the subject, claiming that it is up to the "tool", and Eclipse's compiler does not honor this convention. [1] It would be nice if 269 + Jigsaw could say definitively that if module A provides javax.annotation.processing.Processor with some processor impl, then compilation of a module requiring A will run that processor if there are matching annotations (*). Second, for cases where it is undesirable or impossible to collocate the processor with its supported annotations, there needs to be some way for a module using the annotations to explicitly request that this processor be run. -processorpath works in older JDKs, but this is contrary to the style of modulepath. I would expect some module-info.java declaration such as requires processor proc.module.name @ 1.0; which would produce no runtime dep compiled into module-info.class, and (like -processorpath) would not expose any public types from proc.module.name, but would check proc.module.name for provided Processor's. Less commonly, you might need a syntax for invoking particular processors by class name and/or passing processor arguments. Of course you can add -processor/-A to the javac command line, but this is most suitable when running the processor for some one-off purpose like static analysis. If the processor is needed by the module sources (for error checking on annotations, generating resources, and/or generating classes) then it would be more appropriate for this configuration to be permanently declared in module-info.java. (*) Unlike some service locator frameworks, ServiceLoader is incapable of lazily loading services matching some declarative pattern, which can affect client application startup time - and in the case of Processor, compilation time. In the NetBeans source base we have around 37 processors registered in SL style, and a single module's classpath might well contain a dozen or more. Each of these classes must be loaded (possibly triggering loading of related classes) just to call getSupportedAnnotationTypes, even though this metadata is almost always static and most available processors will not be needed. [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=280542 From Alan.Bateman at oracle.com Tue Jan 24 03:09:59 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 24 Jan 2012 11:09:59 +0000 Subject: lib/dt.jar In-Reply-To: <4F1E8FBC.5080702@oracle.com> References: <4F1E8FBC.5080702@oracle.com> Message-ID: <4F1E9187.2080601@oracle.com> On 24/01/2012 11:02, Jesse Glick wrote: > This JAR seems to have been dropped from Jigsaw builds, at least mine; > perhaps jdk/make/javax/swing/beaninfo/Makefile was never called. > Anyway this horrible makefile could probably be replaced with a > 269-based processor (*). > > Where should classes like javax.swing.JTableBeanInfo go? More > generally, how will java.beans.Introspector's search path work under > Jigsaw, especially in "design-time" mode? > > (*) Which leads me to another question which I will post separately. I was chatting with Jan Lahoda about this a few days ago and he had to copy it from a jdk8 build to get the NB editor working. We don't done anything about the bean info classes yet but that will be resolved in time. Also remember that there is a completely new build project in the works for jdk8 so that will eventually replace all these make files. Also there is still a lot of development to be done on Jigsaw and there will be many issues until everything is done. -Alan. From jesse.glick at oracle.com Tue Jan 24 04:07:29 2012 From: jesse.glick at oracle.com (Jesse Glick) Date: Tue, 24 Jan 2012 07:07:29 -0500 Subject: -encoding and -source in module-info.java Message-ID: <4F1E9F01.1090809@oracle.com> The encoding and source level of a module are fundamental attributes of its sources, without which you cannot reliably even parse a syntax tree, so I think they should be declared in module-info.java. Otherwise it is left up to someone calling javac by hand, or a build script, to specify these options; that is potentially error-prone, and means that tools which inspect sources (including but not limited to IDEs) need to have some separate mechanism for configuration of these attributes: you cannot just hand them the sourcepath and let them run. I am assuming that all files in the sourcepath use the same encoding and source level, which seems a reasonable restriction. As to the source level, obviously given that JDK 8 will introduce module-info.java, "8" (or "1.8") seems like the right default value; but a syntax ought to be defined for specifying a newer level, e.g. source 1.9; // or 9? Furthermore I think that JDK 9+ versions of javac should keep the same default source level - you should need to explicitly mark what version of the Java language your module expects. Otherwise a module might compile differently according to which version of javac was used, which is undesirable, and tools cannot guess what version you meant. A little more verbosity here seems to be justified. Whether the bytecode target (-target) should be specified in module-info.java is another question. I have seen projects built using -target 5 for JDK 5 compatibility but also in a separate artifact using -target 6 for speed on JDK 6+ (split verifier). Probably the target level should default to the source level, and in the rare case that you need to override this, you can do so using a javac command option - this has no impact on tools which just need to parse and analyze source files. As to the encoding, something like encoding ISO-8859-2; would suffice. The obvious problems for encoding are 1. What should the default value be? javac currently uses the platform default encoding, which IMHO is a horrible choice because it means that two people running javac with the same parameters on the same files may be producing different classes and/or warning messages. I would suggest making UTF-8 be the default when compiling in module mode (leaving the old behavior intact for legacy mode). For developers who want to keep sources in a different character set, adding one line per module-info.java does not seem like much of a burden. 2. What is module-info.java itself encoded in? If not UTF-8, then you need to be able to reliably find the encoding declaration and then rescan the file in that encoding. That is easy for most encodings (just do an initial scan in ISO-8859-1), including everything commonly used by developers AFAIK; a little trickier for UTF-16/32-type encodings but possible by ignoring 0x00/0xFE/0xFF; and only fails on some mainframe charsets, old JIS variants, and dingbats (*). Even those rare cases are probably guessable. [1] (*) Demo program: import java.io.UnsupportedEncodingException; import java.nio.charset.Charset; import java.util.Arrays; public class CharsetTest { public static void main(String[] args) throws UnsupportedEncodingException { Charset raw = Charset.forName("ISO-8859-1"); for (Charset c : Charset.availableCharsets().values()) { String text = "/* leading comment */\nmodule test {\n encoding " + c.name() + ";\n}\n"; byte[] encoded; try { encoded = text.getBytes(c); } catch (UnsupportedOperationException x) { System.out.println("cannot encode using " + c.name()); continue; } if (Arrays.equals(encoded, text.getBytes(raw))) { System.out.println("OK in " + c.name()); } else if (new String(encoded, raw).contains(" encoding " + c.name() + ";")) { System.out.println("substring match in " + c.name()); dump(encoded); } else if (new String(encoded, raw).replace("\u0000", "").contains(" encoding " + c.name() + ";")) { System.out.println("NUL-stripped match in " + c.name()); dump(encoded); } else { System.out.println("garbled in " + c.name()); dump(encoded); } } } private static void dump(byte[] encoded) { for (byte b : encoded) { if (b >= 32 && b <= 126 || b == '\n' || b == '\r') { System.out.write(b); } else if (b == 0) { System.out.print('@'); } else { System.out.printf("\\%02X", b); } } System.out.println(); } private CharsetTest() {} } [1] http://jchardet.sourceforge.net/ From mikhail.ershov at oracle.com Tue Jan 24 05:37:48 2012 From: mikhail.ershov at oracle.com (Mike Ershov) Date: Tue, 24 Jan 2012 16:37:48 +0300 Subject: Questions about jigsaw API Message-ID: <4F1EB42C.5080103@oracle.com> Hello, I'm adapting sigtest tool ( sigtest.java.net ) to jigsaw and have some questions about jigsaw API: 1) I need to read class bytes for any particular class and all its dependencies. In other words for module com.acme.mod at 3.1 I have to analyze com.acme.mod at 3.1's classes, their superclasses from other com.acme.* modules recursively and their platform superclasses including java.lang.Object. Maybe I missed something but I can't find easy way to do it. So I resolve all dependencies manually. This is my the main question. I very appreciate any recommendations. 2) org.openjdk.jigsaw.Library byte[] readClass(ModuleId mid, java.lang.String className) according to the javadoc "reads the class bytes of the given class within the given module, in this library or in a parent library." But actually it doesn't read a parent library. Please correct the description or, better, add this functionality. 3) I expected that SimpleLibrary.openSystemLibrary().readClass(Platform.bootModule(), "java.lang.Object") returns Object's bytes. It returns null because Platform.bootModule() is "jdk.base at 8-ea" instead of "jdk.boot at 8-ea". 4) I noticed that public org.openjdk.jigsaw.LoaderPool has no public constructors. If there is no reasons for such design it's better to do it not public ( like LibraryPool ) or make them all public. Thanks in advance, Mike From mikhail.ershov at oracle.com Tue Jan 24 05:40:05 2012 From: mikhail.ershov at oracle.com (Mike Ershov) Date: Tue, 24 Jan 2012 16:40:05 +0300 Subject: Javac ignores module-info dependencies Message-ID: <4F1EB4B5.40009@oracle.com> Hello, I noticed that javac does not take requires part of module-info as compile class path. Is it correct behavior? I have sources for two modules under one source root - m1 and m2. m2 uses class from m1 but m2's module-info has no "requires m1" statement. I expected compile-time error, but a compilation is successful and I see runtime error. The code is attached. Sorry in advance if this is known issue. Thanks, Mike From Alan.Bateman at oracle.com Tue Jan 24 06:15:56 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 24 Jan 2012 14:15:56 +0000 Subject: native cmds and libs in the module library In-Reply-To: <4F19AABD.90604@oracle.com> References: <4EE62FE1.70006@oracle.com> <4EEF597F.3030804@oracle.com> <4EEF6518.4060004@oracle.com> <4EF08A20.7030106@oracle.com> <4EF08C15.7060305@oracle.com> <4F071DDA.2040607@oracle.com> <4F0B71E8.2010104@oracle.com> <4F158596.2030306@oracle.com> <4F166EB4.9060108@oracle.com> <4F19AABD.90604@oracle.com> Message-ID: <4F1EBD1C.3020607@oracle.com> On 20/01/2012 17:56, Chris Hegarty wrote: > Thanks Mandy, > > You are correct. I was storing absolute paths. > > Updated webrev: > http://cr.openjdk.java.net/~chegar/jigsaw/libbin_webrev.04/webrev/ > > - Paths to 'jmod create -L lib -natlib ...' are resolved > relative to the current working dir, as you would expect. > - natlib, natcmd, config, paths are stored relative to the module > library root, in the libraries metadata. > - The per module 'files' contains paths relative to the modules > install directory. > > - I made most of the specific code suggestions you said, with the > exception that natlibs, natcmds, and configs can still be null > in SimpleLibrary. I use this to differentiate between a passed > path and a per module path. > > -Chris. I think this quite good. Can you briefly summarize how one would use this on Windows? I assume it requires specifying the --natcmd and --natlib to be the same directory. In the simple library layout I added a flags word some time ago and it has many spare bits. Rather than storing 0 or 1 before each path then an alternative would be to use some of the spare bits. A minor nit but the code style with if-then-else is a bit inconsistent. SimpleLibrary.storePath, SimpleLibrary.resolveAndEnsurePath, Librarian.Create.go are just a couple of examples that jump out (there are many more). A general comment is that we'll need to go over this again once we get to clean-up the implementation, improve performance, make library operations atomic, etc. I mention this because what we have now is a bit inefficient and there's also quite a bit of hopping between new and old APIs. It will need a major clean-up at some point. On the tests then I think an important test to include is a test that attempts to install a library or binary outside of the bin and lib trees. I think the validation code that you've added will catch this but I think a test is important. -Alan. From mikhail.ershov at oracle.com Tue Jan 24 07:17:00 2012 From: mikhail.ershov at oracle.com (Mike Ershov) Date: Tue, 24 Jan 2012 18:17:00 +0300 Subject: Javac ignores module-info dependencies In-Reply-To: <4F1EB4B5.40009@oracle.com> References: <4F1EB4B5.40009@oracle.com> Message-ID: <4F1ECB6C.9000903@oracle.com> Sorry for inconvenience, trying to resend with attachment. Mike Mike Ershov wrote: > Hello, > > I noticed that javac does not take requires part of module-info as > compile class path. Is it correct behavior? > I have sources for two modules under one source root - > m1 and m2. m2 uses class from m1 but m2's module-info has no "requires > m1" statement. I expected compile-time error, but a compilation is > successful and I see runtime error. The code is attached. > > Sorry in advance if this is known issue. > > Thanks, > Mike > From mikhail.ershov at oracle.com Tue Jan 24 07:36:14 2012 From: mikhail.ershov at oracle.com (Mike Ershov) Date: Tue, 24 Jan 2012 18:36:14 +0300 Subject: Javac ignores module-info dependencies In-Reply-To: <4F1ECB6C.9000903@oracle.com> References: <4F1EB4B5.40009@oracle.com> <4F1ECB6C.9000903@oracle.com> Message-ID: <4F1ECFEE.2040908@oracle.com> Sorry again, attachments are prohibited here. The code: ==== files ./make.sh ./srcmod/mod2/p2/Main.java ./srcmod/mod2/module-info.java ./srcmod/mod1/p1/C.java ./srcmod/mod1/module-info.java ==== make.sh #!/bin/sh JIGSAW=/opt/java/j8/bin SRC=srcmod/ rm -rf classes mkdir classes rm -rf mlib $JIGSAW/jmod create -L mlib $JIGSAW/javac -d classes -modulepath mlib -sourcepath $SRC `find $SRC -name '*.java'` $JIGSAW/jpkg -m classes/mod1 jmod mod1 $JIGSAW/jpkg -m classes/mod2 jmod mod2 $JIGSAW/jmod install -L mlib mod1 at 1.0.jmod $JIGSAW/jmod install -L mlib mod2 at 1.0.jmod $JIGSAW/java -L mlib -m mod2 ==== srcmod/mod1/module-info.java module mod1 @1.0 { requires jdk.base; } ==== srcmod/mod1/p1/C.java package p1; public class C { public void say() { System.out.println("Hello, bug!"); } } ==== srcmod/mod2/module-info.java module mod2 @1.0 { requires jdk.base; class p2.Main; } ==== srcmod/mod2/p2/Main.java package p2; import p1.C; public class Main { public static void main(String[] args) { new C().say(); } } Mike Ershov wrote: > Sorry for inconvenience, trying to resend with attachment. > > Mike > > Mike Ershov wrote: >> Hello, >> >> I noticed that javac does not take requires part of module-info as >> compile class path. Is it correct behavior? >> I have sources for two modules under one source root - >> m1 and m2. m2 uses class from m1 but m2's module-info has no "requires >> m1" statement. I expected compile-time error, but a compilation is >> successful and I see runtime error. The code is attached. >> >> Sorry in advance if this is known issue. >> >> Thanks, >> Mike >> > From Alan.Bateman at oracle.com Tue Jan 24 07:39:43 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 24 Jan 2012 15:39:43 +0000 Subject: Questions about jigsaw API In-Reply-To: <4F1EB42C.5080103@oracle.com> References: <4F1EB42C.5080103@oracle.com> Message-ID: <4F1ED0BF.5080105@oracle.com> On 24/01/2012 13:37, Mike Ershov wrote: > Hello, > > I'm adapting sigtest tool ( sigtest.java.net ) to jigsaw and have some > questions about jigsaw API: > > 1) I need to read class bytes for any particular class and all its > dependencies. In other words for module com.acme.mod at 3.1 I have to > analyze com.acme.mod at 3.1's classes, their superclasses from other > com.acme.* modules recursively and their platform superclasses including > java.lang.Object. Maybe I missed something but I can't find easy way to > do it. So I resolve all dependencies manually. This is my the main > question. I very appreciate any recommendations. Does com.acme.mod at 3.1 have an entry point? -- just asking that as maybe all you need to do is read its configuration and that will give you the set of contexts and in turn the set of modules. Alternatively you can run the resolver and generate the configuration (which may be what you are doing now?). > > 2) org.openjdk.jigsaw.Library byte[] readClass(ModuleId mid, > java.lang.String className) according to the javadoc "reads the class > bytes of the given class within the given module, in this library or in > a parent library." But actually it doesn't read a parent library. Please > correct the description or, better, add this functionality. This should work. > > 3) I expected that > SimpleLibrary.openSystemLibrary().readClass(Platform.bootModule(), > "java.lang.Object") returns Object's bytes. It returns null because > Platform.bootModule() is "jdk.base at 8-ea" instead of "jdk.boot at 8-ea". The jdk.boot/jdk.base issue will go away once the views/exports work is pushed. > > 4) I noticed that public org.openjdk.jigsaw.LoaderPool has no public > constructors. If there is no reasons for such design it's better to do > it not public ( like LibraryPool ) or make them all public. Can you explain what you are looking to do? -Alan. From jonathan.gibbons at oracle.com Tue Jan 24 08:00:25 2012 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 24 Jan 2012 08:00:25 -0800 Subject: Javac ignores module-info dependencies In-Reply-To: <4F1EB4B5.40009@oracle.com> References: <4F1EB4B5.40009@oracle.com> Message-ID: <4F1ED599.8030507@oracle.com> Mike, Sorry, known issue. I've been waiting for the visibility and accessibility discussions to wind down before implementing the rules in javac. -- Jon On 01/24/2012 05:40 AM, Mike Ershov wrote: > Hello, > > I noticed that javac does not take requires part of module-info as > compile class path. Is it correct behavior? > I have sources for two modules under one source root - > m1 and m2. m2 uses class from m1 but m2's module-info has no "requires > m1" statement. I expected compile-time error, but a compilation is > successful and I see runtime error. The code is attached. > > Sorry in advance if this is known issue. > > Thanks, > Mike > From mark.reinhold at oracle.com Tue Jan 24 08:07:52 2012 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 24 Jan 2012 08:07:52 -0800 Subject: State of jigsaw: Description of module file format? In-Reply-To: reinier@zwitserloot.com; Tue, 24 Jan 2012 08:38:09 +0100; Message-ID: <20120124160752.E8781D18@eggemoggin.niobe.net> 2012/1/23 23:38 -0800, reinier at zwitserloot.com: > I noticed this document: > http://cr.openjdk.java.net/~mr/jigsaw/notes/jigsaw-big-picture-01 > > Does not cover the module file format. No, not yet. The Jigsaw project page links to a (slightly out-of-date) description, here: http://cr.openjdk.java.net/~mr/jigsaw/notes/module-file-format/ There is at present no provision for source code, javadoc, or license text. - Mark From mark.reinhold at oracle.com Tue Jan 24 09:56:22 2012 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 24 Jan 2012 09:56:22 -0800 Subject: Module views with exports support In-Reply-To: mandy.chung@oracle.com; Fri, 30 Dec 2011 09:42:16 PST; <4EFDF7F8.7040900@oracle.com> Message-ID: <20120124175622.8D177D18@eggemoggin.niobe.net> 2011/12/30 9:42 -0800, mandy.chung at oracle.com: > A new webrev for the module views [1] with the exports support: > http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/module-views.01/ There are some big changes here, thanks for working through all the details. Suggestions on the API: - Rename ModuleViewQuery back to ModuleIdQuery, for now. - Rename Dependence to ViewDependence, rename Service.Dependence to ServiceDependence, and make both of them extend a new class Dependence which declares only the modifiers() method. - Replace Service.ProviderInfo with a map in the ModuleView interface: Map> ModuleView.services(). - Delete the now-empty Service class. - Rename ModuleInfo.requires() to .requiresModules(). - In ModuleInfo, is the view(ModuleId) method really necessary? If so then replace it and theand views() methods with a single method: Map views(). If not, remove it. - In ModuleInfo, is the views(String) method really necessary? If not, remove it. The implementation is fine for now, though as previously discussed we need eventually to integrate views more deeply into the code so that it's not necessary to have multiple copies of the same module-info file in a library when a module has multiple views. Finally, I see that the unit tests use wildcard exports ("exports y.*") rather than plain package exports ("exports y"). Is this temporary, waiting on related changes in javac? - Mark From mandy.chung at oracle.com Tue Jan 24 10:10:46 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 24 Jan 2012 10:10:46 -0800 Subject: Module views with exports support In-Reply-To: <20120124175622.8D177D18@eggemoggin.niobe.net> References: <20120124175622.8D177D18@eggemoggin.niobe.net> Message-ID: <4F1EF426.90406@oracle.com> Thanks for the review and suggestion. I'll make the change and send out a new webrev. W.r.t. the the wildcard exports, it's temporary and waiting for javac related change. Mandy On 1/24/2012 9:56 AM, mark.reinhold at oracle.com wrote: > 2011/12/30 9:42 -0800, mandy.chung at oracle.com: >> A new webrev for the module views [1] with the exports support: >> http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/module-views.01/ > There are some big changes here, thanks for working through all the > details. > > Suggestions on the API: > > - Rename ModuleViewQuery back to ModuleIdQuery, for now. > > - Rename Dependence to ViewDependence, rename Service.Dependence to > ServiceDependence, and make both of them extend a new class > Dependence which declares only the modifiers() method. > > - Replace Service.ProviderInfo with a map in the ModuleView interface: > Map> ModuleView.services(). > > - Delete the now-empty Service class. > > - Rename ModuleInfo.requires() to .requiresModules(). > > - In ModuleInfo, is the view(ModuleId) method really necessary? If so > then replace it and theand views() methods with a single method: > Map views(). If not, remove it. > > - In ModuleInfo, is the views(String) method really necessary? If not, > remove it. > > The implementation is fine for now, though as previously discussed we > need eventually to integrate views more deeply into the code so that it's > not necessary to have multiple copies of the same module-info file in a > library when a module has multiple views. > > Finally, I see that the unit tests use wildcard exports ("exports y.*") > rather than plain package exports ("exports y"). Is this temporary, > waiting on related changes in javac? > > - Mark From jonathan.gibbons at oracle.com Tue Jan 24 10:21:43 2012 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 24 Jan 2012 10:21:43 -0800 Subject: Jigsaw spec clarifications In-Reply-To: <4F18B84E.60303@oracle.com> References: <4F189A23.3090101@oracle.com> <4F18B592.7020707@oracle.com> <4F18B84E.60303@oracle.com> Message-ID: <4F1EF6B7.2050403@oracle.com> On 01/19/2012 04:41 PM, Alex Buckley wrote: > On 1/19/2012 4:30 PM, Alex Buckley wrote: >> On 1/19/2012 2:33 PM, Jonathan Gibbons wrote: >>> provides service S with S_A; >>> provides service S with S_B; >> >> Illegal. Ambiguity in which implementation to use. > > Actually, scratch that. Legal! It's clear from > http://openjdk.java.net/projects/jigsaw/doc/topics/services.html that > a module can offer multiple implementations of a service interface. > > Alex What about: provides service S with S_A; provides service S with S_A; -- Jon From alex.buckley at oracle.com Tue Jan 24 12:41:22 2012 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 24 Jan 2012 12:41:22 -0800 Subject: Jigsaw spec clarifications In-Reply-To: <4F1EF6B7.2050403@oracle.com> References: <4F189A23.3090101@oracle.com> <4F18B592.7020707@oracle.com> <4F18B84E.60303@oracle.com> <4F1EF6B7.2050403@oracle.com> Message-ID: <4F1F1772.9060706@oracle.com> On 1/24/2012 10:21 AM, Jonathan Gibbons wrote: > What about: > provides service S with S_A; > provides service S with S_A; We ban all other duplicates in a module declaration, even "harmless" ones like "permits A; permits A;", so this should be illegal too. I will update the compile-time and run-time rules. Alex From neal at gafter.com Tue Jan 24 13:35:32 2012 From: neal at gafter.com (Neal Gafter) Date: Tue, 24 Jan 2012 13:35:32 -0800 Subject: -encoding and -source in module-info.java In-Reply-To: <4F1E9F01.1090809@oracle.com> References: <4F1E9F01.1090809@oracle.com> Message-ID: Overall, I agree it would be nice to place these options together in a file for the compiler to consume. I just don't think it should be a "Java programming language source" file. The idea of using module-info.java to specify compilation options seems most tempting, but as long as it is a source file in the language, it must be subject to those options as well. Which means that specifying them inside the file itself is pretty pointless. As to the source level, what can the language specification say other than that "8" is the only allowed value? And what can the next version of the language specification say other than that "9" is the only allowed value? On Tue, Jan 24, 2012 at 4:07 AM, Jesse Glick wrote: > The encoding and source level of a module are fundamental attributes of > its sources, without which you cannot reliably even parse a syntax tree, so > I think they should be declared in module-info.java. Otherwise it is left > up to someone calling javac by hand, or a build script, to specify these > options; that is potentially error-prone, and means that tools which > inspect sources (including but not limited to IDEs) need to have some > separate mechanism for configuration of these attributes: you cannot just > hand them the sourcepath and let them run. > > I am assuming that all files in the sourcepath use the same encoding and > source level, which seems a reasonable restriction. > > > As to the source level, obviously given that JDK 8 will introduce > module-info.java, "8" (or "1.8") seems like the right default value; but a > syntax ought to be defined for specifying a newer level, e.g. > > source 1.9; // or 9? > > Furthermore I think that JDK 9+ versions of javac should keep the same > default source level - you should need to explicitly mark what version of > the Java language your module expects. Otherwise a module might compile > differently according to which version of javac was used, which is > undesirable, and tools cannot guess what version you meant. A little more > verbosity here seems to be justified. > > Whether the bytecode target (-target) should be specified in > module-info.java is another question. I have seen projects built using > -target 5 for JDK 5 compatibility but also in a separate artifact using > -target 6 for speed on JDK 6+ (split verifier). Probably the target level > should default to the source level, and in the rare case that you need to > override this, you can do so using a javac command option - this has no > impact on tools which just need to parse and analyze source files. > > > As to the encoding, something like > > encoding ISO-8859-2; > > would suffice. The obvious problems for encoding are > > 1. What should the default value be? javac currently uses the platform > default encoding, which IMHO is a horrible choice because it means that two > people running javac with the same parameters on the same files may be > producing different classes and/or warning messages. I would suggest making > UTF-8 be the default when compiling in module mode (leaving the old > behavior intact for legacy mode). For developers who want to keep sources > in a different character set, adding one line per module-info.java does not > seem like much of a burden. > > 2. What is module-info.java itself encoded in? If not UTF-8, then you need > to be able to reliably find the encoding declaration and then rescan the > file in that encoding. That is easy for most encodings (just do an initial > scan in ISO-8859-1), including everything commonly used by developers > AFAIK; a little trickier for UTF-16/32-type encodings but possible by > ignoring 0x00/0xFE/0xFF; and only fails on some mainframe charsets, old JIS > variants, and dingbats (*). Even those rare cases are probably guessable. > [1] > > > (*) Demo program: > > import java.io.**UnsupportedEncodingException; > import java.nio.charset.Charset; > import java.util.Arrays; > public class CharsetTest { > public static void main(String[] args) throws > UnsupportedEncodingException { > Charset raw = Charset.forName("ISO-8859-1"); > for (Charset c : Charset.availableCharsets().**values()) { > String text = "/* leading comment */\nmodule test {\n encoding > " + c.name() + ";\n}\n"; > byte[] encoded; > try { > encoded = text.getBytes(c); > } catch (UnsupportedOperationException x) { > System.out.println("cannot encode using " + c.name()); > continue; > } > if (Arrays.equals(encoded, text.getBytes(raw))) { > System.out.println("OK in " + c.name()); > } else if (new String(encoded, raw).contains(" encoding " + > c.name() + ";")) { > System.out.println("substring match in " + c.name()); > dump(encoded); > } else if (new String(encoded, raw).replace("\u0000", > "").contains(" encoding " + c.name() + ";")) { > System.out.println("NUL-**stripped match in " + c.name()); > dump(encoded); > } else { > System.out.println("garbled in " + c.name()); > dump(encoded); > } > } > } > private static void dump(byte[] encoded) { > for (byte b : encoded) { > if (b >= 32 && b <= 126 || b == '\n' || b == '\r') { > System.out.write(b); > } else if (b == 0) { > System.out.print('@'); > } else { > System.out.printf("\\%02X", b); > } > } > System.out.println(); > } > private CharsetTest() {} > } > > > [1] http://jchardet.sourceforge.**net/ > From eric at tibco.com Tue Jan 24 13:47:49 2012 From: eric at tibco.com (Eric Johnson) Date: Tue, 24 Jan 2012 22:47:49 +0100 Subject: -encoding and -source in module-info.java In-Reply-To: References: <4F1E9F01.1090809@oracle.com> Message-ID: <4F1F2705.3050606@tibco.com> Of course, to me, this circles back to the point I've chimed in on with others before. Module info shouldn't be in a file ending in .java. It *isn't* part of the language, it is part of the metadata for using the language. -Eric. On 1/24/12 10:35 PM, Neal Gafter wrote: > The idea of using module-info.java to specify compilation options seems > most tempting, but as long as it is a source file in the language, it must > be subject to those options as well. Which means that specifying them > inside the file itself is pretty pointless. As to the source level, what > can the language specification say other than that "8" is the only allowed > value? And what can the next version of the language specification say > other than that "9" is the only allowed value? From jesse.glick at oracle.com Tue Jan 24 14:07:08 2012 From: jesse.glick at oracle.com (Jesse Glick) Date: Tue, 24 Jan 2012 17:07:08 -0500 Subject: -encoding and -source in module-info.java In-Reply-To: References: <4F1E9F01.1090809@oracle.com> Message-ID: <4F1F2B8C.70500@oracle.com> On 01/24/2012 04:35 PM, Neal Gafter wrote: > I agree it would be nice to place these options together in a file for the compiler to consume. I just don't think it should be a "Java programming language > source" file. Well in the current Jigsaw prototype there is only one source of metadata, and that is module-info.java. Whether such a file extension/name/style is appropriate for module metadata is a long-running argument on the list which I did not want to get into. > as long as it is a source file in the language, it must be subject to those > options as well. Which means that specifying them inside the file itself is pretty pointless. I do not think so. It is admittedly a bit tricky with respect to encoding, but the XML spec has managed this. > As to the source level, what can the language specification say other than > that "8" is the only allowed value? It could say that it must follow a decimal-type format (which may be more restrictive than module versions), and that 1.8 is the smallest legal value; but it could probably just say that 1.8 is the only allowed value. (I am punting for now on whether the abbreviation "8" is legal in this context.) > what can the next version of the language specification say other than that "9" is the only allowed value? I am not sure precisely how the language spec would be worded but it would say that for this revision of the spec, 1.9 is the only legal value. As to the actual compiler in JDK 9, it would accept either 1.8 or 1.9, and control its behavior accordingly, just as if you had passed -source on the CLI. It is only necessary to ensure that the module-info.java token structure is not changed so radically between releases that a single file could be interpreted in multiple ways, which does not seem like a likely problem given that the much richer "regular" Java language token structure has not changed much since 1.0. A defense against this kind of change is to force the encoding and/or source level to be specified in a special simplistic header (like a pragma) at the very top of the file outside the regular token stream, though this would look inconsistent with the rest of the file. Bear in mind that works fine; an XML parser supporting the 1.1 spec of course also reads version="1.0" files, adjusting its permitted syntax slightly according to the declared version, and reads the rest of the file according to the declared encoding. Similarly, HTML files can specify both their encoding and specification level in band. From forax at univ-mlv.fr Tue Jan 24 14:14:45 2012 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Tue, 24 Jan 2012 23:14:45 +0100 Subject: -encoding and -source in module-info.java In-Reply-To: <4F1F2B8C.70500@oracle.com> References: <4F1E9F01.1090809@oracle.com> <4F1F2B8C.70500@oracle.com> Message-ID: <4F1F2D55.8040604@univ-mlv.fr> On 01/24/2012 11:07 PM, Jesse Glick wrote: > On 01/24/2012 04:35 PM, Neal Gafter wrote: >> I agree it would be nice to place these options together in a file >> for the compiler to consume. I just don't think it should be a "Java >> programming language >> source" file. > > Well in the current Jigsaw prototype there is only one source of > metadata, and that is module-info.java. Whether such a file > extension/name/style is appropriate for module metadata is a > long-running argument on the list which I did not want to get into. > >> as long as it is a source file in the language, it must be subject to >> those >> options as well. Which means that specifying them inside the file >> itself is pretty pointless. > > I do not think so. It is admittedly a bit tricky with respect to > encoding, but the XML spec has managed this. No, it doesn't work. As an example try to specify utf-16 as encoding of an XML file. I only works for US-ASCII, UTF8 and all encodings that contains the 128 first value of the ASCII and encode them as a byte. R?mi From forax at univ-mlv.fr Tue Jan 24 14:21:44 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 24 Jan 2012 23:21:44 +0100 Subject: -encoding and -source in module-info.java In-Reply-To: <4F1F2705.3050606@tibco.com> References: <4F1E9F01.1090809@oracle.com> <4F1F2705.3050606@tibco.com> Message-ID: <4F1F2EF8.3000106@univ-mlv.fr> On 01/24/2012 10:47 PM, Eric Johnson wrote: > Of course, to me, this circles back to the point I've chimed in on > with others before. Module info shouldn't be in a file ending in > .java. It *isn't* part of the language, it is part of the metadata for > using the language. > > -Eric. There is no need to put compilation options in the module description file, defining a module and compiling sources are two different tasks, the module metadata describe requires/provides of a module that it. Why do you want mix these to things together ? I believe that Maven has the two things mixed only because there is no module description in Java. When Java 8 will be out, it will be more clear, R?mi > > On 1/24/12 10:35 PM, Neal Gafter wrote: >> The idea of using module-info.java to specify compilation options seems >> most tempting, but as long as it is a source file in the language, it >> must >> be subject to those options as well. Which means that specifying them >> inside the file itself is pretty pointless. As to the source level, >> what >> can the language specification say other than that "8" is the only >> allowed >> value? And what can the next version of the language specification say >> other than that "9" is the only allowed value? From jesse.glick at oracle.com Tue Jan 24 15:14:12 2012 From: jesse.glick at oracle.com (Jesse Glick) Date: Tue, 24 Jan 2012 18:14:12 -0500 Subject: -encoding and -source in module-info.java In-Reply-To: <4F1F2D55.8040604@univ-mlv.fr> References: <4F1E9F01.1090809@oracle.com> <4F1F2B8C.70500@oracle.com> <4F1F2D55.8040604@univ-mlv.fr> Message-ID: <4F1F3B44.5080900@oracle.com> On 01/24/2012 05:14 PM, R?mi Forax wrote: > it doesn't work. As an example try to specify utf-16 as encoding of an XML file. Works for me in Chrome and Xerces, even if there is no BOM. http://www.w3.org/TR/2008/REC-xml-20081126/#sec-guessing From forax at univ-mlv.fr Tue Jan 24 15:41:59 2012 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Wed, 25 Jan 2012 00:41:59 +0100 Subject: -encoding and -source in module-info.java In-Reply-To: <4F1F3B44.5080900@oracle.com> References: <4F1E9F01.1090809@oracle.com> <4F1F2B8C.70500@oracle.com> <4F1F2D55.8040604@univ-mlv.fr> <4F1F3B44.5080900@oracle.com> Message-ID: <4F1F41C7.7000005@univ-mlv.fr> On 01/25/2012 12:14 AM, Jesse Glick wrote: > On 01/24/2012 05:14 PM, R?mi Forax wrote: >> it doesn't work. As an example try to specify utf-16 as encoding of >> an XML file. > > Works for me in Chrome and Xerces, even if there is no BOM. > > http://www.w3.org/TR/2008/REC-xml-20081126/#sec-guessing Nice to know that it works in Chrome and Xerces for UTF16, but it doesn't work with the parser used by my colleagues and provided by a lowly company of Redmond. R?mi From jesse.glick at oracle.com Tue Jan 24 16:25:50 2012 From: jesse.glick at oracle.com (Jesse Glick) Date: Tue, 24 Jan 2012 19:25:50 -0500 Subject: -encoding and -source in module-info.java In-Reply-To: <4F1F41C7.7000005@univ-mlv.fr> References: <4F1E9F01.1090809@oracle.com> <4F1F2B8C.70500@oracle.com> <4F1F2D55.8040604@univ-mlv.fr> <4F1F3B44.5080900@oracle.com> <4F1F41C7.7000005@univ-mlv.fr> Message-ID: <4F1F4C0E.5010906@oracle.com> On 01/24/2012 06:41 PM, R?mi Forax wrote: > Nice to know that it works in Chrome and Xerces for UTF16, > but it doesn't work with the parser used by my colleagues and > provided by a lowly company of Redmond. I am merely using the XML prolog example to point out that it is possible to sniff an encoding declaration out of a file using that same encoding, even for the obscure case of non-ASCII-superset encodings; XML parsers are not required to do so, since sometimes an encoding is specified out of band. The cases are different technically because (1) XML defines no default encoding, whereas Jigsaw could and I think should, so a legal module-info.java not using UTF-8 must specify its actual encoding which makes detection easier; (2) the XML prolog is required to be the first bytes in the file, which makes detection easier, whereas this might be considered too ugly for module-info.java; (3) there would be one widely used reference implementation of the parser, namely javac, and that and other implementations must pass the same TCK which I would expect to test the corner cases. From alex.buckley at oracle.com Tue Jan 24 17:08:21 2012 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 24 Jan 2012 17:08:21 -0800 Subject: -encoding and -source in module-info.java In-Reply-To: <4F1E9F01.1090809@oracle.com> References: <4F1E9F01.1090809@oracle.com> Message-ID: <4F1F5605.9070100@oracle.com> Compilation units in the Java programming language consist of UTF-16 code units. No desire to change that. A compiler may support other encodings but that's an implementation detail and so does not belong in the Java SE platform's idea of a module declaration. Documenting and/or enforcing the language level is a much trickier topic that I doubt will be addressed by the module system. The API level available to a program can theoretically be "configured" by depending on a given version of java.base, but it's still up to a compiler to a) switch its language level to match the desired API and b) switch its own use of platform classes to match the desired API (http://blogs.oracle.com/darcy/entry/bootclasspath_older_source). Alex On 1/24/2012 4:07 AM, Jesse Glick wrote: > The encoding and source level of a module are fundamental attributes of > its sources, without which you cannot reliably even parse a syntax tree, > so I think they should be declared in module-info.java. Otherwise it is > left up to someone calling javac by hand, or a build script, to specify > these options; that is potentially error-prone, and means that tools > which inspect sources (including but not limited to IDEs) need to have > some separate mechanism for configuration of these attributes: you > cannot just hand them the sourcepath and let them run. > > I am assuming that all files in the sourcepath use the same encoding and > source level, which seems a reasonable restriction. > > > As to the source level, obviously given that JDK 8 will introduce > module-info.java, "8" (or "1.8") seems like the right default value; but > a syntax ought to be defined for specifying a newer level, e.g. > > source 1.9; // or 9? > > Furthermore I think that JDK 9+ versions of javac should keep the same > default source level - you should need to explicitly mark what version > of the Java language your module expects. Otherwise a module might > compile differently according to which version of javac was used, which > is undesirable, and tools cannot guess what version you meant. A little > more verbosity here seems to be justified. > > Whether the bytecode target (-target) should be specified in > module-info.java is another question. I have seen projects built using > -target 5 for JDK 5 compatibility but also in a separate artifact using > -target 6 for speed on JDK 6+ (split verifier). Probably the target > level should default to the source level, and in the rare case that you > need to override this, you can do so using a javac command option - this > has no impact on tools which just need to parse and analyze source files. > > > As to the encoding, something like > > encoding ISO-8859-2; > > would suffice. The obvious problems for encoding are > > 1. What should the default value be? javac currently uses the platform > default encoding, which IMHO is a horrible choice because it means that > two people running javac with the same parameters on the same files may > be producing different classes and/or warning messages. I would suggest > making UTF-8 be the default when compiling in module mode (leaving the > old behavior intact for legacy mode). For developers who want to keep > sources in a different character set, adding one line per > module-info.java does not seem like much of a burden. > > 2. What is module-info.java itself encoded in? If not UTF-8, then you > need to be able to reliably find the encoding declaration and then > rescan the file in that encoding. That is easy for most encodings (just > do an initial scan in ISO-8859-1), including everything commonly used by > developers AFAIK; a little trickier for UTF-16/32-type encodings but > possible by ignoring 0x00/0xFE/0xFF; and only fails on some mainframe > charsets, old JIS variants, and dingbats (*). Even those rare cases are > probably guessable. [1] > > > (*) Demo program: > > import java.io.UnsupportedEncodingException; > import java.nio.charset.Charset; > import java.util.Arrays; > public class CharsetTest { > public static void main(String[] args) throws > UnsupportedEncodingException { > Charset raw = Charset.forName("ISO-8859-1"); > for (Charset c : Charset.availableCharsets().values()) { > String text = "/* leading comment */\nmodule test {\n encoding " + > c.name() + ";\n}\n"; > byte[] encoded; > try { > encoded = text.getBytes(c); > } catch (UnsupportedOperationException x) { > System.out.println("cannot encode using " + c.name()); > continue; > } > if (Arrays.equals(encoded, text.getBytes(raw))) { > System.out.println("OK in " + c.name()); > } else if (new String(encoded, raw).contains(" encoding " + c.name() + > ";")) { > System.out.println("substring match in " + c.name()); > dump(encoded); > } else if (new String(encoded, raw).replace("\u0000", "").contains(" > encoding " + c.name() + ";")) { > System.out.println("NUL-stripped match in " + c.name()); > dump(encoded); > } else { > System.out.println("garbled in " + c.name()); > dump(encoded); > } > } > } > private static void dump(byte[] encoded) { > for (byte b : encoded) { > if (b >= 32 && b <= 126 || b == '\n' || b == '\r') { > System.out.write(b); > } else if (b == 0) { > System.out.print('@'); > } else { > System.out.printf("\\%02X", b); > } > } > System.out.println(); > } > private CharsetTest() {} > } > > > [1] http://jchardet.sourceforge.net/ From neal at gafter.com Tue Jan 24 20:31:52 2012 From: neal at gafter.com (Neal Gafter) Date: Tue, 24 Jan 2012 20:31:52 -0800 Subject: -encoding and -source in module-info.java In-Reply-To: <4F1F2B8C.70500@oracle.com> References: <4F1E9F01.1090809@oracle.com> <4F1F2B8C.70500@oracle.com> Message-ID: On Tue, Jan 24, 2012 at 2:07 PM, Jesse Glick wrote: > > I am not sure precisely how the language spec would be worded but it would > say that for this revision of the spec, 1.9 is the only legal value The compiler is required to obey the platform specifications, which includes the language spec. If "source 1.8" is illegal, then it must be rejected. And therefore a source file written for the previous version of the language "source 1.8" is not legal in the latest version of the language. This is exactly the opposite of what Oracle should be trying to achieve with version-to-version source compatibility. From mandy.chung at oracle.com Tue Jan 24 20:43:40 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 24 Jan 2012 20:43:40 -0800 Subject: Module views with exports support In-Reply-To: <20120124175622.8D177D18@eggemoggin.niobe.net> References: <20120124175622.8D177D18@eggemoggin.niobe.net> Message-ID: <4F1F887C.8080002@oracle.com> Updated webrev at: http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/module-views.02/ This incorporates Mark's and Alan's review comments. On 1/24/2012 9:56 AM, mark.reinhold at oracle.com wrote: > Suggestions on the API: > > - Rename ModuleViewQuery back to ModuleIdQuery, for now. > I also reverted the Category renamed methods and keep them as they are. gatherLocalModuleIds listModuleIds findModuleIds findLatestModuleId > - Rename Dependence to ViewDependence, rename Service.Dependence to > ServiceDependence, and make both of them extend a new class > Dependence which declares only the modifiers() method. > - Replace Service.ProviderInfo with a map in the ModuleView interface: > Map> ModuleView.services(). > > - Delete the now-empty Service class. > > - Rename ModuleInfo.requires() to .requiresModules(). > Done > - In ModuleInfo, is the view(ModuleId) method really necessary? If so > then replace it and theand views() methods with a single method: > Map views(). If not, remove it. > The view(ModuleId) is not strictly needed. It's used in the Resolver when it first reads the ModuleInfo of the candidate and finds the ModuleView of the given mid (L259-265). It's also used in the new Category.readModuleView convenient method. I removed the view(ModuleId) method for now and replaced the call site with the code to lookup the view. > - In ModuleInfo, is the views(String) method really necessary? If not, > remove it. > removed. On 1/17/2012 7:26 AM, Alan Bateman wrote: > I like views and works really well for the JDK. I'm in two minds on > some of the renaming as it forces anyone using the API to have to deal > with the concept more than I had expected. For example when one > invokes a list or find modules in a Catalog then I think it's > debatable as to whether it should return the ModuleIds of the modules > or ModuleIds synthesized from the view name and the module's version. I keep them as they are for now. > I'm also in two minds on the changes to the module library where there > is a directory with a copy of the module info. I can see how this is > used but it kinda feels that this should be an index (key'ed on view) > instead. Yep. It's just an easy way to get this prototype implemented while giving us more time to implement a long-term solution. Will do that next. > In ModuleInfo then defaultView and views() make sense (the views > method just needs to be clear that the returned set includes the > default view). I'm less sure about the view(ModuleId) and view(String) > methods as they aren't strictly required. Removed. > In Service.Dependence I see the constructor takes a boolean to > indicate if the dependency is optional. It may be more consistent > (with Dependence) to have it take a set of modifiers - if you agree > then I can take into the services patch as it's not re-based to your > changes. I have revised it per Mark's suggestion. > I don't see anything obviously wrong with the exports work although I > found ContextView in the linker hard to deal, maybe it just needs > another name. I thought about naming it just 'View' :) > What you would think about jmod ls -v printing the exports too? I missed that in the webrev. It's now included in the new version. > Minor nit is that I didn't understand the changes to Hi :-) That's left from my hack to use NetBeans to test jigsaw. I reverted the change. Thanks Mandy From mikhail.ershov at oracle.com Wed Jan 25 05:58:42 2012 From: mikhail.ershov at oracle.com (Mike Ershov) Date: Wed, 25 Jan 2012 16:58:42 +0300 Subject: Questions about jigsaw API In-Reply-To: <4F1ED0BF.5080105@oracle.com> References: <4F1EB42C.5080103@oracle.com> <4F1ED0BF.5080105@oracle.com> Message-ID: <4F200A92.8090704@oracle.com> Alan Bateman wrote: > On 24/01/2012 13:37, Mike Ershov wrote: >> Hello, >> >> I'm adapting sigtest tool ( sigtest.java.net ) to jigsaw and have >> some questions about jigsaw API: >> >> 1) I need to read class bytes for any particular class and all its >> dependencies. In other words for module com.acme.mod at 3.1 I have to >> analyze com.acme.mod at 3.1's classes, their superclasses from other >> com.acme.* modules recursively and their platform superclasses including >> java.lang.Object. Maybe I missed something but I can't find easy way to >> do it. So I resolve all dependencies manually. This is my the main >> question. I very appreciate any recommendations. > Does com.acme.mod at 3.1 have an entry point? -- just asking that as > maybe all you need to do is read its configuration and that will give > you the set of contexts and in turn the set of modules. Alternatively > you can run the resolver and generate the configuration (which may be > what you are doing now?). Thanks Alan, this is the answer I was looking for! > >> >> 4) I noticed that public org.openjdk.jigsaw.LoaderPool has no public >> constructors. If there is no reasons for such design it's better to do >> it not public ( like LibraryPool ) or make them all public. > Can you explain what you are looking to do? I was exploring org.openjdk.jigsaw API and noticed that two public classes, LoaderPool and Loader (because its constructor accepts LoaderPool as parameter) can not be used as public. From jesse.glick at oracle.com Wed Jan 25 07:14:25 2012 From: jesse.glick at oracle.com (Jesse Glick) Date: Wed, 25 Jan 2012 10:14:25 -0500 Subject: -encoding and -source in module-info.java In-Reply-To: References: <4F1E9F01.1090809@oracle.com> <4F1F2B8C.70500@oracle.com> Message-ID: <4F201C51.50000@oracle.com> On 01/24/2012 11:31 PM, Neal Gafter wrote: > The compiler is required to obey the platform specifications, which includes the language spec. ...and _previous_ language specs. > If "source 1.8" is illegal, then it must be rejected. And therefore a > source file written for the previous version of the language "source 1.8" is not legal in the latest version of the language. Yes, but it is legal in the previous version of the language, so javac from JDK 9 would compile the module without complaints as if you had passed -source 1.8 on the command line. You just would not be able to use reified generics (or whatever source 1.9 brings you) in that module. From chris.hegarty at oracle.com Wed Jan 25 07:28:56 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 25 Jan 2012 15:28:56 +0000 Subject: native cmds and libs in the module library In-Reply-To: <4F1EBD1C.3020607@oracle.com> References: <4EE62FE1.70006@oracle.com> <4EEF597F.3030804@oracle.com> <4EEF6518.4060004@oracle.com> <4EF08A20.7030106@oracle.com> <4EF08C15.7060305@oracle.com> <4F071DDA.2040607@oracle.com> <4F0B71E8.2010104@oracle.com> <4F158596.2030306@oracle.com> <4F166EB4.9060108@oracle.com> <4F19AABD.90604@oracle.com> <4F1EBD1C.3020607@oracle.com> Message-ID: <4F201FB8.9040307@oracle.com> Alan, Mandy, Thank you for your comments. In short, I would like to integrate what is in the latest webrev (with your approval/review), and then continue the remainder of this work as a separate task. Latest webrev http://cr.openjdk.java.net/~chegar/jigsaw/libbin_webrev.05/webrev/ Changes: - SimpleLibrary parent, natlib, natcmd, and config are now final (Mandys comment). - Cleanup some style issues. - Backout changes to Modules.gmk (install from jmod files). Long description. I think it best to postpone to the next phase of this work creating the images by installing from jmod files. The reason being that this doesn't work very well on Windows yet. The jmod files for Windows contain both commands and libraries in the NATIVE_CMDS section of the jmod file, and config/property files in the NATIVE_LIBS section. It will not work to simply set --natcmd bin, and --natlib lib, as the findLocalNativeLibrary will then be searching in the wrong place. The solution is to have the appropriate files put in the correct section of the jmod file in the first place, and this will require separating out commands, libraries, and config files during the build . I think this is best done as a separate task. Thanks, -Chris. On 24/01/2012 14:15, Alan Bateman wrote: > .... > Can you briefly summarize how one would use this on Windows? I assume it > requires specifying the --natcmd and --natlib to be the same directory. > > In the simple library layout I added a flags word some time ago and it > has many spare bits. Rather than storing 0 or 1 before each path then an > alternative would be to use some of the spare bits. > > A minor nit but the code style with if-then-else is a bit inconsistent. > SimpleLibrary.storePath, SimpleLibrary.resolveAndEnsurePath, > Librarian.Create.go are just a couple of examples that jump out (there > are many more). > > A general comment is that we'll need to go over this again once we get > to clean-up the implementation, improve performance, make library > operations atomic, etc. I mention this because what we have now is a bit > inefficient and there's also quite a bit of hopping between new and old > APIs. It will need a major clean-up at some point. > > On the tests then I think an important test to include is a test that > attempts to install a library or binary outside of the bin and lib > trees. I think the validation code that you've added will catch this but > I think a test is important. > > -Alan. > > > > > From jesse.glick at oracle.com Wed Jan 25 07:47:51 2012 From: jesse.glick at oracle.com (Jesse Glick) Date: Wed, 25 Jan 2012 10:47:51 -0500 Subject: -encoding and -source in module-info.java In-Reply-To: <4F1F5605.9070100@oracle.com> References: <4F1E9F01.1090809@oracle.com> <4F1F5605.9070100@oracle.com> Message-ID: <4F202427.3040300@oracle.com> On 01/24/2012 08:08 PM, Alex Buckley wrote: > Compilation units in the Java programming language consist of UTF-16 code units. Of course. That is a character set, not an encoding. > so does not belong in the Java SE platform's idea of a module declaration. Perhaps not; theoretically a compiler could be loading sources out of a database that provides Unicode strings natively. But javac invoked from the command line always works on files, and these have a definite layout in the filesystem - including $root/module-info.java - and must have a specific encoding. This means that a directory tree representing sources for a Java module has an unambiguous meaning in the Java language only if something in that tree declares the encoding. That would suggest something like $root/encoding containing the (ASCII-encoded) name of the encoding. Alternately, require modular Java sources to use a standard encoding, presumably UTF-8, as modern languages are tending to do. > The API level available to a program can > theoretically be "configured" by depending on a given version of java.base (Or java.boot?) This is an interesting option newly available with Jigsaw - basically to tie the source level (and I suppose the target level) to that supported by the platform itself. This is a sensible enough default; the question is whether some modules may still need to 1. Use a newer source level than the platform supports, while using the supported target level. Historically this has worked in certain cases, where third-party libraries can fill in missing platform classes. Of course it cannot work in all or even most cases. 2. Use an older source level than the platform supports, whether using the recommended target level. Useful mainly in case new platform APIs are wanted, but a language change was incompatible for this module. 3. Use an older source level and an older target level. Useful in case the module must be able to run on the older platform, but can use a handful of new APIs where available (checked via reflection perhaps). You are still left with the problem of a module which declares no explicit platform dependency: some default value must be used for the source level, and changing this default according to which version of javac happens to be used to compile it is a very bad idea. > it's still up to a compiler to a) switch its language level to match the desired API The main issue here would be whether it is possible to determine the version of java.base/boot/whatever being requested before knowing for sure what version of the language module-info.java is written in. If a new language spec radically changed how module versions are requested, it might be tricky to interpret the requires clauses unambiguously. > b) switch its own use of platform classes to match the desired API This issue at least would finally be addressed by modular javac: your module would compile against whatever platform API it requests, I hope downloading older platform modules on demand. In current Java projects it is generally impractical to pass -bootclasspath to a project with a CI-friendly build script - you would have to include a copy of the target JDK's rt.jar in versioned project sources - so generally this is not done, yet -source must be passed for predictability, so everyone using JDK 7 javac to compile gets the annoying warning mentioned in that blog. (Using -Xlint:-options is undesirable since then unrelated problems with javac options will be suppressed.) From mandy.chung at oracle.com Wed Jan 25 08:45:36 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 25 Jan 2012 08:45:36 -0800 Subject: native cmds and libs in the module library In-Reply-To: <4F201FB8.9040307@oracle.com> References: <4EE62FE1.70006@oracle.com> <4EEF597F.3030804@oracle.com> <4EEF6518.4060004@oracle.com> <4EF08A20.7030106@oracle.com> <4EF08C15.7060305@oracle.com> <4F071DDA.2040607@oracle.com> <4F0B71E8.2010104@oracle.com> <4F158596.2030306@oracle.com> <4F166EB4.9060108@oracle.com> <4F19AABD.90604@oracle.com> <4F1EBD1C.3020607@oracle.com> <4F201FB8.9040307@oracle.com> Message-ID: <4F2031B0.3050309@oracle.com> On 1/25/12 7:28 AM, Chris Hegarty wrote: > > In short, I would like to integrate what is in the latest webrev (with > your approval/review), and then continue the remainder of this work as > a separate task. > That's fine with me. Your new webrev looks good. It's also better for this changeset to go first before the module views that I will do the merge. > > The solution is to have the appropriate files put in the correct > section of the jmod file in the first place, and this will require > separating out commands, libraries, and config files during the build > . I think this is best done as a separate task. Agree and this would require quite some amount of works. I can help working with you on that. Thanks Mandy From alex.buckley at oracle.com Wed Jan 25 10:59:21 2012 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 25 Jan 2012 10:59:21 -0800 Subject: -encoding and -source in module-info.java In-Reply-To: <4F201C51.50000@oracle.com> References: <4F1E9F01.1090809@oracle.com> <4F1F2B8C.70500@oracle.com> <4F201C51.50000@oracle.com> Message-ID: <4F205109.5000506@oracle.com> On 1/25/2012 7:14 AM, Jesse Glick wrote: > On 01/24/2012 11:31 PM, Neal Gafter wrote: >> The compiler is required to obey the platform specifications, which >> includes the language spec. > > ...and _previous_ language specs. No, a compiler that complies with Java SE n only needs to respect the JLS in Java SE n. (Getting off topic now.) Alex From alex.buckley at oracle.com Wed Jan 25 11:16:33 2012 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 25 Jan 2012 11:16:33 -0800 Subject: -encoding and -source in module-info.java In-Reply-To: <4F202427.3040300@oracle.com> References: <4F1E9F01.1090809@oracle.com> <4F1F5605.9070100@oracle.com> <4F202427.3040300@oracle.com> Message-ID: <4F205511.3090504@oracle.com> On 1/25/2012 7:47 AM, Jesse Glick wrote: > On 01/24/2012 08:08 PM, Alex Buckley wrote: >> Compilation units in the Java programming language consist of UTF-16 >> code units. > > Of course. That is a character set, not an encoding. Certainly UTF-16 is an encoding. Recall the difference between code points and code units. > Perhaps not; theoretically a compiler could be loading sources out of a > database that provides Unicode strings natively. But javac invoked from > the command line always works on files, and these have a definite layout > in the filesystem - including $root/module-info.java - and must have a > specific encoding. This means that a directory tree representing sources > for a Java module has an unambiguous meaning in the Java language only > if something in that tree declares the encoding. That would suggest > something like $root/encoding containing the (ASCII-encoded) name of the > encoding. All those things are implementation details and so don't belong in a module declaration as defined by the JLS. (This applies regardless of the syntax used for a module declaration.) > Alternately, require modular Java sources to use a standard encoding, > presumably UTF-8, as modern languages are tending to do. Again, there is no desire to change the JLS to support encodings of Unicode other than UTF-16. > (Or java.boot?) This is an interesting option newly available with > Jigsaw - basically to tie the source level (and I suppose the target > level) to that supported by the platform itself. This is a sensible > enough default; the question is whether some modules may still need to We are well aware of these interactions. > You are still left with the problem of a module which declares no > explicit platform dependency: some default value must be used for the > source level, and changing this default according to which version of > javac happens to be used to compile it is a very bad idea. If there's no explicit java.base dependence, Jigsaw specifies an implicit dependence on the "current" platform's API (java.base). javac will continue to assume the "current" platform's language level, so there's a match. Alex From jesse.glick at oracle.com Wed Jan 25 12:47:23 2012 From: jesse.glick at oracle.com (Jesse Glick) Date: Wed, 25 Jan 2012 15:47:23 -0500 Subject: -encoding and -source in module-info.java In-Reply-To: <4F205511.3090504@oracle.com> References: <4F1E9F01.1090809@oracle.com> <4F1F5605.9070100@oracle.com> <4F202427.3040300@oracle.com> <4F205511.3090504@oracle.com> Message-ID: <4F206A5B.8020105@oracle.com> On 01/25/2012 02:16 PM, Alex Buckley wrote: > All those things are implementation details and so don't belong in a module declaration as defined by the JLS. Then the encoding needs to be specified somehow in the source root outside of a module declaration (such as my proposed $root/encoding file). I do not really care whether the JLS ever mentions it or not, so long as javac interprets disk files with a predictable encoding - so that all Java language tools which operate on files (*) will be able to parse a given module source tree the same way. Currently they need out of band information to do so, and that is a significant problem. >> Alternately, require modular Java sources to use a standard encoding, >> presumably UTF-8, as modern languages are tending to do. > > there is no desire to change the JLS to support encodings of Unicode other than UTF-16. The representation of surrogate code points using 16-bit code units is not what I am discussing. The "alternate" proposal was for disk files to be unconditionally interpreted by command-line javac as being in UTF-8 format, as if '-encoding UTF-8' were passed to an earlier version of the tool. Obviously this is meaningless for the hypothetical case discussed in the JLS of a program stored in a database, or the more practical case of a program using JSR 199 and providing a FileObject that supports only a Reader and not an InputStream. > If there's no explicit java.base dependence, Jigsaw specifies an implicit dependence on the "current" platform's API (java.base). This is bad since it makes the interpretation of the source module dependent on the context in which it is interpreted. Among other problems, if the language level is inferred from the version of the platform, using a different contextual platform than the original author intended could mean that the exact same source module not only _behaves_ differently when run (which is to be expected) but _parses_ differently as well. (*) Or sources otherwise grouped in the conventional way and potentially accessible via java.nio.file.FileSystem, such as inside a ZIP. From mandy.chung at oracle.com Wed Jan 25 13:10:51 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 25 Jan 2012 13:10:51 -0800 Subject: ModuleNameAndVersionQuery vs CONSTANT_ModuleQuery_Info Message-ID: <4F206FDB.8040001@oracle.com> Alex, In a 'requires' clause, version is optional. It seems that the version_index in the CONSTANT_ModuleQuery_info structure should be zero in that case as in the CONSTANT_ModuleId_info But the spec for the CONSTANT_ModuleQuery_info structure requires the version_index be a valid index into the constant_pool table. A spec bug? Mandy From peter.jensen at oracle.com Wed Jan 25 15:36:10 2012 From: peter.jensen at oracle.com (Peter Jensen) Date: Wed, 25 Jan 2012 15:36:10 -0800 Subject: -encoding and -source in module-info.java In-Reply-To: <4F206A5B.8020105@oracle.com> References: <4F1E9F01.1090809@oracle.com> <4F1F5605.9070100@oracle.com> <4F202427.3040300@oracle.com> <4F205511.3090504@oracle.com> <4F206A5B.8020105@oracle.com> Message-ID: <4F2091EA.2020504@oracle.com> On 01/25/12 12:47, Jesse Glick wrote: > On 01/25/2012 02:16 PM, Alex Buckley wrote: >> All those things are implementation details and so don't belong in a >> module declaration as defined by the JLS. > > Then the encoding needs to be specified somehow in the source root > outside of a module declaration (such as my proposed $root/encoding > file). I do not really care whether the JLS ever mentions it or not, > so long as javac interprets disk files with a predictable encoding - > so that all Java language tools which operate on files (*) will be > able to parse a given module source tree the same way. Currently they > need out of band information to do so, and that is a significant problem. A Java compiler may support different encodings, it may support compilation of source code written against different version of the JLS, it may support generation of Java byte code relying on APIs as defined by different versions of the JLS, ... Specifying such options, in whatever format, means specifying common capabilities where it has previously been open to the implementation. While there might be sense in doing so, I fail to recognize why modules make this any more, or less, of an issue. Did I miss an argument why this is especially critical for modules? Or is it more a matter of filling an existing void? From jesse.glick at oracle.com Wed Jan 25 16:52:43 2012 From: jesse.glick at oracle.com (Jesse Glick) Date: Wed, 25 Jan 2012 19:52:43 -0500 Subject: -encoding and -source in module-info.java In-Reply-To: <4F2091EA.2020504@oracle.com> References: <4F1E9F01.1090809@oracle.com> <4F1F5605.9070100@oracle.com> <4F202427.3040300@oracle.com> <4F205511.3090504@oracle.com> <4F206A5B.8020105@oracle.com> <4F2091EA.2020504@oracle.com> Message-ID: <4F20A3DB.2070701@oracle.com> On 01/25/2012 06:36 PM, Peter Jensen wrote: > A Java compiler may support different encodings The Java platform specifies a minimum set of encodings which are guaranteed to be supported, so I would expect that these would be guaranteed for source file encoding too. Whether it is prudent to permit a source tree to use an "optional" encoding, i.e. whether a compiler implemented in the JVM should support any extra encoding that JVM actually supports, is another question. > it may support compilation of source code written against different version of the JLS That is why I recommended that the source level be physically declared in the source root. (Whether in module-info.java itself or in some other standardized place does not make much practical difference, so long as either the JLS or the javac tool docs specify it.) > Specifying such options, in whatever format, means specifying common capabilities where it has previously been open to the implementation. -encoding and -source at least are considered "standard" options (not -X prefixed). Anyway a (file-based) compiler could not work at all unless it knew what the values of these two fundamental parameters were: they are intrinsic properties of the sources themselves. > [is this] especially critical for modules? Or is it more a matter of filling an existing void? There is an existing void. The reason I bring this up in the context of Jigsaw is that in JDK 7 and earlier, a naked source tree could not be analyzed in any very useful way at all because you would lack any information about its expected classpath: even if you optimistically guessed at encoding (ISO-8859-1?) and source level (1.7?), you would get no further than a syntax parse. Even a wildcard import would be impossible to interpret. So in the existing language, any tool which wants to work with a source tree at more than a superficial level - an IDE, a static analyzer, HTMLized code browser, structural grep, etc. - really has to be supplied a bunch of metadata (*) to make any sense of it, especially a classpath. Given that, you might as well throw in an encoding and source level at the same time. By contrast, under the current Jigsaw design a tool could get complete "classpath" information (**) right from $basedir/module-info.java (***), making it possible for the first time to be run without any configuration beyond the location of the source root (or a file within that root) - but only if the encoding and source level can also be obtained. It would seem a pity to have almost, but not quite, self-describing module sources in JDK 8. My recent post about migrating -processorpath to module-info.java is on the same topic. While there are some processors which are elective for a given module - a programmer or CI build might run them on some occasions or might not - many processors are integral to the function of a library used by the module. The processor might perform mandatory semantic error checks, without which an IDE or refactoring tool would be unaware that it was about to make an invalid change. More critically, the processor might generate Java sources which are required for regular project sources to compile - so without knowledge of which processors are expected to be run by javac, a source-based tool would be left with unexplained missing symbols. Those javac options which could be freely changed for a given source tree without really affecting the meaning of the input, such as -g or -Xmaxerrs or -Xprefer:source, are irrelevant to source-based tools and do not belong in portable source metadata. How -target should be treated is debatable. -Xlint suboptions are a grey area in between intrinsic and incidental attributes - a given module may be tuned to be "lint-free" for certain classes of warning only - so it would be nice if @SuppressWarnings could be specified in module-info.java and considered to apply to all compilation units in the module (meaning it is OK to use -Xlint:all). (*) Or be embedded in or otherwise integrated with Maven, which is the only broadly accepted metadata for Java sources today. While reading maven-compiler-plugin parameters is cumbersome, it at least can be done pretty reliably. Script-oriented build tools (Ant, Gradle, ...) are more or less opaque to a tool which wants to know how javac would have been invoked, and parsing proprietary project metadata from all popular IDEs would be challenging. (**) At least a list of required module names and baseline versions, which can be translated to the equivalent of a classpath if those dependencies can be located somehow. Assuming they must be present in the local cache repository (or in a preregistered remote repository) in order for javac to work, then any tool running on the same machine could find them too. (***) The same argument applies if module metadata were to be in some other format - XML, manifest, etc. - so long as javac mandates that this be physically located in a specific place in the source tree, rather than referred to with a CLI option. From alex.buckley at oracle.com Wed Jan 25 17:06:49 2012 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 25 Jan 2012 17:06:49 -0800 Subject: ModuleNameAndVersionQuery vs CONSTANT_ModuleQuery_Info In-Reply-To: <4F206FDB.8040001@oracle.com> References: <4F206FDB.8040001@oracle.com> Message-ID: <4F20A729.9000707@oracle.com> On 1/25/2012 1:10 PM, Mandy Chung wrote: > In a 'requires' clause, version is optional. It seems that > the version_index in the CONSTANT_ModuleQuery_info structure > should be zero in that case as in the CONSTANT_ModuleId_info Yes. The representation of a 'requires' clause (ModuleRequires.module_table) used to refer to CONSTANT_ModuleId, so it got version-less queries for free. Then we broke out version queries into CONSTANT_ModuleQuery. I am wondering if we need both kinds of constant pool entry, given that the JVM can't distinguish between a string which holds a single version and a string which holds a version query. That is, the strong typing provided by different kinds of constant pool entries can be subverted. But I'll leave them both in for now. Project page will update soon. Alex From Alan.Bateman at oracle.com Thu Jan 26 03:52:54 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 26 Jan 2012 11:52:54 +0000 Subject: native cmds and libs in the module library In-Reply-To: <4F201FB8.9040307@oracle.com> References: <4EE62FE1.70006@oracle.com> <4EEF597F.3030804@oracle.com> <4EEF6518.4060004@oracle.com> <4EF08A20.7030106@oracle.com> <4EF08C15.7060305@oracle.com> <4F071DDA.2040607@oracle.com> <4F0B71E8.2010104@oracle.com> <4F158596.2030306@oracle.com> <4F166EB4.9060108@oracle.com> <4F19AABD.90604@oracle.com> <4F1EBD1C.3020607@oracle.com> <4F201FB8.9040307@oracle.com> Message-ID: <4F213E96.3020100@oracle.com> On 25/01/2012 15:28, Chris Hegarty wrote: > Alan, Mandy, > > Thank you for your comments. > > In short, I would like to integrate what is in the latest webrev (with > your approval/review), and then continue the remainder of this work as > a separate task. > > Latest webrev > http://cr.openjdk.java.net/~chegar/jigsaw/libbin_webrev.05/webrev/ > > Changes: > - SimpleLibrary parent, natlib, natcmd, and config are now final > (Mandys comment). > - Cleanup some style issues. > - Backout changes to Modules.gmk (install from jmod files). > > Long description. > > I think it best to postpone to the next phase of this work creating > the images by installing from jmod files. The reason being that this > doesn't work very well on Windows yet. > > The jmod files for Windows contain both commands and libraries in the > NATIVE_CMDS section of the jmod file, and config/property files in the > NATIVE_LIBS section. It will not work to simply set --natcmd bin, and > --natlib lib, as the findLocalNativeLibrary will then be searching in > the wrong place. > > The solution is to have the appropriate files put in the correct > section of the jmod file in the first place, and this will require > separating out commands, libraries, and config files during the build > . I think this is best done as a separate task. > > Thanks, > -Chris. > I agree with Mandy, I think you should just push the patch that you have now and address the separation and Windows issues in a second phase. -Alan. From jesse.glick at oracle.com Thu Jan 26 05:44:40 2012 From: jesse.glick at oracle.com (Jesse Glick) Date: Thu, 26 Jan 2012 08:44:40 -0500 Subject: -processorpath & META-INF/services/javax.annotation.processing.Processor In-Reply-To: <4F1E8FCD.5070604@oracle.com> References: <4F1E8FCD.5070604@oracle.com> Message-ID: <4F2158C8.5000206@oracle.com> A couple of other points on this topic I just thought of. On 01/24/2012 06:02 AM, Jesse Glick wrote: > It would be nice if [...when] module A provides javax.annotation.processing.Processor with some processor impl, then compilation of a module requiring A will run that > processor if there are matching annotations A longstanding irritation in 269 is that if as a library designer you do supply both an annotation and a matching processor, you have to choose between 1. Include the processor in the same module/JAR/etc. as the annotation (registered in ServiceLoader style). Ensures that everyone using the library (*) runs the processor automatically. But makes the library a bit larger, and may introduce additional dependencies not used at runtime. 2. Place the processor in a different module. Keeps the library slimmer, but means that users will not have the processor run by default - they would need to check the documentation of each library they use which defines any annotations and manually configure a processor path, which is unmaintainable when more than a couple of such libraries are involved. It would be a valuable improvement to let a library module declare that it has an associated processor module to be used only during compilation. Specifically, any module requiring that library (incl. indirectly via "requires public") should include the processor module in its processorpath or equivalent. For example: module lib { exports lib; requires processor service lib.proc; // syntax?? } package lib; public @interface Anno {} module lib.proc { requires lib; provides service javax.annotation.processing.Processor with lib.proc.Proc; } package lib.proc; @javax.annotation.processing.SupportedAnnotationTypes("lib.Anno") public class Proc extends javax.annotation.processing.AbstractProcessor {...} module user { requires lib; // "requires processor lib.proc" is implied } package user; // lib.proc.Proc will be run on this: @lib.Anno class C {} (There probably needs to be some way of overriding processor discovery, like -proc:none or -processor only.This in current versions of javac.) Another 269-related consideration is how processors will actually be run in JDK 8 javac. Currently the contents of -processorpath (defaulting to -classpath) are dumped into a URLClassLoader and then ServiceLoader or the equivalent is used for discovery if -processor is not given. In a modular environment, you would expect each ProcessingEnvironment to be associated with a transient LoaderPool (?) so that the semantics of the module system - especially dependencies and exported types - are used for loading processors and their associated classes. (The Javadoc of ProcessingEnvironment currently says "from the perspective of the running annotation processors, at least the chosen subset of helper classes are viewed as being loaded by the same class loader"; this would need to be updated to refer to modules.) TBD how modular javac should behave w.r.t. processors when run on an older JDK, as is the case for bootstrapping the JDK itself. If it knew how to resolve module dependencies, it could fall back to computing the transitive closure of dependencies of all processor modules and creating a URLClassLoader. But if the JDK does not use 269 internally - or only in higher-level modules that can be built after javac has been bootstrapped - then this may not be an issue. (*) Except Eclipse users in certain setups, as mentioned in the previous post. From chris.hegarty at oracle.com Thu Jan 26 05:56:51 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 26 Jan 2012 13:56:51 +0000 Subject: native cmds and libs in the module library In-Reply-To: <4F213E96.3020100@oracle.com> References: <4EE62FE1.70006@oracle.com> <4EEF597F.3030804@oracle.com> <4EEF6518.4060004@oracle.com> <4EF08A20.7030106@oracle.com> <4EF08C15.7060305@oracle.com> <4F071DDA.2040607@oracle.com> <4F0B71E8.2010104@oracle.com> <4F158596.2030306@oracle.com> <4F166EB4.9060108@oracle.com> <4F19AABD.90604@oracle.com> <4F1EBD1C.3020607@oracle.com> <4F201FB8.9040307@oracle.com> <4F213E96.3020100@oracle.com> Message-ID: <4F215BA3.3010907@oracle.com> On 01/26/12 11:52 AM, Alan Bateman wrote: > ..... >> > I agree with Mandy, I think you should just push the patch that you have > now and address the separation and Windows issues in a second phase. Thanks Alan, and Mandy. I will push this patch soon. -Chris. > > -Alan. > From mark.reinhold at oracle.com Thu Jan 26 07:27:51 2012 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 26 Jan 2012 07:27:51 -0800 Subject: Module views with exports support In-Reply-To: mandy.chung@oracle.com; Tue, 24 Jan 2012 20:43:40 PST; <4F1F887C.8080002@oracle.com> Message-ID: <20120126152751.43051DB6@eggemoggin.niobe.net> 2012/1/24 20:43 -0800, mandy.chung at oracle.com: > Updated webrev at: > > http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/module-views.02/ Looks good to me. - Mark From chris.hegarty at oracle.com Thu Jan 26 08:05:38 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 26 Jan 2012 16:05:38 +0000 Subject: jigsaw repo push problem (Read-only) Message-ID: <4F2179D2.4060508@oracle.com> Hi, I'm trying to push a changeset to the jigsaw/jigsaw/jdk repository and am getting an error, "Read-only file system". This would appear to be a problem on the server, but since his is my first attempt to push anything to this repo there could be something misconfigured in my environment! >: hg push Enter passphrase for key '/home/chhegar/.ssh/id_rsa': pushing to ssh://chegar at hg.openjdk.java.net/jigsaw/jigsaw/jdk searching for changes remote: abort: could not lock repository jigsaw/jigsaw/jdk: Read-only file system abort: unexpected response: empty string Thanks, -Chris. From mark.reinhold at oracle.com Thu Jan 26 08:26:02 2012 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 26 Jan 2012 08:26:02 -0800 Subject: jigsaw repo push problem (Read-only) In-Reply-To: chris.hegarty@oracle.com; Thu, 26 Jan 2012 16:05:38 GMT; <4F2179D2.4060508@oracle.com> Message-ID: <20120126162602.474B8DB6@eggemoggin.niobe.net> 2012/1/26 8:05 -0800, chris.hegarty at oracle.com: > I'm trying to push a changeset to the jigsaw/jigsaw/jdk repository and am > getting an error, "Read-only file system". > > This would appear to be a problem on the server, but since his is my first > attempt to push anything to this repo there could be something misconfigured in > my environment! No, the problem is that you aren't (yet) a Committer for Jigsaw. I'll make you an Author for now; please ask Mandy or Alan to push your changesets. - Mark From chris.hegarty at oracle.com Thu Jan 26 08:28:52 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 26 Jan 2012 16:28:52 +0000 Subject: jigsaw repo push problem (Read-only) In-Reply-To: <20120126162602.474B8DB6@eggemoggin.niobe.net> References: <20120126162602.474B8DB6@eggemoggin.niobe.net> Message-ID: <4F217F44.7010905@oracle.com> On 01/26/12 04:26 PM, mark.reinhold at oracle.com wrote: > 2012/1/26 8:05 -0800, chris.hegarty at oracle.com: >> I'm trying to push a changeset to the jigsaw/jigsaw/jdk repository and am >> getting an error, "Read-only file system". >> >> This would appear to be a problem on the server, but since his is my first >> attempt to push anything to this repo there could be something misconfigured in >> my environment! > > No, the problem is that you aren't (yet) a Committer for Jigsaw. D'oh! > I'll make you an Author for now; please ask Mandy or Alan to push your > changesets. Thanks Mark, will do. -Chris. > > - Mark From Alan.Bateman at oracle.com Thu Jan 26 09:02:21 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 26 Jan 2012 17:02:21 +0000 Subject: jigsaw repo push problem (Read-only) In-Reply-To: <4F217F44.7010905@oracle.com> References: <20120126162602.474B8DB6@eggemoggin.niobe.net> <4F217F44.7010905@oracle.com> Message-ID: <4F21871D.8030005@oracle.com> On 26/01/2012 16:28, Chris Hegarty wrote: > : > >> I'll make you an Author for now; please ask Mandy or Alan to push your >> changesets. > > Thanks Mark, will do. I'll push it for you shortly. -Alan From alan.bateman at oracle.com Thu Jan 26 09:07:22 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 26 Jan 2012 17:07:22 +0000 Subject: hg: jigsaw/jigsaw/jdk: Support installation of commands, configuration and native libraries outside of module library Message-ID: <20120126170742.B82DE471D5@hg.openjdk.java.net> Changeset: a22f65ac0b9a Author: chegar Date: 2012-01-26 16:59 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/a22f65ac0b9a Support installation of commands, configuration and native libraries outside of module library Reviewed-by: mchung, alanb ! src/share/classes/org/openjdk/jigsaw/Files.java ! src/share/classes/org/openjdk/jigsaw/ModuleFile.java ! src/share/classes/org/openjdk/jigsaw/SimpleLibrary.java ! src/share/classes/org/openjdk/jigsaw/cli/Librarian.java ! test/java/lang/reflect/Module/ModuleAnnotationTest.java ! test/org/openjdk/jigsaw/hello-native.sh From ekaterina.pavlova at oracle.com Thu Jan 26 10:30:49 2012 From: ekaterina.pavlova at oracle.com (Ekaterina Pavlova) Date: Thu, 26 Jan 2012 10:30:49 -0800 Subject: java.security.AccessControlException is thrown in case system SecurityManager is reset when running in module mode Message-ID: <4F219BD9.709@oracle.com> Hello, java.security.AccessControlException is thrown in case system SecurityManager is reset when running application in module mode. The minimized test case is attached. Is this known issue? Note, the test works fine in legacy mode but fails in module mode. thanks, -katya === > cat Hello.java package a; import java.security.*; public class Hello { public static void main(String[] args) { System.setSecurityManager(new CustomSecurity()); System.out.println("Going to call System.exit"); System.exit(0); } } class CustomSecurity extends SecurityManager {} > cat module-info.java module hello @ 1.0 { requires jdk.base; class a.Hello; } # run in legacy mode > java a.Hello Going to call System.exit # run in module mode > java -L mlib -m hello Going to call System.exit Exception in thread "main" java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "exitVM.0") at java.security.AccessControlContext.checkPermission(AccessControlContext.java:364) at java.security.AccessController.checkPermission(AccessController.java:555) at java.lang.SecurityManager.checkPermission(SecurityManager.java:550) at java.lang.SecurityManager.checkExit(SecurityManager.java:762) at java.lang.Runtime.exit(Runtime.java:105) at java.lang.System.exit(System.java:962) at a.Hello.main(Hello.java:10) From sean.mullan at oracle.com Thu Jan 26 11:02:06 2012 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 26 Jan 2012 14:02:06 -0500 Subject: java.security.AccessControlException is thrown in case system SecurityManager is reset when running in module mode In-Reply-To: <4F219BD9.709@oracle.com> References: <4F219BD9.709@oracle.com> Message-ID: <4F21A32E.3020404@oracle.com> On 1/26/12 1:30 PM, Ekaterina Pavlova wrote: > Hello, > > java.security.AccessControlException is thrown in case system SecurityManager is reset when running > application in module mode. The minimized test case is attached. Is this known issue? > Note, the test works fine in legacy mode but fails in module mode. The reason it works in legacy mode is because sun.misc.Launcher.AppClassLoader overrides getPermissions(CodeSource) and adds the exitVM permission: /** * allow any classes loaded from classpath to exit the VM. */ protected PermissionCollection getPermissions(CodeSource codesource) { PermissionCollection perms = super.getPermissions(codesource); perms.add(new RuntimePermission("exitVM")); return perms; } For jigsaw, we can probably add a similar workaround in org.openjdk.jigsaw.Launcher or Loader when it is loading a module with an entry point. But, one of the things I also want to explore is storing the permissions granted to a module by the configured policy in the module library when it is installed. If a module with an entry point is installed (which I guess is the equivalent of an application?), it could automatically add the RuntimePermission exitVM permission. Then when the module is loaded, these permissions would be loaded into the ProtectionDomain associated with that module. --Sean From mandy.chung at oracle.com Thu Jan 26 14:43:09 2012 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 26 Jan 2012 22:43:09 +0000 Subject: hg: jigsaw/jigsaw/jdk: Module views support Message-ID: <20120126224319.4D3E6471E0@hg.openjdk.java.net> Changeset: 2661318d6cfe Author: mchung Date: 2012-01-26 14:32 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/2661318d6cfe Module views support Reviewed-by: alanb, mr ! make/common/Defs-modules.gmk ! make/common/Defs.gmk ! make/common/Modules.gmk ! make/common/Rules.gmk ! make/docs/Makefile ! make/java/java/FILES_java.gmk ! make/modules/Makefile ! make/modules/jdk.depconfig ! make/modules/modules.config ! make/modules/modules.group ! make/modules/modules.properties ! make/tools/classanalyzer/nbproject/project.properties ! make/tools/classanalyzer/src/com/sun/classanalyzer/AnnotatedDependency.java ! make/tools/classanalyzer/src/com/sun/classanalyzer/ClassAnalyzer.java ! make/tools/classanalyzer/src/com/sun/classanalyzer/ClassListWriter.java ! make/tools/classanalyzer/src/com/sun/classanalyzer/ClassPath.java + make/tools/classanalyzer/src/com/sun/classanalyzer/Dependence.java ! make/tools/classanalyzer/src/com/sun/classanalyzer/JigsawModuleBuilder.java ! make/tools/classanalyzer/src/com/sun/classanalyzer/Module.java ! make/tools/classanalyzer/src/com/sun/classanalyzer/ModuleBuilder.java ! make/tools/classanalyzer/src/com/sun/classanalyzer/ModuleConfig.java ! make/tools/classanalyzer/src/com/sun/classanalyzer/ModuleInfo.java ! make/tools/classanalyzer/src/com/sun/classanalyzer/PackageInfo.java ! src/share/bin/java.c ! src/share/classes/java/lang/module/Dependence.java ! src/share/classes/java/lang/module/ModuleInfo.java ! src/share/classes/java/lang/module/ModuleInfoReader.java + src/share/classes/java/lang/module/ModuleView.java + src/share/classes/java/lang/module/ServiceDependence.java + src/share/classes/java/lang/module/ViewDependence.java ! src/share/classes/java/lang/reflect/Module.java ! src/share/classes/java/util/ResourceBundle.java ! src/share/classes/org/openjdk/jigsaw/BaseContext.java ! src/share/classes/org/openjdk/jigsaw/BootLoader.java ! src/share/classes/org/openjdk/jigsaw/Catalog.java ! src/share/classes/org/openjdk/jigsaw/ClassInfo.java ! src/share/classes/org/openjdk/jigsaw/Configuration.java ! src/share/classes/org/openjdk/jigsaw/Configurator.java ! src/share/classes/org/openjdk/jigsaw/ContextBuilder.java ! src/share/classes/org/openjdk/jigsaw/ContextSet.java ! src/share/classes/org/openjdk/jigsaw/Hi.java ! src/share/classes/org/openjdk/jigsaw/Launcher.java ! src/share/classes/org/openjdk/jigsaw/Library.java ! src/share/classes/org/openjdk/jigsaw/Linker.java ! src/share/classes/org/openjdk/jigsaw/LinkingContext.java ! src/share/classes/org/openjdk/jigsaw/Loader.java ! src/share/classes/org/openjdk/jigsaw/LoaderPool.java ! src/share/classes/org/openjdk/jigsaw/PathContext.java ! src/share/classes/org/openjdk/jigsaw/PathLinker.java ! src/share/classes/org/openjdk/jigsaw/Platform.java ! src/share/classes/org/openjdk/jigsaw/PublishedRepository.java ! src/share/classes/org/openjdk/jigsaw/RepositoryCatalog.java ! src/share/classes/org/openjdk/jigsaw/Resolution.java ! src/share/classes/org/openjdk/jigsaw/Resolver.java ! src/share/classes/org/openjdk/jigsaw/SimpleLibrary.java ! src/share/classes/org/openjdk/jigsaw/cli/Commands.java ! src/share/classes/org/openjdk/jigsaw/cli/Packager.java ! src/share/classes/sun/security/jca/ProviderConfig.java ! src/share/classes/sun/tools/jar/Main.java ! src/share/classes/sun/tools/jar/ModuleInfo.java ! test/Makefile ! test/java/lang/module/_ModuleInfoReader.java ! test/java/lang/module/module-info-reader.sh ! test/org/openjdk/jigsaw/ConfigurationBuilder.java ! test/org/openjdk/jigsaw/ContextBuilder.java ! test/org/openjdk/jigsaw/MockLibrary.java ! test/org/openjdk/jigsaw/ModuleInfoBuilder.java ! test/org/openjdk/jigsaw/_Configurator.java ! test/org/openjdk/jigsaw/_Library.java ! test/org/openjdk/jigsaw/_RemoteRepository.java ! test/org/openjdk/jigsaw/_RemoteRepositoryList.java ! test/org/openjdk/jigsaw/_RepositoryCatalog.java ! test/org/openjdk/jigsaw/circular-deps.sh ! test/org/openjdk/jigsaw/cli/jmod-basic.sh ! test/org/openjdk/jigsaw/cli/signed-modular-jar.sh ! test/org/openjdk/jigsaw/hello-jar.sh ! test/org/openjdk/jigsaw/hello-native.sh ! test/org/openjdk/jigsaw/hello-optional.sh + test/org/openjdk/jigsaw/hello-view.sh ! test/org/openjdk/jigsaw/hello.sh ! test/org/openjdk/jigsaw/library.sh ! test/org/openjdk/jigsaw/maze.sh ! test/org/openjdk/jigsaw/optional-base.sh ! test/org/openjdk/jigsaw/optional-deps.sh ! test/org/openjdk/jigsaw/optional-jaxp.sh ! test/org/openjdk/jigsaw/optional-reexport.sh ! test/org/openjdk/jigsaw/preinstall.sh ! test/org/openjdk/jigsaw/resolver.sh ! test/org/openjdk/jigsaw/tester.sh From mandy.chung at oracle.com Thu Jan 26 14:43:30 2012 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 26 Jan 2012 22:43:30 +0000 Subject: hg: jigsaw/jigsaw/hotspot: Module views support: jdk.boot is replaced with jdk.base Message-ID: <20120126224343.72DEC471E1@hg.openjdk.java.net> Changeset: 0daf3b6ab20c Author: mchung Date: 2012-01-25 09:05 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/0daf3b6ab20c Module views support: jdk.boot is replaced with jdk.base ! src/share/vm/runtime/os.cpp From mandy.chung at oracle.com Thu Jan 26 14:43:45 2012 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 26 Jan 2012 22:43:45 +0000 Subject: hg: jigsaw/jigsaw/langtools: 89 new changesets Message-ID: <20120126224649.283AC471E2@hg.openjdk.java.net> Changeset: 2179237a7f83 Author: jjg Date: 2011-11-15 14:26 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/2179237a7f83 basic support for generating new class file attributes ! src/share/classes/com/sun/tools/classfile/Attribute.java ! src/share/classes/com/sun/tools/classfile/ClassWriter.java ! src/share/classes/com/sun/tools/classfile/ConstantPool.java - src/share/classes/com/sun/tools/classfile/ModuleClass_attribute.java + src/share/classes/com/sun/tools/classfile/ModuleData_attribute.java - src/share/classes/com/sun/tools/classfile/ModuleExport_attribute.java - src/share/classes/com/sun/tools/classfile/ModulePermits_attribute.java ! src/share/classes/com/sun/tools/classfile/ModuleProvides_attribute.java ! src/share/classes/com/sun/tools/classfile/ModuleRequires_attribute.java ! src/share/classes/com/sun/tools/classfile/Module_attribute.java + src/share/classes/com/sun/tools/javac/code/Directive.java + src/share/classes/com/sun/tools/javac/code/ModuleId.java + src/share/classes/com/sun/tools/javac/code/ModuleIdQuery.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Modules.java ! src/share/classes/com/sun/tools/javac/jigsaw/JavacCatalog.java ! src/share/classes/com/sun/tools/javac/jigsaw/JigsawModuleResolver.java ! src/share/classes/com/sun/tools/javac/jvm/ClassFile.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/util/Names.java ! src/share/classes/com/sun/tools/javap/AttributeWriter.java ! src/share/classes/com/sun/tools/javap/ClassWriter.java ! src/share/classes/javax/lang/model/element/ModuleElement.java Changeset: 4210f18e2300 Author: jjg Date: 2011-11-16 17:11 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/4210f18e2300 remove support for old semantic info ! src/share/classes/com/sun/tools/javac/code/Directive.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Modules.java ! src/share/classes/com/sun/tools/javac/jigsaw/JavacCatalog.java ! src/share/classes/com/sun/tools/javac/jigsaw/JigsawModuleResolver.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/javax/lang/model/element/ModuleElement.java Changeset: 71eff8ae0fea Author: jjg Date: 2011-11-21 10:34 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/71eff8ae0fea fix permits ! src/share/classes/com/sun/tools/classfile/ModuleProvides_attribute.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javap/AttributeWriter.java Changeset: 446fb88f6435 Author: jjg Date: 2011-11-21 16:05 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/446fb88f6435 update Tree API + src/share/classes/com/sun/source/tree/EntrypointDirectiveTree.java + src/share/classes/com/sun/source/tree/ExportDirectiveTree.java - src/share/classes/com/sun/source/tree/ModuleClassTree.java + src/share/classes/com/sun/source/tree/ModuleDirectiveTree.java - src/share/classes/com/sun/source/tree/ModuleExportTree.java + src/share/classes/com/sun/source/tree/ModuleIdQueryTree.java ! src/share/classes/com/sun/source/tree/ModuleIdTree.java - src/share/classes/com/sun/source/tree/ModulePermitsTree.java - src/share/classes/com/sun/source/tree/ModuleRequiresTree.java ! src/share/classes/com/sun/source/tree/ModuleTree.java + src/share/classes/com/sun/source/tree/PermitsDirectiveTree.java + src/share/classes/com/sun/source/tree/ProvidesModuleDirectiveTree.java + src/share/classes/com/sun/source/tree/ProvidesServiceDirectiveTree.java + src/share/classes/com/sun/source/tree/RequiresFlag.java + src/share/classes/com/sun/source/tree/RequiresModuleDirectiveTree.java + src/share/classes/com/sun/source/tree/RequiresServiceDirectiveTree.java ! src/share/classes/com/sun/source/tree/Tree.java ! src/share/classes/com/sun/source/tree/TreeVisitor.java + src/share/classes/com/sun/source/tree/ViewDeclarationTree.java ! src/share/classes/com/sun/source/util/SimpleTreeVisitor.java ! src/share/classes/com/sun/source/util/TreeScanner.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/Modules.java ! src/share/classes/com/sun/tools/javac/jigsaw/JavacCatalog.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/jvm/Pool.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java ! src/share/classes/com/sun/tools/javap/AttributeWriter.java Changeset: 686714238fb5 Author: mchung Date: 2011-11-22 15:10 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/686714238fb5 Add a View constructor for the jar tool use ! src/share/classes/com/sun/tools/classfile/ModuleProvides_attribute.java Changeset: 53189d57c19a Author: mchung Date: 2011-11-22 16:18 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/53189d57c19a Fix ClassWriter to write service_table for ModuleRequires attribute ! src/share/classes/com/sun/tools/classfile/ClassWriter.java Changeset: cd04c161e84f Author: jjg Date: 2011-11-23 14:18 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/cd04c161e84f update parser for views ! src/share/classes/com/sun/tools/javac/code/Directive.java ! src/share/classes/com/sun/tools/javac/code/ModuleId.java ! src/share/classes/com/sun/tools/javac/code/ModuleIdQuery.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/AttrContext.java ! src/share/classes/com/sun/tools/javac/comp/Modules.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java ! src/share/classes/com/sun/tools/javac/util/Names.java ! src/share/classes/com/sun/tools/javap/AttributeWriter.java Changeset: 141d01e228c0 Author: mchung Date: 2011-12-01 10:39 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/141d01e228c0 Merge Changeset: f9d568384ddc Author: mchung Date: 2011-12-01 13:37 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/f9d568384ddc Multiple views support ! src/share/classes/com/sun/tools/javac/jigsaw/JavacCatalog.java Changeset: f43ee747f36d Author: mchung Date: 2011-12-01 16:29 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/f43ee747f36d Merge Changeset: 6157cf19b863 Author: mchung Date: 2011-12-02 13:07 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/6157cf19b863 Fix for skip boot cycle build ! make/build.properties ! make/build.xml Changeset: 47147081d5b4 Author: mcimadamore Date: 2011-10-06 18:39 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/47147081d5b4 7090499: missing rawtypes warnings in anonymous inner class Summary: javac does not detect raw types inside anonymous inner classes Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/warnings/7090499/T7090499.java + test/tools/javac/warnings/7090499/T7090499.out Changeset: b5d0b8effc85 Author: mcimadamore Date: 2011-10-17 12:54 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/b5d0b8effc85 7097436: Project Coin: duplicate varargs warnings on method annotated with @SafeVarargs Summary: Duplicate aliasing check during subtyping leads to spurious varargs diagnostic Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/varargs/7097436/T7097436.java + test/tools/javac/varargs/7097436/T7097436.out ! test/tools/javac/varargs/warning/Warn5.java Changeset: 3cdfa97e1be9 Author: mcimadamore Date: 2011-10-17 12:57 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/3cdfa97e1be9 7093325: Redundant entry in bytecode exception table Summary: Inlining of finalizers does not update gaps list accordingly Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java + test/tools/javac/T7093325.java Changeset: 366c233eb838 Author: mcimadamore Date: 2011-10-19 16:56 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/366c233eb838 7102515: javac running very very long and not returning Summary: Verbose resolution diagnostics slow down with operator resolution Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/7102515/T7102515.java + test/tools/javac/7102515/T7102515.out Changeset: d2cbb77469ed Author: jjg Date: 2011-10-19 15:29 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/d2cbb77469ed 7101146: Paths should more directly managed by BaseFileManager Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/share/classes/com/sun/tools/javac/file/Paths.java ! src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java ! src/share/classes/com/sun/tools/javac/util/BaseFileManager.java Changeset: b4021c520e40 Author: jjh Date: 2011-10-21 14:14 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/b4021c520e40 7098530: tools/javac/javazip/Test.sh can fail on Windows Summary: Fix cygpath command to properly convert path Reviewed-by: jjg ! test/tools/javac/javazip/Test.sh Changeset: d346ab55031b Author: mcimadamore Date: 2011-10-24 13:00 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/d346ab55031b 7096014: Javac tokens should retain state Summary: Refactor javac tokens from enum constants to stateful instances (to keep track of position, comments, etc.) Reviewed-by: jjg ! src/share/classes/com/sun/tools/apt/main/AptJavaCompiler.java - src/share/classes/com/sun/tools/javac/parser/DocCommentScanner.java ! src/share/classes/com/sun/tools/javac/parser/EndPosParser.java + src/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java + src/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java - src/share/classes/com/sun/tools/javac/parser/Keywords.java ! src/share/classes/com/sun/tools/javac/parser/Lexer.java ! src/share/classes/com/sun/tools/javac/parser/ParserFactory.java ! src/share/classes/com/sun/tools/javac/parser/Scanner.java ! src/share/classes/com/sun/tools/javac/parser/ScannerFactory.java - src/share/classes/com/sun/tools/javac/parser/Token.java + src/share/classes/com/sun/tools/javac/parser/Tokens.java + src/share/classes/com/sun/tools/javac/parser/UnicodeReader.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javadoc/JavadocTool.java ! test/tools/javac/api/TestJavacTaskScanner.java + test/tools/javac/depDocComment/DeprecatedDocComment3.java + test/tools/javac/tree/DocCommentToplevelTest.java Changeset: 05814303a056 Author: mcimadamore Date: 2011-10-24 13:00 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/05814303a056 7098660: Write better overload resolution/inference tests Summary: Add overload/inference debug diagnostics - added test harness using annotations to check outcome of overload resolution/inference Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/ApplicableMethodFound.java + test/tools/javac/diags/examples/ApplicableMethodFound1.java + test/tools/javac/diags/examples/DeferredMethodInst.java + test/tools/javac/diags/examples/FullInstSig.java + test/tools/javac/diags/examples/NotApplicableMethodFound.java + test/tools/javac/diags/examples/PartialInstSig.java + test/tools/javac/diags/examples/VerboseResolveMulti.java + test/tools/javac/diags/examples/VerboseResolveMulti1.java + test/tools/javac/resolve/Candidate.java + test/tools/javac/resolve/Pos.java + test/tools/javac/resolve/ResolveHarness.java + test/tools/javac/resolve/TraceResolve.java + test/tools/javac/resolve/tests/BoxedReturnTypeInference.java + test/tools/javac/resolve/tests/PrimitiveOverReferenceOverInferred.java + test/tools/javac/resolve/tests/PrimitiveOverReferenceOverVarargs.java + test/tools/javac/resolve/tests/PrimitiveOverReferenceVarargsAmbiguous.java + test/tools/javac/resolve/tests/PrimitiveOverload.java + test/tools/javac/resolve/tests/PrimitiveReturnTypeInference.java + test/tools/javac/resolve/tests/ReferenceOverInferred.java + test/tools/javac/resolve/tests/ReferenceOverVarargs.java + test/tools/javac/resolve/tests/ReferenceOverload.java Changeset: b73a9be0b993 Author: mcimadamore Date: 2011-10-25 15:40 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/b73a9be0b993 7104618: MessageInfo.java is failing after lexer changes Summary: Two langtools regression tests cannot be built due to a bad import statement Reviewed-by: jjg ! test/tools/javac/diags/ArgTypeCompilerFactory.java Changeset: d830d28fc72e Author: jjg Date: 2011-10-25 10:48 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/d830d28fc72e 7104039: refactor/cleanup javac Paths class Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/apt/main/Main.java ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java + src/share/classes/com/sun/tools/javac/file/Locations.java - src/share/classes/com/sun/tools/javac/file/Paths.java ! src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java ! src/share/classes/com/sun/tools/javac/util/BaseFileManager.java ! src/share/classes/com/sun/tools/javadoc/DocletInvoker.java Changeset: a1eaf78ababb Author: jjh Date: 2011-10-25 19:18 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/a1eaf78ababb 7104905: Java SE build fails on call to CreateSymbols Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/file/Locations.java Changeset: 510d09ddc861 Author: katleman Date: 2011-10-13 10:35 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/510d09ddc861 Added tag jdk8-b09 for changeset b7a7e47c8d3d ! .hgtags Changeset: 5010ffc61eda Author: lana Date: 2011-10-12 12:26 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/5010ffc61eda Merge Changeset: f6c783e18bdf Author: lana Date: 2011-10-17 19:07 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/f6c783e18bdf Merge Changeset: 4bf01f1c4e34 Author: katleman Date: 2011-10-20 10:32 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/4bf01f1c4e34 Added tag jdk8-b10 for changeset f6c783e18bdf ! .hgtags Changeset: e52159ff8d0c Author: lana Date: 2011-10-25 10:52 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/e52159ff8d0c Merge Changeset: 897b72b2751b Author: lana Date: 2011-10-26 12:28 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/897b72b2751b Merge - src/share/classes/com/sun/tools/javac/file/Paths.java Changeset: 9e2eb4bc49eb Author: jjh Date: 2011-11-01 15:49 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/9e2eb4bc49eb 7101933: langtools jtreg tests do not work with jprt on windows Summary: Fixed langtools/test/Makefile to work on cygwin. Updated jtreg to 4.1 and JCK to JCK8. Reviewed-by: jjg, ohair ! test/Makefile Changeset: 56830d5cb5bb Author: mcimadamore Date: 2011-11-04 12:36 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/56830d5cb5bb 7104201: Refactor DocCommentScanner Summary: Add new Comment helper class to parse contents of comments in source code Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java ! src/share/classes/com/sun/tools/javac/parser/Tokens.java ! src/share/classes/com/sun/tools/javac/parser/UnicodeReader.java + test/tools/javac/depDocComment/DeprecatedDocComment4.java + test/tools/javac/depDocComment/DeprecatedDocComment4.out Changeset: 8ff85191a7ac Author: katleman Date: 2011-10-27 13:54 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/8ff85191a7ac Added tag jdk8-b11 for changeset 4bf01f1c4e34 ! .hgtags Changeset: 52df2131e294 Author: lana Date: 2011-10-25 21:55 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/52df2131e294 Merge - src/share/classes/com/sun/tools/javac/file/Paths.java - src/share/classes/com/sun/tools/javac/parser/DocCommentScanner.java - src/share/classes/com/sun/tools/javac/parser/Keywords.java - src/share/classes/com/sun/tools/javac/parser/Token.java Changeset: f2d6ed25857d Author: lana Date: 2011-10-28 17:49 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/f2d6ed25857d Merge - src/share/classes/com/sun/tools/javac/file/Paths.java - src/share/classes/com/sun/tools/javac/parser/DocCommentScanner.java - src/share/classes/com/sun/tools/javac/parser/Keywords.java - src/share/classes/com/sun/tools/javac/parser/Token.java Changeset: ae25163501bc Author: katleman Date: 2011-11-03 10:32 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/ae25163501bc Added tag jdk8-b12 for changeset f2d6ed25857d ! .hgtags Changeset: 11c184155128 Author: lana Date: 2011-11-05 00:02 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/11c184155128 Merge Changeset: ca49d50318dc Author: jjg Date: 2011-11-08 11:51 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/ca49d50318dc 6921494: provide way to print javac tree tag values Reviewed-by: jjg, mcimadamore Contributed-by: vicenterz at yahoo.es ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Enter.java ! src/share/classes/com/sun/tools/javac/comp/Env.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/jvm/CRTable.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/model/JavacElements.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java ! src/share/classes/com/sun/tools/javadoc/JavadocTool.java ! test/tools/javac/failover/CheckAttributedTree.java ! test/tools/javac/tree/AbstractTreeScannerTest.java ! test/tools/javac/tree/TreePosTest.java Changeset: 36553cb94345 Author: jjg Date: 2011-11-08 17:06 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/36553cb94345 7108668: allow Log to be initialized and used earlier Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/apt/comp/Apt.java ! src/share/classes/com/sun/tools/javac/api/JavacTool.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java ! src/share/classes/com/sun/tools/javac/util/JavacMessages.java ! src/share/classes/com/sun/tools/javac/util/Log.java ! src/share/classes/com/sun/tools/javac/util/Options.java ! src/share/classes/com/sun/tools/javadoc/Start.java Changeset: ae361e7f435a Author: jjg Date: 2011-11-08 17:06 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/ae361e7f435a 7108669: cleanup Log methods for direct printing to streams Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/apt/main/Main.java ! src/share/classes/com/sun/tools/javac/api/JavacTool.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/main/JavacOption.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/main/RecognizedOptions.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/util/BaseFileManager.java ! src/share/classes/com/sun/tools/javac/util/Log.java ! test/tools/javac/6410653/T6410653.java ! test/tools/javac/diags/ArgTypeCompilerFactory.java Changeset: c1238fcc9515 Author: ksrini Date: 2011-11-14 08:09 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/c1238fcc9515 7110974: (javac) add coding conventions and style checkers for langtools Reviewed-by: jjg ! make/build.properties ! make/build.xml + make/conf/checkstyle-emacs.xsl + make/conf/checkstyle-langtools.xml Changeset: 7375d4979bd3 Author: ksrini Date: 2011-11-14 15:11 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/7375d4979bd3 7106166: (javac) re-factor EndPos parser Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/jvm/CRTable.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java - src/share/classes/com/sun/tools/javac/parser/EndPosParser.java + src/share/classes/com/sun/tools/javac/parser/EndPosTable.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/ParserFactory.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/share/classes/com/sun/tools/javac/util/DiagnosticSource.java ! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java ! src/share/classes/com/sun/tools/javac/util/Log.java ! test/tools/javac/6304921/TestLog.java ! test/tools/javac/failover/CheckAttributedTree.java ! test/tools/javac/tree/TreePosTest.java Changeset: 65444e7998e3 Author: katleman Date: 2011-11-10 11:47 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/65444e7998e3 Added tag jdk8-b13 for changeset ae25163501bc ! .hgtags Changeset: b7003a6a530b Author: lana Date: 2011-11-14 18:16 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/b7003a6a530b Merge Changeset: 15ea1c763273 Author: asaha Date: 2011-06-27 12:29 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/15ea1c763273 Merge - src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/inherit.gif Changeset: c79cf0f04be6 Author: asaha Date: 2011-06-28 08:39 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/c79cf0f04be6 Merge Changeset: 34e175c1fabc Author: asaha Date: 2011-07-19 11:05 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/34e175c1fabc Merge Changeset: c4478931e22d Author: asaha Date: 2011-11-07 21:52 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/c4478931e22d Merge Changeset: 58f1325d72b2 Author: lana Date: 2011-11-14 18:18 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/58f1325d72b2 Merge Changeset: 16906df5bffc Author: katleman Date: 2011-11-17 10:46 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/16906df5bffc Added tag jdk8-b14 for changeset 58f1325d72b2 ! .hgtags Changeset: f07d6f55d39a Author: lana Date: 2011-11-18 11:12 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/f07d6f55d39a Merge Changeset: 07599bd780ca Author: jjh Date: 2011-11-19 15:54 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/07599bd780ca 7110611: compiler message file broken for javac -fullversion Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/main/Main.java Changeset: c896d95e7469 Author: mcimadamore Date: 2011-11-24 13:36 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/c896d95e7469 7115046: Add AST node for lambda expressions Summary: Add tree nodes for representing lambda expressions and update relevant visitors interfaces Reviewed-by: jjg + src/share/classes/com/sun/source/tree/LambdaExpressionTree.java ! src/share/classes/com/sun/source/tree/Tree.java ! src/share/classes/com/sun/source/tree/TreeVisitor.java ! src/share/classes/com/sun/source/util/SimpleTreeVisitor.java ! src/share/classes/com/sun/source/util/TreeScanner.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java ! src/share/classes/com/sun/tools/javac/tree/TreeTranslator.java Changeset: ec59a2ce9114 Author: mcimadamore Date: 2011-11-24 13:38 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/ec59a2ce9114 7115049: Add AST node for method references Summary: Add tree nodes for representing method/constructor references and update relevant visitors interfaces Reviewed-by: jjg + src/share/classes/com/sun/source/tree/MemberReferenceTree.java ! src/share/classes/com/sun/source/tree/Tree.java ! src/share/classes/com/sun/source/tree/TreeVisitor.java ! src/share/classes/com/sun/source/util/SimpleTreeVisitor.java ! src/share/classes/com/sun/source/util/TreeScanner.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java ! src/share/classes/com/sun/tools/javac/tree/TreeTranslator.java Changeset: 9448fe783fd2 Author: mcimadamore Date: 2011-11-28 15:56 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/9448fe783fd2 7115050: Add parser support for lambda expressions Summary: Add support for parsing lambda expressions to JavacParser Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/Lexer.java ! src/share/classes/com/sun/tools/javac/parser/Scanner.java ! src/share/classes/com/sun/tools/javac/parser/Tokens.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/diags/examples/CatchWithoutTry.java + test/tools/javac/diags/examples/LambdaNotSupported.java + test/tools/javac/diags/examples/NotAStatement.java ! test/tools/javac/generics/rare/6665356/T6665356.out + test/tools/javac/lambda/LambdaParserTest.java Changeset: 3343b22e2761 Author: mcimadamore Date: 2011-11-28 16:05 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/3343b22e2761 7115052: Add parser support for method references Summary: Add support for parsing method references to JavacParser Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/Tokens.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/diags/examples/IllegalChar.java + test/tools/javac/diags/examples/MethodReferencesNotSupported.java + test/tools/javac/lambda/MethodReferenceParserTest.java ! test/tools/javac/quid/T6999438.out Changeset: f0124245478e Author: jjg Date: 2011-12-08 16:28 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/f0124245478e Merge ! .hgtags ! make/build.properties ! make/build.xml ! make/tools/GenStubs/GenStubs.java ! src/share/classes/com/sun/source/tree/Tree.java ! src/share/classes/com/sun/source/tree/TreeVisitor.java ! src/share/classes/com/sun/source/util/SimpleTreeVisitor.java ! src/share/classes/com/sun/source/util/TreeScanner.java ! src/share/classes/com/sun/tools/javac/code/Directive.java ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Enter.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/Modules.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/file/CompositeLocation.java ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java + src/share/classes/com/sun/tools/javac/file/Locations.java - src/share/classes/com/sun/tools/javac/file/Paths.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/main/RecognizedOptions.java ! src/share/classes/com/sun/tools/javac/model/JavacElements.java - src/share/classes/com/sun/tools/javac/parser/DocCommentScanner.java - src/share/classes/com/sun/tools/javac/parser/EndPosParser.java + src/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java - src/share/classes/com/sun/tools/javac/parser/Keywords.java ! src/share/classes/com/sun/tools/javac/parser/Lexer.java ! src/share/classes/com/sun/tools/javac/parser/Scanner.java ! src/share/classes/com/sun/tools/javac/parser/ScannerFactory.java - src/share/classes/com/sun/tools/javac/parser/Token.java + src/share/classes/com/sun/tools/javac/parser/Tokens.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/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java ! src/share/classes/com/sun/tools/javac/tree/TreeTranslator.java ! src/share/classes/com/sun/tools/javac/util/Debug.java ! src/share/classes/javax/tools/ModuleFileManager.java Changeset: ee3dfb4cc37b Author: jjg Date: 2011-12-12 09:06 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/ee3dfb4cc37b Merge cleanup ! make/build.properties ! make/build.xml ! make/tools/Jigsaw/FpkgTask.java ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/jigsaw/JavacCatalog.java ! src/share/classes/com/sun/tools/javac/jigsaw/JigsawModuleResolver.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/Tokens.java Changeset: 983aec02b01a Author: jjg Date: 2011-12-12 09:08 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/983aec02b01a Merge ! make/build.properties ! make/build.xml Changeset: a8b9bbcfc6af Author: jjg Date: 2011-12-12 09:15 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/a8b9bbcfc6af Merge fixups ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! test/tools/javac/lambda/MethodReferenceParserTest.java Changeset: 37825b0d594e Author: jjg Date: 2011-12-12 09:54 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/37825b0d594e add missing file + test/tools/javac/T7120266.java Changeset: e89b588adcc5 Author: mchung Date: 2011-12-14 08:38 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/e89b588adcc5 JavacCatalog update for module view ! src/share/classes/com/sun/tools/javac/jigsaw/JavacCatalog.java Changeset: 1188d9bf35d9 Author: jjg Date: 2011-12-15 11:12 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/1188d9bf35d9 fix "requires optional service" ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javap/AttributeWriter.java Changeset: abfa0d8ea803 Author: ksrini Date: 2011-12-07 10:47 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/abfa0d8ea803 7086015: fix test/tools/javac/parser/netbeans/JavacParserTest.java Reviewed-by: ksrini, jjg Contributed-by: matherey.nunez at oracle.com ! test/tools/javac/parser/netbeans/JavacParserTest.java Changeset: 9350d0498d21 Author: ksrini Date: 2011-12-09 08:40 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/9350d0498d21 7119032: (javac) increase visibility of JavacParser methods to improve subtyping Reviewed-by: jjg Contributed-by: jan.lahoda at oracle.com ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java Changeset: e7d5e1a7cde5 Author: ksrini Date: 2011-12-10 17:44 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/e7d5e1a7cde5 7119487: JavacParserTest.java test fails on Windows platforms Reviewed-by: jjg + test/tools/javac/parser/JavacParserTest.java - test/tools/javac/parser/netbeans/JavacParserTest.java Changeset: e55270a7a022 Author: mcimadamore Date: 2011-12-11 17:48 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/e55270a7a022 7120266: javac fails to compile hotspot code Summary: Parser changes for method references cause bad intercation with method call syntax Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java + test/tools/javac/T7120266.java ! test/tools/javac/lambda/MethodReferenceParserTest.java Changeset: 4822dfe0922b Author: ohair Date: 2011-12-12 08:15 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/4822dfe0922b 7119829: Adjust default jprt testing configuration Reviewed-by: alanb ! make/jprt.properties Changeset: 3809292620c9 Author: jjg Date: 2011-12-13 11:21 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/3809292620c9 7120736: refactor javac option handling Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/api/JavacTool.java ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Enter.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/file/Locations.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/jvm/Target.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/util/BaseFileManager.java ! src/share/classes/com/sun/tools/javac/util/Log.java ! src/share/classes/com/sun/tools/javac/util/Options.java ! test/tools/javac/diags/examples/UnsupportedEncoding.java Changeset: 4e4fed1d02f9 Author: jjg Date: 2011-12-13 14:33 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/4e4fed1d02f9 7121164: renamed files not committed Reviewed-by: ksrini - src/share/classes/com/sun/tools/javac/main/JavacOption.java + src/share/classes/com/sun/tools/javac/main/Option.java + src/share/classes/com/sun/tools/javac/main/OptionHelper.java - src/share/classes/com/sun/tools/javac/main/OptionName.java - src/share/classes/com/sun/tools/javac/main/RecognizedOptions.java Changeset: 4261dc8af622 Author: jjg Date: 2011-12-14 16:16 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/4261dc8af622 7111022: javac no long prints last round of processing 7121323: Sqe tests using -Xstdout option fail with an invalid flag error message Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/main/Option.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/util/Log.java ! test/tools/javac/4846262/Test.sh + test/tools/javac/processing/options/testPrintProcessorInfo/TestWithXstdout.java ! test/tools/javac/util/T6597678.java Changeset: 281eeedf9755 Author: jjg Date: 2011-12-14 17:52 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/281eeedf9755 7121681: compiler message file broken for javac -fullversion Reviewed-by: jjh ! src/share/classes/com/sun/tools/javac/main/Option.java Changeset: 42ffceeceeca Author: jjg Date: 2011-12-14 21:52 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/42ffceeceeca 7121682: remove obsolete import Reviewed-by: jjh ! test/tools/javac/api/T6838467.java Changeset: ec2c0973cc31 Author: katleman Date: 2011-12-01 10:33 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/ec2c0973cc31 Added tag jdk8-b15 for changeset 07599bd780ca ! .hgtags Changeset: 2584f5358cba Author: lana Date: 2011-12-06 20:26 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/2584f5358cba Merge Changeset: 1cbe86c11ba6 Author: lana Date: 2011-12-12 10:08 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/1cbe86c11ba6 Merge - test/tools/javac/parser/netbeans/JavacParserTest.java Changeset: 55a49c399603 Author: katleman Date: 2011-12-15 12:16 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/55a49c399603 Added tag jdk8-b17 for changeset 1cbe86c11ba6 ! .hgtags Changeset: 29a512337b79 Author: katleman Date: 2011-12-15 15:47 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/29a512337b79 Added tag jdk8-b16 for changeset ec2c0973cc31 ! .hgtags Changeset: ab1b1cc78577 Author: katleman Date: 2011-12-15 15:57 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/ab1b1cc78577 Merge ! .hgtags - test/tools/javac/parser/netbeans/JavacParserTest.java Changeset: ab2a880cc23b Author: lana Date: 2011-12-15 19:53 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/ab2a880cc23b Merge Changeset: 6b773fdeb633 Author: jjg Date: 2011-12-16 13:49 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/6b773fdeb633 7121961: javadoc is missing a resource property Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties Changeset: a7a2720c7897 Author: jjh Date: 2011-12-16 16:41 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/a7a2720c7897 7122342: testPrintProcessorInfo/TestWithXstdout.java failed for JDK8 nightly build at 12/16/2011 Summary: Do not pass empty args to javac Reviewed-by: jjg ! test/tools/javac/processing/options/testPrintProcessorInfo/TestWithXstdout.java Changeset: 1ae5988e201b Author: mcimadamore Date: 2011-12-19 12:07 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/1ae5988e201b 7120463: Fix method reference parser support in order to avoid ambiguities Summary: Add lookahead routine to disambiguate between method reference in method context and binary expression Reviewed-by: jjg, dlsmith ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! test/tools/javac/lambda/MethodReferenceParserTest.java Changeset: 116f68a5e677 Author: jjg Date: 2011-12-23 22:30 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/116f68a5e677 7124605: typos in javac comments Reviewed-by: ksrini ! test/tools/javac/generics/diamond/7046778/DiamondAndInnerClassTest.java ! test/tools/javac/generics/inference/7086601/T7086601b.java ! test/tools/javac/generics/rawOverride/7062745/GenericOverrideTest.java ! test/tools/javac/lambda/LambdaParserTest.java Changeset: 3c71fcc22b99 Author: cl Date: 2011-12-22 19:00 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/3c71fcc22b99 Added tag jdk8-b18 for changeset ab1b1cc78577 ! .hgtags Changeset: 77b2c066084c Author: lana Date: 2011-12-23 16:39 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/77b2c066084c Merge - src/share/classes/com/sun/tools/javac/main/JavacOption.java - src/share/classes/com/sun/tools/javac/main/OptionName.java - src/share/classes/com/sun/tools/javac/main/RecognizedOptions.java Changeset: 67512b631961 Author: lana Date: 2011-12-28 10:52 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/67512b631961 Merge Changeset: 7a836147b266 Author: jjg Date: 2012-01-03 11:37 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/7a836147b266 4881269: improve diagnostic for ill-formed tokens Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/IllegalDot.java + test/tools/javac/parser/T4881269.java + test/tools/javac/parser/T4881269.out Changeset: 65f76ffb8095 Author: jjg Date: 2012-01-04 12:46 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/65f76ffb8095 Merge ! .hgtags ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Enter.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/Modules.java ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/share/classes/com/sun/tools/javac/file/Locations.java ! src/share/classes/com/sun/tools/javac/jigsaw/JigsawModuleResolver.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/jvm/Target.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java - src/share/classes/com/sun/tools/javac/main/JavacOption.java ! src/share/classes/com/sun/tools/javac/main/Main.java + src/share/classes/com/sun/tools/javac/main/Option.java - src/share/classes/com/sun/tools/javac/main/OptionName.java - src/share/classes/com/sun/tools/javac/main/RecognizedOptions.java ! src/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/4846262/Test.sh ! test/tools/javac/lambda/MethodReferenceParserTest.java - test/tools/javac/parser/netbeans/JavacParserTest.java Changeset: 92271a5b0647 Author: alanb Date: 2012-01-16 15:37 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/92271a5b0647 Need to create Service with index/impl_index ! src/share/classes/com/sun/tools/classfile/ModuleProvides_attribute.java Changeset: 583ebefb8aad Author: mchung Date: 2012-01-24 19:11 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/583ebefb8aad jigsaw API update ! src/share/classes/com/sun/tools/javac/jigsaw/JavacCatalog.java From mandy.chung at oracle.com Thu Jan 26 19:18:01 2012 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 27 Jan 2012 03:18:01 +0000 Subject: hg: jigsaw/jigsaw/jdk: Missed hg remove a file in the module views changeset Message-ID: <20120127031812.1B7DC471F5@hg.openjdk.java.net> Changeset: 71a6e9559cbb Author: mchung Date: 2012-01-26 19:17 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/71a6e9559cbb Missed hg remove a file in the module views changeset - make/tools/classanalyzer/src/com/sun/classanalyzer/PlatformModuleBuilder.java From mandy.chung at oracle.com Thu Jan 26 20:15:43 2012 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 27 Jan 2012 04:15:43 +0000 Subject: hg: jigsaw/jigsaw/jdk: Remove module annotation support Message-ID: <20120127041553.5F87A471FD@hg.openjdk.java.net> Changeset: 04b4c8c3596a Author: mchung Date: 2012-01-26 20:15 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/04b4c8c3596a Remove module annotation support - make/modules/update_module.sh - src/share/classes/java/lang/module/ModuleInfoAnnotation.java - src/share/classes/java/lang/module/UnsupportedElementTypeException.java - test/java/lang/module/ModuleAnnotationTest.java - test/java/lang/module/module-info-annotation.sh - test/java/lang/reflect/Module/ModuleAnnotationTest.java - test/java/lang/reflect/Module/module-annotation.sh From jesse.glick at oracle.com Fri Jan 27 07:07:43 2012 From: jesse.glick at oracle.com (Jesse Glick) Date: Fri, 27 Jan 2012 10:07:43 -0500 Subject: hg: jigsaw/jigsaw/jdk: Remove module annotation support In-Reply-To: <20120127041553.5F87A471FD@hg.openjdk.java.net> References: <20120127041553.5F87A471FD@hg.openjdk.java.net> Message-ID: <4F22BDBF.1090908@oracle.com> On 01/26/2012 11:15 PM, mandy.chung at oracle.com wrote: > URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/04b4c8c3596a > Remove module annotation support Was there some alternate plan for making the contents of module-info.java extensible by third parties? From Alan.Bateman at oracle.com Fri Jan 27 07:19:15 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 27 Jan 2012 15:19:15 +0000 Subject: hg: jigsaw/jigsaw/jdk: Remove module annotation support In-Reply-To: <4F22BDBF.1090908@oracle.com> References: <20120127041553.5F87A471FD@hg.openjdk.java.net> <4F22BDBF.1090908@oracle.com> Message-ID: <4F22C073.5000006@oracle.com> On 27/01/2012 15:07, Jesse Glick wrote: > On 01/26/2012 11:15 PM, mandy.chung at oracle.com wrote: >> URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/04b4c8c3596a >> Remove module annotation support > > Was there some alternate plan for making the contents of > module-info.java extensible by third parties? Anything after the module declaration is passed through by the compiler into the ModuleData attribute. -Alan. From reinier at zwitserloot.com Fri Jan 27 07:49:43 2012 From: reinier at zwitserloot.com (Reinier Zwitserloot) Date: Fri, 27 Jan 2012 16:49:43 +0100 Subject: State of jigsaw: Description of module file format? In-Reply-To: <20120124160752.E8781D18@eggemoggin.niobe.net> References: <20120124160752.E8781D18@eggemoggin.niobe.net> Message-ID: Would it be possible to consider adding such a feature? Three ways to go that come to mind: A) Create a new section type for 'source', 'javadoc' and for 'license'. Define the content of license to just be the license text. 'source' and 'javadoc' are analogous to the resources section, with SubSectionFileHeader describing the files using the same path restrictions as class files, i.e. the javadoc of my/package/name/MyClass.class is found in the javadoc section, in the SubSection with path my/package/name/MyClass.html. The source is in the 'source' section, SubSection my/package/name/MyClass.java. Existing tooling (incl. netbeans, intelliJ, and eclipse) manage to figure this out once you provide them 3 separate archive files, one with javadoc, one with source, and one with class files, using the same model, so presumably this should be enough. B) Create a new section type for 'extra data'. Extra data sections have no subsections, and the data associated with it starts with a newline-terminated key string, such as "source" or "license", followed by some data. Presumably for licenses this data will be the raw license text, and for source files it will be an archive file stream, presumably in zip format. This method is a little easier on the module description file format and is easier to expand on later, but it requires 2 very different processors for handling class data vs. source/javadoc data for tools. C) Hack the functionality into the 'resources' section, using some accepted initial path (src/ and api/ for example). While option A requires some additional work in the jigsaw spec, it does appear to offer some unique advantages: * Tooling can use the same code they already use to read class data to read javadoc/src. * Any module file format consumer (including the JVM) can stream past the javadoc/src or even jump right past if the module source is random access by skipping the entire section; all that needs to be read to do this is the section header (section type + size). * No risk of different pseudo-standards as every IDE attempts to define their own magic prefix path in the resource section for source/javadoc. * Trivial to write size optimizer that strips sections out that aren't required to run the module. It's not that much harder to write such a tool in any of the other scenarios, but if 'src/' and 'api/' files in the resource section are merely strongly assumed to be irrelevant but never officially defined as such, this tool would not be entirely safe to use (there's always a chance the app itself does need these files and picked an unfortunate path name to store these resources into). Looking at the buid side of existing module-esque systems, such as ivy and maven, indicates there's a need for such a feature (for example, to publish to maven-central, source and javadoc has to be there, and all 3 (production jar, javadoc zip, and source zip) are as a rule available for any project there. >From a more practical standpoint, being able to see the API documentation when using a library, or jump into the source either to just review how a third party library's code works or to allow the debugger to jump into a method call is a rather useful aspect, and all the 3 major IDEs have ways to associate javadoc/source with a library dependency in order to accomplish these things. It would be nice if a single module file is all you need to download and link into your IDE or debugger without the hassle of having to also ship the source and javadoc separately. --Reinier Zwitserloot On Tue, Jan 24, 2012 at 17:07, wrote: > 2012/1/23 23:38 -0800, reinier at zwitserloot.com: > > I noticed this document: > > http://cr.openjdk.java.net/~mr/jigsaw/notes/jigsaw-big-picture-01 > > > > Does not cover the module file format. > > No, not yet. The Jigsaw project page links to a (slightly out-of-date) > description, here: > > http://cr.openjdk.java.net/~mr/jigsaw/notes/module-file-format/ > > There is at present no provision for source code, javadoc, or license > text. > > - Mark > From jesse.glick at oracle.com Fri Jan 27 08:12:27 2012 From: jesse.glick at oracle.com (Jesse Glick) Date: Fri, 27 Jan 2012 11:12:27 -0500 Subject: hg: jigsaw/jigsaw/jdk: Remove module annotation support In-Reply-To: <4F22C073.5000006@oracle.com> References: <20120127041553.5F87A471FD@hg.openjdk.java.net> <4F22BDBF.1090908@oracle.com> <4F22C073.5000006@oracle.com> Message-ID: <4F22CCEB.6060300@oracle.com> On 01/27/2012 10:19 AM, Alan Bateman wrote: > Anything after the module declaration is passed through by the compiler into the ModuleData attribute. lang-vm.html [1] does not seem to mention this but perhaps it is too old. Seems I can indeed write module foo {} hibernateconfig "stuff.xml"; Hi mom! and that compiles. So, how would such things be checked for syntax or semantics? How would different tools avoid clobbering each other's metadata? Annotations at least have a well-defined syntax, and a well-defined mechanism for semantic validation (JSR 269). [1] http://openjdk.java.net/projects/jigsaw/doc/lang-vm.html From jesse.glick at oracle.com Fri Jan 27 09:00:17 2012 From: jesse.glick at oracle.com (Jesse Glick) Date: Fri, 27 Jan 2012 12:00:17 -0500 Subject: Source/Javadoc links (was: Description of module file format?) In-Reply-To: References: <20120124160752.E8781D18@eggemoggin.niobe.net> Message-ID: <4F22D821.8010603@oracle.com> On 01/27/2012 10:49 AM, Reinier Zwitserloot wrote: > Trivial to write size optimizer that strips sections out that aren't > required to run the module. For example, for deployment to an embedded device, or via JNLP or applet. I do not see any compelling reason to strip out optional sections for SE desktop deployment - disks are cheap these days. I agree that a well-defined location is critical, and including this information right in the jmod rather than a separate artifact is desirable for simplicity. (OSGi defines the OSGI-OPT/ ZIP path prefix which it guarantees can be safely stripped out, but does not define more than that as far as I know.) > being able to see the API documentation > when using a library, or jump into the source either to just review how a > third party library's code works or to allow the debugger to jump into a > method call is a rather useful aspect Yes, this is absolutely crucial for developer productivity when using third-party libraries - or even your own libraries that you just happen to be referencing by well-known version in the repository, rather than via collocation in a source checkout. I work on Maven support in NetBeans and I can say that automatic association of sources and Javadoc with a dependency (downloading them on demand in that case) is a key feature, one of the primary "pain points" when using something like plain Ant without a repository concept. In my experience sources are much more important than Javadoc, so if package size is a concern dropping Javadoc but keeping sources would be reasonable. An IDE can essentially reconstruct Javadoc from source files during code completion anyway - and formatted appropriately for that tool rather than a web browser. You can always publish HTML Javadoc on your project site but once users start really writing code this is not likely to be the preferred medium. There are of course some subtleties in producing on-the-fly documentation: 1. The javadoc tool lets you decide which packages & classes, and which access levels, to document. I think this is superseded by the exports list of the module. 2. The tool lets you enable or disable display of @author and @version and the like. But an IDE (or other source-consuming tool) can just have a personal preference for displaying these. 3. HTML generation lets you link to other Javadoc sets. Probably superseded by the requires clause of the module: if sources are available for other libraries (or HTML Javadoc has been associated by some other means), then a tool can trivially link to them itself. 4. Custom doclets are probably inappropriate for general-purpose consumption, especially by a tool which may have its own specialized way of displaying library documentation to begin with. 5. Custom taglets are a more interesting case, since these would actually be specific to certain projects. How widely used are these? To what extent are these superseded by @Documented annotations? When they are not trivially replaced with an annotation, does it make sense to declare required taglets in module-info.java, so that they would both be run automatically by javadoc with special parameters, and interpretable by IDEs which wish to support this feature (running the taglet in a sandbox)? Custom -tag looks to be superseded by annotations. 6. Some libraries include custom content under doc-files/ subdirs, generally HTML pages and maybe some images. I suppose these could be preserved as is in the source section of a jmod. 7. Documentation written in a language other than English is uncommon but a consideration. If the only documentation - that written in source files itself - is in another language, then to reconstruct summary sentences properly you need to know to use the right BreakIterator. (If the primary documentation is in English but translated documentation is available separately, then probably nothing special needs to happen in the jmod: an IDE user can explicitly associate the translated documentation with the library.) From jonathan.gibbons at oracle.com Fri Jan 27 13:37:12 2012 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 27 Jan 2012 13:37:12 -0800 Subject: javac: "legacy" mode Message-ID: <4F231908.1020001@oracle.com> Until recently, javac implicitly supported "legacy" compilations (meaning compilations that were valid in JDK 7 or earlier). This was as side-effect by design of "single-module mode", because the default requires if none was given was "jdk at 8-ea". Now, we have changed the default requires to "java.base@>=8". This means that without any other changes, a legacy compilation referencing non-base classes will fail to compile. There are two possible solutions. 1. Have javac support -Xmode:legacy, which would change the default requires. It would also require everyone to change the way they use javac for legacy compilations. 2. Distinguish between the case of no module compilation units in a compilation and module compilation units involved, but not containing any requires on the base module. If no module compilation unit is observable, one would be synthesized containing "requires jdk;" or some equivalent. If any observable module compilation unit does not contain a requires for the platform base, then a "requires java.base>=N;" will be generated, with an appropriate value of N, per the spec. -- Jon From alex.buckley at oracle.com Fri Jan 27 14:02:31 2012 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 27 Jan 2012 14:02:31 -0800 Subject: hg: jigsaw/jigsaw/jdk: Remove module annotation support In-Reply-To: <4F22CCEB.6060300@oracle.com> References: <20120127041553.5F87A471FD@hg.openjdk.java.net> <4F22BDBF.1090908@oracle.com> <4F22C073.5000006@oracle.com> <4F22CCEB.6060300@oracle.com> Message-ID: <4F231EF7.1070002@oracle.com> On 1/27/2012 8:12 AM, Jesse Glick wrote: > On 01/27/2012 10:19 AM, Alan Bateman wrote: >> Anything after the module declaration is passed through by the >> compiler into the ModuleData attribute. > > lang-vm.html [1] does not seem to mention this but perhaps it is too > old. It doesn't mention it because it doesn't need to. The limit of the Java language is the CompilationUnit production. A compiler is free to parse text outside that production and store it in a ModuleData attribute. > Seems I can indeed write > > module foo {} > hibernateconfig "stuff.xml"; > Hi mom! > > and that compiles. So, how would such things be checked for syntax or > semantics? How would different tools avoid clobbering each other's > metadata? They won't be checked for syntax or semantics because they're not part of the Java language or module system. See http://openjdk.java.net/projects/jigsaw/doc/draft-java-module-system-requirements-12#extensible-module-declarations. Alex From jesse.glick at oracle.com Fri Jan 27 14:29:26 2012 From: jesse.glick at oracle.com (Jesse Glick) Date: Fri, 27 Jan 2012 17:29:26 -0500 Subject: hg: jigsaw/jigsaw/jdk: Remove module annotation support In-Reply-To: <4F231EF7.1070002@oracle.com> References: <20120127041553.5F87A471FD@hg.openjdk.java.net> <4F22BDBF.1090908@oracle.com> <4F22C073.5000006@oracle.com> <4F22CCEB.6060300@oracle.com> <4F231EF7.1070002@oracle.com> Message-ID: <4F232546.7020508@oracle.com> On 01/27/2012 05:02 PM, Alex Buckley wrote: > It doesn't mention it because it doesn't need to. The limit of the Java language is the CompilationUnit production. A compiler is free to parse text outside that > production and store it in a ModuleData attribute. This is bizarre. You cannot append random text to the end of regular Java source files. X.java:1: error: class, interface, or enum expected class X {} hello world! ^ 1 error >> how would such things be checked for syntax or >> semantics? How would different tools avoid clobbering each other's >> metadata? > > They won't be checked for syntax or semantics because they're not part of the Java language or module system. See > http://openjdk.java.net/projects/jigsaw/doc/draft-java-module-system-requirements-12#extensible-module-declarations. There needs to be some convention or guideline for other tools to be able to cooperatively edit such metadata. Otherwise it is rather useless - you could not even tell for sure what kind of tool is doing the extending and add your own separate metadata! Annotations with an extension of 269 would offer fully validatable extensibility consistent with the rest of the Java language, but even something as simple as /([^:]+: .*\n)*/ key-value pairs (like JAR manifests) would be far better than this. From peter.jensen at oracle.com Fri Jan 27 14:30:42 2012 From: peter.jensen at oracle.com (Peter Jensen) Date: Fri, 27 Jan 2012 14:30:42 -0800 Subject: javac: "legacy" mode In-Reply-To: <4F231908.1020001@oracle.com> References: <4F231908.1020001@oracle.com> Message-ID: <4F232592.8050501@oracle.com> On 01/27/12 13:37, Jonathan Gibbons wrote: > Until recently, javac implicitly supported "legacy" compilations > (meaning compilations that were valid in JDK 7 or earlier). This was > as side-effect by design of "single-module mode", because the default > requires if none was given was "jdk at 8-ea". > > Now, we have changed the default requires to "java.base@>=8". This > means that without any other changes, a legacy compilation referencing > non-base classes will fail to compile. > > There are two possible solutions. > > 1. Have javac support -Xmode:legacy, which would change the default > requires. It would also require everyone to change the way they use > javac for legacy compilations. That pretty much seems like a no-go, for legacy tooling. > > 2. Distinguish between the case of no module compilation units in a > compilation and module compilation units involved, but not containing > any requires on the base module. If no module compilation unit is > observable, one would be synthesized containing "requires jdk;" or > some equivalent. If any observable module compilation unit does not > contain a requires for the platform base, then a "requires > java.base>=N;" will be generated, with an appropriate value of N, per > the spec. What happens if I have some classes, compiled in legacy mode, and I want to mix them into a module? Example: I may not have the source files, but I really want to reuse these classes. > > -- Jon > From alex.buckley at oracle.com Fri Jan 27 14:38:11 2012 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 27 Jan 2012 14:38:11 -0800 Subject: hg: jigsaw/jigsaw/jdk: Remove module annotation support In-Reply-To: <4F232546.7020508@oracle.com> References: <20120127041553.5F87A471FD@hg.openjdk.java.net> <4F22BDBF.1090908@oracle.com> <4F22C073.5000006@oracle.com> <4F22CCEB.6060300@oracle.com> <4F231EF7.1070002@oracle.com> <4F232546.7020508@oracle.com> Message-ID: <4F232753.4050706@oracle.com> On 1/27/2012 2:29 PM, Jesse Glick wrote: > This is bizarre. You cannot append random text to the end of regular > Java source files. > > X.java:1: error: class, interface, or enum expected > class X {} hello world! > ^ > 1 error In deference to the module system's requirement for extensible metadata, javac chooses to allow extra text in a file when a CompilationUnit contains a module declaration. You can guess how it stores such text in a class file. > There needs to be some convention or guideline for other tools to be > able to cooperatively edit such metadata. Otherwise it is rather useless > - you could not even tell for sure what kind of tool is doing the > extending and add your own separate metadata! Annotations with an > extension of 269 would offer fully validatable extensibility consistent > with the rest of the Java language, but even something as simple as > /([^:]+: .*\n)*/ key-value pairs (like JAR manifests) would be far > better than this. As ever, Jesse, we understand all this. Since the requirement for the syntax of a module declaration (and therefore its extensibility) is open, we have chosen to proceed down a particular path in the implementation. Alex From jonathan.gibbons at oracle.com Fri Jan 27 14:49:16 2012 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 27 Jan 2012 14:49:16 -0800 Subject: hg: jigsaw/jigsaw/jdk: Remove module annotation support In-Reply-To: <4F232546.7020508@oracle.com> References: <20120127041553.5F87A471FD@hg.openjdk.java.net> <4F22BDBF.1090908@oracle.com> <4F22C073.5000006@oracle.com> <4F22CCEB.6060300@oracle.com> <4F231EF7.1070002@oracle.com> <4F232546.7020508@oracle.com> Message-ID: <4F2329EC.3070805@oracle.com> On 01/27/2012 02:29 PM, Jesse Glick wrote: > On 01/27/2012 05:02 PM, Alex Buckley wrote: >> It doesn't mention it because it doesn't need to. The limit of the >> Java language is the CompilationUnit production. A compiler is free >> to parse text outside that >> production and store it in a ModuleData attribute. > > This is bizarre. You cannot append random text to the end of regular > Java source files. > > X.java:1: error: class, interface, or enum expected > class X {} hello world! > ^ > 1 error The difference is in the grammar, and in the curlies around TypeDeclaration. After one type declaration, you can have another, and another, so the syntax error you are seeing comes because javac is trying to parse your "hello world!" text as a TypeDeclaration. In contrast, there is no need for javac to read beyond the end of a ModuleDeclaration. CompilationUnit: [PackageDeclaration] {ImportDeclaration} {TypeDeclaration} [ModuleDeclaration] > >>> how would such things be checked for syntax or >>> semantics? How would different tools avoid clobbering each other's >>> metadata? >> >> They won't be checked for syntax or semantics because they're not >> part of the Java language or module system. See >> http://openjdk.java.net/projects/jigsaw/doc/draft-java-module-system-requirements-12#extensible-module-declarations. >> > > There needs to be some convention or guideline for other tools to be > able to cooperatively edit such metadata. Otherwise it is rather > useless - you could not even tell for sure what kind of tool is doing > the extending and add your own separate metadata! Annotations with an > extension of 269 would offer fully validatable extensibility > consistent with the rest of the Java language, but even something as > simple as /([^:]+: .*\n)*/ key-value pairs (like JAR manifests) would > be far better than this. One might reasonably expect that those that are interested to do so could reasonably establish such a guideline. I couldn't possibly comment. You could even have a doctype sort of directive, and encoding info even, immediately after the close curly, to describe the coding convention for what follows. :-) Note: javac currently trims any whitespace between the close-curly and the first non-whitespace character, when it writes the ModuleData attribute, and does not write a ModuleData attribute if there is only whitespace after the close curly. From mandy.chung at oracle.com Fri Jan 27 17:28:56 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 27 Jan 2012 17:28:56 -0800 Subject: javac: "legacy" mode In-Reply-To: <4F231908.1020001@oracle.com> References: <4F231908.1020001@oracle.com> Message-ID: <4F234F58.9040002@oracle.com> On 1/27/2012 1:37 PM, Jonathan Gibbons wrote: > Until recently, javac implicitly supported "legacy" compilations > (meaning compilations that were valid in JDK 7 or earlier). This was > as side-effect by design of "single-module mode", because the default > requires if none was given was "jdk at 8-ea". > > Now, we have changed the default requires to "java.base@>=8". This > means that without any other changes, a legacy compilation referencing > non-base classes will fail to compile. > > There are two possible solutions. > > 1. Have javac support -Xmode:legacy, which would change the default > requires. It would also require everyone to change the way they use > javac for legacy compilations. > This seems a major compatibility concern but it might worth taking the migration story into account. What if javac -source 7 -target 7 uses the entire "jdk" as the default and keep "java.base" as the default for -source 8 -target 8 (possibly provide a switch to say using the entire "jdk" rather than just the base)? I'm in two minds and I think it deserves some more thought. > 2. Distinguish between the case of no module compilation units in a > compilation and module compilation units involved, but not containing > any requires on the base module. If no module compilation unit is > observable, one would be synthesized containing "requires jdk;" or > some equivalent. If any observable module compilation unit does not > contain a requires for the platform base, then a "requires > java.base>=N;" will be generated, with an appropriate value of N, per > the spec. I did some work to support legacy mode in runtime some time ago [1]. I have re-based it with the latest jigsaw forest. It's just a good timing and discuss how legacy mode should work in runtime/compile-time. I should restart this work soon. Mandy [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2010-June/001061.html From ekaterina.pavlova at oracle.com Fri Jan 27 21:49:28 2012 From: ekaterina.pavlova at oracle.com (Ekaterina Pavlova) Date: Fri, 27 Jan 2012 21:49:28 -0800 Subject: javac: "legacy" mode In-Reply-To: <4F234F58.9040002@oracle.com> References: <4F231908.1020001@oracle.com> <4F234F58.9040002@oracle.com> Message-ID: <4F238C68.2010003@oracle.com> On 1/27/12 5:28 PM, Mandy Chung wrote: > On 1/27/2012 1:37 PM, Jonathan Gibbons wrote: >> Until recently, javac implicitly supported "legacy" compilations (meaning compilations that were valid in JDK 7 or earlier). This was as side-effect by design of >> "single-module mode", because the default requires if none was given was "jdk at 8-ea". >> >> Now, we have changed the default requires to "java.base@>=8". This means that without any other changes, a legacy compilation referencing non-base classes will fail to >> compile. >> >> There are two possible solutions. >> >> 1. Have javac support -Xmode:legacy, which would change the default requires. It would also require everyone to change the way they use javac for legacy compilations. >> > > This seems a major compatibility concern but it might worth taking the migration story into account. What if javac > -source 7 -target 7 uses the entire "jdk" as the default > and keep "java.base" as the default for -source 8 -target 8 (possibly provide a switch to say using the entire "jdk" > rather than just the base)? I'm in two minds and I > think it deserves some more thought. Perhaps introduce something like -Xmode:module and keep legacy mode as default one is more safe as the compatibility will not be broken. Later defaults can be changed. -katya From jonathan.gibbons at oracle.com Sat Jan 28 08:37:03 2012 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Sat, 28 Jan 2012 08:37:03 -0800 Subject: javac: "legacy" mode In-Reply-To: <4F238C68.2010003@oracle.com> References: <4F231908.1020001@oracle.com> <4F234F58.9040002@oracle.com> <4F238C68.2010003@oracle.com> Message-ID: <4F24242F.7000000@oracle.com> On 01/27/2012 09:49 PM, Ekaterina Pavlova wrote: > On 1/27/12 5:28 PM, Mandy Chung wrote: >> On 1/27/2012 1:37 PM, Jonathan Gibbons wrote: >>> Until recently, javac implicitly supported "legacy" compilations >>> (meaning compilations that were valid in JDK 7 or earlier). This was >>> as side-effect by design of >>> "single-module mode", because the default requires if none was given >>> was "jdk at 8-ea". >>> >>> Now, we have changed the default requires to "java.base@>=8". This >>> means that without any other changes, a legacy compilation >>> referencing non-base classes will fail to >>> compile. >>> >>> There are two possible solutions. >>> >>> 1. Have javac support -Xmode:legacy, which would change the default >>> requires. It would also require everyone to change the way they use >>> javac for legacy compilations. >>> >> >> This seems a major compatibility concern but it might worth taking >> the migration story into account. What if javac >> -source 7 -target 7 uses the entire "jdk" as the default >> and keep "java.base" as the default for -source 8 -target 8 (possibly >> provide a switch to say using the entire "jdk" >> rather than just the base)? I'm in two minds and I >> think it deserves some more thought. > > Perhaps introduce something like -Xmode:module and keep legacy mode as > default one > is more safe as the compatibility will not be broken. > Later defaults can be changed. > > -katya I think it is more helpful to have javac just "do the right thing". There are three recognizable types of compilation for javac, roughly corresponding to 0, 1, many module-info files in the compilation. legacy mode: no module-path option, no module-info to be compiled or on classpath source hierarchy is organized by packages, as now output dir will be organized by packages, as now single module mode: class path set, or module path not set source hierarchy is organized by packages, as now output dir will be organized by packages, as now multi-module mode module path set but not class path. source hierarchy must be organized by modules. output dir will be organized by modules The presumption is that in legacy mode, you should have access to all JDK classes. In either module mode, unless you specify otherwise, a module will only have access to the classes in the java.base module. I also think we should add to -verbose, so that javac can be more informative about the type of compilation it is doing -- Jon From reinier at zwitserloot.com Mon Jan 30 08:53:17 2012 From: reinier at zwitserloot.com (Reinier Zwitserloot) Date: Mon, 30 Jan 2012 17:53:17 +0100 Subject: -encoding and -source in module-info.java In-Reply-To: References: <4F1E9F01.1090809@oracle.com> Message-ID: +1 on this excellent idea. In regards to neal's hammering on how 'source' is not particularly conducive to inclusion in a language spec: There's an easy anwer to this problem: The same answer used to skirt around the classpath issue. The JLS would simply say that the format of this directive is something along the lines of: source 1.8; where the exact format of the 'parameter' to source is: Sequence(ZeroOrMore(Sequence(DIGITS, '.')), DIGITS) and exactly 0 or 1 source directives may exist in module-info.java, probably with some further restrictions on where this directive is legally allowed to appear. I'll leave the exact details to be hashed out later; the point is: The JLS does not have to convey legal values for this directive, it merely needs to define the format for it. This parameter will be interpreted by the compiler, and the compiler is then entirely free to figure out what this means all by itself. At best, the spec can (and probably should) declare that 1.8 (or 8) _MUST_ be a legal value, with nothing said about any other value. This is 100% analogous to how classpath is handled: The language spec is quite clear on what "import java.util.Arrays;" means, and the language spec is quite clear on how one should resolve the statement "Arrays.asList(someInteger, someDouble, someInteger);" _once the compiler knows the signatures present in java.util.Arrays_, but it gives absolutely no hint whatsoever as to how the compiler is supposed to figure out what those signatures are, when provided with only an import statement. Without the spec defining how to get these signatures, the correct answer to 'how should I translate Arrays.asList(a, b, c) to bytecode' is dependent on external factors too, i.e. the spec alone cannot give a definitive answer. The JLS does not even mention the classpath nor the JVMS which needs to be used to parse the classfiles one would find there in order to find the signatures of Arrays, which is necessary to correctly resolve method calls. - Let alone specify any of these things. Thus, we arrive at a perhaps somewhat uncomfortable fact: Given just the JLS, it is impossible to write a compiler that can compile anything except the simplest source files (namely: Ones with 0 dependencies in them, not even a dependency on java.lang.String, as the JLS does not specify the signatures present in the String class). It can't even give you an LST, because it cannot resolve method calls. Given that, I don't see any problem with being similarly unspecified for parameters to the 'source' directive that aren't "1.8". Specifying 'source' that way (1.8 is legal, everything else - who knows?) thus doesn't change anything about how the JLS itself is not actually enough, you need a 'meta-spec' a level above that to end up with a practically usable compiler. The encoding issue can be similarly solved (do not actually define in the JLS spec what to do with this directive, just define what it should look like and add a note if needed to explain its general intent, leaving it clear that it's up to the compiler to do sensible things with this meta-information), but the case here is not quite as strong as for 'source'. It might be a good idea to write a sister specification which lists minimum legal compiler switches and defines what a compiler is supposed to do with various meta-information. This specification should go into classpath, sourcepath, warning levels for -Xlint (and push -Xlint out of -X territory. In fact, this spec should list every non -X switch and not mention anything about -X switches except the idea that -X itself is implementation-specific), how the lightweight encoding directive is supposed to be found, links to all the different JLS spec versions and specifications on how to handle -source and -target (and the source directive), and rules that any -encoding parameter (or directive) in a given list MUST be parsed correctly in order to warrant the title 'java compiler'. This spec can use 'can' and 'must' as appropriate. For example, a java1.8 compatible compiler MUST understand 'source 1.8;' and MAY treat 'source 1.7;' as a directive to compile according to the JLS 1.7. If it does not do so, then it MUST emit a 'not compatible with that source version' error. --Reinier Zwitserloot On Tue, Jan 24, 2012 at 22:35, Neal Gafter wrote: > Overall, I agree it would be nice to place these options together in a file > for the compiler to consume. I just don't think it should be a "Java > programming language source" file. > > The idea of using module-info.java to specify compilation options seems > most tempting, but as long as it is a source file in the language, it must > be subject to those options as well. Which means that specifying them > inside the file itself is pretty pointless. As to the source level, what > can the language specification say other than that "8" is the only allowed > value? And what can the next version of the language specification say > other than that "9" is the only allowed value? > > On Tue, Jan 24, 2012 at 4:07 AM, Jesse Glick > wrote: > > > The encoding and source level of a module are fundamental attributes of > > its sources, without which you cannot reliably even parse a syntax tree, > so > > I think they should be declared in module-info.java. Otherwise it is left > > up to someone calling javac by hand, or a build script, to specify these > > options; that is potentially error-prone, and means that tools which > > inspect sources (including but not limited to IDEs) need to have some > > separate mechanism for configuration of these attributes: you cannot just > > hand them the sourcepath and let them run. > > > > I am assuming that all files in the sourcepath use the same encoding and > > source level, which seems a reasonable restriction. > > > > > > As to the source level, obviously given that JDK 8 will introduce > > module-info.java, "8" (or "1.8") seems like the right default value; but > a > > syntax ought to be defined for specifying a newer level, e.g. > > > > source 1.9; // or 9? > > > > Furthermore I think that JDK 9+ versions of javac should keep the same > > default source level - you should need to explicitly mark what version of > > the Java language your module expects. Otherwise a module might compile > > differently according to which version of javac was used, which is > > undesirable, and tools cannot guess what version you meant. A little more > > verbosity here seems to be justified. > > > > Whether the bytecode target (-target) should be specified in > > module-info.java is another question. I have seen projects built using > > -target 5 for JDK 5 compatibility but also in a separate artifact using > > -target 6 for speed on JDK 6+ (split verifier). Probably the target level > > should default to the source level, and in the rare case that you need to > > override this, you can do so using a javac command option - this has no > > impact on tools which just need to parse and analyze source files. > > > > > > As to the encoding, something like > > > > encoding ISO-8859-2; > > > > would suffice. The obvious problems for encoding are > > > > 1. What should the default value be? javac currently uses the platform > > default encoding, which IMHO is a horrible choice because it means that > two > > people running javac with the same parameters on the same files may be > > producing different classes and/or warning messages. I would suggest > making > > UTF-8 be the default when compiling in module mode (leaving the old > > behavior intact for legacy mode). For developers who want to keep sources > > in a different character set, adding one line per module-info.java does > not > > seem like much of a burden. > > > > 2. What is module-info.java itself encoded in? If not UTF-8, then you > need > > to be able to reliably find the encoding declaration and then rescan the > > file in that encoding. That is easy for most encodings (just do an > initial > > scan in ISO-8859-1), including everything commonly used by developers > > AFAIK; a little trickier for UTF-16/32-type encodings but possible by > > ignoring 0x00/0xFE/0xFF; and only fails on some mainframe charsets, old > JIS > > variants, and dingbats (*). Even those rare cases are probably guessable. > > [1] > > > > > > (*) Demo program: > > > > import java.io.**UnsupportedEncodingException; > > import java.nio.charset.Charset; > > import java.util.Arrays; > > public class CharsetTest { > > public static void main(String[] args) throws > > UnsupportedEncodingException { > > Charset raw = Charset.forName("ISO-8859-1"); > > for (Charset c : Charset.availableCharsets().**values()) { > > String text = "/* leading comment */\nmodule test {\n > encoding > > " + c.name() + ";\n}\n"; > > byte[] encoded; > > try { > > encoded = text.getBytes(c); > > } catch (UnsupportedOperationException x) { > > System.out.println("cannot encode using " + c.name()); > > continue; > > } > > if (Arrays.equals(encoded, text.getBytes(raw))) { > > System.out.println("OK in " + c.name()); > > } else if (new String(encoded, raw).contains(" encoding " + > > c.name() + ";")) { > > System.out.println("substring match in " + c.name()); > > dump(encoded); > > } else if (new String(encoded, raw).replace("\u0000", > > "").contains(" encoding " + c.name() + ";")) { > > System.out.println("NUL-**stripped match in " + c.name > ()); > > dump(encoded); > > } else { > > System.out.println("garbled in " + c.name()); > > dump(encoded); > > } > > } > > } > > private static void dump(byte[] encoded) { > > for (byte b : encoded) { > > if (b >= 32 && b <= 126 || b == '\n' || b == '\r') { > > System.out.write(b); > > } else if (b == 0) { > > System.out.print('@'); > > } else { > > System.out.printf("\\%02X", b); > > } > > } > > System.out.println(); > > } > > private CharsetTest() {} > > } > > > > > > [1] http://jchardet.sourceforge.**net/ > > > > From alex.buckley at oracle.com Mon Jan 30 12:04:39 2012 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 30 Jan 2012 12:04:39 -0800 Subject: -encoding and -source in module-info.java In-Reply-To: References: <4F1E9F01.1090809@oracle.com> Message-ID: <4F26F7D7.3080208@oracle.com> The JLS is not going to define syntax for a 'source' declaration and then leave it up to compilers to interpret. It is bad enough that the JLS defers to "host system" for resolving dependences, and that will be fixed with a standard module system configured from the language. We're not going to take two steps forward, then one step back. The idea of explicit source levels _in the language_ comes up every few years. I assume people want to use it as a backdoor way of removing language features. But that is off-topic for this list. On 1/30/2012 8:53 AM, Reinier Zwitserloot wrote: > It might be a good idea to write a sister specification which lists minimum > legal compiler switches and defines what a compiler is supposed to do with > various meta-information. This specification should go into classpath, > sourcepath, warning levels for -Xlint (and push -Xlint out of -X territory. Sounds good. Please discuss further on compiler-dev, not jigsaw-dev. Alex From reinier at zwitserloot.com Mon Jan 30 12:27:07 2012 From: reinier at zwitserloot.com (Reinier Zwitserloot) Date: Mon, 30 Jan 2012 21:27:07 +0100 Subject: -encoding and -source in module-info.java In-Reply-To: <4F26F7D7.3080208@oracle.com> References: <4F1E9F01.1090809@oracle.com> <4F26F7D7.3080208@oracle.com> Message-ID: Okay. What's the inherent problem in specifying inside the JLS: (A) The 'home' value (for the JLS8, that would be 8/1.8) has to be supported, (B) a mapping from version values to links to older versions of the JLS, and (C) that a compiler may choose to compile any version listed in the mapping according to that spec, OR emit a warning that its interpreting the source file according to some other JLS and that this might not be what the user wanted. The only thing left up to the compiler is which of the various JLS versions that it supports will be used to parse and compile the file, and that, if it's not an exact match to the source directive if present, a warning must be emitted. As a consequence of that specification, ONLY implementing the 'home' value (1.8) and emitting warnings if the source directive doesn't match it, is a valid implementation. This is not a backdoor strategy to get incompatible changes introduced into the JLS. It's just useful. If it wasn't, why does -source even exist in the first place? As Jesse Glick said, it would be fantastic if a module, either in precompiled state (i.e. the root directory of a module-info.java and all its related source file), as well as postcompiled state (jmod file) are 100% self-describing. They would be if this kind of meta-data is pulled into the module itself. NB: I'd be in favour of deprecating and then eventually removing some exceedingly rarely used language features such as postfix array brackets for variables and especially method declarations, i.e. public int iReturnAnIntArray() [] {}, and doing so would be made possible by in-band source directives, but that's not the point of this request - the point is to let a module be self-descriptive. The fact that it does open the door on perhaps one day deprecating existing language syntax is a mostly irrelevant bonus. --Reinier Zwitserloot On Mon, Jan 30, 2012 at 21:04, Alex Buckley wrote: > The JLS is not going to define syntax for a 'source' declaration and then > leave it up to compilers to interpret. It is bad enough that the JLS defers > to "host system" for resolving dependences, and that will be fixed with a > standard module system configured from the language. We're not going to > take two steps forward, then one step back. > > The idea of explicit source levels _in the language_ comes up every few > years. I assume people want to use it as a backdoor way of removing > language features. But that is off-topic for this list. > > > On 1/30/2012 8:53 AM, Reinier Zwitserloot wrote: > >> It might be a good idea to write a sister specification which lists >> minimum >> legal compiler switches and defines what a compiler is supposed to do with >> various meta-information. This specification should go into classpath, >> sourcepath, warning levels for -Xlint (and push -Xlint out of -X >> territory. >> > > Sounds good. Please discuss further on compiler-dev, not jigsaw-dev. > > Alex > From alex.buckley at oracle.com Mon Jan 30 12:31:56 2012 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 30 Jan 2012 12:31:56 -0800 Subject: -encoding and -source in module-info.java In-Reply-To: References: <4F1E9F01.1090809@oracle.com> <4F26F7D7.3080208@oracle.com> Message-ID: <4F26FE3C.40500@oracle.com> On 1/30/2012 12:27 PM, Reinier Zwitserloot wrote: > As Jesse Glick said, it would be fantastic if a module, either in > precompiled state (i.e. the root directory of a module-info.java and all > its related source file), as well as postcompiled state (jmod file) are > 100% self-describing. They would be if this kind of meta-data is pulled > into the module itself. OK, but that's not currently a requirement the Jigsaw team is working towards. Alex From mandy.chung at oracle.com Mon Jan 30 21:13:41 2012 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 31 Jan 2012 05:13:41 +0000 Subject: hg: jigsaw/jigsaw: 14 new changesets Message-ID: <20120131051342.01D9A47299@hg.openjdk.java.net> Changeset: 4e06ae613e99 Author: katleman Date: 2011-12-01 10:33 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/rev/4e06ae613e99 Added tag jdk8-b15 for changeset a4f28069d44a ! .hgtags Changeset: 8606f4ab62dc Author: katleman Date: 2011-12-15 12:16 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/rev/8606f4ab62dc Added tag jdk8-b17 for changeset 4e06ae613e99 ! .hgtags Changeset: d82d3bb3a2e5 Author: katleman Date: 2011-12-15 15:47 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/rev/d82d3bb3a2e5 Added tag jdk8-b16 for changeset 4e06ae613e99 ! .hgtags Changeset: 7010bd24cdd0 Author: katleman Date: 2011-12-15 15:51 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/rev/7010bd24cdd0 Merge ! .hgtags Changeset: e1fc13802e0c Author: cl Date: 2011-12-22 19:00 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/rev/e1fc13802e0c Added tag jdk8-b18 for changeset 7010bd24cdd0 ! .hgtags Changeset: 9acd7374ff8a Author: ohair Date: 2011-12-12 08:11 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/rev/9acd7374ff8a 7119829: Adjust default jprt testing configuration Reviewed-by: alanb ! make/jprt.properties ! test/Makefile Changeset: 00d13c40d7a7 Author: lana Date: 2011-12-15 19:49 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/rev/00d13c40d7a7 Merge Changeset: 237bc29afbfc Author: lana Date: 2011-12-23 16:36 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/rev/237bc29afbfc Merge Changeset: 5a5eaf6374bc Author: katleman Date: 2011-12-29 15:14 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/rev/5a5eaf6374bc Added tag jdk8-b19 for changeset 237bc29afbfc ! .hgtags Changeset: cc771d92284f Author: katleman Date: 2012-01-05 08:42 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/rev/cc771d92284f Added tag jdk8-b20 for changeset 5a5eaf6374bc ! .hgtags Changeset: 7ad075c80995 Author: katleman Date: 2012-01-13 10:05 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/rev/7ad075c80995 Added tag jdk8-b21 for changeset cc771d92284f ! .hgtags Changeset: 60d6f64a86b1 Author: katleman Date: 2012-01-20 13:08 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/rev/60d6f64a86b1 Added tag jdk8-b22 for changeset 7ad075c80995 ! .hgtags Changeset: 1a5f1d6b98d6 Author: katleman Date: 2012-01-26 18:23 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/rev/1a5f1d6b98d6 Added tag jdk8-b23 for changeset 60d6f64a86b1 ! .hgtags Changeset: 51c793afb1eb Author: mchung Date: 2012-01-30 21:10 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/rev/51c793afb1eb Merge ! .hgtags ! make/jprt.properties ! test/Makefile From mandy.chung at oracle.com Mon Jan 30 21:13:46 2012 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 31 Jan 2012 05:13:46 +0000 Subject: hg: jigsaw/jigsaw/jaxp: 17 new changesets Message-ID: <20120131051347.1D48F4729A@hg.openjdk.java.net> Changeset: 8181f7634e4a Author: katleman Date: 2011-12-01 10:33 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxp/rev/8181f7634e4a Added tag jdk8-b15 for changeset 804f666d6d44 ! .hgtags Changeset: e32444f13774 Author: katleman Date: 2011-12-06 08:43 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxp/rev/e32444f13774 7117162: jdk8/jaxws/Makefile default DROPS_DIR should set to jdk8-drops Reviewed-by: ohair, xdono, mchung ! build.properties ! make/Makefile Changeset: 09eb517404b0 Author: katleman Date: 2011-12-07 13:02 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxp/rev/09eb517404b0 Merge Changeset: db44484a9d6e Author: katleman Date: 2011-12-15 12:16 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxp/rev/db44484a9d6e Added tag jdk8-b17 for changeset 09eb517404b0 ! .hgtags Changeset: bc3ed3122933 Author: katleman Date: 2011-12-15 15:47 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxp/rev/bc3ed3122933 Added tag jdk8-b16 for changeset 09eb517404b0 ! .hgtags Changeset: ebec6a7e8d4e Author: katleman Date: 2011-12-15 15:54 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxp/rev/ebec6a7e8d4e Merge ! .hgtags Changeset: 5fb25931f1c2 Author: cl Date: 2011-12-22 19:00 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxp/rev/5fb25931f1c2 Added tag jdk8-b18 for changeset ebec6a7e8d4e ! .hgtags Changeset: a482d45c93e9 Author: ohair Date: 2011-12-12 08:12 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxp/rev/a482d45c93e9 7117110: Remove target 1.5 from jaxp and jaxws repo builds for mac Reviewed-by: alanb ! build.xml Changeset: a49db7c01db7 Author: ohair Date: 2011-12-12 08:12 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxp/rev/a49db7c01db7 7119829: Adjust default jprt testing configuration Reviewed-by: alanb ! make/jprt.properties Changeset: f26e2ab2c2c7 Author: lana Date: 2011-12-15 19:49 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxp/rev/f26e2ab2c2c7 Merge Changeset: dffeb62b1a7f Author: lana Date: 2011-12-23 16:36 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxp/rev/dffeb62b1a7f Merge Changeset: f052abb8f374 Author: katleman Date: 2011-12-29 15:14 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxp/rev/f052abb8f374 Added tag jdk8-b19 for changeset dffeb62b1a7f ! .hgtags Changeset: d41eeadf5c13 Author: katleman Date: 2012-01-05 08:42 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxp/rev/d41eeadf5c13 Added tag jdk8-b20 for changeset f052abb8f374 ! .hgtags Changeset: cf9d6ec44f89 Author: katleman Date: 2012-01-13 10:05 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxp/rev/cf9d6ec44f89 Added tag jdk8-b21 for changeset d41eeadf5c13 ! .hgtags Changeset: 95102fd33418 Author: katleman Date: 2012-01-20 13:08 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxp/rev/95102fd33418 Added tag jdk8-b22 for changeset cf9d6ec44f89 ! .hgtags Changeset: 7836655e2495 Author: katleman Date: 2012-01-26 18:23 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxp/rev/7836655e2495 Added tag jdk8-b23 for changeset 95102fd33418 ! .hgtags Changeset: 8539c5fcf834 Author: mchung Date: 2012-01-30 21:10 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxp/rev/8539c5fcf834 Merge ! .hgtags From mandy.chung at oracle.com Mon Jan 30 21:13:48 2012 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 31 Jan 2012 05:13:48 +0000 Subject: hg: jigsaw/jigsaw/jaxws: 19 new changesets Message-ID: <20120131051349.1B81B4729B@hg.openjdk.java.net> Changeset: 76e37e606354 Author: katleman Date: 2011-12-01 10:33 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxws/rev/76e37e606354 Added tag jdk8-b15 for changeset c9ab96ff23d5 ! .hgtags Changeset: 23c42f40fd3e Author: katleman Date: 2011-12-06 08:43 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxws/rev/23c42f40fd3e 7117162: jdk8/jaxws/Makefile default DROPS_DIR should set to jdk8-drops Reviewed-by: ohair, xdono, mchung ! build.properties ! make/Makefile Changeset: 3d45ab79643d Author: katleman Date: 2011-12-07 13:02 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxws/rev/3d45ab79643d Merge Changeset: b38846b9974c Author: katleman Date: 2011-12-15 12:16 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxws/rev/b38846b9974c Added tag jdk8-b17 for changeset 3d45ab79643d ! .hgtags Changeset: e662b652098c Author: katleman Date: 2011-12-15 15:47 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxws/rev/e662b652098c Added tag jdk8-b16 for changeset 3d45ab79643d ! .hgtags Changeset: 54928c8850f5 Author: katleman Date: 2011-12-15 15:54 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxws/rev/54928c8850f5 Merge ! .hgtags Changeset: 72d410c3bab1 Author: cl Date: 2011-12-22 19:00 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxws/rev/72d410c3bab1 Added tag jdk8-b18 for changeset 54928c8850f5 ! .hgtags Changeset: 6d622b1b4db0 Author: ohair Date: 2011-12-12 08:13 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxws/rev/6d622b1b4db0 7117110: Remove target 1.5 from jaxp and jaxws repo builds for mac Reviewed-by: alanb ! build.xml Changeset: 6d2030eacdac Author: ohair Date: 2011-12-12 08:13 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxws/rev/6d2030eacdac 7119829: Adjust default jprt testing configuration Reviewed-by: alanb ! make/jprt.properties Changeset: b2e4ab8b5fa3 Author: lana Date: 2011-12-15 19:49 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxws/rev/b2e4ab8b5fa3 Merge Changeset: b73b733214aa Author: lana Date: 2011-12-23 16:36 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxws/rev/b73b733214aa Merge Changeset: 2b2818e3386f Author: katleman Date: 2011-12-29 15:14 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxws/rev/2b2818e3386f Added tag jdk8-b19 for changeset b73b733214aa ! .hgtags Changeset: dc2ee8b87884 Author: katleman Date: 2012-01-05 08:42 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxws/rev/dc2ee8b87884 Added tag jdk8-b20 for changeset 2b2818e3386f ! .hgtags Changeset: e67d51254533 Author: ohair Date: 2012-01-09 09:22 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxws/rev/e67d51254533 7096063: /META-INF/mimetypes.default missing in jre\lib\resources.jar Reviewed-by: dholmes ! build-defs.xml Changeset: c266cab0e3ff Author: katleman Date: 2012-01-11 16:12 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxws/rev/c266cab0e3ff Merge Changeset: 8d3df89b0f2d Author: katleman Date: 2012-01-13 10:05 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxws/rev/8d3df89b0f2d Added tag jdk8-b21 for changeset c266cab0e3ff ! .hgtags Changeset: 25ce7a000487 Author: katleman Date: 2012-01-20 13:08 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxws/rev/25ce7a000487 Added tag jdk8-b22 for changeset 8d3df89b0f2d ! .hgtags Changeset: e0d90803439b Author: katleman Date: 2012-01-26 18:23 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxws/rev/e0d90803439b Added tag jdk8-b23 for changeset 25ce7a000487 ! .hgtags Changeset: 00b537933ea2 Author: mchung Date: 2012-01-30 21:10 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxws/rev/00b537933ea2 Merge ! .hgtags From mandy.chung at oracle.com Mon Jan 30 21:13:43 2012 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 31 Jan 2012 05:13:43 +0000 Subject: hg: jigsaw/jigsaw/corba: 17 new changesets Message-ID: <20120131051401.CD9E64729C@hg.openjdk.java.net> Changeset: 44c269731425 Author: coffeys Date: 2011-11-11 10:16 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/corba/rev/44c269731425 7091388: Regular unexplained npe's from corba libs after system has been running for days Reviewed-by: alanb ! src/share/classes/com/sun/corba/se/impl/encoding/CDRInputStream.java ! src/share/classes/com/sun/corba/se/impl/encoding/CDRInputStream_1_0.java ! src/share/classes/com/sun/corba/se/impl/encoding/CDROutputStream.java ! src/share/classes/com/sun/corba/se/impl/encoding/CDROutputStream_1_0.java Changeset: 7da69e7175a7 Author: lana Date: 2011-11-18 11:01 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/corba/rev/7da69e7175a7 Merge Changeset: 82dc033975bb Author: katleman Date: 2011-12-01 10:33 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/corba/rev/82dc033975bb Added tag jdk8-b15 for changeset 7da69e7175a7 ! .hgtags Changeset: 05f47d29b438 Author: katleman Date: 2011-12-15 12:16 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/corba/rev/05f47d29b438 Added tag jdk8-b17 for changeset 82dc033975bb ! .hgtags Changeset: 6e51ad8d3707 Author: katleman Date: 2011-12-15 15:47 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/corba/rev/6e51ad8d3707 Added tag jdk8-b16 for changeset 82dc033975bb ! .hgtags Changeset: 312cf15d1657 Author: katleman Date: 2011-12-15 15:52 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/corba/rev/312cf15d1657 Merge ! .hgtags Changeset: 46bd4a46a5a8 Author: cl Date: 2011-12-22 19:00 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/corba/rev/46bd4a46a5a8 Added tag jdk8-b18 for changeset 312cf15d1657 ! .hgtags Changeset: 75529c21094f Author: ohair Date: 2011-12-12 08:15 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/corba/rev/75529c21094f 7119829: Adjust default jprt testing configuration Reviewed-by: alanb ! make/jprt.properties Changeset: 0289a94d653b Author: lana Date: 2011-12-15 19:49 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/corba/rev/0289a94d653b Merge Changeset: 052dda3b5ce3 Author: dmeetry Date: 2011-12-18 22:12 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/corba/rev/052dda3b5ce3 7046238: new InitialContext(); hangs Summary: Synchronization on a single monitor for contactInfo parameters with identical hashCode() Reviewed-by: robm, skoppar ! src/share/classes/com/sun/corba/se/impl/protocol/CorbaClientRequestDispatcherImpl.java Changeset: e1366c5d84ef Author: lana Date: 2011-12-23 16:36 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/corba/rev/e1366c5d84ef Merge Changeset: 51d8b6cb18c0 Author: katleman Date: 2011-12-29 15:14 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/corba/rev/51d8b6cb18c0 Added tag jdk8-b19 for changeset e1366c5d84ef ! .hgtags Changeset: f157fc2a71a3 Author: katleman Date: 2012-01-05 08:42 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/corba/rev/f157fc2a71a3 Added tag jdk8-b20 for changeset 51d8b6cb18c0 ! .hgtags Changeset: a11d0062c445 Author: katleman Date: 2012-01-13 10:05 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/corba/rev/a11d0062c445 Added tag jdk8-b21 for changeset f157fc2a71a3 ! .hgtags Changeset: 5218eb256658 Author: katleman Date: 2012-01-20 13:08 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/corba/rev/5218eb256658 Added tag jdk8-b22 for changeset a11d0062c445 ! .hgtags Changeset: b98f0e6dddf9 Author: katleman Date: 2012-01-26 18:23 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/corba/rev/b98f0e6dddf9 Added tag jdk8-b23 for changeset 5218eb256658 ! .hgtags Changeset: c61ae6ba3603 Author: mchung Date: 2012-01-30 21:10 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/corba/rev/c61ae6ba3603 Merge ! .hgtags From mandy.chung at oracle.com Mon Jan 30 21:13:50 2012 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 31 Jan 2012 05:13:50 +0000 Subject: hg: jigsaw/jigsaw/langtools: 16 new changesets Message-ID: <20120131051512.F41C34729D@hg.openjdk.java.net> Changeset: ffd294128a48 Author: katleman Date: 2011-12-29 15:14 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/ffd294128a48 Added tag jdk8-b19 for changeset 77b2c066084c ! .hgtags Changeset: 020819eb56d2 Author: katleman Date: 2012-01-05 08:42 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/020819eb56d2 Added tag jdk8-b20 for changeset ffd294128a48 ! .hgtags Changeset: a07eef109532 Author: jjh Date: 2012-01-03 17:18 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/a07eef109532 7046929: tools/javac/api/T6397104.java fails Reviewed-by: jjg ! test/tools/javac/api/T6397104.java Changeset: 4e8aa6eca726 Author: lana Date: 2012-01-04 10:58 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/4e8aa6eca726 Merge Changeset: bcb21abf1c41 Author: lana Date: 2012-01-09 19:13 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/bcb21abf1c41 Merge Changeset: 390a7828ae18 Author: katleman Date: 2012-01-13 10:05 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/390a7828ae18 Added tag jdk8-b21 for changeset bcb21abf1c41 ! .hgtags Changeset: f6191bad139a Author: katleman Date: 2012-01-20 13:08 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/f6191bad139a Added tag jdk8-b22 for changeset 390a7828ae18 ! .hgtags Changeset: 70d92518063e Author: mcimadamore Date: 2012-01-11 18:23 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/70d92518063e 7126754: Generics compilation failure casting List to List Summary: Problems with Types.rewriteQuantifiers not preserving variance Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/cast/7126754/T7126754.java + test/tools/javac/cast/7126754/T7126754.out Changeset: 133744729455 Author: mcimadamore Date: 2012-01-12 15:28 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/133744729455 7123100: javac fails with java.lang.StackOverflowError Summary: Inference of under-constrained type-variables creates erroneous recursive wildcard types Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Infer.java + test/tools/javac/cast/7123100/T7123100a.java + test/tools/javac/cast/7123100/T7123100a.out + test/tools/javac/cast/7123100/T7123100b.java + test/tools/javac/cast/7123100/T7123100b.out + test/tools/javac/cast/7123100/T7123100c.java + test/tools/javac/cast/7123100/T7123100c.out + test/tools/javac/cast/7123100/T7123100d.java + test/tools/javac/cast/7123100/T7123100d.out Changeset: 1e2f4f4fb9f7 Author: jjh Date: 2012-01-17 17:14 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/1e2f4f4fb9f7 7127924: langtools regression tests sometimes fail en-masse on windows Reviewed-by: jjg ! test/tools/javac/diags/CheckExamples.java ! test/tools/javac/diags/MessageInfo.java ! test/tools/javac/diags/RunExamples.java Changeset: f00afa80f1f0 Author: lana Date: 2012-01-18 11:00 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/f00afa80f1f0 Merge Changeset: cf2496340fef Author: darcy Date: 2012-01-18 16:43 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/cf2496340fef 7130768: Clarify behavior of Element.getEnclosingElements in subtypes Reviewed-by: mcimadamore, jjg ! src/share/classes/javax/lang/model/element/Element.java ! src/share/classes/javax/lang/model/element/PackageElement.java ! src/share/classes/javax/lang/model/element/TypeElement.java Changeset: 99261fc7d95d Author: jjh Date: 2012-01-18 18:26 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/99261fc7d95d 7131308: Three regression tests fail due to bad fix for 7127924 Reviewed-by: jjg ! test/tools/javac/diags/CheckExamples.java ! test/tools/javac/diags/MessageInfo.java ! test/tools/javac/diags/RunExamples.java Changeset: 601ffcc6551d Author: lana Date: 2012-01-24 13:44 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/601ffcc6551d Merge Changeset: 6c9d21ca92c4 Author: katleman Date: 2012-01-26 18:23 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/6c9d21ca92c4 Added tag jdk8-b23 for changeset 601ffcc6551d ! .hgtags Changeset: 55173d94a8f0 Author: mchung Date: 2012-01-30 21:10 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/55173d94a8f0 Merge ! .hgtags ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/javax/lang/model/element/Element.java From david.holmes at oracle.com Mon Jan 30 21:19:10 2012 From: david.holmes at oracle.com (David Holmes) Date: Tue, 31 Jan 2012 15:19:10 +1000 Subject: native cmds and libs in the module library In-Reply-To: <4F213E96.3020100@oracle.com> References: <4EE62FE1.70006@oracle.com> <4EEF597F.3030804@oracle.com> <4EEF6518.4060004@oracle.com> <4EF08A20.7030106@oracle.com> <4EF08C15.7060305@oracle.com> <4F071DDA.2040607@oracle.com> <4F0B71E8.2010104@oracle.com> <4F158596.2030306@oracle.com> <4F166EB4.9060108@oracle.com> <4F19AABD.90604@oracle.com> <4F1EBD1C.3020607@oracle.com> <4F201FB8.9040307@oracle.com> <4F213E96.3020100@oracle.com> Message-ID: <4F2779CE.4050308@oracle.com> So this may be the extra work you are referring to but I was surprised to discover that doing: jmod create -L foo --natcmd bin --natlib lib didn't create foo/bin and foo/lib but rather created ./bin and ./lib David On 26/01/2012 9:52 PM, Alan Bateman wrote: > On 25/01/2012 15:28, Chris Hegarty wrote: >> Alan, Mandy, >> >> Thank you for your comments. >> >> In short, I would like to integrate what is in the latest webrev (with >> your approval/review), and then continue the remainder of this work as >> a separate task. >> >> Latest webrev >> http://cr.openjdk.java.net/~chegar/jigsaw/libbin_webrev.05/webrev/ >> >> Changes: >> - SimpleLibrary parent, natlib, natcmd, and config are now final >> (Mandys comment). >> - Cleanup some style issues. >> - Backout changes to Modules.gmk (install from jmod files). >> >> Long description. >> >> I think it best to postpone to the next phase of this work creating >> the images by installing from jmod files. The reason being that this >> doesn't work very well on Windows yet. >> >> The jmod files for Windows contain both commands and libraries in the >> NATIVE_CMDS section of the jmod file, and config/property files in the >> NATIVE_LIBS section. It will not work to simply set --natcmd bin, and >> --natlib lib, as the findLocalNativeLibrary will then be searching in >> the wrong place. >> >> The solution is to have the appropriate files put in the correct >> section of the jmod file in the first place, and this will require >> separating out commands, libraries, and config files during the build >> . I think this is best done as a separate task. >> >> Thanks, >> -Chris. >> > I agree with Mandy, I think you should just push the patch that you have > now and address the separation and Windows issues in a second phase. > > -Alan. > From mandy.chung at oracle.com Mon Jan 30 21:13:49 2012 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 31 Jan 2012 05:13:49 +0000 Subject: hg: jigsaw/jigsaw/hotspot: 166 new changesets Message-ID: <20120131052025.DFF314729E@hg.openjdk.java.net> Changeset: d1f29d4e0bc6 Author: katleman Date: 2011-12-01 10:33 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/d1f29d4e0bc6 Added tag jdk8-b15 for changeset fde2a39ed7f3 ! .hgtags Changeset: 698a22e99f74 Author: katleman Date: 2011-12-15 12:16 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/698a22e99f74 Added tag jdk8-b17 for changeset d1f29d4e0bc6 ! .hgtags Changeset: 09f3b8a372b2 Author: katleman Date: 2011-12-15 15:47 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/09f3b8a372b2 Added tag jdk8-b16 for changeset d1f29d4e0bc6 ! .hgtags Changeset: e46c2339d0fc Author: katleman Date: 2011-12-15 15:52 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/e46c2339d0fc Merge ! .hgtags Changeset: da4182086289 Author: jcoomes Date: 2011-11-18 17:39 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/da4182086289 7113503: Bump the hs23 build number to 07 Reviewed-by: johnc Contributed-by: alejandro.murillo at oracle.com ! make/hotspot_version Changeset: 36b057451829 Author: dholmes Date: 2011-11-16 20:38 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/36b057451829 7110017: is_headless_jre should be updated to reflect the new location of awt toolkit libraries Reviewed-by: dholmes, dsamersoff Contributed-by: Chris Hegarty ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp Changeset: 002cb3fc8256 Author: coleenp Date: 2011-11-18 17:26 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/002cb3fc8256 Merge Changeset: c17bc65648de Author: brutisso Date: 2011-11-21 08:02 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/c17bc65648de 7112308: Fix Visual Studio build for precompiled header Summary: Add the new path to precompiled.hpp in the project make file Reviewed-by: coleenp, dholmes, brutisso Contributed-by: rbackman ! make/windows/makefiles/projectcreator.make Changeset: 1d090cf33da6 Author: coleenp Date: 2011-11-21 10:22 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/1d090cf33da6 Merge Changeset: 242b4e0e6f73 Author: phh Date: 2011-11-29 09:21 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/242b4e0e6f73 7116189: Export JVM_SetNativeThreadName from Hotspot Summary: Added JVM_SetNativeThreadName to linker mapfiles on Solaris and Linux. Reviewed-by: dcubed, dholmes Contributed-by: michael.x.mcmahon at oracle.com ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! make/solaris/makefiles/mapfile-vers Changeset: 763f01599ff4 Author: phh Date: 2011-11-29 17:00 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/763f01599ff4 7116481: Commercial features in Hotspot must be gated by a switch Summary: Add -XX:+UnlockCommercialVMOptions to gate use of commercial feature switches in the same way as -XX:UnlockDiagnosticVMOptions gates use of diagnostic feature switches. Reviewed-by: jwilhelm, kamg ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/globals_extension.hpp Changeset: 358eca91be48 Author: phh Date: 2011-11-30 12:48 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/358eca91be48 7116730: Revert 7116481: Commercial features in Hotspot must be gated by a switch Summary: Revert 7116481 to current hsx/hotspot-main Reviewed-by: kamg ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/globals_extension.hpp Changeset: 81a08cd7f6a1 Author: coleenp Date: 2011-12-01 13:42 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/81a08cd7f6a1 Merge Changeset: a88de71c4e3a Author: tonyp Date: 2011-11-18 12:52 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/a88de71c4e3a 7097002: G1: remove a lot of unused / redundant code from the G1CollectorPolicy class Summary: Major cleanup of the G1CollectorPolicy class. It removes a lot of unused fields and methods and also consolidates replicated information (mainly various ways of counting the number of CSet regions) into one copy. Reviewed-by: johnc, brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: d06a2d7fcd5b Author: brutisso Date: 2011-11-21 07:47 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/d06a2d7fcd5b 7110718: -XX:MarkSweepAlwaysCompactCount=0 crashes the JVM Summary: Interpret MarkSweepAlwaysCompactCount < 1 as never do full compaction Reviewed-by: ysr, tonyp, jmasa, johnc ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweepDecorator.cpp ! src/share/vm/memory/space.hpp Changeset: b5a5f30c483d Author: johnc Date: 2011-11-21 09:24 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/b5a5f30c483d 7110173: GCNotifier::pushNotification publishes stale data. Summary: GCNotifier::pushNotification() references GCMemoryManager::_last_gc_stat but is called from GCMemoryManager::gc_end() before GCMemoryManager::_last_gc_stat is set up using the values in GCMemoryManager::_current_gc_stat. As a result the GC notification code accesses unitialized or stale data. Move the notification call after GCMemoryManager::_las_gc_stat is set, but inside the same if-block. Reviewed-by: poonam, dholmes, fparain, mchung ! src/share/vm/services/memoryManager.cpp Changeset: 6071e0581859 Author: johnc Date: 2011-11-18 12:27 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/6071e0581859 7111795: G1: Various cleanups identified during walk through of changes for 6484965 Summary: Various cleanups and formatting changes identified during a code walk through of the changes for 6484965 ("G1: piggy-back liveness accounting phase on marking"). Reviewed-by: brutisso, tonyp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp Changeset: 3a298e04d914 Author: tonyp Date: 2011-11-22 04:47 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/3a298e04d914 Merge Changeset: bca17e38de00 Author: jmasa Date: 2011-08-09 10:16 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/bca17e38de00 6593758: RFE: Enhance GC ergonomics to dynamically choose ParallelGCThreads Summary: Select number of GC threads dynamically based on heap usage and number of Java threads Reviewed-by: johnc, ysr, jcoomes ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/gc_implementation/parallelScavenge/cardTableExtension.cpp ! src/share/vm/gc_implementation/parallelScavenge/cardTableExtension.hpp ! src/share/vm/gc_implementation/parallelScavenge/gcTaskManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/gcTaskManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/gcTaskThread.cpp ! src/share/vm/gc_implementation/parallelScavenge/gcTaskThread.hpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/parallelScavenge/psTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/psTasks.hpp ! src/share/vm/gc_implementation/shared/adaptiveSizePolicy.cpp ! src/share/vm/gc_implementation/shared/adaptiveSizePolicy.hpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/cardTableRS.cpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/memory/sharedHeap.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/utilities/workgroup.cpp ! src/share/vm/utilities/workgroup.hpp ! src/share/vm/utilities/yieldingWorkgroup.cpp ! src/share/vm/utilities/yieldingWorkgroup.hpp Changeset: 00dd86e542eb Author: johnc Date: 2011-11-28 09:49 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/00dd86e542eb 7114303: G1: assert(_g1->mark_in_progress()) failed: shouldn't be here otherwise Summary: Race between the VM thread reading G1CollectedHeap::_mark_in_progress and it being set by the concurrent mark thread when concurrent marking is aborted by a full GC. Have the concurrent mark thread join the SuspendibleThreadSet before changing the marking state. Reviewed-by: tonyp, brutisso ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp Changeset: dc467e8b2c5e Author: johnc Date: 2011-11-17 12:40 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/dc467e8b2c5e 7112743: G1: Reduce overhead of marking closure during evacuation pauses Summary: Parallelize the serial code that was used to mark objects reachable from survivor objects in the collection set. Some minor improvments in the timers used to track the freeing of the collection set along with some tweaks to PrintGCDetails. Reviewed-by: tonyp, brutisso ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/oops/objArrayOop.hpp Changeset: ea640b5e949a Author: jmasa Date: 2011-11-22 14:18 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/ea640b5e949a 7106024: CMS: Removed unused code for precleaning in remark phase Summary: Remove dead code. Reviewed-by: stefank, ysr ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/cardTableModRefBS.hpp Changeset: 7913e93dca52 Author: jmasa Date: 2011-11-22 14:59 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/7913e93dca52 7112997: Remove obsolete code ResetObjectsClosure and VerifyUpdateClosure Summary: Remove obsolete code. Reviewed-by: brutisso, ysr, jcoomes ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/gc_implementation/shared/markSweep.inline.hpp Changeset: 1bbf5b6fb7b0 Author: tonyp Date: 2011-12-02 08:52 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/1bbf5b6fb7b0 Merge ! src/share/vm/runtime/globals.hpp Changeset: 6de8c9ba5907 Author: jcoomes Date: 2011-12-02 15:11 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/6de8c9ba5907 Merge Changeset: aed8bf036ce2 Author: jcoomes Date: 2011-12-02 15:11 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/aed8bf036ce2 Added tag hs23-b07 for changeset 6de8c9ba5907 ! .hgtags Changeset: cf4dd13bbcd3 Author: jcoomes Date: 2011-12-02 21:10 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/cf4dd13bbcd3 7117536: new hotspot build - hs23-b08 Reviewed-by: johnc ! make/hotspot_version Changeset: cd00eaeebef6 Author: phh Date: 2011-12-05 12:50 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/cd00eaeebef6 7117389: Add a framework for vendor-specific command line switch extensions to Hotspot Summary: Add a file, globals_ext.hpp, containing a null interface, to be replaced by a vendor in altsrc as needed. Reviewed-by: coleenp, kamg, dholmes, johnc, jrose ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp + src/share/vm/runtime/globals_ext.hpp ! src/share/vm/runtime/globals_extension.hpp Changeset: 8657ec177a14 Author: dcubed Date: 2011-12-05 14:55 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/8657ec177a14 7117748: SA_APPLE_BOOT_JAVA and ALWAYS_PASS_TEST_GAMMA settings should not be required on MacOS X Summary: Replace SA_APPLE_BOOT_JAVA with logic that checks the boot JDK for the location of JDI classes. ALWAYS_PASS_TEST_GAMMA is true by default on Darwin. Reviewed-by: kvn, swingler ! make/bsd/makefiles/buildtree.make ! make/bsd/makefiles/sa.make Changeset: 41cce03b29a8 Author: dcubed Date: 2011-12-06 05:28 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/41cce03b29a8 Merge Changeset: 03865c41c4f3 Author: vladidan Date: 2011-12-06 16:35 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/03865c41c4f3 Merge ! src/share/vm/runtime/globals.hpp Changeset: 55d777c0860a Author: dcubed Date: 2011-12-07 07:27 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/55d777c0860a 7118648: disable compressed oops by default on MacOS X until 7118647 is fixed Summary: UseCompressedOops is false by default on MacOS X; can still be set manually Reviewed-by: jmelvin, kvn, dholmes ! src/share/vm/runtime/arguments.cpp Changeset: e8fdaf4a66cb Author: kvn Date: 2011-11-10 20:17 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/e8fdaf4a66cb 7110586: C2 generates incorrect results Summary: Exact limit of empty loop calculated incorrectly. Reviewed-by: iveresov, never ! src/share/vm/opto/loopnode.cpp + test/compiler/7110586/Test7110586.java Changeset: 8c57262447d3 Author: kvn Date: 2011-11-14 18:38 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/8c57262447d3 7105605: Use EA info to optimize pointers compare Summary: optimize pointers compare using EA information. Reviewed-by: never, twisti ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/escape.hpp Changeset: 6729bbc1fcd6 Author: twisti Date: 2011-11-16 01:39 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/6729bbc1fcd6 7003454: order constants in constant table by number of references in code Reviewed-by: kvn, never, bdelsart ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/vtableStubs_sparc.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/adlparse.cpp ! src/share/vm/adlc/output_c.cpp ! src/share/vm/asm/assembler.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/opto/matcher.hpp Changeset: 1bd45abaa507 Author: kvn Date: 2011-11-16 09:13 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/1bd45abaa507 6890673: Eliminate allocations immediately after EA Summary: Try to eliminate allocations and related locks immediately after escape analysis. Reviewed-by: never ! src/share/vm/opto/block.cpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/macro.hpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp Changeset: 973293defacd Author: iveresov Date: 2011-11-16 19:42 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/973293defacd 7112085: assert(fr.interpreter_frame_expression_stack_size()==0) failed: only handle empty stacks Summary: Move the inlinee invoke notification callback into inlinee preamble Reviewed-by: kvn, never ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/runtime/simpleThresholdPolicy.cpp ! src/share/vm/runtime/simpleThresholdPolicy.hpp ! test/compiler/6792161/Test6792161.java Changeset: a04a201f0f5a Author: twisti Date: 2011-11-17 04:07 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/a04a201f0f5a 7108383: JSR 292: JRuby bench_define_method_methods.rb: assert(slow_jvms != NULL) failed: miss path must not Reviewed-by: kvn, never ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/doCall.cpp Changeset: 59bc0d4d9ea3 Author: never Date: 2011-11-18 10:29 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/59bc0d4d9ea3 7110489: C1: 64-bit tiered with ForceUnreachable: assert(reachable(src)) failed: Address should be reachable Reviewed-by: kvn, iveresov, twisti ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.hpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp Changeset: 7793051af7d6 Author: twisti Date: 2011-11-21 00:57 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/7793051af7d6 7110058: change default for ScavengeRootsInCode to 2 Reviewed-by: kvn, never ! src/share/vm/runtime/globals.hpp Changeset: f03a3c8bd5e5 Author: roland Date: 2011-09-14 09:22 +0200 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/f03a3c8bd5e5 7077312: Provide a CALL effect for instruct declaration in the ad file Summary: abstracted way to declare that the MachNode has the effect of a call (kills caller save registers, preserves callee save registers) Reviewed-by: twisti, never ! src/share/vm/adlc/adlparse.cpp ! src/share/vm/adlc/adlparse.hpp ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/formssel.hpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/opto/block.hpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/machnode.hpp ! src/share/vm/opto/node.hpp Changeset: db2e64ca2d5a Author: roland Date: 2011-11-22 09:45 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/db2e64ca2d5a 7090968: Allow adlc register class to depend on runtime conditions Summary: allow reg_class definition as a function. Reviewed-by: kvn, never ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/adlparse.cpp ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/adlc/formsopt.cpp ! src/share/vm/adlc/formsopt.hpp ! src/share/vm/adlc/output_c.cpp ! src/share/vm/opto/matcher.hpp Changeset: cc81b9c09bbb Author: kvn Date: 2011-11-28 15:46 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/cc81b9c09bbb 7112478: after 7105605 JRuby bench_define_method_methods.rb fails with NPE Summary: Fixed several EA issues with Connection Graph construction. Reviewed-by: never, twisti ! src/share/vm/ci/bcEscapeAnalyzer.cpp ! src/share/vm/ci/bcEscapeAnalyzer.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/escape.hpp Changeset: 97825a4f7369 Author: iveresov Date: 2011-11-30 17:35 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/97825a4f7369 7116795: Tiered: enable by default for server Summary: Enable tiered compilation on server VM by default Reviewed-by: kvn, never ! make/jprt.properties ! src/cpu/sparc/vm/c2_globals_sparc.hpp ! src/cpu/x86/vm/c2_globals_x86.hpp Changeset: f745b2be3737 Author: kvn Date: 2011-12-02 21:37 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/f745b2be3737 7117282: assert(base == NULL || t_adr->isa_rawptr() || !phase->type(base) Summary: Delay memory node transformation until the memory is processed. Reviewed-by: iveresov, never ! src/share/vm/opto/memnode.cpp Changeset: 81f7362f7bed Author: kvn Date: 2011-12-08 10:27 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/81f7362f7bed Merge ! make/jprt.properties ! src/share/vm/runtime/globals.hpp Changeset: 4406629aa157 Author: johnc Date: 2011-12-02 12:39 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/4406629aa157 7114095: G1: assert(obj == oopDesc::load_decode_heap_oop(p)) failed: p should still be pointing to obj Summary: As a result of the changes for 4965777, the G1 reference field scanning closure could be applied to the discovered field of a reference object twice. The failing assert is too strong if the result of the first application of the closure is stolen, and the referenced object, evacuated by another worker thread. Reviewed-by: ysr, tonyp ! src/share/vm/gc_implementation/g1/g1OopClosures.inline.hpp Changeset: e37aedaedccd Author: tonyp Date: 2011-12-05 12:26 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/e37aedaedccd Merge Changeset: f1391adc6681 Author: stefank Date: 2011-11-28 10:19 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/f1391adc6681 7112034: Parallel CMS fails to properly mark reference objects Summary: Enabled reference processing when work stealing during concurrent marking Reviewed-by: jmasa, brutisso ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp Changeset: f4414323345f Author: stefank Date: 2011-11-28 14:58 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/f4414323345f 7116081: USE_PRECOMPILED_HEADER=0 triggers a single threaded build of the JVM Summary: Changed the conditional to see if the precompiled header has been specified. Also, removed the unused PrecompiledOption. Reviewed-by: dholmes, brutisso ! make/bsd/makefiles/gcc.make ! make/bsd/makefiles/top.make ! make/linux/makefiles/gcc.make ! make/linux/makefiles/top.make ! make/solaris/makefiles/gcc.make Changeset: d23d2b18183e Author: tonyp Date: 2011-12-07 12:54 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/d23d2b18183e 7118202: G1: eden size unnecessarily drops to a minimum Summary: An integer underflow can cause the RSet lengths to be massively overpredicted which forces the eden size to the minimum. Reviewed-by: brutisso, johnc ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp Changeset: e9b91fd07263 Author: jmasa Date: 2011-12-09 06:46 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/e9b91fd07263 Merge Changeset: 6d7d0790074d Author: jmasa Date: 2011-12-09 19:28 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/6d7d0790074d 7119584: UseParallelGC barrier task can be overwritten. Summary: Provoke a GC for a metadata allocation failure. Reviewed-by: johnc, iveresov ! src/share/vm/gc_implementation/parallelScavenge/gcTaskManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/gcTaskThread.cpp Changeset: 3b688d6ff3d0 Author: fparain Date: 2011-12-14 04:30 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/3b688d6ff3d0 7104647: Adding a diagnostic command framework Reviewed-by: phh, dcubed ! src/share/vm/services/attachListener.cpp + src/share/vm/services/diagnosticArgument.cpp + src/share/vm/services/diagnosticArgument.hpp + src/share/vm/services/diagnosticCommand.cpp + src/share/vm/services/diagnosticCommand.hpp + src/share/vm/services/diagnosticFramework.cpp + src/share/vm/services/diagnosticFramework.hpp ! src/share/vm/services/jmm.h ! src/share/vm/services/management.cpp Changeset: 31f6f10e4379 Author: vladidan Date: 2011-12-14 20:06 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/31f6f10e4379 Merge Changeset: a2fef924d8e6 Author: amurillo Date: 2011-12-16 12:38 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/a2fef924d8e6 Merge ! .hgtags Changeset: 61165f53f165 Author: amurillo Date: 2011-12-16 12:37 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/61165f53f165 Added tag hs23-b08 for changeset a2fef924d8e6 ! .hgtags Changeset: 7e075537835d Author: cl Date: 2011-12-22 19:00 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/7e075537835d Added tag jdk8-b18 for changeset 61165f53f165 ! .hgtags Changeset: 434acc838772 Author: amurillo Date: 2011-12-16 12:46 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/434acc838772 7122001: new hotspot build - hs23-b09 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 3c648b9ad052 Author: stefank Date: 2011-12-14 12:15 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/3c648b9ad052 7121373: Clean up CollectedHeap::is_in Summary: Fixed G1CollectedHeap::is_in, added tests, cleaned up comments and made Space::is_in pure virtual. Reviewed-by: brutisso, tonyp, jcoomes ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/generation.hpp ! src/share/vm/memory/space.cpp ! src/share/vm/memory/space.hpp ! src/share/vm/oops/arrayOop.cpp ! src/share/vm/oops/arrayOop.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/utilities/quickSort.cpp ! src/share/vm/utilities/quickSort.hpp Changeset: fd2b426c30db Author: johnc Date: 2011-12-14 17:43 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/fd2b426c30db 7119908: G1: Cache CSet start region for each worker for subsequent reuse Summary: Cache workers' calculated starting heap region, used for parallel iteration over the collcection set, for subsequent reuse. Reviewed-by: tonyp, brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp Changeset: 41406797186b Author: tonyp Date: 2011-12-16 02:14 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/41406797186b 7113012: G1: rename not-fully-young GCs as "mixed" Summary: Renamed partially-young GCs as mixed and fully-young GCs as young. Change all external output that includes those terms (GC log and GC ergo log) as well as any comments, fields, methods, etc. The changeset also includes very minor code tidying up (added some curly brackets). Reviewed-by: johnc, brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1ErgoVerbose.cpp ! src/share/vm/gc_implementation/g1/g1ErgoVerbose.hpp ! src/share/vm/gc_implementation/g1/g1MonitoringSupport.hpp Changeset: adedfbbf0360 Author: johnc Date: 2011-12-16 11:40 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/adedfbbf0360 7120038: G1: ParallelGCThreads==0 is broken Summary: Running G1 with ParallelGCThreads==0 results in various crashes and asserts. Most of these are caused by unguarded references to the worker threads array or an incorrect number of active workers. Reviewed-by: jmasa, tonyp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: e7dead7e90af Author: johnc Date: 2011-12-19 10:02 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/e7dead7e90af 7117303: VM uses non-monotonic time source and complains that it is non-monotonic Summary: Replaces calls to os::javaTimeMillis(), which does not (and cannot) guarantee monotonicity, in GC code to an equivalent expression that uses os::javaTimeNanos(). os::javaTimeNanos is guaranteed monotonically non-decreasing if the underlying platform provides a monotonic time source. Changes in OS files are to make use of the newly defined constants in globalDefinitions.hpp. Reviewed-by: dholmes, ysr ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/generation.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 129cd462ae89 Author: jmasa Date: 2011-12-20 12:27 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/129cd462ae89 Merge Changeset: 96ce4c27112f Author: coleenp Date: 2011-12-19 15:34 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/96ce4c27112f 7122939: TraceBytecodes broken with UseCompressedOops Summary: Disable verify_heapbase on sparc if TraceBytecodes because the latter uses r12 as a temp register Reviewed-by: coleenp, phh Contributed-by: Volker Simonis ! src/cpu/x86/vm/assembler_x86.cpp Changeset: 6c995c08526c Author: phh Date: 2011-12-19 15:50 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/6c995c08526c 7122880: Extend vendor-specific command interface to include manageable switches Summary: Add Flag::external_ext()/writable_ext(), both return false. Reviewed-by: coleenp, zgu ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/globals_ext.hpp ! src/share/vm/services/management.cpp Changeset: 4502fd5c7698 Author: phh Date: 2011-12-19 21:38 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/4502fd5c7698 Merge Changeset: 11c26bfcf8c7 Author: phh Date: 2011-12-21 15:48 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/11c26bfcf8c7 7091417: recvfrom's 6th input should be of type socklen_t Summary: Revamp class os's socket method formal args to match socket.h, insert casts in appropriate places, and copyin-copyout int*'s that s/b socklen_t*'s in jvm.cpp. Reviewed-by: coleenp, dholmes Contributed-by: erik.gahlin at oracle.com, rickard.backman at oracle.com, nils.loodin at oracle.com, markus.gronlund at oracle.com ! src/os/bsd/vm/jvm_bsd.h ! src/os/bsd/vm/os_bsd.inline.hpp ! src/os/linux/vm/jvm_linux.h ! src/os/linux/vm/os_linux.inline.hpp ! src/os/solaris/vm/jvm_solaris.h ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/os_solaris.inline.hpp ! src/os/windows/vm/jvm_windows.h ! src/os/windows/vm/os_windows.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/utilities/ostream.cpp Changeset: c01e115b095e Author: coleenp Date: 2011-12-21 16:41 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/c01e115b095e 7064927: retransformClasses() does not pass in LocalVariableTable of a method Summary: Handle LVT attribute in the class file reconstitutor. Reviewed-by: phh, coleenp Contributed-by: thomaswue ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp ! src/share/vm/prims/jvmtiClassFileReconstituter.hpp Changeset: d532160c55f7 Author: coleenp Date: 2011-12-21 18:22 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/d532160c55f7 Merge Changeset: 4b18532913c7 Author: vladidan Date: 2011-12-22 12:01 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/4b18532913c7 Merge ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp Changeset: 4bcf61041217 Author: amurillo Date: 2011-12-23 15:24 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/4bcf61041217 Merge Changeset: 9232e0ecbc2c Author: amurillo Date: 2011-12-23 15:24 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/9232e0ecbc2c Added tag hs23-b09 for changeset 4bcf61041217 ! .hgtags Changeset: fe2c87649981 Author: katleman Date: 2011-12-29 15:14 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/fe2c87649981 Added tag jdk8-b19 for changeset 9232e0ecbc2c ! .hgtags Changeset: 9952d1c439d6 Author: katleman Date: 2012-01-05 08:42 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/9952d1c439d6 Added tag jdk8-b20 for changeset fe2c87649981 ! .hgtags Changeset: ed621d125d02 Author: katleman Date: 2012-01-13 10:05 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/ed621d125d02 Added tag jdk8-b21 for changeset 9952d1c439d6 ! .hgtags Changeset: 0841c0ec2ed6 Author: amurillo Date: 2011-12-23 15:29 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/0841c0ec2ed6 7123810: new hotspot build - hs23-b10 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 3b2b58fb1425 Author: tonyp Date: 2011-12-20 12:59 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/3b2b58fb1425 7123165: G1: output during parallel verification can get messed up Summary: Serialize the worker threads that are generating output during parallel heap verification to make sure the output is consistent. Reviewed-by: brutisso, johnc, jmasa ! src/share/vm/gc_implementation/g1/heapRegion.cpp Changeset: d15b458c4225 Author: jmasa Date: 2011-12-20 20:29 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/d15b458c4225 Merge Changeset: 67fdcb391461 Author: tonyp Date: 2011-12-21 07:53 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/67fdcb391461 7119027: G1: use atomics to update RS length / predict time of inc CSet Summary: Make sure that the updates to the RS length and inc CSet predicted time are updated in an MT-safe way. Reviewed-by: brutisso, iveresov ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp Changeset: 441e946dc1af Author: jmasa Date: 2011-12-14 13:34 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/441e946dc1af 7121618: Change type of number of GC workers to unsigned int. Summary: Change variables representing the number of GC workers to uint from int and size_t. Change the parameter in work(int i) to work(uint worker_id). Reviewed-by: brutisso, tonyp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.inline.hpp ! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/memory/sharedHeap.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/workgroup.cpp ! src/share/vm/utilities/workgroup.hpp ! src/share/vm/utilities/yieldingWorkgroup.cpp ! src/share/vm/utilities/yieldingWorkgroup.hpp Changeset: 1cbe7978b021 Author: brutisso Date: 2011-12-21 22:13 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/1cbe7978b021 7113021: G1: automatically enable young gen size auto-tuning when -Xms==-Xmx Summary: Use a percentage of -Xms as min and another percentage of -Xmx as max for the young gen size Reviewed-by: tonyp, johnc ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: 7faca6dfa2ed Author: jmasa Date: 2011-12-27 12:38 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/7faca6dfa2ed Merge ! src/share/vm/runtime/globals.hpp Changeset: 4ceaf61479fc Author: dcubed Date: 2011-12-22 12:50 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/4ceaf61479fc 7122253: Instrumentation.retransformClasses() leaks class bytes Summary: Change ClassFileParser::parseClassFile() to use the instanceKlass:_cached_class_file_bytes field to avoid leaking the cache. Reviewed-by: coleenp, acorn, poonam ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: 4ec93d767458 Author: vladidan Date: 2011-12-26 20:36 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/4ec93d767458 Merge Changeset: 3db6ea5ce021 Author: vladidan Date: 2011-12-29 20:09 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/3db6ea5ce021 Merge Changeset: 20bfb6d15a94 Author: iveresov Date: 2011-12-27 16:43 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/20bfb6d15a94 7124829: NUMA: memory leak on Linux with large pages Summary: In os::free_memory() use mmap with the same attributes as for the heap space Reviewed-by: kvn Contributed-by: Aleksey Ignatenko ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp ! src/share/vm/gc_implementation/shared/mutableSpace.cpp ! src/share/vm/runtime/os.hpp Changeset: 776173fc2df9 Author: stefank Date: 2011-12-29 07:37 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/776173fc2df9 7125516: G1: ~ConcurrentMark() frees incorrectly Summary: Replaced the code with a ShouldNotReachHere Reviewed-by: tonyp, jmasa ! src/share/vm/gc_implementation/g1/concurrentMark.cpp Changeset: 5ee33ff9b1c4 Author: jmasa Date: 2012-01-03 10:22 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/5ee33ff9b1c4 Merge Changeset: 75c0a73eee98 Author: coleenp Date: 2011-11-17 12:53 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/75c0a73eee98 7102776: Pack instanceKlass boolean fields into single u1 field Summary: Reduce class runtime memory usage by packing 4 instanceKlass boolean fields into single u1 field. Save 4-byte for each loaded class. Reviewed-by: dholmes, bobv, phh, twisti, never, coleenp Contributed-by: Jiangli Zhou ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! src/share/vm/code/dependencies.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: da4dd142ea01 Author: bobv Date: 2011-11-29 14:44 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/da4dd142ea01 Merge ! src/share/vm/code/dependencies.cpp Changeset: 52b5d32fbfaf Author: coleenp Date: 2011-12-06 18:28 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/52b5d32fbfaf 7117052: instanceKlass::_init_state can be u1 type Summary: Change instanceKlass::_init_state field to u1 type. Reviewed-by: bdelsart, coleenp, dholmes, phh, never Contributed-by: Jiangli Zhou ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/memory/dump.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/parseHelper.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: eccc4b1f8945 Author: vladidan Date: 2011-12-07 16:47 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/eccc4b1f8945 7050298: ARM: SIGSEGV in JNIHandleBlock::allocate_handle Summary: missing release barrier in Monitor::IUnlock Reviewed-by: dholmes, dice ! src/share/vm/runtime/mutex.cpp Changeset: 2685ea97b89f Author: jiangli Date: 2011-12-09 11:29 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/2685ea97b89f Merge ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp Changeset: 8fdf463085e1 Author: jiangli Date: 2011-12-16 17:33 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/8fdf463085e1 Merge Changeset: dca455dea3a7 Author: bdelsart Date: 2011-12-20 12:33 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/dca455dea3a7 7116216: StackOverflow GC crash Summary: GC crash for explicit stack overflow checks after a C2I transition. Reviewed-by: coleenp, never Contributed-by: yang02.wang at sap.com, bertrand.delsart at oracle.com ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp + test/compiler/7116216/LargeFrame.java + test/compiler/7116216/StackOverflow.java Changeset: cd5d8cafcc84 Author: jiangli Date: 2011-12-28 12:15 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/cd5d8cafcc84 7123315: instanceKlass::_static_oop_field_count and instanceKlass::_java_fields_count should be u2 type. Summary: Change instanceKlass::_static_oop_field_count and instanceKlass::_java_fields_count to u2 type. Reviewed-by: never, bdelsart, dholmes Contributed-by: Jiangli Zhou ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 05de27e852c4 Author: jiangli Date: 2012-01-04 12:36 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/05de27e852c4 Merge ! src/share/vm/classfile/classFileParser.cpp Changeset: b6a04c79ccbc Author: stefank Date: 2012-01-02 10:01 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/b6a04c79ccbc 7125503: Compiling collectedHeap.cpp fails with -Werror=int-to-pointer-cast with g++ 4.6.1 Summary: Used uintptr_t and void* for all the casts and checks in test_is_in. Reviewed-by: tonyp, jmasa ! src/share/vm/gc_interface/collectedHeap.cpp Changeset: 4753e3dda3c8 Author: jmasa Date: 2012-01-04 07:56 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/4753e3dda3c8 Merge Changeset: 2ee4167627a3 Author: jmasa Date: 2012-01-05 21:02 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/2ee4167627a3 Merge Changeset: 7ab5f6318694 Author: phh Date: 2012-01-01 11:17 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/7ab5f6318694 7125934: Add a fast unordered timestamp capability to Hotspot on x86/x64 Summary: Add rdtsc detection and inline generation. Reviewed-by: kamg, dholmes Contributed-by: karen.kinnear at oracle.com ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/os_cpu/bsd_x86/vm/os_bsd_x86.hpp + src/os_cpu/bsd_x86/vm/os_bsd_x86.inline.hpp ! src/os_cpu/linux_x86/vm/os_linux_x86.hpp + src/os_cpu/linux_x86/vm/os_linux_x86.inline.hpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.hpp + src/os_cpu/solaris_x86/vm/os_solaris_x86.inline.hpp ! src/os_cpu/solaris_x86/vm/solaris_x86_32.il ! src/os_cpu/solaris_x86/vm/solaris_x86_64.il ! src/os_cpu/windows_x86/vm/os_windows_x86.hpp + src/os_cpu/windows_x86/vm/os_windows_x86.inline.hpp ! src/share/vm/runtime/init.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp + src/share/vm/runtime/os_ext.hpp Changeset: b16494a69d3d Author: phh Date: 2012-01-03 15:11 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/b16494a69d3d 7126185: Clean up lasterror handling, add os::get_last_error() Summary: Add os::get_last_error(), replace getLastErrorString() by os::lasterror() in os_windows.cpp. Reviewed-by: kamg, dholmes Contributed-by: erik.gahlin at oracle.com ! src/os/posix/vm/os_posix.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/runtime/os.hpp Changeset: 5b58979183f9 Author: dcubed Date: 2012-01-05 06:24 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/5b58979183f9 7127032: fix for 7122253 adds a JvmtiThreadState earlier than necessary Summary: Use JavaThread::jvmti_thread_state() instead of JvmtiThreadState::state_for(). Reviewed-by: coleenp, poonam, acorn ! src/share/vm/classfile/classFileParser.cpp Changeset: 8a63c6323842 Author: fparain Date: 2012-01-05 07:26 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/8a63c6323842 7125594: C-heap growth issue in ThreadService::find_deadlocks_at_safepoint Reviewed-by: sspitsyn, dcubed, mchung, dholmes ! src/share/vm/services/threadService.cpp Changeset: 2e0ef19fc891 Author: phh Date: 2012-01-05 17:14 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/2e0ef19fc891 7126480: Make JVM start time in milliseconds since the Java epoch available Summary: Expose existing Management::_begin_vm_creation_time via new accessor Management::begin_vm_creation_time(). Reviewed-by: acorn, dcubed ! src/share/vm/services/management.hpp Changeset: 66259eca2bf7 Author: phh Date: 2012-01-05 17:16 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/66259eca2bf7 Merge Changeset: 2b3acb34791f Author: dcubed Date: 2012-01-06 16:18 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/2b3acb34791f Merge ! src/os/windows/vm/os_windows.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/runtime/os.hpp Changeset: abcceac2f7cd Author: iveresov Date: 2011-12-12 12:44 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/abcceac2f7cd 7119730: Tiered: SIGSEGV in AdvancedThresholdPolicy::is_method_profiled(methodOop) Summary: Added handles for references to methods in select_task() Reviewed-by: twisti, kvn ! src/share/vm/runtime/advancedThresholdPolicy.cpp Changeset: 7bca37d28f32 Author: roland Date: 2011-12-13 10:54 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/7bca37d28f32 7114106: C1: assert(goto_state->is_same(sux_state)) failed: states must match now Summary: fix C1's CEE to take inlining into account when the stacks in states are compared. Reviewed-by: iveresov, never ! src/share/vm/c1/c1_Optimizer.cpp Changeset: d725f0affb1a Author: iveresov Date: 2011-12-13 17:10 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/d725f0affb1a 7121111: -server -Xcomp -XX:+TieredCompilation does not invoke C2 compiler Summary: Exercise C2 more in tiered mode with Xcomp Reviewed-by: kvn, never ! src/share/vm/runtime/arguments.cpp Changeset: 127b3692c168 Author: kvn Date: 2011-12-14 14:54 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/127b3692c168 7116452: Add support for AVX instructions Summary: Added support for AVX extension to the x86 instruction set. Reviewed-by: never ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/assembler_x86.inline.hpp ! src/cpu/x86/vm/nativeInst_x86.cpp ! src/cpu/x86/vm/nativeInst_x86.hpp ! src/cpu/x86/vm/register_definitions_x86.cpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/runtime/globals.hpp Changeset: 669f6a7d5b70 Author: never Date: 2011-12-19 14:16 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/669f6a7d5b70 7121073: secondary_super_cache memory slice has incorrect bounds in flatten_alias_type Reviewed-by: kvn ! src/share/vm/opto/compile.cpp Changeset: 65149e74c706 Author: kvn Date: 2011-12-20 00:55 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/65149e74c706 7121648: Use 3-operands SIMD instructions on x86 with AVX Summary: Use 3-operands SIMD instructions in C2 generated code for machines with AVX. Reviewed-by: never ! make/bsd/makefiles/adlc.make ! make/linux/makefiles/adlc.make ! make/solaris/makefiles/adlc.make ! make/windows/makefiles/adlc.make ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp + src/cpu/x86/vm/x86.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/opto/matcher.cpp Changeset: 069ab3f976d3 Author: stefank Date: 2011-12-07 11:35 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/069ab3f976d3 7118863: Move sizeof(klassOopDesc) into the *Klass::*_offset_in_bytes() functions Summary: Moved sizeof(klassOopDesc), changed the return type to ByteSize and removed the _in_bytes suffix. Reviewed-by: never, bdelsart, coleenp, jrose ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_MacroAssembler_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/oops/arrayKlass.hpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/klassOop.hpp ! src/share/vm/oops/objArrayKlass.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/parseHelper.cpp ! src/share/vm/shark/sharkIntrinsics.cpp ! src/share/vm/shark/sharkTopLevelBlock.cpp Changeset: 1dc233a8c7fe Author: roland Date: 2011-12-20 16:56 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/1dc233a8c7fe 7121140: Allocation paths require explicit memory synchronization operations for RMO systems Summary: adds store store barrier after initialization of header and body of objects. Reviewed-by: never, kvn ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/formssel.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/node.hpp Changeset: e5ac210043cd Author: roland Date: 2011-12-22 10:55 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/e5ac210043cd 7123108: C1: assert(if_state != NULL) failed: states do not match up Summary: In CEE, ensure if and common successor state are at the same inline level Reviewed-by: never ! src/share/vm/c1/c1_Optimizer.cpp + test/compiler/7123108/Test7123108.java Changeset: b642b49f9738 Author: roland Date: 2011-12-23 09:36 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/b642b49f9738 7123253: C1: in store check code, usage of registers may be incorrect Summary: fix usage of input register in assembly code for store check. Reviewed-by: never ! src/share/vm/c1/c1_LIR.cpp Changeset: 40c2484c09e1 Author: kvn Date: 2011-12-23 15:24 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/40c2484c09e1 7110832: ctw/.../org_apache_avalon_composition_util_StringHelper crashes the VM Summary: Distance is too large for one short branch in string_indexofC8(). Reviewed-by: iveresov ! src/cpu/x86/vm/assembler_x86.cpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp Changeset: d12a66fa3820 Author: kvn Date: 2011-12-27 15:08 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/d12a66fa3820 7123954: Some CTW test crash with SIGSEGV Summary: Correct Allocate expansion code to preserve i_o when only slow call is generated. Reviewed-by: iveresov ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/macro.cpp Changeset: 8940fd98d540 Author: kvn Date: 2011-12-29 11:37 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/8940fd98d540 Merge ! src/cpu/x86/vm/assembler_x86.cpp ! src/share/vm/runtime/globals.hpp Changeset: 9c87bcb3b4dd Author: kvn Date: 2011-12-30 11:43 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/9c87bcb3b4dd 7125879: assert(proj != NULL) failed: must be found Summary: Leave i_o attached to slow allocation call when there are no i_o users after the call. Reviewed-by: iveresov, twisti ! src/share/vm/opto/macro.cpp + test/compiler/7125879/Test7125879.java Changeset: 1cb50d7a9d95 Author: iveresov Date: 2012-01-05 17:25 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/1cb50d7a9d95 7119294: Two command line options cause JVM to crash Summary: Setup thread register in MacroAssembler::incr_allocated_bytes() on x64 Reviewed-by: kvn ! src/cpu/x86/vm/assembler_x86.cpp Changeset: 22cee0ee8927 Author: kvn Date: 2012-01-06 20:09 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/22cee0ee8927 Merge ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/parseHelper.cpp Changeset: 8f8b94305aff Author: dcubed Date: 2012-01-11 19:54 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/8f8b94305aff 7129240: backout fix for 7102776 until 7128770 is resolved Reviewed-by: phh, bobv, coleenp, dcubed Contributed-by: Jiangli Zhou ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! src/share/vm/code/dependencies.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 4f25538b54c9 Author: fparain Date: 2012-01-09 10:27 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/4f25538b54c9 7120511: Add diagnostic commands Reviewed-by: acorn, phh, dcubed, sspitsyn ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/init.cpp ! src/share/vm/services/attachListener.cpp ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/diagnosticCommand.hpp ! src/share/vm/services/diagnosticFramework.cpp ! src/share/vm/services/diagnosticFramework.hpp ! src/share/vm/services/management.cpp Changeset: 865e0817f32b Author: kamg Date: 2012-01-10 15:47 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/865e0817f32b Merge ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: efdf6985a3a2 Author: kamg Date: 2012-01-12 09:59 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/efdf6985a3a2 Merge Changeset: 5da7201222d5 Author: kvn Date: 2012-01-07 10:39 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/5da7201222d5 7110824: ctw/jarfiles/GUI3rdParty_jar/ob_mask_DateField crashes VM Summary: Change yank_if_dead() to recursive method to remove all dead inputs. Reviewed-by: never ! src/cpu/sparc/vm/sparc.ad ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/postaloc.cpp Changeset: e9a5e0a812c8 Author: kvn Date: 2012-01-07 13:26 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/e9a5e0a812c8 7125896: Eliminate nested locks Summary: Nested locks elimination done before lock nodes expansion by looking for outer locks of the same object. Reviewed-by: never, twisti ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/ci/ciTypeFlow.hpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/locknode.cpp ! src/share/vm/opto/locknode.hpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/macro.hpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/deoptimization.cpp Changeset: 35acf8f0a2e4 Author: kvn Date: 2012-01-10 18:05 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/35acf8f0a2e4 7128352: assert(obj_node == obj) failed Summary: Compare uncasted object nodes. Reviewed-by: never ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/locknode.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/phaseX.hpp ! src/share/vm/opto/subnode.cpp ! test/compiler/7116216/StackOverflow.java Changeset: c8d8e124380c Author: kvn Date: 2012-01-12 12:28 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/c8d8e124380c 7064302: JDK7 build 147 crashed after testing my java 6-compiled web app Summary: Don't split CMove node if it's control edge is different from split region. Reviewed-by: never ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/loopopts.cpp Changeset: 31a5b9aad4bc Author: jrose Date: 2012-01-13 00:27 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/31a5b9aad4bc Merge ! src/share/vm/runtime/arguments.cpp Changeset: bacb651cf5bf Author: tonyp Date: 2012-01-05 05:54 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/bacb651cf5bf 7113006: G1: excessive ergo output when an evac failure happens Summary: Introduce a flag that is set when a heap expansion attempt during a GC fails so that we do not consantly attempt to expand the heap when it's going to fail anyway. This not only prevents the excessive ergo output (which is generated when a region allocation fails) but also avoids excessive and ultimately unsuccessful expansion attempts. Reviewed-by: jmasa, johnc ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp Changeset: 5fd354a959c5 Author: jmasa Date: 2012-01-05 21:21 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/5fd354a959c5 Merge Changeset: 023652e49ac0 Author: johnc Date: 2011-12-23 11:14 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/023652e49ac0 7121496: G1: do the per-region evacuation failure handling work in parallel Summary: Parallelize the removal of self forwarding pointers etc. by wrapping in a HeapRegion closure, which is then wrapped inside an AbstractGangTask. Reviewed-by: tonyp, iveresov ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp + src/share/vm/gc_implementation/g1/g1EvacFailure.hpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp Changeset: 02838862dec8 Author: tonyp Date: 2012-01-07 00:43 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/02838862dec8 7121623: G1: always be able to reliably calculate the length of a forwarded chunked array Summary: Store the "next chunk start index" in the length field of the to-space object, instead of the from-space object, so that we can always reliably read the size of all from-space objects. Reviewed-by: johnc, ysr, jmasa ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 97c00e21fecb Author: tonyp Date: 2012-01-09 23:50 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/97c00e21fecb 7125281: G1: heap expansion code is replicated Reviewed-by: brutisso, johnc ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 1d6185f732aa Author: brutisso Date: 2012-01-10 20:02 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/1d6185f732aa 7128532: G1: Change default value of G1DefaultMaxNewGenPercent to 80 Reviewed-by: tonyp, jmasa ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: 2ace1c4ee8da Author: tonyp Date: 2012-01-10 18:58 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/2ace1c4ee8da 6888336: G1: avoid explicitly marking and pushing objects in survivor spaces Summary: This change simplifies the interaction between GC and concurrent marking. By disabling survivor spaces during the initial-mark pause we don't need to propagate marks of objects we copy during each GC (since we never need to copy an explicitly marked object). Reviewed-by: johnc, brutisso ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1EvacFailure.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegion.inline.hpp ! src/share/vm/gc_implementation/g1/ptrQueue.hpp ! src/share/vm/gc_implementation/g1/satbQueue.cpp ! src/share/vm/gc_implementation/g1/satbQueue.hpp Changeset: 9d4f4a1825e4 Author: brutisso Date: 2012-01-13 01:55 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/9d4f4a1825e4 Merge Changeset: 5acd82522540 Author: brutisso Date: 2012-01-13 06:18 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/5acd82522540 Merge Changeset: b0ff910edfc9 Author: kvn Date: 2012-01-12 14:45 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/b0ff910edfc9 7128355: assert(!nocreate) failed: Cannot build a phi for a block already parsed Summary: Do not common BoxLock nodes and avoid creating phis of boxes. Reviewed-by: never ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/locknode.cpp ! src/share/vm/opto/locknode.hpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/parse1.cpp Changeset: f4d8930a45b9 Author: jrose Date: 2012-01-13 00:51 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/f4d8930a45b9 Merge Changeset: 89d0a5d40008 Author: kvn Date: 2012-01-13 12:58 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/89d0a5d40008 7129618: assert(obj_node->eqv_uncast(obj),""); Summary: Relax verification and locks elimination checks for new implementation (EliminateNestedLocks). Reviewed-by: iveresov ! src/share/vm/opto/locknode.cpp ! src/share/vm/opto/macro.cpp Changeset: e504fd26c073 Author: kvn Date: 2012-01-13 14:21 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/e504fd26c073 Merge Changeset: 513351373923 Author: amurillo Date: 2012-01-14 00:47 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/513351373923 Merge Changeset: 24727fb37561 Author: amurillo Date: 2012-01-14 00:47 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/24727fb37561 Added tag hs23-b10 for changeset 513351373923 ! .hgtags Changeset: 338d438ee229 Author: katleman Date: 2012-01-20 13:08 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/338d438ee229 Added tag jdk8-b22 for changeset 24727fb37561 ! .hgtags Changeset: 4e80db53c323 Author: amurillo Date: 2012-01-14 00:52 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/4e80db53c323 7129512: new hotspot build - hs23-b11 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 94ec88ca68e2 Author: phh Date: 2012-01-11 17:34 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/94ec88ca68e2 7115199: Add event tracing hooks and Java Flight Recorder infrastructure Summary: Added a nop tracing infrastructure, JFR makefile changes and other infrastructure used only by JFR. Reviewed-by: acorn, sspitsyn Contributed-by: markus.gronlund at oracle.com ! make/Makefile ! make/bsd/makefiles/vm.make ! make/defs.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/vm.make ! make/windows/build.bat ! make/windows/create_obj_files.sh ! make/windows/makefiles/projectcreator.make ! make/windows/makefiles/vm.make ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/classfile/symbolTable.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/methodKlass.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/prims/jni.cpp + src/share/vm/prims/jniExport.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vm_operations.hpp + src/share/vm/trace/traceEventTypes.hpp + src/share/vm/trace/traceMacros.hpp + src/share/vm/trace/tracing.hpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 4f3ce9284781 Author: phh Date: 2012-01-11 17:58 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/4f3ce9284781 Merge ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp Changeset: f1cd52d6ce02 Author: kamg Date: 2012-01-17 10:16 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/f1cd52d6ce02 Merge Changeset: d7e3846464d0 Author: zgu Date: 2012-01-17 13:08 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/d7e3846464d0 7071311: Decoder enhancement Summary: Made decoder thread-safe Reviewed-by: coleenp, kamg - src/os/bsd/vm/decoder_bsd.cpp + src/os/bsd/vm/decoder_machO.cpp + src/os/bsd/vm/decoder_machO.hpp ! src/os/linux/vm/decoder_linux.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/decoder_solaris.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/decoder_windows.cpp + src/os/windows/vm/decoder_windows.hpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/utilities/decoder.cpp ! src/share/vm/utilities/decoder.hpp + src/share/vm/utilities/decoder_elf.cpp + src/share/vm/utilities/decoder_elf.hpp ! src/share/vm/utilities/elfFile.cpp ! src/share/vm/utilities/elfFile.hpp ! src/share/vm/utilities/elfStringTable.cpp ! src/share/vm/utilities/elfStringTable.hpp ! src/share/vm/utilities/elfSymbolTable.cpp ! src/share/vm/utilities/elfSymbolTable.hpp ! src/share/vm/utilities/vmError.cpp Changeset: 6520f9861937 Author: kamg Date: 2012-01-17 21:25 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/6520f9861937 Merge Changeset: db18ca98d237 Author: zgu Date: 2012-01-18 11:45 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/db18ca98d237 7131050: fix for "7071311 Decoder enhancement" does not build on MacOS X Summary: Decoder API changes did not reflect in os_bsd Reviewed-by: kamg, dcubed ! src/os/bsd/vm/os_bsd.cpp Changeset: eaa9557116a2 Author: bdelsart Date: 2012-01-18 16:18 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/eaa9557116a2 7120448: Fix FP values for compiled frames in frame::describe Summary: fix for debug method frame::describe Reviewed-by: never, kvn ! src/cpu/sparc/vm/frame_sparc.inline.hpp ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/frame_x86.hpp ! src/cpu/zero/vm/frame_zero.inline.hpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp Changeset: 15d394228cfa Author: jrose Date: 2012-01-19 13:00 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/15d394228cfa 7111138: delete the obsolete flag -XX:+UseRicochetFrames Reviewed-by: dholmes, bdelsart, kvn, twisti ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/zero/vm/methodHandles_zero.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: 898522ae3c32 Author: iveresov Date: 2012-01-19 10:56 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/898522ae3c32 7131288: COMPILE SKIPPED: deopt handler overflow (retry at different tier) Summary: Fix exception handler stub size, enable guarantees to check for the correct deopt and exception stub sizes in the future Reviewed-by: kvn, never, twisti ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp Changeset: 469e0a46f2fe Author: jrose Date: 2012-01-19 17:20 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/469e0a46f2fe Merge Changeset: 50d9b7a0072c Author: jrose Date: 2012-01-19 18:35 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/50d9b7a0072c Merge Changeset: dcc292399a39 Author: amurillo Date: 2012-01-20 16:56 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/dcc292399a39 Merge - src/os/bsd/vm/decoder_bsd.cpp Changeset: e850d8e7ea54 Author: amurillo Date: 2012-01-20 16:56 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/e850d8e7ea54 Added tag hs23-b11 for changeset dcc292399a39 ! .hgtags Changeset: 6edfe6e42a68 Author: katleman Date: 2012-01-26 18:23 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/6edfe6e42a68 Added tag jdk8-b23 for changeset e850d8e7ea54 ! .hgtags Changeset: 62825b3de60f Author: mchung Date: 2012-01-30 21:10 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/62825b3de60f Merge ! .hgtags ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! make/solaris/makefiles/mapfile-vers ! make/windows/makefiles/vm.make ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp - src/os/bsd/vm/decoder_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/vmStructs.cpp From mandy.chung at oracle.com Mon Jan 30 21:14:07 2012 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 31 Jan 2012 05:14:07 +0000 Subject: hg: jigsaw/jigsaw/jdk: 210 new changesets Message-ID: <20120131055220.C7713472A1@hg.openjdk.java.net> Changeset: 89952dc5be8e Author: prr Date: 2011-11-17 10:32 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/89952dc5be8e 7113017: Use POSIX compliant include file headers in sun/awt/medialib/mlib_types.h Reviewed-by: prr, bae Contributed-by: littlee at linux.vnet.ibm.com ! src/share/native/sun/awt/medialib/mlib_types.h Changeset: 60331bbcf4ad Author: lana Date: 2011-11-18 16:16 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/60331bbcf4ad Merge Changeset: f410b91caf45 Author: weijun Date: 2011-11-09 09:30 +0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/f410b91caf45 7107019: sun.security.krb5.internal.ccache.CCacheInputStream.readCred does not use auth data Reviewed-by: valeriep ! src/share/classes/sun/security/krb5/internal/ccache/CCacheInputStream.java ! src/share/classes/sun/security/krb5/internal/ccache/Credentials.java Changeset: 52be75d060f9 Author: weijun Date: 2011-11-09 15:51 +0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/52be75d060f9 7109096: keytool -genkeypair needn't call -selfcert Reviewed-by: xuelei ! src/share/classes/sun/security/tools/CertAndKeyGen.java ! src/share/classes/sun/security/tools/KeyTool.java Changeset: d6a5da5f6ba0 Author: dl Date: 2011-11-10 12:21 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/d6a5da5f6ba0 7107516: LinkedBlockingQueue/Deque.drainTo(Collection, int) returns 'maxElements' if its value is negative Reviewed-by: chegar, mduigou, dholmes ! src/share/classes/java/util/concurrent/LinkedBlockingDeque.java ! src/share/classes/java/util/concurrent/LinkedBlockingQueue.java Changeset: 0ccfb35cce26 Author: michaelm Date: 2011-11-10 15:30 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/0ccfb35cce26 7110484: HttpServer.stop() not closing selector Reviewed-by: chegar ! src/share/classes/sun/net/httpserver/ServerImpl.java Changeset: e5d65a583c15 Author: michaelm Date: 2011-11-10 15:41 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/e5d65a583c15 Merge Changeset: 830d2e46023a Author: lancea Date: 2011-11-10 11:41 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/830d2e46023a 7110111: Minor Java SE javadoc & Constructor clean up Reviewed-by: alanb, darcy Contributed-by: Martin Desruisseaux ! src/share/classes/java/io/Writer.java ! src/share/classes/java/lang/AssertionError.java ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/Double.java ! src/share/classes/java/lang/Float.java ! src/share/classes/java/sql/PreparedStatement.java ! src/share/classes/java/sql/Statement.java ! src/share/classes/java/util/jar/Attributes.java Changeset: 9dd994f319ee Author: coffeys Date: 2011-11-11 10:08 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/9dd994f319ee 7105952: Improve finalisation for FileInputStream/FileOutputStream/RandomAccessFile Reviewed-by: alanb ! src/share/classes/java/io/FileInputStream.java ! src/share/classes/java/io/FileOutputStream.java ! src/share/classes/java/io/RandomAccessFile.java ! src/solaris/classes/java/io/FileDescriptor.java ! src/windows/classes/java/io/FileDescriptor.java - test/java/io/FileDescriptor/FileChannelFDTest.java + test/java/io/FileDescriptor/Sharing.java - test/java/io/etc/FileDescriptorSharing.java Changeset: 5c7c83a6ee24 Author: xuelei Date: 2011-11-14 01:21 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/5c7c83a6ee24 7111548: unexpected debug log message Reviewed-by: wetmore ! src/share/classes/sun/security/ssl/SSLSocketImpl.java Changeset: 68fc55d12ae6 Author: chegar Date: 2011-11-14 10:06 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/68fc55d12ae6 7107020: java.net.PlainSocketImpl.socketSetOption() calls itself Reviewed-by: alanb, chegar Contributed-by: kurchi.subhra.hazra at oracle.com ! src/windows/classes/java/net/PlainSocketImpl.java Changeset: c740519fe83a Author: weijun Date: 2011-11-16 11:53 +0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/c740519fe83a 7111579: klist starttime, renewtill, ticket etype Reviewed-by: mullan ! src/share/classes/sun/security/krb5/internal/ccache/Credentials.java ! src/windows/classes/sun/security/krb5/internal/tools/Klist.java Changeset: cd6d236e863b Author: okutsu Date: 2011-11-16 12:57 +0900 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/cd6d236e863b 7111903: (tz) Windows-only: tzmappings needs update for KB2570791 Reviewed-by: peytoia ! src/windows/lib/tzmappings Changeset: 1266e72f7896 Author: okutsu Date: 2011-11-16 13:17 +0900 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/1266e72f7896 Merge Changeset: 398442b00b2b Author: ksrini Date: 2011-11-16 12:23 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/398442b00b2b 7112160: jdk8 javadoc failure in jdk/make/docs javadoc: error - java.lang.OutOfMemoryError Reviewed-by: ohair, katleman ! make/docs/Makefile Changeset: 3cd7dcf4a302 Author: mchung Date: 2011-11-17 15:47 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/3cd7dcf4a302 7067691: java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java failing intermittently Reviewed-by: alanb, mchung Contributed-by: gary.adams at oracle.com ! test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java ! test/java/lang/management/PlatformLoggingMXBean/PlatformLoggingMXBeanTest.java Changeset: 5bfff9616b86 Author: weijun Date: 2011-11-18 16:13 +0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/5bfff9616b86 7077172: KerberosTime does not take into account system clock adjustement Reviewed-by: valeriep ! src/share/classes/sun/security/krb5/internal/KerberosTime.java Changeset: cd37d8066437 Author: lana Date: 2011-11-18 11:11 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/cd37d8066437 Merge ! src/share/classes/sun/security/ssl/SSLSocketImpl.java Changeset: c98235762b30 Author: alanb Date: 2011-11-19 19:55 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/c98235762b30 6818464: TEST_BUG: java/util/Timer/KillThread.java failing intermittently Reviewed-by: dholmes, alanb, forax Contributed-by: gary.adams at oracle.com ! test/java/util/Timer/KillThread.java Changeset: 8be37eae9598 Author: alanb Date: 2011-11-19 19:59 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/8be37eae9598 6731620: TEST_BUG: java/util/Timer/Args.java is too optimistic about the execution time of System.out.printf Reviewed-by: dholmes, forax Contributed-by: gary.adams at oracle.com ! test/java/util/Timer/Args.java Changeset: 450c17e4808d Author: alanb Date: 2011-11-19 20:03 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/450c17e4808d 6860309: TEST_BUG: Insufficient sleep time in java/lang/Runtime/exec/StreamsSurviveDestroy.java Reviewed-by: alanb, dholmes, forax Contributed-by: gary.adams at oracle.com ! test/java/lang/Runtime/exec/StreamsSurviveDestroy.java Changeset: 184578f3e8b9 Author: alanb Date: 2011-11-21 12:51 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/184578f3e8b9 7084033: TEST_BUG: test/java/lang/ThreadGroup/Stop.java fails intermittently Reviewed-by: forax, chegar, dholmes Contributed-by: gary.adams at oracle.com ! test/java/lang/ThreadGroup/Stop.java Changeset: 2db942c7eb9c Author: alanb Date: 2011-11-21 12:57 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/2db942c7eb9c 7114125: TEST_BUG: java/util/Timer/KillThread.java should use volatile cross thread variable declaration Reviewed-by: dholmes, alanb Contributed-by: gary.adams at oracle.com ! test/java/util/Timer/KillThread.java Changeset: 81987765cb81 Author: ngmr Date: 2011-11-11 14:40 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/81987765cb81 7112670: Inet4AddressImpl should use getaddrinfo/getnameinfo Reviewed-by: chegar, alanb, mduigou, ngmr Contributed-by: Charles Lee ! src/solaris/native/java/net/Inet4AddressImpl.c ! src/solaris/native/java/net/Inet6AddressImpl.c ! src/solaris/native/java/net/net_util_md.c ! src/solaris/native/java/net/net_util_md.h Changeset: ee2fa62fb09f Author: ngmr Date: 2011-11-22 09:51 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/ee2fa62fb09f 7114558: Inet4AddressImpl should use memset (rather than bzero) and NI_MAXHOST (rather than MAXHOSTNAMELEN) Reviewed-by: chegar Contributed-by: Neil Richards ! src/solaris/native/java/net/Inet4AddressImpl.c ! src/solaris/native/java/net/Inet6AddressImpl.c Changeset: 1945abeb82a0 Author: mullan Date: 2011-11-22 08:58 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/1945abeb82a0 7093090: Reduce synchronization in java.security.Policy.getPolicyNoCheck Reviewed-by: valeriep ! src/share/classes/java/security/Policy.java Changeset: bb8f19b80557 Author: mullan Date: 2011-11-22 09:00 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/bb8f19b80557 Merge - test/java/io/FileDescriptor/FileChannelFDTest.java - test/java/io/etc/FileDescriptorSharing.java Changeset: b4d7020c2a40 Author: mullan Date: 2011-11-22 09:17 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/b4d7020c2a40 Merge Changeset: 82151e860a64 Author: xuelei Date: 2011-11-23 03:40 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/82151e860a64 7113275: compatibility issue with MD2 trust anchor and old X509TrustManager Summary: also reviewed by Dennis.Gu at oracle.com Reviewed-by: mullan ! src/share/classes/sun/security/ssl/SSLContextImpl.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/MD2InTrustAnchor.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/TrustTrustedCert.java Changeset: 7eb0debca9b3 Author: chegar Date: 2011-11-23 12:30 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/7eb0debca9b3 6776144: java/lang/ThreadGroup/NullThreadName.java fails with Thread group is not destroyed ,fastdebug LINUX Reviewed-by: chegar, dholmes Contributed-by: gary.adams at oracle.com ! test/java/lang/ThreadGroup/NullThreadName.java Changeset: d27f0b2f1476 Author: coffeys Date: 2011-11-23 14:55 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/d27f0b2f1476 7102369: remove java.rmi.server.codebase property parsing from registyimpl 7094468: rmiregistry clean up Reviewed-by: smarks ! src/share/classes/sun/rmi/registry/RegistryImpl.java ! src/share/classes/sun/rmi/server/LoaderHandler.java + test/java/rmi/registry/readTest/readTest.java + test/java/rmi/registry/readTest/readTest.sh + test/java/rmi/registry/readTest/testPkg/Client.java + test/java/rmi/registry/readTest/testPkg/Hello.java + test/java/rmi/registry/readTest/testPkg/Server.java Changeset: 855675a4235b Author: lana Date: 2011-11-23 11:37 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/855675a4235b Merge - test/java/io/FileDescriptor/FileChannelFDTest.java - test/java/io/etc/FileDescriptorSharing.java Changeset: 3c248d0e2c48 Author: lana Date: 2011-11-28 15:15 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/3c248d0e2c48 Merge - test/java/io/FileDescriptor/FileChannelFDTest.java - test/java/io/etc/FileDescriptorSharing.java Changeset: 929597c6e777 Author: katleman Date: 2011-12-01 10:33 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/929597c6e777 Added tag jdk8-b15 for changeset 3c248d0e2c48 ! .hgtags Changeset: 23acf34c80b0 Author: neugens Date: 2011-12-03 15:40 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/23acf34c80b0 7117914: Fix javac warnings in src/share/classes/sun/java2d Summary: Fix some javac warnings in java2d related code for the Warning Cleanup Day. Reviewed-by: prr, flar ! src/share/classes/java/awt/geom/Path2D.java ! src/share/classes/sun/awt/image/BufImgSurfaceData.java ! src/share/classes/sun/java2d/SunGraphics2D.java ! src/share/classes/sun/java2d/SurfaceData.java ! src/share/classes/sun/java2d/SurfaceDataProxy.java ! src/share/classes/sun/java2d/loops/GraphicsPrimitive.java ! src/share/classes/sun/java2d/loops/SurfaceType.java ! src/share/classes/sun/java2d/opengl/OGLBufImgOps.java ! src/share/classes/sun/java2d/opengl/OGLDrawImage.java ! src/share/classes/sun/java2d/opengl/OGLPaints.java ! src/share/classes/sun/java2d/opengl/OGLSurfaceData.java ! src/share/classes/sun/java2d/pipe/AAShapePipe.java ! src/share/classes/sun/java2d/pipe/BufferedPaints.java ! src/share/classes/sun/java2d/pipe/BufferedRenderPipe.java ! src/share/classes/sun/java2d/pipe/DrawImage.java ! src/share/classes/sun/java2d/pipe/GlyphListPipe.java ! src/share/classes/sun/java2d/pipe/LoopPipe.java ! src/share/classes/sun/java2d/pipe/RenderingEngine.java ! src/solaris/classes/sun/java2d/x11/X11Renderer.java ! src/solaris/classes/sun/java2d/x11/X11SurfaceData.java Changeset: 70b40ea06df0 Author: prr Date: 2011-12-03 16:26 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/70b40ea06df0 7117199: Fix javac warnings in src/share/classes/java/awt/font Reviewed-by: jgodinez, bae ! src/share/classes/java/awt/font/StyledParagraph.java ! src/share/classes/java/awt/font/TextAttribute.java ! src/share/classes/java/awt/font/TextLayout.java ! src/share/classes/java/awt/font/TextLine.java ! src/share/classes/java/awt/font/TextMeasurer.java Changeset: 4075d524fa46 Author: lana Date: 2011-12-06 16:15 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/4075d524fa46 Merge Changeset: e53a078c2840 Author: anthony Date: 2011-11-09 13:43 +0300 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/e53a078c2840 7045370: Java Statically Determines Display Size on Linux platforms Summary: Listen to ConfigureNotify events on the root window and update the current screen size accordingly Reviewed-by: art, bae ! src/share/classes/java/awt/Component.java ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/solaris/classes/sun/awt/X11GraphicsDevice.java ! src/solaris/native/sun/awt/awt_GraphicsEnv.c Changeset: 84e473cf4531 Author: rupashka Date: 2011-11-10 14:10 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/84e473cf4531 6938583: Unexpected NullPointerException by InputContext.endComposition() Reviewed-by: rupashka Contributed-by: Charles Lee ! src/share/classes/javax/swing/text/DefaultCaret.java + test/javax/swing/text/DefaultCaret/6938583/bug6938583.java Changeset: 81f1b32f9e24 Author: malenkov Date: 2011-11-10 17:15 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/81f1b32f9e24 7057459: Regression: Performance degradation with java.beans.XMLEncoder Reviewed-by: rupashka ! src/share/classes/java/beans/Encoder.java Changeset: e120c78cb45c Author: malenkov Date: 2011-11-10 17:27 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/e120c78cb45c 7064279: Introspector.getBeanInfo() should release some resources in timely manner Reviewed-by: art, alexp ! src/share/classes/java/beans/Beans.java ! src/share/classes/java/beans/Introspector.java ! src/share/classes/java/beans/PropertyEditorManager.java + src/share/classes/java/beans/ThreadGroupContext.java ! test/java/beans/Beans/6669869/TestDesignTime.java ! test/java/beans/Beans/6669869/TestGuiAvailable.java ! test/java/beans/Introspector/6380849/TestBeanInfo.java + test/java/beans/Introspector/7064279/Test7064279.java + test/java/beans/Introspector/7064279/test.jar ! test/java/beans/Introspector/Test6660539.java ! test/java/beans/PropertyEditor/6380849/TestPropertyEditor.java Changeset: 8b6a69b2e482 Author: malenkov Date: 2011-11-10 17:32 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/8b6a69b2e482 7087876: java/beans/PropertyDescriptor.html#createPropertyEditor() throws RE if editor cannot be created Reviewed-by: rupashka ! src/share/classes/java/beans/PropertyDescriptor.java + test/java/beans/PropertyEditor/Test7087876.java Changeset: b02495c51b9c Author: malenkov Date: 2011-11-10 17:35 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/b02495c51b9c 7092744: XMLEncoder fails to encode and breaks backward compatibility Reviewed-by: rupashka ! src/share/classes/com/sun/beans/finder/AbstractFinder.java ! src/share/classes/com/sun/beans/finder/ConstructorFinder.java ! src/share/classes/com/sun/beans/finder/MethodFinder.java + test/java/beans/XMLEncoder/Test7092744.java Changeset: 16327765859c Author: malenkov Date: 2011-11-10 17:37 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/16327765859c 7087429: Constructor of java.beans.PropertyChangeEvent should declare thrown NPE for null source Reviewed-by: rupashka ! src/share/classes/java/beans/PropertyChangeEvent.java + test/java/beans/PropertyChangeSupport/Test7087429.java Changeset: f614bcada2a9 Author: anthony Date: 2011-11-11 15:17 +0300 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/f614bcada2a9 7103610: _NET_WM_PID and WM_CLIENT_MACHINE are not set Summary: Set the properties to all top-level windows Reviewed-by: anthony Contributed-by: Danesh Dadachanji ! make/sun/xawt/mapfile-vers ! src/solaris/classes/sun/awt/X11/XWindowPeer.java ! src/solaris/native/sun/xawt/XToolkit.c Changeset: c0f3f1558a94 Author: rupashka Date: 2011-11-14 14:00 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/c0f3f1558a94 7109617: Test was writed for Metal L&F but not set it Reviewed-by: rupashka Contributed-by: alexandr.scherbatiy at oracle.com + test/javax/swing/plaf/metal/MetalLookAndFeel/5073047/bug5073047.java Changeset: a51777c9228a Author: malenkov Date: 2011-11-14 14:38 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/a51777c9228a 7110521: Regression test failed: Introspector/TestTypeResolver.java Reviewed-by: rupashka ! test/java/beans/Introspector/TestTypeResolver.java Changeset: 28f768c41a90 Author: serb Date: 2011-11-12 04:13 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/28f768c41a90 6996291: command line selection of MToolkit by -Dawt.toolkit=sun.awt.motif.MToolkit fails from jdk7 b21 on Reviewed-by: art, dcherepanov, bae, prr ! make/sun/awt/FILES_c_unix.gmk ! make/sun/awt/FILES_export_unix.gmk ! make/sun/awt/mapfile-mawt-vers ! make/sun/awt/mapfile-vers-linux ! make/sun/awt/mawt.gmk - make/sun/motif12/reorder-i586 - make/sun/motif12/reorder-sparc - make/sun/motif12/reorder-sparcv9 ! make/sun/xawt/mapfile-vers ! src/solaris/classes/sun/awt/X11/ListHelper.java ! src/solaris/classes/sun/awt/X11/XEmbedCanvasPeer.java ! src/solaris/classes/sun/awt/X11/XEmbedChildProxyPeer.java - src/solaris/classes/sun/awt/motif/AWTLockAccess.java ! src/solaris/classes/sun/awt/motif/MFontConfiguration.java - src/solaris/classes/sun/awt/motif/MFontPeer.java - src/solaris/classes/sun/awt/motif/MToolkit.java - src/solaris/classes/sun/awt/motif/MToolkitThreadBlockedHandler.java - src/solaris/classes/sun/awt/motif/MWindowAttributes.java - src/solaris/classes/sun/awt/motif/X11FontMetrics.java - src/solaris/native/sun/awt/MouseInfo.c - src/solaris/native/sun/awt/XDrawingArea.c - src/solaris/native/sun/awt/XDrawingArea.h - src/solaris/native/sun/awt/XDrawingAreaP.h ! src/solaris/native/sun/awt/awt.h ! src/solaris/native/sun/awt/awt_AWTEvent.c ! src/solaris/native/sun/awt/awt_Component.h - src/solaris/native/sun/awt/awt_Cursor.h ! src/solaris/native/sun/awt/awt_DrawingSurface.c ! src/solaris/native/sun/awt/awt_Font.c ! src/solaris/native/sun/awt/awt_Font.h ! src/solaris/native/sun/awt/awt_GraphicsEnv.c ! src/solaris/native/sun/awt/awt_InputMethod.c - src/solaris/native/sun/awt/awt_KeyboardFocusManager.h - src/solaris/native/sun/awt/awt_MToolkit.c - src/solaris/native/sun/awt/awt_MToolkit.h - src/solaris/native/sun/awt/awt_MenuItem.h - src/solaris/native/sun/awt/awt_PopupMenu.h ! src/solaris/native/sun/awt/awt_Robot.c - src/solaris/native/sun/awt/awt_TopLevel.h - src/solaris/native/sun/awt/awt_Window.h - src/solaris/native/sun/awt/awt_mgrsel.c - src/solaris/native/sun/awt/awt_mgrsel.h - src/solaris/native/sun/awt/awt_motif.h ! src/solaris/native/sun/awt/awt_p.h ! src/solaris/native/sun/awt/awt_util.c ! src/solaris/native/sun/awt/awt_util.h - src/solaris/native/sun/awt/awt_wm.c - src/solaris/native/sun/awt/awt_wm.h - src/solaris/native/sun/awt/awt_xembed.h - src/solaris/native/sun/awt/awt_xembed_server.c - src/solaris/native/sun/awt/awt_xembed_server.h ! src/solaris/native/sun/awt/canvas.h ! src/solaris/native/sun/awt/multi_font.c ! src/solaris/native/sun/awt/multi_font.h ! src/solaris/native/sun/java2d/opengl/GLXSurfaceData.c ! src/solaris/native/sun/java2d/opengl/GLXSurfaceData.h ! src/solaris/native/sun/java2d/x11/X11SurfaceData.c ! src/solaris/native/sun/xawt/XToolkit.c Changeset: 6a9d735ebd0a Author: bagiras Date: 2011-11-16 15:40 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/6a9d735ebd0a 7108598: Pogo Table Games freeze with JDK 7 Reviewed-by: art, ant ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java + test/java/awt/print/PaintSetEnabledDeadlock/PaintSetEnabledDeadlock.java Changeset: 1df53949945d Author: lana Date: 2011-11-18 15:49 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/1df53949945d Merge Changeset: 90d33a64a404 Author: rupashka Date: 2011-11-21 18:22 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/90d33a64a404 7109085: Test use hotkeys not intended for Mac Reviewed-by: rupashka Contributed-by: alexandr.scherbatiy at oracle.com ! test/javax/swing/regtesthelpers/Util.java + test/javax/swing/text/DefaultEditorKit/4278839/bug4278839.java + test/javax/swing/text/JTextComponent/5074573/bug5074573.java + test/javax/swing/text/html/HTMLEditorKit/5043626/bug5043626.java Changeset: c3c80f96cb83 Author: rupashka Date: 2011-11-25 11:52 +0300 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/c3c80f96cb83 7113337: Swing closed test tries to click in the area reserved for resize by Mac OS X Reviewed-by: rupashka Contributed-by: alexandr.scherbatiy at oracle.com + test/javax/swing/PopupFactory/6276087/NonOpaquePopupMenuTest.java Changeset: 9cbc208dcf08 Author: rupashka Date: 2011-11-29 12:47 +0300 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/9cbc208dcf08 7112925: closed/javax/swing/JTabbedPane/4624207/bug4624207.java fails on MacOS Reviewed-by: rupashka Contributed-by: alexandr.scherbatiy at oracle.com + test/javax/swing/JTabbedPane/4624207/bug4624207.java Changeset: 051beb804b12 Author: rupashka Date: 2011-11-30 16:54 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/051beb804b12 7110440: closed/javax/swing/JScrollBar/4865918/bug4865918.java fails on Aqua L&F Reviewed-by: rupashka Contributed-by: alexandr.scherbatiy at oracle.com + test/javax/swing/JScrollBar/4865918/bug4865918.java Changeset: 7dd4395fe4a5 Author: rupashka Date: 2011-11-30 19:38 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/7dd4395fe4a5 7115357: closed/javax/swing/JTable/6263446/bug6263446Table.java fails on MacOS Reviewed-by: rupashka Contributed-by: alexandr.scherbatiy at oracle.com + test/javax/swing/JTable/6263446/bug6263446.java Changeset: 4b416a0180dc Author: lana Date: 2011-11-29 15:57 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/4b416a0180dc Merge - test/java/io/FileDescriptor/FileChannelFDTest.java - test/java/io/etc/FileDescriptorSharing.java Changeset: 45eb5a61da07 Author: lana Date: 2011-11-30 12:06 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/45eb5a61da07 Merge Changeset: 79b5c5a8c7e9 Author: serb Date: 2011-12-05 17:11 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/79b5c5a8c7e9 7115400: jdk 8 awt-gate build fails in headless toolkit on solaris. Reviewed-by: prr, art, bae ! make/sun/awt/FILES_c_unix.gmk + src/solaris/native/sun/awt/HeadlessToolkit.c ! src/solaris/native/sun/java2d/x11/X11SurfaceData.h Changeset: 2b1438297561 Author: lana Date: 2011-12-06 16:17 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/2b1438297561 Merge - make/sun/motif12/reorder-i586 - make/sun/motif12/reorder-sparc - make/sun/motif12/reorder-sparcv9 - src/solaris/classes/sun/awt/motif/AWTLockAccess.java - src/solaris/classes/sun/awt/motif/MFontPeer.java - src/solaris/classes/sun/awt/motif/MToolkit.java - src/solaris/classes/sun/awt/motif/MToolkitThreadBlockedHandler.java - src/solaris/classes/sun/awt/motif/MWindowAttributes.java - src/solaris/classes/sun/awt/motif/X11FontMetrics.java - src/solaris/native/sun/awt/MouseInfo.c - src/solaris/native/sun/awt/XDrawingArea.c - src/solaris/native/sun/awt/XDrawingArea.h - src/solaris/native/sun/awt/XDrawingAreaP.h - src/solaris/native/sun/awt/awt_Cursor.h - src/solaris/native/sun/awt/awt_KeyboardFocusManager.h - src/solaris/native/sun/awt/awt_MToolkit.c - src/solaris/native/sun/awt/awt_MToolkit.h - src/solaris/native/sun/awt/awt_MenuItem.h - src/solaris/native/sun/awt/awt_PopupMenu.h - src/solaris/native/sun/awt/awt_TopLevel.h - src/solaris/native/sun/awt/awt_Window.h - src/solaris/native/sun/awt/awt_mgrsel.c - src/solaris/native/sun/awt/awt_mgrsel.h - src/solaris/native/sun/awt/awt_motif.h - src/solaris/native/sun/awt/awt_wm.c - src/solaris/native/sun/awt/awt_wm.h - src/solaris/native/sun/awt/awt_xembed.h - src/solaris/native/sun/awt/awt_xembed_server.c - src/solaris/native/sun/awt/awt_xembed_server.h Changeset: 387190e1f782 Author: chegar Date: 2011-11-25 10:34 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/387190e1f782 7115150: java.net.HttpCookie code cleanup, style, formatting, typos Reviewed-by: michaelm ! src/share/classes/java/net/HttpCookie.java Changeset: e5ecbf555679 Author: chegar Date: 2011-11-25 13:46 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/e5ecbf555679 7115586: Suppress creation of SocketImpl in SocketAdaptor's constructor Reviewed-by: chegar, alanb Contributed-by: sajia at taobao.com ! src/share/classes/sun/nio/ch/SocketAdaptor.java Changeset: 022540b11147 Author: weijun Date: 2011-11-28 18:16 +0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/022540b11147 7115744: Do not call File::deleteOnExit in security tests Reviewed-by: xuelei ! test/sun/security/krb5/auto/CrossRealm.java ! test/sun/security/krb5/auto/HttpNegotiateServer.java ! test/sun/security/krb5/auto/KDC.java ! test/sun/security/krb5/auto/OkAsDelegateXRealm.java ! test/sun/security/krb5/auto/OneKDC.java ! test/sun/security/krb5/auto/SSL.java ! test/sun/security/krb5/auto/W83.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngineResult/Deserialize.java Changeset: d1928ae4e0a2 Author: xuelei Date: 2011-11-28 02:35 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/d1928ae4e0a2 7115524: sun.security.provider.certpath.ssl.SSLServerCertStore no longer works Reviewed-by: weijun ! src/share/classes/sun/security/provider/certpath/ssl/SSLServerCertStore.java Changeset: 955aae8c1106 Author: ngmr Date: 2011-11-24 11:34 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/955aae8c1106 7115070: (fs) lookupPrincipalByName/lookupPrincipalByGroupName should treat ESRCH as not found Reviewed-by: alanb Contributed-by: Jonathan Lu ! src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c Changeset: 6fbd69f8e3ab Author: ngmr Date: 2011-11-18 09:03 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/6fbd69f8e3ab 7094995: Trailing daemon thread causes continuous GC in agentvm mode Summary: Shutdown GcInducingThread once test (successfully) finishes Reviewed-by: alanb, chegar, dholmes, darcy Contributed-by: Neil Richards ! test/java/util/zip/ZipFile/ClearStaleZipFileInputStreams.java Changeset: cf47846165f4 Author: dholmes Date: 2011-11-29 00:26 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/cf47846165f4 7109092: Wrong computation results with double at armsflt Summary: need to link to custom soft-float library with required FP accuracy Reviewed-by: alanb, ohair ! make/common/Defs-embedded.gmk Changeset: a47de985fec9 Author: sherman Date: 2011-11-29 11:39 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/a47de985fec9 7110149: Update the JDK8 bundled zlib library to the latest version 1.2.5 Summary: updated to zlib-1.2.5 Reviewed-by: alanb ! make/common/Defs.gmk ! make/java/zip/FILES_c.gmk ! make/sun/splashscreen/FILES_c.gmk - src/share/native/java/util/zip/zlib-1.2.3/ChangeLog - src/share/native/java/util/zip/zlib-1.2.3/README - src/share/native/java/util/zip/zlib-1.2.3/compress.c - src/share/native/java/util/zip/zlib-1.2.3/crc32.h - src/share/native/java/util/zip/zlib-1.2.3/deflate.c - src/share/native/java/util/zip/zlib-1.2.3/deflate.h - src/share/native/java/util/zip/zlib-1.2.3/gzio.c - src/share/native/java/util/zip/zlib-1.2.3/infback.c - src/share/native/java/util/zip/zlib-1.2.3/inffast.c - src/share/native/java/util/zip/zlib-1.2.3/inffast.h - src/share/native/java/util/zip/zlib-1.2.3/inffixed.h - src/share/native/java/util/zip/zlib-1.2.3/inflate.c - src/share/native/java/util/zip/zlib-1.2.3/inflate.h - src/share/native/java/util/zip/zlib-1.2.3/inftrees.c - src/share/native/java/util/zip/zlib-1.2.3/inftrees.h - src/share/native/java/util/zip/zlib-1.2.3/patches/ChangeLog_java - src/share/native/java/util/zip/zlib-1.2.3/patches/crc32.c.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/inflate.c.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/zconf.h.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/zlib.h.diff - src/share/native/java/util/zip/zlib-1.2.3/trees.c - src/share/native/java/util/zip/zlib-1.2.3/trees.h - src/share/native/java/util/zip/zlib-1.2.3/uncompr.c - src/share/native/java/util/zip/zlib-1.2.3/zadler32.c - src/share/native/java/util/zip/zlib-1.2.3/zconf.h - src/share/native/java/util/zip/zlib-1.2.3/zcrc32.c - src/share/native/java/util/zip/zlib-1.2.3/zlib.h - src/share/native/java/util/zip/zlib-1.2.3/zutil.c - src/share/native/java/util/zip/zlib-1.2.3/zutil.h + src/share/native/java/util/zip/zlib-1.2.5/ChangeLog + src/share/native/java/util/zip/zlib-1.2.5/README + src/share/native/java/util/zip/zlib-1.2.5/compress.c + src/share/native/java/util/zip/zlib-1.2.5/crc32.h + src/share/native/java/util/zip/zlib-1.2.5/deflate.c + src/share/native/java/util/zip/zlib-1.2.5/deflate.h + src/share/native/java/util/zip/zlib-1.2.5/gzclose.c + src/share/native/java/util/zip/zlib-1.2.5/gzguts.h + src/share/native/java/util/zip/zlib-1.2.5/gzlib.c + src/share/native/java/util/zip/zlib-1.2.5/gzread.c + src/share/native/java/util/zip/zlib-1.2.5/gzwrite.c + src/share/native/java/util/zip/zlib-1.2.5/infback.c + src/share/native/java/util/zip/zlib-1.2.5/inffast.c + src/share/native/java/util/zip/zlib-1.2.5/inffast.h + src/share/native/java/util/zip/zlib-1.2.5/inffixed.h + src/share/native/java/util/zip/zlib-1.2.5/inflate.c + src/share/native/java/util/zip/zlib-1.2.5/inflate.h + src/share/native/java/util/zip/zlib-1.2.5/inftrees.c + src/share/native/java/util/zip/zlib-1.2.5/inftrees.h + src/share/native/java/util/zip/zlib-1.2.5/patches/ChangeLog_java + src/share/native/java/util/zip/zlib-1.2.5/trees.c + src/share/native/java/util/zip/zlib-1.2.5/trees.h + src/share/native/java/util/zip/zlib-1.2.5/uncompr.c + src/share/native/java/util/zip/zlib-1.2.5/zadler32.c + src/share/native/java/util/zip/zlib-1.2.5/zconf.h + src/share/native/java/util/zip/zlib-1.2.5/zcrc32.c + src/share/native/java/util/zip/zlib-1.2.5/zlib.h + src/share/native/java/util/zip/zlib-1.2.5/zutil.c + src/share/native/java/util/zip/zlib-1.2.5/zutil.h + test/java/util/zip/DeInflate.java Changeset: 07e359b01d8a Author: sherman Date: 2011-11-29 13:05 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/07e359b01d8a 7109837: Provide a mechanism for computing an Adler32 checksum for the contents of a ByteBuffer Summary: added methods Adler32/CRC32.update(ByteBuffer) Reviewed-by: alanb ! make/java/zip/mapfile-vers ! src/share/classes/java/util/zip/Adler32.java ! src/share/classes/java/util/zip/CRC32.java ! src/share/native/java/util/zip/Adler32.c ! src/share/native/java/util/zip/CRC32.c + test/java/util/zip/TimeChecksum.java Changeset: c5313d712ab0 Author: lana Date: 2011-11-29 12:04 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/c5313d712ab0 Merge Changeset: a3edcdff37e1 Author: lana Date: 2011-11-29 13:49 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/a3edcdff37e1 Merge Changeset: 4749df4f04f1 Author: alanb Date: 2011-11-30 10:57 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/4749df4f04f1 7030624: size_t usages in src/windows/native/java/io/io_util_md.c need to be re-visited Reviewed-by: lancea, chegar ! src/share/native/java/io/io_util.c ! src/windows/native/java/io/io_util_md.c ! src/windows/native/java/io/io_util_md.h Changeset: 7795c41ed54c Author: alanb Date: 2011-11-30 12:42 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/7795c41ed54c 7116404: Miscellaneous warnings (java.rmi.**, serialization, some core classes) Reviewed-by: lancea, chegar, smarks ! src/share/classes/java/io/File.java ! src/share/classes/java/io/ObjectInputStream.java ! src/share/classes/java/io/ObjectOutputStream.java ! src/share/classes/java/io/ObjectStreamClass.java ! src/share/classes/java/io/SequenceInputStream.java ! src/share/classes/java/lang/ClassLoader.java ! src/share/classes/java/lang/Enum.java ! src/share/classes/java/lang/Package.java ! src/share/classes/java/lang/Runtime.java ! src/share/classes/java/lang/SecurityManager.java ! src/share/classes/java/lang/System.java ! src/share/classes/java/lang/Thread.java ! src/share/classes/java/lang/ThreadGroup.java ! src/share/classes/java/rmi/MarshalledObject.java ! src/share/classes/java/rmi/dgc/VMID.java ! src/share/classes/java/rmi/server/LogStream.java ! src/share/classes/java/rmi/server/RemoteObject.java ! src/share/classes/sun/misc/JavaLangAccess.java ! src/share/classes/sun/misc/Launcher.java ! src/share/classes/sun/misc/Unsafe.java ! src/share/classes/sun/misc/VM.java Changeset: 43a630f11af6 Author: smarks Date: 2011-11-30 13:11 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/43a630f11af6 7116322: enhance javac make rule with a little bit of instrumentation Reviewed-by: dholmes, ohair ! make/common/Rules.gmk Changeset: 3b8186aee592 Author: chegar Date: 2011-12-01 11:09 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/3b8186aee592 7116722: Miscellaneous warnings sun.misc ( and related classes ) Reviewed-by: alanb, darcy, forax, hawtin, lancea ! src/share/classes/com/sun/net/httpserver/spi/HttpServerProvider.java ! src/share/classes/java/net/InetAddress.java ! src/share/classes/java/util/jar/JarVerifier.java ! src/share/classes/java/util/jar/JavaUtilJarAccessImpl.java ! src/share/classes/javax/script/ScriptEngineManager.java ! src/share/classes/sun/misc/BASE64Decoder.java ! src/share/classes/sun/misc/ExtensionDependency.java ! src/share/classes/sun/misc/JarIndex.java ! src/share/classes/sun/misc/JavaUtilJarAccess.java ! src/share/classes/sun/misc/ProxyGenerator.java ! src/share/classes/sun/misc/Service.java ! src/share/classes/sun/misc/Signal.java ! test/sun/misc/JarIndex/metaInfFilenames/Basic.java Changeset: 89130611b178 Author: mcimadamore Date: 2011-12-01 18:34 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/89130611b178 7116954: Misc warnings in java.beans/java.beans.context Summary: Remove generic warnings form java.beans and java.beans.context Reviewed-by: alanb, chegar ! src/share/classes/java/beans/BeanDescriptor.java ! src/share/classes/java/beans/Beans.java ! src/share/classes/java/beans/ChangeListenerMap.java ! src/share/classes/java/beans/DefaultPersistenceDelegate.java ! src/share/classes/java/beans/Encoder.java ! src/share/classes/java/beans/EventHandler.java ! src/share/classes/java/beans/EventSetDescriptor.java ! src/share/classes/java/beans/FeatureDescriptor.java ! src/share/classes/java/beans/IndexedPropertyDescriptor.java ! src/share/classes/java/beans/Introspector.java ! src/share/classes/java/beans/MetaData.java ! src/share/classes/java/beans/MethodDescriptor.java ! src/share/classes/java/beans/NameGenerator.java ! src/share/classes/java/beans/PersistenceDelegate.java ! src/share/classes/java/beans/PropertyChangeSupport.java ! src/share/classes/java/beans/PropertyDescriptor.java ! src/share/classes/java/beans/PropertyEditorSupport.java ! src/share/classes/java/beans/ReflectionUtils.java ! src/share/classes/java/beans/SimpleBeanInfo.java ! src/share/classes/java/beans/Statement.java ! src/share/classes/java/beans/VetoableChangeSupport.java ! src/share/classes/java/beans/XMLEncoder.java ! src/share/classes/java/beans/beancontext/BeanContext.java ! src/share/classes/java/beans/beancontext/BeanContextMembershipEvent.java Changeset: 0e3f706741ca Author: smarks Date: 2011-12-01 16:14 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/0e3f706741ca 7116890: additional warnings fixes for java.io Reviewed-by: alanb, smarks Contributed-by: Sebastian Sickelmann ! src/share/classes/java/io/ExpiringCache.java ! src/share/classes/java/io/LineNumberInputStream.java ! src/share/classes/java/io/LineNumberReader.java ! src/share/classes/java/io/ObjectOutputStream.java ! src/share/classes/java/io/RandomAccessFile.java Changeset: b03da32c3186 Author: peytoia Date: 2011-12-02 16:09 +0900 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/b03da32c3186 7056472: Speed up test/java/util/ResourceBundle/Control/ExpirationTest.sh Reviewed-by: okutsu - test/java/util/ResourceBundle/Control/ExpirationTest.java - test/java/util/ResourceBundle/Control/ExpirationTest.sh Changeset: f615db07991e Author: chegar Date: 2011-12-02 11:39 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/f615db07991e 7116946: JSSecurityManager should use java.util.ServiceLoader to lookup service providers Reviewed-by: prr ! src/share/classes/com/sun/media/sound/JSSecurityManager.java Changeset: 37f6e294759f Author: chegar Date: 2011-12-02 14:17 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/37f6e294759f 7116957: javax.script.ScriptEngineManager should use java.util.ServiceLoader to lookup service providers Reviewed-by: alanb, lancea ! src/share/classes/com/sun/net/httpserver/spi/HttpServerProvider.java ! src/share/classes/javax/script/ScriptEngineManager.java ! src/share/classes/sun/net/ftp/FtpClientProvider.java Changeset: 9950e2c9f3b5 Author: alanb Date: 2011-12-02 17:37 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/9950e2c9f3b5 7117357: Warnings in sun.instrument, tools and other sun.* classes Reviewed-by: lancea, chegar ! src/share/classes/sun/instrument/InstrumentationImpl.java ! src/share/classes/sun/instrument/TransformerManager.java ! src/share/classes/sun/launcher/LauncherHelper.java ! src/share/classes/sun/management/counter/perf/PerfInstrumentation.java ! src/share/classes/sun/management/jmxremote/ConnectorBootstrap.java ! src/share/classes/sun/net/RegisteredDomain.java ! src/share/classes/sun/net/www/protocol/jar/Handler.java ! src/share/classes/sun/tools/attach/HotSpotAttachProvider.java ! src/share/classes/sun/tools/jinfo/JInfo.java ! src/share/classes/sun/tools/jmap/JMap.java ! src/share/classes/sun/tools/jps/Jps.java ! src/share/classes/sun/tools/jstack/JStack.java ! src/share/classes/sun/tools/serialver/SerialVer.java Changeset: 42532a097816 Author: naoto Date: 2011-12-02 16:04 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/42532a097816 7117465: Warning cleanup for IMF classes Reviewed-by: okutsu ! src/share/classes/java/awt/im/InputMethodHighlight.java ! src/share/classes/sun/awt/im/CompositionArea.java ! src/share/classes/sun/awt/im/CompositionAreaHandler.java ! src/share/classes/sun/awt/im/InputContext.java ! src/share/classes/sun/awt/im/InputMethodContext.java ! src/share/classes/sun/awt/im/InputMethodJFrame.java ! src/share/classes/sun/awt/im/InputMethodManager.java ! src/share/classes/sun/awt/im/SimpleInputMethodWindow.java Changeset: 1d7037df65ed Author: sherman Date: 2011-12-02 16:25 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/1d7037df65ed 5035850: (str) String.CASE_INSENSITIVE_ORDER should override readResolve() Summary: Fix to ensure singleton property of String.CaseInsensitiveComparator is maintained through de/serialization. Reviewed-by: alanb, forax, smarks, dholmes Contributed-by: darryl.mocek at oracle.com ! src/share/classes/java/lang/String.java + test/java/lang/String/CaseInsensitiveComparator.java Changeset: 98502d7a3f98 Author: mchung Date: 2011-12-02 16:29 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/98502d7a3f98 7117585: Eliminate java.lang.instrument, java.lang.management warnings Reviewed-by: mchung Contributed-by: Jon VanAlten ! src/share/classes/java/lang/instrument/ClassDefinition.java ! src/share/classes/java/lang/management/ManagementFactory.java ! src/share/classes/java/lang/management/PlatformComponent.java Changeset: 3c524deb8431 Author: lancea Date: 2011-12-02 19:33 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/3c524deb8431 7116445: Miscellaneous warnings in the JDBC/RowSet classes Reviewed-by: smarks, chegar ! src/share/classes/com/sun/rowset/CachedRowSetImpl.java ! src/share/classes/com/sun/rowset/FilteredRowSetImpl.java ! src/share/classes/com/sun/rowset/JdbcRowSetImpl.java ! src/share/classes/com/sun/rowset/JdbcRowSetResourceBundle.java ! src/share/classes/com/sun/rowset/JoinRowSetImpl.java ! src/share/classes/com/sun/rowset/WebRowSetImpl.java ! src/share/classes/com/sun/rowset/internal/CachedRowSetReader.java ! src/share/classes/com/sun/rowset/internal/CachedRowSetWriter.java ! src/share/classes/com/sun/rowset/internal/Row.java ! src/share/classes/com/sun/rowset/internal/SyncResolverImpl.java ! src/share/classes/com/sun/rowset/internal/WebRowSetXmlWriter.java ! src/share/classes/com/sun/rowset/internal/XmlReaderContentHandler.java ! src/share/classes/java/sql/Date.java ! src/share/classes/java/sql/DriverManager.java ! src/share/classes/java/sql/Time.java ! src/share/classes/java/sql/Timestamp.java ! src/share/classes/javax/sql/StatementEvent.java ! src/share/classes/javax/sql/rowset/BaseRowSet.java ! src/share/classes/javax/sql/rowset/RowSetMetaDataImpl.java ! src/share/classes/javax/sql/rowset/RowSetProvider.java ! src/share/classes/javax/sql/rowset/serial/SQLInputImpl.java ! src/share/classes/javax/sql/rowset/serial/SQLOutputImpl.java ! src/share/classes/javax/sql/rowset/serial/SerialArray.java ! src/share/classes/javax/sql/rowset/serial/SerialBlob.java ! src/share/classes/javax/sql/rowset/serial/SerialJavaObject.java ! src/share/classes/javax/sql/rowset/serial/SerialRef.java ! src/share/classes/javax/sql/rowset/serial/SerialStruct.java ! src/share/classes/javax/sql/rowset/spi/SyncFactory.java Changeset: f2a5d0001f15 Author: okutsu Date: 2011-12-03 10:58 +0900 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/f2a5d0001f15 7117487: Warnings Cleanup: some i18n classes in java.util and sun.util Reviewed-by: lancea, naoto ! src/share/classes/java/util/Date.java ! src/share/classes/java/util/GregorianCalendar.java ! src/share/classes/java/util/JapaneseImperialCalendar.java ! src/share/classes/java/util/ResourceBundle.java ! src/share/classes/sun/util/calendar/BaseCalendar.java ! src/share/classes/sun/util/calendar/CalendarSystem.java ! src/share/classes/sun/util/calendar/LocalGregorianCalendar.java ! src/share/classes/sun/util/calendar/ZoneInfo.java ! src/share/classes/sun/util/calendar/ZoneInfoFile.java ! src/share/classes/sun/util/resources/OpenListResourceBundle.java ! src/share/classes/sun/util/resources/TimeZoneNamesBundle.java Changeset: 2ae848ea980a Author: weijun Date: 2011-12-05 10:19 +0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/2ae848ea980a 7116857: Warnings in javax.security and some sun.misc Reviewed-by: smarks ! src/share/classes/javax/security/auth/kerberos/ServicePermission.java ! src/share/classes/sun/misc/CEFormatException.java ! src/share/classes/sun/misc/CEStreamExhausted.java ! src/share/classes/sun/misc/ClassLoaderUtil.java ! src/share/classes/sun/misc/CompoundEnumeration.java ! src/share/classes/sun/misc/ExtensionInstallationException.java ! src/share/classes/sun/misc/FloatingDecimal.java ! src/share/classes/sun/misc/FormattedFloatingDecimal.java ! src/share/classes/sun/misc/InvalidJarIndexException.java ! src/share/classes/sun/misc/LRUCache.java ! src/share/classes/sun/misc/Queue.java ! src/share/classes/sun/misc/RequestProcessor.java ! src/share/classes/sun/misc/ServiceConfigurationError.java ! src/share/classes/sun/misc/URLClassPath.java Changeset: 053cb321467a Author: alanb Date: 2011-12-05 12:23 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/053cb321467a 7117717: (aio) Tests failing due to implementation bug 7052549 Reviewed-by: weijun, chegar ! test/ProblemList.txt ! test/java/nio/channels/AsynchronousSocketChannel/Basic.java Changeset: da28826c5672 Author: alanb Date: 2011-12-05 12:24 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/da28826c5672 Merge Changeset: f352dd3cdff8 Author: dl Date: 2011-12-05 13:58 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/f352dd3cdff8 7117360: Warnings in java.util.concurrent.atomic package Reviewed-by: chegar, dholmes ! src/share/classes/java/util/concurrent/atomic/AtomicBoolean.java ! src/share/classes/java/util/concurrent/atomic/AtomicInteger.java ! src/share/classes/java/util/concurrent/atomic/AtomicIntegerArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicLong.java ! src/share/classes/java/util/concurrent/atomic/AtomicLongArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicLongFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicReference.java ! src/share/classes/java/util/concurrent/atomic/AtomicReferenceArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicStampedReference.java Changeset: 194faa6fdb3c Author: sherman Date: 2011-12-05 10:50 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/194faa6fdb3c 5063455: (fmt) MissingFormatArgumentException.getFormatSpecifier() incorrect return value Summary: updated the incorrect StringBuilder constructor usage Reviewed-by: dholmes, sherman Contributed-by: brandon.passanisi at oracle.com ! src/share/classes/java/util/Formatter.java + test/java/util/MissingFormatArgumentException/GetFormatSpecifier.java Changeset: ca383e32deaf Author: peytoia Date: 2011-12-06 08:39 +0900 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/ca383e32deaf 7116914: Miscellaneous warnings (sun.text) Reviewed-by: smarks, okutsu ! src/share/classes/sun/text/CompactByteArray.java ! src/share/classes/sun/text/IntHashtable.java ! src/share/classes/sun/text/bidi/BidiBase.java ! src/share/classes/sun/text/normalizer/ICUData.java ! src/share/classes/sun/text/normalizer/NormalizerBase.java ! src/share/classes/sun/text/normalizer/NormalizerImpl.java ! src/share/classes/sun/text/normalizer/SymbolTable.java ! src/share/classes/sun/text/normalizer/UnicodeSet.java ! src/share/classes/sun/text/normalizer/UnicodeSetIterator.java ! src/share/classes/sun/text/normalizer/VersionInfo.java Changeset: f4fe86bba8a2 Author: smarks Date: 2011-12-05 16:30 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/f4fe86bba8a2 7116993: fix warnings in java.applet Reviewed-by: art, smarks Contributed-by: Danesh Dadachanji ! src/share/classes/java/applet/Applet.java Changeset: 85363edbc92f Author: naoto Date: 2011-12-05 17:08 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/85363edbc92f 7117469: Warning cleanup for j.u.Currency and j.u.Locale related classes Reviewed-by: okutsu, smarks ! src/share/classes/java/util/Currency.java ! src/share/classes/sun/util/LocaleServiceProviderPool.java ! src/share/classes/sun/util/resources/LocaleData.java Changeset: 77f6d4360f4b Author: smarks Date: 2011-12-06 10:14 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/77f6d4360f4b 7116997: fix warnings in java.util.PropertyPermission Reviewed-by: smarks Contributed-by: Brandon Passanisi ! src/share/classes/java/util/PropertyPermission.java Changeset: b71d1acfae52 Author: lana Date: 2011-12-06 20:25 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/b71d1acfae52 Merge ! src/share/classes/java/beans/Beans.java ! src/share/classes/java/beans/Encoder.java ! src/share/classes/java/beans/Introspector.java ! src/share/classes/java/beans/PropertyDescriptor.java - src/share/native/java/util/zip/zlib-1.2.3/ChangeLog - src/share/native/java/util/zip/zlib-1.2.3/README - src/share/native/java/util/zip/zlib-1.2.3/compress.c - src/share/native/java/util/zip/zlib-1.2.3/crc32.h - src/share/native/java/util/zip/zlib-1.2.3/deflate.c - src/share/native/java/util/zip/zlib-1.2.3/deflate.h - src/share/native/java/util/zip/zlib-1.2.3/gzio.c - src/share/native/java/util/zip/zlib-1.2.3/infback.c - src/share/native/java/util/zip/zlib-1.2.3/inffast.c - src/share/native/java/util/zip/zlib-1.2.3/inffast.h - src/share/native/java/util/zip/zlib-1.2.3/inffixed.h - src/share/native/java/util/zip/zlib-1.2.3/inflate.c - src/share/native/java/util/zip/zlib-1.2.3/inflate.h - src/share/native/java/util/zip/zlib-1.2.3/inftrees.c - src/share/native/java/util/zip/zlib-1.2.3/inftrees.h - src/share/native/java/util/zip/zlib-1.2.3/patches/ChangeLog_java - src/share/native/java/util/zip/zlib-1.2.3/patches/crc32.c.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/inflate.c.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/zconf.h.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/zlib.h.diff - src/share/native/java/util/zip/zlib-1.2.3/trees.c - src/share/native/java/util/zip/zlib-1.2.3/trees.h - src/share/native/java/util/zip/zlib-1.2.3/uncompr.c - src/share/native/java/util/zip/zlib-1.2.3/zadler32.c - src/share/native/java/util/zip/zlib-1.2.3/zconf.h - src/share/native/java/util/zip/zlib-1.2.3/zcrc32.c - src/share/native/java/util/zip/zlib-1.2.3/zlib.h - src/share/native/java/util/zip/zlib-1.2.3/zutil.c - src/share/native/java/util/zip/zlib-1.2.3/zutil.h - test/java/util/ResourceBundle/Control/ExpirationTest.java - test/java/util/ResourceBundle/Control/ExpirationTest.sh Changeset: cd95291bbbf3 Author: katleman Date: 2011-12-15 12:16 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/cd95291bbbf3 Added tag jdk8-b17 for changeset b71d1acfae52 ! .hgtags Changeset: 8f3d916a9164 Author: katleman Date: 2011-12-15 15:47 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/8f3d916a9164 Added tag jdk8-b16 for changeset 929597c6e777 ! .hgtags Changeset: e55ac966ed95 Author: katleman Date: 2011-12-15 15:55 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/e55ac966ed95 Merge ! .hgtags - make/sun/motif12/reorder-i586 - make/sun/motif12/reorder-sparc - make/sun/motif12/reorder-sparcv9 - src/share/native/java/util/zip/zlib-1.2.3/ChangeLog - src/share/native/java/util/zip/zlib-1.2.3/README - src/share/native/java/util/zip/zlib-1.2.3/compress.c - src/share/native/java/util/zip/zlib-1.2.3/crc32.h - src/share/native/java/util/zip/zlib-1.2.3/deflate.c - src/share/native/java/util/zip/zlib-1.2.3/deflate.h - src/share/native/java/util/zip/zlib-1.2.3/gzio.c - src/share/native/java/util/zip/zlib-1.2.3/infback.c - src/share/native/java/util/zip/zlib-1.2.3/inffast.c - src/share/native/java/util/zip/zlib-1.2.3/inffast.h - src/share/native/java/util/zip/zlib-1.2.3/inffixed.h - src/share/native/java/util/zip/zlib-1.2.3/inflate.c - src/share/native/java/util/zip/zlib-1.2.3/inflate.h - src/share/native/java/util/zip/zlib-1.2.3/inftrees.c - src/share/native/java/util/zip/zlib-1.2.3/inftrees.h - src/share/native/java/util/zip/zlib-1.2.3/patches/ChangeLog_java - src/share/native/java/util/zip/zlib-1.2.3/patches/crc32.c.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/inflate.c.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/zconf.h.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/zlib.h.diff - src/share/native/java/util/zip/zlib-1.2.3/trees.c - src/share/native/java/util/zip/zlib-1.2.3/trees.h - src/share/native/java/util/zip/zlib-1.2.3/uncompr.c - src/share/native/java/util/zip/zlib-1.2.3/zadler32.c - src/share/native/java/util/zip/zlib-1.2.3/zconf.h - src/share/native/java/util/zip/zlib-1.2.3/zcrc32.c - src/share/native/java/util/zip/zlib-1.2.3/zlib.h - src/share/native/java/util/zip/zlib-1.2.3/zutil.c - src/share/native/java/util/zip/zlib-1.2.3/zutil.h - src/solaris/classes/sun/awt/motif/AWTLockAccess.java - src/solaris/classes/sun/awt/motif/MFontPeer.java - src/solaris/classes/sun/awt/motif/MToolkit.java - src/solaris/classes/sun/awt/motif/MToolkitThreadBlockedHandler.java - src/solaris/classes/sun/awt/motif/MWindowAttributes.java - src/solaris/classes/sun/awt/motif/X11FontMetrics.java - src/solaris/native/sun/awt/MouseInfo.c - src/solaris/native/sun/awt/XDrawingArea.c - src/solaris/native/sun/awt/XDrawingArea.h - src/solaris/native/sun/awt/XDrawingAreaP.h - src/solaris/native/sun/awt/awt_Cursor.h - src/solaris/native/sun/awt/awt_KeyboardFocusManager.h - src/solaris/native/sun/awt/awt_MToolkit.c - src/solaris/native/sun/awt/awt_MToolkit.h - src/solaris/native/sun/awt/awt_MenuItem.h - src/solaris/native/sun/awt/awt_PopupMenu.h - src/solaris/native/sun/awt/awt_TopLevel.h - src/solaris/native/sun/awt/awt_Window.h - src/solaris/native/sun/awt/awt_mgrsel.c - src/solaris/native/sun/awt/awt_mgrsel.h - src/solaris/native/sun/awt/awt_motif.h - src/solaris/native/sun/awt/awt_wm.c - src/solaris/native/sun/awt/awt_wm.h - src/solaris/native/sun/awt/awt_xembed.h - src/solaris/native/sun/awt/awt_xembed_server.c - src/solaris/native/sun/awt/awt_xembed_server.h - test/java/util/ResourceBundle/Control/ExpirationTest.java - test/java/util/ResourceBundle/Control/ExpirationTest.sh Changeset: 134420afe9c2 Author: ngthomas Date: 2011-11-13 21:39 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/134420afe9c2 7109885: security baseline for 7u2 or above is not set correctly Reviewed-by: ccheung, igor, ohair ! make/common/shared/Sanity.gmk Changeset: 6f594239e9dc Author: ngthomas Date: 2011-11-15 23:33 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/6f594239e9dc 7112298: remove security baseline sanity check Reviewed-by: ccheung, igor, ohair ! make/common/shared/Sanity.gmk Changeset: fcc7cafa0027 Author: herrick Date: 2011-11-18 06:35 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/fcc7cafa0027 Merge - make/sun/rmi/rmi/mapfile-vers - src/share/classes/sun/security/pkcs/EncodingException.java - src/share/classes/sun/security/pkcs/PKCS10.java - src/share/classes/sun/security/pkcs/PKCS10Attribute.java - src/share/classes/sun/security/pkcs/PKCS10Attributes.java - src/share/classes/sun/security/util/BigInt.java - src/share/classes/sun/security/util/PathList.java - src/share/classes/sun/security/x509/CertAndKeyGen.java - src/share/native/sun/rmi/server/MarshalInputStream.c - test/java/net/DatagramSocket/ChangingAddress.java - test/sun/security/util/BigInt/BigIntEqualsHashCode.java Changeset: 526e99f06a59 Author: igor Date: 2011-12-06 16:31 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/526e99f06a59 Merge - test/java/io/FileDescriptor/FileChannelFDTest.java - test/java/io/etc/FileDescriptorSharing.java Changeset: 334bd51fb3f3 Author: igor Date: 2011-12-19 10:06 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/334bd51fb3f3 Merge - make/sun/motif12/reorder-i586 - make/sun/motif12/reorder-sparc - make/sun/motif12/reorder-sparcv9 - src/share/native/java/util/zip/zlib-1.2.3/ChangeLog - src/share/native/java/util/zip/zlib-1.2.3/README - src/share/native/java/util/zip/zlib-1.2.3/compress.c - src/share/native/java/util/zip/zlib-1.2.3/crc32.h - src/share/native/java/util/zip/zlib-1.2.3/deflate.c - src/share/native/java/util/zip/zlib-1.2.3/deflate.h - src/share/native/java/util/zip/zlib-1.2.3/gzio.c - src/share/native/java/util/zip/zlib-1.2.3/infback.c - src/share/native/java/util/zip/zlib-1.2.3/inffast.c - src/share/native/java/util/zip/zlib-1.2.3/inffast.h - src/share/native/java/util/zip/zlib-1.2.3/inffixed.h - src/share/native/java/util/zip/zlib-1.2.3/inflate.c - src/share/native/java/util/zip/zlib-1.2.3/inflate.h - src/share/native/java/util/zip/zlib-1.2.3/inftrees.c - src/share/native/java/util/zip/zlib-1.2.3/inftrees.h - src/share/native/java/util/zip/zlib-1.2.3/patches/ChangeLog_java - src/share/native/java/util/zip/zlib-1.2.3/patches/crc32.c.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/inflate.c.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/zconf.h.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/zlib.h.diff - src/share/native/java/util/zip/zlib-1.2.3/trees.c - src/share/native/java/util/zip/zlib-1.2.3/trees.h - src/share/native/java/util/zip/zlib-1.2.3/uncompr.c - src/share/native/java/util/zip/zlib-1.2.3/zadler32.c - src/share/native/java/util/zip/zlib-1.2.3/zconf.h - src/share/native/java/util/zip/zlib-1.2.3/zcrc32.c - src/share/native/java/util/zip/zlib-1.2.3/zlib.h - src/share/native/java/util/zip/zlib-1.2.3/zutil.c - src/share/native/java/util/zip/zlib-1.2.3/zutil.h - src/solaris/classes/sun/awt/motif/AWTLockAccess.java - src/solaris/classes/sun/awt/motif/MFontPeer.java - src/solaris/classes/sun/awt/motif/MToolkit.java - src/solaris/classes/sun/awt/motif/MToolkitThreadBlockedHandler.java - src/solaris/classes/sun/awt/motif/MWindowAttributes.java - src/solaris/classes/sun/awt/motif/X11FontMetrics.java - src/solaris/native/sun/awt/MouseInfo.c - src/solaris/native/sun/awt/XDrawingArea.c - src/solaris/native/sun/awt/XDrawingArea.h - src/solaris/native/sun/awt/XDrawingAreaP.h - src/solaris/native/sun/awt/awt_Cursor.h - src/solaris/native/sun/awt/awt_KeyboardFocusManager.h - src/solaris/native/sun/awt/awt_MToolkit.c - src/solaris/native/sun/awt/awt_MToolkit.h - src/solaris/native/sun/awt/awt_MenuItem.h - src/solaris/native/sun/awt/awt_PopupMenu.h - src/solaris/native/sun/awt/awt_TopLevel.h - src/solaris/native/sun/awt/awt_Window.h - src/solaris/native/sun/awt/awt_mgrsel.c - src/solaris/native/sun/awt/awt_mgrsel.h - src/solaris/native/sun/awt/awt_motif.h - src/solaris/native/sun/awt/awt_wm.c - src/solaris/native/sun/awt/awt_wm.h - src/solaris/native/sun/awt/awt_xembed.h - src/solaris/native/sun/awt/awt_xembed_server.c - src/solaris/native/sun/awt/awt_xembed_server.h - test/java/util/ResourceBundle/Control/ExpirationTest.java - test/java/util/ResourceBundle/Control/ExpirationTest.sh Changeset: c6fab5332075 Author: cl Date: 2011-12-22 19:00 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/c6fab5332075 Added tag jdk8-b18 for changeset 334bd51fb3f3 ! .hgtags Changeset: 7dbc53242c2a Author: art Date: 2011-12-07 17:45 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/7dbc53242c2a 7117008: Warnings cleanup day: reduce number of javac warnings in the sun.awt package Reviewed-by: anthony, denis, bagiras ! src/share/classes/sun/awt/AWTAutoShutdown.java ! src/share/classes/sun/awt/AppContext.java ! src/share/classes/sun/awt/CausedFocusEvent.java ! src/share/classes/sun/awt/DebugSettings.java ! src/share/classes/sun/awt/EmbeddedFrame.java ! src/share/classes/sun/awt/EventListenerAggregate.java - src/share/classes/sun/awt/FocusingTextField.java ! src/share/classes/sun/awt/HeadlessToolkit.java - src/share/classes/sun/awt/HorizBagLayout.java ! src/share/classes/sun/awt/KeyboardFocusManagerPeerImpl.java ! src/share/classes/sun/awt/ModalityEvent.java - src/share/classes/sun/awt/OrientableFlowLayout.java ! src/share/classes/sun/awt/PaintEventDispatcher.java ! src/share/classes/sun/awt/PeerEvent.java ! src/share/classes/sun/awt/SunDisplayChanger.java ! src/share/classes/sun/awt/SunGraphicsCallback.java ! src/share/classes/sun/awt/SunToolkit.java ! src/share/classes/sun/awt/UngrabEvent.java - src/share/classes/sun/awt/VariableGridLayout.java - src/share/classes/sun/awt/VerticalBagLayout.java Changeset: 18925904efc2 Author: alexsch Date: 2011-12-12 15:33 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/18925904efc2 7105890: closed/javax/swing/JScrollBar/4708809/bug4708809.java deadlocks on MacOS Reviewed-by: alexp + test/javax/swing/JScrollBar/4708809/bug4708809.java Changeset: 44b26d6a55a6 Author: alexsch Date: 2011-12-13 15:32 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/44b26d6a55a6 7112931: closed/javax/swing/JTabbedPane/6416920/bug6416920.java fails on MacOS Reviewed-by: alexp + test/javax/swing/JTabbedPane/6416920/bug6416920.java Changeset: 70233f5e909c Author: alexsch Date: 2011-12-13 17:30 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/70233f5e909c 7120869: javax/swing/JScrollBar/4708809/bug4708809.java fails on Windows Summary: The robot auto-delay is increased to fix the test failing on Windows. Reviewed-by: alexp ! test/javax/swing/JScrollBar/4708809/bug4708809.java Changeset: 032a91abc540 Author: alexsch Date: 2011-12-13 18:38 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/032a91abc540 7116950: Reduce number of warnings in swing Reviewed-by: art ! src/share/classes/com/sun/java/swing/Painter.java ! src/share/classes/java/beans/PropertyDescriptor.java ! src/share/classes/javax/swing/AbstractButton.java ! src/share/classes/javax/swing/ActionMap.java ! src/share/classes/javax/swing/ActionPropertyChangeListener.java ! src/share/classes/javax/swing/AncestorNotifier.java ! src/share/classes/javax/swing/ArrayTable.java ! src/share/classes/javax/swing/Box.java ! src/share/classes/javax/swing/BoxLayout.java ! src/share/classes/javax/swing/ButtonGroup.java ! src/share/classes/javax/swing/ComponentInputMap.java ! src/share/classes/javax/swing/InputMap.java ! src/share/classes/javax/swing/JButton.java ! src/share/classes/javax/swing/JComponent.java ! src/share/classes/javax/swing/JLabel.java ! src/share/classes/javax/swing/JLayeredPane.java ! src/share/classes/javax/swing/JMenu.java ! src/share/classes/javax/swing/JMenuBar.java ! src/share/classes/javax/swing/JMenuItem.java ! src/share/classes/javax/swing/JPopupMenu.java ! src/share/classes/javax/swing/JRootPane.java ! src/share/classes/javax/swing/JSeparator.java ! src/share/classes/javax/swing/JToolTip.java ! src/share/classes/javax/swing/JTree.java ! src/share/classes/javax/swing/JWindow.java ! src/share/classes/javax/swing/MenuSelectionManager.java ! src/share/classes/javax/swing/Popup.java ! src/share/classes/javax/swing/RepaintManager.java ! src/share/classes/javax/swing/Timer.java ! src/share/classes/javax/swing/border/AbstractBorder.java ! src/share/classes/javax/swing/border/CompoundBorder.java ! src/share/classes/javax/swing/border/EmptyBorder.java ! src/share/classes/javax/swing/border/MatteBorder.java ! src/share/classes/javax/swing/border/TitledBorder.java ! src/share/classes/javax/swing/event/AncestorEvent.java ! src/share/classes/javax/swing/event/ChangeEvent.java ! src/share/classes/javax/swing/event/EventListenerList.java ! src/share/classes/javax/swing/event/ListDataEvent.java ! src/share/classes/javax/swing/event/MenuDragMouseEvent.java ! src/share/classes/javax/swing/event/MenuEvent.java ! src/share/classes/javax/swing/event/MenuKeyEvent.java ! src/share/classes/javax/swing/event/PopupMenuEvent.java ! src/share/classes/javax/swing/plaf/ComponentUI.java ! src/share/classes/javax/swing/text/BadLocationException.java ! src/share/classes/javax/swing/tree/DefaultTreeSelectionModel.java Changeset: 282b2ce90afe Author: lana Date: 2011-12-16 12:12 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/282b2ce90afe Merge ! src/share/classes/java/beans/PropertyDescriptor.java - src/share/native/java/util/zip/zlib-1.2.3/ChangeLog - src/share/native/java/util/zip/zlib-1.2.3/README - src/share/native/java/util/zip/zlib-1.2.3/compress.c - src/share/native/java/util/zip/zlib-1.2.3/crc32.h - src/share/native/java/util/zip/zlib-1.2.3/deflate.c - src/share/native/java/util/zip/zlib-1.2.3/deflate.h - src/share/native/java/util/zip/zlib-1.2.3/gzio.c - src/share/native/java/util/zip/zlib-1.2.3/infback.c - src/share/native/java/util/zip/zlib-1.2.3/inffast.c - src/share/native/java/util/zip/zlib-1.2.3/inffast.h - src/share/native/java/util/zip/zlib-1.2.3/inffixed.h - src/share/native/java/util/zip/zlib-1.2.3/inflate.c - src/share/native/java/util/zip/zlib-1.2.3/inflate.h - src/share/native/java/util/zip/zlib-1.2.3/inftrees.c - src/share/native/java/util/zip/zlib-1.2.3/inftrees.h - src/share/native/java/util/zip/zlib-1.2.3/patches/ChangeLog_java - src/share/native/java/util/zip/zlib-1.2.3/patches/crc32.c.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/inflate.c.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/zconf.h.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/zlib.h.diff - src/share/native/java/util/zip/zlib-1.2.3/trees.c - src/share/native/java/util/zip/zlib-1.2.3/trees.h - src/share/native/java/util/zip/zlib-1.2.3/uncompr.c - src/share/native/java/util/zip/zlib-1.2.3/zadler32.c - src/share/native/java/util/zip/zlib-1.2.3/zconf.h - src/share/native/java/util/zip/zlib-1.2.3/zcrc32.c - src/share/native/java/util/zip/zlib-1.2.3/zlib.h - src/share/native/java/util/zip/zlib-1.2.3/zutil.c - src/share/native/java/util/zip/zlib-1.2.3/zutil.h - test/java/util/ResourceBundle/Control/ExpirationTest.java - test/java/util/ResourceBundle/Control/ExpirationTest.sh Changeset: 75bd7295c706 Author: bagiras Date: 2011-12-19 15:21 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/75bd7295c706 7117334: Warnings cleanup day: reduce number of javac warnings in the java.awt package Reviewed-by: art, denis, alexsch ! src/share/classes/java/awt/AWTEvent.java ! src/share/classes/java/awt/AWTEventMulticaster.java ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Font.java ! src/share/classes/java/awt/Toolkit.java ! src/share/classes/java/awt/image/ColorModel.java Changeset: d15f38f08ce9 Author: denis Date: 2011-12-19 16:44 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/d15f38f08ce9 7117011: Reduce number of warnings in sun/awt/windows and sun/awt/datatransfer Reviewed-by: art ! src/share/classes/sun/awt/datatransfer/DataTransferer.java ! src/share/classes/sun/awt/dnd/SunDragSourceContextPeer.java ! src/solaris/classes/sun/awt/X11/XClipboard.java ! src/windows/classes/sun/awt/windows/TranslucentWindowPainter.java ! src/windows/classes/sun/awt/windows/WBufferStrategy.java ! src/windows/classes/sun/awt/windows/WChoicePeer.java ! src/windows/classes/sun/awt/windows/WClipboard.java ! src/windows/classes/sun/awt/windows/WComponentPeer.java ! src/windows/classes/sun/awt/windows/WDataTransferer.java ! src/windows/classes/sun/awt/windows/WDesktopProperties.java ! src/windows/classes/sun/awt/windows/WDialogPeer.java ! src/windows/classes/sun/awt/windows/WEmbeddedFrame.java ! src/windows/classes/sun/awt/windows/WFileDialogPeer.java ! src/windows/classes/sun/awt/windows/WFramePeer.java ! src/windows/classes/sun/awt/windows/WInputMethod.java ! src/windows/classes/sun/awt/windows/WMenuItemPeer.java ! src/windows/classes/sun/awt/windows/WPageDialog.java ! src/windows/classes/sun/awt/windows/WPageDialogPeer.java ! src/windows/classes/sun/awt/windows/WPrintDialog.java ! src/windows/classes/sun/awt/windows/WPrintDialogPeer.java ! src/windows/classes/sun/awt/windows/WToolkit.java ! src/windows/classes/sun/awt/windows/WWindowPeer.java Changeset: cded2429cdbf Author: anthony Date: 2011-12-20 12:48 +0300 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/cded2429cdbf 7122796: SunToolkit constructor should create the EventQueue for the Main AppContext Summary: Always create an EQ for the main AppContext in SunToolkit constructor Reviewed-by: art ! src/share/classes/sun/awt/AppContext.java ! src/share/classes/sun/awt/SunToolkit.java + test/java/awt/EventQueue/MainAppContext/MainAppContext.java Changeset: 94d7051cca13 Author: lana Date: 2011-12-20 15:26 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/94d7051cca13 Merge - src/share/classes/sun/awt/FocusingTextField.java - src/share/classes/sun/awt/HorizBagLayout.java - src/share/classes/sun/awt/OrientableFlowLayout.java - src/share/classes/sun/awt/VariableGridLayout.java - src/share/classes/sun/awt/VerticalBagLayout.java Changeset: 4f0f9f9c4892 Author: smarks Date: 2011-12-07 12:12 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/4f0f9f9c4892 7117249: fix warnings in java.util.jar, .logging, .prefs, .zip Reviewed-by: alanb, dholmes, forax, sherman, smarks Contributed-by: Prasannaa , Martijn Verburg , Goerge_Albrecht , Graham Allan , Michael Barker ! src/share/classes/java/util/jar/JarFile.java ! src/share/classes/java/util/jar/Manifest.java ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/java/util/prefs/Preferences.java ! src/share/classes/java/util/prefs/XmlSupport.java ! src/share/classes/java/util/zip/ZipEntry.java Changeset: f8897baf40ea Author: omajid Date: 2011-12-08 13:48 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/f8897baf40ea 7117612: Miscellaneous warnings in java.lang Reviewed-by: smarks, dholmes, alanb, darcy ! src/share/classes/java/lang/Boolean.java ! src/share/classes/java/lang/Byte.java ! src/share/classes/java/lang/Character.java ! src/share/classes/java/lang/CharacterName.java ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/ClassLoader.java ! src/share/classes/java/lang/ConditionalSpecialCasing.java ! src/share/classes/java/lang/Double.java ! src/share/classes/java/lang/EnumConstantNotPresentException.java ! src/share/classes/java/lang/Float.java ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Long.java ! src/share/classes/java/lang/Short.java ! src/share/classes/java/lang/System.java ! src/share/classes/java/lang/ThreadLocal.java ! src/share/classes/java/lang/Void.java ! src/solaris/classes/java/lang/ProcessEnvironment.java ! src/windows/classes/java/lang/ProcessEnvironment.java Changeset: 9bb7c3b97384 Author: smarks Date: 2011-12-08 14:57 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/9bb7c3b97384 7118546: fix warnings in javax.xml.crypto, javax.script Reviewed-by: mullan ! src/share/classes/javax/script/ScriptException.java ! src/share/classes/javax/xml/crypto/NodeSetData.java ! src/share/classes/javax/xml/crypto/dom/DOMCryptoContext.java ! src/share/classes/javax/xml/crypto/dsig/Manifest.java ! src/share/classes/javax/xml/crypto/dsig/Reference.java ! src/share/classes/javax/xml/crypto/dsig/SignatureProperties.java ! src/share/classes/javax/xml/crypto/dsig/SignatureProperty.java ! src/share/classes/javax/xml/crypto/dsig/SignedInfo.java ! src/share/classes/javax/xml/crypto/dsig/TransformService.java ! src/share/classes/javax/xml/crypto/dsig/XMLObject.java ! src/share/classes/javax/xml/crypto/dsig/XMLSignature.java ! src/share/classes/javax/xml/crypto/dsig/XMLSignatureFactory.java ! src/share/classes/javax/xml/crypto/dsig/keyinfo/KeyInfo.java ! src/share/classes/javax/xml/crypto/dsig/keyinfo/KeyInfoFactory.java ! src/share/classes/javax/xml/crypto/dsig/keyinfo/PGPData.java ! src/share/classes/javax/xml/crypto/dsig/keyinfo/RetrievalMethod.java ! src/share/classes/javax/xml/crypto/dsig/keyinfo/X509Data.java ! src/share/classes/javax/xml/crypto/dsig/spec/ExcC14NParameterSpec.java ! src/share/classes/javax/xml/crypto/dsig/spec/XPathFilter2ParameterSpec.java ! src/share/classes/javax/xml/crypto/dsig/spec/XPathFilterParameterSpec.java ! src/share/classes/javax/xml/crypto/dsig/spec/XPathType.java Changeset: 77d41c0e4ffc Author: jjh Date: 2011-12-09 12:56 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/77d41c0e4ffc 7117053: Fix build warnings in com/sun/tools/jdi/* Summary: Warnings fixed. Also reviewed by serguei.spitsyn at oracle.com, who is not yet an openjdk reviewer Reviewed-by: ksrini ! make/tools/src/build/tools/jdwpgen/ArrayRegionTypeNode.java ! make/tools/src/build/tools/jdwpgen/OutNode.java ! src/share/classes/com/sun/jdi/AbsentInformationException.java ! src/share/classes/com/sun/jdi/ClassNotLoadedException.java ! src/share/classes/com/sun/jdi/ClassNotPreparedException.java ! src/share/classes/com/sun/jdi/IncompatibleThreadStateException.java ! src/share/classes/com/sun/jdi/InconsistentDebugInfoException.java ! src/share/classes/com/sun/jdi/InternalException.java ! src/share/classes/com/sun/jdi/InvalidCodeIndexException.java ! src/share/classes/com/sun/jdi/InvalidLineNumberException.java ! src/share/classes/com/sun/jdi/InvalidStackFrameException.java ! src/share/classes/com/sun/jdi/InvalidTypeException.java ! src/share/classes/com/sun/jdi/InvocationException.java ! src/share/classes/com/sun/jdi/JDIPermission.java ! src/share/classes/com/sun/jdi/NativeMethodException.java ! src/share/classes/com/sun/jdi/ObjectCollectedException.java ! src/share/classes/com/sun/jdi/VMCannotBeModifiedException.java ! src/share/classes/com/sun/jdi/VMDisconnectedException.java ! src/share/classes/com/sun/jdi/VMMismatchException.java ! src/share/classes/com/sun/jdi/VMOutOfMemoryException.java ! src/share/classes/com/sun/jdi/connect/IllegalConnectorArgumentsException.java ! src/share/classes/com/sun/jdi/connect/TransportTimeoutException.java ! src/share/classes/com/sun/jdi/connect/VMStartException.java ! src/share/classes/com/sun/jdi/connect/spi/ClosedConnectionException.java ! src/share/classes/com/sun/jdi/request/DuplicateRequestException.java ! src/share/classes/com/sun/jdi/request/InvalidRequestStateException.java ! src/share/classes/com/sun/tools/jdi/ArrayReferenceImpl.java ! src/share/classes/com/sun/tools/jdi/ArrayTypeImpl.java ! src/share/classes/com/sun/tools/jdi/BooleanValueImpl.java ! src/share/classes/com/sun/tools/jdi/CharValueImpl.java ! src/share/classes/com/sun/tools/jdi/ClassLoaderReferenceImpl.java ! src/share/classes/com/sun/tools/jdi/ClassTypeImpl.java ! src/share/classes/com/sun/tools/jdi/ConcreteMethodImpl.java ! src/share/classes/com/sun/tools/jdi/ConnectorImpl.java ! src/share/classes/com/sun/tools/jdi/DoubleValueImpl.java ! src/share/classes/com/sun/tools/jdi/EventRequestManagerImpl.java ! src/share/classes/com/sun/tools/jdi/EventSetImpl.java ! src/share/classes/com/sun/tools/jdi/FloatValueImpl.java ! src/share/classes/com/sun/tools/jdi/GenericAttachingConnector.java ! src/share/classes/com/sun/tools/jdi/IntegerValueImpl.java ! src/share/classes/com/sun/tools/jdi/InterfaceTypeImpl.java ! src/share/classes/com/sun/tools/jdi/InternalEventHandler.java ! src/share/classes/com/sun/tools/jdi/JDWPException.java - src/share/classes/com/sun/tools/jdi/LinkedHashMap.java ! src/share/classes/com/sun/tools/jdi/LongValueImpl.java ! src/share/classes/com/sun/tools/jdi/MethodImpl.java ! src/share/classes/com/sun/tools/jdi/MirrorImpl.java ! src/share/classes/com/sun/tools/jdi/ObjectReferenceImpl.java ! src/share/classes/com/sun/tools/jdi/ProcessAttachingConnector.java ! src/share/classes/com/sun/tools/jdi/RawCommandLineLauncher.java ! src/share/classes/com/sun/tools/jdi/ReferenceTypeImpl.java ! src/share/classes/com/sun/tools/jdi/ShortValueImpl.java ! src/share/classes/com/sun/tools/jdi/SunCommandLineLauncher.java ! src/share/classes/com/sun/tools/jdi/TargetVM.java ! src/share/classes/com/sun/tools/jdi/ThreadAction.java ! src/share/classes/com/sun/tools/jdi/ThreadGroupReferenceImpl.java ! src/share/classes/com/sun/tools/jdi/ThreadReferenceImpl.java ! src/share/classes/com/sun/tools/jdi/VMAction.java ! src/share/classes/com/sun/tools/jdi/VMState.java ! src/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java Changeset: c508f38245f8 Author: ngmr Date: 2011-12-12 11:41 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/c508f38245f8 7118907: InetAddress.isReachable() should return false if sendto fails with EHOSTUNREACH Reviewed-by: alanb, chegar Contributed-by: Charles Lee ! src/solaris/native/java/net/Inet4AddressImpl.c ! src/solaris/native/java/net/Inet6AddressImpl.c Changeset: 3216717f96f5 Author: dl Date: 2011-12-12 10:45 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/3216717f96f5 7118066: Warnings in java.util.concurrent package Reviewed-by: chegar, dholmes ! src/share/classes/java/util/concurrent/ArrayBlockingQueue.java ! src/share/classes/java/util/concurrent/ConcurrentHashMap.java ! src/share/classes/java/util/concurrent/ConcurrentLinkedDeque.java ! src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java ! src/share/classes/java/util/concurrent/ConcurrentSkipListMap.java ! src/share/classes/java/util/concurrent/ConcurrentSkipListSet.java ! src/share/classes/java/util/concurrent/CopyOnWriteArrayList.java ! src/share/classes/java/util/concurrent/DelayQueue.java ! src/share/classes/java/util/concurrent/Exchanger.java ! src/share/classes/java/util/concurrent/ForkJoinPool.java ! src/share/classes/java/util/concurrent/ForkJoinTask.java ! src/share/classes/java/util/concurrent/ForkJoinWorkerThread.java ! src/share/classes/java/util/concurrent/LinkedTransferQueue.java ! src/share/classes/java/util/concurrent/Phaser.java ! src/share/classes/java/util/concurrent/PriorityBlockingQueue.java ! src/share/classes/java/util/concurrent/ScheduledThreadPoolExecutor.java ! src/share/classes/java/util/concurrent/SynchronousQueue.java ! test/java/util/Collections/EmptyIterator.java Changeset: d4f9d7e86a92 Author: chegar Date: 2011-12-12 03:54 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/d4f9d7e86a92 Merge Changeset: 9c0a6185188f Author: ohair Date: 2011-12-12 08:17 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/9c0a6185188f 7119829: Adjust default jprt testing configuration Reviewed-by: alanb ! make/jprt.properties ! test/Makefile Changeset: c647ebb3c4f7 Author: naoto Date: 2011-12-13 15:41 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/c647ebb3c4f7 4808233: "Locale" not thread-safe Reviewed-by: okutsu ! src/share/classes/java/util/Locale.java Changeset: e446c7d24d6c Author: lana Date: 2011-12-15 19:52 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/e446c7d24d6c Merge - make/sun/motif12/reorder-i586 - make/sun/motif12/reorder-sparc - make/sun/motif12/reorder-sparcv9 - src/solaris/classes/sun/awt/motif/AWTLockAccess.java - src/solaris/classes/sun/awt/motif/MFontPeer.java - src/solaris/classes/sun/awt/motif/MToolkit.java - src/solaris/classes/sun/awt/motif/MToolkitThreadBlockedHandler.java - src/solaris/classes/sun/awt/motif/MWindowAttributes.java - src/solaris/classes/sun/awt/motif/X11FontMetrics.java - src/solaris/native/sun/awt/MouseInfo.c - src/solaris/native/sun/awt/XDrawingArea.c - src/solaris/native/sun/awt/XDrawingArea.h - src/solaris/native/sun/awt/XDrawingAreaP.h - src/solaris/native/sun/awt/awt_Cursor.h - src/solaris/native/sun/awt/awt_KeyboardFocusManager.h - src/solaris/native/sun/awt/awt_MToolkit.c - src/solaris/native/sun/awt/awt_MToolkit.h - src/solaris/native/sun/awt/awt_MenuItem.h - src/solaris/native/sun/awt/awt_PopupMenu.h - src/solaris/native/sun/awt/awt_TopLevel.h - src/solaris/native/sun/awt/awt_Window.h - src/solaris/native/sun/awt/awt_mgrsel.c - src/solaris/native/sun/awt/awt_mgrsel.h - src/solaris/native/sun/awt/awt_motif.h - src/solaris/native/sun/awt/awt_wm.c - src/solaris/native/sun/awt/awt_wm.h - src/solaris/native/sun/awt/awt_xembed.h - src/solaris/native/sun/awt/awt_xembed_server.c - src/solaris/native/sun/awt/awt_xembed_server.h Changeset: 33ac7a057b9c Author: chegar Date: 2011-12-16 16:09 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/33ac7a057b9c 7095980: Ensure HttpURLConnection (and supporting APIs) don't expose HttpOnly cookies Reviewed-by: michaelm ! src/share/classes/java/net/HttpCookie.java + src/share/classes/sun/misc/JavaNetHttpCookieAccess.java ! src/share/classes/sun/misc/SharedSecrets.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java + test/sun/net/www/protocol/http/HttpOnly.java Changeset: abbca81a98a7 Author: smarks Date: 2011-12-17 08:21 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/abbca81a98a7 7122235: stop the build if javac fails Reviewed-by: chegar, dholmes, mcimadamore, ohair ! make/common/Rules.gmk Changeset: 528eb0d43e3a Author: alanb Date: 2011-12-17 20:07 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/528eb0d43e3a 7087549: (fs) Files.newInputStream throws UOE for custom provider options Reviewed-by: alanb Contributed-by: brandon.passanisi at oracle.com ! src/share/classes/java/nio/file/spi/FileSystemProvider.java + test/java/nio/file/Files/CustomOptions.java Changeset: 5b27b978ed42 Author: sherman Date: 2011-12-19 14:14 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/5b27b978ed42 6990617: Regular expression doesn't match if unicode character next to a digit. Summary: updated RemoveQEQuotation() to deal with this case correctly Reviewed-by: sherman Contributed-by: stephen.flores at oracle.com ! src/share/classes/java/util/regex/Pattern.java ! test/java/util/regex/RegExTest.java Changeset: 570f3d893596 Author: lana Date: 2011-12-20 15:27 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/570f3d893596 Merge - src/share/classes/com/sun/tools/jdi/LinkedHashMap.java Changeset: 6f19ff39cff4 Author: lana Date: 2011-12-23 16:38 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/6f19ff39cff4 Merge - src/share/classes/com/sun/tools/jdi/LinkedHashMap.java - src/share/classes/sun/awt/FocusingTextField.java - src/share/classes/sun/awt/HorizBagLayout.java - src/share/classes/sun/awt/OrientableFlowLayout.java - src/share/classes/sun/awt/VariableGridLayout.java - src/share/classes/sun/awt/VerticalBagLayout.java Changeset: 60dd940eb58e Author: yhuang Date: 2011-12-12 18:21 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/60dd940eb58e 7003124: In Bulgarian Locale DateFormat is wrong Reviewed-by: naoto, peytoia ! src/share/classes/sun/text/resources/FormatData_bg.java ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: cd03cd0e0965 Author: mfang Date: 2011-12-15 11:29 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/cd03cd0e0965 Merge Changeset: 3778f8577305 Author: katleman Date: 2011-12-28 15:14 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/3778f8577305 Merge Changeset: 80350ee39fa8 Author: katleman Date: 2011-12-29 15:14 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/80350ee39fa8 Added tag jdk8-b19 for changeset 3778f8577305 ! .hgtags Changeset: 172d70c50c65 Author: cgruszka Date: 2011-09-15 13:59 -0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/172d70c50c65 7066713: Separate demos from the bundles on Solaris and Linux Summary: add new license files to demos and samples, new directory for bundling Reviewed-by: katleman, ohair, billyh ! make/common/Release.gmk ! make/common/shared/Defs-control.gmk Changeset: eaf967fd25c5 Author: cgruszka Date: 2011-10-18 14:21 -0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/eaf967fd25c5 7099017: jdk7u2-dev does not build Summary: changes to skip demo/DEMOS_LICENSE and sample/SAMPLES_LICENSE when building OPENJDK Reviewed-by: ohair, billyh ! make/common/Release.gmk Changeset: 39b7f01203c9 Author: cgruszka Date: 2011-11-17 16:57 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/39b7f01203c9 Merge Changeset: b64e7263b4fd Author: cgruszka Date: 2011-11-18 01:03 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/b64e7263b4fd Merge Changeset: e98869ff9f1e Author: cgruszka Date: 2011-12-05 12:41 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/e98869ff9f1e Merge - test/java/io/FileDescriptor/FileChannelFDTest.java - test/java/io/etc/FileDescriptorSharing.java Changeset: ffa36a6a46f5 Author: cgruszka Date: 2011-12-16 15:01 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/ffa36a6a46f5 Merge - make/sun/motif12/reorder-i586 - make/sun/motif12/reorder-sparc - make/sun/motif12/reorder-sparcv9 - src/share/native/java/util/zip/zlib-1.2.3/ChangeLog - src/share/native/java/util/zip/zlib-1.2.3/README - src/share/native/java/util/zip/zlib-1.2.3/compress.c - src/share/native/java/util/zip/zlib-1.2.3/crc32.h - src/share/native/java/util/zip/zlib-1.2.3/deflate.c - src/share/native/java/util/zip/zlib-1.2.3/deflate.h - src/share/native/java/util/zip/zlib-1.2.3/gzio.c - src/share/native/java/util/zip/zlib-1.2.3/infback.c - src/share/native/java/util/zip/zlib-1.2.3/inffast.c - src/share/native/java/util/zip/zlib-1.2.3/inffast.h - src/share/native/java/util/zip/zlib-1.2.3/inffixed.h - src/share/native/java/util/zip/zlib-1.2.3/inflate.c - src/share/native/java/util/zip/zlib-1.2.3/inflate.h - src/share/native/java/util/zip/zlib-1.2.3/inftrees.c - src/share/native/java/util/zip/zlib-1.2.3/inftrees.h - src/share/native/java/util/zip/zlib-1.2.3/patches/ChangeLog_java - src/share/native/java/util/zip/zlib-1.2.3/patches/crc32.c.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/inflate.c.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/zconf.h.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/zlib.h.diff - src/share/native/java/util/zip/zlib-1.2.3/trees.c - src/share/native/java/util/zip/zlib-1.2.3/trees.h - src/share/native/java/util/zip/zlib-1.2.3/uncompr.c - src/share/native/java/util/zip/zlib-1.2.3/zadler32.c - src/share/native/java/util/zip/zlib-1.2.3/zconf.h - src/share/native/java/util/zip/zlib-1.2.3/zcrc32.c - src/share/native/java/util/zip/zlib-1.2.3/zlib.h - src/share/native/java/util/zip/zlib-1.2.3/zutil.c - src/share/native/java/util/zip/zlib-1.2.3/zutil.h - src/solaris/classes/sun/awt/motif/AWTLockAccess.java - src/solaris/classes/sun/awt/motif/MFontPeer.java - src/solaris/classes/sun/awt/motif/MToolkit.java - src/solaris/classes/sun/awt/motif/MToolkitThreadBlockedHandler.java - src/solaris/classes/sun/awt/motif/MWindowAttributes.java - src/solaris/classes/sun/awt/motif/X11FontMetrics.java - src/solaris/native/sun/awt/MouseInfo.c - src/solaris/native/sun/awt/XDrawingArea.c - src/solaris/native/sun/awt/XDrawingArea.h - src/solaris/native/sun/awt/XDrawingAreaP.h - src/solaris/native/sun/awt/awt_Cursor.h - src/solaris/native/sun/awt/awt_KeyboardFocusManager.h - src/solaris/native/sun/awt/awt_MToolkit.c - src/solaris/native/sun/awt/awt_MToolkit.h - src/solaris/native/sun/awt/awt_MenuItem.h - src/solaris/native/sun/awt/awt_PopupMenu.h - src/solaris/native/sun/awt/awt_TopLevel.h - src/solaris/native/sun/awt/awt_Window.h - src/solaris/native/sun/awt/awt_mgrsel.c - src/solaris/native/sun/awt/awt_mgrsel.h - src/solaris/native/sun/awt/awt_motif.h - src/solaris/native/sun/awt/awt_wm.c - src/solaris/native/sun/awt/awt_wm.h - src/solaris/native/sun/awt/awt_xembed.h - src/solaris/native/sun/awt/awt_xembed_server.c - src/solaris/native/sun/awt/awt_xembed_server.h - test/java/util/ResourceBundle/Control/ExpirationTest.java - test/java/util/ResourceBundle/Control/ExpirationTest.sh Changeset: 5fe1525e6e2c Author: cgruszka Date: 2011-12-23 10:43 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/5fe1525e6e2c Merge Changeset: 39e938cd1b82 Author: cgruszka Date: 2012-01-03 14:34 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/39e938cd1b82 Merge Changeset: fc050750f8a0 Author: katleman Date: 2012-01-05 08:42 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/fc050750f8a0 Added tag jdk8-b20 for changeset 39e938cd1b82 ! .hgtags Changeset: 1c4fffa22930 Author: okutsu Date: 2011-12-21 17:09 +0900 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/1c4fffa22930 7122054: (tz) Windows-only: tzmappings needs update for KB2633952 Reviewed-by: peytoia ! src/windows/lib/tzmappings Changeset: b1814b3ea6d3 Author: michaelm Date: 2011-12-21 10:06 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/b1814b3ea6d3 7078386: NetworkInterface.getNetworkInterfaces() may return corrupted results on linux Reviewed-by: michaelm, alanb, chegar Contributed-by: brandon.passanisi at oracle.com ! src/solaris/native/java/net/NetworkInterface.c Changeset: a9dfdc523c2c Author: valeriep Date: 2011-12-21 14:08 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/a9dfdc523c2c 6839886: Array overrun in pkcs11 Summary: Fix the wrong value when dealing w/ month and day. Reviewed-by: mullan ! src/share/native/sun/security/pkcs11/wrapper/p11_convert.c Changeset: 11698dedbe79 Author: weijun Date: 2011-12-22 15:35 +0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/11698dedbe79 7122169: TcpTimeout fail for various reasons Reviewed-by: alanb ! test/sun/security/krb5/auto/TcpTimeout.java Changeset: 559e07ed1f56 Author: alanb Date: 2011-12-22 10:52 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/559e07ed1f56 7076310: (file) AclEntry.Builder setFlags throws IllegalArgumentException if set argument is empty Reviewed-by: alanb Contributed-by: stephen.flores at oracle.com ! src/share/classes/java/nio/file/attribute/AclEntry.java + test/java/nio/file/attribute/AclEntry/EmptySet.java Changeset: 3c1ab134db71 Author: dcubed Date: 2011-12-22 18:35 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/3c1ab134db71 7121600: Instrumentation.redefineClasses() leaks class bytes Summary: Call JNI ReleaseByteArrayElements() on memory returned by JNI GetByteArrayElements(). Also push test for 7122253. Reviewed-by: acorn, poonam ! src/share/instrument/JPLISAgent.c + test/java/lang/instrument/BigClass.java + test/java/lang/instrument/MakeJAR4.sh + test/java/lang/instrument/RedefineBigClass.sh + test/java/lang/instrument/RedefineBigClassAgent.java + test/java/lang/instrument/RedefineBigClassApp.java + test/java/lang/instrument/RetransformBigClass.sh + test/java/lang/instrument/RetransformBigClassAgent.java + test/java/lang/instrument/RetransformBigClassApp.java Changeset: 437255d15e76 Author: lana Date: 2011-12-28 10:51 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/437255d15e76 Merge - src/share/classes/sun/awt/FocusingTextField.java - src/share/classes/sun/awt/HorizBagLayout.java - src/share/classes/sun/awt/OrientableFlowLayout.java - src/share/classes/sun/awt/VariableGridLayout.java - src/share/classes/sun/awt/VerticalBagLayout.java Changeset: 3a7ea63302f8 Author: smarks Date: 2011-12-29 16:39 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/3a7ea63302f8 7122061: add -Xlint:all -Werror to warning-free build steps Reviewed-by: chegar, alanb, dholmes, ohair ! make/com/sun/demo/jvmti/hprof/Makefile ! make/com/sun/java/browser/net/Makefile ! make/com/sun/tools/Makefile ! make/com/sun/tools/attach/Makefile ! make/com/sun/tracing/Makefile ! make/com/sun/tracing/dtrace/Makefile ! make/java/instrument/Makefile ! make/java/rmi/Makefile ! make/java/text/base/Makefile ! make/java/text/bidi/Makefile ! make/java/util/Makefile ! make/javax/accessibility/Makefile ! make/javax/others/Makefile ! make/javax/security/Makefile ! make/jpda/tty/Makefile ! make/sun/launcher/Makefile ! make/sun/serialver/Makefile ! make/sun/text/Makefile ! make/sun/util/Makefile Changeset: 5aeefe0e5d8c Author: chegar Date: 2012-01-01 09:24 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/5aeefe0e5d8c 7125055: ContentHandler.getContent API changed in error Reviewed-by: alanb ! src/share/classes/java/net/ContentHandler.java ! src/share/classes/sun/net/www/content/image/gif.java ! src/share/classes/sun/net/www/content/image/jpeg.java ! src/share/classes/sun/net/www/content/image/png.java ! src/share/classes/sun/net/www/content/image/x_xbitmap.java ! src/share/classes/sun/net/www/content/image/x_xpixmap.java Changeset: 8952a5f494f9 Author: ksrini Date: 2012-01-03 08:27 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/8952a5f494f9 7123582: (launcher) display the -version and -XshowSettings Reviewed-by: alanb ! src/share/bin/java.c ! test/tools/launcher/Settings.java Changeset: 5e34726cb4bb Author: ksrini Date: 2012-01-03 08:33 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/5e34726cb4bb 7124443: (launcher) test DefaultsLocaleTest fails with Windows shells. Reviewed-by: darcy ! test/tools/launcher/DefaultLocaleTest.java - test/tools/launcher/DefaultLocaleTest.sh + test/tools/launcher/DefaultLocaleTestRun.java ! test/tools/launcher/TestHelper.java Changeset: 0194fe5ca404 Author: fparain Date: 2012-01-04 03:49 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/0194fe5ca404 7104647: Adding a diagnostic command framework Reviewed-by: mchung, dholmes ! make/common/Release.gmk ! make/java/management/mapfile-vers ! make/launchers/Makefile ! make/sun/tools/Makefile + src/linux/doc/man/jcmd.1 + src/share/classes/com/sun/management/DiagnosticCommandArgumentInfo.java + src/share/classes/com/sun/management/DiagnosticCommandInfo.java ! src/share/classes/com/sun/management/HotSpotDiagnosticMXBean.java ! src/share/classes/sun/management/HotSpotDiagnostic.java ! src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java + src/share/classes/sun/tools/jcmd/Arguments.java + src/share/classes/sun/tools/jcmd/JCmd.java ! src/share/javavm/export/jmm.h ! src/share/native/sun/management/HotSpotDiagnostic.c + src/solaris/doc/sun/man/man1/jcmd.1 + test/com/sun/management/HotSpotDiagnosticMXBean/ExecuteDiagnosticCommand.java + test/com/sun/management/HotSpotDiagnosticMXBean/GetDiagnosticCommandInfo.java + test/com/sun/management/HotSpotDiagnosticMXBean/GetDiagnosticCommands.java ! test/sun/tools/common/CommonSetup.sh + test/sun/tools/jcmd/dcmd-script.txt + test/sun/tools/jcmd/help_help.out + test/sun/tools/jcmd/jcmd-Defaults.sh + test/sun/tools/jcmd/jcmd-f.sh + test/sun/tools/jcmd/jcmd-help-help.sh + test/sun/tools/jcmd/jcmd-help.sh + test/sun/tools/jcmd/jcmd-pid.sh + test/sun/tools/jcmd/jcmd_Output1.awk + test/sun/tools/jcmd/jcmd_pid_Output1.awk + test/sun/tools/jcmd/jcmd_pid_Output2.awk + test/sun/tools/jcmd/usage.out Changeset: 38a318502e19 Author: lana Date: 2012-01-04 10:57 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/38a318502e19 Merge ! make/common/Release.gmk - test/tools/launcher/DefaultLocaleTest.sh Changeset: 93ab1df09d11 Author: lana Date: 2012-01-09 19:12 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/93ab1df09d11 Merge - test/tools/launcher/DefaultLocaleTest.sh Changeset: ddb97d4fa83d Author: ohair Date: 2012-01-04 17:42 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/ddb97d4fa83d 7127104: Build issue with prtconf and zones, also using := to avoid extra execs Reviewed-by: katleman ! make/common/shared/Platform.gmk Changeset: 7c8c16f2c05e Author: ohair Date: 2012-01-09 09:18 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/7c8c16f2c05e 7128320: Fix freetype sanity check to make it more generic Reviewed-by: luchsh, katleman Contributed-by: Jonathan Lu ! make/common/Defs-linux.gmk ! make/common/Defs-solaris.gmk ! make/common/Defs-windows.gmk ! make/common/Demo.gmk ! make/tools/freetypecheck/Makefile Changeset: 664fa4fb0ee4 Author: katleman Date: 2012-01-11 16:13 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/664fa4fb0ee4 Merge Changeset: dda27c73d8db Author: katleman Date: 2012-01-13 10:05 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/dda27c73d8db Added tag jdk8-b21 for changeset 664fa4fb0ee4 ! .hgtags Changeset: 76bfd08d8cc5 Author: katleman Date: 2012-01-20 13:08 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/76bfd08d8cc5 Added tag jdk8-b22 for changeset dda27c73d8db ! .hgtags Changeset: 44bd765c22f4 Author: prr Date: 2012-01-13 13:11 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/44bd765c22f4 7127827: JRE8: javaws fails to launch on oracle linux due to XRender Reviewed-by: bae, jgodinez ! src/solaris/classes/sun/java2d/xr/XRCompositeManager.java Changeset: b566004bcb1a Author: dbuck Date: 2012-01-16 11:52 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/b566004bcb1a 7083621: Add fontconfig file for OEL6 and rename RH/O EL 5 file so that it is picked up for all 5.x updates Reviewed-by: bae, prr ! make/sun/awt/Makefile Changeset: 397667460892 Author: lana Date: 2012-01-18 11:27 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/397667460892 Merge - test/tools/launcher/DefaultLocaleTest.sh Changeset: e0f94b9c53a8 Author: alexsch Date: 2012-01-10 15:46 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/e0f94b9c53a8 7110815: closed/javax/swing/JSplitPane/4885629/bug4885629.java unstable on MacOS Reviewed-by: kizune + test/javax/swing/JSplitPane/4885629/bug4885629.java Changeset: 79d14e328670 Author: alexsch Date: 2012-01-10 17:11 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/79d14e328670 6505523: NullPointerException in BasicTreeUI when a node is removed by expansion listener Reviewed-by: rupashka ! src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java + test/javax/swing/JTree/6505523/bug6505523.java Changeset: ce32a4e1be1d Author: alexsch Date: 2012-01-13 12:39 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/ce32a4e1be1d 7121765: closed/javax/swing/JTextArea/4697612/bug4697612.java fails on MacOS on Aqua L&F Reviewed-by: rupashka + test/javax/swing/JTextArea/4697612/bug4697612.java + test/javax/swing/JTextArea/4697612/bug4697612.txt Changeset: 59b8875949e1 Author: malenkov Date: 2012-01-16 18:28 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/59b8875949e1 7122740: PropertyDescriptor Performance Slow Reviewed-by: rupashka ! src/share/classes/com/sun/beans/TypeResolver.java Changeset: 3e9d35e6ee4f Author: denis Date: 2012-01-17 19:09 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/3e9d35e6ee4f 7110590: DnDMerlinQLTestsuite_DnDJTextArea test fails with an java.awt.dnd.InvalidDnDOperationException Reviewed-by: art ! src/share/classes/java/awt/AWTKeyStroke.java Changeset: 89bc9d08fe82 Author: anthony Date: 2012-01-18 19:09 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/89bc9d08fe82 7130662: GTK file dialog crashes with a NPE Summary: Guard adding a back slash to the directory name with an if (!= null) check Reviewed-by: anthony, art Contributed-by: Matt ! src/solaris/classes/sun/awt/X11/GtkFileDialogPeer.java Changeset: fe1278123fbb Author: lana Date: 2012-01-18 11:41 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/fe1278123fbb Merge - test/tools/launcher/DefaultLocaleTest.sh Changeset: 4d8b49a45cff Author: lana Date: 2012-01-18 20:23 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/4d8b49a45cff Merge Changeset: 400cc379adb5 Author: alanb Date: 2012-01-06 15:00 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/400cc379adb5 7127235: (fs) NPE in Files.walkFileTree if cached attributes are GC'ed Reviewed-by: forax, chegar ! src/share/classes/java/nio/file/FileTreeWalker.java Changeset: cdc128128044 Author: valeriep Date: 2012-01-05 18:18 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/cdc128128044 6414899: P11Digest should support cloning Summary: Enhanced the PKCS11 Digest implementation to support cloning Reviewed-by: vinnie ! make/sun/security/pkcs11/mapfile-vers ! src/share/classes/sun/security/pkcs11/P11Digest.java ! src/share/classes/sun/security/pkcs11/wrapper/PKCS11.java ! src/share/lib/security/sunpkcs11-solaris.cfg ! src/share/native/sun/security/pkcs11/wrapper/pkcs11wrapper.h + test/sun/security/pkcs11/MessageDigest/TestCloning.java Changeset: e6ef778c1df4 Author: valeriep Date: 2012-01-06 11:02 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/e6ef778c1df4 Merge Changeset: 6720ae7b1448 Author: valeriep Date: 2012-01-06 16:06 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/6720ae7b1448 7033170: Cipher.getMaxAllowedKeyLength(String) throws NoSuchAlgorithmException Summary: Changed to always use full transformation as provider properties. Reviewed-by: mullan ! src/share/classes/sun/security/pkcs11/SunPKCS11.java ! test/javax/crypto/Cipher/GetMaxAllowed.java Changeset: 2050ff9dfc92 Author: darcy Date: 2012-01-06 18:47 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/2050ff9dfc92 7123649: Remove public modifier from Math.powerOfTwoF. Reviewed-by: smarks, alanb ! src/share/classes/java/lang/Math.java Changeset: 74c92c3e66ad Author: gadams Date: 2012-01-09 19:33 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/74c92c3e66ad 7030573: test/java/io/FileInputStream/LargeFileAvailable.java fails when there is insufficient disk space Reviewed-by: alanb ! test/java/io/FileInputStream/LargeFileAvailable.java Changeset: 858038d89fd5 Author: darcy Date: 2012-01-09 15:54 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/858038d89fd5 7128441: StrictMath performance improvement note shared with Math Reviewed-by: darcy Contributed-by: Martin Desruisseaux ! src/share/classes/java/lang/Math.java ! src/share/classes/java/lang/StrictMath.java Changeset: dd69d3695cee Author: darcy Date: 2012-01-09 20:14 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/dd69d3695cee 7128512: Javadoc typo in java.lang.invoke.MethodHandle Reviewed-by: mduigou ! src/share/classes/java/lang/invoke/MethodHandle.java Changeset: d72de8b3fe36 Author: chegar Date: 2012-01-10 10:57 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/d72de8b3fe36 7123415: Some cases of network interface indexes being read incorrectly Reviewed-by: chegar Contributed-by: brandon.passanisi at oracle.com ! src/solaris/native/java/net/net_util_md.c Changeset: bba276a6aa0d Author: chegar Date: 2012-01-10 12:48 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/bba276a6aa0d 7128584: Typo in sun.misc.VM's private directMemory field comment Reviewed-by: forax, chegar Contributed-by: Krystal Mok ! src/share/classes/sun/misc/VM.java Changeset: 49e64a8fc18f Author: darcy Date: 2012-01-10 17:12 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/49e64a8fc18f 7112008: Javadoc for j.l.Object.finalize() vs JLS 12.6 Finalization of Class Instances Reviewed-by: mduigou ! src/share/classes/java/lang/Object.java Changeset: 62dbcbe4c446 Author: darcy Date: 2012-01-10 17:46 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/62dbcbe4c446 7128931: Bad HTML escaping in java.lang.Throwable javadoc Reviewed-by: mduigou ! src/share/classes/java/lang/Throwable.java Changeset: 31a1fc60a895 Author: chegar Date: 2012-01-11 10:52 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/31a1fc60a895 7128648: HttpURLConnection.getHeaderFields should return an unmodifiable Map Reviewed-by: michaelm ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java + test/java/net/HttpURLConnection/UnmodifiableMaps.java Changeset: 82144054d2d8 Author: alanb Date: 2012-01-11 13:07 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/82144054d2d8 7068856: (fs) Typo in Files.isSameFile() javadoc 7099208: (fs) Files.newBufferedReader has typo in javadoc Reviewed-by: forax ! src/share/classes/java/nio/file/Files.java ! src/share/classes/java/nio/file/Path.java Changeset: 96fe796fd242 Author: ksrini Date: 2012-01-11 08:14 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/96fe796fd242 7125442: jar application located in two bytes character named folder cannot be run with JRE 7 u1/u2 Reviewed-by: sherman, mchung, darcy ! src/share/bin/java.c + test/tools/launcher/I18NJarTest.java ! test/tools/launcher/TestHelper.java Changeset: 11e52d5ba64e Author: xuelei Date: 2012-01-12 03:39 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/11e52d5ba64e 7106773: 512 bits RSA key cannot work with SHA384 and SHA512 Reviewed-by: weijun ! src/share/classes/sun/security/pkcs11/P11Cipher.java ! src/share/classes/sun/security/pkcs11/P11Key.java ! src/share/classes/sun/security/pkcs11/P11RSACipher.java ! src/share/classes/sun/security/pkcs11/P11Signature.java ! src/share/classes/sun/security/ssl/ClientHandshaker.java ! src/share/classes/sun/security/ssl/ServerHandshaker.java ! src/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java ! src/share/classes/sun/security/util/DisabledAlgorithmConstraints.java + src/share/classes/sun/security/util/KeyLength.java + src/share/classes/sun/security/util/Length.java ! src/windows/classes/sun/security/mscapi/Key.java ! src/windows/classes/sun/security/mscapi/RSACipher.java ! src/windows/classes/sun/security/mscapi/RSASignature.java + test/sun/security/mscapi/ShortRSAKey1024.sh + test/sun/security/mscapi/ShortRSAKey512.sh + test/sun/security/mscapi/ShortRSAKey768.sh + test/sun/security/mscapi/ShortRSAKeyWithinTLS.java ! test/sun/security/pkcs11/KeyStore/ClientAuth.java ! test/sun/security/pkcs11/KeyStore/ClientAuth.sh ! test/sun/security/ssl/javax/net/ssl/SSLContextVersion.java + test/sun/security/ssl/javax/net/ssl/TLSv12/ShortRSAKey512.java Changeset: 38bf1e9b6979 Author: weijun Date: 2012-01-13 09:50 +0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/38bf1e9b6979 7090565: Move test/closed/javax/security/auth/x500/X500Principal/Parse.java to open tests Reviewed-by: mullan + test/javax/security/auth/x500/X500Principal/NameFormat.java Changeset: ef3b6736c074 Author: valeriep Date: 2012-01-12 16:04 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/ef3b6736c074 7088989: Improve the performance for T4 by utilizing the newly provided crypto APIs Summary: Added the OracleUcrypto provider for utilizing the Solaris ucrypto API. Reviewed-by: weijun ! make/com/oracle/Makefile + make/com/oracle/net/Makefile + make/com/oracle/nio/Makefile + make/com/oracle/security/ucrypto/FILES_c.gmk + make/com/oracle/security/ucrypto/Makefile + make/com/oracle/security/ucrypto/mapfile-vers + make/com/oracle/util/Makefile ! src/share/lib/security/java.security-solaris ! test/Makefile + test/com/oracle/security/ucrypto/TestAES.java + test/com/oracle/security/ucrypto/TestDigest.java + test/com/oracle/security/ucrypto/TestRSA.java + test/com/oracle/security/ucrypto/UcryptoTest.java ! test/java/security/Provider/DefaultPKCS11.java Changeset: a7ad2fcd7291 Author: valeriep Date: 2012-01-12 18:49 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/a7ad2fcd7291 Merge Changeset: 7e593aa6ad41 Author: littlee Date: 2012-01-13 13:20 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/7e593aa6ad41 7129029: (fs) Unix file system provider should be buildable on platforms that don't support O_NOFOLLOW Reviewed-by: alanb ! src/solaris/classes/sun/nio/fs/UnixChannelFactory.java ! src/solaris/classes/sun/nio/fs/UnixFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/UnixNativeDispatcher.java ! src/solaris/classes/sun/nio/fs/UnixPath.java ! src/solaris/native/sun/nio/fs/genUnixConstants.c Changeset: e8e08d46cc37 Author: weijun Date: 2012-01-16 10:10 +0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/e8e08d46cc37 7118809: rcache deadlock Reviewed-by: valeriep ! src/share/classes/sun/security/krb5/internal/rcache/CacheTable.java ! src/share/classes/sun/security/krb5/internal/rcache/ReplayCache.java ! test/sun/security/krb5/auto/Context.java + test/sun/security/krb5/auto/ReplayCache.java Changeset: d1b0bda3a3c7 Author: alanb Date: 2012-01-16 16:30 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/d1b0bda3a3c7 7130398: ProblemList.txt updates (1/2012) Reviewed-by: chegar ! test/ProblemList.txt Changeset: e8a143213c65 Author: chegar Date: 2012-01-16 18:05 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/e8a143213c65 7129083: CookieManager does not store cookies if url is read before setting cookie manager Reviewed-by: michaelm ! src/share/classes/sun/net/www/http/HttpClient.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! src/share/classes/sun/net/www/protocol/https/HttpsClient.java + test/sun/net/www/http/HttpClient/CookieHttpClientTest.java + test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CookieHttpsClientTest.java Changeset: 40d699d7f6a1 Author: chegar Date: 2012-01-17 14:10 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/40d699d7f6a1 6671616: TEST_BUG: java/io/File/BlockIsDirectory.java fails when /dev/dsk empty (sol) Reviewed-by: alanb ! test/ProblemList.txt - test/java/io/File/BlockIsDirectory.java Changeset: 2f096eb72520 Author: mchung Date: 2012-01-17 15:55 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/2f096eb72520 7117570: Warnings in sun.mangement.* and its subpackages Reviewed-by: mchung, dsamersoff Contributed-by: kurchi.subhra.hazra at oracle.com ! src/share/classes/sun/management/Agent.java ! src/share/classes/sun/management/ConnectorAddressLink.java ! src/share/classes/sun/management/Flag.java ! src/share/classes/sun/management/GarbageCollectionNotifInfoCompositeData.java ! src/share/classes/sun/management/GarbageCollectorImpl.java ! src/share/classes/sun/management/GcInfoBuilder.java ! src/share/classes/sun/management/GcInfoCompositeData.java ! src/share/classes/sun/management/HotSpotDiagnostic.java ! src/share/classes/sun/management/HotspotCompilation.java ! src/share/classes/sun/management/HotspotThread.java ! src/share/classes/sun/management/LazyCompositeData.java ! src/share/classes/sun/management/ManagementFactoryHelper.java ! src/share/classes/sun/management/MappedMXBeanType.java ! src/share/classes/sun/management/MonitorInfoCompositeData.java ! src/share/classes/sun/management/NotificationEmitterSupport.java ! src/share/classes/sun/management/RuntimeImpl.java ! src/share/classes/sun/management/ThreadInfoCompositeData.java ! src/share/classes/sun/management/counter/perf/PerfInstrumentation.java ! src/share/classes/sun/management/jmxremote/ConnectorBootstrap.java ! src/share/classes/sun/management/snmp/AdaptorBootstrap.java ! src/share/classes/sun/management/snmp/jvminstr/JVM_MANAGEMENT_MIB_IMPL.java ! src/share/classes/sun/management/snmp/jvminstr/JvmMemGCTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmMemManagerTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmMemMgrPoolRelTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmMemPoolTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmMemoryImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmMemoryMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmOSImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTBootClassPathEntryImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTBootClassPathTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTClassPathEntryImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTClassPathTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTInputArgsEntryImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTInputArgsTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTLibraryPathEntryImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTLibraryPathTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRuntimeMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmThreadInstanceEntryImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmThreadInstanceTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmThreadingMetaImpl.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmClassesVerboseLevel.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmJITCompilerTimeMonitoring.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemManagerState.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemPoolCollectThreshdSupport.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemPoolState.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemPoolThreshdSupport.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemPoolType.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemoryGCCall.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemoryGCVerboseLevel.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmRTBootClassPathSupport.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmThreadContentionMonitoring.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmThreadCpuTimeMonitoring.java ! src/share/classes/sun/management/snmp/jvmmib/JVM_MANAGEMENT_MIB.java ! src/share/classes/sun/management/snmp/jvmmib/JVM_MANAGEMENT_MIBOidTable.java ! src/share/classes/sun/management/snmp/jvmmib/JvmClassLoadingMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmCompilationMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemGCEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemGCTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemManagerEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemManagerTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemMgrPoolRelEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemMgrPoolRelTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemPoolEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemPoolTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmOSMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTBootClassPathEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTBootClassPathTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTClassPathEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTClassPathTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTInputArgsEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTInputArgsTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTLibraryPathEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTLibraryPathTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRuntimeMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmThreadInstanceEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmThreadInstanceTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmThreadingMeta.java ! src/share/classes/sun/management/snmp/util/MibLogger.java ! src/share/classes/sun/management/snmp/util/SnmpListTableCache.java ! src/share/classes/sun/management/snmp/util/SnmpNamedListTableCache.java ! src/share/classes/sun/management/snmp/util/SnmpTableCache.java Changeset: b14e13237498 Author: lana Date: 2012-01-18 11:00 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/b14e13237498 Merge Changeset: e6614f361127 Author: lana Date: 2012-01-18 20:24 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/e6614f361127 Merge - test/java/io/File/BlockIsDirectory.java Changeset: 227fcf5d0bec Author: lana Date: 2012-01-24 13:43 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/227fcf5d0bec Merge - test/java/io/File/BlockIsDirectory.java Changeset: db189e2f3cdb Author: jrose Date: 2012-01-18 17:34 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/db189e2f3cdb 7117167: Misc warnings in java.lang.invoke and sun.invoke.* Reviewed-by: smarks ! src/share/classes/java/lang/invoke/AdapterMethodHandle.java ! src/share/classes/java/lang/invoke/MemberName.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleProxies.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/sun/invoke/util/ValueConversions.java ! src/share/classes/sun/invoke/util/Wrapper.java ! test/java/lang/invoke/CallSiteTest.java ! test/java/lang/invoke/ClassValueTest.java ! test/java/lang/invoke/InvokeGenericTest.java ! test/java/lang/invoke/JavaDocExamplesTest.java ! test/java/lang/invoke/MethodHandlesTest.java ! test/java/lang/invoke/MethodTypeTest.java ! test/java/lang/invoke/PermuteArgsTest.java ! test/java/lang/invoke/RicochetTest.java ! test/java/lang/invoke/ThrowExceptionsTest.java ! test/sun/invoke/util/ValueConversionsTest.java Changeset: 01014596ada1 Author: jrose Date: 2012-01-18 17:34 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/01014596ada1 7077803: java.lang.InternalError in java.lang.invoke.MethodHandleNatives.init Summary: Use correct access token for unreflecting MHs where setAccessible(true) Reviewed-by: never, twisti ! src/share/classes/java/lang/invoke/MethodHandles.java Changeset: 92d2cba30f08 Author: jrose Date: 2012-01-18 17:34 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/92d2cba30f08 7030453: JSR 292 ClassValue.get method is too slow Summary: Implement ClassValue cooperatively with Class like ThreadLocal with Thread. Reviewed-by: twisti, mduigou ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/ClassValue.java ! test/java/lang/invoke/ClassValueTest.java Changeset: 81a2629aa2a2 Author: amurillo Date: 2012-01-20 14:31 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/81a2629aa2a2 Merge Changeset: 954a1c535730 Author: amurillo Date: 2012-01-25 12:36 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/954a1c535730 Merge - test/java/io/File/BlockIsDirectory.java Changeset: d3b334e376d3 Author: mr Date: 2012-01-23 12:39 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/d3b334e376d3 7110396: Sound code fails to build with gcc 4.6 on multiarch Linux systems Reviewed-by: ohair ! make/javax/sound/jsoundalsa/Makefile Changeset: 54202e0148ec Author: katleman Date: 2012-01-25 13:54 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/54202e0148ec Merge Changeset: 34029a0c69bb Author: katleman Date: 2012-01-26 18:23 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/34029a0c69bb Added tag jdk8-b23 for changeset 54202e0148ec ! .hgtags Changeset: 4cf0a3d369ef Author: mchung Date: 2012-01-30 21:10 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/4cf0a3d369ef Merge ! .hgtags ! make/com/sun/tools/attach/Makefile ! make/common/Defs-linux.gmk ! make/common/Defs-solaris.gmk ! make/common/Defs-windows.gmk ! make/common/Defs.gmk ! make/common/Demo.gmk ! make/common/Release.gmk ! make/common/Rules.gmk ! make/common/shared/Platform.gmk ! make/common/shared/Sanity.gmk ! make/java/instrument/Makefile ! make/java/text/base/Makefile ! make/javax/sound/jsoundalsa/Makefile ! make/jpda/tty/Makefile ! make/jprt.properties ! make/launchers/Makefile ! make/modules/modules.config ! make/modules/modules.group ! make/sun/awt/Makefile ! make/sun/launcher/Makefile - make/sun/motif12/reorder-i586 - make/sun/motif12/reorder-sparc - make/sun/motif12/reorder-sparcv9 ! make/sun/serialver/Makefile ! make/sun/text/Makefile ! make/sun/tools/Makefile ! src/share/bin/java.c - src/share/classes/com/sun/tools/jdi/LinkedHashMap.java ! src/share/classes/java/io/File.java ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/ClassLoader.java ! src/share/classes/java/lang/SecurityManager.java ! src/share/classes/java/lang/System.java ! src/share/classes/java/util/ResourceBundle.java ! src/share/classes/java/util/jar/JarFile.java ! src/share/classes/java/util/prefs/Preferences.java - src/share/classes/sun/awt/FocusingTextField.java - src/share/classes/sun/awt/HorizBagLayout.java - src/share/classes/sun/awt/OrientableFlowLayout.java - src/share/classes/sun/awt/VariableGridLayout.java - src/share/classes/sun/awt/VerticalBagLayout.java ! src/share/classes/sun/launcher/LauncherHelper.java ! src/share/classes/sun/misc/JavaLangAccess.java ! src/share/classes/sun/misc/SharedSecrets.java - src/share/native/java/util/zip/zlib-1.2.3/ChangeLog - src/share/native/java/util/zip/zlib-1.2.3/README - src/share/native/java/util/zip/zlib-1.2.3/compress.c - src/share/native/java/util/zip/zlib-1.2.3/crc32.h - src/share/native/java/util/zip/zlib-1.2.3/deflate.c - src/share/native/java/util/zip/zlib-1.2.3/deflate.h - src/share/native/java/util/zip/zlib-1.2.3/gzio.c - src/share/native/java/util/zip/zlib-1.2.3/infback.c - src/share/native/java/util/zip/zlib-1.2.3/inffast.c - src/share/native/java/util/zip/zlib-1.2.3/inffast.h - src/share/native/java/util/zip/zlib-1.2.3/inffixed.h - src/share/native/java/util/zip/zlib-1.2.3/inflate.c - src/share/native/java/util/zip/zlib-1.2.3/inflate.h - src/share/native/java/util/zip/zlib-1.2.3/inftrees.c - src/share/native/java/util/zip/zlib-1.2.3/inftrees.h - src/share/native/java/util/zip/zlib-1.2.3/patches/ChangeLog_java - src/share/native/java/util/zip/zlib-1.2.3/patches/crc32.c.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/inflate.c.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/zconf.h.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/zlib.h.diff - src/share/native/java/util/zip/zlib-1.2.3/trees.c - src/share/native/java/util/zip/zlib-1.2.3/trees.h - src/share/native/java/util/zip/zlib-1.2.3/uncompr.c - src/share/native/java/util/zip/zlib-1.2.3/zadler32.c - src/share/native/java/util/zip/zlib-1.2.3/zconf.h - src/share/native/java/util/zip/zlib-1.2.3/zcrc32.c - src/share/native/java/util/zip/zlib-1.2.3/zlib.h - src/share/native/java/util/zip/zlib-1.2.3/zutil.c - src/share/native/java/util/zip/zlib-1.2.3/zutil.h - src/solaris/classes/sun/awt/motif/AWTLockAccess.java - src/solaris/classes/sun/awt/motif/MFontPeer.java - src/solaris/classes/sun/awt/motif/MToolkit.java - src/solaris/classes/sun/awt/motif/MToolkitThreadBlockedHandler.java - src/solaris/classes/sun/awt/motif/MWindowAttributes.java - src/solaris/classes/sun/awt/motif/X11FontMetrics.java - src/solaris/native/sun/awt/MouseInfo.c - src/solaris/native/sun/awt/XDrawingArea.c - src/solaris/native/sun/awt/XDrawingArea.h - src/solaris/native/sun/awt/XDrawingAreaP.h - src/solaris/native/sun/awt/awt_Cursor.h - src/solaris/native/sun/awt/awt_KeyboardFocusManager.h - src/solaris/native/sun/awt/awt_MToolkit.c - src/solaris/native/sun/awt/awt_MToolkit.h - src/solaris/native/sun/awt/awt_MenuItem.h - src/solaris/native/sun/awt/awt_PopupMenu.h - src/solaris/native/sun/awt/awt_TopLevel.h - src/solaris/native/sun/awt/awt_Window.h - src/solaris/native/sun/awt/awt_mgrsel.c - src/solaris/native/sun/awt/awt_mgrsel.h - src/solaris/native/sun/awt/awt_motif.h - src/solaris/native/sun/awt/awt_wm.c - src/solaris/native/sun/awt/awt_wm.h - src/solaris/native/sun/awt/awt_xembed.h - src/solaris/native/sun/awt/awt_xembed_server.c - src/solaris/native/sun/awt/awt_xembed_server.h ! test/Makefile - test/java/io/File/BlockIsDirectory.java - test/java/io/FileDescriptor/FileChannelFDTest.java - test/java/io/etc/FileDescriptorSharing.java - test/java/util/ResourceBundle/Control/ExpirationTest.java - test/java/util/ResourceBundle/Control/ExpirationTest.sh - test/tools/launcher/DefaultLocaleTest.sh From mandy.chung at oracle.com Mon Jan 30 21:56:14 2012 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 31 Jan 2012 05:56:14 +0000 Subject: hg: jigsaw/jigsaw/jdk: Fixed entry point in jdk.jcmd view Message-ID: <20120131055625.0582A472A2@hg.openjdk.java.net> Changeset: 9aa5af75699e Author: mchung Date: 2012-01-30 21:16 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/9aa5af75699e Fixed entry point in jdk.jcmd view ! make/modules/modules.group From mandy.chung at oracle.com Mon Jan 30 21:58:18 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 30 Jan 2012 21:58:18 -0800 Subject: jigsaw now sync'ed with jdk8-b23 In-Reply-To: <20120131051342.01D9A47299@hg.openjdk.java.net> References: <20120131051342.01D9A47299@hg.openjdk.java.net> Message-ID: <4F2782FA.5040406@oracle.com> From Alan.Bateman at oracle.com Tue Jan 31 00:04:28 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 31 Jan 2012 08:04:28 +0000 Subject: native cmds and libs in the module library In-Reply-To: <4F2779CE.4050308@oracle.com> References: <4EE62FE1.70006@oracle.com> <4EEF597F.3030804@oracle.com> <4EEF6518.4060004@oracle.com> <4EF08A20.7030106@oracle.com> <4EF08C15.7060305@oracle.com> <4F071DDA.2040607@oracle.com> <4F0B71E8.2010104@oracle.com> <4F158596.2030306@oracle.com> <4F166EB4.9060108@oracle.com> <4F19AABD.90604@oracle.com> <4F1EBD1C.3020607@oracle.com> <4F201FB8.9040307@oracle.com> <4F213E96.3020100@oracle.com> <4F2779CE.4050308@oracle.com> Message-ID: <4F27A08C.7050001@oracle.com> On 31/01/2012 05:19, David Holmes wrote: > So this may be the extra work you are referring to but I was surprised > to discover that doing: > > jmod create -L foo --natcmd bin --natlib lib > > didn't create foo/bin and foo/lib but rather created ./bin and ./lib Right, because if you specify relative directories then they are relative to pwd. If it helps then creating a custom image containing the system library then it can be done with steps such as: mkdir -p image/lib jmod create -L image/lib/modules --natcmd image/bin --natlib image/lib jmod install -L image/lib/modules jdk.base at 8-ea.jmod and that will give you a layout equivalent of the build's jre-base-image. -Alan. From david.holmes at oracle.com Tue Jan 31 00:40:06 2012 From: david.holmes at oracle.com (David Holmes) Date: Tue, 31 Jan 2012 18:40:06 +1000 Subject: native cmds and libs in the module library In-Reply-To: <4F27A08C.7050001@oracle.com> References: <4EE62FE1.70006@oracle.com> <4EEF597F.3030804@oracle.com> <4EEF6518.4060004@oracle.com> <4EF08A20.7030106@oracle.com> <4EF08C15.7060305@oracle.com> <4F071DDA.2040607@oracle.com> <4F0B71E8.2010104@oracle.com> <4F158596.2030306@oracle.com> <4F166EB4.9060108@oracle.com> <4F19AABD.90604@oracle.com> <4F1EBD1C.3020607@oracle.com> <4F201FB8.9040307@oracle.com> <4F213E96.3020100@oracle.com> <4F2779CE.4050308@oracle.com> <4F27A08C.7050001@oracle.com> Message-ID: <4F27A8E6.2090000@oracle.com> On 31/01/2012 6:04 PM, Alan Bateman wrote: > On 31/01/2012 05:19, David Holmes wrote: >> So this may be the extra work you are referring to but I was surprised >> to discover that doing: >> >> jmod create -L foo --natcmd bin --natlib lib >> >> didn't create foo/bin and foo/lib but rather created ./bin and ./lib > Right, because if you specify relative directories then they are > relative to pwd. I was thinking of the Library as being a "root" directory for everything, but its just the location to place the %jigsaw-library file, and the installed modules. > If it helps then creating a custom image containing the system library > then it can be done with steps such as: > > mkdir -p image/lib > jmod create -L image/lib/modules --natcmd image/bin --natlib image/lib > jmod install -L image/lib/modules jdk.base at 8-ea.jmod > > and that will give you a layout equivalent of the build's jre-base-image. Many thanks - and that worked without the IllegalArgumentException I reported in separate email. David ----- > -Alan. From Alan.Bateman at oracle.com Tue Jan 31 06:06:20 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 31 Jan 2012 14:06:20 +0000 Subject: javac: "legacy" mode In-Reply-To: <4F24242F.7000000@oracle.com> References: <4F231908.1020001@oracle.com> <4F234F58.9040002@oracle.com> <4F238C68.2010003@oracle.com> <4F24242F.7000000@oracle.com> Message-ID: <4F27F55C.1030807@oracle.com> On 28/01/2012 16:37, Jonathan Gibbons wrote: > : > I think it is more helpful to have javac just "do the right thing". > There are three recognizable types of compilation for javac, roughly > corresponding to 0, 1, many module-info files in the compilation. > > legacy mode: > no module-path option, no module-info to be compiled or on classpath > source hierarchy is organized by packages, as now > output dir will be organized by packages, as now > > single module mode: > class path set, or module path not set > source hierarchy is organized by packages, as now > output dir will be organized by packages, as now > > multi-module mode > module path set but not class path. > source hierarchy must be organized by modules. > output dir will be organized by modules > > The presumption is that in legacy mode, you should have access to all > JDK classes. In either module mode, unless you specify otherwise, a > module will only have access to the classes in the java.base module. > > I also think we should add to -verbose, so that javac can be more > informative about the type of compilation it is doing > > -- Jon Joining this thread a bit late but I think it is the case that javac has to do the right thing. There would be a bounty on your head if the world had to change their command-lines to compile existing code the way it has always compiled. So if there isn't any module compilation units then would it mean that jdk at 8 (as opposed to jdk.base at 8 when compiling in any module mode) would be required? -Alan. From lhochet at gmail.com Tue Jan 31 14:07:00 2012 From: lhochet at gmail.com (Ludovic HOCHET) Date: Tue, 31 Jan 2012 23:07:00 +0100 Subject: jigsaw now sync'ed with jdk8-b23 In-Reply-To: <4F2782FA.5040406@oracle.com> References: <20120131051342.01D9A47299@hg.openjdk.java.net> <4F2782FA.5040406@oracle.com> Message-ID: Hello, I tried building the latest source, but I'm having the following when trying to launch jconsole: ludovic at jigsaw-vm:~/dev/jigsaw$ export JIG=~/dev/jigsaw/build/linux-i586/jdk-module-image ludovic at jigsaw-vm:~/dev/jigsaw$ $JIG/bin/java -m jdk.jconsole Exception in thread "main" java.util.ServiceConfigurationError: sun.java2d.pipe.RenderingEngine: Provider sun.java2d.jules.JulesRenderingEngine not found at java.util.ServiceLoader.fail(ServiceLoader.java:231) at java.util.ServiceLoader.access$400(ServiceLoader.java:181) at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:367) at java.util.ServiceLoader$1.next(ServiceLoader.java:438) at sun.java2d.pipe.RenderingEngine$1.run(RenderingEngine.java:140) at sun.java2d.pipe.RenderingEngine$1.run(RenderingEngine.java:121) at java.security.AccessController.doPrivileged(Native Method) at sun.java2d.pipe.RenderingEngine.getInstance(RenderingEngine.java:121) at sun.java2d.pipe.LoopPipe.(LoopPipe.java:55) at sun.java2d.SurfaceData.(SurfaceData.java:448) at sun.awt.X11GraphicsEnvironment$1.run(X11GraphicsEnvironment.java:132) at java.security.AccessController.doPrivileged(Native Method) at sun.awt.X11GraphicsEnvironment.(X11GraphicsEnvironment.java:74) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:186) at java.awt.GraphicsEnvironment.createGE(GraphicsEnvironment.java:102) at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(GraphicsEnvironment.java:81) at sun.awt.X11.XToolkit.(XToolkit.java:121) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:186) at java.awt.Toolkit$2.run(Toolkit.java:870) at java.awt.Toolkit$2.run(Toolkit.java:863) at java.security.AccessController.doPrivileged(Native Method) at java.awt.Toolkit.getDefaultToolkit(Toolkit.java:862) at javax.swing.UIManager.getSystemLookAndFeelClassName(UIManager.java:604) at sun.tools.jconsole.JConsole.(JConsole.java:64) On Tue, Jan 31, 2012 at 06:58, Mandy Chung wrote: > > -- Ludovic ----------------------------------------- "Les formes qui differencient les etres importent peu si leur pensees s'unissent pour batir un univers..." Yoko Tsuno (in 'Les titans' by Roger Leloup) [The shapes that differenciate beings are not important if their thoughts unite to build a universe] From mandy.chung at oracle.com Tue Jan 31 15:49:02 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 31 Jan 2012 15:49:02 -0800 Subject: jigsaw now sync'ed with jdk8-b23 In-Reply-To: References: <20120131051342.01D9A47299@hg.openjdk.java.net> <4F2782FA.5040406@oracle.com> Message-ID: <4F287DEE.20505@oracle.com> On 1/31/2012 2:07 PM, Ludovic HOCHET wrote: > Hello, > I tried building the latest source, but I'm having the following when > trying to launch jconsole: > Thanks for reporting it. > ludovic at jigsaw-vm:~/dev/jigsaw$ export > JIG=~/dev/jigsaw/build/linux-i586/jdk-module-image > ludovic at jigsaw-vm:~/dev/jigsaw$ $JIG/bin/java -m jdk.jconsole > Exception in thread "main" java.util.ServiceConfigurationError: > sun.java2d.pipe.RenderingEngine: Provider > sun.java2d.jules.JulesRenderingEngine not found This depends on the services support that Alan is working on [1]. The service loader is not yet module-aware. Prior to the module views and exports change, all public types including sun.java2d.jules.JulesRenderingEngine are exported and that's why it was working previously. sun.java2d.pipe.RenderingEngine calls ServiceLoader.loadInstalled method to create a new service loader using the extension class loader. In module mode, there isn't any extension class loader but instead it should use the caller's module loader. Alan, what do you think to integrate the change you have in the ServiceLoader class that uses the proper module loader in module mode first? I think that can be separated from the services work. Mandy [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2011-December/001819.html From mikhail.ershov at oracle.com Mon Jan 23 10:39:16 2012 From: mikhail.ershov at oracle.com (Mike Ershov) Date: Mon, 23 Jan 2012 21:39:16 +0300 Subject: Questions about jigsaw API Message-ID: <4F1DA954.9010108@oracle.com> Hello, I'm adapting sigtest tool ( sigtest.java.net ) to jigsaw and have some questions about jigsaw API: 1) I need to read class bytes for any particular class and all its dependencies. In other words for module com.acme.mod at 3.1 I have to analyze com.acme.mod at 3.1's classes, their superclasses from other com.acme.* modules recursively and their platform superclasses including java.lang.Object. Maybe I missed something but I can't find easy way to do it. So I resolve all dependencies manually. This is my the main question. I very appreciate any recommendations. 2) org.openjdk.jigsaw.Library byte[] readClass(ModuleId mid, java.lang.String className) according to the javadoc "reads the class bytes of the given class within the given module, in this library or in a parent library." But actually it doesn't read a parent library. Please correct the description or, better, add this functionality. 3) I expected that SimpleLibrary.openSystemLibrary().readClass(Platform.bootModule(), "java.lang.Object") returns Object's bytes. It returns null because Platform.bootModule() is "jdk.base at 8-ea" instead of "jdk.boot at 8-ea". 4) I noticed that public org.openjdk.jigsaw.LoaderPool has no public constructors. If there is no reasons for such design it's better to do it not public ( like LibraryPool ) or make them all public. Thanks in advance, Mike From mikhail.ershov at oracle.com Tue Jan 24 00:51:18 2012 From: mikhail.ershov at oracle.com (Mike Ershov) Date: Tue, 24 Jan 2012 11:51:18 +0300 Subject: Javac ignores module-info dependencies Message-ID: <4F1E7106.2070708@oracle.com> Hello, I noticed that javac does not take requires part of module-info as compile class path. Is it correct behavior? I have sources for two modules under one source root - m1 and m2. m2 uses class from m1 but m2's module-info has no "requires m1" statement. I expected compile-time error, but a compilation is successful and I see runtime error. The code is attached. Sorry in advance if this is known issue. Thanks, Mike