From paul.sandoz at oracle.com Sun Jul 1 02:34:10 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Sun, 1 Jul 2012 11:34:10 +0200 Subject: Services/configuration/context webrevs Message-ID: Hi, I thought it would help to consolidate the service/configuration changes into one email. Each is like a plane circling in a holding pattern waiting to land at Heathrow... I have also separated out the configuration/context refactoring into a separate webrev. Service provider module resolution ----------------------------------------------- http://cr.openjdk.java.net/~psandoz/jigsaw/resolver-services/webrev.2/ - "permits" clauses do not affect service provider module resolution - service provider module resolution occurs after "application" resolution. Essentially the application has to successfully resolve as if there were no "requires service " clauses present and after that service provider module resolution occurs. I understand that on and off list there is reasonable agreement to go forward with this latter approach. Service state on configuration ---------------------------------------- http://cr.openjdk.java.net/~psandoz/jigsaw/config-services/webrev/ An extension of Configuration called InstalledConfiguration that encapsulates state mapping service interface class names to context and service provider class names for more optimal service instance creation. This state is exposed as an Iterable of a tuple of Context and service provider class name. An Iterable, rather than a Map, assumes much less on the underlying state representation. Context and persistence of service information is left unmodified. IMHO there is little benefit in separating this out. In terms of storage the service provider class names need to be associated with the correspond context. I felt it best to avoid duplication of context names in the persisted storage. Note that Configuration already performs another optimization, creating the map of context for context name, and the refactoring changes (see below) create the map of context for module view/alias name. Refactoring of configuration and context ------------------------------------------------------ http://cr.openjdk.java.net/~psandoz/jigsaw/config-refactor/webrev/ This is my attempt to refactor (or "curate" :-) ) the configuration and context classes to make "cleaner" the approach of building state of contexts and configurations then creating instances of contexts and configurations. I have tried to reduce the assumptions between things in the process of resolving, context builder construction (grouping modules into contexts), and linking local and remote suppliers. IMHO we need to gradually transition this code base from it's prototype-like state; much like Chris is doing for module file parsing/reading i am attempting to do for another area. http://cr.openjdk.java.net/~psandoz/jigsaw/config-refactor/config-services-webrev/ The above webrev is the same as "Service state on configuration" functionality but rebased on the refactoring changes (Mercurial queues are useful!). You may observe that it integrates more cleanly with SimpleLibrary when building the installed configuration from storage as there is no need for an explicit "initialization" step to calculate the optimal service look up state. Next steps -------------- - The test class _Configuration (and associated test builder classes) need to updated to support the building of contexts with service information and new tests need to be added verify service provider module dependency resolution. This may be an opportunity to see if TestNG can be used? - Retain topological order (from resolver's depth first search) for modules, contexts and service state. Iteration order of entries for HashMap and HashSet are not guaranteed if even it has up to now been mostly stable. The hash code related fixes in JDK8 will change that. Thus we need to explicitly support a consistent ordering using LinkedHashMap and LinkedHashSet. This is also the point at which to optimize the copying of state when building and constructing the configuration and contexts (i want persistent collections like those in Clojure and Scala!). Paul. From paul.sandoz at oracle.com Mon Jul 2 11:02:15 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 2 Jul 2012 20:02:15 +0200 Subject: Using Compile Time Annotations for Modularizing URLStreamHandlerFactory In-Reply-To: <10985988.FBv3kuCx4y@logoutik> References: <4FDBA66C.1090703@oracle.com> <10985988.FBv3kuCx4y@logoutik> Message-ID: <9E0397FE-90EA-498F-B2D2-D7569628D893@oracle.com> Hi, A bit late replying... On Jun 18, 2012, at 12:43 PM, Jaroslav Tulach wrote: > Dne P? 15. ?ervna 2012 17:17:32, Jesse Glick napsal(a): >> Something to consider - in a big application it is not uncommon to have >> multiple URL handlers implemented in various places. Yet the JRE only lets >> you set a single URLStreamHandlerFactory for the whole JVM. > > What a coincidence! On Friday I gave a talk at GeekOut, Tallinn, Estonia about > annotation processors and my main example was creation of effective, modular, > scalable, robust, condense, no-boiler plate and lazy support for registration > of URLStreamHandlers. > >> So for the >> application to be modular, you need to write a proxy factory which accepts >> modular registrations, > > Indeed I had to start with Proxy factory. Then I demonstrated classical > ServiceLoader approach (which you probably have in mind when thinking about > modularity & URLStreamHandlers). I continued showing, that it is not scalable. > To fix that I provided annotation and its processor. Still the code was too > verbose. I fixed that by allowing direct registration of URLConnection - and > generating the rest on a fly. At the end I eliminated almost all boiler plate > code in my final example[1] by generating wrapper URLConnection registration > by the annotation processor. This reminds me of types of thing one can do with dependency injection frameworks e.g. register a CDI-based or Guice-based proxy to do the look up. CDI implementations will scan, at runtime, the Java class files on the classpath for annotations and creates bindings from those, where as Guice requires a more explicit binding using Module (unless one layers on top). My preference is Guice's explicit binding rather than CDI's approach where everything is spread out. IMHO this is an area worth exploring further. > > Source code: https://github.com/jtulach/Annotations > Presentation: http://wiki.apidesign.org/images/0/08/HackIntoYourCompiler.pdf > > I know many of the ideas of using annotations go beyond the scope of Jigsaw > and you have your own problems, but (as I think this is the way effective > modularity should be built) I'd like to be able to build this on top of > Jigsaw. Won't Jigsaw try to prevent us doing this? At the moment there no mechanism in javac to augment a module declaration with "provides service S with P;", plus the module declaration would need "requires M;" for the module M that exports the type S. And in general how annotation processors hook up in the module model still needs to be worked out since they might have a different dependency graph to the application itself. I am still not sure in general about the annotation processor approach. It is rather clever and neat but, i wonder if it might be possible to explore an approach of a richer DI binding model some part declarative for the resolver to chew on and some part runtime for registration of the binding implementations. Paul. From paul.sandoz at oracle.com Tue Jul 3 05:45:23 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 3 Jul 2012 14:45:23 +0200 Subject: Self-describing sources: the JavaC patch In-Reply-To: <10091150.uPWDTv3VrT@logoutik> References: <10091150.uPWDTv3VrT@logoutik> Message-ID: <027A21D5-420F-4881-9824-E30B40FB9793@oracle.com> Hi, It surprised me too [*]: http://docs.oracle.com/javase/7/docs/technotes/tools/solaris/javac.html#commandlineargfile I suppose a motivation for this feature was command line length limitations. On Jun 26, 2012, at 11:14 AM, Jaroslav Tulach wrote: > Hello guys. > We had a discussion with Paul recently trying to find a way to have a form of > self-describing sources and not to compromise ''module-info.java'' purity. > > Here is a proposal > http://wiki.netbeans.org/JavacOptionsInSourceFiles > that modifies JavaC a bit and seems to fulfil many of the needs IDEs have[1]. > > What can stop us from changing JavaC to perform > > $ javac @source-info.cfg > > by default? Using this format for OpenJDK sources itself? > Changing other CLI > tools jar, jmod to extract information from the same configuration file? Would it be fair to say the logical progression is towards a project description configuration? I don't see how the NetBeans goal of 100% parity with a headless build could be achieved otherwise. How would NetBeans differentiate between source and test source? Or differentiate between building a modular jar or a jmod file? There needs to be an orchestrating meta-tool and configuration, and if such a meta-tool exists then is there any point in each tool processing the configuration file? since the meta-tool can tell the other tools what to do. Paul. [*] I was browsing the ant source recently and noticed that javac support on VMS requires that a special options file is created, but not using the supported command line file arg. From mandy.chung at oracle.com Wed Jul 4 20:55:07 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 04 Jul 2012 20:55:07 -0700 Subject: Services/configuration/context webrevs In-Reply-To: References: Message-ID: <4FF5101B.3010907@oracle.com> On 7/1/2012 2:34 AM, Paul Sandoz wrote: > Hi, > > I thought it would help to consolidate the service/configuration changes into one email. Yes, that helps. Thanks. > Service provider module resolution > ----------------------------------------------- > > http://cr.openjdk.java.net/~psandoz/jigsaw/resolver-services/webrev.2/ > > - "permits" clauses do not affect service provider module resolution > > - service provider module resolution occurs after "application" resolution. Essentially the application has to successfully resolve as if there were no "requires service " clauses present and after that service provider module resolution occurs. > > I understand that on and off list there is reasonable agreement to go forward with this latter approach. Doing the service provider dependency resolution in phases would make it a little easier to trace and diagnose. Each phase may add new modules to the graph (service provider module and its dependencies) and looks like it requires to re-validate if a module is required optionally but failed to be chosen in phase 0. For example, M requires optional X; requires service S; P requires X @ 1.0 provides service S with S1; X @ 1.0 permits P In this case, phase 0 will chose M only. Phase 1 choses P and X at 1.0 and the solution includes M, P, and X at 1.0. However, X at 1.0doesn't permit M but it's linked with M in your current implementation. Nits w.r.t. the change: Resolver.javaL221: toString() call is not needed L446: best to follow current convention to put the first parameter next to the signature L445 and line break at the second parameter. L450: 4-space indent would be good. L458: typo 'dependencey' L533: if serviceInterface was resolved in previous phases, it can skip and process the next service interface. many.sh L119 - it'd be good to add a comment that p4 is 1 implementation and permits is ignored. I think it would be useful to add a few test cases that service provider module pulls in new modules and how this fix changes the solution - e.g. a case when a provider module is not included due to a module selected in phase 0 doesn't satisfy its dependency. Mandy From paul.sandoz at oracle.com Thu Jul 5 02:47:34 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 5 Jul 2012 11:47:34 +0200 Subject: Services/configuration/context webrevs In-Reply-To: <4FF5101B.3010907@oracle.com> References: <4FF5101B.3010907@oracle.com> Message-ID: Hi, Thanks for looking at this. On Jul 5, 2012, at 5:55 AM, Mandy Chung wrote: > On 7/1/2012 2:34 AM, Paul Sandoz wrote: >> Hi, >> >> I thought it would help to consolidate the service/configuration changes into one email. > > Yes, that helps. Thanks. > >> Service provider module resolution >> ----------------------------------------------- >> >> http://cr.openjdk.java.net/~psandoz/jigsaw/resolver-services/webrev.2/ >> >> - "permits" clauses do not affect service provider module resolution >> >> - service provider module resolution occurs after "application" resolution. Essentially the application has to successfully resolve as if there were no "requires service " clauses present and after that service provider module resolution occurs. >> >> I understand that on and off list there is reasonable agreement to go forward with this latter approach. > > Doing the service provider dependency resolution in phases would make it a little easier to trace and diagnose. Each phase may add new modules to the graph (service provider module and its dependencies) Yes. (BTW there are currently three phases for jdk.base :-) ). > and looks like it requires to re-validate if a module is required optionally but failed to be chosen in phase 0. > For example, > > M > requires optional X; > requires service S; > > P > requires X @ 1.0 > provides service S with S1; > > X @ 1.0 > permits P > > In this case, phase 0 will chose M only. Phase 1 choses P and X at 1.0 and the solution includes M, P, and X at 1.0. However, X at 1.0doesn't permit M but it's linked with M in your current implementation. Well spotted. Hmm... need to put my thinking cap on and investigate! A service provider module choice from the perspective of the resolver is the same as a root module choice. I don't currently see how the above case is different from: module x at 1.0 { permits y; } module y at 1.0 { requires x; } module z at 1.0 { requires optional x; } when the order of resolution is z, y, then x. I have attached a simple test case that resolves using the above modules. So i think we have a general bug and require either: 1) a validation step on the set of resolved modules; or 2) the compile and install time linkers do the right thing. Which one we choose depends on whether we consider the above a valid solution or not. Can x be present but the linker knows that z should not link to x? i.e. as if the "resolve optional x" gets erased by the resolver by adapting the module info of z. It seems reasonable. Perhaps for now we should go with 1). I will do it as another webrev. > Nits w.r.t. the change: > Resolver.javaL221: toString() call is not needed s/221/211. OK. > L446: best to follow current convention to put the first parameter > next to the signature L445 and line break at the second parameter. > L450: 4-space indent would be good. Can we reach agreement on a code convention for Jigsaw that is supported by the NetBeans formatting options? then i can just hit Ctrl+Shift+F :-) i fully admit i am lazy! I don't have any strong preference on the style, I just want to be consistent and do it quickly to avoid us spending unnecessary cycles on these aspects. > L458: typo 'dependencey' > L533: if serviceInterface was resolved in previous phases, it can skip and process the next service interface. > I was wondering about this. A service provider dependency that failed to resolve in phase n might be resolved later in a phase > n. So i left that as is for now. Also I did not bother to check if a service provider dependency was already resolved since it is done in the resolve method and i wanted the tracing to show what was going on. > many.sh L119 - it'd be good to add a comment that p4 is 1 implementation > and permits is ignored. > > I think it would be useful to add a few test cases that service provider module pulls in new modules and how this fix changes the solution - e.g. a case when a provider module is not included due to a module selected in phase 0 doesn't satisfy its dependency. Yes, i want to flesh out the _Configurator related tests to support services, that should make redundant some of the shell-script-based tests, those tests can then focus on the use of ServiceLoader and we can probably consolidate. I have a preference to do that in another webrev, since it is gonna result in some shuffling around is that OK? Also i have a preference to do that after the refactoring changes (which somewhat cleans up that test code), but realize that could hold things up. Paul. From mandy.chung at oracle.com Thu Jul 5 08:13:20 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 05 Jul 2012 08:13:20 -0700 Subject: Services/configuration/context webrevs In-Reply-To: References: <4FF5101B.3010907@oracle.com> Message-ID: <4FF5AF10.6030309@oracle.com> On 7/5/2012 2:47 AM, Paul Sandoz wrote: > >> and looks like it requires to re-validate if a module is required optionally but failed to be chosen in phase 0. >> For example, >> >> M >> requires optional X; >> requires service S; >> >> P >> requires X @ 1.0 >> provides service S with S1; >> >> X @ 1.0 >> permits P >> >> In this case, phase 0 will chose M only. Phase 1 choses P andX at 1.0 and the solution includes M, P, andX at 1.0. However,X at 1.0doesn't permit M but it's linked with M in your current implementation. > Well spotted. Hmm... need to put my thinking cap on and investigate! > > A service provider module choice from the perspective of the resolver is the same as a root module choice. I don't currently see how the above case is different from: > > modulex at 1.0 { > permits y; > } > > moduley at 1.0 { > requires x; > } > > modulez at 1.0 { > requires optional x; > } > > when the order of resolution is z, y, then x. I have attached a simple test case that resolves using the above modules. The attachment is missing. The resulting solution would be z at 1.0 only which is correct. In the example I showed above, the service provider module P requires a module X at 1.0 that doesn't satisfy the constraints in the previously resolved modules. I would consider that module P will not be included as its dependency X at 1.0 fails to be resolved. > So i think we have a general bug and require either: > > 1) a validation step on the set of resolved modules; or > > 2) the compile and install time linkers do the right thing. > > Which one we choose depends on whether we consider the above a valid solution or not. Can x be present but the linker knows that z should not link to x? i.e. as if the "resolve optional x" gets erased by the resolver by adapting the module info of z. It seems reasonable. In your example, there is no service provider module in the picture. The current implementation should resolve z with no x module in the solution. Just to make sure this is the behavior you're thinking about - if x is required by a service provider module p being resolved in phase 1 due to (z but not x is one of the resolved module in phase 0), would the service provider module requiring x be included in the solution? >> L446: best to follow current convention to put the first parameter >> next to the signature L445 and line break at the second parameter. >> L450: 4-space indent would be good. > Can we reach agreement on a code convention for Jigsaw that is supported by the NetBeans formatting options? then i can just hit Ctrl+Shift+F :-) i fully admit i am lazy! One inconsistency I know of is the for-each statement "for (T a: iterable)" vs "for (T a : iterable)" whether a space is needed after ":". Other than that the coding convention for jigsaw is fairly consistently applied in the org.openjdk.jigsaw source e.g. 4-space indentation, and line breaks. Is there any other inconsistency you observe? > I don't have any strong preference on the style, I just want to be consistent and do it quickly to avoid us spending unnecessary cycles on these aspects. > > >> L458: typo 'dependencey' >> L533: if serviceInterface was resolved in previous phases, it can skip and process the next service interface. >> > I was wondering about this. A service provider dependency that failed to resolve in phase n might be resolved later in a phase> n. So i left that as is for now. Also I did not bother to check if a service provider dependency was already resolved since it is done in the resolve method and i wanted the tracing to show what was going on. Is it possible to have a service provider dependency that failed to resolve in phase n but successfully resolved later in phase > n? During resolution, the module libraries should be locked and there should be no change to the list of available modules. In any case, I think it's fine not to check that and the resolver/library would do better caching and avoid reading the same set of module-info multiple times. > >> many.sh L119 - it'd be good to add a comment that p4 is 1 implementation >> and permits is ignored. >> >> I think it would be useful to add a few test cases that service provider module pulls in new modules and how this fix changes the solution - e.g. a case when a provider module is not included due to a module selected in phase 0 doesn't satisfy its dependency. > Yes, i want to flesh out the _Configurator related tests to support services, that should make redundant some of the shell-script-based tests, those tests can then focus on the use of ServiceLoader and we can probably consolidate. > > I have a preference to do that in another webrev, since it is gonna result in some shuffling around is that OK? > > Also i have a preference to do that after the refactoring changes (which somewhat cleans up that test code), but realize that could hold things up. I see and you have several changes lined up. Would you consider to include the tests update in part of the refactoring webrev? Test cases are sometimes helpful for code review. Mandy From paul.sandoz at oracle.com Thu Jul 5 10:26:12 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 5 Jul 2012 19:26:12 +0200 Subject: Services/configuration/context webrevs In-Reply-To: <4FF5AF10.6030309@oracle.com> References: <4FF5101B.3010907@oracle.com> <4FF5AF10.6030309@oracle.com> Message-ID: On Jul 5, 2012, at 5:13 PM, Mandy Chung wrote: >>> >> Well spotted. Hmm... need to put my thinking cap on and investigate! >> >> A service provider module choice from the perspective of the resolver is the same as a root module choice. I don't currently see how the above case is different from: >> >> modulex at 1.0 { >> permits y; >> } >> >> moduley at 1.0 { >> requires x; >> } >> >> modulez at 1.0 { >> requires optional x; >> } >> >> when the order of resolution is z, y, then x. I have attached a simple test case that resolves using the above modules. > > The attachment is missing. That attachment got stripped by the mail server :-( i will resend to you privately. > The resulting solution would be z at 1.0 only which is correct. No, because module y is a required root module; x y and z will be compiled at the same time by javac (would be clearer if the attachment was present!). For me the solution is: [exec] | Configured for [x at 1.0, y at 1.0, z at 1.0] If I rename module z to y and module y to z the resolution will fail: [exec] error: Cannot resolve module dependencies using Jigsaw module resolver [exec] [x@=1.0, y@=1.0, z@=1.0]: Cannot resolve > In the example I showed above, the service provider module P requires a module X at 1.0 that doesn't satisfy the constraints in the previously resolved modules. I think the issue is more general. A service provider dependency is equivalent to an optional root dependency. > I would consider that module P will not be included as its dependency X at 1.0 fails to be resolved. > OK. >> So i think we have a general bug and require either: >> >> 1) a validation step on the set of resolved modules; or >> >> 2) the compile and install time linkers do the right thing. >> >> Which one we choose depends on whether we consider the above a valid solution or not. Can x be present but the linker knows that z should not link to x? i.e. as if the "resolve optional x" gets erased by the resolver by adapting the module info of z. It seems reasonable. > > In your example, there is no service provider module in the picture. The current implementation should resolve z with no x module in the solution. Just to make sure this is the behavior you're thinking about - if x is required by a service provider module p being resolved in phase 1 due to (z but not x is one of the resolved module in phase 0), would the service provider module requiring x be included in the solution? Yes i am beginning to think so, x would be included in the configuration but z would not be linked to x. To me that makes sense because of the "requires optional x" in z. Why should, for a failed resolution of x in z, the optionality of x in z affect other modules that can resolve a dependency on x? I realize that option 1) above does not make sense given the optionality. >>> L446: best to follow current convention to put the first parameter >>> next to the signature L445 and line break at the second parameter. >>> L450: 4-space indent would be good. >> Can we reach agreement on a code convention for Jigsaw that is supported by the NetBeans formatting options? then i can just hit Ctrl+Shift+F :-) i fully admit i am lazy! > > One inconsistency I know of is the for-each statement "for (T a: iterable)" vs "for (T a : iterable)" whether a space is needed after ":". Other than that the coding convention for jigsaw is fairly consistently applied in the org.openjdk.jigsaw source e.g. 4-space indentation, and line breaks. Is there any other inconsistency you observe? > It is not so much the existing inconsistency, i don't know to what extent the code is or is not consistent, but the effort required to not be inconsistent and the effort required to review code and point out the inconsistencies. It's something a tool like NBs can do. We just need agreement on the style and i can come up with a NBs formatting configuration. >> I don't have any strong preference on the style, I just want to be consistent and do it quickly to avoid us spending unnecessary cycles on these aspects. >> >> >>> L458: typo 'dependencey' >>> L533: if serviceInterface was resolved in previous phases, it can skip and process the next service interface. >>> >> I was wondering about this. A service provider dependency that failed to resolve in phase n might be resolved later in a phase> n. So i left that as is for now. Also I did not bother to check if a service provider dependency was already resolved since it is done in the resolve method and i wanted the tracing to show what was going on. > > Is it possible to have a service provider dependency that failed to resolve in phase n but successfully resolved later in phase > n? During resolution, the module libraries should be locked and there should be no change to the list of available modules. Good point, i am struggling to come up with an example. > In any case, I think it's fine not to check that and the resolver/library would do better caching and avoid reading the same set of module-info multiple times. > >> >>> many.sh L119 - it'd be good to add a comment that p4 is 1 implementation >>> and permits is ignored. >>> >>> I think it would be useful to add a few test cases that service provider module pulls in new modules and how this fix changes the solution - e.g. a case when a provider module is not included due to a module selected in phase 0 doesn't satisfy its dependency. >> Yes, i want to flesh out the _Configurator related tests to support services, that should make redundant some of the shell-script-based tests, those tests can then focus on the use of ServiceLoader and we can probably consolidate. >> >> I have a preference to do that in another webrev, since it is gonna result in some shuffling around is that OK? >> >> Also i have a preference to do that after the refactoring changes (which somewhat cleans up that test code), but realize that could hold things up. > > I see and you have several changes lined up. Would you consider to include the tests update in part of the refactoring webrev? Test cases are sometimes helpful for code review. > Yes. To keep things easier for everyone else it is probably best if keep work on the tip and pull it up stream as required. Paul. From jaroslav.tulach at oracle.com Thu Jul 5 13:45:23 2012 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Thu, 05 Jul 2012 22:45:23 +0200 Subject: Self-describing sources: the JavaC patch In-Reply-To: <027A21D5-420F-4881-9824-E30B40FB9793@oracle.com> References: <10091150.uPWDTv3VrT@logoutik> <027A21D5-420F-4881-9824-E30B40FB9793@oracle.com> Message-ID: <3707756.VTPEZ5Kcoo@logoutik> Hello Paul, I am on vacation, but I found this message worth replying sooner than I get back. Dne ?t 3. ?ervence 2012 14:45:23, Paul Sandoz napsal(a): > http://docs.oracle.com/javase/7/docs/technotes/tools/solaris/javac.html#commandlineargfile > > I suppose a motivation for this feature was command line length limitations. Very likely this support has been created to workaround some OS limitation. On the other hand, it basically captures the IDE needs. > On Jun 26, 2012, at 11:14 AM, Jaroslav Tulach wrote: > > Hello guys. > > We had a discussion with Paul recently trying to find a way to have a form > > of self-describing sources and not to compromise ''module-info.java'' > > purity. > > > > Here is a proposal > > http://wiki.netbeans.org/JavacOptionsInSourceFiles > > that modifies JavaC a bit and seems to fulfil many of the needs IDEs > > have[1]. > > > > What can stop us from changing JavaC to perform > > > > $ javac @source-info.cfg > > > > by default? Using this format for OpenJDK sources itself? > > > > > > Changing other CLI > > tools jar, jmod to extract information from the same configuration file? > > Would it be fair to say the logical progression is towards a project > description configuration? Right. Sources can't live alone and you need some information to process them the right way. Basically it sounds like a project description configuration, but see [1]. > I don't see how the NetBeans goal of 100% parity with a headless build could > be achieved otherwise. The way JavaC and other JDK tools (jmod, jar) understand the sources should be driven by the file layout. Not by (extensively long) command line parameters. > How would NetBeans differentiate between source and test source? [1] Please don't imagine Maven, we don't need to go that far. In certain systems "project" may not mean code+test. I've seen some systems that have a special project for the sources and other project for tests. I have not noticed any activity on the JDK team side to adhere to 21st century testing standards. And I don't need it. Code can live without tests, in spite what Maven tries to teach us... > Or > differentiate between building a modular jar or a jmod file? My proposal was suggesting different sections for [jar] and for [jmod] inside a single configuration file. Thta would basically be it, I guess. Details are TDB, first I need to convince JavaC team to even consider this idea, then jar and jmod will be the next target. > There needs to be an orchestrating meta-tool and configuration, and if such > a meta-tool exists then is there any point in each tool processing the > configuration file? since the meta-tool can tell the other tools what to > do. Is not that a matter of abstraction? Maven certainly defines "phases" that abstract from compilation, war, jar packaging, etc. For our purposes, it is essential to know that is it necessary to invoke javac before invoking jmod. But for that we don't need an "orchestrating meta-tool". Enough to hard code it for now. -jt PS: Please keep in mind that I am investigating options what will allow NetBeans to support Jigsaw without using Maven. Of course, if Jigsaw team tells us: "Go use Maven", we can get all our meta-information there. From paul.sandoz at oracle.com Fri Jul 6 09:43:08 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 6 Jul 2012 18:43:08 +0200 Subject: Modular services with OpenJDK Jigsaw and Guice Message-ID: Something for the weekend: http://earthly-powers.blogspot.fr/2012/07/modular-services-with-openjdk-jigsaw.html Paul. From jaroslav.tulach at oracle.com Mon Jul 9 04:49:33 2012 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Mon, 09 Jul 2012 13:49:33 +0200 Subject: Modular services with OpenJDK Jigsaw and Guice In-Reply-To: References: Message-ID: <13556194.iPbhCHo037@logoutik> Dne P? 6. ?ervence 2012 18:43:08, Paul Sandoz napsal(a): > Something for the weekend: > > http://earthly-powers.blogspot.fr/2012/07/modular-services-with-openjdk-jigs > aw.html Interesting. I was playing with something similar, but with Spring: http://wiki.apidesign.org/wiki/LookupAndSpring Translation notes: - Lookup.getDefault() means something like ServiceLoader.load(all_types) - @ServiceProvider is "provides service" I was trying to do this with Guice as well, but it does not work well. Guice would like to know all registered services before its "module" is constructed and we were seeking for a lazy binding. However we have not managed to convince Guice to call us back, when a particular type is needed. We gave up. -jt From paul.sandoz at oracle.com Mon Jul 9 08:52:12 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 9 Jul 2012 17:52:12 +0200 Subject: Service provider module resolution Re: Services/configuration/context webrevs In-Reply-To: <4FF5101B.3010907@oracle.com> References: <4FF5101B.3010907@oracle.com> Message-ID: <339D0144-4FBE-4557-AF2B-68B9CE38257C@oracle.com> Hi, The following webrev fixes the nits. Many service-based tests are added to _Configurator.java, which makes most of the service-based *.sh tests redundant so those redundant ones removed. I added a runtime service-based test [*] that ensures correct behavior for all three ServiceLoader methods. http://cr.openjdk.java.net/~psandoz/jigsaw/resolver-services/webrev.3/ -- I also added tests that show the permits behavior is general and not specific to services: 693 /* 694 * The following two tests re-produce an issue with permits 695 * and requires optional. Depending on the order of resolution 696 * a module, x, may be linked to a module, z, that is not 697 * permitted to do so. 698 * 699 * "requires optional" should not cause a resolution failure instead 700 * linking should not be performed for a "requires optional x" where 701 * x does not permit the requiring module. 702 */ 703 704 new Test("permits-requires-optional-permissive-linking", true, "z at 1") { 705 void init(MockLibrary mlib) { 706 mlib.add(module("z at 1") 707 .requiresOptional("x") 708 .requires("y")) 709 .add(module("y at 1").requires("x")) 710 .add(module("x at 1").permits("y")); 711 } 712 void ref(ConfigurationBuilder cfbd) { 713 cfbd.add(context("z at 1").remote("+x", "+y")) 714 .add(context("y at 1").remote("+x")) 715 .add(context("x at 1")); 716 // The result should be 717 // cfbd.add(context("z at 1").remote(""+y")) 718 // .add(context("y at 1").remote("+x")) 719 // .add(context("x at 1")); 720 } 721 }; 722 723 new Test("permits-requires-optional-failure", false, "z at 1") { 724 void init(MockLibrary mlib) { 725 mlib.add(module("z at 1") 726 .requires("y") 727 .requiresOptional("x")) 728 .add(module("y at 1").requires("x")) 729 .add(module("x at 1").permits("y")); 730 } 731 void ref(ConfigurationBuilder cfbd) { 732 cfbd.add(context("z at 1").remote("+x", "+y")) 733 .add(context("y at 1").remote("+x")) 734 .add(context("x at 1")); 735 // The result should be 736 // cfbd.add(context("z at 1").remote(""+y")) 737 // .add(context("y at 1").remote("+x")) 738 // .add(context("x at 1")); 739 } I will work on fixing that this week. Paul. [*] I held back on the temptation for now to convert to testng! jtreg is rather smart but IMHO we really need tests we can edit, debug and run within the IDE. On Jul 5, 2012, at 5:55 AM, Mandy Chung wrote: > On 7/1/2012 2:34 AM, Paul Sandoz wrote: >> Hi, >> >> I thought it would help to consolidate the service/configuration changes into one email. > > Yes, that helps. Thanks. > >> Service provider module resolution >> ----------------------------------------------- >> >> http://cr.openjdk.java.net/~psandoz/jigsaw/resolver-services/webrev.2/ >> >> - "permits" clauses do not affect service provider module resolution >> >> - service provider module resolution occurs after "application" resolution. Essentially the application has to successfully resolve as if there were no "requires service " clauses present and after that service provider module resolution occurs. >> >> I understand that on and off list there is reasonable agreement to go forward with this latter approach. > > Doing the service provider dependency resolution in phases would make it a little easier to trace and diagnose. Each phase may add new modules to the graph (service provider module and its dependencies) and looks like it requires to re-validate if a module is required optionally but failed to be chosen in phase 0. For example, > > M > requires optional X; > requires service S; > > P > requires X @ 1.0 > provides service S with S1; > > X @ 1.0 > permits P > > In this case, phase 0 will chose M only. Phase 1 choses P and X at 1.0 and the solution includes M, P, and X at 1.0. However, X at 1.0doesn't permit M but it's linked with M in your current implementation. > Nits w.r.t. the change: > Resolver.javaL221: toString() call is not needed > L446: best to follow current convention to put the first parameter > next to the signature L445 and line break at the second parameter. > L450: 4-space indent would be good. > L458: typo 'dependencey' > L533: if serviceInterface was resolved in previous phases, it can skip and process the next service interface. > > many.sh L119 - it'd be good to add a comment that p4 is 1 implementation > and permits is ignored. > > I think it would be useful to add a few test cases that service provider module pulls in new modules and how this fix changes the solution - e.g. a case when a provider module is not included due to a module selected in phase 0 doesn't satisfy its dependency. > > Mandy > From paul.sandoz at oracle.com Tue Jul 10 01:38:27 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 10 Jul 2012 10:38:27 +0200 Subject: Modular services with OpenJDK Jigsaw and Guice In-Reply-To: <13556194.iPbhCHo037@logoutik> References: <13556194.iPbhCHo037@logoutik> Message-ID: <17A28CF7-FE0E-45A2-90BB-59623F62B328@oracle.com> On Jul 9, 2012, at 1:49 PM, Jaroslav Tulach wrote: > Dne P? 6. ?ervence 2012 18:43:08, Paul Sandoz napsal(a): >> Something for the weekend: >> >> http://earthly-powers.blogspot.fr/2012/07/modular-services-with-openjdk-jigs >> aw.html > > Interesting. I was playing with something similar, but with Spring: > http://wiki.apidesign.org/wiki/LookupAndSpring > Translation notes: > - Lookup.getDefault() means something like ServiceLoader.load(all_types) > - @ServiceProvider is "provides service" > > I was trying to do this with Guice as well, but it does not work well. Guice > would like to know all registered services before its "module" is constructed > and we were seeking for a lazy binding. However we have not managed to > convince Guice to call us back, when a particular type is needed. We gave up. > Sisu provides extensions to Guice to avoid the need to explicitly bind: http://www.eclipse.org/sisu/ but i dunno if that can do what you want. FWIW i have a preference for explicit bindings, it seems to fit well with the idea of a module declaration expressing it's interface to consumers. Paul. From paul.sandoz at oracle.com Tue Jul 10 02:50:50 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 10 Jul 2012 11:50:50 +0200 Subject: Self-describing sources: the JavaC patch In-Reply-To: <3707756.VTPEZ5Kcoo@logoutik> References: <10091150.uPWDTv3VrT@logoutik> <027A21D5-420F-4881-9824-E30B40FB9793@oracle.com> <3707756.VTPEZ5Kcoo@logoutik> Message-ID: <1DEB346D-D950-49A3-915A-B6E59A85E4B2@oracle.com> Hi, On Jul 5, 2012, at 10:45 PM, Jaroslav Tulach wrote: > Hello Paul, > I am on vacation, but I found this message worth replying sooner than I get > back. > > Dne ?t 3. ?ervence 2012 14:45:23, Paul Sandoz napsal(a): >> > http://docs.oracle.com/javase/7/docs/technotes/tools/solaris/javac.html#commandlineargfile >> >> I suppose a motivation for this feature was command line length limitations. > > Very likely this support has been created to workaround some OS limitation. On > the other hand, it basically captures the IDE needs. > >> On Jun 26, 2012, at 11:14 AM, Jaroslav Tulach wrote: >>> Hello guys. >>> We had a discussion with Paul recently trying to find a way to have a form >>> of self-describing sources and not to compromise ''module-info.java'' >>> purity. >>> >>> Here is a proposal >>> http://wiki.netbeans.org/JavacOptionsInSourceFiles >>> that modifies JavaC a bit and seems to fulfil many of the needs IDEs >>> have[1]. >>> >>> What can stop us from changing JavaC to perform >>> >>> $ javac @source-info.cfg >>> >>> by default? Using this format for OpenJDK sources itself? >>> >>> >>> Changing other CLI >>> tools jar, jmod to extract information from the same configuration file? >> >> Would it be fair to say the logical progression is towards a project >> description configuration? > > Right. Sources can't live alone and you need some information to process them > the right way. Basically it sounds like a project description configuration, > but see [1]. > >> I don't see how the NetBeans goal of 100% parity with a headless build could >> be achieved otherwise. > > The way JavaC and other JDK tools (jmod, jar) understand the sources should be > driven by the file layout. Not by (extensively long) command line parameters. > So a default path for the source-info.cfg, and perhaps default paths for source, compilation of and jars/jmods? >> How would NetBeans differentiate between source and test source? > > [1] Please don't imagine Maven, :-) > we don't need to go that far. In certain > systems "project" may not mean code+test. I've seen some systems that have a > special project for the sources and other project for tests. I have not > noticed any activity on the JDK team side to adhere to 21st century testing > standards. And I don't need it. Code can live without tests, in spite what > Maven tries to teach us... > While i had maven in mind i was also thinking more generally e.g. unit-like tests are run and need to pass before installing and/or releasing. >> Or >> differentiate between building a modular jar or a jmod file? > > My proposal was suggesting different sections for [jar] and for [jmod] inside a > single configuration file. Thta would basically be it, I guess. Details are TDB, > first I need to convince JavaC team to even consider this idea, then jar and > jmod will be the next target. > >> There needs to be an orchestrating meta-tool and configuration, and if such >> a meta-tool exists then is there any point in each tool processing the >> configuration file? since the meta-tool can tell the other tools what to >> do. > > Is not that a matter of abstraction? Maven certainly defines "phases" that > abstract from compilation, war, jar packaging, etc. For our purposes, it is > essential to know that is it necessary to invoke javac before invoking jmod. > But for that we don't need an "orchestrating meta-tool". Enough to hard code > it for now. OK, just trying to work out what a larger picture might be. I suspect any largish project is likely to consist of multiple modules that are, where possible, compiled and installed independently in a well-defined order. I hope the JDK modularization effort of source restructuring heads towards that approach but it may take a while to get there. > -jt > > PS: Please keep in mind that I am investigating options what will allow > NetBeans to support Jigsaw without using Maven. Of course, if Jigsaw team > tells us: "Go use Maven", we can get all our meta-information there. > We need the likes of Jon et. al. to opine on this. I feel a little under qualified to espouse confidently on this area but it seems to me the approach of defaults and options in a source configuration file is low enough down in the stack to be flexibly reused by other tooling and quite useful for simple Java projects. Paul. From jaroslav.tulach at oracle.com Tue Jul 10 07:00:42 2012 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Tue, 10 Jul 2012 16:00:42 +0200 Subject: Self-describing sources: the JavaC patch In-Reply-To: <1DEB346D-D950-49A3-915A-B6E59A85E4B2@oracle.com> References: <10091150.uPWDTv3VrT@logoutik> <3707756.VTPEZ5Kcoo@logoutik> <1DEB346D-D950-49A3-915A-B6E59A85E4B2@oracle.com> Message-ID: <1642954.CpYIiz5COi@logoutik> Hello Paul. Dne ?t 10. ?ervence 2012 11:50:50, Paul Sandoz napsal(a): > > The way JavaC and other JDK tools (jmod, jar) understand the sources > > should be driven by the file layout. Not by (extensively long) command > > line parameters. > So a default path for the source-info.cfg, and perhaps default paths for > source, compilation of and jars/jmods? Right. I would suggest: - source-info.cfg would be expected in the working directory of the tool - all javac build products would be created under build subdir by default - jar or jmod would generate the result into dist directory - sources would be expected under src directory Of course, the actual layout may differ. But there should be defaults, imho. > >> How would NetBeans differentiate between source and test source? > > > > [1] Please don't imagine Maven, > : > :-) > : > > we don't need to go that far. In certain > > systems "project" may not mean code+test. I've seen some systems that have > > a special project for the sources and other project for tests. I have not > > noticed any activity on the JDK team side to adhere to 21st century > > testing standards. And I don't need it. Code can live without tests, in > > spite what Maven tries to teach us... > > While i had maven in mind i was also thinking more generally e.g. unit-like > tests are run and need to pass before installing and/or releasing. We don't need that to have self-describing sources. I don't want to ask the Jigsaw or JavaC team too much. But ... if the source-info.cfg is extensible, I can imagine testng tool could read its section(s) as well. > >> Or > >> differentiate between building a modular jar or a jmod file? > > > > My proposal was suggesting different sections for [jar] and for [jmod] > > inside a single configuration file. Thta would basically be it, I guess. > > Details are TDB, first I need to convince JavaC team to even consider > > this idea, then jar and jmod will be the next target. > > > >> There needs to be an orchestrating meta-tool and configuration, and if > >> such > >> a meta-tool exists then is there any point in each tool processing the > >> configuration file? since the meta-tool can tell the other tools what to > >> do. > > > > Is not that a matter of abstraction? Maven certainly defines "phases" that > > abstract from compilation, war, jar packaging, etc. For our purposes, it > > is > > essential to know that is it necessary to invoke javac before invoking > > jmod. But for that we don't need an "orchestrating meta-tool". Enough to > > hard code it for now. > > OK, just trying to work out what a larger picture might be. Yeah, I am trying to keep phases out of the scope. > I suspect any largish project is likely to consist of multiple modules that > are, where possible, compiled and installed independently in a well-defined > order. I hope the JDK modularization effort of source restructuring heads > towards that approach but it may take a while to get there. > > -jt > > > > PS: Please keep in mind that I am investigating options what will allow > > NetBeans to support Jigsaw without using Maven. Of course, if Jigsaw team > > tells us: "Go use Maven", we can get all our meta-information there. > > We need the likes of Jon et. al. to opine on this. I've put this topic on NetBeans/JavaC agenda for tomorrow's conf call. > I feel a little under qualified to espouse confidently on this area but it > seems to me the approach of defaults and options in a source configuration > file is low enough down in the stack to be flexibly reused by other tooling > and quite useful for simple Java projects. I am very pleased to hear that. -jt From paul.sandoz at oracle.com Tue Jul 10 09:02:27 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 10 Jul 2012 18:02:27 +0200 Subject: Requires optional permits Re: Service provider module resolution In-Reply-To: <339D0144-4FBE-4557-AF2B-68B9CE38257C@oracle.com> References: <4FF5101B.3010907@oracle.com> <339D0144-4FBE-4557-AF2B-68B9CE38257C@oracle.com> Message-ID: <4799B191-54CD-4606-AC15-9164E46046DA@oracle.com> Hi, Based off the previous webrev is the following one that fixes requires optional with permits: http://cr.openjdk.java.net/~psandoz/jigsaw/resolver-services/requires-optional-permits-webrev/ The two following tests produce the same configuration result where x is not linked to z. 693 new Test("permits-requires-optional-first", true, "z at 1") { 694 void init(MockLibrary mlib) { 695 mlib.add(module("z at 1") 696 .requiresOptional("x") 697 .requires("y")) 698 .add(module("y at 1").requires("x")) 699 .add(module("x at 1").permits("y")); 700 } 701 void ref(ConfigurationBuilder cfbd) { 702 cfbd.add(context("z at 1").remote("+y")) 703 .add(context("y at 1").remote("+x")) 704 .add(context("x at 1")); 705 } 706 }; 707 708 new Test("permits-requires-optional-second", true, "z at 1") { 709 void init(MockLibrary mlib) { 710 mlib.add(module("z at 1") 711 .requires("y") 712 .requiresOptional("x")) 713 .add(module("y at 1").requires("x")) 714 .add(module("x at 1").permits("y")); 715 } 716 void ref(ConfigurationBuilder cfbd) { 717 cfbd.add(context("z at 1").remote("+y")) 718 .add(context("y at 1").remote("+x")) 719 .add(context("x at 1")); 720 } 721 }; -- IIUC from reading the Jigsaw Big Picture document an optional dependency must resolve at compile time, if such a dependency is not resolvable due to permits or otherwise no module being present then resolution should fail. Currently this is not the case. Even the most simple "requires optional foo" where module "foo" does not exist will not resolute in resolution failure at compilation. This implies: 1) Compile-time resolution should fail e.g. with some post-validation step in PathLinker; and 2) Install-time resolution should pass with correct linking (as implemented in the webrev). Thoughts? Paul. On Jul 9, 2012, at 5:52 PM, Paul Sandoz wrote: > Hi, > > The following webrev fixes the nits. Many service-based tests are added to _Configurator.java, which makes most of the service-based *.sh tests redundant so those redundant ones removed. I added a runtime service-based test [*] that ensures correct behavior for all three ServiceLoader methods. > > http://cr.openjdk.java.net/~psandoz/jigsaw/resolver-services/webrev.3/ > > -- > > I also added tests that show the permits behavior is general and not specific to services: > > 693 /* > 694 * The following two tests re-produce an issue with permits > 695 * and requires optional. Depending on the order of resolution > 696 * a module, x, may be linked to a module, z, that is not > 697 * permitted to do so. > 698 * > 699 * "requires optional" should not cause a resolution failure instead > 700 * linking should not be performed for a "requires optional x" where > 701 * x does not permit the requiring module. > 702 */ > 703 > 704 new Test("permits-requires-optional-permissive-linking", true, "z at 1") { > 705 void init(MockLibrary mlib) { > 706 mlib.add(module("z at 1") > 707 .requiresOptional("x") > 708 .requires("y")) > 709 .add(module("y at 1").requires("x")) > 710 .add(module("x at 1").permits("y")); > 711 } > 712 void ref(ConfigurationBuilder cfbd) { > 713 cfbd.add(context("z at 1").remote("+x", "+y")) > 714 .add(context("y at 1").remote("+x")) > 715 .add(context("x at 1")); > 716 // The result should be > 717 // cfbd.add(context("z at 1").remote(""+y")) > 718 // .add(context("y at 1").remote("+x")) > 719 // .add(context("x at 1")); > 720 } > 721 }; > 722 > 723 new Test("permits-requires-optional-failure", false, "z at 1") { > 724 void init(MockLibrary mlib) { > 725 mlib.add(module("z at 1") > 726 .requires("y") > 727 .requiresOptional("x")) > 728 .add(module("y at 1").requires("x")) > 729 .add(module("x at 1").permits("y")); > 730 } > 731 void ref(ConfigurationBuilder cfbd) { > 732 cfbd.add(context("z at 1").remote("+x", "+y")) > 733 .add(context("y at 1").remote("+x")) > 734 .add(context("x at 1")); > 735 // The result should be > 736 // cfbd.add(context("z at 1").remote(""+y")) > 737 // .add(context("y at 1").remote("+x")) > 738 // .add(context("x at 1")); > 739 } > > I will work on fixing that this week. > > Paul. > > [*] I held back on the temptation for now to convert to testng! jtreg is rather smart but IMHO we really need tests we can edit, debug and run within the IDE. > > On Jul 5, 2012, at 5:55 AM, Mandy Chung wrote: > >> On 7/1/2012 2:34 AM, Paul Sandoz wrote: >>> Hi, >>> >>> I thought it would help to consolidate the service/configuration changes into one email. >> >> Yes, that helps. Thanks. >> >>> Service provider module resolution >>> ----------------------------------------------- >>> >>> http://cr.openjdk.java.net/~psandoz/jigsaw/resolver-services/webrev.2/ >>> >>> - "permits" clauses do not affect service provider module resolution >>> >>> - service provider module resolution occurs after "application" resolution. Essentially the application has to successfully resolve as if there were no "requires service " clauses present and after that service provider module resolution occurs. >>> >>> I understand that on and off list there is reasonable agreement to go forward with this latter approach. >> >> Doing the service provider dependency resolution in phases would make it a little easier to trace and diagnose. Each phase may add new modules to the graph (service provider module and its dependencies) and looks like it requires to re-validate if a module is required optionally but failed to be chosen in phase 0. For example, >> >> M >> requires optional X; >> requires service S; >> >> P >> requires X @ 1.0 >> provides service S with S1; >> >> X @ 1.0 >> permits P >> >> In this case, phase 0 will chose M only. Phase 1 choses P and X at 1.0 and the solution includes M, P, and X at 1.0. However, X at 1.0doesn't permit M but it's linked with M in your current implementation. >> Nits w.r.t. the change: >> Resolver.javaL221: toString() call is not needed >> L446: best to follow current convention to put the first parameter >> next to the signature L445 and line break at the second parameter. >> L450: 4-space indent would be good. >> L458: typo 'dependencey' >> L533: if serviceInterface was resolved in previous phases, it can skip and process the next service interface. >> >> many.sh L119 - it'd be good to add a comment that p4 is 1 implementation >> and permits is ignored. >> >> I think it would be useful to add a few test cases that service provider module pulls in new modules and how this fix changes the solution - e.g. a case when a provider module is not included due to a module selected in phase 0 doesn't satisfy its dependency. >> >> Mandy >> > From david.holmes at oracle.com Tue Jul 10 18:53:00 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 11 Jul 2012 11:53:00 +1000 Subject: Requires optional permits Re: Service provider module resolution In-Reply-To: <4799B191-54CD-4606-AC15-9164E46046DA@oracle.com> References: <4FF5101B.3010907@oracle.com> <339D0144-4FBE-4557-AF2B-68B9CE38257C@oracle.com> <4799B191-54CD-4606-AC15-9164E46046DA@oracle.com> Message-ID: <4FFCDC7C.9050802@oracle.com> On 11/07/2012 2:02 AM, Paul Sandoz wrote: > Based off the previous webrev is the following one that fixes requires optional with permits: > > http://cr.openjdk.java.net/~psandoz/jigsaw/resolver-services/requires-optional-permits-webrev/ > > The two following tests produce the same configuration result where x is not linked to z. > > 693 new Test("permits-requires-optional-first", true, "z at 1") { > 694 void init(MockLibrary mlib) { > 695 mlib.add(module("z at 1") > 696 .requiresOptional("x") > 697 .requires("y")) > 698 .add(module("y at 1").requires("x")) > 699 .add(module("x at 1").permits("y")); > 700 } > 701 void ref(ConfigurationBuilder cfbd) { > 702 cfbd.add(context("z at 1").remote("+y")) > 703 .add(context("y at 1").remote("+x")) > 704 .add(context("x at 1")); > 705 } > 706 }; > 707 > 708 new Test("permits-requires-optional-second", true, "z at 1") { > 709 void init(MockLibrary mlib) { > 710 mlib.add(module("z at 1") > 711 .requires("y") > 712 .requiresOptional("x")) > 713 .add(module("y at 1").requires("x")) > 714 .add(module("x at 1").permits("y")); > 715 } > 716 void ref(ConfigurationBuilder cfbd) { > 717 cfbd.add(context("z at 1").remote("+y")) > 718 .add(context("y at 1").remote("+x")) > 719 .add(context("x at 1")); > 720 } > 721 }; > > -- > > IIUC from reading the Jigsaw Big Picture document an optional dependency must resolve at compile time, if such a dependency is not resolvable due to permits or otherwise no module being present then resolution should fail. Are you only referring to an optional dependency on a module which in turns has a permits clause? I would not in general expect to have to resolve an optional dependency at compile time. David ------ > Currently this is not the case. Even the most simple "requires optional foo" where module "foo" does not exist will not resolute in resolution failure at compilation. > > This implies: > > 1) Compile-time resolution should fail e.g. with some post-validation step in PathLinker; and > > 2) Install-time resolution should pass with correct linking (as implemented in the webrev). > > Thoughts? > > Paul. > > On Jul 9, 2012, at 5:52 PM, Paul Sandoz wrote: > >> Hi, >> >> The following webrev fixes the nits. Many service-based tests are added to _Configurator.java, which makes most of the service-based *.sh tests redundant so those redundant ones removed. I added a runtime service-based test [*] that ensures correct behavior for all three ServiceLoader methods. >> >> http://cr.openjdk.java.net/~psandoz/jigsaw/resolver-services/webrev.3/ >> >> -- >> >> I also added tests that show the permits behavior is general and not specific to services: >> >> 693 /* >> 694 * The following two tests re-produce an issue with permits >> 695 * and requires optional. Depending on the order of resolution >> 696 * a module, x, may be linked to a module, z, that is not >> 697 * permitted to do so. >> 698 * >> 699 * "requires optional" should not cause a resolution failure instead >> 700 * linking should not be performed for a "requires optional x" where >> 701 * x does not permit the requiring module. >> 702 */ >> 703 >> 704 new Test("permits-requires-optional-permissive-linking", true, "z at 1") { >> 705 void init(MockLibrary mlib) { >> 706 mlib.add(module("z at 1") >> 707 .requiresOptional("x") >> 708 .requires("y")) >> 709 .add(module("y at 1").requires("x")) >> 710 .add(module("x at 1").permits("y")); >> 711 } >> 712 void ref(ConfigurationBuilder cfbd) { >> 713 cfbd.add(context("z at 1").remote("+x", "+y")) >> 714 .add(context("y at 1").remote("+x")) >> 715 .add(context("x at 1")); >> 716 // The result should be >> 717 // cfbd.add(context("z at 1").remote(""+y")) >> 718 // .add(context("y at 1").remote("+x")) >> 719 // .add(context("x at 1")); >> 720 } >> 721 }; >> 722 >> 723 new Test("permits-requires-optional-failure", false, "z at 1") { >> 724 void init(MockLibrary mlib) { >> 725 mlib.add(module("z at 1") >> 726 .requires("y") >> 727 .requiresOptional("x")) >> 728 .add(module("y at 1").requires("x")) >> 729 .add(module("x at 1").permits("y")); >> 730 } >> 731 void ref(ConfigurationBuilder cfbd) { >> 732 cfbd.add(context("z at 1").remote("+x", "+y")) >> 733 .add(context("y at 1").remote("+x")) >> 734 .add(context("x at 1")); >> 735 // The result should be >> 736 // cfbd.add(context("z at 1").remote(""+y")) >> 737 // .add(context("y at 1").remote("+x")) >> 738 // .add(context("x at 1")); >> 739 } >> >> I will work on fixing that this week. >> >> Paul. >> >> [*] I held back on the temptation for now to convert to testng! jtreg is rather smart but IMHO we really need tests we can edit, debug and run within the IDE. >> >> On Jul 5, 2012, at 5:55 AM, Mandy Chung wrote: >> >>> On 7/1/2012 2:34 AM, Paul Sandoz wrote: >>>> Hi, >>>> >>>> I thought it would help to consolidate the service/configuration changes into one email. >>> >>> Yes, that helps. Thanks. >>> >>>> Service provider module resolution >>>> ----------------------------------------------- >>>> >>>> http://cr.openjdk.java.net/~psandoz/jigsaw/resolver-services/webrev.2/ >>>> >>>> - "permits" clauses do not affect service provider module resolution >>>> >>>> - service provider module resolution occurs after "application" resolution. Essentially the application has to successfully resolve as if there were no "requires service " clauses present and after that service provider module resolution occurs. >>>> >>>> I understand that on and off list there is reasonable agreement to go forward with this latter approach. >>> >>> Doing the service provider dependency resolution in phases would make it a little easier to trace and diagnose. Each phase may add new modules to the graph (service provider module and its dependencies) and looks like it requires to re-validate if a module is required optionally but failed to be chosen in phase 0. For example, >>> >>> M >>> requires optional X; >>> requires service S; >>> >>> P >>> requires X @ 1.0 >>> provides service S with S1; >>> >>> X @ 1.0 >>> permits P >>> >>> In this case, phase 0 will chose M only. Phase 1 choses P and X at 1.0 and the solution includes M, P, and X at 1.0. However, X at 1.0doesn't permit M but it's linked with M in your current implementation. >>> Nits w.r.t. the change: >>> Resolver.javaL221: toString() call is not needed >>> L446: best to follow current convention to put the first parameter >>> next to the signature L445 and line break at the second parameter. >>> L450: 4-space indent would be good. >>> L458: typo 'dependencey' >>> L533: if serviceInterface was resolved in previous phases, it can skip and process the next service interface. >>> >>> many.sh L119 - it'd be good to add a comment that p4 is 1 implementation >>> and permits is ignored. >>> >>> I think it would be useful to add a few test cases that service provider module pulls in new modules and how this fix changes the solution - e.g. a case when a provider module is not included due to a module selected in phase 0 doesn't satisfy its dependency. >>> >>> Mandy >>> >> > From paul.sandoz at oracle.com Tue Jul 10 23:12:03 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 11 Jul 2012 08:12:03 +0200 Subject: Requires optional permits Re: Service provider module resolution In-Reply-To: <4FFCDC7C.9050802@oracle.com> References: <4FF5101B.3010907@oracle.com> <339D0144-4FBE-4557-AF2B-68B9CE38257C@oracle.com> <4799B191-54CD-4606-AC15-9164E46046DA@oracle.com> <4FFCDC7C.9050802@oracle.com> Message-ID: On Jul 11, 2012, at 3:53 AM, David Holmes wrote: >> >> IIUC from reading the Jigsaw Big Picture document an optional dependency must resolve at compile time, if such a dependency is not resolvable due to permits or otherwise no module being present then resolution should fail. > > Are you only referring to an optional dependency on a module which in turns has a permits clause? An optional dependency in general. From the Jigsaw Big Picture document: " Optional dependences A dependence from one module to another can be declared optional: module bar { requires optional foo; } If no foo module is available then bar can still be installed and invoked. Code in bar that uses types from foo must be written defensively so that it operates properly when foo is not available. A foo module must still be available when compiling bar since code in bar can depend upon types declared in foo. " > I would not in general expect to have to resolve an optional dependency at compile time. I was of the same opinion but then changed my mind. If there is an optional dependency then presumably code in the depending module must be using types exported by the optional dependent module. Reflection is one way to use those types, another is a little bit of indirection (static or via reflection) to static usage of those types. Paul. From david.holmes at oracle.com Tue Jul 10 23:28:07 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 11 Jul 2012 16:28:07 +1000 Subject: Requires optional permits Re: Service provider module resolution In-Reply-To: References: <4FF5101B.3010907@oracle.com> <339D0144-4FBE-4557-AF2B-68B9CE38257C@oracle.com> <4799B191-54CD-4606-AC15-9164E46046DA@oracle.com> <4FFCDC7C.9050802@oracle.com> Message-ID: <4FFD1CF7.4090409@oracle.com> On 11/07/2012 4:12 PM, Paul Sandoz wrote: > On Jul 11, 2012, at 3:53 AM, David Holmes wrote: >>> >>> IIUC from reading the Jigsaw Big Picture document an optional dependency must resolve at compile time, if such a dependency is not resolvable due to permits or otherwise no module being present then resolution should fail. >> >> Are you only referring to an optional dependency on a module which in turns has a permits clause? > > An optional dependency in general. From the Jigsaw Big Picture document: > > " > Optional dependences > A dependence from one module to another can be declared optional: > > module bar { > requires optional foo; > } > > If no foo module is available then bar can still be installed and invoked. Code in bar that uses types from foo must be written defensively so that it operates properly when foo is not available. > > A foo module must still be available when compiling bar since code in bar can depend upon types declared in foo. > " > >> I would not in general expect to have to resolve an optional dependency at compile time. > > I was of the same opinion but then changed my mind. > > If there is an optional dependency then presumably code in the depending module must be using types exported by the optional dependent module. Reflection is one way to use those types, another is a little bit of indirection (static or via reflection) to static usage of those types. I think this is wrong. I can use the optional module reflectively so that there is no direct type dependency (else the dependency would not be optional!). There is no reason that it needs to be present at compile time if I don't use those types directly. I would think the above statement from the Big Picture should read: "A foo module must still be available when compiling bar _if_ code in bar depends upon types declared in foo." Cheers, David ----- > Paul. From paul.sandoz at oracle.com Tue Jul 10 23:59:20 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 11 Jul 2012 08:59:20 +0200 Subject: Requires optional permits Re: Service provider module resolution In-Reply-To: <4FFD1CF7.4090409@oracle.com> References: <4FF5101B.3010907@oracle.com> <339D0144-4FBE-4557-AF2B-68B9CE38257C@oracle.com> <4799B191-54CD-4606-AC15-9164E46046DA@oracle.com> <4FFCDC7C.9050802@oracle.com> <4FFD1CF7.4090409@oracle.com> Message-ID: <14728F1E-CB64-4C41-8922-C6C23CFB1A2F@oracle.com> On Jul 11, 2012, at 8:28 AM, David Holmes wrote: >> >> If there is an optional dependency then presumably code in the depending module must be using types exported by the optional dependent module. Reflection is one way to use those types, another is a little bit of indirection (static or via reflection) to static usage of those types. > > I think this is wrong. I can use the optional module reflectively so that there is no direct type dependency (else the dependency would not be optional!). Yes, but the dependency can also be direct at compile time and optional at install time, it's just that "requires optional" does not differentiate between the two cases. > There is no reason that it needs to be present at compile time if I don't use those types directly. I would think the above statement from the Big Picture should read: > > "A foo module must still be available when compiling bar _if_ code in bar depends upon types declared in foo." > That's seems reasonable to me. I will try and get some clarification on this. Perhaps the resolver should output warnings at compile time for optional modules that are not present to augment any "cannot find symbol" compiler errors? Paul. From jaroslav.tulach at oracle.com Wed Jul 11 00:22:18 2012 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Wed, 11 Jul 2012 09:22:18 +0200 Subject: Compile time vs. runtime deps was: Requires optional permits In-Reply-To: <14728F1E-CB64-4C41-8922-C6C23CFB1A2F@oracle.com> References: <4FFD1CF7.4090409@oracle.com> <14728F1E-CB64-4C41-8922-C6C23CFB1A2F@oracle.com> Message-ID: <4069042.FfET1c2eWZ@logoutik> Dne St 11. ?ervence 2012 08:59:20, Paul Sandoz napsal(a): > On Jul 11, 2012, at 8:28 AM, David Holmes wrote: > >> If there is an optional dependency then presumably code in the depending > >> module must be using types exported by the optional dependent module. > >> Reflection is one way to use those types, another is a little bit of > >> indirection (static or via reflection) to static usage of those types.> > > I think this is wrong. I can use the optional module reflectively so that > > there is no direct type dependency (else the dependency would not be > > optional!). > Yes, but the dependency can also be direct at compile time and optional at > install time, it's just that "requires optional" does not differentiate > between the two cases. > > There is no reason that it needs to be present at compile time if I don't > > use those types directly. I would think the above statement from the Big > > Picture should read: > > > > "A foo module must still be available when compiling bar _if_ code in bar > > depends upon types declared in foo." > That's seems reasonable to me. I will try and get some clarification on > this. > > Perhaps the resolver should output warnings at compile time for optional > modules that are not present to augment any "cannot find symbol" compiler > errors? I believe both cases are possible. I can have optional dependency I need to compile against and I can as well have another optional dependency I don't need to compile against. There needs to be a way to express that properly to Jigsaw runtime as well as Javac. This is another example when runtime and compile time dependencies may differ. The first one I know is the list of annotation processor providing modules to be present when compiling, but not during execution. Time to introduce "requires compile m at 1.0"? -jt From paul.sandoz at oracle.com Wed Jul 11 01:05:09 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 11 Jul 2012 10:05:09 +0200 Subject: Compile time vs. runtime deps was: Requires optional permits In-Reply-To: <4069042.FfET1c2eWZ@logoutik> References: <4FFD1CF7.4090409@oracle.com> <14728F1E-CB64-4C41-8922-C6C23CFB1A2F@oracle.com> <4069042.FfET1c2eWZ@logoutik> Message-ID: <4F3FA406-BCB8-4B6E-8186-A37363CCD32D@oracle.com> On Jul 11, 2012, at 9:22 AM, Jaroslav Tulach wrote: > Dne St 11. ?ervence 2012 08:59:20, Paul Sandoz napsal(a): >> On Jul 11, 2012, at 8:28 AM, David Holmes wrote: >>>> If there is an optional dependency then presumably code in the depending >>>> module must be using types exported by the optional dependent module. >>>> Reflection is one way to use those types, another is a little bit of >>>> indirection (static or via reflection) to static usage of those types.> >>> I think this is wrong. I can use the optional module reflectively so that >>> there is no direct type dependency (else the dependency would not be >>> optional!). >> Yes, but the dependency can also be direct at compile time and optional at >> install time, it's just that "requires optional" does not differentiate >> between the two cases. >>> There is no reason that it needs to be present at compile time if I don't >>> use those types directly. I would think the above statement from the Big >>> Picture should read: >>> >>> "A foo module must still be available when compiling bar _if_ code in bar >>> depends upon types declared in foo." >> That's seems reasonable to me. I will try and get some clarification on >> this. >> >> Perhaps the resolver should output warnings at compile time for optional >> modules that are not present to augment any "cannot find symbol" compiler >> errors? > > I believe both cases are possible. I can have optional dependency I need to > compile against and I can as well have another optional dependency I don't > need to compile against. > Yes > There needs to be a way to express that properly to Jigsaw runtime as well as > Javac. > I was wondering the same. > This is another example when runtime and compile time dependencies may > differ. The first one I know is the list of annotation processor providing > modules to be present when compiling, but not during execution. > > Time to introduce "requires compile m at 1.0"? Scopes! Just to be clear: the annotation processor case is different from the two cases previously discussed with "requires optional", where defensive coding is used to deal with absence of the optional dependency at runtime. I suspect modular annotation processor support will require container support to isolate dependencies of compiling the application from the dependencies of the annotation processors. I can imagine something similar is required for test dependencies. Paul. From david.holmes at oracle.com Wed Jul 11 01:33:41 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 11 Jul 2012 18:33:41 +1000 Subject: Compile time vs. runtime deps was: Requires optional permits In-Reply-To: <4069042.FfET1c2eWZ@logoutik> References: <4FFD1CF7.4090409@oracle.com> <14728F1E-CB64-4C41-8922-C6C23CFB1A2F@oracle.com> <4069042.FfET1c2eWZ@logoutik> Message-ID: <4FFD3A65.40403@oracle.com> On 11/07/2012 5:22 PM, Jaroslav Tulach wrote: > Dne St 11. ?ervence 2012 08:59:20, Paul Sandoz napsal(a): >> On Jul 11, 2012, at 8:28 AM, David Holmes wrote: >>>> If there is an optional dependency then presumably code in the depending >>>> module must be using types exported by the optional dependent module. >>>> Reflection is one way to use those types, another is a little bit of >>>> indirection (static or via reflection) to static usage of those types.> >>> I think this is wrong. I can use the optional module reflectively so that >>> there is no direct type dependency (else the dependency would not be >>> optional!). >> Yes, but the dependency can also be direct at compile time and optional at >> install time, it's just that "requires optional" does not differentiate >> between the two cases. >>> There is no reason that it needs to be present at compile time if I don't >>> use those types directly. I would think the above statement from the Big >>> Picture should read: >>> >>> "A foo module must still be available when compiling bar _if_ code in bar >>> depends upon types declared in foo." >> That's seems reasonable to me. I will try and get some clarification on >> this. >> >> Perhaps the resolver should output warnings at compile time for optional >> modules that are not present to augment any "cannot find symbol" compiler >> errors? > > I believe both cases are possible. I can have optional dependency I need to > compile against and I can as well have another optional dependency I don't > need to compile against. > > There needs to be a way to express that properly to Jigsaw runtime as well as > Javac. I don't see why I need to make the distinction to the compiler. I declare an optional dependency and at compile-time it is, or isn't found. During compilation I reference a type and a module for that type is, or isn't, found. Whether the module was omitted or was optional it is simply a compile-time error if the type is not found. (I don't expect javac to know or determine that the not-found type would have been found in the missing optional module - how could it?) Conversely if I don't reference a type that isn't found, it is irrelevant whether there exists an optional module that wasn't found. David ----- > > This is another example when runtime and compile time dependencies may > differ. The first one I know is the list of annotation processor providing > modules to be present when compiling, but not during execution. > > Time to introduce "requires compile m at 1.0"? > -jt > From paul.sandoz at oracle.com Wed Jul 11 01:49:09 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 11 Jul 2012 10:49:09 +0200 Subject: Modular services with OpenJDK Jigsaw and Guice In-Reply-To: References: <13556194.iPbhCHo037@logoutik> <17A28CF7-FE0E-45A2-90BB-59623F62B328@oracle.com> Message-ID: <46556F11-344E-4712-A111-2875E77070D7@oracle.com> Hi Tim, Just to be clear on the approach i was experimenting with. I was not trying to shoe horn service discovery into Guice. Rather i was using Guice for explicit binding of service interfaces and using the ServiceLoader mechanism to bootstrap access to Injector instances provided by modules. The bindings of the Injector instances are introspected to find all keys for the type literal that is the service interface. From those keys service instances are obtained from the corresponding Injector. Using Guice this way provides a richer way to bind and scope service interfaces than is capable with ServiceLoader (in classpath or module mode) at the expense of having to explicitly declare the binding (which is currently also required in module mode for services), and the resolver is blind to what service interfaces are bound. I anticipated there would be one Guice Module/Injector per Java module for such Guice-based service lookup. I am sure it is possible to improve on this with tighter integration with the module system, especially the resolver if there were richer ways to signal the binding of service interfaces. Paul. On Jul 10, 2012, at 7:54 PM, Tim Boudreau wrote: > On Tue, Jul 10, 2012 at 4:38 AM, Paul Sandoz wrote: > Sisu provides extensions to Guice to avoid the need to explicitly bind: > > http://www.eclipse.org/sisu/ > > but i dunno if that can do what you want. > > FWIW i have a preference for explicit bindings, it seems to fit well with the idea of a module declaration expressing it's interface to consumers. > > Yeah, I've done the classpath scanning thing too. It's a bit brute-force and ugly, though. It does give you an additional sanity check on startup - if a class couldn't actually resolve its dependencies or threw an exception in a static initializer, you find that out immediately on startup. When I did this, I would just, say, look up all non-abstract subtypes of some interface which did not have my @Invisible annotation. > > But I don't think it's worth it - I'd rather use a mechanism like Lookup, or if I need more metadata, write an annotation processor that writes a file into the classpath, and then provide a module that finds and reads all such files, loads classes and binds them. Forcing loading every class the VM can see is overkill - and it should be a clear indication to anybody doing it that they're trying to fit a square peg in a round hole. > > The thing we're really touching on here is that Service Discovery != Dependency Injection, and sometimes you need both. Trying to shoehorn generic service discovery into Guice doesn't seem like a fabulous idea - it's simply not for that. If you've gotta, gotta, gotta do that, an annotation processor and some mechanism like META-INF/services files will work (ideally with richer metainfo than just a class name). > > But Guice injection is entirely based around Key[1] - which really just wraps up a type, generic RTTI and optional annotations; when it tries to inject a constructor parameter, it is constructing a Key for that parameter and then comparing it with the keys that the injector knows about. So injection is not polymorphic unless you tell Guice it is - I can call Lookup.lookup(Object.class) and I'll get something or other; if I @Inject Object, it's an error unless something told Guice to bind Object somehow - it will not guess for me (I had to learn this the hard way a few years ago, since I was used to Lookup [2]). > > One of my favorite things about Guice (as opposed to, say, Spring) is that it is tightly focused on exactly one very specific problem it's there to solve. It isn't a service discovery library, it's a separate-your-configuration-from-your-business-logic library. Probably things that try to abuse Guice to be a service-discovery/auto-wiring platform should not be encouraged, and some simple, clean mechanism like Lookup should be fulfilling that role - with an easy way to wrap a Guice Provider around that mechanism *for specific types*. > > Auto-wiring is useful and good (but commonly you need a way to override or turn pieces of it off in a test environment, and that aspect is usually implemented as an afterthought or hack when somebody tries to write a test and something explodes - Jarda, how many subclasses are there of Repository in older unit tests for NetBeans that don't directly use FileSystem?). It's good to have the mechanism be configurable and optionally able to be initialized by running code on startup (to solve the test environment problem). But it's really a different problem than Guice solves - it's just that the shape of the solution is deceptively similar. > > Orthagonal to all of this is the desire not to load classes on startup. That's an optimization. One that's critical for desktop applications, and uninteresting or even harmful for server-side applications (if the process is going to run for months, I care much more about it failing quickly if it's broken than I do about startup time). So probably any service discovery mechanism should be *able* to be completely declarative, but that should not be the only way to initialize things. > > -Tim > > [1] http://google-guice.googlecode.com/git/javadoc/com/google/inject/Key.html > [2] https://groups.google.com/forum/?fromgroups#!topic/google-guice/wyA1ZijITZU > From njbartlett at gmail.com Wed Jul 11 02:19:30 2012 From: njbartlett at gmail.com (Neil Bartlett) Date: Wed, 11 Jul 2012 10:19:30 +0100 Subject: Requires optional permits Re: Service provider module resolution In-Reply-To: <4FFD1CF7.4090409@oracle.com> References: <4FF5101B.3010907@oracle.com> <339D0144-4FBE-4557-AF2B-68B9CE38257C@oracle.com> <4799B191-54CD-4606-AC15-9164E46046DA@oracle.com> <4FFCDC7C.9050802@oracle.com> <4FFD1CF7.4090409@oracle.com> Message-ID: You don't have to interact with the optional dependency purely with reflection. You could check for the availability of the class first with ClassLoader.loadClass() or Class.forName(), and if that doesn't throw an exception then you can proceed and use the class in the normal way. Of course this has to be done before calling any code that has the dependency, whether directly or indirectly e.g. via a supertype. I have sometimes seen this done in OSGi, alhough optionality at the level of static class/package dependencies is widely considered to be a bad practice. If you do this then you clearly need the dependency at compile time but it is not needed at runtime. This is one of several reasons why compile dependencies differ from runtime dependencies. Neil On Wed, Jul 11, 2012 at 7:28 AM, David Holmes wrote: > On 11/07/2012 4:12 PM, Paul Sandoz wrote: >> >> On Jul 11, 2012, at 3:53 AM, David Holmes wrote: >>>> >>>> >>>> IIUC from reading the Jigsaw Big Picture document an optional dependency >>>> must resolve at compile time, if such a dependency is not resolvable due to >>>> permits or otherwise no module being present then resolution should fail. >>> >>> >>> Are you only referring to an optional dependency on a module which in >>> turns has a permits clause? >> >> >> An optional dependency in general. From the Jigsaw Big Picture document: >> >> " >> Optional dependences >> A dependence from one module to another can be declared optional: >> >> module bar { >> requires optional foo; >> } >> >> If no foo module is available then bar can still be installed and invoked. >> Code in bar that uses types from foo must be written defensively so that it >> operates properly when foo is not available. >> >> A foo module must still be available when compiling bar since code in bar >> can depend upon types declared in foo. >> " >> >>> I would not in general expect to have to resolve an optional dependency >>> at compile time. >> >> >> I was of the same opinion but then changed my mind. >> >> If there is an optional dependency then presumably code in the depending >> module must be using types exported by the optional dependent module. >> Reflection is one way to use those types, another is a little bit of >> indirection (static or via reflection) to static usage of those types. > > > I think this is wrong. I can use the optional module reflectively so that > there is no direct type dependency (else the dependency would not be > optional!). There is no reason that it needs to be present at compile time > if I don't use those types directly. I would think the above statement from > the Big Picture should read: > > "A foo module must still be available when compiling bar _if_ code in bar > depends upon types declared in foo." > > Cheers, > David > ----- > >> Paul. From david.holmes at oracle.com Wed Jul 11 03:54:20 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 11 Jul 2012 20:54:20 +1000 Subject: Requires optional permits Re: Service provider module resolution In-Reply-To: References: <4FF5101B.3010907@oracle.com> <339D0144-4FBE-4557-AF2B-68B9CE38257C@oracle.com> <4799B191-54CD-4606-AC15-9164E46046DA@oracle.com> <4FFCDC7C.9050802@oracle.com> <4FFD1CF7.4090409@oracle.com> Message-ID: <4FFD5B5C.6080802@oracle.com> On 11/07/2012 7:19 PM, Neil Bartlett wrote: > You don't have to interact with the optional dependency purely with > reflection. You could check for the availability of the class first > with ClassLoader.loadClass() or Class.forName(), and if that doesn't > throw an exception then you can proceed and use the class in the > normal way. Of course this has to be done before calling any code that > has the dependency, whether directly or indirectly e.g. via a > supertype. > > I have sometimes seen this done in OSGi, alhough optionality at the > level of static class/package dependencies is widely considered to be > a bad practice. > > If you do this then you clearly need the dependency at compile time > but it is not needed at runtime. This is one of several reasons why > compile dependencies differ from runtime dependencies. Sure. If you need it at compile time you need it at compile time. But if you don't you don't. My issue is with the apparent requirement that you _must_ be able to resolve the optional dependency at compile-time, whether you _need_ it or not. And I don't see that I should have to pre-declare whether I have a compile-time dependency or only a runtime one, as that will become self-evident at compile-time. Cheers, David > Neil > > > On Wed, Jul 11, 2012 at 7:28 AM, David Holmes wrote: >> On 11/07/2012 4:12 PM, Paul Sandoz wrote: >>> >>> On Jul 11, 2012, at 3:53 AM, David Holmes wrote: >>>>> >>>>> >>>>> IIUC from reading the Jigsaw Big Picture document an optional dependency >>>>> must resolve at compile time, if such a dependency is not resolvable due to >>>>> permits or otherwise no module being present then resolution should fail. >>>> >>>> >>>> Are you only referring to an optional dependency on a module which in >>>> turns has a permits clause? >>> >>> >>> An optional dependency in general. From the Jigsaw Big Picture document: >>> >>> " >>> Optional dependences >>> A dependence from one module to another can be declared optional: >>> >>> module bar { >>> requires optional foo; >>> } >>> >>> If no foo module is available then bar can still be installed and invoked. >>> Code in bar that uses types from foo must be written defensively so that it >>> operates properly when foo is not available. >>> >>> A foo module must still be available when compiling bar since code in bar >>> can depend upon types declared in foo. >>> " >>> >>>> I would not in general expect to have to resolve an optional dependency >>>> at compile time. >>> >>> >>> I was of the same opinion but then changed my mind. >>> >>> If there is an optional dependency then presumably code in the depending >>> module must be using types exported by the optional dependent module. >>> Reflection is one way to use those types, another is a little bit of >>> indirection (static or via reflection) to static usage of those types. >> >> >> I think this is wrong. I can use the optional module reflectively so that >> there is no direct type dependency (else the dependency would not be >> optional!). There is no reason that it needs to be present at compile time >> if I don't use those types directly. I would think the above statement from >> the Big Picture should read: >> >> "A foo module must still be available when compiling bar _if_ code in bar >> depends upon types declared in foo." >> >> Cheers, >> David >> ----- >> >>> Paul. From jaroslav.tulach at oracle.com Wed Jul 11 06:24:02 2012 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Wed, 11 Jul 2012 15:24:02 +0200 Subject: Compile time vs. runtime deps In-Reply-To: <4FFD3A65.40403@oracle.com> References: <4069042.FfET1c2eWZ@logoutik> <4FFD3A65.40403@oracle.com> Message-ID: <6679083.Hk9oz1TG9s@logoutik> Dne St 11. ?ervence 2012 18:33:41, David Holmes napsal(a): > On 11/07/2012 5:22 PM, Jaroslav Tulach wrote: > > Dne St 11. ?ervence 2012 08:59:20, Paul Sandoz napsal(a): > >> On Jul 11, 2012, at 8:28 AM, David Holmes wrote: > > > I believe both cases are possible. I can have optional dependency I need > > to > > compile against and I can as well have another optional dependency I don't > > need to compile against. > > > > There needs to be a way to express that properly to Jigsaw runtime as well > > as Javac. > > I don't see why I need to make the distinction to the compiler. I > declare an optional dependency and at compile-time it is, or isn't > found. That could produce different result during the compilation. The compilation could either succeed or fail. Javac and IDEs need to know whether the optional (in runtime) library should or should not be on the compilation "classpath". > During compilation I reference a type and a module for that type > is, or isn't, found. Whether the module was omitted or was optional it > is simply a compile-time error if the type is not found. (I don't expect > javac to know or determine that the not-found type would have been found > in the missing optional module - how could it?) The Javac and IDEs have to know. My proposal was to introduce some way of telling the system that there is a compile time only dependency. Thus for the case when you want a fully optional dependency you could say: requires optional m at 1.0; which would mean "m at 1.0" should not be present while compiling. Or one could use requires compile optional m at 1.0; which would make the "m at 1.0" optional during execution, but Javac and other source processing tools would know that it has to be present. -jt > > This is another example when runtime and compile time dependencies may > > differ. The first one I know is the list of annotation processor providing > > modules to be present when compiling, but not during execution. > > > > Time to introduce "requires compile m at 1.0"? > > -jt From Alan.Bateman at oracle.com Wed Jul 11 07:24:07 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 11 Jul 2012 15:24:07 +0100 Subject: Requires optional permits Re: Service provider module resolution In-Reply-To: References: <4FF5101B.3010907@oracle.com> <339D0144-4FBE-4557-AF2B-68B9CE38257C@oracle.com> <4799B191-54CD-4606-AC15-9164E46046DA@oracle.com> <4FFCDC7C.9050802@oracle.com> <4FFD1CF7.4090409@oracle.com> Message-ID: <4FFD8C87.5050207@oracle.com> On 11/07/2012 10:19, Neil Bartlett wrote: > You don't have to interact with the optional dependency purely with > reflection. You could check for the availability of the class first > with ClassLoader.loadClass() or Class.forName(), and if that doesn't > throw an exception then you can proceed and use the class in the > normal way. Of course this has to be done before calling any code that > has the dependency, whether directly or indirectly e.g. via a > supertype. > > I have sometimes seen this done in OSGi, alhough optionality at the > level of static class/package dependencies is widely considered to be > a bad practice. > > If you do this then you clearly need the dependency at compile time > but it is not needed at runtime. This is one of several reasons why > compile dependencies differ from runtime dependencies. > I realize you're not advocating this approach but it involves assumptions that may not be true everywhere. In particular it assumes that VM is not doing eager resolution as in theory you may get the CNF before the Class.forName executes. Precompilation and other install time optimizations have the potential to complicate things too. In any case, it's still all very fragile as the code compiles but may fail with CNF at runtime. -Alan. From david.holmes at oracle.com Wed Jul 11 17:54:27 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 12 Jul 2012 10:54:27 +1000 Subject: Compile time vs. runtime deps In-Reply-To: <6679083.Hk9oz1TG9s@logoutik> References: <4069042.FfET1c2eWZ@logoutik> <4FFD3A65.40403@oracle.com> <6679083.Hk9oz1TG9s@logoutik> Message-ID: <4FFE2043.4010905@oracle.com> On 11/07/2012 11:24 PM, Jaroslav Tulach wrote: > Dne St 11. ?ervence 2012 18:33:41, David Holmes napsal(a): >> On 11/07/2012 5:22 PM, Jaroslav Tulach wrote: >>> Dne St 11. ?ervence 2012 08:59:20, Paul Sandoz napsal(a): >>>> On Jul 11, 2012, at 8:28 AM, David Holmes wrote: >> >>> I believe both cases are possible. I can have optional dependency I need >>> to >>> compile against and I can as well have another optional dependency I don't >>> need to compile against. >>> >>> There needs to be a way to express that properly to Jigsaw runtime as well >>> as Javac. >> >> I don't see why I need to make the distinction to the compiler. I >> declare an optional dependency and at compile-time it is, or isn't >> found. > > That could produce different result during the compilation. The compilation > could either succeed or fail. Javac and IDEs need to know whether the optional > (in runtime) library should or should not be on the compilation "classpath". You mean the tools are going to dynamically examine my module-info.java/class and use it to determine what they should set modulepath/classpath to ??? That is not something I would have expected at all. If I build a project and the optional, but needed at compile-time, module is not present then I get a compilation error: type XXX not found. It is then up to me to realize that I am missing the module that exports XXX and either install it to the main library or add the library it is in to the appropriate path. (Just as I would have to add the jar file today.) >> During compilation I reference a type and a module for that type >> is, or isn't, found. Whether the module was omitted or was optional it >> is simply a compile-time error if the type is not found. (I don't expect >> javac to know or determine that the not-found type would have been found >> in the missing optional module - how could it?) > > The Javac and IDEs have to know. My proposal was to introduce some way of > telling the system that there is a compile time only dependency. Thus for the > case when you want a fully optional dependency you could say: > > requires optional m at 1.0; > > which would mean "m at 1.0" should not be present while compiling. Or one could > use > > requires compile optional m at 1.0; > > which would make the "m at 1.0" optional during execution, but Javac and other > source processing tools would know that it has to be present. Seems like an unnecessary complication to the module system to me. Cheers, David > -jt > >>> This is another example when runtime and compile time dependencies may >>> differ. The first one I know is the list of annotation processor providing >>> modules to be present when compiling, but not during execution. >>> >>> Time to introduce "requires compile m at 1.0"? >>> -jt From paul.sandoz at oracle.com Thu Jul 12 04:58:15 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 12 Jul 2012 13:58:15 +0200 Subject: Compile time vs. runtime deps In-Reply-To: <4FFE2043.4010905@oracle.com> References: <4069042.FfET1c2eWZ@logoutik> <4FFD3A65.40403@oracle.com> <6679083.Hk9oz1TG9s@logoutik> <4FFE2043.4010905@oracle.com> Message-ID: <98187E6C-C6E4-4063-9A15-25E6F3124DA0@oracle.com> On Jul 12, 2012, at 2:54 AM, David Holmes wrote: > On 11/07/2012 11:24 PM, Jaroslav Tulach wrote: >> Dne St 11. ?ervence 2012 18:33:41, David Holmes napsal(a): >>> On 11/07/2012 5:22 PM, Jaroslav Tulach wrote: >>>> Dne St 11. ?ervence 2012 08:59:20, Paul Sandoz napsal(a): >>>>> On Jul 11, 2012, at 8:28 AM, David Holmes wrote: >>> >>>> I believe both cases are possible. I can have optional dependency I need >>>> to >>>> compile against and I can as well have another optional dependency I don't >>>> need to compile against. >>>> >>>> There needs to be a way to express that properly to Jigsaw runtime as well >>>> as Javac. >>> >>> I don't see why I need to make the distinction to the compiler. I >>> declare an optional dependency and at compile-time it is, or isn't >>> found. >> >> That could produce different result during the compilation. The compilation >> could either succeed or fail. Javac and IDEs need to know whether the optional >> (in runtime) library should or should not be on the compilation "classpath". > > You mean the tools are going to dynamically examine my module-info.java/class and use it to determine what they should set modulepath/classpath to ??? > > That is not something I would have expected at all. If I build a project and the optional, but needed at compile-time, module is not present then I get a compilation error: type XXX not found. It is then up to me to realize that I am missing the module that exports XXX and either install it to the main library or add the library it is in to the appropriate path. (Just as I would have to add the jar file today.) > Maven has saved many a developer, when building a project, from the pain of manually dealing with jars! If the compile-time dependency was made explicit then tooling and/or the module system can automate what would otherwise be a manual process. Paul. From jaroslav.tulach at oracle.com Thu Jul 12 06:26:57 2012 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Thu, 12 Jul 2012 15:26:57 +0200 Subject: Compile time vs. runtime deps In-Reply-To: <4FFE2043.4010905@oracle.com> References: <6679083.Hk9oz1TG9s@logoutik> <4FFE2043.4010905@oracle.com> Message-ID: <1976077.ZL4lzu9txV@logoutik> Dne ?t 12. ?ervence 2012 10:54:27, David Holmes napsal(a): > >> I don't see why I need to make the distinction to the compiler. I > >> declare an optional dependency and at compile-time it is, or isn't > >> found. > > > > That could produce different result during the compilation. The > > compilation > > could either succeed or fail. Javac and IDEs need to know whether the > > optional (in runtime) library should or should not be on the compilation > > "classpath". > You mean the tools are going to dynamically examine my > module-info.java/class and use it to determine what they should set > modulepath/classpath to ??? Hello David, yes, that is the jigsaw plan. module-info.java is going to be the source of compilation classpath for javac. It is supposed to save us for "classpath hell". However, unlike other tools that shield us from such "hell", the current design addresses just a half (at most) of the problem. Should it stay this way, we are going to be faced to "classpath nightmare"... > That is not something I would have expected at all. I guess you are looking at Jigsaw from VM perspective, then! That is OK, but the Jigsaw tries to define (a bit of) tooling story too. > If I build a project > and the optional, but needed at compile-time, module is not present then > I get a compilation error: type XXX not found. It is then up to me to > realize that I am missing the module that exports XXX and either install > it to the main library or add the library it is in to the appropriate > path. (Just as I would have to add the jar file today.) The vicious circle is closed by noting that the "appropriate path" is expressed in module-info.java. And we are back where we started: this missing module is required for compilation, but optional for execution - we need a way to express that inside of module-info.java. -jt > > >> During compilation I reference a type and a module for that type > >> is, or isn't, found. Whether the module was omitted or was optional it > >> is simply a compile-time error if the type is not found. (I don't expect > >> javac to know or determine that the not-found type would have been found > >> in the missing optional module - how could it?) > > > > The Javac and IDEs have to know. My proposal was to introduce some way of > > telling the system that there is a compile time only dependency. Thus for > > the case when you want a fully optional dependency you could say: > > > > requires optional m at 1.0; > > > > which would mean "m at 1.0" should not be present while compiling. Or one > > could use > > > > requires compile optional m at 1.0; > > > > which would make the "m at 1.0" optional during execution, but Javac and > > other > > source processing tools would know that it has to be present. > > Seems like an unnecessary complication to the module system to me. > > Cheers, > David > > > -jt > > > >>> This is another example when runtime and compile time dependencies may > >>> differ. The first one I know is the list of annotation processor > >>> providing > >>> modules to be present when compiling, but not during execution. > >>> > >>> Time to introduce "requires compile m at 1.0"? > >>> -jt From deepak.patwardhan at itaas.com Thu Jul 12 06:54:50 2012 From: deepak.patwardhan at itaas.com (Deepak S Patwardhan) Date: Thu, 12 Jul 2012 19:24:50 +0530 Subject: ANT build file for the Quickstart example Message-ID: <004701cd6035$e94ec840$bbec58c0$@itaas.com> Hello, Has anyone written an ANT build file for the Quick start example on Project jigsaw's homepage ? Since current Maven is pretty much unusable for Jigsaw projects (right?), I tried to create an ANT build.xml with the intention to define targets like compile - compile the code. dist - prepare the jmod files using jpkg. install - install the jmod files into project's module library using jmod. But, I can't get the compile to happen successfully. This is what I tried : (target init creates the modules/ folder) The build fails with this message : compile: [javac] Compiling 5 source files to /home/deepak/Projects/kingdom/kssjava8/jigsaw/modules [javac] javac: invalid flag: -modulepath modules [javac] Usage: javac [javac] use -help for a list of possible options Any suggestions ? Regards, Deepak S Patwardhan. From alan.bateman at oracle.com Thu Jul 12 07:09:16 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 12 Jul 2012 14:09:16 +0000 Subject: hg: jigsaw/jigsaw: 15 new changesets Message-ID: <20120712140917.A508847FBC@hg.openjdk.java.net> Changeset: df998cd4d51d Author: sla Date: 2012-06-07 15:28 +0200 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/rev/df998cd4d51d 7165257: Add JFR tests to the JDK code base Reviewed-by: ohair, dholmes, nloodin, mgronlun ! make/jprt.properties Changeset: 6aea9b1a3840 Author: lana Date: 2012-06-08 12:01 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/rev/6aea9b1a3840 Merge Changeset: efd26e051e50 Author: erikj Date: 2012-06-07 20:25 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/rev/efd26e051e50 7170079: Adjustments to build-infra makefiles Reviewed-by: ohair, ohrstrom, ihse, jonas Contributed-by: jonas , erikj , ihse , tgranat , ykantser ! README-builds.html ! common/autoconf/autogen.sh ! common/autoconf/builddeps.m4 ! common/autoconf/configure ! common/autoconf/configure.ac ! common/autoconf/help.m4 ! common/autoconf/platform.m4 ! common/autoconf/spec.gmk.in ! common/bin/compareimage.sh ! common/bin/diffexec.sh ! common/bin/diffjarzip.sh ! common/bin/difflib.sh ! common/bin/logger.sh ! common/makefiles/JavaCompilation.gmk ! common/makefiles/MakeBase.gmk ! common/makefiles/Makefile ! common/makefiles/NativeCompilation.gmk Changeset: dd596160b323 Author: ohair Date: 2012-06-08 17:25 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/rev/dd596160b323 7170091: Fix missing wait between repo cloning in hgforest.sh Reviewed-by: strarup ! make/scripts/hgforest.sh Changeset: c61921f9b965 Author: ohair Date: 2012-06-08 17:28 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/rev/c61921f9b965 Merge Changeset: 661c9aae602b Author: katleman Date: 2012-06-13 16:53 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/rev/661c9aae602b Merge Changeset: 02c6c67c1bb7 Author: katleman Date: 2012-06-14 13:13 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/rev/02c6c67c1bb7 Added tag jdk8-b43 for changeset 661c9aae602b ! .hgtags Changeset: 8fb4cd2f05a1 Author: mbykov Date: 2012-06-19 14:24 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/rev/8fb4cd2f05a1 7178241: Basic script for JDK source code legal headers conformance verification Summary: A new script lic_check.sh to check license headers in JDK source code Reviewed-by: ohair, darcy Contributed-by: misha.bykov at oracle.com + make/scripts/lic_check.sh Changeset: e4f81a817447 Author: katleman Date: 2012-06-20 15:22 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/rev/e4f81a817447 Merge Changeset: 1e989139ce0d Author: katleman Date: 2012-06-21 17:07 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/rev/1e989139ce0d Added tag jdk8-b44 for changeset e4f81a817447 ! .hgtags Changeset: 1af3996aa431 Author: sla Date: 2012-06-11 20:52 +0200 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/rev/1af3996aa431 7175802: Missing jdk_jfr in top-level make file Reviewed-by: alanb ! test/Makefile Changeset: 67e1fb3b2b33 Author: lana Date: 2012-06-17 21:27 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/rev/67e1fb3b2b33 Merge Changeset: 633f2378c904 Author: lana Date: 2012-06-25 21:37 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/rev/633f2378c904 Merge Changeset: 27fa766a2298 Author: katleman Date: 2012-06-28 09:32 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/rev/27fa766a2298 Added tag jdk8-b45 for changeset 633f2378c904 ! .hgtags Changeset: 39e070487954 Author: alanb Date: 2012-07-11 14:49 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/rev/39e070487954 Merge ! .hgtags ! make/jprt.properties ! make/scripts/hgforest.sh ! test/Makefile From alan.bateman at oracle.com Thu Jul 12 07:09:33 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 12 Jul 2012 14:09:33 +0000 Subject: hg: jigsaw/jigsaw/corba: 15 new changesets Message-ID: <20120712140943.5726547FBD@hg.openjdk.java.net> Changeset: 0c0b50c7b76a Author: erikj Date: 2012-06-07 20:30 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/corba/rev/0c0b50c7b76a 7170079: Adjustments to build-infra makefiles Reviewed-by: ohair, ohrstrom, ihse, jonas Contributed-by: jonas , erikj , ihse , tgranat , ykantser ! makefiles/Makefile Changeset: a1f721fbe5d0 Author: ohair Date: 2012-06-13 09:43 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/corba/rev/a1f721fbe5d0 7176691: prtconf: devinfo facility not available in corba building Reviewed-by: tbell ! make/common/shared/Platform.gmk Changeset: cd879aff5d3c Author: katleman Date: 2012-06-13 16:53 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/corba/rev/cd879aff5d3c Merge Changeset: 439d9bf8e4ff Author: katleman Date: 2012-06-14 13:14 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/corba/rev/439d9bf8e4ff Added tag jdk8-b43 for changeset cd879aff5d3c ! .hgtags Changeset: ad3ba4b392cc Author: katleman Date: 2012-06-21 17:07 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/corba/rev/ad3ba4b392cc Added tag jdk8-b44 for changeset 439d9bf8e4ff ! .hgtags Changeset: 5222b7d658d4 Author: coffeys Date: 2012-03-26 14:01 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/corba/rev/5222b7d658d4 7143851: Improve IIOP stub and tie generation in RMIC 7149048: Changes to corba rmic stubGenerator class are not used during jdk build process Reviewed-by: mschoene, robm ! src/share/classes/sun/rmi/rmic/iiop/StubGenerator.java Changeset: e324dfb90c9e Author: mbankal Date: 2012-03-28 02:50 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/corba/rev/e324dfb90c9e 7079902: Refine CORBA data models Reviewed-by: coffeys ! src/share/classes/com/sun/corba/se/impl/interceptors/ClientRequestInfoImpl.java ! src/share/classes/com/sun/corba/se/impl/interceptors/ServerRequestInfoImpl.java ! src/share/classes/com/sun/corba/se/impl/javax/rmi/CORBA/Util.java ! src/share/classes/com/sun/corba/se/impl/oa/poa/POAPolicyMediatorBase_R.java ! src/share/classes/com/sun/corba/se/impl/oa/toa/TOAFactory.java ! src/share/classes/com/sun/corba/se/impl/orb/ParserTable.java ! src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryId_1_3.java ! src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryId_1_3_1.java ! src/share/classes/com/sun/corba/se/impl/protocol/LocalClientRequestDispatcherBase.java ! src/share/classes/com/sun/corba/se/impl/util/RepositoryId.java ! src/share/classes/com/sun/corba/se/spi/logging/CORBALogDomains.java ! src/share/classes/sun/rmi/rmic/iiop/IDLNames.java Changeset: 2846cb957582 Author: mbankal Date: 2012-03-28 02:53 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/corba/rev/2846cb957582 Merge Changeset: a00c5c0b1f30 Author: asaha Date: 2012-04-10 10:41 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/corba/rev/a00c5c0b1f30 Merge - make/tools/src/build/tools/stripproperties/StripProperties.java Changeset: 3697feea6f54 Author: asaha Date: 2012-05-08 07:27 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/corba/rev/3697feea6f54 Merge Changeset: 787fb5a0602f Author: asaha Date: 2012-05-21 14:50 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/corba/rev/787fb5a0602f Merge Changeset: 25bb958d07de Author: asaha Date: 2012-06-07 12:29 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/corba/rev/25bb958d07de Merge Changeset: 747dad9e9d37 Author: lana Date: 2012-06-26 10:13 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/corba/rev/747dad9e9d37 Merge Changeset: 30141e598d72 Author: katleman Date: 2012-06-28 09:32 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/corba/rev/30141e598d72 Added tag jdk8-b45 for changeset 747dad9e9d37 ! .hgtags Changeset: 783c171018ec Author: alanb Date: 2012-07-11 14:57 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/corba/rev/783c171018ec Merge ! .hgtags From alan.bateman at oracle.com Thu Jul 12 07:17:34 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 12 Jul 2012 14:17:34 +0000 Subject: hg: jigsaw/jigsaw/hotspot: 80 new changesets Message-ID: <20120712142023.B5B4847FBF@hg.openjdk.java.net> Changeset: b38fb5f31e31 Author: katleman Date: 2012-06-14 13:14 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/b38fb5f31e31 Added tag jdk8-b43 for changeset e77b8e0ed1f8 ! .hgtags Changeset: 6e2633440960 Author: amurillo Date: 2012-06-01 15:30 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/6e2633440960 7173438: new hotspot build - hs24-b14 Reviewed-by: jcoomes ! make/hotspot_version Changeset: fab99b17c1de Author: mikael Date: 2012-06-01 20:17 +0200 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/fab99b17c1de 7155453: [macosx] re-enable jbb tests in JPRT Summary: Run SPECjbb in headless mode and enable SPECjbb runs on OSX Reviewed-by: dcubed, dholmes ! make/jprt.properties Changeset: 4434fdad6b37 Author: dholmes Date: 2012-06-02 07:32 -0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/4434fdad6b37 Merge ! make/jprt.properties Changeset: e17b61ba7bb3 Author: kamg Date: 2012-06-04 10:22 -0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/e17b61ba7bb3 7166498: JVM crash in ClassVerifier Summary: Fixed raw pointer being used after potential safepoint/GC Reviewed-by: acorn, fparain, dholmes ! src/share/vm/classfile/verifier.cpp Changeset: a297b0e14605 Author: mgerdin Date: 2012-06-04 09:21 +0200 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/a297b0e14605 7172226: HotSpot fails to build with GCC 4.7 because of stricter c++ argument dependent lookup Summary: Add "using" keyword to import base class functions from FreeList to fix template name lookup in gcc 4.7 Reviewed-by: brutisso, iveresov ! src/share/vm/memory/binaryTreeDictionary.cpp ! src/share/vm/memory/binaryTreeDictionary.hpp Changeset: 37552638d24a Author: brutisso Date: 2012-06-05 22:30 +0200 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/37552638d24a 7172388: G1: _total_full_collections should not be incremented for concurrent cycles Reviewed-by: azeemj, jmasa ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/vm_operations_g1.cpp ! src/share/vm/gc_implementation/g1/vm_operations_g1.hpp Changeset: b9442ac22f59 Author: brutisso Date: 2012-06-04 13:29 +0200 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/b9442ac22f59 7173460: G1: java/lang/management/MemoryMXBean/CollectionUsageThreshold.java failes with G1 Summary: The scope of TraceMemoryManagerStats in G1CollectedHeap need to cover the call to G1MonitoringSupport::update_sizes() Reviewed-by: johnc, jmasa ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 063451aefde8 Author: jcoomes Date: 2012-06-08 09:49 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/063451aefde8 Merge Changeset: 2fe087c3e814 Author: jiangli Date: 2012-06-06 14:33 -0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/2fe087c3e814 7172967: Eliminate constMethod's _method backpointer to methodOop. Summary: Eliminate constMethod's _method backpointer to methodOop, and move the _constant field from methodOop to constMethod. Reviewed-by: roland, bdelsart, kamg ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstMethod.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Method.java ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.hpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/interp_masm_x86_32.hpp ! src/cpu/x86/vm/interp_masm_x86_64.hpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/os/solaris/dtrace/generateJvmOffsets.cpp ! src/os/solaris/dtrace/jhelper.d ! src/os/solaris/dtrace/libjvm_db.c ! src/share/vm/oops/constMethodKlass.cpp ! src/share/vm/oops/constMethodOop.cpp ! src/share/vm/oops/constMethodOop.hpp ! src/share/vm/oops/methodKlass.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: ab6ab9f84b2d Author: bdelsart Date: 2012-06-11 04:47 -0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/ab6ab9f84b2d Merge Changeset: dcfcdd01af4b Author: fparain Date: 2012-06-05 06:48 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/dcfcdd01af4b 7171703: JNI DefineClass crashes client VM when first parameter is NULL Reviewed-by: acorn, kamg, sspitsyn, dholmes ! src/share/vm/prims/jni.cpp Changeset: de909f001528 Author: mikael Date: 2012-06-06 05:21 +0200 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/de909f001528 7170275: os::print_os_info needs to know about Windows 8 Summary: Recognize Windows 8 and Windows Server 2012 Reviewed-by: sla, kvn, azeemj ! src/os/windows/vm/os_windows.cpp Changeset: 40b4aaf010e4 Author: dholmes Date: 2012-06-08 02:06 -0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/40b4aaf010e4 7172708: 32/64 bit type issues on Windows after Mac OS X port Reviewed-by: dholmes, coleenp Contributed-by: Chris Dennis ! src/share/vm/utilities/globalDefinitions_visCPP.hpp Changeset: 0a8b8cb8b22c Author: sla Date: 2012-06-11 10:28 +0200 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/0a8b8cb8b22c Merge Changeset: 4d399f013e5a Author: kamg Date: 2012-06-11 13:10 -0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/4d399f013e5a 7175914: Usage of gcc with precompiled headers produces wrong build dependencies Summary: Add -fpch-deps flag to gcc builds Reviewed-by: kamg, coleenp Contributed-by: volker.simonis at gmail.com ! make/bsd/makefiles/gcc.make ! make/linux/makefiles/gcc.make ! make/solaris/makefiles/gcc.make Changeset: 17b1b616daf7 Author: sla Date: 2012-06-14 12:21 +0200 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/17b1b616daf7 Merge Changeset: 8f6ce6f1049b Author: kvn Date: 2012-05-25 07:53 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/8f6ce6f1049b 7170463: C2 should recognize "obj.getClass() == A.class" code pattern Summary: optimize this code pattern obj.getClass() == A.class. Reviewed-by: jrose, kvn Contributed-by: Krystal Mok ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/subnode.cpp Changeset: 4d8787136e08 Author: twisti Date: 2012-05-25 11:39 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/4d8787136e08 7170145: C1 doesn't respect the JMM with volatile field loads Reviewed-by: kvn, roland ! src/share/vm/c1/c1_ValueMap.hpp Changeset: c8289830e172 Author: twisti Date: 2012-05-30 12:17 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/c8289830e172 7172843: C1: fix "assert(has_printable_bci()) failed: _printable_bci should have been set" Reviewed-by: twisti Contributed-by: Krystal Mok ! src/share/vm/c1/c1_Canonicalizer.cpp ! src/share/vm/c1/c1_Instruction.hpp Changeset: 7bc2d5136f54 Author: amurillo Date: 2012-06-01 11:25 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/7bc2d5136f54 7173635: jprt.properties should include release jdk7u6 Reviewed-by: jcoomes ! make/jprt.properties Changeset: 8f37087fc13f Author: roland Date: 2012-06-05 10:15 +0200 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/8f37087fc13f 7171890: C1: add Class.isInstance intrinsic Summary: Class.cast which calls Class.isInstance is heavily used by the new JSR 292 implementation Reviewed-by: roland Contributed-by: Krystal Mok ! src/share/vm/c1/c1_Canonicalizer.cpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/c1/c1_Runtime1.hpp Changeset: e1635876b206 Author: twisti Date: 2012-06-06 15:57 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/e1635876b206 7174884: C1: failures after 7171890: assert(cur_state != NULL) failed: state_before must be set Reviewed-by: kvn ! src/share/vm/c1/c1_Canonicalizer.cpp Changeset: 829ee34e7cbd Author: kvn Date: 2012-06-11 08:35 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/829ee34e7cbd Merge ! make/jprt.properties Changeset: ccaa67adfe5b Author: twisti Date: 2012-06-11 16:47 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/ccaa67adfe5b 7063674: Wrong results from basic comparisons after calls to Long.bitCount(long) Reviewed-by: kvn ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad Changeset: 0919b2e7895d Author: kvn Date: 2012-06-11 14:58 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/0919b2e7895d 7174510: 19 JCK compiler tests fail with C2 error: memNode.cpp:812 - ShouldNotReachHere Summary: Add missing check for EncodeP node in MemNode::Ideal_common_DU_postCCP() method. Reviewed-by: twisti ! src/share/vm/opto/memnode.cpp Changeset: d5dded5d1e0d Author: kvn Date: 2012-06-11 22:38 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/d5dded5d1e0d Merge Changeset: e7715c222897 Author: roland Date: 2012-06-12 10:02 +0200 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/e7715c222897 7174532: jdk/test/java/lang/Math/WorstCaseTests.java failing on x86 Summary: increase precision on x86 for the steps of the computation of exp and pow. Reviewed-by: kvn ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp Changeset: 121e5708ae96 Author: kvn Date: 2012-06-12 09:47 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/121e5708ae96 7169782: C2: SIGSEGV in LShiftLNode::Ideal(PhaseGVN*, bool) Summary: keep intermediate node alive till the end of the graph construction using dummy hook node trick Reviewed-by: kvn, twisti Contributed-by: vladimir.x.ivanov at oracle.com ! src/share/vm/opto/divnode.cpp + test/compiler/6732154/Test6732154.java + test/compiler/7169782/Test7169782.java Changeset: 8b0a4867acf0 Author: twisti Date: 2012-06-12 14:31 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/8b0a4867acf0 7174218: remove AtomicLongCSImpl intrinsics Reviewed-by: kvn, twisti Contributed-by: Krystal Mok ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/forms.cpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/prims/jvm.h ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 5e990493719e Author: kvn Date: 2012-06-12 16:23 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/5e990493719e 7173340: C2: code cleanup: use PhaseIterGVN::replace_edge(Node*, int, Node*) where applicable Summary: replace frequent C2 optimizer code patterns with new methods calls Reviewed-by: kvn, twisti Contributed-by: vladimir.x.ivanov at oracle.com ! src/share/vm/opto/domgraph.cpp ! src/share/vm/opto/ifnode.cpp ! src/share/vm/opto/loopPredicate.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopUnswitch.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/phaseX.hpp ! src/share/vm/opto/split_if.cpp ! src/share/vm/opto/superword.cpp Changeset: e2fe93124108 Author: twisti Date: 2012-06-13 11:36 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/e2fe93124108 7174928: JSR 292: unresolved invokedynamic call sites deopt and osr infinitely Reviewed-by: kvn ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp Changeset: eba1d5bce9e8 Author: kvn Date: 2012-06-14 14:59 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/eba1d5bce9e8 Merge ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 5ba29a1db46e Author: amurillo Date: 2012-06-15 14:07 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/5ba29a1db46e Merge Changeset: 831e5c76a20a Author: amurillo Date: 2012-06-15 14:07 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/831e5c76a20a Added tag hs24-b14 for changeset 5ba29a1db46e ! .hgtags Changeset: 0976e71907b9 Author: katleman Date: 2012-06-21 17:07 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/0976e71907b9 Added tag jdk8-b44 for changeset 831e5c76a20a ! .hgtags Changeset: 1e76463170b3 Author: kamg Date: 2012-03-29 18:55 -0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/1e76463170b3 7110720: Issue with vm config file loadingIssue with vm config file loading Summary: disabling default config files if -XX:-ReadDefaultConfigFiles Reviewed-by: phh, jrose, dcubed, dholmes ! src/share/vm/compiler/compilerOracle.cpp ! src/share/vm/compiler/compilerOracle.hpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/runtime/arguments.cpp + test/runtime/7110720/Test7110720.sh Changeset: e778c29768e6 Author: never Date: 2012-04-04 20:44 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/e778c29768e6 7152811: Issues in client compiler Reviewed-by: kvn, jrose ! src/share/vm/ci/ciField.cpp ! src/share/vm/ci/ciField.hpp Changeset: 958bb4b7be49 Author: asaha Date: 2012-04-10 10:42 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/958bb4b7be49 Merge ! src/share/vm/runtime/arguments.cpp Changeset: aa07e41a9f80 Author: never Date: 2012-04-12 12:07 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/aa07e41a9f80 7160677: missing else in fix for 7152811 Reviewed-by: kvn, kevinw ! src/share/vm/ci/ciField.cpp Changeset: 5142b5110214 Author: asaha Date: 2012-05-08 07:29 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/5142b5110214 Merge ! src/share/vm/opto/runtime.cpp Changeset: d558e01a72c0 Author: kamg Date: 2012-05-03 15:37 -0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/d558e01a72c0 7160757: Problem with hotspot/runtime_classfile Summary: Allow only current and super invokespecials of Reviewed-by: never, coleenp, dcubed ! src/share/vm/classfile/verifier.cpp + test/runtime/7160757/Test7160757.java Changeset: 6d2c830e025d Author: asaha Date: 2012-05-08 11:29 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/6d2c830e025d Merge Changeset: 84e198dc2474 Author: asaha Date: 2012-05-21 14:56 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/84e198dc2474 Merge - src/share/vm/gc_implementation/concurrentMarkSweep/binaryTreeDictionary.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/binaryTreeDictionary.hpp - src/share/vm/gc_implementation/concurrentMarkSweep/freeBlockDictionary.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/freeBlockDictionary.hpp - src/share/vm/gc_implementation/concurrentMarkSweep/freeList.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/freeList.hpp ! src/share/vm/runtime/arguments.cpp Changeset: f9d57285de70 Author: asaha Date: 2012-06-07 12:30 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/f9d57285de70 Merge ! src/share/vm/runtime/arguments.cpp Changeset: 9d5f20961bc5 Author: lana Date: 2012-06-26 10:27 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/9d5f20961bc5 Merge ! src/share/vm/classfile/verifier.cpp Changeset: a8b9798c1d45 Author: katleman Date: 2012-06-28 09:32 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/a8b9798c1d45 Added tag jdk8-b45 for changeset 9d5f20961bc5 ! .hgtags Changeset: 1c280e5b8d31 Author: amurillo Date: 2012-06-15 14:17 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/1c280e5b8d31 7175515: new hotspot build - hs24-b15 Reviewed-by: jcoomes ! make/hotspot_version Changeset: e9140bf80b4a Author: coleenp Date: 2012-06-13 19:52 -0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/e9140bf80b4a 7158800: Improve storage of symbol tables Summary: Use an alternate version of hashing algorithm for symbol string tables and after a certain bucket size to improve performance Reviewed-by: pbk, kamg, dlong, kvn, fparain + src/share/vm/classfile/altHashing.cpp + src/share/vm/classfile/altHashing.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/classfile/symbolTable.hpp ! src/share/vm/memory/dump.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/init.cpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/utilities/hashtable.cpp ! src/share/vm/utilities/hashtable.hpp ! src/share/vm/utilities/hashtable.inline.hpp + test/runtime/7158800/BadUtf8.java + test/runtime/7158800/InternTest.java + test/runtime/7158800/badstrings.txt Changeset: b87e5a681416 Author: poonam Date: 2012-06-14 02:12 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/b87e5a681416 6310967: SA: jstack -m produce failures in output Summary: While looking for the sender frame check that the frame pointer should not be less than the stack pointer. Reviewed-by: dholmes, sla ! agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpot.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/amd64/BsdAMD64CFrame.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/x86/BsdX86CFrame.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/cdbg/CFrame.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/cdbg/basic/amd64/AMD64CFrame.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/cdbg/basic/x86/X86CFrame.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/amd64/LinuxAMD64CFrame.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/sparc/LinuxSPARCCFrame.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/x86/LinuxX86CFrame.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ProcCFrame.java ! agent/src/share/classes/sun/jvm/hotspot/tools/PStack.java Changeset: e16bc4ad5f20 Author: poonam Date: 2012-06-14 22:55 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/e16bc4ad5f20 Merge Changeset: 86e17e45019d Author: coleenp Date: 2012-06-15 07:51 -0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/86e17e45019d 7177307: fix fo CR7158800 doesn't contain Test7158800.sh Summary: forgot to hg add it Reviewed-by: pbk, kamg, dlong, kvn, fparain + test/runtime/7158800/Test7158800.sh Changeset: 58ad5f22317e Author: sla Date: 2012-06-18 11:33 +0200 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/58ad5f22317e Merge ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/runtime/globals.hpp Changeset: d1b0644d6acf Author: dcubed Date: 2012-06-20 14:18 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/d1b0644d6acf 7175255: symlinks are wrong, which caused jdk8-promote-2 to fail (client/64/64 directories in debuginfo zips) Summary: Fix bad paths in client/64 and server/64 debug info and symlink creation Reviewed-by: ohair, dholmes ! make/solaris/makefiles/add_gnu_debuglink.make ! make/solaris/makefiles/dtrace.make ! make/solaris/makefiles/fix_empty_sec_hdr_flags.make Changeset: 7de1d3b57419 Author: dcubed Date: 2012-06-20 14:29 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/7de1d3b57419 Merge ! make/solaris/makefiles/defs.make Changeset: cfa2c82f4c04 Author: minqi Date: 2012-06-22 15:35 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/cfa2c82f4c04 7175133: jinfo failed to get system properties after 6924259 Summary: String offset and count fields as fix of 6924259 were removed, and become optional. SA still use offset and count fields to read String contents and failed. Fix if they exist, use them other then use value field only to read, this keeps consistent with the changes in 6924259. Reviewed-by: dholmes, mikael Contributed-by: yumin.qi at oracle.com ! agent/src/share/classes/sun/jvm/hotspot/oops/OopUtilities.java Changeset: d8a240abb23a Author: minqi Date: 2012-06-22 15:39 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/d8a240abb23a 7177128: SA cannot get correct system properties after 7126277 Summary: Bug fix of 7126277 changed hashing algorithm and also changed key as final field, this led SA unable to set correct value for key. Solution by reading key/value and insert them into the new table. Reviewed-by: dholmes, mikael Contributed-by: yumin.qi at oracle.com ! agent/src/share/classes/sun/jvm/hotspot/utilities/ObjectReader.java Changeset: 588f559105c1 Author: sla Date: 2012-06-25 14:34 +0200 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/588f559105c1 7178846: IterateThroughHeap: heap_iteration_callback passes a negative size Summary: Missing cast caused integer overflow Reviewed-by: rbackman, dholmes ! src/share/vm/prims/jvmtiTagMap.cpp Changeset: 246d977b51f2 Author: coleenp Date: 2012-06-25 21:33 -0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/246d977b51f2 7178670: runtime/7158800/BadUtf8.java fails in SymbolTable::rehash_table Summary: Cannot delete _buckets and HashtableEntries in shared space (CDS) Reviewed-by: acorn, kvn, dlong, dcubed, kamg ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/classfile/symbolTable.hpp ! src/share/vm/utilities/hashtable.cpp ! src/share/vm/utilities/hashtable.hpp Changeset: 36b2d4cfcf03 Author: coleenp Date: 2012-06-25 18:59 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/36b2d4cfcf03 Merge Changeset: 74533f63b116 Author: sla Date: 2012-06-27 15:23 +0200 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/74533f63b116 7178667: ALT_EXPORT_PATH does not export server jvm on macosx Summary: Missing .PHONY targets in makefile Reviewed-by: dholmes, dsamersoff ! make/bsd/makefiles/universal.gmk Changeset: f7baf26515fc Author: collins Date: 2012-06-19 21:16 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/f7baf26515fc 7178113: build environment change Summary: Simple change to enable proper builds of arm target Reviewed-by: ohair, dholmes ! make/jprt.properties Changeset: 634b8615a6ba Author: jiangli Date: 2012-06-22 14:00 -0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/634b8615a6ba 7177409: Perf regression in JVM_GetClassDeclaredFields after generic signature changes. Summary: In fieldDescriptor::generic_signature() returns NULL immediately if the field has no generic signature. Reviewed-by: dholmes, coleenp, jcoomes ! src/share/vm/runtime/fieldDescriptor.cpp ! src/share/vm/runtime/fieldDescriptor.hpp ! src/share/vm/runtime/reflection.cpp Changeset: 06320b1578cb Author: dlong Date: 2012-06-25 15:34 -0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/06320b1578cb 7156729: PPC: R_PPC_REL24 relocation error related to some libraries built without -fPIC Summary: build powerpc with -fPIC Reviewed-by: mikael, vladidan, roland Contributed-by: dean.long at oracle.com ! make/pic.make Changeset: 7d5f65916db0 Author: bdelsart Date: 2012-06-28 04:21 -0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/7d5f65916db0 Merge Changeset: 8c92982cbbc4 Author: kvn Date: 2012-06-15 01:25 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/8c92982cbbc4 7119644: Increase superword's vector size up to 256 bits Summary: Increase vector size up to 256-bits for YMM AVX registers on x86. Reviewed-by: never, twisti, roland ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/register_x86.cpp ! src/cpu/x86/vm/register_x86.hpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vmreg_x86.cpp ! src/cpu/x86/vm/vmreg_x86.inline.hpp ! src/cpu/x86/vm/x86.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/forms.cpp ! src/share/vm/adlc/forms.hpp ! src/share/vm/adlc/formsopt.cpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/formssel.hpp ! src/share/vm/adlc/main.cpp ! src/share/vm/code/vmreg.cpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/ifg.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/opto/machnode.hpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/matcher.hpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/mulnode.hpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/opcodes.cpp ! src/share/vm/opto/opcodes.hpp ! src/share/vm/opto/postaloc.cpp ! src/share/vm/opto/reg_split.cpp ! src/share/vm/opto/regmask.cpp ! src/share/vm/opto/regmask.hpp ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/superword.hpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp ! src/share/vm/opto/vectornode.cpp ! src/share/vm/opto/vectornode.hpp ! src/share/vm/runtime/vmStructs.cpp + test/compiler/7119644/TestBooleanVect.java + test/compiler/7119644/TestByteDoubleVect.java + test/compiler/7119644/TestByteFloatVect.java + test/compiler/7119644/TestByteIntVect.java + test/compiler/7119644/TestByteLongVect.java + test/compiler/7119644/TestByteShortVect.java + test/compiler/7119644/TestByteVect.java + test/compiler/7119644/TestCharShortVect.java + test/compiler/7119644/TestCharVect.java + test/compiler/7119644/TestDoubleVect.java + test/compiler/7119644/TestFloatDoubleVect.java + test/compiler/7119644/TestFloatVect.java + test/compiler/7119644/TestIntDoubleVect.java + test/compiler/7119644/TestIntFloatVect.java + test/compiler/7119644/TestIntLongVect.java + test/compiler/7119644/TestIntVect.java + test/compiler/7119644/TestLongDoubleVect.java + test/compiler/7119644/TestLongFloatVect.java + test/compiler/7119644/TestLongVect.java + test/compiler/7119644/TestShortDoubleVect.java + test/compiler/7119644/TestShortFloatVect.java + test/compiler/7119644/TestShortIntVect.java + test/compiler/7119644/TestShortLongVect.java + test/compiler/7119644/TestShortVect.java Changeset: eeb819cf36e5 Author: roland Date: 2012-06-18 09:52 +0200 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/eeb819cf36e5 7174363: Arrays.copyOfRange leads to VM crash with -Xcomp -server if executed by testing framework Summary: Arrays.copyOfRange(original, from, to) with from > original.length tries to do a copy with a negative length. Reviewed-by: kvn, twisti ! src/share/vm/opto/library_call.cpp + test/compiler/7174363/Test7174363.java Changeset: f8de958e5b2c Author: twisti Date: 2012-06-18 12:29 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/f8de958e5b2c 7176856: add the JRE name to the error log Reviewed-by: coleenp, jrose, kvn, twisti Contributed-by: Krystal Mok ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/java.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/utilities/vmError.cpp Changeset: 765ee2d1674b Author: twisti Date: 2012-06-18 15:17 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/765ee2d1674b 7157365: jruby/bench.bench_timeout crashes with JVM internal error Reviewed-by: jrose, kvn ! src/share/vm/memory/universe.hpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/type.cpp Changeset: 6f8f439e247d Author: kvn Date: 2012-06-19 15:12 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/6f8f439e247d 7177923: SIGBUS on sparc in compiled code for java.util.Calendar.clear() Summary: disable vectorization of a memory access with more elements per vector than one which is used for alignment on sparc Reviewed-by: twisti ! src/cpu/x86/vm/x86.ad ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/superword.hpp Changeset: 40782a131183 Author: roland Date: 2012-06-21 09:52 +0200 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/40782a131183 7129715: MAC: SIGBUS in nsk stress test Summary: StackOverflowError may get lost on OSX. Reviewed-by: kvn, dcubed ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp Changeset: 424142833d10 Author: kvn Date: 2012-06-22 10:40 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/424142833d10 7178280: Failed new vector regression tests Summary: When looking for the same value in an other register check that all parts of that register has the same value. Reviewed-by: johnc, twisti ! src/share/vm/opto/postaloc.cpp Changeset: 751bd303aa45 Author: kvn Date: 2012-06-26 09:06 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/751bd303aa45 7179138: Incorrect result with String concatenation optimization Summary: check for and skip diamond shaped NULL check code for the result of toString() Reviewed-by: twisti, roland ! src/share/vm/opto/stringopts.cpp + test/compiler/7179138/Test7179138_1.java + test/compiler/7179138/Test7179138_2.java Changeset: de2f17add1fb Author: kvn Date: 2012-06-28 10:35 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/de2f17add1fb Merge Changeset: 7994a5a35fcf Author: johnc Date: 2012-06-25 16:00 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/7994a5a35fcf 6921087: G1: remove per-GC-thread expansion tables from the fine-grain remembered sets Summary: Remove the per-thread expansion tables (PosParPRT) and associated expansion and compaction from the fine grain RSet entries. This code has been unused for a while. Reviewed-by: johnc, brutisso Contributed-by: Thomas Schatzl ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp Changeset: 22de825d6faf Author: jcoomes Date: 2012-06-29 11:15 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/22de825d6faf Merge Changeset: 61a94c2da7c4 Author: coleenp Date: 2012-06-29 14:28 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/61a94c2da7c4 7179759: ENV: Nightly fails during jdk copiyng for solaris platforms after FDS unzipping Summary: libjvm_g_db.so and libjvm_g_dtrace.so links in .diz file still had 64 directory Reviewed-by: kamg, dholmes, sspitsyn ! make/solaris/makefiles/dtrace.make Changeset: 40e5a3f2907e Author: amurillo Date: 2012-06-29 17:04 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/40e5a3f2907e Merge Changeset: cf37a594c38d Author: amurillo Date: 2012-06-29 17:04 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/cf37a594c38d Added tag hs24-b15 for changeset 40e5a3f2907e ! .hgtags Changeset: aaa5e1895ff1 Author: alanb Date: 2012-07-11 18:07 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/aaa5e1895ff1 Merge ! .hgtags ! make/jprt.properties ! src/cpu/x86/vm/vm_version_x86.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/fieldDescriptor.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/reflection.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmStructs.cpp From alan.bateman at oracle.com Thu Jul 12 07:23:16 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 12 Jul 2012 14:23:16 +0000 Subject: hg: jigsaw/jigsaw/jaxp: 18 new changesets Message-ID: <20120712142401.0690447FC1@hg.openjdk.java.net> Changeset: 633700642caf Author: joehw Date: 2012-06-07 13:47 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxp/rev/633700642caf 7151118: Regressions on 7u4 b11 comp. 7u4 b06 on specjvm2008.xml.transform subbenchmark Summary: roll back XalanJ-2271 that caused the regression Reviewed-by: lancea ! src/com/sun/org/apache/xml/internal/serializer/CharInfo.java ! src/com/sun/org/apache/xml/internal/serializer/ToHTMLStream.java ! src/com/sun/org/apache/xml/internal/serializer/ToStream.java ! src/com/sun/org/apache/xml/internal/serializer/ToXMLStream.java Changeset: 238d2d0249af Author: joehw Date: 2012-06-08 11:28 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxp/rev/238d2d0249af 7157608: One feature is not recognized. Summary: adding feature standard-uri-conformant into the recognized list Reviewed-by: psandoz ! src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java Changeset: b94fad1cb830 Author: lana Date: 2012-06-08 12:01 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxp/rev/b94fad1cb830 Merge Changeset: 83a38059327b Author: erikj Date: 2012-06-07 20:30 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxp/rev/83a38059327b 7170079: Adjustments to build-infra makefiles Reviewed-by: ohair, ohrstrom, ihse, jonas Contributed-by: jonas , erikj , ihse , tgranat , ykantser ! makefiles/Makefile Changeset: eff4ece9c8bc Author: katleman Date: 2012-06-13 16:53 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxp/rev/eff4ece9c8bc Merge Changeset: 0b3f3a4ce139 Author: katleman Date: 2012-06-14 13:14 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxp/rev/0b3f3a4ce139 Added tag jdk8-b43 for changeset eff4ece9c8bc ! .hgtags Changeset: a5c1047a05e9 Author: katleman Date: 2012-06-21 17:07 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxp/rev/a5c1047a05e9 Added tag jdk8-b44 for changeset 0b3f3a4ce139 ! .hgtags Changeset: f328914a04ea Author: joehw Date: 2012-06-11 15:47 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxp/rev/f328914a04ea 7157610: NullPointerException occurs when parsing XML doc Summary: recovers what was the original disallow-doctype-decl, reporting error when disallow-doctype-decl is true, and change everything else that was added for SupportDTD to be governed by a new flag 'fSupportDTD'. Reviewed-by: lancea ! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentScannerImpl.java Changeset: 0c7f86d9ff8b Author: joehw Date: 2012-06-12 10:23 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxp/rev/0c7f86d9ff8b 7144423: StAX EventReader swallows the cause of error Summary: make sure the cause of the error is properly reported Reviewed-by: lancea, psandoz ! src/com/sun/xml/internal/stream/XMLEventReaderImpl.java Changeset: a079926a6d81 Author: lana Date: 2012-06-17 21:29 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxp/rev/a079926a6d81 Merge Changeset: 54a86b897fe8 Author: lana Date: 2012-06-25 21:37 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxp/rev/54a86b897fe8 Merge Changeset: d117133a7283 Author: joehw Date: 2012-04-10 13:59 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxp/rev/d117133a7283 7157609: Issues with loop Reviewed-by: hawtin, lancea, asaha ! src/share/classes/com/sun/org/apache/xerces/internal/impl/XMLScanner.java Changeset: 0e635b48336a Author: asaha Date: 2012-05-08 07:30 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxp/rev/0e635b48336a Merge = src/com/sun/org/apache/xerces/internal/impl/XMLScanner.java < src/share/classes/com/sun/org/apache/xerces/internal/impl/XMLScanner.java - src/share/classes/com/sun/java_cup/internal/runtime/Scanner.java - src/share/classes/com/sun/java_cup/internal/runtime/Symbol.java - src/share/classes/com/sun/java_cup/internal/runtime/lr_parser.java - src/share/classes/com/sun/java_cup/internal/runtime/virtual_parse_stack.java - src/share/classes/com/sun/org/apache/bcel/internal/Constants.java - src/share/classes/com/sun/org/apache/bcel/internal/ExceptionConstants.java - src/share/classes/com/sun/org/apache/bcel/internal/Repository.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/AccessFlags.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/Attribute.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/AttributeReader.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/ClassFormatException.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/ClassParser.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/Code.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/CodeException.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/Constant.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantCP.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantClass.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantDouble.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantFieldref.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantFloat.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantInteger.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantInterfaceMethodref.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantLong.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantMethodref.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantNameAndType.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantObject.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantPool.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantString.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantUtf8.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantValue.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/Deprecated.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/DescendingVisitor.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/EmptyVisitor.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/ExceptionTable.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/Field.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/FieldOrMethod.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/InnerClass.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/InnerClasses.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/JavaClass.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/LineNumber.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/LineNumberTable.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/LocalVariable.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/LocalVariableTable.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/Method.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/Node.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/PMGClass.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/Signature.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/SourceFile.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/StackMap.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/StackMapEntry.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/StackMapType.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/Synthetic.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/Unknown.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/Utility.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/Visitor.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/package.html - src/share/classes/com/sun/org/apache/bcel/internal/generic/AALOAD.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/AASTORE.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/ACONST_NULL.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/ALOAD.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/ANEWARRAY.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/ARETURN.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/ARRAYLENGTH.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/ASTORE.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/ATHROW.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/AllocationInstruction.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/ArithmeticInstruction.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/ArrayInstruction.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/ArrayType.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/BALOAD.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/BASTORE.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/BIPUSH.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/BREAKPOINT.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/BasicType.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/BranchHandle.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/BranchInstruction.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/CALOAD.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/CASTORE.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/CHECKCAST.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/CPInstruction.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/ClassGen.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/ClassGenException.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/ClassObserver.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/CodeExceptionGen.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/CompoundInstruction.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/ConstantPoolGen.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/ConstantPushInstruction.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/ConversionInstruction.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/D2F.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/D2I.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/D2L.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/DADD.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/DALOAD.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/DASTORE.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/DCMPG.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/DCMPL.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/DCONST.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/DDIV.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/DLOAD.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/DMUL.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/DNEG.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/DREM.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/DRETURN.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/DSTORE.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/DSUB.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/DUP.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/DUP2.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/DUP2_X1.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/DUP2_X2.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/DUP_X1.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/DUP_X2.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/EmptyVisitor.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/ExceptionThrower.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/F2D.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/F2I.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/F2L.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/FADD.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/FALOAD.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/FASTORE.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/FCMPG.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/FCMPL.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/FCONST.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/FDIV.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/FLOAD.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/FMUL.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/FNEG.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/FREM.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/FRETURN.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/FSTORE.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/FSUB.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/FieldGen.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/FieldGenOrMethodGen.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/FieldInstruction.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/FieldObserver.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/FieldOrMethod.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/GETFIELD.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/GETSTATIC.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/GOTO.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/GOTO_W.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/GotoInstruction.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/I2B.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/I2C.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/I2D.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/I2F.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/I2L.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/I2S.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/IADD.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/IALOAD.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/IAND.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/IASTORE.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/ICONST.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/IDIV.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/IFEQ.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/IFGE.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/IFGT.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/IFLE.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/IFLT.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/IFNE.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/IFNONNULL.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/IFNULL.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/IF_ACMPEQ.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/IF_ACMPNE.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/IF_ICMPEQ.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/IF_ICMPGE.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/IF_ICMPGT.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/IF_ICMPLE.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/IF_ICMPLT.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/IF_ICMPNE.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/IINC.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/ILOAD.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/IMPDEP1.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/IMPDEP2.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/IMUL.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/INEG.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/INSTANCEOF.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/INVOKEINTERFACE.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/INVOKESPECIAL.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/INVOKESTATIC.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/INVOKEVIRTUAL.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/IOR.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/IREM.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/IRETURN.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/ISHL.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/ISHR.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/ISTORE.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/ISUB.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/IUSHR.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/IXOR.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/IfInstruction.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/IndexedInstruction.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/Instruction.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/InstructionComparator.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/InstructionConstants.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/InstructionFactory.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/InstructionHandle.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/InstructionList.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/InstructionListObserver.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/InstructionTargeter.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/InvokeInstruction.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/JSR.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/JSR_W.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/JsrInstruction.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/L2D.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/L2F.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/L2I.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/LADD.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/LALOAD.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/LAND.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/LASTORE.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/LCMP.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/LCONST.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/LDC.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/LDC2_W.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/LDC_W.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/LDIV.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/LLOAD.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/LMUL.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/LNEG.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/LOOKUPSWITCH.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/LOR.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/LREM.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/LRETURN.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/LSHL.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/LSHR.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/LSTORE.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/LSUB.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/LUSHR.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/LXOR.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/LineNumberGen.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/LoadClass.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/LoadInstruction.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/LocalVariableGen.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/LocalVariableInstruction.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/MONITORENTER.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/MONITOREXIT.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/MULTIANEWARRAY.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/MethodGen.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/MethodObserver.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/NEW.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/NEWARRAY.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/NOP.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/NamedAndTyped.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/ObjectType.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/POP.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/POP2.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/PUSH.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/PUTFIELD.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/PUTSTATIC.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/PopInstruction.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/PushInstruction.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/RET.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/RETURN.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/ReferenceType.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/ReturnInstruction.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/ReturnaddressType.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/SALOAD.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/SASTORE.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/SIPUSH.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/SWAP.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/SWITCH.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/Select.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/StackConsumer.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/StackInstruction.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/StackProducer.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/StoreInstruction.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/TABLESWITCH.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/TargetLostException.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/Type.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/TypedInstruction.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/UnconditionalBranch.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/VariableLengthInstruction.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/Visitor.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/package.html - src/share/classes/com/sun/org/apache/bcel/internal/package.html - src/share/classes/com/sun/org/apache/bcel/internal/util/AttributeHTML.java - src/share/classes/com/sun/org/apache/bcel/internal/util/BCELFactory.java - src/share/classes/com/sun/org/apache/bcel/internal/util/BCELifier.java - src/share/classes/com/sun/org/apache/bcel/internal/util/ByteSequence.java - src/share/classes/com/sun/org/apache/bcel/internal/util/Class2HTML.java - src/share/classes/com/sun/org/apache/bcel/internal/util/ClassLoader.java - src/share/classes/com/sun/org/apache/bcel/internal/util/ClassLoaderRepository.java - src/share/classes/com/sun/org/apache/bcel/internal/util/ClassPath.java - src/share/classes/com/sun/org/apache/bcel/internal/util/ClassQueue.java - src/share/classes/com/sun/org/apache/bcel/internal/util/ClassSet.java - src/share/classes/com/sun/org/apache/bcel/internal/util/ClassStack.java - src/share/classes/com/sun/org/apache/bcel/internal/util/ClassVector.java - src/share/classes/com/sun/org/apache/bcel/internal/util/CodeHTML.java - src/share/classes/com/sun/org/apache/bcel/internal/util/ConstantHTML.java - src/share/classes/com/sun/org/apache/bcel/internal/util/InstructionFinder.java - src/share/classes/com/sun/org/apache/bcel/internal/util/JavaWrapper.java - src/share/classes/com/sun/org/apache/bcel/internal/util/MethodHTML.java - src/share/classes/com/sun/org/apache/bcel/internal/util/Repository.java - src/share/classes/com/sun/org/apache/bcel/internal/util/SyntheticRepository.java - src/share/classes/com/sun/org/apache/bcel/internal/util/package.html - src/share/classes/com/sun/org/apache/regexp/internal/CharacterArrayCharacterIterator.java - src/share/classes/com/sun/org/apache/regexp/internal/CharacterIterator.java - src/share/classes/com/sun/org/apache/regexp/internal/RE.java - src/share/classes/com/sun/org/apache/regexp/internal/RECompiler.java - src/share/classes/com/sun/org/apache/regexp/internal/REDebugCompiler.java - src/share/classes/com/sun/org/apache/regexp/internal/REProgram.java - src/share/classes/com/sun/org/apache/regexp/internal/RESyntaxException.java - src/share/classes/com/sun/org/apache/regexp/internal/RETest.java - src/share/classes/com/sun/org/apache/regexp/internal/REUtil.java - src/share/classes/com/sun/org/apache/regexp/internal/ReaderCharacterIterator.java - src/share/classes/com/sun/org/apache/regexp/internal/StreamCharacterIterator.java - src/share/classes/com/sun/org/apache/regexp/internal/StringCharacterIterator.java - src/share/classes/com/sun/org/apache/regexp/internal/recompile.java - src/share/classes/com/sun/org/apache/xalan/META-INF/services/javax.xml.transform.TransformerFactory - src/share/classes/com/sun/org/apache/xalan/META-INF/services/javax.xml.xpath.XPathFactory - src/share/classes/com/sun/org/apache/xalan/META-INF/services/org.apache.xml.dtm.DTMManager - src/share/classes/com/sun/org/apache/xalan/internal/Version.java - src/share/classes/com/sun/org/apache/xalan/internal/extensions/ExpressionContext.java - src/share/classes/com/sun/org/apache/xalan/internal/extensions/package.html - src/share/classes/com/sun/org/apache/xalan/internal/lib/ExsltBase.java - src/share/classes/com/sun/org/apache/xalan/internal/lib/ExsltCommon.java - src/share/classes/com/sun/org/apache/xalan/internal/lib/ExsltDatetime.java - src/share/classes/com/sun/org/apache/xalan/internal/lib/ExsltDynamic.java - src/share/classes/com/sun/org/apache/xalan/internal/lib/ExsltMath.java - src/share/classes/com/sun/org/apache/xalan/internal/lib/ExsltSets.java - src/share/classes/com/sun/org/apache/xalan/internal/lib/ExsltStrings.java - src/share/classes/com/sun/org/apache/xalan/internal/lib/Extensions.java - src/share/classes/com/sun/org/apache/xalan/internal/lib/NodeInfo.java - src/share/classes/com/sun/org/apache/xalan/internal/lib/ObjectFactory.java - src/share/classes/com/sun/org/apache/xalan/internal/lib/SecuritySupport.java - src/share/classes/com/sun/org/apache/xalan/internal/lib/SecuritySupport12.java - src/share/classes/com/sun/org/apache/xalan/internal/lib/package.html - src/share/classes/com/sun/org/apache/xalan/internal/res/XSLMessages.java - src/share/classes/com/sun/org/apache/xalan/internal/res/XSLTErrorResources.java - src/share/classes/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_de.java - src/share/classes/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_en.java - src/share/classes/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_es.java - src/share/classes/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_fr.java - src/share/classes/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_it.java - src/share/classes/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_ja.java - src/share/classes/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_ko.java - src/share/classes/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_pt_BR.java - src/share/classes/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_sv.java - src/share/classes/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_zh_CN.java - src/share/classes/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_zh_TW.java - src/share/classes/com/sun/org/apache/xalan/internal/res/XSLTInfo.properties - src/share/classes/com/sun/org/apache/xalan/internal/res/package.html - src/share/classes/com/sun/org/apache/xalan/internal/templates/Constants.java - src/share/classes/com/sun/org/apache/xalan/internal/templates/package.html - src/share/classes/com/sun/org/apache/xalan/internal/xslt/EnvironmentCheck.java - src/share/classes/com/sun/org/apache/xalan/internal/xslt/ObjectFactory.java - src/share/classes/com/sun/org/apache/xalan/internal/xslt/Process.java - src/share/classes/com/sun/org/apache/xalan/internal/xslt/SecuritySupport.java - src/share/classes/com/sun/org/apache/xalan/internal/xslt/SecuritySupport12.java - src/share/classes/com/sun/org/apache/xalan/internal/xslt/package.html - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/CollatorFactory.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/DOM.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/DOMCache.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/DOMEnhancedForDTM.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/NodeIterator.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/ProcessorVersion.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/StripFilter.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/Translet.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/TransletException.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/cmdline/Compile.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/cmdline/ObjectFactory.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/cmdline/SecuritySupport.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/cmdline/SecuritySupport12.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/cmdline/Transform.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/cmdline/getopt/GetOpt.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/cmdline/getopt/GetOptsException.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/cmdline/getopt/IllegalArgumentException.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/cmdline/getopt/MissingOptArgException.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/AbsoluteLocationPath.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/AbsolutePathPattern.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/AlternativePattern.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/AncestorPattern.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/ApplyImports.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/ApplyTemplates.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/ArgumentList.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Attribute.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/AttributeSet.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/AttributeValue.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/AttributeValueTemplate.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/BinOpExpr.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/BooleanCall.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/BooleanExpr.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/CallTemplate.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/CastCall.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/CastExpr.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/CeilingCall.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Choose.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Closure.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Comment.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/CompilerException.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/ConcatCall.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Constants.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/ContainsCall.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Copy.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/CopyOf.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/CurrentCall.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/DecimalFormatting.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/DocumentCall.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/ElementAvailableCall.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/EqualityExpr.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Expression.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Fallback.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/FilterExpr.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/FilterParentPath.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/FilteredAbsoluteLocationPath.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/FloorCall.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/FlowList.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/ForEach.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/FormatNumberCall.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/FunctionAvailableCall.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/FunctionCall.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/GenerateIdCall.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/IdKeyPattern.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/IdPattern.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/If.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/IllegalCharException.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Import.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Include.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Instruction.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/IntExpr.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Key.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/KeyCall.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/KeyPattern.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/LangCall.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/LastCall.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/LiteralAttribute.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/LiteralElement.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/LiteralExpr.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/LocalNameCall.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/LocationPathPattern.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/LogicalExpr.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Makefile.inc - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Message.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Mode.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/NameBase.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/NameCall.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/NamespaceAlias.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/NamespaceUriCall.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/NodeTest.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/NotCall.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Number.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/NumberCall.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/ObjectFactory.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Otherwise.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Output.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Param.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/ParameterRef.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/ParentLocationPath.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/ParentPattern.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Parser.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Pattern.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/PositionCall.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Predicate.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/ProcessingInstruction.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/ProcessingInstructionPattern.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/QName.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/RealExpr.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/RelationalExpr.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/RelativeLocationPath.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/RelativePathPattern.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/RoundCall.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/SecuritySupport.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/SecuritySupport12.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/SimpleAttributeValue.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Sort.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/SourceLoader.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/StartsWithCall.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Step.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/StepPattern.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/StringCall.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/StringLengthCall.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Stylesheet.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/SymbolTable.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/SyntaxTreeNode.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Template.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/TestSeq.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Text.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/TopLevelElement.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/TransletOutput.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/UnaryOpExpr.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/UnionPathExpr.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/UnparsedEntityUriCall.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/UnresolvedRef.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/UnsupportedElement.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/UseAttributeSets.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/ValueOf.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Variable.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/VariableBase.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/VariableRef.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/VariableRefBase.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/When.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Whitespace.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/WithParam.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/XPathLexer.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/XPathParser.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/XSLTC.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/XslAttribute.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/XslElement.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/sym.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/AttributeSetMethodGenerator.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/BooleanType.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ClassGenerator.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/CompareGenerator.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_ca.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_cs.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_de.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_es.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_fr.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_it.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_ja.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_ko.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_pt_BR.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_sk.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_sv.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_zh_CN.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_zh_TW.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMsg.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/FilterGenerator.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/IntType.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/MatchGenerator.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/MethodGenerator.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/MethodType.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/MultiHashtable.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/NamedMethodGenerator.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/NodeCounterGenerator.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/NodeSetType.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/NodeSortRecordFactGenerator.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/NodeSortRecordGenerator.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/NodeType.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/NumberType.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ObjectFactory.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ObjectType.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/RealType.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ReferenceType.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ResultTreeType.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/RtMethodGenerator.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/SecuritySupport.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/SecuritySupport12.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/SlotAllocator.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/StringStack.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/StringType.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/TestGenerator.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/Type.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/TypeCheckError.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/Util.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/VoidType.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/xpath.cup - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/xpath.lex - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/AbsoluteIterator.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/AdaptiveResultTreeImpl.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/AnyNodeCounter.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/BitArray.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/CachedNodeListIterator.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/ClonedNodeListIterator.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/CollatorFactoryBase.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/CurrentNodeListFilter.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/CurrentNodeListIterator.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/DOMAdapter.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/DOMBuilder.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/DOMWSFilter.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/DocumentCache.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/DupFilterIterator.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/EmptyFilter.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/ExtendedSAX.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/Filter.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/FilterIterator.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/FilteredStepIterator.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/ForwardPositionIterator.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/KeyIndex.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/LoadDocument.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/MatchingIterator.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/MultiDOM.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/MultiValuedNodeHeapIterator.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/MultipleNodeCounter.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/NodeCounter.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/NodeIteratorBase.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/NodeSortRecord.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/NodeSortRecordFactory.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/NthIterator.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/ObjectFactory.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/SAXImpl.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/SecuritySupport.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/SecuritySupport12.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/SimpleResultTreeImpl.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/SingleNodeCounter.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/SingletonIterator.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/SortSettings.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/SortingIterator.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/StepIterator.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/StripWhitespaceFilter.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/UnionIterator.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/XSLTCDTMManager.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/javax.xml.transform.TransformerFactory - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/AbstractTranslet.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/Attributes.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/BasisLibrary.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/Constants.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_ca.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_cs.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_de.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_es.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_fr.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_it.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_ja.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_ko.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_pt_BR.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_sk.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_sv.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_zh_CN.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_zh_TW.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/Hashtable.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/MessageHandler.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/Node.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/ObjectFactory.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/Operators.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/Parameter.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/SecuritySupport.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/SecuritySupport12.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/StringValueHandler.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/output/OutputBuffer.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/output/StringOutputBuffer.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/output/TransletOutputHandlerFactory.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/output/WriterOutputBuffer.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/DOM2SAX.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/DOM2TO.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/ObjectFactory.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/OutputSettings.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/SAX2DOM.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/SAX2StAXBaseWriter.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/SAX2StAXEventWriter.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/SAX2StAXStreamWriter.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/SecuritySupport.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/SecuritySupport12.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/SmartTransformerFactoryImpl.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/StAXEvent2SAX.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/StAXStream2SAX.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesHandlerImpl.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesImpl.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TrAXFilter.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerFactoryImpl.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerHandlerImpl.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerImpl.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/Util.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/XSLTCSource.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/util/IntegerArray.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/AttrImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/AttrNSImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/AttributeMap.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/CDATASectionImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/CharacterDataImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/ChildNode.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/CommentImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/CoreDOMImplementationImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/CoreDocumentImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/DOMConfigurationImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/DOMErrorImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/DOMImplementationImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/DOMImplementationListImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/DOMImplementationSourceImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/DOMInputImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/DOMLocatorImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/DOMMessageFormatter.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/DOMNormalizer.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/DOMOutputImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/DOMStringListImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/DOMXSImplementationSourceImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/DeepNodeListImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/DeferredAttrImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/DeferredAttrNSImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/DeferredCDATASectionImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/DeferredCommentImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/DeferredDOMImplementationImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/DeferredDocumentImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/DeferredDocumentTypeImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/DeferredElementDefinitionImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/DeferredElementImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/DeferredElementNSImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/DeferredEntityImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/DeferredEntityReferenceImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/DeferredNode.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/DeferredNotationImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/DeferredProcessingInstructionImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/DeferredTextImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/DocumentFragmentImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/DocumentImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/DocumentTypeImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/ElementDefinitionImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/ElementImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/ElementNSImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/EntityImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/EntityReferenceImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/LCount.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/NamedNodeMapImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/NodeImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/NodeIteratorImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/NodeListCache.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/NotationImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/ObjectFactory.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/PSVIAttrNSImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/PSVIDOMImplementationImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/PSVIDocumentImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/PSVIElementNSImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/ParentNode.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/ProcessingInstructionImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/RangeExceptionImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/RangeImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/SecuritySupport.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/TextImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/TreeWalkerImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/events/EventImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/events/MutationEventImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/org.apache.xerces.dom.DOMImplementationSourceImpl - src/share/classes/com/sun/org/apache/xerces/internal/dom/org.w3c.dom.DOMImplementationSourceList - src/share/classes/com/sun/org/apache/xerces/internal/impl/Constants.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/ExternalSubsetResolver.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/PropertyManager.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/RevalidationHandler.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/Version.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/XML11DTDScannerImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/XML11DocumentScannerImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/XML11EntityScanner.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/XML11NSDocumentScannerImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/XML11NamespaceBinder.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/XMLDTDScannerImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/XMLDocumentScannerImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/XMLEntityDescription.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/XMLEntityHandler.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/XMLEntityScanner.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/XMLErrorReporter.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/XMLNSDocumentScannerImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/XMLNamespaceBinder.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/XMLStreamFilterImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/XMLStreamReaderImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/XMLVersionDetector.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/BalancedDTDGrammar.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/DTDGrammar.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/DTDGrammarBucket.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/XML11DTDProcessor.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/XML11DTDValidator.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/XML11NSDTDValidator.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/XMLAttributeDecl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/XMLContentSpec.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/XMLDTDDescription.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/XMLDTDLoader.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/XMLDTDProcessor.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/XMLDTDValidator.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/XMLDTDValidatorFilter.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/XMLElementDecl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/XMLEntityDecl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/XMLNSDTDValidator.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/XMLNotationDecl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/XMLSimpleType.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/models/CMAny.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/models/CMBinOp.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/models/CMLeaf.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/models/CMNode.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/models/CMStateSet.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/models/CMUniOp.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/models/ContentModelValidator.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/models/DFAContentModel.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/models/MixedContentModel.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/models/SimpleContentModel.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/DTDDVFactory.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/DVFactoryException.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/DatatypeException.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/DatatypeValidator.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/InvalidDatatypeFacetException.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/InvalidDatatypeValueException.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/ObjectFactory.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/SchemaDVFactory.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/SecuritySupport.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/ValidatedInfo.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/ValidationContext.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/XSFacets.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/XSSimpleType.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/dtd/DTDDVFactoryImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/dtd/ENTITYDatatypeValidator.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/dtd/IDDatatypeValidator.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/dtd/IDREFDatatypeValidator.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/dtd/ListDatatypeValidator.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/dtd/NMTOKENDatatypeValidator.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/dtd/NOTATIONDatatypeValidator.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/dtd/StringDatatypeValidator.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/dtd/XML11DTDDVFactoryImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/dtd/XML11IDDatatypeValidator.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/dtd/XML11IDREFDatatypeValidator.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/dtd/XML11NMTOKENDatatypeValidator.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/util/Base64.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/util/ByteListImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/util/HexBin.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/AbstractDateTimeDV.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/AnyAtomicDV.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/AnySimpleDV.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/AnyURIDV.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/Base64BinaryDV.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/BaseDVFactory.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/BaseSchemaDVFactory.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/BooleanDV.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/DateDV.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/DateTimeDV.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/DayDV.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/DayTimeDurationDV.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/DecimalDV.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/DoubleDV.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/DurationDV.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/EntityDV.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/ExtendedSchemaDVFactoryImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/FloatDV.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/FullDVFactory.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/HexBinaryDV.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/IDDV.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/IDREFDV.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/IntegerDV.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/ListDV.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/MonthDV.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/MonthDayDV.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/PrecisionDecimalDV.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/QNameDV.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/SchemaDVFactoryImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/SchemaDateTimeException.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/StringDV.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/TimeDV.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/TypeValidator.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/UnionDV.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/XSSimpleTypeDecl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/XSSimpleTypeDelegate.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/YearDV.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/YearMonthDV.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/YearMonthDurationDV.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/io/ASCIIReader.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/io/MalformedByteSequenceException.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/io/UCSReader.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/io/UTF8Reader.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_de.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_es.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_fr.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_it.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_ja.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_ko.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_pt_BR.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_sv.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_zh_CN.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_zh_TW.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_de.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_es.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_fr.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_it.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_ja.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_ko.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_pt_BR.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_sv.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_zh_CN.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_zh_TW.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_de.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_es.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_fr.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_it.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_ja.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_ko.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_pt_BR.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_sv.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_zh_CN.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_zh_TW.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_de.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_es.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_fr.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_it.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_ja.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_ko.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_pt_BR.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_sv.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_zh_CN.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_zh_TW.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_de.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_es.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_fr.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_it.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_ja.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_ko.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_pt_BR.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_sv.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_zh_CN.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_zh_TW.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_de.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_es.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_fr.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_it.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_ja.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_ko.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_pt_BR.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_sv.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_zh_CN.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_zh_TW.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_de.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_es.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_fr.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_it.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ja.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ko.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_pt_BR.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_sv.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_zh_CN.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_zh_TW.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_de.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_es.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_fr.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_it.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_ja.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_ko.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_pt_BR.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_sv.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_zh_CN.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_zh_TW.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_de.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_es.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_fr.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_it.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_ja.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_ko.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_pt_BR.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_sv.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_zh_CN.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_zh_TW.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_de.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_es.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_fr.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_it.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_ja.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_ko.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_pt_BR.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_sv.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_zh_CN.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_zh_TW.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/validation/EntityState.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/validation/ValidationManager.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/validation/ValidationState.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xpath/XPath.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xpath/XPathException.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xpath/regex/BMPattern.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xpath/regex/CaseInsensitiveMap.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xpath/regex/Match.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xpath/regex/Op.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xpath/regex/ParseException.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xpath/regex/ParserForXMLSchema.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xpath/regex/REUtil.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xpath/regex/RangeToken.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xpath/regex/RegexParser.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xpath/regex/RegularExpression.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xpath/regex/Token.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xpath/regex/message.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/xpath/regex/message_fr.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/xpath/regex/message_ja.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/AttributePSVImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/ElementPSVImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/SchemaGrammar.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/SchemaNamespaceSupport.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/SchemaSymbols.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/SubstitutionGroupHandler.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/XMLSchemaException.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/XMLSchemaLoader.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/XMLSchemaValidator.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/XSAnnotationImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/XSAttributeDecl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/XSAttributeGroupDecl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/XSAttributeUseImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/XSComplexTypeDecl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/XSConstraints.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/XSDDescription.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/XSDeclarationPool.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/XSElementDecl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/XSGrammarBucket.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/XSGroupDecl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/XSImplementationImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/XSLoaderImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/XSMessageFormatter.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/XSModelGroupImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/XSModelImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/XSNotationDecl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/XSParticleDecl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/XSWildcardDecl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/identity/Field.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/identity/FieldActivator.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/identity/IdentityConstraint.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/identity/KeyRef.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/identity/Selector.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/identity/UniqueOrKey.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/identity/ValueStore.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/identity/XPathMatcher.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/models/CMBuilder.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/models/CMNodeFactory.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/models/XSAllCM.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/models/XSCMBinOp.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/models/XSCMLeaf.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/models/XSCMRepeatingLeaf.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/models/XSCMUniOp.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/models/XSCMValidator.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/models/XSDFACM.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/models/XSEmptyCM.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/opti/AttrImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/opti/DefaultDocument.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/opti/DefaultElement.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/opti/DefaultNode.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/opti/DefaultText.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/opti/DefaultXMLDocumentHandler.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/opti/ElementImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/opti/NamedNodeMapImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/opti/NodeImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/opti/SchemaDOM.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/opti/SchemaDOMImplementation.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/opti/SchemaDOMParser.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/opti/SchemaParsingConfig.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/opti/TextImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/SchemaContentHandler.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/StAXSchemaParser.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSAnnotationInfo.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSAttributeChecker.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDAbstractIDConstraintTraverser.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDAbstractParticleTraverser.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDAbstractTraverser.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDAttributeGroupTraverser.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDAttributeTraverser.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDComplexTypeTraverser.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDElementTraverser.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDGroupTraverser.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDHandler.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDKeyrefTraverser.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDNotationTraverser.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDSimpleTypeTraverser.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDUniqueOrKeyTraverser.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDWildcardTraverser.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDocumentInfo.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/util/LSInputListImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/util/ObjectListImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/util/ShortListImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/util/SimpleLocator.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/util/StringListImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/util/XInt.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/util/XIntPool.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/util/XSGrammarPool.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/util/XSInputSource.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/util/XSNamedMap4Types.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/util/XSNamedMapImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/util/XSObjectListImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/DefaultValidationErrorHandler.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/DocumentBuilderFactoryImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/DocumentBuilderImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/JAXPConstants.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/JAXPValidatorComponent.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/SAXParserFactoryImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/SAXParserImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/SchemaValidatorConfiguration.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/TeeXMLDocumentFilterImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/UnparsedEntityHandler.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/datatype/DatatypeFactoryImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/datatype/DurationDayTimeImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/datatype/DurationImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/datatype/DurationYearMonthImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/datatype/XMLGregorianCalendarImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/datatype/javax.xml.datatype.DatatypeFactory - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/javax.xml.parsers.DocumentBuilderFactory - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/javax.xml.parsers.SAXParserFactory - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/AbstractXMLSchema.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/DOMDocumentHandler.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/DOMResultAugmentor.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/DOMResultBuilder.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/DOMValidatorHelper.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/DraconianErrorHandler.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/EmptyXMLSchema.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/ErrorHandlerAdaptor.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/JAXPValidationMessageFormatter.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/ReadOnlyGrammarPool.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/SimpleXMLSchema.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/SoftReferenceGrammarPool.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/StAXValidatorHelper.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/StreamValidatorHelper.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/Util.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/ValidatorHandlerImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/ValidatorHelper.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/ValidatorImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/WeakReferenceXMLSchema.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/WrappedSAXException.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchema.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaFactory.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaValidatorComponentManager.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/XSGrammarPoolContainer.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/javax.xml.validation.SchemaFactory - src/share/classes/com/sun/org/apache/xerces/internal/parsers/AbstractDOMParser.java - src/share/classes/com/sun/org/apache/xerces/internal/parsers/AbstractSAXParser.java - src/share/classes/com/sun/org/apache/xerces/internal/parsers/AbstractXMLDocumentParser.java - src/share/classes/com/sun/org/apache/xerces/internal/parsers/BasicParserConfiguration.java - src/share/classes/com/sun/org/apache/xerces/internal/parsers/CachingParserPool.java - src/share/classes/com/sun/org/apache/xerces/internal/parsers/DOMParser.java - src/share/classes/com/sun/org/apache/xerces/internal/parsers/DOMParserImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/parsers/DTDConfiguration.java - src/share/classes/com/sun/org/apache/xerces/internal/parsers/DTDParser.java - src/share/classes/com/sun/org/apache/xerces/internal/parsers/IntegratedParserConfiguration.java - src/share/classes/com/sun/org/apache/xerces/internal/parsers/NonValidatingConfiguration.java - src/share/classes/com/sun/org/apache/xerces/internal/parsers/ObjectFactory.java - src/share/classes/com/sun/org/apache/xerces/internal/parsers/SAXParser.java - src/share/classes/com/sun/org/apache/xerces/internal/parsers/SecurityConfiguration.java - src/share/classes/com/sun/org/apache/xerces/internal/parsers/SecuritySupport.java - src/share/classes/com/sun/org/apache/xerces/internal/parsers/StandardParserConfiguration.java - src/share/classes/com/sun/org/apache/xerces/internal/parsers/XIncludeAwareParserConfiguration.java - src/share/classes/com/sun/org/apache/xerces/internal/parsers/XIncludeParserConfiguration.java - src/share/classes/com/sun/org/apache/xerces/internal/parsers/XML11Configurable.java - src/share/classes/com/sun/org/apache/xerces/internal/parsers/XML11Configuration.java - src/share/classes/com/sun/org/apache/xerces/internal/parsers/XML11DTDConfiguration.java - src/share/classes/com/sun/org/apache/xerces/internal/parsers/XML11NonValidatingConfiguration.java - src/share/classes/com/sun/org/apache/xerces/internal/parsers/XMLDocumentParser.java - src/share/classes/com/sun/org/apache/xerces/internal/parsers/XMLGrammarCachingConfiguration.java - src/share/classes/com/sun/org/apache/xerces/internal/parsers/XMLGrammarParser.java - src/share/classes/com/sun/org/apache/xerces/internal/parsers/XMLGrammarPreparser.java - src/share/classes/com/sun/org/apache/xerces/internal/parsers/XMLParser.java - src/share/classes/com/sun/org/apache/xerces/internal/parsers/XPointerParserConfiguration.java - src/share/classes/com/sun/org/apache/xerces/internal/parsers/org.apache.xerces.xni.parser.DTDConfiguration - src/share/classes/com/sun/org/apache/xerces/internal/parsers/org.apache.xerces.xni.parser.XML11Configuration - src/share/classes/com/sun/org/apache/xerces/internal/parsers/org.apache.xerces.xni.parser.XMLParserConfiguration - src/share/classes/com/sun/org/apache/xerces/internal/parsers/org.xml.sax.driver - src/share/classes/com/sun/org/apache/xerces/internal/util/AttributesProxy.java - src/share/classes/com/sun/org/apache/xerces/internal/util/AugmentationsImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/util/DOMEntityResolverWrapper.java - src/share/classes/com/sun/org/apache/xerces/internal/util/DOMErrorHandlerWrapper.java - src/share/classes/com/sun/org/apache/xerces/internal/util/DOMInputSource.java - src/share/classes/com/sun/org/apache/xerces/internal/util/DOMUtil.java - src/share/classes/com/sun/org/apache/xerces/internal/util/DatatypeMessageFormatter.java - src/share/classes/com/sun/org/apache/xerces/internal/util/DefaultErrorHandler.java - src/share/classes/com/sun/org/apache/xerces/internal/util/DraconianErrorHandler.java - src/share/classes/com/sun/org/apache/xerces/internal/util/EncodingMap.java - src/share/classes/com/sun/org/apache/xerces/internal/util/EntityResolver2Wrapper.java - src/share/classes/com/sun/org/apache/xerces/internal/util/EntityResolverWrapper.java - src/share/classes/com/sun/org/apache/xerces/internal/util/ErrorHandlerProxy.java - src/share/classes/com/sun/org/apache/xerces/internal/util/ErrorHandlerWrapper.java - src/share/classes/com/sun/org/apache/xerces/internal/util/FeatureState.java - src/share/classes/com/sun/org/apache/xerces/internal/util/HTTPInputSource.java - src/share/classes/com/sun/org/apache/xerces/internal/util/IntStack.java - src/share/classes/com/sun/org/apache/xerces/internal/util/JAXPNamespaceContextWrapper.java - src/share/classes/com/sun/org/apache/xerces/internal/util/LocatorProxy.java - src/share/classes/com/sun/org/apache/xerces/internal/util/LocatorWrapper.java - src/share/classes/com/sun/org/apache/xerces/internal/util/MessageFormatter.java - src/share/classes/com/sun/org/apache/xerces/internal/util/NamespaceContextWrapper.java - src/share/classes/com/sun/org/apache/xerces/internal/util/NamespaceSupport.java - src/share/classes/com/sun/org/apache/xerces/internal/util/ParserConfigurationSettings.java - src/share/classes/com/sun/org/apache/xerces/internal/util/PropertyState.java - src/share/classes/com/sun/org/apache/xerces/internal/util/SAX2XNI.java - src/share/classes/com/sun/org/apache/xerces/internal/util/SAXInputSource.java - src/share/classes/com/sun/org/apache/xerces/internal/util/SAXLocatorWrapper.java - src/share/classes/com/sun/org/apache/xerces/internal/util/SAXMessageFormatter.java - src/share/classes/com/sun/org/apache/xerces/internal/util/SecurityManager.java - src/share/classes/com/sun/org/apache/xerces/internal/util/ShadowedSymbolTable.java - src/share/classes/com/sun/org/apache/xerces/internal/util/StAXInputSource.java - src/share/classes/com/sun/org/apache/xerces/internal/util/StAXLocationWrapper.java - src/share/classes/com/sun/org/apache/xerces/internal/util/Status.java - src/share/classes/com/sun/org/apache/xerces/internal/util/SymbolHash.java - src/share/classes/com/sun/org/apache/xerces/internal/util/SymbolTable.java - src/share/classes/com/sun/org/apache/xerces/internal/util/SynchronizedSymbolTable.java - src/share/classes/com/sun/org/apache/xerces/internal/util/TeeXMLDocumentFilterImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/util/TypeInfoImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/util/URI.java - src/share/classes/com/sun/org/apache/xerces/internal/util/XML11Char.java - src/share/classes/com/sun/org/apache/xerces/internal/util/XMLAttributesImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/util/XMLAttributesIteratorImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/util/XMLCatalogResolver.java - src/share/classes/com/sun/org/apache/xerces/internal/util/XMLChar.java - src/share/classes/com/sun/org/apache/xerces/internal/util/XMLDocumentFilterImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/util/XMLEntityDescriptionImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/util/XMLErrorCode.java - src/share/classes/com/sun/org/apache/xerces/internal/util/XMLGrammarPoolImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/util/XMLInputSourceAdaptor.java - src/share/classes/com/sun/org/apache/xerces/internal/util/XMLResourceIdentifierImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/util/XMLStringBuffer.java - src/share/classes/com/sun/org/apache/xerces/internal/util/XMLSymbols.java - src/share/classes/com/sun/org/apache/xerces/internal/xinclude/MultipleScopeNamespaceSupport.java - src/share/classes/com/sun/org/apache/xerces/internal/xinclude/ObjectFactory.java - src/share/classes/com/sun/org/apache/xerces/internal/xinclude/SecuritySupport.java - src/share/classes/com/sun/org/apache/xerces/internal/xinclude/XInclude11TextReader.java - src/share/classes/com/sun/org/apache/xerces/internal/xinclude/XIncludeHandler.java - src/share/classes/com/sun/org/apache/xerces/internal/xinclude/XIncludeMessageFormatter.java - src/share/classes/com/sun/org/apache/xerces/internal/xinclude/XIncludeNamespaceSupport.java - src/share/classes/com/sun/org/apache/xerces/internal/xinclude/XIncludeTextReader.java - src/share/classes/com/sun/org/apache/xerces/internal/xinclude/XPointerElementHandler.java - src/share/classes/com/sun/org/apache/xerces/internal/xinclude/XPointerFramework.java - src/share/classes/com/sun/org/apache/xerces/internal/xinclude/XPointerSchema.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/Augmentations.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/NamespaceContext.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/QName.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/XMLAttributes.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/XMLDTDContentModelHandler.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/XMLDTDHandler.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/XMLDocumentFragmentHandler.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/XMLDocumentHandler.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/XMLLocator.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/XMLResourceIdentifier.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/XMLString.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/XNIException.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/grammars/Grammar.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/grammars/XMLDTDDescription.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/grammars/XMLGrammarDescription.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/grammars/XMLGrammarLoader.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/grammars/XMLGrammarPool.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/grammars/XMLSchemaDescription.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/grammars/XSGrammar.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/parser/XMLComponent.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/parser/XMLComponentManager.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/parser/XMLConfigurationException.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/parser/XMLDTDContentModelFilter.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/parser/XMLDTDContentModelSource.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/parser/XMLDTDFilter.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/parser/XMLDTDScanner.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/parser/XMLDTDSource.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/parser/XMLDocumentFilter.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/parser/XMLDocumentScanner.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/parser/XMLDocumentSource.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/parser/XMLEntityResolver.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/parser/XMLErrorHandler.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/parser/XMLInputSource.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/parser/XMLParseException.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/parser/XMLParserConfiguration.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/parser/XMLPullParserConfiguration.java - src/share/classes/com/sun/org/apache/xerces/internal/xpointer/ElementSchemePointer.java - src/share/classes/com/sun/org/apache/xerces/internal/xpointer/ShortHandPointer.java - src/share/classes/com/sun/org/apache/xerces/internal/xpointer/XPointerErrorHandler.java - src/share/classes/com/sun/org/apache/xerces/internal/xpointer/XPointerHandler.java - src/share/classes/com/sun/org/apache/xerces/internal/xpointer/XPointerMessageFormatter.java - src/share/classes/com/sun/org/apache/xerces/internal/xpointer/XPointerPart.java - src/share/classes/com/sun/org/apache/xerces/internal/xpointer/XPointerProcessor.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/AttributePSVI.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/ElementPSVI.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/ItemPSVI.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/LSInputList.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/PSVIProvider.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/ShortList.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/StringList.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/XSAnnotation.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/XSAttributeDeclaration.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/XSAttributeGroupDefinition.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/XSAttributeUse.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/XSComplexTypeDefinition.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/XSConstants.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/XSElementDeclaration.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/XSException.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/XSFacet.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/XSIDCDefinition.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/XSImplementation.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/XSLoader.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/XSModel.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/XSModelGroup.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/XSModelGroupDefinition.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/XSMultiValueFacet.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/XSNamedMap.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/XSNamespaceItem.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/XSNamespaceItemList.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/XSNotationDeclaration.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/XSObject.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/XSObjectList.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/XSParticle.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/XSSimpleTypeDefinition.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/XSTerm.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/XSTypeDefinition.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/XSWildcard.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/datatypes/ByteList.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/datatypes/ObjectList.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/datatypes/XSDateTime.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/datatypes/XSDecimal.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/datatypes/XSDouble.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/datatypes/XSFloat.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/datatypes/XSQName.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/datatypes/package.html - src/share/classes/com/sun/org/apache/xml/internal/dtm/Axis.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/DTM.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/DTMAxisIterator.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/DTMAxisTraverser.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/DTMConfigurationException.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/DTMDOMException.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/DTMException.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/DTMFilter.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/DTMIterator.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/DTMManager.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/DTMWSFilter.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ObjectFactory.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/SecuritySupport.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/SecuritySupport12.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/ChunkedIntArray.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/CoroutineManager.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/CoroutineParser.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/CustomStringPool.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/DTMAxisIterNodeList.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/DTMAxisIteratorBase.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/DTMChildIterNodeList.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/DTMDefaultBase.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/DTMDefaultBaseIterators.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/DTMDefaultBaseTraversers.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/DTMDocumentImpl.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/DTMManagerDefault.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/DTMNamedNodeMap.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/DTMNodeIterator.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/DTMNodeList.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/DTMNodeListBase.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/DTMNodeProxy.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/DTMSafeStringPool.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/DTMStringPool.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/DTMTreeWalker.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/EmptyIterator.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/ExpandedNameTable.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/ExtendedType.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/IncrementalSAXSource.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/IncrementalSAXSource_Filter.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/IncrementalSAXSource_Xerces.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/NodeLocator.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/ObjectFactory.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/SecuritySupport.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/SecuritySupport12.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/dom2dtm/DOM2DTM.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/dom2dtm/DOM2DTMdefaultNamespaceDeclarationNode.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/sax2dtm/SAX2DTM.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/sax2dtm/SAX2DTM2.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/sax2dtm/SAX2RTFDTM.java - src/share/classes/com/sun/org/apache/xml/internal/res/XMLErrorResources.java - src/share/classes/com/sun/org/apache/xml/internal/res/XMLErrorResources_ca.java - src/share/classes/com/sun/org/apache/xml/internal/res/XMLErrorResources_cs.java - src/share/classes/com/sun/org/apache/xml/internal/res/XMLErrorResources_de.java - src/share/classes/com/sun/org/apache/xml/internal/res/XMLErrorResources_en.java - src/share/classes/com/sun/org/apache/xml/internal/res/XMLErrorResources_es.java - src/share/classes/com/sun/org/apache/xml/internal/res/XMLErrorResources_fr.java - src/share/classes/com/sun/org/apache/xml/internal/res/XMLErrorResources_it.java - src/share/classes/com/sun/org/apache/xml/internal/res/XMLErrorResources_ja.java - src/share/classes/com/sun/org/apache/xml/internal/res/XMLErrorResources_ko.java - src/share/classes/com/sun/org/apache/xml/internal/res/XMLErrorResources_pt_BR.java - src/share/classes/com/sun/org/apache/xml/internal/res/XMLErrorResources_sk.java - src/share/classes/com/sun/org/apache/xml/internal/res/XMLErrorResources_sv.java - src/share/classes/com/sun/org/apache/xml/internal/res/XMLErrorResources_tr.java - src/share/classes/com/sun/org/apache/xml/internal/res/XMLErrorResources_zh_CN.java - src/share/classes/com/sun/org/apache/xml/internal/res/XMLErrorResources_zh_HK.java - src/share/classes/com/sun/org/apache/xml/internal/res/XMLErrorResources_zh_TW.java - src/share/classes/com/sun/org/apache/xml/internal/res/XMLMessages.java - src/share/classes/com/sun/org/apache/xml/internal/resolver/Catalog.java - src/share/classes/com/sun/org/apache/xml/internal/resolver/CatalogEntry.java - src/share/classes/com/sun/org/apache/xml/internal/resolver/CatalogException.java - src/share/classes/com/sun/org/apache/xml/internal/resolver/CatalogManager.java - src/share/classes/com/sun/org/apache/xml/internal/resolver/Resolver.java - src/share/classes/com/sun/org/apache/xml/internal/resolver/helpers/BootstrapResolver.java - src/share/classes/com/sun/org/apache/xml/internal/resolver/helpers/Debug.java - src/share/classes/com/sun/org/apache/xml/internal/resolver/helpers/FileURL.java - src/share/classes/com/sun/org/apache/xml/internal/resolver/helpers/Namespaces.java - src/share/classes/com/sun/org/apache/xml/internal/resolver/helpers/PublicId.java - src/share/classes/com/sun/org/apache/xml/internal/resolver/readers/CatalogReader.java - src/share/classes/com/sun/org/apache/xml/internal/resolver/readers/DOMCatalogParser.java - src/share/classes/com/sun/org/apache/xml/internal/resolver/readers/DOMCatalogReader.java - src/share/classes/com/sun/org/apache/xml/internal/resolver/readers/ExtendedXMLCatalogReader.java - src/share/classes/com/sun/org/apache/xml/internal/resolver/readers/OASISXMLCatalogReader.java - src/share/classes/com/sun/org/apache/xml/internal/resolver/readers/SAXCatalogParser.java - src/share/classes/com/sun/org/apache/xml/internal/resolver/readers/SAXCatalogReader.java - src/share/classes/com/sun/org/apache/xml/internal/resolver/readers/SAXParserHandler.java - src/share/classes/com/sun/org/apache/xml/internal/resolver/readers/TR9401CatalogReader.java - src/share/classes/com/sun/org/apache/xml/internal/resolver/readers/TextCatalogReader.java - src/share/classes/com/sun/org/apache/xml/internal/resolver/readers/XCatalogReader.java - src/share/classes/com/sun/org/apache/xml/internal/resolver/tools/CatalogResolver.java - src/share/classes/com/sun/org/apache/xml/internal/resolver/tools/ResolvingParser.java - src/share/classes/com/sun/org/apache/xml/internal/resolver/tools/ResolvingXMLFilter.java - src/share/classes/com/sun/org/apache/xml/internal/resolver/tools/ResolvingXMLReader.java - src/share/classes/com/sun/org/apache/xml/internal/serialize/BaseMarkupSerializer.java - src/share/classes/com/sun/org/apache/xml/internal/serialize/DOMSerializer.java - src/share/classes/com/sun/org/apache/xml/internal/serialize/DOMSerializerImpl.java - src/share/classes/com/sun/org/apache/xml/internal/serialize/ElementState.java - src/share/classes/com/sun/org/apache/xml/internal/serialize/EncodingInfo.java - src/share/classes/com/sun/org/apache/xml/internal/serialize/Encodings.java - src/share/classes/com/sun/org/apache/xml/internal/serialize/HTMLEntities.res - src/share/classes/com/sun/org/apache/xml/internal/serialize/HTMLSerializer.java - src/share/classes/com/sun/org/apache/xml/internal/serialize/HTMLdtd.java - src/share/classes/com/sun/org/apache/xml/internal/serialize/IndentPrinter.java - src/share/classes/com/sun/org/apache/xml/internal/serialize/LineSeparator.java - src/share/classes/com/sun/org/apache/xml/internal/serialize/Method.java - src/share/classes/com/sun/org/apache/xml/internal/serialize/ObjectFactory.java - src/share/classes/com/sun/org/apache/xml/internal/serialize/OutputFormat.java - src/share/classes/com/sun/org/apache/xml/internal/serialize/Printer.java - src/share/classes/com/sun/org/apache/xml/internal/serialize/SecuritySupport.java - src/share/classes/com/sun/org/apache/xml/internal/serialize/Serializer.java - src/share/classes/com/sun/org/apache/xml/internal/serialize/SerializerFactory.java - src/share/classes/com/sun/org/apache/xml/internal/serialize/SerializerFactoryImpl.java - src/share/classes/com/sun/org/apache/xml/internal/serialize/TextSerializer.java - src/share/classes/com/sun/org/apache/xml/internal/serialize/XHTMLSerializer.java - src/share/classes/com/sun/org/apache/xml/internal/serialize/XML11Serializer.java - src/share/classes/com/sun/org/apache/xml/internal/serialize/XMLSerializer.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/AttributesImplSerializer.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/CharInfo.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/DOMSerializer.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/ElemContext.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/ElemDesc.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/EmptySerializer.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/EncodingInfo.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/Encodings.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/Encodings.properties - src/share/classes/com/sun/org/apache/xml/internal/serializer/ExtendedContentHandler.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/ExtendedLexicalHandler.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/HTMLEntities.properties - src/share/classes/com/sun/org/apache/xml/internal/serializer/Method.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/NamespaceMappings.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/ObjectFactory.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/OutputPropertiesFactory.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/OutputPropertyUtils.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/SecuritySupport.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/SecuritySupport12.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/SerializationHandler.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/Serializer.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/SerializerBase.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/SerializerConstants.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/SerializerFactory.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/SerializerTrace.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/SerializerTraceWriter.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/ToHTMLSAXHandler.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/ToHTMLStream.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/ToSAXHandler.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/ToStream.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/ToTextSAXHandler.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/ToTextStream.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/ToUnknownStream.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/ToXMLSAXHandler.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/ToXMLStream.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/TransformStateSetter.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/TreeWalker.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/Utils.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/Version.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/WriterChain.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/WriterToASCI.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/WriterToUTF8Buffered.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/XMLEntities.properties - src/share/classes/com/sun/org/apache/xml/internal/serializer/XSLOutputAttributes.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/output_html.properties - src/share/classes/com/sun/org/apache/xml/internal/serializer/output_text.properties - src/share/classes/com/sun/org/apache/xml/internal/serializer/output_unknown.properties - src/share/classes/com/sun/org/apache/xml/internal/serializer/output_xml.properties - src/share/classes/com/sun/org/apache/xml/internal/serializer/package.html - src/share/classes/com/sun/org/apache/xml/internal/serializer/utils/AttList.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/utils/BoolStack.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/utils/DOM2Helper.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/utils/Messages.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/utils/MsgKey.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_ca.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_cs.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_de.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_en.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_es.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_fr.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_it.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_ja.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_ko.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_sv.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_zh_CN.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_zh_TW.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/utils/StringToIntTable.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/utils/SystemIDResolver.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/utils/URI.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/utils/Utils.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/utils/WrappedRuntimeException.java - src/share/classes/com/sun/org/apache/xml/internal/utils/AttList.java - src/share/classes/com/sun/org/apache/xml/internal/utils/BoolStack.java - src/share/classes/com/sun/org/apache/xml/internal/utils/CharKey.java - src/share/classes/com/sun/org/apache/xml/internal/utils/Constants.java - src/share/classes/com/sun/org/apache/xml/internal/utils/DOM2Helper.java - src/share/classes/com/sun/org/apache/xml/internal/utils/DOMBuilder.java - src/share/classes/com/sun/org/apache/xml/internal/utils/DOMHelper.java - src/share/classes/com/sun/org/apache/xml/internal/utils/DOMOrder.java - src/share/classes/com/sun/org/apache/xml/internal/utils/DefaultErrorHandler.java - src/share/classes/com/sun/org/apache/xml/internal/utils/ElemDesc.java - src/share/classes/com/sun/org/apache/xml/internal/utils/FastStringBuffer.java - src/share/classes/com/sun/org/apache/xml/internal/utils/Hashtree2Node.java - src/share/classes/com/sun/org/apache/xml/internal/utils/IntStack.java - src/share/classes/com/sun/org/apache/xml/internal/utils/IntVector.java - src/share/classes/com/sun/org/apache/xml/internal/utils/ListingErrorHandler.java - src/share/classes/com/sun/org/apache/xml/internal/utils/LocaleUtility.java - src/share/classes/com/sun/org/apache/xml/internal/utils/MutableAttrListImpl.java - src/share/classes/com/sun/org/apache/xml/internal/utils/NSInfo.java - src/share/classes/com/sun/org/apache/xml/internal/utils/NameSpace.java - src/share/classes/com/sun/org/apache/xml/internal/utils/NamespaceSupport2.java - src/share/classes/com/sun/org/apache/xml/internal/utils/NodeConsumer.java - src/share/classes/com/sun/org/apache/xml/internal/utils/NodeVector.java - src/share/classes/com/sun/org/apache/xml/internal/utils/ObjectFactory.java - src/share/classes/com/sun/org/apache/xml/internal/utils/ObjectPool.java - src/share/classes/com/sun/org/apache/xml/internal/utils/ObjectStack.java - src/share/classes/com/sun/org/apache/xml/internal/utils/ObjectVector.java - src/share/classes/com/sun/org/apache/xml/internal/utils/PrefixResolver.java - src/share/classes/com/sun/org/apache/xml/internal/utils/PrefixResolverDefault.java - src/share/classes/com/sun/org/apache/xml/internal/utils/QName.java - src/share/classes/com/sun/org/apache/xml/internal/utils/RawCharacterHandler.java - src/share/classes/com/sun/org/apache/xml/internal/utils/SAXSourceLocator.java - src/share/classes/com/sun/org/apache/xml/internal/utils/SecuritySupport.java - src/share/classes/com/sun/org/apache/xml/internal/utils/SecuritySupport12.java - src/share/classes/com/sun/org/apache/xml/internal/utils/SerializableLocatorImpl.java - src/share/classes/com/sun/org/apache/xml/internal/utils/StopParseException.java - src/share/classes/com/sun/org/apache/xml/internal/utils/StringBufferPool.java - src/share/classes/com/sun/org/apache/xml/internal/utils/StringComparable.java - src/share/classes/com/sun/org/apache/xml/internal/utils/StringToIntTable.java - src/share/classes/com/sun/org/apache/xml/internal/utils/StringToStringTable.java - src/share/classes/com/sun/org/apache/xml/internal/utils/StringToStringTableVector.java - src/share/classes/com/sun/org/apache/xml/internal/utils/StringVector.java - src/share/classes/com/sun/org/apache/xml/internal/utils/StylesheetPIHandler.java - src/share/classes/com/sun/org/apache/xml/internal/utils/SuballocatedByteVector.java - src/share/classes/com/sun/org/apache/xml/internal/utils/SuballocatedIntVector.java - src/share/classes/com/sun/org/apache/xml/internal/utils/SystemIDResolver.java - src/share/classes/com/sun/org/apache/xml/internal/utils/ThreadControllerWrapper.java - src/share/classes/com/sun/org/apache/xml/internal/utils/TreeWalker.java - src/share/classes/com/sun/org/apache/xml/internal/utils/Trie.java - src/share/classes/com/sun/org/apache/xml/internal/utils/URI.java - src/share/classes/com/sun/org/apache/xml/internal/utils/UnImplNode.java - src/share/classes/com/sun/org/apache/xml/internal/utils/WrappedRuntimeException.java - src/share/classes/com/sun/org/apache/xml/internal/utils/WrongParserException.java - src/share/classes/com/sun/org/apache/xml/internal/utils/XML11Char.java - src/share/classes/com/sun/org/apache/xml/internal/utils/XMLChar.java - src/share/classes/com/sun/org/apache/xml/internal/utils/XMLCharacterRecognizer.java - src/share/classes/com/sun/org/apache/xml/internal/utils/XMLReaderManager.java - src/share/classes/com/sun/org/apache/xml/internal/utils/XMLString.java - src/share/classes/com/sun/org/apache/xml/internal/utils/XMLStringDefault.java - src/share/classes/com/sun/org/apache/xml/internal/utils/XMLStringFactory.java - src/share/classes/com/sun/org/apache/xml/internal/utils/XMLStringFactoryDefault.java - src/share/classes/com/sun/org/apache/xml/internal/utils/package.html - src/share/classes/com/sun/org/apache/xml/internal/utils/res/CharArrayWrapper.java - src/share/classes/com/sun/org/apache/xml/internal/utils/res/IntArrayWrapper.java - src/share/classes/com/sun/org/apache/xml/internal/utils/res/LongArrayWrapper.java - src/share/classes/com/sun/org/apache/xml/internal/utils/res/StringArrayWrapper.java - src/share/classes/com/sun/org/apache/xml/internal/utils/res/XResourceBundle.java - src/share/classes/com/sun/org/apache/xml/internal/utils/res/XResourceBundleBase.java - src/share/classes/com/sun/org/apache/xml/internal/utils/res/XResources_de.java - src/share/classes/com/sun/org/apache/xml/internal/utils/res/XResources_en.java - src/share/classes/com/sun/org/apache/xml/internal/utils/res/XResources_es.java - src/share/classes/com/sun/org/apache/xml/internal/utils/res/XResources_fr.java - src/share/classes/com/sun/org/apache/xml/internal/utils/res/XResources_it.java - src/share/classes/com/sun/org/apache/xml/internal/utils/res/XResources_ja_JP_A.java - src/share/classes/com/sun/org/apache/xml/internal/utils/res/XResources_ja_JP_HA.java - src/share/classes/com/sun/org/apache/xml/internal/utils/res/XResources_ja_JP_HI.java - src/share/classes/com/sun/org/apache/xml/internal/utils/res/XResources_ja_JP_I.java - src/share/classes/com/sun/org/apache/xml/internal/utils/res/XResources_ko.java - src/share/classes/com/sun/org/apache/xml/internal/utils/res/XResources_sv.java - src/share/classes/com/sun/org/apache/xml/internal/utils/res/XResources_zh_CN.java - src/share/classes/com/sun/org/apache/xml/internal/utils/res/XResources_zh_TW.java - src/share/classes/com/sun/org/apache/xpath/internal/Arg.java - src/share/classes/com/sun/org/apache/xpath/internal/CachedXPathAPI.java - src/share/classes/com/sun/org/apache/xpath/internal/Expression.java - src/share/classes/com/sun/org/apache/xpath/internal/ExpressionNode.java - src/share/classes/com/sun/org/apache/xpath/internal/ExpressionOwner.java - src/share/classes/com/sun/org/apache/xpath/internal/ExtensionsProvider.java - src/share/classes/com/sun/org/apache/xpath/internal/FoundIndex.java - src/share/classes/com/sun/org/apache/xpath/internal/NodeSet.java - src/share/classes/com/sun/org/apache/xpath/internal/NodeSetDTM.java - src/share/classes/com/sun/org/apache/xpath/internal/SourceTree.java - src/share/classes/com/sun/org/apache/xpath/internal/SourceTreeManager.java - src/share/classes/com/sun/org/apache/xpath/internal/VariableStack.java - src/share/classes/com/sun/org/apache/xpath/internal/WhitespaceStrippingElementMatcher.java - src/share/classes/com/sun/org/apache/xpath/internal/XPath.java - src/share/classes/com/sun/org/apache/xpath/internal/XPathAPI.java - src/share/classes/com/sun/org/apache/xpath/internal/XPathContext.java - src/share/classes/com/sun/org/apache/xpath/internal/XPathException.java - src/share/classes/com/sun/org/apache/xpath/internal/XPathFactory.java - src/share/classes/com/sun/org/apache/xpath/internal/XPathProcessorException.java - src/share/classes/com/sun/org/apache/xpath/internal/XPathVisitable.java - src/share/classes/com/sun/org/apache/xpath/internal/XPathVisitor.java - src/share/classes/com/sun/org/apache/xpath/internal/axes/AttributeIterator.java - src/share/classes/com/sun/org/apache/xpath/internal/axes/AxesWalker.java - src/share/classes/com/sun/org/apache/xpath/internal/axes/BasicTestIterator.java - src/share/classes/com/sun/org/apache/xpath/internal/axes/ChildIterator.java - src/share/classes/com/sun/org/apache/xpath/internal/axes/ChildTestIterator.java - src/share/classes/com/sun/org/apache/xpath/internal/axes/ContextNodeList.java - src/share/classes/com/sun/org/apache/xpath/internal/axes/DescendantIterator.java - src/share/classes/com/sun/org/apache/xpath/internal/axes/FilterExprIterator.java - src/share/classes/com/sun/org/apache/xpath/internal/axes/FilterExprIteratorSimple.java - src/share/classes/com/sun/org/apache/xpath/internal/axes/FilterExprWalker.java - src/share/classes/com/sun/org/apache/xpath/internal/axes/HasPositionalPredChecker.java - src/share/classes/com/sun/org/apache/xpath/internal/axes/IteratorPool.java - src/share/classes/com/sun/org/apache/xpath/internal/axes/LocPathIterator.java - src/share/classes/com/sun/org/apache/xpath/internal/axes/MatchPatternIterator.java - src/share/classes/com/sun/org/apache/xpath/internal/axes/NodeSequence.java - src/share/classes/com/sun/org/apache/xpath/internal/axes/OneStepIterator.java - src/share/classes/com/sun/org/apache/xpath/internal/axes/OneStepIteratorForward.java - src/share/classes/com/sun/org/apache/xpath/internal/axes/PathComponent.java - src/share/classes/com/sun/org/apache/xpath/internal/axes/PredicatedNodeTest.java - src/share/classes/com/sun/org/apache/xpath/internal/axes/RTFIterator.java - src/share/classes/com/sun/org/apache/xpath/internal/axes/ReverseAxesWalker.java - src/share/classes/com/sun/org/apache/xpath/internal/axes/SelfIteratorNoPredicate.java - src/share/classes/com/sun/org/apache/xpath/internal/axes/SubContextList.java - src/share/classes/com/sun/org/apache/xpath/internal/axes/UnionChildIterator.java - src/share/classes/com/sun/org/apache/xpath/internal/axes/UnionPathIterator.java - src/share/classes/com/sun/org/apache/xpath/internal/axes/WalkerFactory.java - src/share/classes/com/sun/org/apache/xpath/internal/axes/WalkingIterator.java - src/share/classes/com/sun/org/apache/xpath/internal/axes/WalkingIteratorSorted.java - src/share/classes/com/sun/org/apache/xpath/internal/axes/package.html - src/share/classes/com/sun/org/apache/xpath/internal/compiler/Compiler.java - src/share/classes/com/sun/org/apache/xpath/internal/compiler/FuncLoader.java - src/share/classes/com/sun/org/apache/xpath/internal/compiler/FunctionTable.java - src/share/classes/com/sun/org/apache/xpath/internal/compiler/Keywords.java - src/share/classes/com/sun/org/apache/xpath/internal/compiler/Lexer.java - src/share/classes/com/sun/org/apache/xpath/internal/compiler/ObjectFactory.java - src/share/classes/com/sun/org/apache/xpath/internal/compiler/OpCodes.java - src/share/classes/com/sun/org/apache/xpath/internal/compiler/OpMap.java - src/share/classes/com/sun/org/apache/xpath/internal/compiler/OpMapVector.java - src/share/classes/com/sun/org/apache/xpath/internal/compiler/PsuedoNames.java - src/share/classes/com/sun/org/apache/xpath/internal/compiler/SecuritySupport.java - src/share/classes/com/sun/org/apache/xpath/internal/compiler/SecuritySupport12.java - src/share/classes/com/sun/org/apache/xpath/internal/compiler/XPathDumper.java - src/share/classes/com/sun/org/apache/xpath/internal/compiler/XPathParser.java - src/share/classes/com/sun/org/apache/xpath/internal/compiler/package.html - src/share/classes/com/sun/org/apache/xpath/internal/domapi/XPathEvaluatorImpl.java - src/share/classes/com/sun/org/apache/xpath/internal/domapi/XPathExpressionImpl.java - src/share/classes/com/sun/org/apache/xpath/internal/domapi/XPathNSResolverImpl.java - src/share/classes/com/sun/org/apache/xpath/internal/domapi/XPathNamespaceImpl.java - src/share/classes/com/sun/org/apache/xpath/internal/domapi/XPathResultImpl.java - src/share/classes/com/sun/org/apache/xpath/internal/domapi/XPathStylesheetDOM3Exception.java - src/share/classes/com/sun/org/apache/xpath/internal/domapi/package.html - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncBoolean.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncCeiling.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncConcat.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncContains.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncCount.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncCurrent.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncDoclocation.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncExtElementAvailable.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncExtFunction.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncExtFunctionAvailable.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncFalse.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncFloor.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncGenerateId.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncId.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncLang.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncLast.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncLocalPart.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncNamespace.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncNormalizeSpace.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncNot.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncNumber.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncPosition.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncQname.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncRound.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncStartsWith.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncString.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncStringLength.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncSubstring.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncSubstringAfter.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncSubstringBefore.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncSum.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncSystemProperty.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncTranslate.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncTrue.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncUnparsedEntityURI.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/Function.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/Function2Args.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/Function3Args.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FunctionDef1Arg.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FunctionMultiArgs.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FunctionOneArg.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/ObjectFactory.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/SecuritySupport.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/SecuritySupport12.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/WrongNumberArgsException.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/package.html - src/share/classes/com/sun/org/apache/xpath/internal/jaxp/JAXPExtensionsProvider.java - src/share/classes/com/sun/org/apache/xpath/internal/jaxp/JAXPPrefixResolver.java - src/share/classes/com/sun/org/apache/xpath/internal/jaxp/JAXPVariableStack.java - src/share/classes/com/sun/org/apache/xpath/internal/jaxp/XPathExpressionImpl.java - src/share/classes/com/sun/org/apache/xpath/internal/jaxp/XPathFactoryImpl.java - src/share/classes/com/sun/org/apache/xpath/internal/jaxp/XPathImpl.java - src/share/classes/com/sun/org/apache/xpath/internal/objects/DTMXRTreeFrag.java - src/share/classes/com/sun/org/apache/xpath/internal/objects/XBoolean.java - src/share/classes/com/sun/org/apache/xpath/internal/objects/XBooleanStatic.java - src/share/classes/com/sun/org/apache/xpath/internal/objects/XMLStringFactoryImpl.java - src/share/classes/com/sun/org/apache/xpath/internal/objects/XNodeSet.java - src/share/classes/com/sun/org/apache/xpath/internal/objects/XNodeSetForDOM.java - src/share/classes/com/sun/org/apache/xpath/internal/objects/XNull.java - src/share/classes/com/sun/org/apache/xpath/internal/objects/XNumber.java - src/share/classes/com/sun/org/apache/xpath/internal/objects/XObject.java - src/share/classes/com/sun/org/apache/xpath/internal/objects/XObjectFactory.java - src/share/classes/com/sun/org/apache/xpath/internal/objects/XRTreeFrag.java - src/share/classes/com/sun/org/apache/xpath/internal/objects/XRTreeFragSelectWrapper.java - src/share/classes/com/sun/org/apache/xpath/internal/objects/XString.java - src/share/classes/com/sun/org/apache/xpath/internal/objects/XStringForChars.java - src/share/classes/com/sun/org/apache/xpath/internal/objects/XStringForFSB.java - src/share/classes/com/sun/org/apache/xpath/internal/objects/package.html - src/share/classes/com/sun/org/apache/xpath/internal/operations/And.java - src/share/classes/com/sun/org/apache/xpath/internal/operations/Bool.java - src/share/classes/com/sun/org/apache/xpath/internal/operations/Div.java - src/share/classes/com/sun/org/apache/xpath/internal/operations/Equals.java - src/share/classes/com/sun/org/apache/xpath/internal/operations/Gt.java - src/share/classes/com/sun/org/apache/xpath/internal/operations/Gte.java - src/share/classes/com/sun/org/apache/xpath/internal/operations/Lt.java - src/share/classes/com/sun/org/apache/xpath/internal/operations/Lte.java - src/share/classes/com/sun/org/apache/xpath/internal/operations/Minus.java - src/share/classes/com/sun/org/apache/xpath/internal/operations/Mod.java - src/share/classes/com/sun/org/apache/xpath/internal/operations/Mult.java - src/share/classes/com/sun/org/apache/xpath/internal/operations/Neg.java - src/share/classes/com/sun/org/apache/xpath/internal/operations/NotEquals.java - src/share/classes/com/sun/org/apache/xpath/internal/operations/Number.java - src/share/classes/com/sun/org/apache/xpath/internal/operations/Operation.java - src/share/classes/com/sun/org/apache/xpath/internal/operations/Or.java - src/share/classes/com/sun/org/apache/xpath/internal/operations/Plus.java - src/share/classes/com/sun/org/apache/xpath/internal/operations/Quo.java - src/share/classes/com/sun/org/apache/xpath/internal/operations/String.java - src/share/classes/com/sun/org/apache/xpath/internal/operations/UnaryOperation.java - src/share/classes/com/sun/org/apache/xpath/internal/operations/Variable.java - src/share/classes/com/sun/org/apache/xpath/internal/operations/VariableSafeAbsRef.java - src/share/classes/com/sun/org/apache/xpath/internal/operations/package.html - src/share/classes/com/sun/org/apache/xpath/internal/package.html - src/share/classes/com/sun/org/apache/xpath/internal/patterns/ContextMatchStepPattern.java - src/share/classes/com/sun/org/apache/xpath/internal/patterns/FunctionPattern.java - src/share/classes/com/sun/org/apache/xpath/internal/patterns/NodeTest.java - src/share/classes/com/sun/org/apache/xpath/internal/patterns/NodeTestFilter.java - src/share/classes/com/sun/org/apache/xpath/internal/patterns/StepPattern.java - src/share/classes/com/sun/org/apache/xpath/internal/patterns/UnionPattern.java - src/share/classes/com/sun/org/apache/xpath/internal/patterns/package.html - src/share/classes/com/sun/org/apache/xpath/internal/res/XPATHErrorResources.java - src/share/classes/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_de.java - src/share/classes/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_en.java - src/share/classes/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_es.java - src/share/classes/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_fr.java - src/share/classes/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_it.java - src/share/classes/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_ja.java - src/share/classes/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_ko.java - src/share/classes/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_pt_BR.java - src/share/classes/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_sv.java - src/share/classes/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_zh_CN.java - src/share/classes/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_zh_TW.java - src/share/classes/com/sun/org/apache/xpath/internal/res/XPATHMessages.java - src/share/classes/com/sun/org/apache/xpath/internal/res/package.html - src/share/classes/com/sun/xml/internal/stream/Entity.java - src/share/classes/com/sun/xml/internal/stream/EventFilterSupport.java - src/share/classes/com/sun/xml/internal/stream/StaxEntityResolverWrapper.java - src/share/classes/com/sun/xml/internal/stream/StaxErrorReporter.java - src/share/classes/com/sun/xml/internal/stream/StaxXMLInputSource.java - src/share/classes/com/sun/xml/internal/stream/XMLBufferListener.java - src/share/classes/com/sun/xml/internal/stream/XMLEntityReader.java - src/share/classes/com/sun/xml/internal/stream/XMLEntityStorage.java - src/share/classes/com/sun/xml/internal/stream/XMLEventReaderImpl.java - src/share/classes/com/sun/xml/internal/stream/XMLInputFactoryImpl.java - src/share/classes/com/sun/xml/internal/stream/XMLOutputFactoryImpl.java - src/share/classes/com/sun/xml/internal/stream/dtd/DTDGrammarUtil.java - src/share/classes/com/sun/xml/internal/stream/dtd/nonvalidating/DTDGrammar.java - src/share/classes/com/sun/xml/internal/stream/dtd/nonvalidating/XMLAttributeDecl.java - src/share/classes/com/sun/xml/internal/stream/dtd/nonvalidating/XMLElementDecl.java - src/share/classes/com/sun/xml/internal/stream/dtd/nonvalidating/XMLNotationDecl.java - src/share/classes/com/sun/xml/internal/stream/dtd/nonvalidating/XMLSimpleType.java - src/share/classes/com/sun/xml/internal/stream/events/AttributeImpl.java - src/share/classes/com/sun/xml/internal/stream/events/CharacterEvent.java - src/share/classes/com/sun/xml/internal/stream/events/CommentEvent.java - src/share/classes/com/sun/xml/internal/stream/events/DTDEvent.java - src/share/classes/com/sun/xml/internal/stream/events/DummyEvent.java - src/share/classes/com/sun/xml/internal/stream/events/EndDocumentEvent.java - src/share/classes/com/sun/xml/internal/stream/events/EndElementEvent.java - src/share/classes/com/sun/xml/internal/stream/events/EntityDeclarationImpl.java - src/share/classes/com/sun/xml/internal/stream/events/EntityReferenceEvent.java - src/share/classes/com/sun/xml/internal/stream/events/LocationImpl.java - src/share/classes/com/sun/xml/internal/stream/events/NamedEvent.java - src/share/classes/com/sun/xml/internal/stream/events/NamespaceImpl.java - src/share/classes/com/sun/xml/internal/stream/events/NotationDeclarationImpl.java - src/share/classes/com/sun/xml/internal/stream/events/ProcessingInstructionEvent.java - src/share/classes/com/sun/xml/internal/stream/events/StartDocumentEvent.java - src/share/classes/com/sun/xml/internal/stream/events/StartElementEvent.java - src/share/classes/com/sun/xml/internal/stream/events/XMLEventAllocatorImpl.java - src/share/classes/com/sun/xml/internal/stream/events/XMLEventFactoryImpl.java - src/share/classes/com/sun/xml/internal/stream/javax.xml.stream.XMLEventFactory - src/share/classes/com/sun/xml/internal/stream/javax.xml.stream.XMLInputFactory - src/share/classes/com/sun/xml/internal/stream/javax.xml.stream.XMLOutputFactory - src/share/classes/com/sun/xml/internal/stream/util/BufferAllocator.java - src/share/classes/com/sun/xml/internal/stream/util/ReadOnlyIterator.java - src/share/classes/com/sun/xml/internal/stream/util/ThreadLocalBufferAllocator.java - src/share/classes/com/sun/xml/internal/stream/writers/UTF8OutputStreamWriter.java - src/share/classes/com/sun/xml/internal/stream/writers/WriterUtility.java - src/share/classes/com/sun/xml/internal/stream/writers/XMLDOMWriterImpl.java - src/share/classes/com/sun/xml/internal/stream/writers/XMLEventWriterImpl.java - src/share/classes/com/sun/xml/internal/stream/writers/XMLOutputSource.java - src/share/classes/com/sun/xml/internal/stream/writers/XMLStreamWriterImpl.java - src/share/classes/com/sun/xml/internal/stream/writers/XMLWriter.java - src/share/classes/javax/xml/XMLConstants.java - src/share/classes/javax/xml/datatype/DatatypeConfigurationException.java - src/share/classes/javax/xml/datatype/DatatypeConstants.java - src/share/classes/javax/xml/datatype/DatatypeFactory.java - src/share/classes/javax/xml/datatype/Duration.java - src/share/classes/javax/xml/datatype/FactoryFinder.java - src/share/classes/javax/xml/datatype/SecuritySupport.java - src/share/classes/javax/xml/datatype/XMLGregorianCalendar.java - src/share/classes/javax/xml/datatype/package.html - src/share/classes/javax/xml/namespace/NamespaceContext.java - src/share/classes/javax/xml/namespace/QName.java - src/share/classes/javax/xml/namespace/package.html - src/share/classes/javax/xml/parsers/DocumentBuilder.java - src/share/classes/javax/xml/parsers/DocumentBuilderFactory.java - src/share/classes/javax/xml/parsers/FactoryConfigurationError.java - src/share/classes/javax/xml/parsers/FactoryFinder.java - src/share/classes/javax/xml/parsers/ParserConfigurationException.java - src/share/classes/javax/xml/parsers/SAXParser.java - src/share/classes/javax/xml/parsers/SAXParserFactory.java - src/share/classes/javax/xml/parsers/SecuritySupport.java - src/share/classes/javax/xml/parsers/package.html - src/share/classes/javax/xml/stream/EventFilter.java - src/share/classes/javax/xml/stream/FactoryConfigurationError.java - src/share/classes/javax/xml/stream/FactoryFinder.java - src/share/classes/javax/xml/stream/Location.java - src/share/classes/javax/xml/stream/SecuritySupport.java - src/share/classes/javax/xml/stream/StreamFilter.java - src/share/classes/javax/xml/stream/XMLEventFactory.java - src/share/classes/javax/xml/stream/XMLEventReader.java - src/share/classes/javax/xml/stream/XMLEventWriter.java - src/share/classes/javax/xml/stream/XMLInputFactory.java - src/share/classes/javax/xml/stream/XMLOutputFactory.java - src/share/classes/javax/xml/stream/XMLReporter.java - src/share/classes/javax/xml/stream/XMLResolver.java - src/share/classes/javax/xml/stream/XMLStreamConstants.java - src/share/classes/javax/xml/stream/XMLStreamException.java - src/share/classes/javax/xml/stream/XMLStreamReader.java - src/share/classes/javax/xml/stream/XMLStreamWriter.java - src/share/classes/javax/xml/stream/events/Attribute.java - src/share/classes/javax/xml/stream/events/Characters.java - src/share/classes/javax/xml/stream/events/Comment.java - src/share/classes/javax/xml/stream/events/DTD.java - src/share/classes/javax/xml/stream/events/EndDocument.java - src/share/classes/javax/xml/stream/events/EndElement.java - src/share/classes/javax/xml/stream/events/EntityDeclaration.java - src/share/classes/javax/xml/stream/events/EntityReference.java - src/share/classes/javax/xml/stream/events/Namespace.java - src/share/classes/javax/xml/stream/events/NotationDeclaration.java - src/share/classes/javax/xml/stream/events/ProcessingInstruction.java - src/share/classes/javax/xml/stream/events/StartDocument.java - src/share/classes/javax/xml/stream/events/StartElement.java - src/share/classes/javax/xml/stream/events/XMLEvent.java - src/share/classes/javax/xml/stream/util/EventReaderDelegate.java - src/share/classes/javax/xml/stream/util/StreamReaderDelegate.java - src/share/classes/javax/xml/stream/util/XMLEventAllocator.java - src/share/classes/javax/xml/stream/util/XMLEventConsumer.java - src/share/classes/javax/xml/transform/ErrorListener.java - src/share/classes/javax/xml/transform/FactoryFinder.java - src/share/classes/javax/xml/transform/OutputKeys.java - src/share/classes/javax/xml/transform/Result.java - src/share/classes/javax/xml/transform/SecuritySupport.java - src/share/classes/javax/xml/transform/Source.java - src/share/classes/javax/xml/transform/SourceLocator.java - src/share/classes/javax/xml/transform/Templates.java - src/share/classes/javax/xml/transform/Transformer.java - src/share/classes/javax/xml/transform/TransformerConfigurationException.java - src/share/classes/javax/xml/transform/TransformerException.java - src/share/classes/javax/xml/transform/TransformerFactory.java - src/share/classes/javax/xml/transform/TransformerFactoryConfigurationError.java - src/share/classes/javax/xml/transform/URIResolver.java - src/share/classes/javax/xml/transform/dom/DOMLocator.java - src/share/classes/javax/xml/transform/dom/DOMResult.java - src/share/classes/javax/xml/transform/dom/DOMSource.java - src/share/classes/javax/xml/transform/dom/package.html - src/share/classes/javax/xml/transform/overview.html - src/share/classes/javax/xml/transform/package.html - src/share/classes/javax/xml/transform/sax/SAXResult.java - src/share/classes/javax/xml/transform/sax/SAXSource.java - src/share/classes/javax/xml/transform/sax/SAXTransformerFactory.java - src/share/classes/javax/xml/transform/sax/TemplatesHandler.java - src/share/classes/javax/xml/transform/sax/TransformerHandler.java - src/share/classes/javax/xml/transform/sax/package.html - src/share/classes/javax/xml/transform/stax/StAXResult.java - src/share/classes/javax/xml/transform/stax/StAXSource.java - src/share/classes/javax/xml/transform/stax/package.html - src/share/classes/javax/xml/transform/stream/StreamResult.java - src/share/classes/javax/xml/transform/stream/StreamSource.java - src/share/classes/javax/xml/transform/stream/package.html - src/share/classes/javax/xml/validation/Schema.java - src/share/classes/javax/xml/validation/SchemaFactory.java - src/share/classes/javax/xml/validation/SchemaFactoryFinder.java - src/share/classes/javax/xml/validation/SchemaFactoryLoader.java - src/share/classes/javax/xml/validation/SecuritySupport.java - src/share/classes/javax/xml/validation/TypeInfoProvider.java - src/share/classes/javax/xml/validation/Validator.java - src/share/classes/javax/xml/validation/ValidatorHandler.java - src/share/classes/javax/xml/validation/package.html - src/share/classes/javax/xml/xpath/SecuritySupport.java - src/share/classes/javax/xml/xpath/XPath.java - src/share/classes/javax/xml/xpath/XPathConstants.java - src/share/classes/javax/xml/xpath/XPathException.java - src/share/classes/javax/xml/xpath/XPathExpression.java - src/share/classes/javax/xml/xpath/XPathExpressionException.java - src/share/classes/javax/xml/xpath/XPathFactory.java - src/share/classes/javax/xml/xpath/XPathFactoryConfigurationException.java - src/share/classes/javax/xml/xpath/XPathFactoryFinder.java - src/share/classes/javax/xml/xpath/XPathFunction.java - src/share/classes/javax/xml/xpath/XPathFunctionException.java - src/share/classes/javax/xml/xpath/XPathFunctionResolver.java - src/share/classes/javax/xml/xpath/XPathVariableResolver.java - src/share/classes/javax/xml/xpath/package.html - src/share/classes/org/w3c/dom/Attr.java - src/share/classes/org/w3c/dom/CDATASection.java - src/share/classes/org/w3c/dom/CharacterData.java - src/share/classes/org/w3c/dom/Comment.java - src/share/classes/org/w3c/dom/DOMConfiguration.java - src/share/classes/org/w3c/dom/DOMError.java - src/share/classes/org/w3c/dom/DOMErrorHandler.java - src/share/classes/org/w3c/dom/DOMException.java - src/share/classes/org/w3c/dom/DOMImplementation.java - src/share/classes/org/w3c/dom/DOMImplementationList.java - src/share/classes/org/w3c/dom/DOMImplementationSource.java - src/share/classes/org/w3c/dom/DOMLocator.java - src/share/classes/org/w3c/dom/DOMStringList.java - src/share/classes/org/w3c/dom/Document.java - src/share/classes/org/w3c/dom/DocumentFragment.java - src/share/classes/org/w3c/dom/DocumentType.java - src/share/classes/org/w3c/dom/Element.java - src/share/classes/org/w3c/dom/Entity.java - src/share/classes/org/w3c/dom/EntityReference.java - src/share/classes/org/w3c/dom/NameList.java - src/share/classes/org/w3c/dom/NamedNodeMap.java - src/share/classes/org/w3c/dom/Node.java - src/share/classes/org/w3c/dom/NodeList.java - src/share/classes/org/w3c/dom/Notation.java - src/share/classes/org/w3c/dom/ProcessingInstruction.java - src/share/classes/org/w3c/dom/Text.java - src/share/classes/org/w3c/dom/TypeInfo.java - src/share/classes/org/w3c/dom/UserDataHandler.java - src/share/classes/org/w3c/dom/bootstrap/DOMImplementationRegistry.java - src/share/classes/org/w3c/dom/css/CSS2Properties.java - src/share/classes/org/w3c/dom/css/CSSCharsetRule.java - src/share/classes/org/w3c/dom/css/CSSFontFaceRule.java - src/share/classes/org/w3c/dom/css/CSSImportRule.java - src/share/classes/org/w3c/dom/css/CSSMediaRule.java - src/share/classes/org/w3c/dom/css/CSSPageRule.java - src/share/classes/org/w3c/dom/css/CSSPrimitiveValue.java - src/share/classes/org/w3c/dom/css/CSSRule.java - src/share/classes/org/w3c/dom/css/CSSRuleList.java - src/share/classes/org/w3c/dom/css/CSSStyleDeclaration.java - src/share/classes/org/w3c/dom/css/CSSStyleRule.java - src/share/classes/org/w3c/dom/css/CSSStyleSheet.java - src/share/classes/org/w3c/dom/css/CSSUnknownRule.java - src/share/classes/org/w3c/dom/css/CSSValue.java - src/share/classes/org/w3c/dom/css/CSSValueList.java - src/share/classes/org/w3c/dom/css/Counter.java - src/share/classes/org/w3c/dom/css/DOMImplementationCSS.java - src/share/classes/org/w3c/dom/css/DocumentCSS.java - src/share/classes/org/w3c/dom/css/ElementCSSInlineStyle.java - src/share/classes/org/w3c/dom/css/RGBColor.java - src/share/classes/org/w3c/dom/css/Rect.java - src/share/classes/org/w3c/dom/css/ViewCSS.java - src/share/classes/org/w3c/dom/events/DocumentEvent.java - src/share/classes/org/w3c/dom/events/Event.java - src/share/classes/org/w3c/dom/events/EventException.java - src/share/classes/org/w3c/dom/events/EventListener.java - src/share/classes/org/w3c/dom/events/EventTarget.java - src/share/classes/org/w3c/dom/events/MouseEvent.java - src/share/classes/org/w3c/dom/events/MutationEvent.java - src/share/classes/org/w3c/dom/events/UIEvent.java - src/share/classes/org/w3c/dom/html/HTMLAnchorElement.java - src/share/classes/org/w3c/dom/html/HTMLAppletElement.java - src/share/classes/org/w3c/dom/html/HTMLAreaElement.java - src/share/classes/org/w3c/dom/html/HTMLBRElement.java - src/share/classes/org/w3c/dom/html/HTMLBaseElement.java - src/share/classes/org/w3c/dom/html/HTMLBaseFontElement.java - src/share/classes/org/w3c/dom/html/HTMLBodyElement.java - src/share/classes/org/w3c/dom/html/HTMLButtonElement.java - src/share/classes/org/w3c/dom/html/HTMLCollection.java - src/share/classes/org/w3c/dom/html/HTMLDListElement.java - src/share/classes/org/w3c/dom/html/HTMLDOMImplementation.java - src/share/classes/org/w3c/dom/html/HTMLDirectoryElement.java - src/share/classes/org/w3c/dom/html/HTMLDivElement.java - src/share/classes/org/w3c/dom/html/HTMLDocument.java - src/share/classes/org/w3c/dom/html/HTMLElement.java - src/share/classes/org/w3c/dom/html/HTMLFieldSetElement.java - src/share/classes/org/w3c/dom/html/HTMLFontElement.java - src/share/classes/org/w3c/dom/html/HTMLFormElement.java - src/share/classes/org/w3c/dom/html/HTMLFrameElement.java - src/share/classes/org/w3c/dom/html/HTMLFrameSetElement.java - src/share/classes/org/w3c/dom/html/HTMLHRElement.java - src/share/classes/org/w3c/dom/html/HTMLHeadElement.java - src/share/classes/org/w3c/dom/html/HTMLHeadingElement.java - src/share/classes/org/w3c/dom/html/HTMLHtmlElement.java - src/share/classes/org/w3c/dom/html/HTMLIFrameElement.java - src/share/classes/org/w3c/dom/html/HTMLImageElement.java - src/share/classes/org/w3c/dom/html/HTMLInputElement.java - src/share/classes/org/w3c/dom/html/HTMLIsIndexElement.java - src/share/classes/org/w3c/dom/html/HTMLLIElement.java - src/share/classes/org/w3c/dom/html/HTMLLabelElement.java - src/share/classes/org/w3c/dom/html/HTMLLegendElement.java - src/share/classes/org/w3c/dom/html/HTMLLinkElement.java - src/share/classes/org/w3c/dom/html/HTMLMapElement.java - src/share/classes/org/w3c/dom/html/HTMLMenuElement.java - src/share/classes/org/w3c/dom/html/HTMLMetaElement.java - src/share/classes/org/w3c/dom/html/HTMLModElement.java - src/share/classes/org/w3c/dom/html/HTMLOListElement.java - src/share/classes/org/w3c/dom/html/HTMLObjectElement.java - src/share/classes/org/w3c/dom/html/HTMLOptGroupElement.java - src/share/classes/org/w3c/dom/html/HTMLOptionElement.java - src/share/classes/org/w3c/dom/html/HTMLParagraphElement.java - src/share/classes/org/w3c/dom/html/HTMLParamElement.java - src/share/classes/org/w3c/dom/html/HTMLPreElement.java - src/share/classes/org/w3c/dom/html/HTMLQuoteElement.java - src/share/classes/org/w3c/dom/html/HTMLScriptElement.java - src/share/classes/org/w3c/dom/html/HTMLSelectElement.java - src/share/classes/org/w3c/dom/html/HTMLStyleElement.java - src/share/classes/org/w3c/dom/html/HTMLTableCaptionElement.java - src/share/classes/org/w3c/dom/html/HTMLTableCellElement.java - src/share/classes/org/w3c/dom/html/HTMLTableColElement.java - src/share/classes/org/w3c/dom/html/HTMLTableElement.java - src/share/classes/org/w3c/dom/html/HTMLTableRowElement.java - src/share/classes/org/w3c/dom/html/HTMLTableSectionElement.java - src/share/classes/org/w3c/dom/html/HTMLTextAreaElement.java - src/share/classes/org/w3c/dom/html/HTMLTitleElement.java - src/share/classes/org/w3c/dom/html/HTMLUListElement.java - src/share/classes/org/w3c/dom/ls/DOMImplementationLS.java - src/share/classes/org/w3c/dom/ls/LSException.java - src/share/classes/org/w3c/dom/ls/LSInput.java - src/share/classes/org/w3c/dom/ls/LSLoadEvent.java - src/share/classes/org/w3c/dom/ls/LSOutput.java - src/share/classes/org/w3c/dom/ls/LSParser.java - src/share/classes/org/w3c/dom/ls/LSParserFilter.java - src/share/classes/org/w3c/dom/ls/LSProgressEvent.java - src/share/classes/org/w3c/dom/ls/LSResourceResolver.java - src/share/classes/org/w3c/dom/ls/LSSerializer.java - src/share/classes/org/w3c/dom/ls/LSSerializerFilter.java - src/share/classes/org/w3c/dom/package.html - src/share/classes/org/w3c/dom/ranges/DocumentRange.java - src/share/classes/org/w3c/dom/ranges/Range.java - src/share/classes/org/w3c/dom/ranges/RangeException.java - src/share/classes/org/w3c/dom/ranges/package.html - src/share/classes/org/w3c/dom/stylesheets/DocumentStyle.java - src/share/classes/org/w3c/dom/stylesheets/LinkStyle.java - src/share/classes/org/w3c/dom/stylesheets/MediaList.java - src/share/classes/org/w3c/dom/stylesheets/StyleSheet.java - src/share/classes/org/w3c/dom/stylesheets/StyleSheetList.java - src/share/classes/org/w3c/dom/traversal/DocumentTraversal.java - src/share/classes/org/w3c/dom/traversal/NodeFilter.java - src/share/classes/org/w3c/dom/traversal/NodeIterator.java - src/share/classes/org/w3c/dom/traversal/TreeWalker.java - src/share/classes/org/w3c/dom/views/AbstractView.java - src/share/classes/org/w3c/dom/views/DocumentView.java - src/share/classes/org/w3c/dom/xpath/COPYRIGHT.html - src/share/classes/org/w3c/dom/xpath/XPathEvaluator.java - src/share/classes/org/w3c/dom/xpath/XPathException.java - src/share/classes/org/w3c/dom/xpath/XPathExpression.java - src/share/classes/org/w3c/dom/xpath/XPathNSResolver.java - src/share/classes/org/w3c/dom/xpath/XPathNamespace.java - src/share/classes/org/w3c/dom/xpath/XPathResult.java - src/share/classes/org/xml/sax/AttributeList.java - src/share/classes/org/xml/sax/Attributes.java - src/share/classes/org/xml/sax/COPYING - src/share/classes/org/xml/sax/COPYING.txt - src/share/classes/org/xml/sax/ContentHandler.java - src/share/classes/org/xml/sax/DTDHandler.java - src/share/classes/org/xml/sax/DocumentHandler.java - src/share/classes/org/xml/sax/EntityResolver.java - src/share/classes/org/xml/sax/ErrorHandler.java - src/share/classes/org/xml/sax/HandlerBase.java - src/share/classes/org/xml/sax/InputSource.java - src/share/classes/org/xml/sax/Locator.java - src/share/classes/org/xml/sax/Parser.java - src/share/classes/org/xml/sax/SAXException.java - src/share/classes/org/xml/sax/SAXNotRecognizedException.java - src/share/classes/org/xml/sax/SAXNotSupportedException.java - src/share/classes/org/xml/sax/SAXParseException.java - src/share/classes/org/xml/sax/XMLFilter.java - src/share/classes/org/xml/sax/XMLReader.java - src/share/classes/org/xml/sax/ext/Attributes2.java - src/share/classes/org/xml/sax/ext/Attributes2Impl.java - src/share/classes/org/xml/sax/ext/DeclHandler.java - src/share/classes/org/xml/sax/ext/DefaultHandler2.java - src/share/classes/org/xml/sax/ext/EntityResolver2.java - src/share/classes/org/xml/sax/ext/LexicalHandler.java - src/share/classes/org/xml/sax/ext/Locator2.java - src/share/classes/org/xml/sax/ext/Locator2Impl.java - src/share/classes/org/xml/sax/ext/package.html - src/share/classes/org/xml/sax/helpers/AttributeListImpl.java - src/share/classes/org/xml/sax/helpers/AttributesImpl.java - src/share/classes/org/xml/sax/helpers/DefaultHandler.java - src/share/classes/org/xml/sax/helpers/LocatorImpl.java - src/share/classes/org/xml/sax/helpers/NamespaceSupport.java - src/share/classes/org/xml/sax/helpers/NewInstance.java - src/share/classes/org/xml/sax/helpers/ParserAdapter.java - src/share/classes/org/xml/sax/helpers/ParserFactory.java - src/share/classes/org/xml/sax/helpers/XMLFilterImpl.java - src/share/classes/org/xml/sax/helpers/XMLReaderAdapter.java - src/share/classes/org/xml/sax/helpers/XMLReaderFactory.java - src/share/classes/org/xml/sax/helpers/package.html - src/share/classes/org/xml/sax/package.html Changeset: 6aadb7d98564 Author: asaha Date: 2012-05-21 14:51 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxp/rev/6aadb7d98564 Merge Changeset: c865c6951fea Author: asaha Date: 2012-06-07 12:30 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxp/rev/c865c6951fea Merge Changeset: 57476f66e13c Author: lana Date: 2012-06-26 10:27 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxp/rev/57476f66e13c Merge Changeset: 300f45e99064 Author: katleman Date: 2012-06-28 09:32 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxp/rev/300f45e99064 Added tag jdk8-b45 for changeset 57476f66e13c ! .hgtags Changeset: daf33332f106 Author: alanb Date: 2012-07-11 15:28 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxp/rev/daf33332f106 Merge ! .hgtags From alan.bateman at oracle.com Thu Jul 12 07:24:09 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 12 Jul 2012 14:24:09 +0000 Subject: hg: jigsaw/jigsaw/jaxws: 6 new changesets Message-ID: <20120712142423.BD5C547FC2@hg.openjdk.java.net> Changeset: 001351a98bd5 Author: erikj Date: 2012-06-07 20:30 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxws/rev/001351a98bd5 7170079: Adjustments to build-infra makefiles Reviewed-by: ohair, ohrstrom, ihse, jonas Contributed-by: jonas , erikj , ihse , tgranat , ykantser ! makefiles/Makefile Changeset: f00c12994562 Author: katleman Date: 2012-06-13 16:53 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxws/rev/f00c12994562 Merge Changeset: f6a417540ef1 Author: katleman Date: 2012-06-14 13:14 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxws/rev/f6a417540ef1 Added tag jdk8-b43 for changeset f00c12994562 ! .hgtags Changeset: e80ac58b5ba9 Author: katleman Date: 2012-06-21 17:07 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxws/rev/e80ac58b5ba9 Added tag jdk8-b44 for changeset f6a417540ef1 ! .hgtags Changeset: ae368a83c240 Author: katleman Date: 2012-06-28 09:32 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxws/rev/ae368a83c240 Added tag jdk8-b45 for changeset e80ac58b5ba9 ! .hgtags Changeset: b128a49cc5bc Author: alanb Date: 2012-07-11 16:46 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxws/rev/b128a49cc5bc Merge ! .hgtags From jaroslav.tulach at oracle.com Thu Jul 12 07:41:06 2012 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Thu, 12 Jul 2012 16:41:06 +0200 Subject: Maven task was: ANT build file for the Quickstart example In-Reply-To: <004701cd6035$e94ec840$bbec58c0$@itaas.com> References: <004701cd6035$e94ec840$bbec58c0$@itaas.com> Message-ID: <1990704.VUT8RprP9T@logoutik> Dne ?t 12. ?ervence 2012 19:24:50, Deepak S Patwardhan napsal(a): > Since current Maven is pretty much unusable for Jigsaw projects (right?), There is an attempt to make Maven usable with Jigsaw. Currently the prototype can compile single JAR. It does not handle dependencies among modules however: https://bitbucket.org/jglick/jigsawmaven -jt From alan.bateman at oracle.com Thu Jul 12 07:24:48 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 12 Jul 2012 14:24:48 +0000 Subject: hg: jigsaw/jigsaw/jdk: 148 new changesets Message-ID: <20120712144917.1357C47FC5@hg.openjdk.java.net> Changeset: a2d12ca36eb3 Author: bae Date: 2012-05-25 12:56 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/a2d12ca36eb3 7146550: [macosx] DnD test failure in createCompatibleWritableRaster() Reviewed-by: kizune, serb ! src/macosx/classes/sun/lwawt/macosx/CDragSourceContextPeer.java ! src/macosx/classes/sun/lwawt/macosx/CImage.java ! src/macosx/native/sun/awt/CDragSource.h ! src/macosx/native/sun/awt/CDragSource.m ! src/macosx/native/sun/awt/CDragSourceContextPeer.m ! test/java/awt/dnd/ImageDecoratedDnDNegative/ImageDecoratedDnDNegative.java Changeset: 23b82fb671d4 Author: lana Date: 2012-05-25 19:34 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/23b82fb671d4 Merge Changeset: c892ca15ca52 Author: andrew Date: 2012-05-30 16:17 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/c892ca15ca52 7171223: Building ExtensionSubtables.cpp should use -fno-strict-aliasing Summary: GCC 4.4+ have stricter aliasing requirements which produces a new warning from this code Reviewed-by: prr, ohair ! make/sun/font/Makefile Changeset: d988ed9d40bc Author: bae Date: 2012-05-31 12:15 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/d988ed9d40bc 7120895: FontConfiguration should not use thread contextClassLoader Reviewed-by: igor, prr ! src/share/classes/sun/awt/FontConfiguration.java Changeset: baf734760bd6 Author: lana Date: 2012-06-05 17:56 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/baf734760bd6 Merge Changeset: c499fd3f1695 Author: erikj Date: 2012-06-07 18:05 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/c499fd3f1695 7170969: Add @GenerateNativeHeader to classes whose fields need to be exported for JNI Reviewed-by: ohair, ohrstrom, ihse ! make/sun/awt/make.depend ! src/macosx/classes/apple/laf/JRSUIConstants.java ! src/macosx/classes/com/apple/eawt/FullScreenHandler.java ! src/macosx/classes/com/apple/eawt/event/GestureHandler.java ! src/macosx/classes/sun/java2d/OSXSurfaceData.java ! src/macosx/classes/sun/lwawt/LWLabelPeer.java ! src/macosx/classes/sun/lwawt/LWTextFieldPeer.java ! src/macosx/classes/sun/lwawt/macosx/CocoaConstants.java ! src/share/classes/java/awt/Adjustable.java ! src/share/classes/java/awt/BasicStroke.java ! src/share/classes/java/awt/Choice.java ! src/share/classes/java/awt/DisplayMode.java ! src/share/classes/java/awt/Image.java ! src/share/classes/java/awt/List.java ! src/share/classes/java/awt/PopupMenu.java ! src/share/classes/java/awt/SystemColor.java ! src/share/classes/java/awt/TextComponent.java ! src/share/classes/java/awt/Transparency.java ! src/share/classes/java/awt/color/ColorSpace.java ! src/share/classes/java/awt/color/ICC_Profile.java ! src/share/classes/java/awt/datatransfer/Clipboard.java ! src/share/classes/java/awt/datatransfer/StringSelection.java ! src/share/classes/java/awt/dnd/DnDConstants.java ! src/share/classes/java/awt/event/ActionEvent.java ! src/share/classes/java/awt/event/AdjustmentEvent.java ! src/share/classes/java/awt/event/ComponentEvent.java ! src/share/classes/java/awt/event/InputMethodEvent.java ! src/share/classes/java/awt/event/MouseWheelEvent.java ! src/share/classes/java/awt/geom/PathIterator.java ! src/share/classes/java/awt/image/AffineTransformOp.java ! src/share/classes/java/awt/image/ConvolveOp.java ! src/share/classes/java/awt/image/DataBuffer.java ! src/share/classes/java/awt/image/DirectColorModel.java ! src/share/classes/java/awt/image/ImageConsumer.java ! src/share/classes/java/awt/image/ImageObserver.java ! src/share/classes/java/awt/peer/ComponentPeer.java ! src/share/classes/java/awt/print/PageFormat.java ! src/share/classes/java/awt/print/Pageable.java ! src/share/classes/java/awt/print/Printable.java ! src/share/classes/sun/awt/CharsetString.java ! src/share/classes/sun/awt/EmbeddedFrame.java ! src/share/classes/sun/awt/SunHints.java ! src/share/classes/sun/awt/dnd/SunDragSourceContextPeer.java ! src/share/classes/sun/awt/image/BufImgSurfaceData.java ! src/share/classes/sun/java2d/SunGraphics2D.java ! src/share/classes/sun/java2d/opengl/OGLBlitLoops.java ! src/share/classes/sun/java2d/opengl/OGLContext.java ! src/share/classes/sun/java2d/pipe/BufferedContext.java ! src/share/classes/sun/java2d/pipe/BufferedOpCodes.java ! src/share/classes/sun/java2d/pipe/BufferedPaints.java ! src/share/classes/sun/java2d/pipe/BufferedTextPipe.java ! src/share/classes/sun/java2d/pipe/RegionIterator.java ! src/share/classes/sun/java2d/pipe/RenderBuffer.java ! src/share/classes/sun/java2d/pipe/hw/AccelDeviceEventNotifier.java ! src/share/classes/sun/java2d/pipe/hw/AccelSurface.java ! src/share/classes/sun/java2d/pipe/hw/ContextCapabilities.java ! src/share/classes/sun/nio/ch/DatagramChannelImpl.java ! src/share/classes/sun/nio/ch/IOStatus.java ! src/share/classes/sun/security/pkcs11/Secmod.java ! src/share/classes/sun/security/pkcs11/wrapper/PKCS11.java ! src/solaris/classes/sun/awt/X11/XComponentPeer.java ! src/windows/classes/sun/java2d/d3d/D3DBlitLoops.java ! src/windows/classes/sun/java2d/d3d/D3DContext.java ! src/windows/classes/sun/java2d/d3d/D3DPaints.java ! src/windows/native/java/net/TwoStacksPlainSocketImpl.c ! src/windows/native/sun/windows/awt_DataTransferer.cpp ! src/windows/native/sun/windows/awt_MenuItem.h Changeset: 563582096868 Author: ohair Date: 2012-06-07 18:08 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/563582096868 Merge - src/macosx/bin/amd64/jvm.cfg ! src/macosx/classes/sun/lwawt/LWTextFieldPeer.java ! src/share/classes/sun/nio/ch/DatagramChannelImpl.java - src/share/classes/sun/security/action/LoadLibraryAction.java - test/tools/pack200/dyn.jar - test/tools/pack200/pack200-verifier/src/xmlkit/ClassSyntax.java - test/tools/pack200/pack200-verifier/src/xmlkit/ClassWriter.java - test/tools/pack200/pack200-verifier/src/xmlkit/InstructionAssembler.java - test/tools/pack200/pack200-verifier/src/xmlkit/InstructionSyntax.java Changeset: 992068b99493 Author: lana Date: 2012-06-08 11:58 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/992068b99493 Merge Changeset: 5ff4693406ad Author: dcherepanov Date: 2012-05-22 12:35 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/5ff4693406ad 7160293: [macosx] FileDialog appears on secondary display Reviewed-by: art, bae ! src/macosx/classes/sun/awt/CGraphicsEnvironment.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/PlatformWindow.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformEmbeddedFrame.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/native/sun/awt/AWTWindow.m Changeset: cac4daf60283 Author: zhouyx Date: 2012-05-23 12:37 +0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/cac4daf60283 7170996: IME composition window does not disappear when file dialog is closed : Japanese WinXP Reviewed-by: art, bagiras ! src/windows/native/sun/windows/awt_Component.cpp Changeset: bb3ada9822e4 Author: kizune Date: 2012-05-24 15:11 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/bb3ada9822e4 7144064: [macosx] "Could not find class" error in JTree's ctor when called in headless mode Reviewed-by: art, leonidr ! src/solaris/native/java/lang/java_props_md.c Changeset: cd00d68e06ac Author: neugens Date: 2012-05-25 14:16 +0200 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/cd00d68e06ac 6800513: GTK-LaF renders menus incompletely Reviewed-by: rupashka ! src/share/classes/javax/swing/JPopupMenu.java Changeset: 4b2b963f8774 Author: ant Date: 2012-05-25 20:57 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/4b2b963f8774 7171776: one more setGlobalCurrentFocusCycleRoot call requires doPrivileged Reviewed-by: art ! src/share/classes/java/awt/KeyboardFocusManager.java Changeset: bcdb6e5f31cc Author: lana Date: 2012-05-25 13:39 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/bcdb6e5f31cc Merge Changeset: 3c9adc88956d Author: luchsh Date: 2012-05-30 10:58 +0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/3c9adc88956d 7170655: Frame size does not follow font size change with XToolkit Reviewed-by: serb, art ! src/solaris/classes/sun/awt/X11/XLabelPeer.java + test/java/awt/Frame/ResizeAfterSetFont/ResizeAfterSetFont.java Changeset: 14f9e9060370 Author: alexsch Date: 2012-05-30 14:46 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/14f9e9060370 7146131: [macosx] When click the show optionpane button,it display partly of dialog and hung until timeout Reviewed-by: rupashka ! src/macosx/classes/com/apple/laf/AquaInternalFrameUI.java Changeset: e6de02da6870 Author: alexsch Date: 2012-05-30 14:58 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/e6de02da6870 7141296: [macosx] Mouse Wheel Turn closes combobox popup Reviewed-by: rupashka ! src/macosx/classes/com/apple/laf/AquaScrollPaneUI.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformResponder.java Changeset: 8800a98316b2 Author: neugens Date: 2012-05-30 18:15 +0200 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/8800a98316b2 7171806: Missing test for bug ID 6800513 fix Reviewed-by: rupashka + test/javax/swing/JPopupMenu/6800513/bug6800513.java Changeset: 06a0302856eb Author: leonidr Date: 2012-05-31 20:18 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/06a0302856eb 7150089: [macosx] Default for a custom cursor created from non-existent image is not transparent Reviewed-by: anthony, kizune ! src/macosx/classes/sun/lwawt/macosx/CCustomCursor.java Changeset: fd27852f3ea5 Author: denis Date: 2012-06-01 17:08 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/fd27852f3ea5 7112115: Component.getLocationOnScreen() work incorrectly if create window in point (0, 0) on oel Reviewed-by: serb, art + test/javax/swing/JSpinner/5012888/bug5012888.java Changeset: 0526ba7f723b Author: alexsch Date: 2012-06-04 14:11 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/0526ba7f723b 7161766: [macosx] javax/swing/JPopupMenu/6694823/bug6694823.java failed on Mac OS X Reviewed-by: rupashka ! test/javax/swing/JPopupMenu/6694823/bug6694823.java Changeset: 79df0a4a6573 Author: omajid Date: 2012-06-04 16:39 -0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/79df0a4a6573 7043963: AWT workaround missing for Mutter. Reviewed-by: art, anthony Contributed-by: Denis Lila ! src/solaris/classes/sun/awt/X11/XDecoratedPeer.java ! src/solaris/classes/sun/awt/X11/XWM.java + test/java/awt/WMSpecificTests/Mutter/MutterMaximizeTest.java ! test/java/awt/regtesthelpers/Util.java Changeset: fc64530a1571 Author: anthony Date: 2012-06-05 15:20 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/fc64530a1571 7172722: Latest jdk7u from OSX broke universal build Summary: Add a data memeber for a new property Reviewed-by: serb, swingler ! src/macosx/native/sun/awt/AWTWindow.h Changeset: 5880da7a3628 Author: dcherepanov Date: 2012-06-05 19:48 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/5880da7a3628 7123957: Switch of Gnome theme ends up deadlocked in GTKEngine.native_switch_theme Reviewed-by: art, anthony ! src/solaris/native/sun/awt/swing_GTKEngine.c Changeset: 8c6fef8404ea Author: lana Date: 2012-06-05 18:05 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/8c6fef8404ea Merge Changeset: c6075e29ce94 Author: alexsch Date: 2012-06-06 11:54 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/c6075e29ce94 7169285: [macosx] Test api/javax_swing/JPopupMenu/descriptions.html#setgetXXX doesn't take Mac main menu Reviewed-by: rupashka ! src/share/classes/javax/swing/JPopupMenu.java Changeset: 6694d9e99716 Author: littlee Date: 2012-06-07 10:22 +0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/6694d9e99716 7174233: Openjdk is missing some key maps on the Japanese keyboards Reviewed-by: anthony, naoto ! src/solaris/classes/sun/awt/X11/XKeysym.java ! src/solaris/native/sun/xawt/XWindow.c Changeset: 77c92e809c25 Author: alexsch Date: 2012-06-07 18:24 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/77c92e809c25 7152952: [macosx] List rows overlap with enlarged font Reviewed-by: art, rupashka ! src/macosx/classes/sun/lwawt/LWListPeer.java Changeset: f1063002c843 Author: kizune Date: 2012-06-07 20:04 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/f1063002c843 7124247: [macosx] Implement GraphicsDevice.setDisplayMode() Reviewed-by: anthony, swingler ! src/macosx/classes/sun/awt/CGraphicsDevice.java ! src/macosx/native/sun/awt/CGraphicsDevice.m Changeset: 05ac5622a2ec Author: kizune Date: 2012-06-07 20:06 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/05ac5622a2ec Merge Changeset: 4acd0211f48b Author: rupashka Date: 2012-06-07 21:49 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/4acd0211f48b 7156657: Version 7 doesn't support translucent popup menus against a translucent window Reviewed-by: art, alexsch ! src/share/classes/javax/swing/PopupFactory.java ! src/share/demo/jfc/TransparentRuler/transparentruler/Ruler.java + test/javax/swing/JPopupMenu/7156657/bug7156657.java Changeset: a1d825c477bc Author: alexsch Date: 2012-06-08 14:15 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/a1d825c477bc 7092551: Double-click in TextField sets caret to the beginning Reviewed-by: bagiras, serb ! src/windows/native/sun/windows/awt_TextArea.cpp ! src/windows/native/sun/windows/awt_TextArea.h ! src/windows/native/sun/windows/awt_TextComponent.cpp ! src/windows/native/sun/windows/awt_TextComponent.h ! src/windows/native/sun/windows/awt_TextField.cpp ! src/windows/native/sun/windows/awt_TextField.h Changeset: 34ac493d6bea Author: kizune Date: 2012-06-08 22:21 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/34ac493d6bea 7175566: [macosx] Glich in fix for CR7124247 caused MacOS crash during PIT testing Reviewed-by: anthony, dcherepanov ! src/macosx/native/sun/awt/CGraphicsDevice.m Changeset: 3d7be3ac3a99 Author: lana Date: 2012-06-08 12:00 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/3d7be3ac3a99 Merge Changeset: a2fc04c2dfc8 Author: weijun Date: 2012-05-23 15:51 +0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/a2fc04c2dfc8 7162687: enhance KDC server availability detection Reviewed-by: valeriep ! src/share/classes/sun/security/krb5/KdcComm.java ! src/share/classes/sun/security/krb5/internal/NetClient.java ! test/ProblemList.txt ! test/sun/security/krb5/auto/BadKdc.java ! test/sun/security/krb5/auto/MaxRetries.java ! test/sun/security/krb5/auto/TcpTimeout.java + test/sun/security/krb5/auto/Unreachable.java + test/sun/security/krb5/auto/unreachable.krb5.conf Changeset: 0c3d9050c918 Author: khazra Date: 2012-05-23 10:41 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/0c3d9050c918 7170169: (props) System.getProperty("os.name") should return "Windows 8" when run on Windows 8 Summary: Enable Windows Version 6.2 to be recognized as Windows 8 Reviewed-by: darcy, dholmes, alanb, chegar ! src/windows/native/java/lang/java_props_md.c Changeset: 21703d431217 Author: alanb Date: 2012-05-24 10:57 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/21703d431217 7169050: (se) Selector.select slow on Solaris due to insertion of POLLREMOVE and 0 events Reviewed-by: chegar, coffeys ! src/solaris/classes/sun/nio/ch/DevPollArrayWrapper.java ! src/solaris/native/sun/nio/ch/DevPollArrayWrapper.c Changeset: a11c964d1319 Author: jgish Date: 2012-05-24 14:44 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/a11c964d1319 7160725: Strange or obsolete @see tags in some exception java.lang javadoc Summary: update javadoc for IllegalArgumentException and NumberFormatException Reviewed-by: alanb ! src/share/classes/java/lang/IllegalArgumentException.java Changeset: 5ec5588c733d Author: nloodin Date: 2012-05-24 09:32 +0200 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/5ec5588c733d 7143353: -Xrunhprof fails in Java 7 due to bad switch Reviewed-by: jrose, sspitsyn ! src/share/demo/jvmti/java_crw_demo/java_crw_demo.c ! src/share/javavm/export/classfile_constants.h Changeset: 1c869c799ef9 Author: nloodin Date: 2012-05-24 10:20 -0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/1c869c799ef9 Merge Changeset: e309917fb9af Author: dbhole Date: 2012-05-24 19:00 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/e309917fb9af 7117230: clean up warnings in java.text Reviewed-by: jrose, smarks ! src/share/classes/java/text/AttributedCharacterIterator.java ! src/share/classes/java/text/AttributedString.java ! src/share/classes/java/text/BreakDictionary.java ! src/share/classes/java/text/BreakIterator.java ! src/share/classes/java/text/CharacterIteratorFieldDelegate.java ! src/share/classes/java/text/ChoiceFormat.java ! src/share/classes/java/text/CollationElementIterator.java ! src/share/classes/java/text/DateFormat.java ! src/share/classes/java/text/DecimalFormat.java ! src/share/classes/java/text/DictionaryBasedBreakIterator.java ! src/share/classes/java/text/MergeCollation.java ! src/share/classes/java/text/MessageFormat.java ! src/share/classes/java/text/NumberFormat.java ! src/share/classes/java/text/ParseException.java ! src/share/classes/java/text/RBCollationTables.java ! src/share/classes/java/text/RBTableBuilder.java ! src/share/classes/java/text/RuleBasedBreakIterator.java Changeset: 71cf74329a9e Author: youdwei Date: 2012-05-25 13:28 +0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/71cf74329a9e 7094176: (tz) Incorrect TimeZone display name when DST not applicable / disabled Reviewed-by: okutsu ! src/windows/native/java/util/TimeZone_md.c + test/java/util/TimeZone/DstTzTest.java Changeset: 85696e57d447 Author: youdwei Date: 2012-05-25 14:32 +0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/85696e57d447 7171028: dots are missed in the datetime for Slovanian Reviewed-by: yhuang ! src/share/classes/sun/text/resources/FormatData_sl.java ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: 1def6b6bfbd9 Author: egahlin Date: 2012-05-25 12:24 +0200 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/1def6b6bfbd9 7017818: NLS: JConsoleResources.java cannot be handled by translation team Reviewed-by: mchung, mfang ! make/netbeans/jconsole/build.xml ! make/sun/jconsole/FILES.gmk ! make/sun/jconsole/Makefile ! src/share/classes/sun/tools/jconsole/AboutDialog.java ! src/share/classes/sun/tools/jconsole/BorderedComponent.java ! src/share/classes/sun/tools/jconsole/ClassTab.java ! src/share/classes/sun/tools/jconsole/ConnectDialog.java ! src/share/classes/sun/tools/jconsole/CreateMBeanDialog.java ! src/share/classes/sun/tools/jconsole/Formatter.java ! src/share/classes/sun/tools/jconsole/HTMLPane.java ! src/share/classes/sun/tools/jconsole/InternalDialog.java ! src/share/classes/sun/tools/jconsole/JConsole.java ! src/share/classes/sun/tools/jconsole/LabeledComponent.java ! src/share/classes/sun/tools/jconsole/LocalVirtualMachine.java ! src/share/classes/sun/tools/jconsole/MBeansTab.java ! src/share/classes/sun/tools/jconsole/MaximizableInternalFrame.java ! src/share/classes/sun/tools/jconsole/MemoryPoolProxy.java ! src/share/classes/sun/tools/jconsole/MemoryPoolStat.java ! src/share/classes/sun/tools/jconsole/MemoryTab.java + src/share/classes/sun/tools/jconsole/Messages.java ! src/share/classes/sun/tools/jconsole/OverviewPanel.java ! src/share/classes/sun/tools/jconsole/OverviewTab.java ! src/share/classes/sun/tools/jconsole/Plotter.java ! src/share/classes/sun/tools/jconsole/PlotterPanel.java ! src/share/classes/sun/tools/jconsole/ProxyClient.java ! src/share/classes/sun/tools/jconsole/Resources.java ! src/share/classes/sun/tools/jconsole/SummaryTab.java ! src/share/classes/sun/tools/jconsole/Tab.java ! src/share/classes/sun/tools/jconsole/ThreadTab.java ! src/share/classes/sun/tools/jconsole/VMInternalFrame.java ! src/share/classes/sun/tools/jconsole/VMPanel.java ! src/share/classes/sun/tools/jconsole/VariableGridLayout.java ! src/share/classes/sun/tools/jconsole/Version.java.template ! src/share/classes/sun/tools/jconsole/inspector/OperationEntry.java ! src/share/classes/sun/tools/jconsole/inspector/TableSorter.java ! src/share/classes/sun/tools/jconsole/inspector/ThreadDialog.java ! src/share/classes/sun/tools/jconsole/inspector/Utils.java ! src/share/classes/sun/tools/jconsole/inspector/XArrayDataViewer.java ! src/share/classes/sun/tools/jconsole/inspector/XDataViewer.java ! src/share/classes/sun/tools/jconsole/inspector/XMBeanAttributes.java ! src/share/classes/sun/tools/jconsole/inspector/XMBeanInfo.java ! src/share/classes/sun/tools/jconsole/inspector/XMBeanNotifications.java ! src/share/classes/sun/tools/jconsole/inspector/XObject.java ! src/share/classes/sun/tools/jconsole/inspector/XOpenTypeViewer.java ! src/share/classes/sun/tools/jconsole/inspector/XOperations.java ! src/share/classes/sun/tools/jconsole/inspector/XPlotter.java ! src/share/classes/sun/tools/jconsole/inspector/XPlottingViewer.java ! src/share/classes/sun/tools/jconsole/inspector/XSheet.java ! src/share/classes/sun/tools/jconsole/inspector/XTable.java ! src/share/classes/sun/tools/jconsole/inspector/XTextField.java ! src/share/classes/sun/tools/jconsole/inspector/XTree.java ! src/share/classes/sun/tools/jconsole/inspector/XTreeRenderer.java - src/share/classes/sun/tools/jconsole/resources/JConsoleResources.java - src/share/classes/sun/tools/jconsole/resources/JConsoleResources_ja.java - src/share/classes/sun/tools/jconsole/resources/JConsoleResources_zh_CN.java + src/share/classes/sun/tools/jconsole/resources/messages.properties + src/share/classes/sun/tools/jconsole/resources/messages_ja.properties + src/share/classes/sun/tools/jconsole/resources/messages_zh_CN.properties Changeset: f92325f12654 Author: jgish Date: 2012-05-24 11:11 -0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/f92325f12654 7171474: Incorrect @see tags in java.lang.NumberFormatException javadoc Summary: update javadoc for NumberFormatException Reviewed-by: alanb ! src/share/classes/java/lang/NumberFormatException.java Changeset: 82134992123c Author: dcubed Date: 2012-05-25 08:20 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/82134992123c 7170449: Management is completely broken at least on Solaris 11 X86 Summary: Work around 'gobjcopy' failures on Solaris by adding temporary tools to add the '.gnu_debuglink' section and remove the SHF_ALLOC flag from "empty" section headers. Reviewed-by: sspitsyn, acorn ! make/common/Defs-solaris.gmk ! make/common/Defs.gmk ! make/common/Library.gmk ! make/common/Program.gmk ! make/tools/Makefile + make/tools/add_gnu_debuglink/Makefile + make/tools/add_gnu_debuglink/add_gnu_debuglink.c + make/tools/fix_empty_sec_hdr_flags/Makefile + make/tools/fix_empty_sec_hdr_flags/fix_empty_sec_hdr_flags.c Changeset: 7abdd3cb14ed Author: lana Date: 2012-05-25 16:32 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/7abdd3cb14ed Merge Changeset: 60033ab79213 Author: littlee Date: 2012-05-29 09:42 +0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/60033ab79213 7172177: test/java/util/TimeZone/DstTzTest.java failing on all platforms Reviewed-by: alanb, okutsu - test/java/util/TimeZone/DstTzTest.java Changeset: eb441933f6fe Author: khazra Date: 2012-05-29 13:16 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/eb441933f6fe 7171591: getDefaultScopeID() in src/solaris/native/java/net/net_util_md.c should return a value Summary: Use CHECK_NULL_RETURN instead of CHECK_NULL Reviewed-by: alanb ! src/solaris/native/java/net/net_util_md.c Changeset: 41dcfdbf8f07 Author: ksrini Date: 2012-05-29 14:56 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/41dcfdbf8f07 7168401: pack200 does not produce a compatible pack file for JDK7 classes if indy is not present Reviewed-by: jrose ! src/share/classes/com/sun/java/util/jar/pack/Attribute.java ! src/share/classes/com/sun/java/util/jar/pack/BandStructure.java ! src/share/classes/com/sun/java/util/jar/pack/ClassReader.java ! src/share/classes/com/sun/java/util/jar/pack/ClassWriter.java ! src/share/classes/com/sun/java/util/jar/pack/Constants.java ! src/share/classes/com/sun/java/util/jar/pack/Package.java ! src/share/classes/com/sun/java/util/jar/pack/PackageReader.java ! src/share/classes/com/sun/java/util/jar/pack/PackageWriter.java ! src/share/classes/com/sun/java/util/jar/pack/PackerImpl.java ! src/share/classes/com/sun/java/util/jar/pack/PropMap.java ! src/share/classes/com/sun/java/util/jar/pack/Utils.java ! test/tools/pack200/PackageVersionTest.java Changeset: 2c773daa825d Author: mduigou Date: 2012-05-17 10:06 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/2c773daa825d 6924259: Remove offset and count fields from java.lang.String Summary: Removes the use of shared character array buffers by String along with the two fields needed to support the use of shared buffers. Reviewed-by: alanb, mduigou, forax, briangoetz Contributed-by: brian.doherty at oracle.com ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Long.java ! src/share/classes/java/lang/String.java ! src/share/classes/java/lang/StringCoding.java Changeset: 43bd5ee0205e Author: mduigou Date: 2012-05-30 22:18 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/43bd5ee0205e 7126277: Alternative String hashing implementation Summary: All of the hashing based Map implementations: HashMap, Hashtable, LinkedHashMap, WeakHashMap and ConcurrentHashMap are modified to use an enhanced hashing algorithm for string keys when the capacity of the hash table has ever grown beyond 512 entries. The enhanced hashing implementation uses the murmur3 hashing algorithm along with random hash seeds and index masks. These enhancements mitigate cases where colliding String hash values could result in a performance bottleneck. Reviewed-by: alanb, forax, dl ! make/java/java/FILES_java.gmk ! src/share/classes/java/lang/String.java ! src/share/classes/java/util/HashMap.java ! src/share/classes/java/util/Hashtable.java ! src/share/classes/java/util/LinkedHashMap.java ! src/share/classes/java/util/WeakHashMap.java ! src/share/classes/java/util/concurrent/ConcurrentHashMap.java + src/share/classes/sun/misc/Hashing.java ! test/java/util/Collection/BiggernYours.java ! test/java/util/Hashtable/HashCode.java ! test/java/util/Hashtable/SimpleSerialization.java + test/java/util/Map/Collisions.java ! test/java/util/Map/Get.java + test/sun/misc/Hashing.java Changeset: 0c6830e7241f Author: mullan Date: 2012-05-30 17:19 -0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/0c6830e7241f 6854712: Revocation checking enhancements (JEP-124) 6637288: Add OCSP support to PKIX CertPathBuilder implementation 7126011: ReverseBuilder.getMatchingCACerts may throws NPE Reviewed-by: xuelei ! src/share/classes/java/security/cert/CertPathBuilder.java ! src/share/classes/java/security/cert/CertPathBuilderSpi.java + src/share/classes/java/security/cert/CertPathChecker.java ! src/share/classes/java/security/cert/CertPathValidator.java ! src/share/classes/java/security/cert/CertPathValidatorSpi.java ! src/share/classes/java/security/cert/PKIXCertPathChecker.java + src/share/classes/java/security/cert/PKIXRevocationChecker.java ! src/share/classes/java/security/cert/package.html ! src/share/classes/sun/security/provider/certpath/AdjacencyList.java ! src/share/classes/sun/security/provider/certpath/BasicChecker.java ! src/share/classes/sun/security/provider/certpath/BuildStep.java ! src/share/classes/sun/security/provider/certpath/Builder.java ! src/share/classes/sun/security/provider/certpath/CertStoreHelper.java ! src/share/classes/sun/security/provider/certpath/CollectionCertStore.java ! src/share/classes/sun/security/provider/certpath/ConstraintsChecker.java - src/share/classes/sun/security/provider/certpath/CrlRevocationChecker.java ! src/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java ! src/share/classes/sun/security/provider/certpath/ForwardBuilder.java ! src/share/classes/sun/security/provider/certpath/ForwardState.java ! src/share/classes/sun/security/provider/certpath/IndexedCollectionCertStore.java ! src/share/classes/sun/security/provider/certpath/KeyChecker.java ! src/share/classes/sun/security/provider/certpath/OCSP.java - src/share/classes/sun/security/provider/certpath/OCSPChecker.java ! src/share/classes/sun/security/provider/certpath/OCSPRequest.java ! src/share/classes/sun/security/provider/certpath/OCSPResponse.java + src/share/classes/sun/security/provider/certpath/PKIX.java ! src/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java ! src/share/classes/sun/security/provider/certpath/PKIXMasterCertPathValidator.java ! src/share/classes/sun/security/provider/certpath/PolicyChecker.java ! src/share/classes/sun/security/provider/certpath/PolicyNodeImpl.java ! src/share/classes/sun/security/provider/certpath/ReverseBuilder.java ! src/share/classes/sun/security/provider/certpath/ReverseState.java + src/share/classes/sun/security/provider/certpath/RevocationChecker.java ! src/share/classes/sun/security/provider/certpath/SunCertPathBuilder.java ! src/share/classes/sun/security/provider/certpath/SunCertPathBuilderParameters.java ! src/share/classes/sun/security/provider/certpath/URICertStore.java ! src/share/classes/sun/security/provider/certpath/Vertex.java ! src/share/classes/sun/security/provider/certpath/X509CertPath.java ! src/share/classes/sun/security/provider/certpath/X509CertificatePair.java ! src/share/classes/sun/security/x509/X509CRLEntryImpl.java + test/java/security/cert/PKIXRevocationChecker/UnitTest.java Changeset: 3192e73394fe Author: mullan Date: 2012-05-31 17:07 -0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/3192e73394fe Merge - src/share/classes/sun/security/provider/certpath/CrlRevocationChecker.java ! src/share/classes/sun/security/provider/certpath/ForwardBuilder.java ! src/share/classes/sun/security/provider/certpath/ForwardState.java - src/share/classes/sun/security/provider/certpath/OCSPChecker.java ! src/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java ! src/share/classes/sun/security/provider/certpath/ReverseBuilder.java ! src/share/classes/sun/security/provider/certpath/ReverseState.java ! src/share/classes/sun/security/provider/certpath/SunCertPathBuilder.java Changeset: 48dfc0df61d0 Author: mullan Date: 2012-05-31 17:10 -0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/48dfc0df61d0 Merge Changeset: 7baa22e6a6b3 Author: mduigou Date: 2012-06-01 00:05 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/7baa22e6a6b3 7173432: Handle null key at HashMap resize Summary: If the key to be inserted into a HashMap is null and the table needs to be resized as part of the insertion then addEntry will try to recalculate the hash of a null key. This will fail with an NPE. Reviewed-by: darcy ! src/share/classes/java/util/HashMap.java + test/java/util/HashMap/NullKeyAtResize.java Changeset: 237e27c7ddc3 Author: littlee Date: 2012-06-04 16:30 +0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/237e27c7ddc3 7166055: Javadoc for WeakHashMap contains misleading advice Reviewed-by: dholmes, mduigou ! src/share/classes/java/util/WeakHashMap.java Changeset: a5bb0343f135 Author: weijun Date: 2012-06-04 18:06 +0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/a5bb0343f135 7173036: test/com/sun/jdi/ConnectedVMs.java does not run as expected Reviewed-by: alanb ! test/com/sun/jdi/ConnectedVMs.java Changeset: 4573662cb28c Author: zhouyx Date: 2012-06-05 10:16 +0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/4573662cb28c 7173044: MemoryMonitor hangs if getMax method in MemoryUsage object returns -1 Reviewed-by: dholmes, sspitsyn ! src/share/demo/management/MemoryMonitor/MemoryMonitor.java Changeset: 0678af55d3db Author: weijun Date: 2012-06-05 17:11 +0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/0678af55d3db 7172701: KDC tests cleanup Reviewed-by: xuelei ! test/sun/security/krb5/auto/KDC.java ! test/sun/security/krb5/auto/OkAsDelegate.java ! test/sun/security/krb5/auto/OkAsDelegateXRealm.java - test/sun/security/krb5/auto/ok-as-delegate-xrealm.sh - test/sun/security/krb5/auto/ok-as-delegate.sh Changeset: 5ea56641276c Author: alanb Date: 2012-06-05 12:47 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/5ea56641276c 7173515: (se) Selector.open fails with OOME on Solaris when unlimited file descriptors Reviewed-by: coffeys, chegar - src/share/classes/sun/nio/ch/DevPollSelectorProvider.java ! src/solaris/classes/sun/nio/ch/DevPollArrayWrapper.java + src/solaris/classes/sun/nio/ch/DevPollSelectorProvider.java Changeset: d1f52390275b Author: sherman Date: 2012-06-05 12:11 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/d1f52390275b 6183404: Many eudc characters are incorrectly mapped in MS936 and GBK converter Summary: updated MS936 and GBK mappings Reviewed-by: alanb ! make/tools/CharsetMapping/GBK.map ! make/tools/CharsetMapping/MS936.map Changeset: 91d05db156d3 Author: lana Date: 2012-06-05 17:40 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/91d05db156d3 Merge Changeset: b6eb10d6932f Author: weijun Date: 2012-06-06 10:05 +0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/b6eb10d6932f 7174351: test/sun/security/tools/keytool/standard.sh failed after new Hashtable Reviewed-by: xuelei ! test/sun/security/tools/keytool/KeyToolTest.java Changeset: 119c9a306a3d Author: alanb Date: 2012-06-06 17:59 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/119c9a306a3d 7172826: (se) Selector based on the Solaris event port mechanism Reviewed-by: coffeys, chegar ! make/java/nio/Makefile ! make/java/nio/mapfile-linux ! make/java/nio/mapfile-solaris ! src/share/classes/sun/nio/ch/IOUtil.java ! src/solaris/classes/sun/nio/ch/DevPollArrayWrapper.java ! src/solaris/classes/sun/nio/ch/EPollArrayWrapper.java + src/solaris/classes/sun/nio/ch/EventPortSelectorImpl.java + src/solaris/classes/sun/nio/ch/EventPortSelectorProvider.java + src/solaris/classes/sun/nio/ch/EventPortWrapper.java ! src/solaris/classes/sun/nio/ch/SolarisEventPort.java ! src/solaris/native/sun/nio/ch/DevPollArrayWrapper.c ! src/solaris/native/sun/nio/ch/EPollArrayWrapper.c ! src/solaris/native/sun/nio/ch/IOUtil.c ! src/solaris/native/sun/nio/ch/SolarisEventPort.c ! test/java/nio/channels/Selector/lots_of_updates.sh ! test/java/nio/channels/SocketChannel/Open.sh ! test/sun/nio/ch/SelProvider.java Changeset: af313ded4ffb Author: khazra Date: 2012-06-06 11:37 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/af313ded4ffb 7173645: (props) System.getProperty("os.name") should return "Windows Server 2012" for Windows Server 2012 Summary: Enable Windows Server 2012 to be recognized as "os.name" Reviewed-by: alanb, dholmes, chegar ! src/windows/native/java/lang/java_props_md.c Changeset: f8e72d7ff37d Author: xuelei Date: 2012-06-06 18:18 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/f8e72d7ff37d 7174244: NPE in Krb5ProxyImpl.getServerKeys() Reviewed-by: weijun ! src/share/classes/sun/security/ssl/SSLContextImpl.java ! src/share/classes/sun/security/ssl/ServerHandshaker.java ! src/share/classes/sun/security/ssl/krb5/Krb5ProxyImpl.java + test/sun/security/ssl/sanity/ciphersuites/CipherSuitesInOrder.java Changeset: 713b10821c3d Author: xuelei Date: 2012-06-06 18:39 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/713b10821c3d 7172149: ArrayIndexOutOfBoundsException from Signature.verify Summary: take care of integer addition overflow Reviewed-by: xuelei, wetmore Contributed-by: Jonathan Lu ! src/share/classes/java/security/Signature.java + test/java/security/Signature/VerifyRangeCheckOverflow.java Changeset: 181175887d24 Author: jonas Date: 2012-06-06 13:16 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/181175887d24 7174861: all/OPT jdk build on Solaris with FDS enabled sets wrong options Summary: Use CFLAGS_COMMON instead of CC_OPT and CXXFLAGS_COMMON instead of CXX_OPT for setting FDS options. FDS should also set OPTIMIZATION_LEVEL. Reviewed-by: ihse, dholmes, ohair, dcubed ! make/common/Defs-solaris.gmk Changeset: 7543b6db3026 Author: dcubed Date: 2012-06-06 19:11 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/7543b6db3026 Merge Changeset: 636f9486fde7 Author: alanb Date: 2012-06-07 10:31 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/636f9486fde7 7175011: ProblemList.txt updates (6/2012) Reviewed-by: mduigou, chegar ! test/ProblemList.txt Changeset: 757a5129fad7 Author: alanb Date: 2012-06-07 12:31 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/757a5129fad7 7164256: EnumMap clone doesn't clear the entrySet keeping a reference to the original Map Reviewed-by: alanb, chegar, forax, mduigou Contributed-by: dbelfer at gmail.com ! src/share/classes/java/util/EnumMap.java + test/java/util/EnumMap/ProperEntrySetOnClone.java Changeset: c89018e3f3b6 Author: nloodin Date: 2012-06-05 13:43 +0200 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/c89018e3f3b6 7163471: Licensee source bundle failed around 7u4 Reviewed-by: dholmes, sla, brutisso, erikj ! make/com/oracle/Makefile Changeset: 9b814b887240 Author: weijun Date: 2012-06-07 22:33 +0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/9b814b887240 7175041: HttpTimestamper should accept https URI Reviewed-by: mullan ! src/share/classes/sun/security/timestamp/HttpTimestamper.java Changeset: 23f8be788c77 Author: alanb Date: 2012-06-07 18:42 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/23f8be788c77 7174723: TEST_BUG: java/lang/ProcessBuilder/Basic.java failing [win] Reviewed-by: mduigou ! test/java/lang/ProcessBuilder/Basic.java Changeset: fc0e508b713f Author: mduigou Date: 2012-06-07 01:01 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/fc0e508b713f 7174736: JCK test api/java_util/HashMap/index_EntrySet failing Summary: Corrects a problem with HashMap.removeEntry() that caused a JCK test to fail Reviewed-by: mduigou Contributed-by: alan.bateman at oracle.com ! src/share/classes/java/util/HashMap.java Changeset: abe465d6a9b8 Author: chegar Date: 2012-06-08 09:55 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/abe465d6a9b8 7175413: Typo in comments of JVM_SupportsCX8 in jvm.h Reviewed-by: chegar Contributed-by: Krystal Mok ! src/share/javavm/export/jvm.h Changeset: 8305ddc88a5a Author: lancea Date: 2012-06-07 20:11 -0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/8305ddc88a5a 7172551: Remove Native calls from DriverManager for jigsaw Reviewed-by: alanb, chegar, darcy, mchung ! make/java/java/FILES_c.gmk ! make/java/java/mapfile-vers ! makefiles/java/java/FILES_c.gmk ! makefiles/java/java/mapfile-vers ! src/share/classes/java/sql/DriverManager.java - src/share/native/java/sql/DriverManager.c Changeset: 7cb7bfae9d3a Author: lancea Date: 2012-06-08 09:22 -0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/7cb7bfae9d3a Merge Changeset: 82c41d3065e2 Author: sla Date: 2012-06-07 15:28 +0200 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/82c41d3065e2 7165257: Add JFR tests to the JDK code base Reviewed-by: ohair, dholmes, nloodin, mgronlun ! make/jprt.properties ! test/Makefile Changeset: 961807959c5f Author: sla Date: 2012-06-08 05:39 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/961807959c5f Merge Changeset: a7895dc61088 Author: robm Date: 2012-06-08 18:23 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/a7895dc61088 7161881: (dc) DatagramChannel.bind(null) fails if IPv4 socket and running with preferIPv6Addresses=true Reviewed-by: alanb, chegar ! src/share/classes/sun/nio/ch/DatagramChannelImpl.java + test/java/nio/channels/DatagramChannel/BindNull.java Changeset: cd195e5d2c07 Author: lana Date: 2012-06-08 12:44 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/cd195e5d2c07 Merge ! src/share/classes/sun/nio/ch/DatagramChannelImpl.java - src/share/classes/sun/nio/ch/DevPollSelectorProvider.java - src/share/classes/sun/security/provider/certpath/CrlRevocationChecker.java - src/share/classes/sun/security/provider/certpath/OCSPChecker.java - src/share/classes/sun/tools/jconsole/resources/JConsoleResources.java - src/share/classes/sun/tools/jconsole/resources/JConsoleResources_ja.java - src/share/classes/sun/tools/jconsole/resources/JConsoleResources_zh_CN.java - src/share/native/java/sql/DriverManager.c - test/sun/security/krb5/auto/ok-as-delegate-xrealm.sh - test/sun/security/krb5/auto/ok-as-delegate.sh Changeset: 898ce0cf7476 Author: ohair Date: 2012-06-07 20:40 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/898ce0cf7476 Merge ! src/macosx/classes/sun/lwawt/LWTextFieldPeer.java ! src/share/classes/sun/nio/ch/DatagramChannelImpl.java Changeset: 1953cf522107 Author: erikj Date: 2012-06-07 20:40 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/1953cf522107 7170079: Adjustments to build-infra makefiles Reviewed-by: ohair, ohrstrom, ihse, jonas Contributed-by: jonas , erikj , ihse , tgranat , ykantser ! makefiles/CompileDemos.gmk ! makefiles/CompileJavaClasses.gmk ! makefiles/CompileLaunchers.gmk ! makefiles/CompileNativeLibraries.gmk ! makefiles/CopyFiles.gmk ! makefiles/CopyIntoClasses.gmk ! makefiles/CopySamples.gmk + makefiles/CreateJars.gmk ! makefiles/GendataBreakIterator.gmk + makefiles/GendataFontConfig.gmk + makefiles/GendataHtml32dtd.gmk + makefiles/GendataTimeZone.gmk ! makefiles/GenerateClasses.gmk ! makefiles/GenerateData.gmk ! makefiles/GenerateJavaSources.gmk + makefiles/GensrcBuffer.gmk ! makefiles/GensrcCharacterData.gmk + makefiles/GensrcCharsetCoder.gmk + makefiles/GensrcCharsetMapping.gmk + makefiles/GensrcExceptions.gmk + makefiles/GensrcIcons.gmk ! makefiles/GensrcJDWP.gmk ! makefiles/GensrcLocaleDataMetaInfo.gmk ! makefiles/GensrcMisc.gmk ! makefiles/GensrcProperties.gmk + makefiles/GensrcSwing.gmk + makefiles/GensrcX11Wrappers.gmk ! makefiles/Images.gmk ! makefiles/LegacyMakefiles.gmk ! makefiles/Makefile + makefiles/OldImages.gmk ! makefiles/Setup.gmk ! makefiles/Tools.gmk - makefiles/altclasses/Makefile - makefiles/apple/Makefile - makefiles/apple/applescript/Makefile - makefiles/com/Makefile - makefiles/com/apple/Makefile - makefiles/com/apple/osx/Makefile - makefiles/com/apple/osxui/Makefile - makefiles/com/oracle/Makefile - makefiles/com/oracle/jfr/Makefile - makefiles/com/oracle/security/ucrypto/FILES_c.gmk - makefiles/com/oracle/security/ucrypto/Makefile - makefiles/com/oracle/security/ucrypto/mapfile-vers - makefiles/com/sun/Makefile ! makefiles/common/Defs-macosx.gmk ! makefiles/common/Release-macosx.gmk ! makefiles/common/Release.gmk - makefiles/common/shared/Defs-utils.gmk ! makefiles/common/shared/Defs.gmk ! makefiles/docs/CORE_PKGS.gmk ! makefiles/java/Makefile - makefiles/java/fdlibm/FILES_c.gmk - makefiles/java/fdlibm/Makefile - makefiles/java/instrument/Makefile - makefiles/java/instrument/mapfile-vers - makefiles/java/java/Exportedfiles.gmk - makefiles/java/java/FILES_c.gmk - makefiles/java/java/FILES_java.gmk - makefiles/java/java/Makefile - makefiles/java/java/localelist.sh - makefiles/java/java/mapfile-vers - makefiles/java/java/reflect/Makefile - makefiles/java/java/reorder-i586 - makefiles/java/java/reorder-sparc - makefiles/java/java/reorder-sparcv9 - makefiles/java/java_crw_demo/Makefile - makefiles/java/java_crw_demo/mapfile-vers - makefiles/java/java_hprof_demo/Makefile - makefiles/java/java_hprof_demo/mapfile-vers - makefiles/java/jexec/Makefile - makefiles/java/jli/Makefile - makefiles/java/jli/mapfile-vers - makefiles/java/jobjc/Makefile - makefiles/java/jvm/Makefile - makefiles/java/main/Makefile - makefiles/java/main/java/Makefile - makefiles/java/main/java/mapfile-amd64 - makefiles/java/main/java/mapfile-i586 - makefiles/java/main/java/mapfile-sparc - makefiles/java/main/java/mapfile-sparcv9 - makefiles/java/main/javaw/Makefile - makefiles/java/management/Exportedfiles.gmk - makefiles/java/management/FILES_c.gmk - makefiles/java/management/Makefile - makefiles/java/management/mapfile-vers - makefiles/java/net/FILES_c.gmk - makefiles/java/net/Makefile - makefiles/java/net/mapfile-vers - makefiles/java/nio/Exportedfiles.gmk - makefiles/java/nio/FILES_c.gmk - makefiles/java/nio/FILES_java.gmk - makefiles/java/nio/Makefile - makefiles/java/nio/addNotices.sh - makefiles/java/nio/genBuffer.sh - makefiles/java/nio/genCharsetProvider.sh - makefiles/java/nio/genCoder.sh - makefiles/java/nio/genExceptions.sh - makefiles/java/nio/mapfile-bsd - makefiles/java/nio/mapfile-linux - makefiles/java/nio/mapfile-solaris - makefiles/java/nio/reorder-i586 - makefiles/java/nio/reorder-sparc - makefiles/java/nio/reorder-sparcv9 - makefiles/java/npt/Makefile - makefiles/java/npt/mapfile-vers ! makefiles/java/redist/Makefile - makefiles/java/redist/fonts/Makefile - makefiles/java/security/Makefile - makefiles/java/sun_nio/FILES_java.gmk - makefiles/java/sun_nio/Makefile - makefiles/java/util/FILES_java.gmk - makefiles/java/util/FILES_properties.gmk - makefiles/java/util/Makefile - makefiles/java/verify/Makefile - makefiles/java/verify/mapfile-vers - makefiles/java/verify/reorder-i586 - makefiles/java/verify/reorder-sparc - makefiles/java/verify/reorder-sparcv9 - makefiles/javax/Makefile - makefiles/javax/imageio/Makefile - makefiles/javax/management/Makefile - makefiles/javax/sound/FILES_c.gmk - makefiles/javax/sound/Makefile - makefiles/javax/sound/SoundDefs.gmk - makefiles/javax/sound/jsoundalsa/Makefile - makefiles/javax/sound/jsoundalsa/mapfile-vers - makefiles/javax/sound/jsoundds/Makefile - makefiles/javax/sound/mapfile-vers - makefiles/javax/sql/Makefile - makefiles/javax/swing/FILES.gmk - makefiles/javax/swing/Makefile - makefiles/javax/swing/beaninfo/FILES.gmk - makefiles/javax/swing/beaninfo/Makefile - makefiles/javax/swing/beaninfo/SwingBeans.gmk - makefiles/javax/swing/beaninfo/manifest - makefiles/javax/swing/html32dtd/Makefile - makefiles/javax/swing/plaf/FILES.gmk - makefiles/javax/swing/plaf/Makefile + makefiles/mapfiles/libawt/mapfile-mawt-vers + makefiles/mapfiles/libawt/mapfile-vers + makefiles/mapfiles/libawt/mapfile-vers-linux + makefiles/mapfiles/libawt_headless/mapfile-vers + makefiles/mapfiles/libawt_headless/reorder-i586 + makefiles/mapfiles/libawt_headless/reorder-sparc + makefiles/mapfiles/libawt_headless/reorder-sparcv9 + makefiles/mapfiles/libawt_xawt/mapfile-vers + makefiles/mapfiles/libdcpr/mapfile-vers + makefiles/mapfiles/libhprof/mapfile-vers + makefiles/mapfiles/libinstrument/mapfile-vers + makefiles/mapfiles/libj2gss/mapfile-vers + makefiles/mapfiles/libj2pcsc/mapfile-vers + makefiles/mapfiles/libj2pkcs11/mapfile-vers + makefiles/mapfiles/libj2ucrypto/mapfile-vers + makefiles/mapfiles/libjava/mapfile-vers + makefiles/mapfiles/libjava/reorder-i586 + makefiles/mapfiles/libjava/reorder-sparc + makefiles/mapfiles/libjava/reorder-sparcv9 + makefiles/mapfiles/libjava_crw_demo/mapfile-vers + makefiles/mapfiles/libjdga/mapfile-vers + makefiles/mapfiles/libjfr/mapfile-vers + makefiles/mapfiles/libjli/mapfile-vers ! makefiles/mapfiles/libjpeg/reorder-i586 ! makefiles/mapfiles/libjpeg/reorder-sparc ! makefiles/mapfiles/libjpeg/reorder-sparcv9 + makefiles/mapfiles/libjsound/mapfile-vers + makefiles/mapfiles/libjsoundalsa/mapfile-vers + makefiles/mapfiles/libkcms/mapfile-vers + makefiles/mapfiles/libmanagement/mapfile-vers + makefiles/mapfiles/libmlib_image/mapfile-vers + makefiles/mapfiles/libnet/mapfile-vers + makefiles/mapfiles/libnio/mapfile-bsd + makefiles/mapfiles/libnio/mapfile-linux + makefiles/mapfiles/libnio/mapfile-solaris + makefiles/mapfiles/libnio/reorder-i586 + makefiles/mapfiles/libnio/reorder-sparc + makefiles/mapfiles/libnio/reorder-sparcv9 + makefiles/mapfiles/libnpt/mapfile-vers + makefiles/mapfiles/libsplashscreen/mapfile-vers + makefiles/mapfiles/libsunec/mapfile-vers ! makefiles/mapfiles/libverify/reorder-i586 ! makefiles/mapfiles/libverify/reorder-sparc ! makefiles/mapfiles/libverify/reorder-sparcv9 ! makefiles/mapfiles/libzip/reorder-i586 ! makefiles/mapfiles/libzip/reorder-sparc ! makefiles/mapfiles/libzip/reorder-sparcv9 + makefiles/scripts/addNotices.sh + makefiles/scripts/genCharsetProvider.sh + makefiles/scripts/genExceptions.sh + makefiles/scripts/localelist.sh - makefiles/sun/Makefile - makefiles/sun/awt/CondenseRules.awk - makefiles/sun/awt/Depend.mak - makefiles/sun/awt/Depend.sed - makefiles/sun/awt/FILES_c_macosx.gmk - makefiles/sun/awt/FILES_c_unix.gmk - makefiles/sun/awt/FILES_c_windows.gmk - makefiles/sun/awt/FILES_export_macosx.gmk - makefiles/sun/awt/FILES_export_unix.gmk - makefiles/sun/awt/FILES_export_windows.gmk - makefiles/sun/awt/Makefile - makefiles/sun/awt/README - makefiles/sun/awt/make.depend - makefiles/sun/awt/mapfile-mawt-vers - makefiles/sun/awt/mapfile-vers - makefiles/sun/awt/mapfile-vers-linux - makefiles/sun/awt/mawt.gmk - makefiles/sun/cmm/Makefile - makefiles/sun/cmm/kcms/FILES_c_unix.gmk - makefiles/sun/cmm/kcms/FILES_c_windows.gmk - makefiles/sun/cmm/kcms/Makefile - makefiles/sun/cmm/kcms/mapfile-vers - makefiles/sun/dcpr/FILES_c.gmk - makefiles/sun/dcpr/Makefile - makefiles/sun/dcpr/mapfile-vers - makefiles/sun/headless/Makefile - makefiles/sun/headless/mapfile-vers - makefiles/sun/headless/reorder-i586 - makefiles/sun/headless/reorder-sparc - makefiles/sun/headless/reorder-sparcv9 - makefiles/sun/image/Makefile - makefiles/sun/image/generic/FILES_c.gmk - makefiles/sun/image/generic/Makefile - makefiles/sun/image/generic/mapfile-vers - makefiles/sun/image/vis/FILES_c.gmk - makefiles/sun/image/vis/Makefile - makefiles/sun/javazic/Makefile - makefiles/sun/jdbc/Makefile - makefiles/sun/jdga/Makefile - makefiles/sun/jdga/mapfile-vers - makefiles/sun/lwawt/FILES_c_macosx.gmk - makefiles/sun/lwawt/FILES_export_macosx.gmk - makefiles/sun/lwawt/Makefile - makefiles/sun/nio/Makefile - makefiles/sun/nio/cs/FILES_java.gmk - makefiles/sun/nio/cs/Makefile - makefiles/sun/org/Makefile - makefiles/sun/org/mozilla/Makefile - makefiles/sun/org/mozilla/javascript/Makefile - makefiles/sun/osxapp/Makefile - makefiles/sun/security/Makefile - makefiles/sun/security/ec/FILES_c.gmk - makefiles/sun/security/ec/mapfile-vers - makefiles/sun/security/jgss/Makefile - makefiles/sun/security/jgss/wrapper/FILES_c.gmk - makefiles/sun/security/jgss/wrapper/Makefile - makefiles/sun/security/jgss/wrapper/mapfile-vers - makefiles/sun/security/krb5/FILES_c_windows.gmk - makefiles/sun/security/krb5/Makefile - makefiles/sun/security/mscapi/FILES_cpp.gmk - makefiles/sun/security/mscapi/Makefile - makefiles/sun/security/other/Makefile - makefiles/sun/security/smartcardio/FILES_c.gmk - makefiles/sun/security/smartcardio/Makefile - makefiles/sun/security/smartcardio/mapfile-vers - makefiles/sun/security/tools/Makefile - makefiles/sun/security/util/Makefile - makefiles/sun/splashscreen/FILES_c.gmk - makefiles/sun/splashscreen/Makefile - makefiles/sun/splashscreen/mapfile-vers - makefiles/sun/xawt/FILES_c_unix.gmk - makefiles/sun/xawt/FILES_export_unix.gmk - makefiles/sun/xawt/Makefile - makefiles/sun/xawt/mapfile-vers Changeset: e00f450a3c5f Author: erikj Date: 2012-06-11 09:30 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/e00f450a3c5f 7175966: Fix windows build issues for build-infra project Reviewed-by: ohair ! makefiles/CompileJavaClasses.gmk ! makefiles/java/redist/sajdi/Makefile Changeset: b3246687c369 Author: katleman Date: 2012-06-13 16:57 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/b3246687c369 Merge - makefiles/altclasses/Makefile - makefiles/apple/Makefile - makefiles/apple/applescript/Makefile - makefiles/com/Makefile - makefiles/com/apple/Makefile - makefiles/com/apple/osx/Makefile - makefiles/com/apple/osxui/Makefile - makefiles/com/oracle/Makefile - makefiles/com/oracle/jfr/Makefile - makefiles/com/oracle/security/ucrypto/FILES_c.gmk - makefiles/com/oracle/security/ucrypto/Makefile - makefiles/com/oracle/security/ucrypto/mapfile-vers - makefiles/com/sun/Makefile - makefiles/common/shared/Defs-utils.gmk - makefiles/java/fdlibm/FILES_c.gmk - makefiles/java/fdlibm/Makefile - makefiles/java/instrument/Makefile - makefiles/java/instrument/mapfile-vers - makefiles/java/java/Exportedfiles.gmk - makefiles/java/java/FILES_c.gmk - makefiles/java/java/FILES_java.gmk - makefiles/java/java/Makefile - makefiles/java/java/localelist.sh - makefiles/java/java/mapfile-vers - makefiles/java/java/reflect/Makefile - makefiles/java/java/reorder-i586 - makefiles/java/java/reorder-sparc - makefiles/java/java/reorder-sparcv9 - makefiles/java/java_crw_demo/Makefile - makefiles/java/java_crw_demo/mapfile-vers - makefiles/java/java_hprof_demo/Makefile - makefiles/java/java_hprof_demo/mapfile-vers - makefiles/java/jexec/Makefile - makefiles/java/jli/Makefile - makefiles/java/jli/mapfile-vers - makefiles/java/jobjc/Makefile - makefiles/java/jvm/Makefile - makefiles/java/main/Makefile - makefiles/java/main/java/Makefile - makefiles/java/main/java/mapfile-amd64 - makefiles/java/main/java/mapfile-i586 - makefiles/java/main/java/mapfile-sparc - makefiles/java/main/java/mapfile-sparcv9 - makefiles/java/main/javaw/Makefile - makefiles/java/management/Exportedfiles.gmk - makefiles/java/management/FILES_c.gmk - makefiles/java/management/Makefile - makefiles/java/management/mapfile-vers - makefiles/java/net/FILES_c.gmk - makefiles/java/net/Makefile - makefiles/java/net/mapfile-vers - makefiles/java/nio/Exportedfiles.gmk - makefiles/java/nio/FILES_c.gmk - makefiles/java/nio/FILES_java.gmk - makefiles/java/nio/Makefile - makefiles/java/nio/addNotices.sh - makefiles/java/nio/genBuffer.sh - makefiles/java/nio/genCharsetProvider.sh - makefiles/java/nio/genCoder.sh - makefiles/java/nio/genExceptions.sh - makefiles/java/nio/mapfile-bsd - makefiles/java/nio/mapfile-linux - makefiles/java/nio/mapfile-solaris - makefiles/java/nio/reorder-i586 - makefiles/java/nio/reorder-sparc - makefiles/java/nio/reorder-sparcv9 - makefiles/java/npt/Makefile - makefiles/java/npt/mapfile-vers - makefiles/java/redist/fonts/Makefile - makefiles/java/security/Makefile - makefiles/java/sun_nio/FILES_java.gmk - makefiles/java/sun_nio/Makefile - makefiles/java/util/FILES_java.gmk - makefiles/java/util/FILES_properties.gmk - makefiles/java/util/Makefile - makefiles/java/verify/Makefile - makefiles/java/verify/mapfile-vers - makefiles/java/verify/reorder-i586 - makefiles/java/verify/reorder-sparc - makefiles/java/verify/reorder-sparcv9 - makefiles/javax/Makefile - makefiles/javax/imageio/Makefile - makefiles/javax/management/Makefile - makefiles/javax/sound/FILES_c.gmk - makefiles/javax/sound/Makefile - makefiles/javax/sound/SoundDefs.gmk - makefiles/javax/sound/jsoundalsa/Makefile - makefiles/javax/sound/jsoundalsa/mapfile-vers - makefiles/javax/sound/jsoundds/Makefile - makefiles/javax/sound/mapfile-vers - makefiles/javax/sql/Makefile - makefiles/javax/swing/FILES.gmk - makefiles/javax/swing/Makefile - makefiles/javax/swing/beaninfo/FILES.gmk - makefiles/javax/swing/beaninfo/Makefile - makefiles/javax/swing/beaninfo/SwingBeans.gmk - makefiles/javax/swing/beaninfo/manifest - makefiles/javax/swing/html32dtd/Makefile - makefiles/javax/swing/plaf/FILES.gmk - makefiles/javax/swing/plaf/Makefile - makefiles/sun/Makefile - makefiles/sun/awt/CondenseRules.awk - makefiles/sun/awt/Depend.mak - makefiles/sun/awt/Depend.sed - makefiles/sun/awt/FILES_c_macosx.gmk - makefiles/sun/awt/FILES_c_unix.gmk - makefiles/sun/awt/FILES_c_windows.gmk - makefiles/sun/awt/FILES_export_macosx.gmk - makefiles/sun/awt/FILES_export_unix.gmk - makefiles/sun/awt/FILES_export_windows.gmk - makefiles/sun/awt/Makefile - makefiles/sun/awt/README - makefiles/sun/awt/make.depend - makefiles/sun/awt/mapfile-mawt-vers - makefiles/sun/awt/mapfile-vers - makefiles/sun/awt/mapfile-vers-linux - makefiles/sun/awt/mawt.gmk - makefiles/sun/cmm/Makefile - makefiles/sun/cmm/kcms/FILES_c_unix.gmk - makefiles/sun/cmm/kcms/FILES_c_windows.gmk - makefiles/sun/cmm/kcms/Makefile - makefiles/sun/cmm/kcms/mapfile-vers - makefiles/sun/dcpr/FILES_c.gmk - makefiles/sun/dcpr/Makefile - makefiles/sun/dcpr/mapfile-vers - makefiles/sun/headless/Makefile - makefiles/sun/headless/mapfile-vers - makefiles/sun/headless/reorder-i586 - makefiles/sun/headless/reorder-sparc - makefiles/sun/headless/reorder-sparcv9 - makefiles/sun/image/Makefile - makefiles/sun/image/generic/FILES_c.gmk - makefiles/sun/image/generic/Makefile - makefiles/sun/image/generic/mapfile-vers - makefiles/sun/image/vis/FILES_c.gmk - makefiles/sun/image/vis/Makefile - makefiles/sun/javazic/Makefile - makefiles/sun/jdbc/Makefile - makefiles/sun/jdga/Makefile - makefiles/sun/jdga/mapfile-vers - makefiles/sun/lwawt/FILES_c_macosx.gmk - makefiles/sun/lwawt/FILES_export_macosx.gmk - makefiles/sun/lwawt/Makefile - makefiles/sun/nio/Makefile - makefiles/sun/nio/cs/FILES_java.gmk - makefiles/sun/nio/cs/Makefile - makefiles/sun/org/Makefile - makefiles/sun/org/mozilla/Makefile - makefiles/sun/org/mozilla/javascript/Makefile - makefiles/sun/osxapp/Makefile - makefiles/sun/security/Makefile - makefiles/sun/security/ec/FILES_c.gmk - makefiles/sun/security/ec/mapfile-vers - makefiles/sun/security/jgss/Makefile - makefiles/sun/security/jgss/wrapper/FILES_c.gmk - makefiles/sun/security/jgss/wrapper/Makefile - makefiles/sun/security/jgss/wrapper/mapfile-vers - makefiles/sun/security/krb5/FILES_c_windows.gmk - makefiles/sun/security/krb5/Makefile - makefiles/sun/security/mscapi/FILES_cpp.gmk - makefiles/sun/security/mscapi/Makefile - makefiles/sun/security/other/Makefile - makefiles/sun/security/smartcardio/FILES_c.gmk - makefiles/sun/security/smartcardio/Makefile - makefiles/sun/security/smartcardio/mapfile-vers - makefiles/sun/security/tools/Makefile - makefiles/sun/security/util/Makefile - makefiles/sun/splashscreen/FILES_c.gmk - makefiles/sun/splashscreen/Makefile - makefiles/sun/splashscreen/mapfile-vers - makefiles/sun/xawt/FILES_c_unix.gmk - makefiles/sun/xawt/FILES_export_unix.gmk - makefiles/sun/xawt/Makefile - makefiles/sun/xawt/mapfile-vers Changeset: db471a7af031 Author: katleman Date: 2012-06-14 13:14 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/db471a7af031 Added tag jdk8-b43 for changeset b3246687c369 ! .hgtags Changeset: 9d88f2ce6338 Author: katleman Date: 2012-06-21 17:08 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/9d88f2ce6338 Added tag jdk8-b44 for changeset db471a7af031 ! .hgtags Changeset: eb50eeb2eb7d Author: prr Date: 2012-06-13 12:46 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/eb50eeb2eb7d 7027300: Unsynchronized HashMap access causes endless loop Reviewed-by: bae, jgodinez ! src/share/classes/sun/font/SunLayoutEngine.java Changeset: 5959fec806d8 Author: bae Date: 2012-06-14 11:14 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/5959fec806d8 7153693: Three 2D_ImageIO tests failed due ImageFormatException on OEL 6.* Unbreakable Kernel x64 Reviewed-by: jgodinez, prr ! src/share/native/sun/awt/image/jpeg/jpegdecoder.c Changeset: 2aa89f018a2f Author: prr Date: 2012-06-14 16:34 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/2aa89f018a2f 7158366: [macosx] Print-to-file dialog doesn't have an entry field for a name Reviewed-by: bae, jgodinez ! src/share/classes/sun/print/ServiceDialog.java Changeset: e42563f8ec12 Author: lana Date: 2012-06-17 22:07 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/e42563f8ec12 Merge - makefiles/altclasses/Makefile - makefiles/apple/Makefile - makefiles/apple/applescript/Makefile - makefiles/com/Makefile - makefiles/com/apple/Makefile - makefiles/com/apple/osx/Makefile - makefiles/com/apple/osxui/Makefile - makefiles/com/oracle/Makefile - makefiles/com/oracle/jfr/Makefile - makefiles/com/oracle/security/ucrypto/FILES_c.gmk - makefiles/com/oracle/security/ucrypto/Makefile - makefiles/com/oracle/security/ucrypto/mapfile-vers - makefiles/com/sun/Makefile - makefiles/common/shared/Defs-utils.gmk - makefiles/java/fdlibm/FILES_c.gmk - makefiles/java/fdlibm/Makefile - makefiles/java/instrument/Makefile - makefiles/java/instrument/mapfile-vers - makefiles/java/java/Exportedfiles.gmk - makefiles/java/java/FILES_c.gmk - makefiles/java/java/FILES_java.gmk - makefiles/java/java/Makefile - makefiles/java/java/localelist.sh - makefiles/java/java/mapfile-vers - makefiles/java/java/reflect/Makefile - makefiles/java/java/reorder-i586 - makefiles/java/java/reorder-sparc - makefiles/java/java/reorder-sparcv9 - makefiles/java/java_crw_demo/Makefile - makefiles/java/java_crw_demo/mapfile-vers - makefiles/java/java_hprof_demo/Makefile - makefiles/java/java_hprof_demo/mapfile-vers - makefiles/java/jexec/Makefile - makefiles/java/jli/Makefile - makefiles/java/jli/mapfile-vers - makefiles/java/jobjc/Makefile - makefiles/java/jvm/Makefile - makefiles/java/main/Makefile - makefiles/java/main/java/Makefile - makefiles/java/main/java/mapfile-amd64 - makefiles/java/main/java/mapfile-i586 - makefiles/java/main/java/mapfile-sparc - makefiles/java/main/java/mapfile-sparcv9 - makefiles/java/main/javaw/Makefile - makefiles/java/management/Exportedfiles.gmk - makefiles/java/management/FILES_c.gmk - makefiles/java/management/Makefile - makefiles/java/management/mapfile-vers - makefiles/java/net/FILES_c.gmk - makefiles/java/net/Makefile - makefiles/java/net/mapfile-vers - makefiles/java/nio/Exportedfiles.gmk - makefiles/java/nio/FILES_c.gmk - makefiles/java/nio/FILES_java.gmk - makefiles/java/nio/Makefile - makefiles/java/nio/addNotices.sh - makefiles/java/nio/genBuffer.sh - makefiles/java/nio/genCharsetProvider.sh - makefiles/java/nio/genCoder.sh - makefiles/java/nio/genExceptions.sh - makefiles/java/nio/mapfile-bsd - makefiles/java/nio/mapfile-linux - makefiles/java/nio/mapfile-solaris - makefiles/java/nio/reorder-i586 - makefiles/java/nio/reorder-sparc - makefiles/java/nio/reorder-sparcv9 - makefiles/java/npt/Makefile - makefiles/java/npt/mapfile-vers - makefiles/java/redist/fonts/Makefile - makefiles/java/security/Makefile - makefiles/java/sun_nio/FILES_java.gmk - makefiles/java/sun_nio/Makefile - makefiles/java/util/FILES_java.gmk - makefiles/java/util/FILES_properties.gmk - makefiles/java/util/Makefile - makefiles/java/verify/Makefile - makefiles/java/verify/mapfile-vers - makefiles/java/verify/reorder-i586 - makefiles/java/verify/reorder-sparc - makefiles/java/verify/reorder-sparcv9 - makefiles/javax/Makefile - makefiles/javax/imageio/Makefile - makefiles/javax/management/Makefile - makefiles/javax/sound/FILES_c.gmk - makefiles/javax/sound/Makefile - makefiles/javax/sound/SoundDefs.gmk - makefiles/javax/sound/jsoundalsa/Makefile - makefiles/javax/sound/jsoundalsa/mapfile-vers - makefiles/javax/sound/jsoundds/Makefile - makefiles/javax/sound/mapfile-vers - makefiles/javax/sql/Makefile - makefiles/javax/swing/FILES.gmk - makefiles/javax/swing/Makefile - makefiles/javax/swing/beaninfo/FILES.gmk - makefiles/javax/swing/beaninfo/Makefile - makefiles/javax/swing/beaninfo/SwingBeans.gmk - makefiles/javax/swing/beaninfo/manifest - makefiles/javax/swing/html32dtd/Makefile - makefiles/javax/swing/plaf/FILES.gmk - makefiles/javax/swing/plaf/Makefile - makefiles/sun/Makefile - makefiles/sun/awt/CondenseRules.awk - makefiles/sun/awt/Depend.mak - makefiles/sun/awt/Depend.sed - makefiles/sun/awt/FILES_c_macosx.gmk - makefiles/sun/awt/FILES_c_unix.gmk - makefiles/sun/awt/FILES_c_windows.gmk - makefiles/sun/awt/FILES_export_macosx.gmk - makefiles/sun/awt/FILES_export_unix.gmk - makefiles/sun/awt/FILES_export_windows.gmk - makefiles/sun/awt/Makefile - makefiles/sun/awt/README - makefiles/sun/awt/make.depend - makefiles/sun/awt/mapfile-mawt-vers - makefiles/sun/awt/mapfile-vers - makefiles/sun/awt/mapfile-vers-linux - makefiles/sun/awt/mawt.gmk - makefiles/sun/cmm/Makefile - makefiles/sun/cmm/kcms/FILES_c_unix.gmk - makefiles/sun/cmm/kcms/FILES_c_windows.gmk - makefiles/sun/cmm/kcms/Makefile - makefiles/sun/cmm/kcms/mapfile-vers - makefiles/sun/dcpr/FILES_c.gmk - makefiles/sun/dcpr/Makefile - makefiles/sun/dcpr/mapfile-vers - makefiles/sun/headless/Makefile - makefiles/sun/headless/mapfile-vers - makefiles/sun/headless/reorder-i586 - makefiles/sun/headless/reorder-sparc - makefiles/sun/headless/reorder-sparcv9 - makefiles/sun/image/Makefile - makefiles/sun/image/generic/FILES_c.gmk - makefiles/sun/image/generic/Makefile - makefiles/sun/image/generic/mapfile-vers - makefiles/sun/image/vis/FILES_c.gmk - makefiles/sun/image/vis/Makefile - makefiles/sun/javazic/Makefile - makefiles/sun/jdbc/Makefile - makefiles/sun/jdga/Makefile - makefiles/sun/jdga/mapfile-vers - makefiles/sun/lwawt/FILES_c_macosx.gmk - makefiles/sun/lwawt/FILES_export_macosx.gmk - makefiles/sun/lwawt/Makefile - makefiles/sun/nio/Makefile - makefiles/sun/nio/cs/FILES_java.gmk - makefiles/sun/nio/cs/Makefile - makefiles/sun/org/Makefile - makefiles/sun/org/mozilla/Makefile - makefiles/sun/org/mozilla/javascript/Makefile - makefiles/sun/osxapp/Makefile - makefiles/sun/security/Makefile - makefiles/sun/security/ec/FILES_c.gmk - makefiles/sun/security/ec/mapfile-vers - makefiles/sun/security/jgss/Makefile - makefiles/sun/security/jgss/wrapper/FILES_c.gmk - makefiles/sun/security/jgss/wrapper/Makefile - makefiles/sun/security/jgss/wrapper/mapfile-vers - makefiles/sun/security/krb5/FILES_c_windows.gmk - makefiles/sun/security/krb5/Makefile - makefiles/sun/security/mscapi/FILES_cpp.gmk - makefiles/sun/security/mscapi/Makefile - makefiles/sun/security/other/Makefile - makefiles/sun/security/smartcardio/FILES_c.gmk - makefiles/sun/security/smartcardio/Makefile - makefiles/sun/security/smartcardio/mapfile-vers - makefiles/sun/security/tools/Makefile - makefiles/sun/security/util/Makefile - makefiles/sun/splashscreen/FILES_c.gmk - makefiles/sun/splashscreen/Makefile - makefiles/sun/splashscreen/mapfile-vers - makefiles/sun/xawt/FILES_c_unix.gmk - makefiles/sun/xawt/FILES_export_unix.gmk - makefiles/sun/xawt/Makefile - makefiles/sun/xawt/mapfile-vers - src/share/classes/sun/nio/ch/DevPollSelectorProvider.java - src/share/classes/sun/security/provider/certpath/CrlRevocationChecker.java - src/share/classes/sun/security/provider/certpath/OCSPChecker.java - src/share/classes/sun/tools/jconsole/resources/JConsoleResources.java - src/share/classes/sun/tools/jconsole/resources/JConsoleResources_ja.java - src/share/classes/sun/tools/jconsole/resources/JConsoleResources_zh_CN.java - src/share/native/java/sql/DriverManager.c - test/sun/security/krb5/auto/ok-as-delegate-xrealm.sh - test/sun/security/krb5/auto/ok-as-delegate.sh Changeset: b8ff85860648 Author: prr Date: 2012-06-19 09:07 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/b8ff85860648 7124536: [macosx] PrintServiceLookup.lookupDefaultPrintService() return null Reviewed-by: bae, igor ! src/solaris/classes/sun/print/CUPSPrinter.java ! src/solaris/classes/sun/print/UnixPrintServiceLookup.java Changeset: c05893704c82 Author: lana Date: 2012-06-25 21:34 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/c05893704c82 Merge Changeset: 45259658e158 Author: rupashka Date: 2012-06-09 17:42 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/45259658e158 7165725: JAVA6 HTML PARSER CANNOT PARSE MULTIPLE SCRIPT TAGS IN A LINE CORRECTLY Reviewed-by: alexsch ! src/share/classes/javax/swing/text/html/parser/Parser.java + test/javax/swing/text/html/parser/Parser/7165725/bug7165725.java + test/javax/swing/text/html/parser/Parser/7165725/false-text-after-script.html + test/javax/swing/text/html/parser/Parser/7165725/successive-script-tag.html Changeset: 0474e0ed2ef2 Author: kizune Date: 2012-06-09 19:18 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/0474e0ed2ef2 7173487: closed/java/awt/Frame/RemoveNotifyTest/RemoveNotifyTest.html Reviewed-by: anthony, dcherepanov, serb ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java Changeset: b57167b71169 Author: luchsh Date: 2012-06-11 10:52 +0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/b57167b71169 7155887: ComboBox does not display focus outline in GTK L&F Reviewed-by: rupashka ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKPainter.java Changeset: f05e517a74b3 Author: anthony Date: 2012-06-13 18:33 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/f05e517a74b3 7176644: [macosx] Missing NSAutoreleasePool in CGLGraphicsConfig.m OGLGC_DestroyOGLGraphicsConfig Summary: Create and drain an autorelease pool Reviewed-by: anthony, dcherepanov Contributed-by: Tomas Hurka ! src/macosx/native/sun/java2d/opengl/CGLGraphicsConfig.m Changeset: f90369b3d61d Author: alexsch Date: 2012-06-13 18:43 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/f90369b3d61d 7150049: [macosx] closed/javax/swing/JCheckBox/4449413/bug4449413.java check the checkbox again,it auto fail Reviewed-by: rupashka + test/javax/swing/JCheckBox/4449413/bug4449413.html + test/javax/swing/JCheckBox/4449413/bug4449413.java Changeset: 8326709c6315 Author: kizune Date: 2012-06-15 18:28 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/8326709c6315 7171163: [macosx] Shortcomings in the design of the secondary native event loop made JavaFX DnD deadlock Reviewed-by: anthony, art ! src/macosx/classes/sun/lwawt/macosx/CToolkitThreadBlockedHandler.java ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/macosx/native/sun/awt/LWCToolkit.m ! src/share/classes/sun/awt/dnd/SunDropTargetContextPeer.java Changeset: f709f8ebebd4 Author: lana Date: 2012-06-17 22:03 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/f709f8ebebd4 Merge - makefiles/altclasses/Makefile - makefiles/apple/Makefile - makefiles/apple/applescript/Makefile - makefiles/com/Makefile - makefiles/com/apple/Makefile - makefiles/com/apple/osx/Makefile - makefiles/com/apple/osxui/Makefile - makefiles/com/oracle/Makefile - makefiles/com/oracle/jfr/Makefile - makefiles/com/oracle/security/ucrypto/FILES_c.gmk - makefiles/com/oracle/security/ucrypto/Makefile - makefiles/com/oracle/security/ucrypto/mapfile-vers - makefiles/com/sun/Makefile - makefiles/common/shared/Defs-utils.gmk - makefiles/java/fdlibm/FILES_c.gmk - makefiles/java/fdlibm/Makefile - makefiles/java/instrument/Makefile - makefiles/java/instrument/mapfile-vers - makefiles/java/java/Exportedfiles.gmk - makefiles/java/java/FILES_c.gmk - makefiles/java/java/FILES_java.gmk - makefiles/java/java/Makefile - makefiles/java/java/localelist.sh - makefiles/java/java/mapfile-vers - makefiles/java/java/reflect/Makefile - makefiles/java/java/reorder-i586 - makefiles/java/java/reorder-sparc - makefiles/java/java/reorder-sparcv9 - makefiles/java/java_crw_demo/Makefile - makefiles/java/java_crw_demo/mapfile-vers - makefiles/java/java_hprof_demo/Makefile - makefiles/java/java_hprof_demo/mapfile-vers - makefiles/java/jexec/Makefile - makefiles/java/jli/Makefile - makefiles/java/jli/mapfile-vers - makefiles/java/jobjc/Makefile - makefiles/java/jvm/Makefile - makefiles/java/main/Makefile - makefiles/java/main/java/Makefile - makefiles/java/main/java/mapfile-amd64 - makefiles/java/main/java/mapfile-i586 - makefiles/java/main/java/mapfile-sparc - makefiles/java/main/java/mapfile-sparcv9 - makefiles/java/main/javaw/Makefile - makefiles/java/management/Exportedfiles.gmk - makefiles/java/management/FILES_c.gmk - makefiles/java/management/Makefile - makefiles/java/management/mapfile-vers - makefiles/java/net/FILES_c.gmk - makefiles/java/net/Makefile - makefiles/java/net/mapfile-vers - makefiles/java/nio/Exportedfiles.gmk - makefiles/java/nio/FILES_c.gmk - makefiles/java/nio/FILES_java.gmk - makefiles/java/nio/Makefile - makefiles/java/nio/addNotices.sh - makefiles/java/nio/genBuffer.sh - makefiles/java/nio/genCharsetProvider.sh - makefiles/java/nio/genCoder.sh - makefiles/java/nio/genExceptions.sh - makefiles/java/nio/mapfile-bsd - makefiles/java/nio/mapfile-linux - makefiles/java/nio/mapfile-solaris - makefiles/java/nio/reorder-i586 - makefiles/java/nio/reorder-sparc - makefiles/java/nio/reorder-sparcv9 - makefiles/java/npt/Makefile - makefiles/java/npt/mapfile-vers - makefiles/java/redist/fonts/Makefile - makefiles/java/security/Makefile - makefiles/java/sun_nio/FILES_java.gmk - makefiles/java/sun_nio/Makefile - makefiles/java/util/FILES_java.gmk - makefiles/java/util/FILES_properties.gmk - makefiles/java/util/Makefile - makefiles/java/verify/Makefile - makefiles/java/verify/mapfile-vers - makefiles/java/verify/reorder-i586 - makefiles/java/verify/reorder-sparc - makefiles/java/verify/reorder-sparcv9 - makefiles/javax/Makefile - makefiles/javax/imageio/Makefile - makefiles/javax/management/Makefile - makefiles/javax/sound/FILES_c.gmk - makefiles/javax/sound/Makefile - makefiles/javax/sound/SoundDefs.gmk - makefiles/javax/sound/jsoundalsa/Makefile - makefiles/javax/sound/jsoundalsa/mapfile-vers - makefiles/javax/sound/jsoundds/Makefile - makefiles/javax/sound/mapfile-vers - makefiles/javax/sql/Makefile - makefiles/javax/swing/FILES.gmk - makefiles/javax/swing/Makefile - makefiles/javax/swing/beaninfo/FILES.gmk - makefiles/javax/swing/beaninfo/Makefile - makefiles/javax/swing/beaninfo/SwingBeans.gmk - makefiles/javax/swing/beaninfo/manifest - makefiles/javax/swing/html32dtd/Makefile - makefiles/javax/swing/plaf/FILES.gmk - makefiles/javax/swing/plaf/Makefile - makefiles/sun/Makefile - makefiles/sun/awt/CondenseRules.awk - makefiles/sun/awt/Depend.mak - makefiles/sun/awt/Depend.sed - makefiles/sun/awt/FILES_c_macosx.gmk - makefiles/sun/awt/FILES_c_unix.gmk - makefiles/sun/awt/FILES_c_windows.gmk - makefiles/sun/awt/FILES_export_macosx.gmk - makefiles/sun/awt/FILES_export_unix.gmk - makefiles/sun/awt/FILES_export_windows.gmk - makefiles/sun/awt/Makefile - makefiles/sun/awt/README - makefiles/sun/awt/make.depend - makefiles/sun/awt/mapfile-mawt-vers - makefiles/sun/awt/mapfile-vers - makefiles/sun/awt/mapfile-vers-linux - makefiles/sun/awt/mawt.gmk - makefiles/sun/cmm/Makefile - makefiles/sun/cmm/kcms/FILES_c_unix.gmk - makefiles/sun/cmm/kcms/FILES_c_windows.gmk - makefiles/sun/cmm/kcms/Makefile - makefiles/sun/cmm/kcms/mapfile-vers - makefiles/sun/dcpr/FILES_c.gmk - makefiles/sun/dcpr/Makefile - makefiles/sun/dcpr/mapfile-vers - makefiles/sun/headless/Makefile - makefiles/sun/headless/mapfile-vers - makefiles/sun/headless/reorder-i586 - makefiles/sun/headless/reorder-sparc - makefiles/sun/headless/reorder-sparcv9 - makefiles/sun/image/Makefile - makefiles/sun/image/generic/FILES_c.gmk - makefiles/sun/image/generic/Makefile - makefiles/sun/image/generic/mapfile-vers - makefiles/sun/image/vis/FILES_c.gmk - makefiles/sun/image/vis/Makefile - makefiles/sun/javazic/Makefile - makefiles/sun/jdbc/Makefile - makefiles/sun/jdga/Makefile - makefiles/sun/jdga/mapfile-vers - makefiles/sun/lwawt/FILES_c_macosx.gmk - makefiles/sun/lwawt/FILES_export_macosx.gmk - makefiles/sun/lwawt/Makefile - makefiles/sun/nio/Makefile - makefiles/sun/nio/cs/FILES_java.gmk - makefiles/sun/nio/cs/Makefile - makefiles/sun/org/Makefile - makefiles/sun/org/mozilla/Makefile - makefiles/sun/org/mozilla/javascript/Makefile - makefiles/sun/osxapp/Makefile - makefiles/sun/security/Makefile - makefiles/sun/security/ec/FILES_c.gmk - makefiles/sun/security/ec/mapfile-vers - makefiles/sun/security/jgss/Makefile - makefiles/sun/security/jgss/wrapper/FILES_c.gmk - makefiles/sun/security/jgss/wrapper/Makefile - makefiles/sun/security/jgss/wrapper/mapfile-vers - makefiles/sun/security/krb5/FILES_c_windows.gmk - makefiles/sun/security/krb5/Makefile - makefiles/sun/security/mscapi/FILES_cpp.gmk - makefiles/sun/security/mscapi/Makefile - makefiles/sun/security/other/Makefile - makefiles/sun/security/smartcardio/FILES_c.gmk - makefiles/sun/security/smartcardio/Makefile - makefiles/sun/security/smartcardio/mapfile-vers - makefiles/sun/security/tools/Makefile - makefiles/sun/security/util/Makefile - makefiles/sun/splashscreen/FILES_c.gmk - makefiles/sun/splashscreen/Makefile - makefiles/sun/splashscreen/mapfile-vers - makefiles/sun/xawt/FILES_c_unix.gmk - makefiles/sun/xawt/FILES_export_unix.gmk - makefiles/sun/xawt/Makefile - makefiles/sun/xawt/mapfile-vers - src/share/classes/sun/nio/ch/DevPollSelectorProvider.java - src/share/classes/sun/security/provider/certpath/CrlRevocationChecker.java - src/share/classes/sun/security/provider/certpath/OCSPChecker.java - src/share/classes/sun/tools/jconsole/resources/JConsoleResources.java - src/share/classes/sun/tools/jconsole/resources/JConsoleResources_ja.java - src/share/classes/sun/tools/jconsole/resources/JConsoleResources_zh_CN.java - src/share/native/java/sql/DriverManager.c - test/sun/security/krb5/auto/ok-as-delegate-xrealm.sh - test/sun/security/krb5/auto/ok-as-delegate.sh Changeset: 4b470e9017da Author: alexsch Date: 2012-06-18 15:39 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/4b470e9017da 7174970: NLS [ccjk] Extra mnemonic keys at standard filechooserdialog (open and save) in metal L&F Reviewed-by: rupashka ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_de.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_es.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_fr.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_it.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ja.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ko.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_pt_BR.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_sv.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_CN.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_TW.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_de.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_es.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_fr.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_it.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_ja.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_ko.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_pt_BR.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_sv.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_zh_CN.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_zh_TW.properties Changeset: 3226f1968e77 Author: kizune Date: 2012-06-19 21:09 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/3226f1968e77 7172430: [macosx] debug message in non debug jdk build Reviewed-by: anthony, serb ! src/macosx/native/sun/awt/AWTView.m Changeset: e7dc778d768e Author: anthony Date: 2012-06-22 16:32 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/e7dc778d768e 7170716: JVM crash when opening an AWT app from a registered file. Summary: Copy the queued blocks to prevent their deallocation Reviewed-by: anthony, swingler Contributed-by: Marco Dinacci ! src/macosx/native/sun/osxapp/QueuingApplicationDelegate.h ! src/macosx/native/sun/osxapp/QueuingApplicationDelegate.m Changeset: cafcc94a11a7 Author: anthony Date: 2012-06-25 17:27 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/cafcc94a11a7 7174718: [macosx] Regression in 7u6 b12: PopupFactory leaks DefaultFrames. Summary: Fix memory management Reviewed-by: art, serb ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/native/sun/awt/AWTWindow.m Changeset: 6dae09c6759e Author: lana Date: 2012-06-25 21:36 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/6dae09c6759e Merge Changeset: fc575c78f5d3 Author: alanb Date: 2012-06-10 10:29 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/fc575c78f5d3 7175775: Disable SA options in jinfo/Basic.java test until SA updated for new hash and String count/offset Reviewed-by: minqi ! test/sun/tools/jinfo/Basic.sh Changeset: 46ff1b63b0c3 Author: lancea Date: 2012-06-11 07:10 -0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/46ff1b63b0c3 7171917: CachedRowSetImpl.populate does not handle map properly Reviewed-by: joehw ! src/share/classes/com/sun/rowset/CachedRowSetImpl.java Changeset: 6b6a73e8c036 Author: lancea Date: 2012-06-12 17:32 -0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/6b6a73e8c036 7171918: XmlReaderContentHandler.endElement does not handle a Delete Tag properly Reviewed-by: joehw ! src/share/classes/com/sun/rowset/internal/XmlReaderContentHandler.java Changeset: 9fd127ff51d5 Author: ohair Date: 2012-06-12 13:54 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/9fd127ff51d5 7176138: Fixes for missing close() calls and possible null pointer reference instead of fatal error Reviewed-by: dcubed ! src/share/demo/jvmti/hprof/hprof_table.c ! src/solaris/demo/jvmti/hprof/hprof_md.c Changeset: 7b93a2a9cd15 Author: ohair Date: 2012-06-12 15:16 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/7b93a2a9cd15 Merge Changeset: 4435f8b20d08 Author: weijun Date: 2012-06-13 19:23 +0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/4435f8b20d08 7176574: sun/security/krb5/auto/TcpTimeout.java failed with solaris-i586 Reviewed-by: chegar ! test/sun/security/krb5/auto/TcpTimeout.java Changeset: 4f99d146fce0 Author: alanb Date: 2012-06-14 12:13 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/4f99d146fce0 7176630: (sc) SocketChannel.write does not write more than 128k when channel configured blocking [win] Reviewed-by: khazra, chegar ! src/windows/native/sun/nio/ch/SocketDispatcher.c + test/java/nio/channels/SocketChannel/ShortWrite.java Changeset: 505455116320 Author: mduigou Date: 2012-06-13 16:48 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/505455116320 7173919: Minor optimization of hashing methods Summary: several minor optimizations to hashing methods used by hash map classes Reviewed-by: dholmes ! src/share/classes/java/util/HashMap.java ! src/share/classes/java/util/Hashtable.java ! src/share/classes/java/util/WeakHashMap.java ! src/share/classes/java/util/concurrent/ConcurrentHashMap.java Changeset: 28588ace1fb9 Author: lancea Date: 2012-06-14 15:05 -0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/28588ace1fb9 7145913: CachedRowSetSwriter.insertNewRow() throws SQLException Reviewed-by: joehw, naoto, psandoz, forax ! src/share/classes/com/sun/rowset/internal/CachedRowSetWriter.java Changeset: 00c9d6cce3ec Author: coffeys Date: 2012-06-15 14:16 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/00c9d6cce3ec 7156963: Incorrect copyright header in java/io/SerialCallbackContext Reviewed-by: weijun, coffeys Contributed-by: edvard.wendelin at oracle.com ! src/share/classes/java/io/SerialCallbackContext.java Changeset: 8deec0d1fc6f Author: mullan Date: 2012-06-15 08:43 -0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/8deec0d1fc6f 7176326: CertPath/CertPathBuilderTest failures after webrev 6854712_6637288_7126011 Reviewed-by: xuelei ! src/share/classes/sun/security/provider/certpath/BasicChecker.java + test/java/security/cert/CertPathBuilder/zeroLengthPath/ZeroLengthPath.java Changeset: 0e382512610f Author: mullan Date: 2012-06-15 08:47 -0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/0e382512610f Merge Changeset: e01b47409e37 Author: mullan Date: 2012-06-15 09:16 -0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/e01b47409e37 Merge Changeset: 23394d686f74 Author: alanb Date: 2012-06-15 17:16 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/23394d686f74 7176485: (bf) Allow temporary buffer cache to grow to IOV_MAX Reviewed-by: chegar, coffeys ! make/java/nio/mapfile-linux ! make/java/nio/mapfile-solaris ! src/share/classes/sun/nio/ch/IOUtil.java ! src/share/classes/sun/nio/ch/Util.java ! src/solaris/native/sun/nio/ch/FileDispatcherImpl.c ! src/solaris/native/sun/nio/ch/IOUtil.c ! src/windows/native/sun/nio/ch/IOUtil.c ! src/windows/native/sun/nio/ch/SocketDispatcher.c ! src/windows/native/sun/nio/ch/nio_util.h Changeset: e60cedd3a4aa Author: mduigou Date: 2012-06-15 13:01 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/e60cedd3a4aa 7175758: Improve unit test of Map iterators and Iterator.remove() Summary: Adds additional tests of Map iterators and Iterator.remove() Reviewed-by: lancea ! test/java/util/Map/Collisions.java Changeset: 8e5635ded425 Author: wetmore Date: 2012-06-15 17:42 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/8e5635ded425 7177556: Put TestProviderLeak.java on the ProblemList until test can be reworked Reviewed-by: khazra ! test/ProblemList.txt Changeset: 6b40703aad55 Author: lana Date: 2012-06-17 21:34 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/6b40703aad55 Merge - makefiles/altclasses/Makefile - makefiles/apple/Makefile - makefiles/apple/applescript/Makefile - makefiles/com/Makefile - makefiles/com/apple/Makefile - makefiles/com/apple/osx/Makefile - makefiles/com/apple/osxui/Makefile - makefiles/com/oracle/Makefile - makefiles/com/oracle/jfr/Makefile - makefiles/com/oracle/security/ucrypto/FILES_c.gmk - makefiles/com/oracle/security/ucrypto/Makefile - makefiles/com/oracle/security/ucrypto/mapfile-vers - makefiles/com/sun/Makefile - makefiles/common/shared/Defs-utils.gmk - makefiles/java/fdlibm/FILES_c.gmk - makefiles/java/fdlibm/Makefile - makefiles/java/instrument/Makefile - makefiles/java/instrument/mapfile-vers - makefiles/java/java/Exportedfiles.gmk - makefiles/java/java/FILES_c.gmk - makefiles/java/java/FILES_java.gmk - makefiles/java/java/Makefile - makefiles/java/java/localelist.sh - makefiles/java/java/mapfile-vers - makefiles/java/java/reflect/Makefile - makefiles/java/java/reorder-i586 - makefiles/java/java/reorder-sparc - makefiles/java/java/reorder-sparcv9 - makefiles/java/java_crw_demo/Makefile - makefiles/java/java_crw_demo/mapfile-vers - makefiles/java/java_hprof_demo/Makefile - makefiles/java/java_hprof_demo/mapfile-vers - makefiles/java/jexec/Makefile - makefiles/java/jli/Makefile - makefiles/java/jli/mapfile-vers - makefiles/java/jobjc/Makefile - makefiles/java/jvm/Makefile - makefiles/java/main/Makefile - makefiles/java/main/java/Makefile - makefiles/java/main/java/mapfile-amd64 - makefiles/java/main/java/mapfile-i586 - makefiles/java/main/java/mapfile-sparc - makefiles/java/main/java/mapfile-sparcv9 - makefiles/java/main/javaw/Makefile - makefiles/java/management/Exportedfiles.gmk - makefiles/java/management/FILES_c.gmk - makefiles/java/management/Makefile - makefiles/java/management/mapfile-vers - makefiles/java/net/FILES_c.gmk - makefiles/java/net/Makefile - makefiles/java/net/mapfile-vers - makefiles/java/nio/Exportedfiles.gmk - makefiles/java/nio/FILES_c.gmk - makefiles/java/nio/FILES_java.gmk - makefiles/java/nio/Makefile - makefiles/java/nio/addNotices.sh - makefiles/java/nio/genBuffer.sh - makefiles/java/nio/genCharsetProvider.sh - makefiles/java/nio/genCoder.sh - makefiles/java/nio/genExceptions.sh - makefiles/java/nio/mapfile-bsd - makefiles/java/nio/mapfile-linux - makefiles/java/nio/mapfile-solaris - makefiles/java/nio/reorder-i586 - makefiles/java/nio/reorder-sparc - makefiles/java/nio/reorder-sparcv9 - makefiles/java/npt/Makefile - makefiles/java/npt/mapfile-vers - makefiles/java/redist/fonts/Makefile - makefiles/java/security/Makefile - makefiles/java/sun_nio/FILES_java.gmk - makefiles/java/sun_nio/Makefile - makefiles/java/util/FILES_java.gmk - makefiles/java/util/FILES_properties.gmk - makefiles/java/util/Makefile - makefiles/java/verify/Makefile - makefiles/java/verify/mapfile-vers - makefiles/java/verify/reorder-i586 - makefiles/java/verify/reorder-sparc - makefiles/java/verify/reorder-sparcv9 - makefiles/javax/Makefile - makefiles/javax/imageio/Makefile - makefiles/javax/management/Makefile - makefiles/javax/sound/FILES_c.gmk - makefiles/javax/sound/Makefile - makefiles/javax/sound/SoundDefs.gmk - makefiles/javax/sound/jsoundalsa/Makefile - makefiles/javax/sound/jsoundalsa/mapfile-vers - makefiles/javax/sound/jsoundds/Makefile - makefiles/javax/sound/mapfile-vers - makefiles/javax/sql/Makefile - makefiles/javax/swing/FILES.gmk - makefiles/javax/swing/Makefile - makefiles/javax/swing/beaninfo/FILES.gmk - makefiles/javax/swing/beaninfo/Makefile - makefiles/javax/swing/beaninfo/SwingBeans.gmk - makefiles/javax/swing/beaninfo/manifest - makefiles/javax/swing/html32dtd/Makefile - makefiles/javax/swing/plaf/FILES.gmk - makefiles/javax/swing/plaf/Makefile - makefiles/sun/Makefile - makefiles/sun/awt/CondenseRules.awk - makefiles/sun/awt/Depend.mak - makefiles/sun/awt/Depend.sed - makefiles/sun/awt/FILES_c_macosx.gmk - makefiles/sun/awt/FILES_c_unix.gmk - makefiles/sun/awt/FILES_c_windows.gmk - makefiles/sun/awt/FILES_export_macosx.gmk - makefiles/sun/awt/FILES_export_unix.gmk - makefiles/sun/awt/FILES_export_windows.gmk - makefiles/sun/awt/Makefile - makefiles/sun/awt/README - makefiles/sun/awt/make.depend - makefiles/sun/awt/mapfile-mawt-vers - makefiles/sun/awt/mapfile-vers - makefiles/sun/awt/mapfile-vers-linux - makefiles/sun/awt/mawt.gmk - makefiles/sun/cmm/Makefile - makefiles/sun/cmm/kcms/FILES_c_unix.gmk - makefiles/sun/cmm/kcms/FILES_c_windows.gmk - makefiles/sun/cmm/kcms/Makefile - makefiles/sun/cmm/kcms/mapfile-vers - makefiles/sun/dcpr/FILES_c.gmk - makefiles/sun/dcpr/Makefile - makefiles/sun/dcpr/mapfile-vers - makefiles/sun/headless/Makefile - makefiles/sun/headless/mapfile-vers - makefiles/sun/headless/reorder-i586 - makefiles/sun/headless/reorder-sparc - makefiles/sun/headless/reorder-sparcv9 - makefiles/sun/image/Makefile - makefiles/sun/image/generic/FILES_c.gmk - makefiles/sun/image/generic/Makefile - makefiles/sun/image/generic/mapfile-vers - makefiles/sun/image/vis/FILES_c.gmk - makefiles/sun/image/vis/Makefile - makefiles/sun/javazic/Makefile - makefiles/sun/jdbc/Makefile - makefiles/sun/jdga/Makefile - makefiles/sun/jdga/mapfile-vers - makefiles/sun/lwawt/FILES_c_macosx.gmk - makefiles/sun/lwawt/FILES_export_macosx.gmk - makefiles/sun/lwawt/Makefile - makefiles/sun/nio/Makefile - makefiles/sun/nio/cs/FILES_java.gmk - makefiles/sun/nio/cs/Makefile - makefiles/sun/org/Makefile - makefiles/sun/org/mozilla/Makefile - makefiles/sun/org/mozilla/javascript/Makefile - makefiles/sun/osxapp/Makefile - makefiles/sun/security/Makefile - makefiles/sun/security/ec/FILES_c.gmk - makefiles/sun/security/ec/mapfile-vers - makefiles/sun/security/jgss/Makefile - makefiles/sun/security/jgss/wrapper/FILES_c.gmk - makefiles/sun/security/jgss/wrapper/Makefile - makefiles/sun/security/jgss/wrapper/mapfile-vers - makefiles/sun/security/krb5/FILES_c_windows.gmk - makefiles/sun/security/krb5/Makefile - makefiles/sun/security/mscapi/FILES_cpp.gmk - makefiles/sun/security/mscapi/Makefile - makefiles/sun/security/other/Makefile - makefiles/sun/security/smartcardio/FILES_c.gmk - makefiles/sun/security/smartcardio/Makefile - makefiles/sun/security/smartcardio/mapfile-vers - makefiles/sun/security/tools/Makefile - makefiles/sun/security/util/Makefile - makefiles/sun/splashscreen/FILES_c.gmk - makefiles/sun/splashscreen/Makefile - makefiles/sun/splashscreen/mapfile-vers - makefiles/sun/xawt/FILES_c_unix.gmk - makefiles/sun/xawt/FILES_export_unix.gmk - makefiles/sun/xawt/Makefile - makefiles/sun/xawt/mapfile-vers Changeset: 689129c71ccd Author: alanb Date: 2012-06-18 11:19 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/689129c71ccd 7177617: TEST_BUG: java/nio/channels/AsyncCloseAndInterrupt.java failing (win) Reviewed-by: chegar, coffeys ! test/java/nio/channels/AsyncCloseAndInterrupt.java ! test/java/nio/channels/SocketChannel/AdaptSocket.java + test/java/nio/channels/SocketChannel/CloseDuringWrite.java ! test/java/nio/channels/TestUtil.java Changeset: 4419c8f0b2f2 Author: okutsu Date: 2012-06-19 16:21 +0900 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/4419c8f0b2f2 6380549: (rb) ResourceBundle.Control global binding support Reviewed-by: naoto ! make/java/java/FILES_java.gmk ! src/share/classes/java/util/ResourceBundle.java + src/share/classes/java/util/spi/ResourceBundleControlProvider.java + test/java/util/spi/ResourceBundleControlProvider/UserDefaultControlTest.java + test/java/util/spi/ResourceBundleControlProvider/UserDefaultControlTest.sh + test/java/util/spi/ResourceBundleControlProvider/providersrc/Makefile + test/java/util/spi/ResourceBundleControlProvider/providersrc/UserControlProvider.java + test/java/util/spi/ResourceBundleControlProvider/providersrc/UserXMLControl.java + test/java/util/spi/ResourceBundleControlProvider/providersrc/XmlRB.xml + test/java/util/spi/ResourceBundleControlProvider/providersrc/XmlRB_ja.xml + test/java/util/spi/ResourceBundleControlProvider/providersrc/java.util.spi.ResourceBundleControlProvider + test/java/util/spi/ResourceBundleControlProvider/rbcontrolprovider.jar Changeset: efc2791d7c5d Author: chegar Date: 2012-06-19 10:20 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/efc2791d7c5d 6901992: InvalidJarIndexException due to bug in sun.misc.JarIndex.merge() Reviewed-by: chegar Contributed-by: dbelfer at gmail.com ! src/share/classes/sun/misc/JarIndex.java + test/sun/misc/JarIndex/JarIndexMergeForClassLoaderTest.java + test/sun/misc/JarIndex/JarIndexMergeTest.java Changeset: cdcbd22cfb9d Author: xuelei Date: 2012-06-19 17:28 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/cdcbd22cfb9d 7166487: checkSequenceNumber method never called within readRecord of SSLEngineImpl Reviewed-by: weijun ! src/share/classes/sun/security/ssl/SSLEngineImpl.java Changeset: dfe5617c18b4 Author: dholmes Date: 2012-06-20 22:40 -0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/dfe5617c18b4 7178483: Change version string for Embedded releases Reviewed-by: dholmes, lancea Contributed-by: Gary Collins ! make/common/Defs-embedded.gmk Changeset: 4a4a04bfeece Author: chegar Date: 2012-06-25 14:19 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/4a4a04bfeece 7176784: Windows authentication not working on some computers Reviewed-by: michaelm ! src/windows/native/sun/net/www/protocol/http/ntlm/NTLMAuthSequence.c Changeset: b76779abcd7f Author: lana Date: 2012-06-25 21:38 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/b76779abcd7f Merge Changeset: bff59bf994da Author: mullan Date: 2012-02-22 15:38 -0500 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/bff59bf994da 7145239: Finetune package definition restriction Reviewed-by: hawtin ! src/share/lib/security/java.security ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows Changeset: 1d8a3ef381f7 Author: bae Date: 2012-02-28 10:44 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/1d8a3ef381f7 7143617: Improve fontmanager layout lookup operations Reviewed-by: igor, prr, mschoene ! src/share/native/sun/font/layout/LookupProcessor.cpp ! src/share/native/sun/font/layout/LookupProcessor.h Changeset: 9e6e535a6769 Author: rupashka Date: 2012-02-28 16:09 +0200 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/9e6e535a6769 7143614: SynthLookAndFeel stability improvement Reviewed-by: malenkov ! src/share/classes/javax/swing/plaf/synth/SynthButtonUI.java ! src/share/classes/javax/swing/plaf/synth/SynthLabelUI.java ! src/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java + test/javax/swing/plaf/synth/7143614/bug7143614.java Changeset: 8516c5b4521b Author: weijun Date: 2012-02-29 14:06 +0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/8516c5b4521b 7143872: Improve certificate extension processing Reviewed-by: mullan ! src/share/classes/sun/security/x509/CRLExtensions.java ! src/share/classes/sun/security/x509/CertificateExtensions.java ! src/share/classes/sun/security/x509/X509CRLEntryImpl.java ! src/share/classes/sun/security/x509/X509CRLImpl.java ! src/share/classes/sun/security/x509/X509CertImpl.java + test/sun/security/x509/X509CRLImpl/OrderAndDup.java Changeset: 3640f1a043f8 Author: coffeys Date: 2012-03-26 14:03 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/3640f1a043f8 7143851: Improve IIOP stub and tie generation in RMIC 7149048: Changes to corba rmic stubGenerator class are not used during jdk build process Reviewed-by: mschoene, robm ! make/com/sun/jmx/Makefile Changeset: 9de49289df0f Author: asaha Date: 2012-04-10 10:44 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/9de49289df0f Merge ! make/com/oracle/net/Makefile - make/sun/motif12/reorder-i586 - make/sun/motif12/reorder-sparc - make/sun/motif12/reorder-sparcv9 ! make/sun/rmi/rmi/mapfile-vers - src/linux/doc/man/apt.1 - src/linux/doc/man/ja/apt.1 - src/share/classes/com/sun/tools/jdi/LinkedHashMap.java - src/share/classes/java/lang/invoke/FilterGeneric.java - src/share/classes/java/lang/invoke/FilterOneArgument.java - src/share/classes/java/lang/invoke/FromGeneric.java - src/share/classes/java/lang/invoke/SpreadGeneric.java - src/share/classes/java/lang/invoke/ToGeneric.java - src/share/classes/java/util/XMLUtils.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/io/ByteToCharASCII.java - src/share/classes/sun/io/ByteToCharBig5.java - src/share/classes/sun/io/ByteToCharBig5_HKSCS.java - src/share/classes/sun/io/ByteToCharBig5_Solaris.java - src/share/classes/sun/io/ByteToCharConverter.java - src/share/classes/sun/io/ByteToCharCp037.java - src/share/classes/sun/io/ByteToCharCp1006.java - src/share/classes/sun/io/ByteToCharCp1025.java - src/share/classes/sun/io/ByteToCharCp1026.java - src/share/classes/sun/io/ByteToCharCp1046.java - src/share/classes/sun/io/ByteToCharCp1047.java - src/share/classes/sun/io/ByteToCharCp1097.java - src/share/classes/sun/io/ByteToCharCp1098.java - src/share/classes/sun/io/ByteToCharCp1112.java - src/share/classes/sun/io/ByteToCharCp1122.java - src/share/classes/sun/io/ByteToCharCp1123.java - src/share/classes/sun/io/ByteToCharCp1124.java - src/share/classes/sun/io/ByteToCharCp1140.java - src/share/classes/sun/io/ByteToCharCp1141.java - src/share/classes/sun/io/ByteToCharCp1142.java - src/share/classes/sun/io/ByteToCharCp1143.java - src/share/classes/sun/io/ByteToCharCp1144.java - src/share/classes/sun/io/ByteToCharCp1145.java - src/share/classes/sun/io/ByteToCharCp1146.java - src/share/classes/sun/io/ByteToCharCp1147.java - src/share/classes/sun/io/ByteToCharCp1148.java - src/share/classes/sun/io/ByteToCharCp1149.java - src/share/classes/sun/io/ByteToCharCp1250.java - src/share/classes/sun/io/ByteToCharCp1251.java - src/share/classes/sun/io/ByteToCharCp1252.java - src/share/classes/sun/io/ByteToCharCp1253.java - src/share/classes/sun/io/ByteToCharCp1254.java - src/share/classes/sun/io/ByteToCharCp1255.java - src/share/classes/sun/io/ByteToCharCp1256.java - src/share/classes/sun/io/ByteToCharCp1257.java - src/share/classes/sun/io/ByteToCharCp1258.java - src/share/classes/sun/io/ByteToCharCp1381.java - src/share/classes/sun/io/ByteToCharCp1383.java - src/share/classes/sun/io/ByteToCharCp273.java - src/share/classes/sun/io/ByteToCharCp277.java - src/share/classes/sun/io/ByteToCharCp278.java - src/share/classes/sun/io/ByteToCharCp280.java - src/share/classes/sun/io/ByteToCharCp284.java - src/share/classes/sun/io/ByteToCharCp285.java - src/share/classes/sun/io/ByteToCharCp297.java - src/share/classes/sun/io/ByteToCharCp33722.java - src/share/classes/sun/io/ByteToCharCp420.java - src/share/classes/sun/io/ByteToCharCp424.java - src/share/classes/sun/io/ByteToCharCp437.java - src/share/classes/sun/io/ByteToCharCp500.java - src/share/classes/sun/io/ByteToCharCp737.java - src/share/classes/sun/io/ByteToCharCp775.java - src/share/classes/sun/io/ByteToCharCp833.java - src/share/classes/sun/io/ByteToCharCp834.java - src/share/classes/sun/io/ByteToCharCp838.java - src/share/classes/sun/io/ByteToCharCp850.java - src/share/classes/sun/io/ByteToCharCp852.java - src/share/classes/sun/io/ByteToCharCp855.java - src/share/classes/sun/io/ByteToCharCp856.java - src/share/classes/sun/io/ByteToCharCp857.java - src/share/classes/sun/io/ByteToCharCp858.java - src/share/classes/sun/io/ByteToCharCp860.java - src/share/classes/sun/io/ByteToCharCp861.java - src/share/classes/sun/io/ByteToCharCp862.java - src/share/classes/sun/io/ByteToCharCp863.java - src/share/classes/sun/io/ByteToCharCp864.java - src/share/classes/sun/io/ByteToCharCp865.java - src/share/classes/sun/io/ByteToCharCp866.java - src/share/classes/sun/io/ByteToCharCp868.java - src/share/classes/sun/io/ByteToCharCp869.java - src/share/classes/sun/io/ByteToCharCp870.java - src/share/classes/sun/io/ByteToCharCp871.java - src/share/classes/sun/io/ByteToCharCp874.java - src/share/classes/sun/io/ByteToCharCp875.java - src/share/classes/sun/io/ByteToCharCp918.java - src/share/classes/sun/io/ByteToCharCp921.java - src/share/classes/sun/io/ByteToCharCp922.java - src/share/classes/sun/io/ByteToCharCp930.java - src/share/classes/sun/io/ByteToCharCp933.java - src/share/classes/sun/io/ByteToCharCp935.java - src/share/classes/sun/io/ByteToCharCp937.java - src/share/classes/sun/io/ByteToCharCp939.java - src/share/classes/sun/io/ByteToCharCp942.java - src/share/classes/sun/io/ByteToCharCp942C.java - src/share/classes/sun/io/ByteToCharCp943.java - src/share/classes/sun/io/ByteToCharCp943C.java - src/share/classes/sun/io/ByteToCharCp948.java - src/share/classes/sun/io/ByteToCharCp949.java - src/share/classes/sun/io/ByteToCharCp949C.java - src/share/classes/sun/io/ByteToCharCp950.java - src/share/classes/sun/io/ByteToCharCp964.java - src/share/classes/sun/io/ByteToCharCp970.java - src/share/classes/sun/io/ByteToCharDBCS_ASCII.java - src/share/classes/sun/io/ByteToCharDBCS_EBCDIC.java - src/share/classes/sun/io/ByteToCharDoubleByte.java - src/share/classes/sun/io/ByteToCharEUC.java - src/share/classes/sun/io/ByteToCharEUC2.java - src/share/classes/sun/io/ByteToCharEUC_CN.java - src/share/classes/sun/io/ByteToCharEUC_JP.java - src/share/classes/sun/io/ByteToCharEUC_JP_LINUX.java - src/share/classes/sun/io/ByteToCharEUC_JP_Solaris.java - src/share/classes/sun/io/ByteToCharEUC_KR.java - src/share/classes/sun/io/ByteToCharEUC_TW.java - src/share/classes/sun/io/ByteToCharGB18030.java - src/share/classes/sun/io/ByteToCharGB18030DB.java - src/share/classes/sun/io/ByteToCharGBK.java - src/share/classes/sun/io/ByteToCharISCII91.java - src/share/classes/sun/io/ByteToCharISO2022.java - src/share/classes/sun/io/ByteToCharISO2022CN.java - src/share/classes/sun/io/ByteToCharISO2022JP.java - src/share/classes/sun/io/ByteToCharISO2022KR.java - src/share/classes/sun/io/ByteToCharISO8859_1.java - src/share/classes/sun/io/ByteToCharISO8859_13.java - src/share/classes/sun/io/ByteToCharISO8859_15.java - src/share/classes/sun/io/ByteToCharISO8859_2.java - src/share/classes/sun/io/ByteToCharISO8859_3.java - src/share/classes/sun/io/ByteToCharISO8859_4.java - src/share/classes/sun/io/ByteToCharISO8859_5.java - src/share/classes/sun/io/ByteToCharISO8859_6.java - src/share/classes/sun/io/ByteToCharISO8859_7.java - src/share/classes/sun/io/ByteToCharISO8859_8.java - src/share/classes/sun/io/ByteToCharISO8859_9.java - src/share/classes/sun/io/ByteToCharJIS0201.java - src/share/classes/sun/io/ByteToCharJIS0208.java - src/share/classes/sun/io/ByteToCharJIS0208_Solaris.java - src/share/classes/sun/io/ByteToCharJIS0212.java - src/share/classes/sun/io/ByteToCharJIS0212_Solaris.java - src/share/classes/sun/io/ByteToCharJISAutoDetect.java - src/share/classes/sun/io/ByteToCharJohab.java - src/share/classes/sun/io/ByteToCharKOI8_R.java - src/share/classes/sun/io/ByteToCharMS874.java - src/share/classes/sun/io/ByteToCharMS932.java - src/share/classes/sun/io/ByteToCharMS936.java - src/share/classes/sun/io/ByteToCharMS949.java - src/share/classes/sun/io/ByteToCharMS950.java - src/share/classes/sun/io/ByteToCharMS950_HKSCS.java - src/share/classes/sun/io/ByteToCharMacArabic.java - src/share/classes/sun/io/ByteToCharMacCentralEurope.java - src/share/classes/sun/io/ByteToCharMacCroatian.java - src/share/classes/sun/io/ByteToCharMacCyrillic.java - src/share/classes/sun/io/ByteToCharMacDingbat.java - src/share/classes/sun/io/ByteToCharMacGreek.java - src/share/classes/sun/io/ByteToCharMacHebrew.java - src/share/classes/sun/io/ByteToCharMacIceland.java - src/share/classes/sun/io/ByteToCharMacRoman.java - src/share/classes/sun/io/ByteToCharMacRomania.java - src/share/classes/sun/io/ByteToCharMacSymbol.java - src/share/classes/sun/io/ByteToCharMacThai.java - src/share/classes/sun/io/ByteToCharMacTurkish.java - src/share/classes/sun/io/ByteToCharMacUkraine.java - src/share/classes/sun/io/ByteToCharPCK.java - src/share/classes/sun/io/ByteToCharSJIS.java - src/share/classes/sun/io/ByteToCharSingleByte.java - src/share/classes/sun/io/ByteToCharTIS620.java - src/share/classes/sun/io/ByteToCharUTF16.java - src/share/classes/sun/io/ByteToCharUTF8.java - src/share/classes/sun/io/ByteToCharUnicode.java - src/share/classes/sun/io/ByteToCharUnicodeBig.java - src/share/classes/sun/io/ByteToCharUnicodeBigUnmarked.java - src/share/classes/sun/io/ByteToCharUnicodeLittle.java - src/share/classes/sun/io/ByteToCharUnicodeLittleUnmarked.java - src/share/classes/sun/io/CharToByteASCII.java - src/share/classes/sun/io/CharToByteBig5.java - src/share/classes/sun/io/CharToByteBig5_HKSCS.java - src/share/classes/sun/io/CharToByteBig5_Solaris.java - src/share/classes/sun/io/CharToByteConverter.java - src/share/classes/sun/io/CharToByteCp037.java - src/share/classes/sun/io/CharToByteCp1006.java - src/share/classes/sun/io/CharToByteCp1025.java - src/share/classes/sun/io/CharToByteCp1026.java - src/share/classes/sun/io/CharToByteCp1046.java - src/share/classes/sun/io/CharToByteCp1047.java - src/share/classes/sun/io/CharToByteCp1097.java - src/share/classes/sun/io/CharToByteCp1098.java - src/share/classes/sun/io/CharToByteCp1112.java - src/share/classes/sun/io/CharToByteCp1122.java - src/share/classes/sun/io/CharToByteCp1123.java - src/share/classes/sun/io/CharToByteCp1124.java - src/share/classes/sun/io/CharToByteCp1140.java - src/share/classes/sun/io/CharToByteCp1141.java - src/share/classes/sun/io/CharToByteCp1142.java - src/share/classes/sun/io/CharToByteCp1143.java - src/share/classes/sun/io/CharToByteCp1144.java - src/share/classes/sun/io/CharToByteCp1145.java - src/share/classes/sun/io/CharToByteCp1146.java - src/share/classes/sun/io/CharToByteCp1147.java - src/share/classes/sun/io/CharToByteCp1148.java - src/share/classes/sun/io/CharToByteCp1149.java - src/share/classes/sun/io/CharToByteCp1250.java - src/share/classes/sun/io/CharToByteCp1251.java - src/share/classes/sun/io/CharToByteCp1252.java - src/share/classes/sun/io/CharToByteCp1253.java - src/share/classes/sun/io/CharToByteCp1254.java - src/share/classes/sun/io/CharToByteCp1255.java - src/share/classes/sun/io/CharToByteCp1256.java - src/share/classes/sun/io/CharToByteCp1257.java - src/share/classes/sun/io/CharToByteCp1258.java - src/share/classes/sun/io/CharToByteCp1381.java - src/share/classes/sun/io/CharToByteCp1383.java - src/share/classes/sun/io/CharToByteCp273.java - src/share/classes/sun/io/CharToByteCp277.java - src/share/classes/sun/io/CharToByteCp278.java - src/share/classes/sun/io/CharToByteCp280.java - src/share/classes/sun/io/CharToByteCp284.java - src/share/classes/sun/io/CharToByteCp285.java - src/share/classes/sun/io/CharToByteCp297.java - src/share/classes/sun/io/CharToByteCp33722.java - src/share/classes/sun/io/CharToByteCp420.java - src/share/classes/sun/io/CharToByteCp424.java - src/share/classes/sun/io/CharToByteCp437.java - src/share/classes/sun/io/CharToByteCp500.java - src/share/classes/sun/io/CharToByteCp737.java - src/share/classes/sun/io/CharToByteCp775.java - src/share/classes/sun/io/CharToByteCp833.java - src/share/classes/sun/io/CharToByteCp834.java - src/share/classes/sun/io/CharToByteCp838.java - src/share/classes/sun/io/CharToByteCp850.java - src/share/classes/sun/io/CharToByteCp852.java - src/share/classes/sun/io/CharToByteCp855.java - src/share/classes/sun/io/CharToByteCp856.java - src/share/classes/sun/io/CharToByteCp857.java - src/share/classes/sun/io/CharToByteCp858.java - src/share/classes/sun/io/CharToByteCp860.java - src/share/classes/sun/io/CharToByteCp861.java - src/share/classes/sun/io/CharToByteCp862.java - src/share/classes/sun/io/CharToByteCp863.java - src/share/classes/sun/io/CharToByteCp864.java - src/share/classes/sun/io/CharToByteCp865.java - src/share/classes/sun/io/CharToByteCp866.java - src/share/classes/sun/io/CharToByteCp868.java - src/share/classes/sun/io/CharToByteCp869.java - src/share/classes/sun/io/CharToByteCp870.java - src/share/classes/sun/io/CharToByteCp871.java - src/share/classes/sun/io/CharToByteCp874.java - src/share/classes/sun/io/CharToByteCp875.java - src/share/classes/sun/io/CharToByteCp918.java - src/share/classes/sun/io/CharToByteCp921.java - src/share/classes/sun/io/CharToByteCp922.java - src/share/classes/sun/io/CharToByteCp930.java - src/share/classes/sun/io/CharToByteCp933.java - src/share/classes/sun/io/CharToByteCp935.java - src/share/classes/sun/io/CharToByteCp937.java - src/share/classes/sun/io/CharToByteCp939.java - src/share/classes/sun/io/CharToByteCp942.java - src/share/classes/sun/io/CharToByteCp942C.java - src/share/classes/sun/io/CharToByteCp943.java - src/share/classes/sun/io/CharToByteCp943C.java - src/share/classes/sun/io/CharToByteCp948.java - src/share/classes/sun/io/CharToByteCp949.java - src/share/classes/sun/io/CharToByteCp949C.java - src/share/classes/sun/io/CharToByteCp950.java - src/share/classes/sun/io/CharToByteCp964.java - src/share/classes/sun/io/CharToByteCp970.java - src/share/classes/sun/io/CharToByteDBCS_ASCII.java - src/share/classes/sun/io/CharToByteDBCS_EBCDIC.java - src/share/classes/sun/io/CharToByteDoubleByte.java - src/share/classes/sun/io/CharToByteEUC.java - src/share/classes/sun/io/CharToByteEUC_CN.java - src/share/classes/sun/io/CharToByteEUC_JP.java - src/share/classes/sun/io/CharToByteEUC_JP_LINUX.java - src/share/classes/sun/io/CharToByteEUC_JP_Solaris.java - src/share/classes/sun/io/CharToByteEUC_KR.java - src/share/classes/sun/io/CharToByteEUC_TW.java - src/share/classes/sun/io/CharToByteGB18030.java - src/share/classes/sun/io/CharToByteGBK.java - src/share/classes/sun/io/CharToByteISCII91.java - src/share/classes/sun/io/CharToByteISO2022.java - src/share/classes/sun/io/CharToByteISO2022CN_CNS.java - src/share/classes/sun/io/CharToByteISO2022CN_GB.java - src/share/classes/sun/io/CharToByteISO2022JP.java - src/share/classes/sun/io/CharToByteISO2022KR.java - src/share/classes/sun/io/CharToByteISO8859_1.java - src/share/classes/sun/io/CharToByteISO8859_13.java - src/share/classes/sun/io/CharToByteISO8859_15.java - src/share/classes/sun/io/CharToByteISO8859_2.java - src/share/classes/sun/io/CharToByteISO8859_3.java - src/share/classes/sun/io/CharToByteISO8859_4.java - src/share/classes/sun/io/CharToByteISO8859_5.java - src/share/classes/sun/io/CharToByteISO8859_6.java - src/share/classes/sun/io/CharToByteISO8859_7.java - src/share/classes/sun/io/CharToByteISO8859_8.java - src/share/classes/sun/io/CharToByteISO8859_9.java - src/share/classes/sun/io/CharToByteJIS0201.java - src/share/classes/sun/io/CharToByteJIS0208.java - src/share/classes/sun/io/CharToByteJIS0208_Solaris.java - src/share/classes/sun/io/CharToByteJIS0212.java - src/share/classes/sun/io/CharToByteJIS0212_Solaris.java - src/share/classes/sun/io/CharToByteJohab.java - src/share/classes/sun/io/CharToByteKOI8_R.java - src/share/classes/sun/io/CharToByteMS874.java - src/share/classes/sun/io/CharToByteMS932.java - src/share/classes/sun/io/CharToByteMS936.java - src/share/classes/sun/io/CharToByteMS949.java - src/share/classes/sun/io/CharToByteMS950.java - src/share/classes/sun/io/CharToByteMS950_HKSCS.java - src/share/classes/sun/io/CharToByteMacArabic.java - src/share/classes/sun/io/CharToByteMacCentralEurope.java - src/share/classes/sun/io/CharToByteMacCroatian.java - src/share/classes/sun/io/CharToByteMacCyrillic.java - src/share/classes/sun/io/CharToByteMacDingbat.java - src/share/classes/sun/io/CharToByteMacGreek.java - src/share/classes/sun/io/CharToByteMacHebrew.java - src/share/classes/sun/io/CharToByteMacIceland.java - src/share/classes/sun/io/CharToByteMacRoman.java - src/share/classes/sun/io/CharToByteMacRomania.java - src/share/classes/sun/io/CharToByteMacSymbol.java - src/share/classes/sun/io/CharToByteMacThai.java - src/share/classes/sun/io/CharToByteMacTurkish.java - src/share/classes/sun/io/CharToByteMacUkraine.java - src/share/classes/sun/io/CharToBytePCK.java - src/share/classes/sun/io/CharToByteSJIS.java - src/share/classes/sun/io/CharToByteSingleByte.java - src/share/classes/sun/io/CharToByteTIS620.java - src/share/classes/sun/io/CharToByteUTF16.java - src/share/classes/sun/io/CharToByteUTF8.java - src/share/classes/sun/io/CharToByteUnicode.java - src/share/classes/sun/io/CharToByteUnicodeBig.java - src/share/classes/sun/io/CharToByteUnicodeBigUnmarked.java - src/share/classes/sun/io/CharToByteUnicodeLittle.java - src/share/classes/sun/io/CharToByteUnicodeLittleUnmarked.java - src/share/classes/sun/io/CharacterEncoding.java - src/share/classes/sun/io/ConversionBufferFullException.java - src/share/classes/sun/io/Converters.java - src/share/classes/sun/io/MalformedInputException.java - src/share/classes/sun/io/UnknownCharacterException.java - src/share/classes/sun/nio/ch/SctpMessageInfoImpl.java - src/share/classes/sun/nio/ch/SctpStdSocketOption.java - 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/CRLExtensions.java - src/share/classes/sun/security/x509/CertAndKeyGen.java ! src/share/classes/sun/security/x509/CertificateExtensions.java ! src/share/classes/sun/security/x509/X509CRLEntryImpl.java ! src/share/classes/sun/security/x509/X509CRLImpl.java ! src/share/classes/sun/security/x509/X509CertImpl.java - src/share/classes/sun/tools/jar/JarImageSource.java ! src/share/lib/security/java.security-solaris - src/share/native/java/lang/fdlibm/src/e_acosh.c - src/share/native/java/lang/fdlibm/src/e_gamma.c - src/share/native/java/lang/fdlibm/src/e_gamma_r.c - src/share/native/java/lang/fdlibm/src/e_j0.c - src/share/native/java/lang/fdlibm/src/e_j1.c - src/share/native/java/lang/fdlibm/src/e_jn.c - src/share/native/java/lang/fdlibm/src/e_lgamma.c - src/share/native/java/lang/fdlibm/src/e_lgamma_r.c - src/share/native/java/lang/fdlibm/src/s_asinh.c - src/share/native/java/lang/fdlibm/src/s_erf.c - src/share/native/java/lang/fdlibm/src/w_acosh.c - src/share/native/java/lang/fdlibm/src/w_gamma.c - src/share/native/java/lang/fdlibm/src/w_gamma_r.c - src/share/native/java/lang/fdlibm/src/w_j0.c - src/share/native/java/lang/fdlibm/src/w_j1.c - src/share/native/java/lang/fdlibm/src/w_jn.c - src/share/native/java/lang/fdlibm/src/w_lgamma.c - src/share/native/java/lang/fdlibm/src/w_lgamma_r.c - 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/sun/awt/libpng/pnggccrd.c - src/share/native/sun/awt/libpng/pngvcrd.c - src/share/native/sun/rmi/server/MarshalInputStream.c - 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/classes/sun/nio/ch/SctpAssocChange.java - src/solaris/classes/sun/nio/ch/SctpAssociationImpl.java - src/solaris/classes/sun/nio/ch/SctpChannelImpl.java - src/solaris/classes/sun/nio/ch/SctpMultiChannelImpl.java - src/solaris/classes/sun/nio/ch/SctpNet.java - src/solaris/classes/sun/nio/ch/SctpNotification.java - src/solaris/classes/sun/nio/ch/SctpPeerAddrChange.java - src/solaris/classes/sun/nio/ch/SctpResultContainer.java - src/solaris/classes/sun/nio/ch/SctpSendFailed.java - src/solaris/classes/sun/nio/ch/SctpServerChannelImpl.java - src/solaris/classes/sun/nio/ch/SctpShutdown.java - src/solaris/doc/sun/man/man1/apt.1 - src/solaris/doc/sun/man/man1/ja/apt.1 - 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 - src/solaris/native/sun/nio/ch/Sctp.h - src/solaris/native/sun/nio/ch/SctpChannelImpl.c - src/solaris/native/sun/nio/ch/SctpNet.c - src/solaris/native/sun/nio/ch/SctpServerChannelImpl.c - src/windows/classes/sun/nio/ch/SctpChannelImpl.java - src/windows/classes/sun/nio/ch/SctpMultiChannelImpl.java - src/windows/classes/sun/nio/ch/SctpServerChannelImpl.java - test/java/io/File/BlockIsDirectory.java - test/java/io/File/isDirectory/Applet.html - test/java/io/File/isDirectory/Applet.java - test/java/io/FileDescriptor/FileChannelFDTest.java - test/java/util/ResourceBundle/Control/ExpirationTest.java - test/java/util/ResourceBundle/Control/ExpirationTest.sh - test/sun/nio/cs/OLD/TestX11CS.java - test/sun/nio/cs/TestISCII91.java - test/sun/security/util/BigInt/BigIntEqualsHashCode.java - test/tools/launcher/ChangeDataModel.sh - test/tools/launcher/CreatePlatformFile.java - test/tools/launcher/DefaultLocaleTest.sh - test/tools/launcher/SomeException.java - test/tools/launcher/UnicodeCleanup.java - test/tools/launcher/UnicodeTest.sh - test/tools/launcher/deleteI18n.sh - test/tools/launcher/i18nTest.sh - test/tools/launcher/unresolvedExceptions.sh Changeset: 95998c60ab4b Author: robm Date: 2012-04-11 17:47 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/95998c60ab4b 7143606: File.createTempFile should be improved for temporary files created by the platform. Reviewed-by: sherman ! src/macosx/classes/apple/applescript/AppleScriptEngine.java ! src/share/classes/com/sun/java/util/jar/pack/Driver.java ! src/share/classes/java/awt/Font.java ! src/share/classes/javax/imageio/stream/FileCacheImageInputStream.java ! src/share/classes/javax/imageio/stream/FileCacheImageOutputStream.java ! src/share/classes/javax/management/loading/MLet.java ! src/share/classes/sun/print/PSPrinterJob.java ! src/share/classes/sun/rmi/server/Activation.java ! src/share/classes/sun/tools/jar/Main.java ! src/share/classes/sun/tools/native2ascii/Main.java ! src/solaris/classes/sun/font/FcFontConfiguration.java ! src/solaris/classes/sun/print/UnixPrintJob.java ! src/solaris/classes/sun/print/UnixPrintServiceLookup.java Changeset: afe424ee3240 Author: asaha Date: 2012-05-08 07:34 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/afe424ee3240 Merge ! src/share/lib/security/java.security ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows - test/sun/security/pkcs11/nss/lib/linux-amd64/libfreebl3.chk - test/sun/security/pkcs11/nss/lib/linux-amd64/libfreebl3.so - test/sun/security/pkcs11/nss/lib/linux-amd64/libnspr4.so - test/sun/security/pkcs11/nss/lib/linux-amd64/libnss3.so - test/sun/security/pkcs11/nss/lib/linux-amd64/libnssckbi.so - test/sun/security/pkcs11/nss/lib/linux-amd64/libplc4.so - test/sun/security/pkcs11/nss/lib/linux-amd64/libplds4.so - test/sun/security/pkcs11/nss/lib/linux-amd64/libsoftokn3.chk - test/sun/security/pkcs11/nss/lib/linux-amd64/libsoftokn3.so - test/sun/security/pkcs11/nss/lib/linux-i586/libnspr4.so - test/sun/security/pkcs11/nss/lib/linux-i586/libnss3.so - test/sun/security/pkcs11/nss/lib/linux-i586/libnssckbi.so - test/sun/security/pkcs11/nss/lib/linux-i586/libplc4.so - test/sun/security/pkcs11/nss/lib/linux-i586/libplds4.so - test/sun/security/pkcs11/nss/lib/linux-i586/libsoftokn3.so - test/sun/security/pkcs11/nss/lib/solaris-amd64/libnspr4.so - test/sun/security/pkcs11/nss/lib/solaris-amd64/libnss3.so - test/sun/security/pkcs11/nss/lib/solaris-amd64/libnssckbi.so - test/sun/security/pkcs11/nss/lib/solaris-amd64/libplc4.so - test/sun/security/pkcs11/nss/lib/solaris-amd64/libplds4.so - test/sun/security/pkcs11/nss/lib/solaris-amd64/libsoftokn3.so - test/sun/security/pkcs11/nss/lib/solaris-i586/libfreebl3.so - test/sun/security/pkcs11/nss/lib/solaris-i586/libnspr4.so - test/sun/security/pkcs11/nss/lib/solaris-i586/libnss3.so - test/sun/security/pkcs11/nss/lib/solaris-i586/libnssckbi.so - test/sun/security/pkcs11/nss/lib/solaris-i586/libplc4.so - test/sun/security/pkcs11/nss/lib/solaris-i586/libplds4.so - test/sun/security/pkcs11/nss/lib/solaris-i586/libsoftokn3.so - test/sun/security/pkcs11/nss/lib/solaris-sparc/libfreebl_hybrid_3.chk - test/sun/security/pkcs11/nss/lib/solaris-sparc/libfreebl_hybrid_3.so - test/sun/security/pkcs11/nss/lib/solaris-sparc/libnspr4.so - test/sun/security/pkcs11/nss/lib/solaris-sparc/libnss3.so - test/sun/security/pkcs11/nss/lib/solaris-sparc/libnssckbi.so - test/sun/security/pkcs11/nss/lib/solaris-sparc/libplc4.so - test/sun/security/pkcs11/nss/lib/solaris-sparc/libplds4.so - test/sun/security/pkcs11/nss/lib/solaris-sparc/libsoftokn3.chk - test/sun/security/pkcs11/nss/lib/solaris-sparc/libsoftokn3.so - test/sun/security/pkcs11/nss/lib/solaris-sparcv9/libnspr4.so - test/sun/security/pkcs11/nss/lib/solaris-sparcv9/libnss3.so - test/sun/security/pkcs11/nss/lib/solaris-sparcv9/libnssckbi.so - test/sun/security/pkcs11/nss/lib/solaris-sparcv9/libplc4.so - test/sun/security/pkcs11/nss/lib/solaris-sparcv9/libplds4.so - test/sun/security/pkcs11/nss/lib/solaris-sparcv9/libsoftokn3.so - test/sun/security/pkcs11/nss/lib/windows-i586/libnspr4.dll - test/sun/security/pkcs11/nss/lib/windows-i586/libplc4.dll - test/sun/security/pkcs11/nss/lib/windows-i586/libplds4.dll - test/sun/security/pkcs11/nss/lib/windows-i586/nss3.dll - test/sun/security/pkcs11/nss/lib/windows-i586/nssckbi.dll - test/sun/security/pkcs11/nss/lib/windows-i586/softokn3.dll Changeset: 3a2cfce96908 Author: coffeys Date: 2012-05-17 12:21 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/3a2cfce96908 7123896: Unexpected behavior due to Solaris using separate IPv4 and IPv6 port spaces Reviewed-by: alanb ! src/share/native/java/net/net_util.c ! src/share/native/java/net/net_util.h ! src/solaris/native/java/net/net_util_md.c ! src/windows/native/java/net/net_util_md.c ! test/java/net/Socket/setReuseAddress/Basic.java ! test/java/net/Socket/setReuseAddress/Restart.java Changeset: cf097cda2733 Author: jrose Date: 2012-05-18 20:31 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/cf097cda2733 7165628: Issues with java.lang.invoke.MethodHandles.Lookup Summary: Base SecurityManager checks on either of Lookup.lookupClass or caller class; also clarify Lookup access checks. Reviewed-by: twisti ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/sun/invoke/util/VerifyAccess.java + test/java/lang/invoke/AccessControlTest.java + test/java/lang/invoke/AccessControlTest_subpkg/Acquaintance_remote.java Changeset: 36d899822de7 Author: asaha Date: 2012-05-21 15:13 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/36d899822de7 Merge - src/macosx/bin/amd64/jvm.cfg ! src/share/classes/sun/print/PSPrinterJob.java - src/share/classes/sun/security/action/LoadLibraryAction.java ! src/solaris/classes/sun/print/UnixPrintServiceLookup.java ! src/solaris/native/java/net/net_util_md.c - test/tools/pack200/dyn.jar - test/tools/pack200/pack200-verifier/src/xmlkit/ClassSyntax.java - test/tools/pack200/pack200-verifier/src/xmlkit/ClassWriter.java - test/tools/pack200/pack200-verifier/src/xmlkit/InstructionAssembler.java - test/tools/pack200/pack200-verifier/src/xmlkit/InstructionSyntax.java Changeset: 4c403c00fdf1 Author: asaha Date: 2012-05-24 10:23 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/4c403c00fdf1 7171228: closed/java/lang/SecurityManager/CheckPackageDefinition.java failure Reviewed-by: mullan ! src/share/lib/security/java.security ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows Changeset: 2fbf98031e65 Author: asaha Date: 2012-06-07 12:31 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/2fbf98031e65 Merge ! src/share/native/java/net/net_util.h ! src/solaris/native/java/net/net_util_md.c Changeset: b92353a01aa0 Author: lana Date: 2012-06-26 10:57 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/b92353a01aa0 Merge ! src/share/classes/sun/security/x509/X509CRLEntryImpl.java ! src/solaris/classes/sun/print/UnixPrintServiceLookup.java ! src/solaris/native/java/net/net_util_md.c Changeset: 8d2ed9d58453 Author: katleman Date: 2012-06-28 09:33 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/8d2ed9d58453 Added tag jdk8-b45 for changeset b92353a01aa0 ! .hgtags Changeset: 975e2ccf3b26 Author: alanb Date: 2012-07-11 18:08 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/975e2ccf3b26 Merge ! .hgtags ! make/common/Defs-solaris.gmk ! make/common/Defs.gmk ! make/common/Library.gmk ! make/common/Program.gmk ! make/java/java/FILES_c.gmk ! make/java/java/FILES_java.gmk ! make/java/java/mapfile-vers ! make/java/nio/Makefile ! make/jprt.properties ! make/sun/font/Makefile ! make/sun/jconsole/Makefile - makefiles/altclasses/Makefile - makefiles/apple/Makefile - makefiles/apple/applescript/Makefile - makefiles/com/Makefile - makefiles/com/apple/Makefile - makefiles/com/apple/osx/Makefile - makefiles/com/apple/osxui/Makefile - makefiles/com/oracle/Makefile - makefiles/com/oracle/jfr/Makefile - makefiles/com/oracle/security/ucrypto/FILES_c.gmk - makefiles/com/oracle/security/ucrypto/Makefile - makefiles/com/oracle/security/ucrypto/mapfile-vers - makefiles/com/sun/Makefile - makefiles/common/shared/Defs-utils.gmk - makefiles/java/fdlibm/FILES_c.gmk - makefiles/java/fdlibm/Makefile - makefiles/java/instrument/Makefile - makefiles/java/instrument/mapfile-vers - makefiles/java/java/Exportedfiles.gmk - makefiles/java/java/FILES_c.gmk - makefiles/java/java/FILES_java.gmk - makefiles/java/java/Makefile - makefiles/java/java/localelist.sh - makefiles/java/java/mapfile-vers - makefiles/java/java/reflect/Makefile - makefiles/java/java/reorder-i586 - makefiles/java/java/reorder-sparc - makefiles/java/java/reorder-sparcv9 - makefiles/java/java_crw_demo/Makefile - makefiles/java/java_crw_demo/mapfile-vers - makefiles/java/java_hprof_demo/Makefile - makefiles/java/java_hprof_demo/mapfile-vers - makefiles/java/jexec/Makefile - makefiles/java/jli/Makefile - makefiles/java/jli/mapfile-vers - makefiles/java/jobjc/Makefile - makefiles/java/jvm/Makefile - makefiles/java/main/Makefile - makefiles/java/main/java/Makefile - makefiles/java/main/java/mapfile-amd64 - makefiles/java/main/java/mapfile-i586 - makefiles/java/main/java/mapfile-sparc - makefiles/java/main/java/mapfile-sparcv9 - makefiles/java/main/javaw/Makefile - makefiles/java/management/Exportedfiles.gmk - makefiles/java/management/FILES_c.gmk - makefiles/java/management/Makefile - makefiles/java/management/mapfile-vers - makefiles/java/net/FILES_c.gmk - makefiles/java/net/Makefile - makefiles/java/net/mapfile-vers - makefiles/java/nio/Exportedfiles.gmk - makefiles/java/nio/FILES_c.gmk - makefiles/java/nio/FILES_java.gmk - makefiles/java/nio/Makefile - makefiles/java/nio/addNotices.sh - makefiles/java/nio/genBuffer.sh - makefiles/java/nio/genCharsetProvider.sh - makefiles/java/nio/genCoder.sh - makefiles/java/nio/genExceptions.sh - makefiles/java/nio/mapfile-bsd - makefiles/java/nio/mapfile-linux - makefiles/java/nio/mapfile-solaris - makefiles/java/nio/reorder-i586 - makefiles/java/nio/reorder-sparc - makefiles/java/nio/reorder-sparcv9 - makefiles/java/npt/Makefile - makefiles/java/npt/mapfile-vers - makefiles/java/redist/fonts/Makefile - makefiles/java/security/Makefile - makefiles/java/sun_nio/FILES_java.gmk - makefiles/java/sun_nio/Makefile - makefiles/java/util/FILES_java.gmk - makefiles/java/util/FILES_properties.gmk - makefiles/java/util/Makefile - makefiles/java/verify/Makefile - makefiles/java/verify/mapfile-vers - makefiles/java/verify/reorder-i586 - makefiles/java/verify/reorder-sparc - makefiles/java/verify/reorder-sparcv9 - makefiles/javax/Makefile - makefiles/javax/imageio/Makefile - makefiles/javax/management/Makefile - makefiles/javax/sound/FILES_c.gmk - makefiles/javax/sound/Makefile - makefiles/javax/sound/SoundDefs.gmk - makefiles/javax/sound/jsoundalsa/Makefile - makefiles/javax/sound/jsoundalsa/mapfile-vers - makefiles/javax/sound/jsoundds/Makefile - makefiles/javax/sound/mapfile-vers - makefiles/javax/sql/Makefile - makefiles/javax/swing/FILES.gmk - makefiles/javax/swing/Makefile - makefiles/javax/swing/beaninfo/FILES.gmk - makefiles/javax/swing/beaninfo/Makefile - makefiles/javax/swing/beaninfo/SwingBeans.gmk - makefiles/javax/swing/beaninfo/manifest - makefiles/javax/swing/html32dtd/Makefile - makefiles/javax/swing/plaf/FILES.gmk - makefiles/javax/swing/plaf/Makefile - makefiles/sun/Makefile - makefiles/sun/awt/CondenseRules.awk - makefiles/sun/awt/Depend.mak - makefiles/sun/awt/Depend.sed - makefiles/sun/awt/FILES_c_macosx.gmk - makefiles/sun/awt/FILES_c_unix.gmk - makefiles/sun/awt/FILES_c_windows.gmk - makefiles/sun/awt/FILES_export_macosx.gmk - makefiles/sun/awt/FILES_export_unix.gmk - makefiles/sun/awt/FILES_export_windows.gmk - makefiles/sun/awt/Makefile - makefiles/sun/awt/README - makefiles/sun/awt/make.depend - makefiles/sun/awt/mapfile-mawt-vers - makefiles/sun/awt/mapfile-vers - makefiles/sun/awt/mapfile-vers-linux - makefiles/sun/awt/mawt.gmk - makefiles/sun/cmm/Makefile - makefiles/sun/cmm/kcms/FILES_c_unix.gmk - makefiles/sun/cmm/kcms/FILES_c_windows.gmk - makefiles/sun/cmm/kcms/Makefile - makefiles/sun/cmm/kcms/mapfile-vers - makefiles/sun/dcpr/FILES_c.gmk - makefiles/sun/dcpr/Makefile - makefiles/sun/dcpr/mapfile-vers - makefiles/sun/headless/Makefile - makefiles/sun/headless/mapfile-vers - makefiles/sun/headless/reorder-i586 - makefiles/sun/headless/reorder-sparc - makefiles/sun/headless/reorder-sparcv9 - makefiles/sun/image/Makefile - makefiles/sun/image/generic/FILES_c.gmk - makefiles/sun/image/generic/Makefile - makefiles/sun/image/generic/mapfile-vers - makefiles/sun/image/vis/FILES_c.gmk - makefiles/sun/image/vis/Makefile - makefiles/sun/javazic/Makefile - makefiles/sun/jdbc/Makefile - makefiles/sun/jdga/Makefile - makefiles/sun/jdga/mapfile-vers - makefiles/sun/lwawt/FILES_c_macosx.gmk - makefiles/sun/lwawt/FILES_export_macosx.gmk - makefiles/sun/lwawt/Makefile - makefiles/sun/nio/Makefile - makefiles/sun/nio/cs/FILES_java.gmk - makefiles/sun/nio/cs/Makefile - makefiles/sun/org/Makefile - makefiles/sun/org/mozilla/Makefile - makefiles/sun/org/mozilla/javascript/Makefile - makefiles/sun/osxapp/Makefile - makefiles/sun/security/Makefile - makefiles/sun/security/ec/FILES_c.gmk - makefiles/sun/security/ec/mapfile-vers - makefiles/sun/security/jgss/Makefile - makefiles/sun/security/jgss/wrapper/FILES_c.gmk - makefiles/sun/security/jgss/wrapper/Makefile - makefiles/sun/security/jgss/wrapper/mapfile-vers - makefiles/sun/security/krb5/FILES_c_windows.gmk - makefiles/sun/security/krb5/Makefile - makefiles/sun/security/mscapi/FILES_cpp.gmk - makefiles/sun/security/mscapi/Makefile - makefiles/sun/security/other/Makefile - makefiles/sun/security/smartcardio/FILES_c.gmk - makefiles/sun/security/smartcardio/Makefile - makefiles/sun/security/smartcardio/mapfile-vers - makefiles/sun/security/tools/Makefile - makefiles/sun/security/util/Makefile - makefiles/sun/splashscreen/FILES_c.gmk - makefiles/sun/splashscreen/Makefile - makefiles/sun/splashscreen/mapfile-vers - makefiles/sun/xawt/FILES_c_unix.gmk - makefiles/sun/xawt/FILES_export_unix.gmk - makefiles/sun/xawt/Makefile - makefiles/sun/xawt/mapfile-vers ! src/share/classes/com/sun/java/util/jar/pack/Driver.java ! src/share/classes/java/sql/DriverManager.java ! src/share/classes/java/text/BreakIterator.java ! src/share/classes/java/util/ResourceBundle.java - src/share/classes/sun/nio/ch/DevPollSelectorProvider.java - src/share/classes/sun/security/provider/certpath/CrlRevocationChecker.java - src/share/classes/sun/security/provider/certpath/OCSPChecker.java ! src/share/classes/sun/security/timestamp/HttpTimestamper.java ! src/share/classes/sun/tools/jar/Main.java - src/share/classes/sun/tools/jconsole/resources/JConsoleResources.java - src/share/classes/sun/tools/jconsole/resources/JConsoleResources_ja.java - src/share/classes/sun/tools/jconsole/resources/JConsoleResources_zh_CN.java ! src/share/javavm/export/jvm.h - src/share/native/java/sql/DriverManager.c ! test/Makefile - test/sun/security/krb5/auto/ok-as-delegate-xrealm.sh - test/sun/security/krb5/auto/ok-as-delegate.sh Changeset: 57fe73293f87 Author: alanb Date: 2012-07-12 14:26 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/57fe73293f87 rmic command don't work for 64-bit modules image ! make/com/sun/jmx/Makefile From paul.sandoz at oracle.com Thu Jul 12 08:00:25 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 12 Jul 2012 17:00:25 +0200 Subject: ANT build file for the Quickstart example In-Reply-To: <004701cd6035$e94ec840$bbec58c0$@itaas.com> References: <004701cd6035$e94ec840$bbec58c0$@itaas.com> Message-ID: <411E43ED-23EB-4679-B562-77BA47C05160@oracle.com> Hi Deepak, The error indicates you are not using a version of OpenJDK Jigsaw to compile. See the "executable" attribute of the javac task. However, there is a more fundamental issue using the javac ant task since it knows nothing about the new javac command line options. Thus it will likely confuse OpenJDK Jigsaw javac by including the "-classpath" option in addition to the '-modulepath" option explicitly added (which needs to be ) This is why i have been using special ant macros until the ant tasks are modified. See the examples, that are ant-based, linked from: http://earthly-powers.blogspot.co.uk/2012/06/modular-services-with-openjdk-jigsaw.html http://earthly-powers.blogspot.co.uk/2012/07/modular-services-with-openjdk-jigsaw.html https://github.com/PaulSandoz/openjdk-jigsaw-examples/ Paul. On Jul 12, 2012, at 3:54 PM, Deepak S Patwardhan wrote: > Hello, > > > > Has anyone written an ANT build file for the Quick start example on Project > jigsaw's homepage ? > > > > Since current Maven is pretty much unusable for Jigsaw projects (right?), I > tried to create an ANT build.xml with the intention to define targets like > > > > compile - compile the code. > > dist - prepare the jmod files using jpkg. > > install - install the jmod files into project's module library using jmod. > > > > But, I can't get the compile to happen successfully. This is what I tried : > (target init creates the modules/ folder) > > > > > > fork="yes" includeantruntime="no"> > > > > > > > > > > The build fails with this message : > > > > compile: > > [javac] Compiling 5 source files to > /home/deepak/Projects/kingdom/kssjava8/jigsaw/modules > > [javac] javac: invalid flag: -modulepath modules > > [javac] Usage: javac > > [javac] use -help for a list of possible options > > > > Any suggestions ? > > > > Regards, > > Deepak S Patwardhan. > > > From deepak.patwardhan at itaas.com Thu Jul 12 09:05:03 2012 From: deepak.patwardhan at itaas.com (Deepak S Patwardhan) Date: Thu, 12 Jul 2012 21:35:03 +0530 Subject: ANT build file for the Quickstart example In-Reply-To: <411E43ED-23EB-4679-B562-77BA47C05160@oracle.com> References: <004701cd6035$e94ec840$bbec58c0$@itaas.com> <411E43ED-23EB-4679-B562-77BA47C05160@oracle.com> Message-ID: <005b01cd6048$1a4da3a0$4ee8eae0$@itaas.com> Thanks Paul. That?s exactly what I needed. Regards, Deepak S Patwardhan. From: Paul Sandoz [mailto:paul.sandoz at oracle.com] Sent: 12 July 2012 20:30 To: Deepak S Patwardhan Cc: jigsaw-dev at openjdk.java.net Subject: Re: ANT build file for the Quickstart example Hi?Deepak, The error indicates you are not using a version of OpenJDK Jigsaw to compile. See the "executable" attribute of the javac task. However, there is a more fundamental issue using the javac ant task since it knows nothing about the new javac command line options. Thus it will likely confuse OpenJDK Jigsaw javac by including the "-classpath" option in addition to the '-modulepath" option explicitly added (which needs to be?) This is why i have been using special ant macros until the ant tasks are modified. See the examples, that are ant-based, linked from: ??http://earthly-powers.blogspot.co.uk/2012/06/modular-services-with-openjdk -jigsaw.html ??http://earthly-powers.blogspot.co.uk/2012/07/modular-services-with-openjdk -jigsaw.html ??https://github.com/PaulSandoz/openjdk-jigsaw-examples/ Paul. On Jul 12, 2012, at 3:54 PM, Deepak S Patwardhan wrote: Hello, Has anyone written an ANT build file for the Quick start example on Project jigsaw's homepage ? Since current Maven is pretty much unusable for Jigsaw projects (right?), I tried to create an ANT build.xml with the intention to define targets like compile - compile the code. dist - prepare the jmod files using jpkg. install - install the jmod files into project's module library using jmod. But, I can't get the compile to happen successfully. This is what I tried : (target init creates the modules/ folder) ??? ??????? ??????????? ??????? ??? The build fails with this message : compile: ???[javac] Compiling 5 source files to /home/deepak/Projects/kingdom/kssjava8/jigsaw/modules ???[javac] javac: invalid flag: -modulepath modules ???[javac] Usage: javac ???[javac] use -help for a list of possible options Any suggestions ? Regards, Deepak S Patwardhan. From david.holmes at oracle.com Thu Jul 12 21:12:45 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 13 Jul 2012 14:12:45 +1000 Subject: Compile time vs. runtime deps In-Reply-To: <1976077.ZL4lzu9txV@logoutik> References: <6679083.Hk9oz1TG9s@logoutik> <4FFE2043.4010905@oracle.com> <1976077.ZL4lzu9txV@logoutik> Message-ID: <4FFFA03D.3080907@oracle.com> On 12/07/2012 11:26 PM, Jaroslav Tulach wrote: > Dne ?t 12. ?ervence 2012 10:54:27, David Holmes napsal(a): >>>> I don't see why I need to make the distinction to the compiler. I >>>> declare an optional dependency and at compile-time it is, or isn't >>>> found. >>> >>> That could produce different result during the compilation. The >>> compilation >>> could either succeed or fail. Javac and IDEs need to know whether the >>> optional (in runtime) library should or should not be on the compilation >>> "classpath". >> You mean the tools are going to dynamically examine my >> module-info.java/class and use it to determine what they should set >> modulepath/classpath to ??? > > Hello David, > yes, that is the jigsaw plan. module-info.java is going to be the source of > compilation classpath for javac. It is supposed to save us for "classpath > hell". However, unlike other tools that shield us from such "hell", the > current design addresses just a half (at most) of the problem. Should it stay > this way, we are going to be faced to "classpath nightmare"... > >> That is not something I would have expected at all. > > I guess you are looking at Jigsaw from VM perspective, then! That is OK, but > the Jigsaw tries to define (a bit of) tooling story too. Nothing to do with VM perspective. I just don't expect my compiler or IDE to go and find a missing module for me. If the module is needed and missing then I get an error at compilation time. If the dependency is listed in module-info.java I still get an error at compilation time. Unless you expect the tool to try and resolve the problem (which I don't) then I don't see how adding something in module-info.java makes a difference. David ----- >> If I build a project >> and the optional, but needed at compile-time, module is not present then >> I get a compilation error: type XXX not found. It is then up to me to >> realize that I am missing the module that exports XXX and either install >> it to the main library or add the library it is in to the appropriate >> path. (Just as I would have to add the jar file today.) > > The vicious circle is closed by noting that the "appropriate path" is > expressed in module-info.java. And we are back where we started: this missing > module is required for compilation, but optional for execution - we need a way > to express that inside of module-info.java. > -jt > >> >>>> During compilation I reference a type and a module for that type >>>> is, or isn't, found. Whether the module was omitted or was optional it >>>> is simply a compile-time error if the type is not found. (I don't expect >>>> javac to know or determine that the not-found type would have been found >>>> in the missing optional module - how could it?) >>> >>> The Javac and IDEs have to know. My proposal was to introduce some way of >>> telling the system that there is a compile time only dependency. Thus for >>> the case when you want a fully optional dependency you could say: >>> >>> requires optional m at 1.0; >>> >>> which would mean "m at 1.0" should not be present while compiling. Or one >>> could use >>> >>> requires compile optional m at 1.0; >>> >>> which would make the "m at 1.0" optional during execution, but Javac and >>> other >>> source processing tools would know that it has to be present. >> >> Seems like an unnecessary complication to the module system to me. >> >> Cheers, >> David >> >>> -jt >>> >>>>> This is another example when runtime and compile time dependencies may >>>>> differ. The first one I know is the list of annotation processor >>>>> providing >>>>> modules to be present when compiling, but not during execution. >>>>> >>>>> Time to introduce "requires compile m at 1.0"? >>>>> -jt From paul.sandoz at oracle.com Fri Jul 13 01:23:11 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 13 Jul 2012 10:23:11 +0200 Subject: Compile time vs. runtime deps In-Reply-To: <4FFFA03D.3080907@oracle.com> References: <6679083.Hk9oz1TG9s@logoutik> <4FFE2043.4010905@oracle.com> <1976077.ZL4lzu9txV@logoutik> <4FFFA03D.3080907@oracle.com> Message-ID: On Jul 13, 2012, at 6:12 AM, David Holmes wrote: > On 12/07/2012 11:26 PM, Jaroslav Tulach wrote: >> Dne ?t 12. ?ervence 2012 10:54:27, David Holmes napsal(a): >>>>> I don't see why I need to make the distinction to the compiler. I >>>>> declare an optional dependency and at compile-time it is, or isn't >>>>> found. >>>> >>>> That could produce different result during the compilation. The >>>> compilation >>>> could either succeed or fail. Javac and IDEs need to know whether the >>>> optional (in runtime) library should or should not be on the compilation >>>> "classpath". >>> You mean the tools are going to dynamically examine my >>> module-info.java/class and use it to determine what they should set >>> modulepath/classpath to ??? >> >> Hello David, >> yes, that is the jigsaw plan. module-info.java is going to be the source of >> compilation classpath for javac. It is supposed to save us for "classpath >> hell". However, unlike other tools that shield us from such "hell", the >> current design addresses just a half (at most) of the problem. Should it stay >> this way, we are going to be faced to "classpath nightmare"... >> >>> That is not something I would have expected at all. >> >> I guess you are looking at Jigsaw from VM perspective, then! That is OK, but >> the Jigsaw tries to define (a bit of) tooling story too. > > Nothing to do with VM perspective. I just don't expect my compiler or IDE to go and find a missing module for me. If the module is needed and missing then I get an error at compilation time. If the dependency is listed in module-info.java I still get an error at compilation time. Unless you expect the tool to try and resolve the problem (which I don't) then I don't see how adding something in module-info.java makes a difference. > Do you expect that every developer, when checking out and building a project with such dependencies, deal with compile time errors? With the right information in the module-info.java compile-time dependencies can be downloaded automatically from repositories i.e. just like Maven does. Paul. From Alan.Bateman at oracle.com Fri Jul 13 01:27:54 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 13 Jul 2012 09:27:54 +0100 Subject: Compile time vs. runtime deps In-Reply-To: <4FFFA03D.3080907@oracle.com> References: <6679083.Hk9oz1TG9s@logoutik> <4FFE2043.4010905@oracle.com> <1976077.ZL4lzu9txV@logoutik> <4FFFA03D.3080907@oracle.com> Message-ID: <4FFFDC0A.2070506@oracle.com> On 13/07/2012 05:12, David Holmes wrote: > > Nothing to do with VM perspective. I just don't expect my compiler or > IDE to go and find a missing module for me. If the module is needed > and missing then I get an error at compilation time. If the dependency > is listed in module-info.java I still get an error at compilation > time. Unless you expect the tool to try and resolve the problem (which > I don't) then I don't see how adding something in module-info.java > makes a difference. If you are compiling with -L mlib and that module library is associated with one or more repositories then it would be possible to have the compile cause the missing modules required in the module declaration to be downloaded and installed. It doesn't this now and it brings up many issues of course. -Alan. From david.holmes at oracle.com Fri Jul 13 02:38:14 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 13 Jul 2012 19:38:14 +1000 Subject: Compile time vs. runtime deps In-Reply-To: References: <6679083.Hk9oz1TG9s@logoutik> <4FFE2043.4010905@oracle.com> <1976077.ZL4lzu9txV@logoutik> <4FFFA03D.3080907@oracle.com> Message-ID: <4FFFEC86.1010600@oracle.com> On 13/07/2012 6:23 PM, Paul Sandoz wrote: > On Jul 13, 2012, at 6:12 AM, David Holmes wrote: > >> On 12/07/2012 11:26 PM, Jaroslav Tulach wrote: >>> Dne ?t 12. ?ervence 2012 10:54:27, David Holmes napsal(a): >>>>>> I don't see why I need to make the distinction to the compiler. I >>>>>> declare an optional dependency and at compile-time it is, or isn't >>>>>> found. >>>>> >>>>> That could produce different result during the compilation. The >>>>> compilation >>>>> could either succeed or fail. Javac and IDEs need to know whether the >>>>> optional (in runtime) library should or should not be on the compilation >>>>> "classpath". >>>> You mean the tools are going to dynamically examine my >>>> module-info.java/class and use it to determine what they should set >>>> modulepath/classpath to ??? >>> >>> Hello David, >>> yes, that is the jigsaw plan. module-info.java is going to be the source of >>> compilation classpath for javac. It is supposed to save us for "classpath >>> hell". However, unlike other tools that shield us from such "hell", the >>> current design addresses just a half (at most) of the problem. Should it stay >>> this way, we are going to be faced to "classpath nightmare"... >>> >>>> That is not something I would have expected at all. >>> >>> I guess you are looking at Jigsaw from VM perspective, then! That is OK, but >>> the Jigsaw tries to define (a bit of) tooling story too. >> >> Nothing to do with VM perspective. I just don't expect my compiler or IDE to go and find a missing module for me. If the module is needed and missing then I get an error at compilation time. If the dependency is listed in module-info.java I still get an error at compilation time. Unless you expect the tool to try and resolve the problem (which I don't) then I don't see how adding something in module-info.java makes a difference. >> > > Do you expect that every developer, when checking out and building a project with such dependencies, deal with compile time errors? In general I don't expect users of a module to have to build it in the first place. I don't see why a developer of a module shouldn't have to deal with their own issues - they presumably understood that to use foo.bar they need to download and install foo. > With the right information in the module-info.java compile-time dependencies can be downloaded automatically from repositories i.e. just like Maven does. I have no doubt they could. What I question is whether it is really necessary. David ----- > Paul. From paul.sandoz at oracle.com Fri Jul 13 02:49:33 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 13 Jul 2012 11:49:33 +0200 Subject: Compile time vs. runtime deps In-Reply-To: <4FFFEC86.1010600@oracle.com> References: <6679083.Hk9oz1TG9s@logoutik> <4FFE2043.4010905@oracle.com> <1976077.ZL4lzu9txV@logoutik> <4FFFA03D.3080907@oracle.com> <4FFFEC86.1010600@oracle.com> Message-ID: <89A5BDD7-5A52-4082-9D3B-9A38243CEC3E@oracle.com> On Jul 13, 2012, at 11:38 AM, David Holmes wrote: > On 13/07/2012 6:23 PM, Paul Sandoz wrote: >> On Jul 13, 2012, at 6:12 AM, David Holmes wrote: >> >>> On 12/07/2012 11:26 PM, Jaroslav Tulach wrote: >>>> Dne ?t 12. ?ervence 2012 10:54:27, David Holmes napsal(a): >>>>>>> I don't see why I need to make the distinction to the compiler. I >>>>>>> declare an optional dependency and at compile-time it is, or isn't >>>>>>> found. >>>>>> >>>>>> That could produce different result during the compilation. The >>>>>> compilation >>>>>> could either succeed or fail. Javac and IDEs need to know whether the >>>>>> optional (in runtime) library should or should not be on the compilation >>>>>> "classpath". >>>>> You mean the tools are going to dynamically examine my >>>>> module-info.java/class and use it to determine what they should set >>>>> modulepath/classpath to ??? >>>> >>>> Hello David, >>>> yes, that is the jigsaw plan. module-info.java is going to be the source of >>>> compilation classpath for javac. It is supposed to save us for "classpath >>>> hell". However, unlike other tools that shield us from such "hell", the >>>> current design addresses just a half (at most) of the problem. Should it stay >>>> this way, we are going to be faced to "classpath nightmare"... >>>> >>>>> That is not something I would have expected at all. >>>> >>>> I guess you are looking at Jigsaw from VM perspective, then! That is OK, but >>>> the Jigsaw tries to define (a bit of) tooling story too. >>> >>> Nothing to do with VM perspective. I just don't expect my compiler or IDE to go and find a missing module for me. If the module is needed and missing then I get an error at compilation time. If the dependency is listed in module-info.java I still get an error at compilation time. Unless you expect the tool to try and resolve the problem (which I don't) then I don't see how adding something in module-info.java makes a difference. >>> >> >> Do you expect that every developer, when checking out and building a project with such dependencies, deal with compile time errors? > > In general I don't expect users of a module to have to build it in the first place. Users no, developers yes. > I don't see why a developer of a module shouldn't have to deal with their own issues - they presumably understood that to use foo.bar they need to download and install foo. It is not just the developer of the module, but a developer in general who is interested in building that module. The expectation of many open source projects is that they should be easy to check out and build, otherwise it is a barrier to adoption. Paul. From david.holmes at oracle.com Fri Jul 13 03:11:00 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 13 Jul 2012 20:11:00 +1000 Subject: Compile time vs. runtime deps In-Reply-To: <89A5BDD7-5A52-4082-9D3B-9A38243CEC3E@oracle.com> References: <6679083.Hk9oz1TG9s@logoutik> <4FFE2043.4010905@oracle.com> <1976077.ZL4lzu9txV@logoutik> <4FFFA03D.3080907@oracle.com> <4FFFEC86.1010600@oracle.com> <89A5BDD7-5A52-4082-9D3B-9A38243CEC3E@oracle.com> Message-ID: <4FFFF434.30305@oracle.com> This is somewhat digressing but ... On 13/07/2012 7:49 PM, Paul Sandoz wrote: > On Jul 13, 2012, at 11:38 AM, David Holmes wrote: >> On 13/07/2012 6:23 PM, Paul Sandoz wrote: >>> On Jul 13, 2012, at 6:12 AM, David Holmes wrote: >>> >>>> On 12/07/2012 11:26 PM, Jaroslav Tulach wrote: >>>>> Dne ?t 12. ?ervence 2012 10:54:27, David Holmes napsal(a): >>>>>>>> I don't see why I need to make the distinction to the compiler. I >>>>>>>> declare an optional dependency and at compile-time it is, or isn't >>>>>>>> found. >>>>>>> >>>>>>> That could produce different result during the compilation. The >>>>>>> compilation >>>>>>> could either succeed or fail. Javac and IDEs need to know whether the >>>>>>> optional (in runtime) library should or should not be on the compilation >>>>>>> "classpath". >>>>>> You mean the tools are going to dynamically examine my >>>>>> module-info.java/class and use it to determine what they should set >>>>>> modulepath/classpath to ??? >>>>> >>>>> Hello David, >>>>> yes, that is the jigsaw plan. module-info.java is going to be the source of >>>>> compilation classpath for javac. It is supposed to save us for "classpath >>>>> hell". However, unlike other tools that shield us from such "hell", the >>>>> current design addresses just a half (at most) of the problem. Should it stay >>>>> this way, we are going to be faced to "classpath nightmare"... >>>>> >>>>>> That is not something I would have expected at all. >>>>> >>>>> I guess you are looking at Jigsaw from VM perspective, then! That is OK, but >>>>> the Jigsaw tries to define (a bit of) tooling story too. >>>> >>>> Nothing to do with VM perspective. I just don't expect my compiler or IDE to go and find a missing module for me. If the module is needed and missing then I get an error at compilation time. If the dependency is listed in module-info.java I still get an error at compilation time. Unless you expect the tool to try and resolve the problem (which I don't) then I don't see how adding something in module-info.java makes a difference. >>>> >>> >>> Do you expect that every developer, when checking out and building a project with such dependencies, deal with compile time errors? >> >> In general I don't expect users of a module to have to build it in the first place. > > Users no, developers yes. > > >> I don't see why a developer of a module shouldn't have to deal with their own issues - they presumably understood that to use foo.bar they need to download and install foo. > > It is not just the developer of the module, but a developer in general who is interested in building that module. > > The expectation of many open source projects is that they should be easy to check out and build, otherwise it is a barrier to adoption. That is true for projects involving native code because of the problems in getting binaries that will run on a thousand different flavours of system. But for Java surely this will be much rarer and limited again to modules that include native libraries. I consider needing to get and build the source for a project as a barrier to adoption. YMMV. David > Paul. From paul.sandoz at oracle.com Fri Jul 13 03:37:04 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 13 Jul 2012 12:37:04 +0200 Subject: Compile time vs. runtime deps In-Reply-To: <4FFFF434.30305@oracle.com> References: <6679083.Hk9oz1TG9s@logoutik> <4FFE2043.4010905@oracle.com> <1976077.ZL4lzu9txV@logoutik> <4FFFA03D.3080907@oracle.com> <4FFFEC86.1010600@oracle.com> <89A5BDD7-5A52-4082-9D3B-9A38243CEC3E@oracle.com> <4FFFF434.30305@oracle.com> Message-ID: <5B026B6A-8A14-4178-B5D1-A49252D6C95B@oracle.com> On Jul 13, 2012, at 12:11 PM, David Holmes wrote: > I consider needing to get and build the source for a project as a barrier to adoption. > In the open source world adoption can and often does involve development. Paul. From paul.sandoz at oracle.com Fri Jul 13 10:14:36 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 13 Jul 2012 19:14:36 +0200 Subject: Publish and fetch a modular jar to a repository Message-ID: <218EBB50-5575-4DA1-BBE2-3D5D2E5E107B@oracle.com> Hi, Here is a webrev to support the publishing and fetching of modular jars from a repository: http://cr.openjdk.java.net/~psandoz/jigsaw/repo-add-jar/webrev/ I resisted the temptation to make too many changes since I think this area will need to go through a significant redesign to generalize the storage of stuff on the repository (src, docs etc) and be extensible to support stuff like reverse indexes and provide a sprinkling of REST on the HTTP repository. So it just adds the feature with minimal fuss. I hacked the testing in rather quickly, it perhaps could be improved with some guidance or feedback. Paul. From Alan.Bateman at oracle.com Mon Jul 16 01:53:40 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 16 Jul 2012 09:53:40 +0100 Subject: Publish and fetch a modular jar to a repository In-Reply-To: <218EBB50-5575-4DA1-BBE2-3D5D2E5E107B@oracle.com> References: <218EBB50-5575-4DA1-BBE2-3D5D2E5E107B@oracle.com> Message-ID: <5003D694.4010904@oracle.com> On 13/07/2012 18:14, Paul Sandoz wrote: > Hi, > > Here is a webrev to support the publishing and fetching of modular jars from a repository: > > http://cr.openjdk.java.net/~psandoz/jigsaw/repo-add-jar/webrev/ > > I resisted the temptation to make too many changes since I think this area will need to go through a significant redesign to generalize the storage of stuff on the repository (src, docs etc) and be extensible to support stuff like reverse indexes and provide a sprinkling of REST on the HTTP repository. > > So it just adds the feature with minimal fuss. > > I hacked the testing in rather quickly, it perhaps could be improved with some guidance or feedback. > > Paul. Yes, the existing repository support is very much a prototype and will likely need need to be designed/replaced in time. Off-hand, I don't see any issue with adding modular JAR files to the existing repository. The only thing that comes to mind is that we will likely need to rev the module format soon to support platform specific modules and other attributes to indicate device features/capabilities. I'm sure that will require updating the repository catalog and we'll need to figure out what that means for modular JAR files, if anything. Anyway, I skimmed through the webrev and made the following notes: ModuleFile.java - L600, I assume you meant usize. Repository.ModuleType - probably best for the enum values to be in uppercase. Repository.ModuleType - L101 - typo, "consistent" -> "consists". The fix to RemoteRepository.java to use setInstanceFollowRedirects is a good catch, that would could easily have lurked for a long time. In Resolver then you might want to rename "ms" as it's no longer a ModuleSize. PublishedRepository.java L198, the toFile() shouldn't be necessary here, can use Files.exists(file). Same thing at L226 where you could use Files.newInputStream. One advantage here is that there is potential for a much more useful exception when there is an error. On testing, then given that it's likely that the repository support will be replaced then it should be okay to just have a test that exercises publishing a few modular JAR files into a repository. I see you've cloned repolist.sh so that should be sufficient for now. -Alan. From paul.sandoz at oracle.com Mon Jul 16 03:18:23 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 16 Jul 2012 12:18:23 +0200 Subject: Publish and fetch a modular jar to a repository In-Reply-To: <5003D694.4010904@oracle.com> References: <218EBB50-5575-4DA1-BBE2-3D5D2E5E107B@oracle.com> <5003D694.4010904@oracle.com> Message-ID: <7428530F-3741-4F6B-8D01-5206A8E10B96@oracle.com> Hi Alan, Thanks for looking at this. Here is an update: http://cr.openjdk.java.net/~psandoz/jigsaw/repo-add-jar/webrev.1/ On Jul 16, 2012, at 10:53 AM, Alan Bateman wrote: > On 13/07/2012 18:14, Paul Sandoz wrote: >> >> Hi, >> >> Here is a webrev to support the publishing and fetching of modular jars from a repository: >> >> http://cr.openjdk.java.net/~psandoz/jigsaw/repo-add-jar/webrev/ >> >> I resisted the temptation to make too many changes since I think this area will need to go through a significant redesign to generalize the storage of stuff on the repository (src, docs etc) and be extensible to support stuff like reverse indexes and provide a sprinkling of REST on the HTTP repository. >> >> So it just adds the feature with minimal fuss. >> >> I hacked the testing in rather quickly, it perhaps could be improved with some guidance or feedback. >> >> Paul. > Yes, the existing repository support is very much a prototype and will likely need need to be designed/replaced in time. > > Off-hand, I don't see any issue with adding modular JAR files to the existing repository. FWIW all my ant macros/targets now work :-) > The only thing that comes to mind is that we will likely need to rev the module format soon to support platform specific modules and other attributes to indicate device features/capabilities. I'm sure that will require updating the repository catalog and we'll need to figure out what that means for modular JAR files, if anything. > Yes, i think this comes down to having multiple content associated with a module id, whether that be module files for various capabilities, source or javadoc etc. IMHO the catalog needs to be in an extensible format that is easily consumable i.e. it is something that is likely to be consumed by many clients, in various languages, for various purposes. To me that means a textual format. That does not rule out other optimized formats. One can use HTTP content negotiation and/or there can be a services document, served by the root resource, that tells the client what there is and how to get to it (no need to hard code all URIs). > Anyway, I skimmed through the webrev and made the following notes: > > ModuleFile.java - L600, I assume you meant usize. > Yes, good catch. > Repository.ModuleType - probably best for the enum values to be in uppercase. My preference is to use symbols where possible, e.g. in this case the name of an enum corresponds directly to the file extension name. But i realize this is not to everyones taste so i changed it. > Repository.ModuleType - L101 - typo, "consistent" -> "consists". > OK. > The fix to RemoteRepository.java to use setInstanceFollowRedirects is a good catch, that would could easily have lurked for a long time. > Yes, that's a nasty one :-) > In Resolver then you might want to rename "ms" as it's no longer a ModuleSize. > OK. > PublishedRepository.java L198, the toFile() shouldn't be necessary here, can use Files.exists(file). Same thing at L226 where you could use Files.newInputStream. One advantage here is that there is potential for a much more useful exception when there is an error. > OK. Paul. > On testing, then given that it's likely that the repository support will be replaced then it should be okay to just have a test that exercises publishing a few modular JAR files into a repository. I see you've cloned repolist.sh so that should be sufficient for now. > > -Alan. > > From chris.hegarty at oracle.com Mon Jul 16 03:30:24 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 16 Jul 2012 11:30:24 +0100 Subject: Publish and fetch a modular jar to a repository In-Reply-To: <5003D694.4010904@oracle.com> References: <218EBB50-5575-4DA1-BBE2-3D5D2E5E107B@oracle.com> <5003D694.4010904@oracle.com> Message-ID: <5003ED40.6010607@oracle.com> Paul, I've gone through these changes too, looks good to me. Trivially, L281 PublishedRepository.java, the local 'len' is not needed, simply 'while (in.read(buf) != -1)'. I also wonder in ModuleMetaData if download() and install() should be renamed to downloadSize() and installSize(), since ModuleSize -> ModuleMetaData. Just a thought when I seen the usage in Resolver. -Chris. On 16/07/2012 09:53, Alan Bateman wrote: > On 13/07/2012 18:14, Paul Sandoz wrote: >> Hi, >> >> Here is a webrev to support the publishing and fetching of modular >> jars from a repository: >> >> http://cr.openjdk.java.net/~psandoz/jigsaw/repo-add-jar/webrev/ >> >> I resisted the temptation to make too many changes since I think this >> area will need to go through a significant redesign to generalize the >> storage of stuff on the repository (src, docs etc) and be extensible >> to support stuff like reverse indexes and provide a sprinkling of REST >> on the HTTP repository. >> >> So it just adds the feature with minimal fuss. >> >> I hacked the testing in rather quickly, it perhaps could be improved >> with some guidance or feedback. >> >> Paul. > Yes, the existing repository support is very much a prototype and will > likely need need to be designed/replaced in time. > > Off-hand, I don't see any issue with adding modular JAR files to the > existing repository. The only thing that comes to mind is that we will > likely need to rev the module format soon to support platform specific > modules and other attributes to indicate device features/capabilities. > I'm sure that will require updating the repository catalog and we'll > need to figure out what that means for modular JAR files, if anything. > > Anyway, I skimmed through the webrev and made the following notes: > > ModuleFile.java - L600, I assume you meant usize. > > Repository.ModuleType - probably best for the enum values to be in > uppercase. > Repository.ModuleType - L101 - typo, "consistent" -> "consists". > > The fix to RemoteRepository.java to use setInstanceFollowRedirects is a > good catch, that would could easily have lurked for a long time. > > In Resolver then you might want to rename "ms" as it's no longer a > ModuleSize. > > PublishedRepository.java L198, the toFile() shouldn't be necessary here, > can use Files.exists(file). Same thing at L226 where you could use > Files.newInputStream. One advantage here is that there is potential for > a much more useful exception when there is an error. > > On testing, then given that it's likely that the repository support will > be replaced then it should be okay to just have a test that exercises > publishing a few modular JAR files into a repository. I see you've > cloned repolist.sh so that should be sufficient for now. > > -Alan. > > From paul.sandoz at oracle.com Mon Jul 16 03:42:38 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 16 Jul 2012 12:42:38 +0200 Subject: Publish and fetch a modular jar to a repository In-Reply-To: <5003ED40.6010607@oracle.com> References: <218EBB50-5575-4DA1-BBE2-3D5D2E5E107B@oracle.com> <5003D694.4010904@oracle.com> <5003ED40.6010607@oracle.com> Message-ID: <47F071DC-5D9A-4C70-A47E-CFAF6FB04225@oracle.com> On Jul 16, 2012, at 12:30 PM, Chris Hegarty wrote: > Paul, > > I've gone through these changes too, looks good to me. > Thanks. > Trivially, L281 PublishedRepository.java, the local 'len' is not needed, simply 'while (in.read(buf) != -1)'. > OK. > I also wonder in ModuleMetaData if download() and install() should be renamed to downloadSize() and installSize(), since ModuleSize -> ModuleMetaData. Just a thought when I seen the usage in Resolver. > OK. s/download()/getDownloadSize() http://cr.openjdk.java.net/~psandoz/jigsaw/repo-add-jar/webrev.2/ Paul. From Alan.Bateman at oracle.com Mon Jul 16 08:50:44 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 16 Jul 2012 16:50:44 +0100 Subject: Publish and fetch a modular jar to a repository In-Reply-To: <7428530F-3741-4F6B-8D01-5206A8E10B96@oracle.com> References: <218EBB50-5575-4DA1-BBE2-3D5D2E5E107B@oracle.com> <5003D694.4010904@oracle.com> <7428530F-3741-4F6B-8D01-5206A8E10B96@oracle.com> Message-ID: <50043854.30605@oracle.com> On 16/07/2012 11:18, Paul Sandoz wrote: > Hi Alan, > > Thanks for looking at this. > > Here is an update: > > http://cr.openjdk.java.net/~psandoz/jigsaw/repo-add-jar/webrev.1/ I see there's a webrev.2 with additional comments from Chris so I looked at that. On Repository.ModuleType I see you've changed it to add a constructor to take the extension type so that looks better although I do think the enum values should in uppercase. Otherwise I don't have any issues, I think Chris is going to help you get this in. > : > > IMHO the catalog needs to be in an extensible format that is easily consumable i.e. it is something that is likely to be consumed by many clients, in various languages, for various purposes. To me that means a textual format. That does not rule out other optimized formats. One can use HTTP content negotiation and/or there can be a services document, served by the root resource, that tells the client what there is and how to get to it (no need to hard code all URIs). > I agree it needs to be easy to consume, also we have to assume it will change or be extended over time. Also need to thing through use-cases, like modules moving to be another repository, etc. I think it will be useful to also look at existing and well-established repositories as this isn't new ground. -Alan From paul.sandoz at oracle.com Mon Jul 16 09:21:36 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 16 Jul 2012 18:21:36 +0200 Subject: Publish and fetch a modular jar to a repository In-Reply-To: <50043854.30605@oracle.com> References: <218EBB50-5575-4DA1-BBE2-3D5D2E5E107B@oracle.com> <5003D694.4010904@oracle.com> <7428530F-3741-4F6B-8D01-5206A8E10B96@oracle.com> <50043854.30605@oracle.com> Message-ID: <887F8EF5-B3AC-4AAA-AF1B-DCCF225B86FF@oracle.com> On Jul 16, 2012, at 5:50 PM, Alan Bateman wrote: > On 16/07/2012 11:18, Paul Sandoz wrote: >> Hi Alan, >> >> Thanks for looking at this. >> >> Here is an update: >> >> http://cr.openjdk.java.net/~psandoz/jigsaw/repo-add-jar/webrev.1/ > I see there's a webrev.2 with additional comments from Chris so I looked at that. > > On Repository.ModuleType I see you've changed it to add a constructor to take the extension type so that looks better although I do think the enum values should in uppercase. OK, converted to upper case. I have no strong preference on the style, just wanna be consistent, like with code formatting (but wanna automate that bit): http://cr.openjdk.java.net/~psandoz/jigsaw/repo-add-jar/webrev.3/ > > Otherwise I don't have any issues, I think Chris is going to help you get this in. > Yes. >> : >> >> IMHO the catalog needs to be in an extensible format that is easily consumable i.e. it is something that is likely to be consumed by many clients, in various languages, for various purposes. To me that means a textual format. That does not rule out other optimized formats. One can use HTTP content negotiation and/or there can be a services document, served by the root resource, that tells the client what there is and how to get to it (no need to hard code all URIs). >> > I agree it needs to be easy to consume, also we have to assume it will change or be extended over time. Also need to thing through use-cases, like modules moving to be another repository, etc. I think it will be useful to also look at existing and well-established repositories as this isn't new ground. > Agreed, given my moderate RESTafarian background we may be able to do some interesting stuff. Paul. From Alan.Bateman at oracle.com Mon Jul 16 10:42:16 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 16 Jul 2012 18:42:16 +0100 Subject: Publish and fetch a modular jar to a repository In-Reply-To: <887F8EF5-B3AC-4AAA-AF1B-DCCF225B86FF@oracle.com> References: <218EBB50-5575-4DA1-BBE2-3D5D2E5E107B@oracle.com> <5003D694.4010904@oracle.com> <7428530F-3741-4F6B-8D01-5206A8E10B96@oracle.com> <50043854.30605@oracle.com> <887F8EF5-B3AC-4AAA-AF1B-DCCF225B86FF@oracle.com> Message-ID: <50045278.5010605@oracle.com> On 16/07/2012 17:21, Paul Sandoz wrote: > > : > OK, converted to upper case. I have no strong preference on the style, just wanna be consistent, like with code formatting (but wanna automate that bit): > > http://cr.openjdk.java.net/~psandoz/jigsaw/repo-add-jar/webrev.3/ > > Thanks looks fine to me. -Alan From jaroslav.tulach at oracle.com Tue Jul 17 01:17:53 2012 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Tue, 17 Jul 2012 10:17:53 +0200 Subject: Convert to Modular JAR was: Publish and fetch a modular jar to a repository In-Reply-To: <50045278.5010605@oracle.com> References: <218EBB50-5575-4DA1-BBE2-3D5D2E5E107B@oracle.com> <887F8EF5-B3AC-4AAA-AF1B-DCCF225B86FF@oracle.com> <50045278.5010605@oracle.com> Message-ID: <2601914.8Wx6BtPsZb@logoutik> Dne Po 16. ?ervence 2012 18:42:16, Alan Bateman napsal(a): > On 16/07/2012 17:21, Paul Sandoz wrote: > > OK, converted to upper case. I have no strong preference on the style, just wanna be consistent, like with code formatting (but wanna automate that bit): > > http://cr.openjdk.java.net/~psandoz/jigsaw/repo-add-jar/webrev.3/ > > Thanks looks fine to me. Hello Paul, my comment may not be related to this particular webrev, but I think it is good time to remind that we plan to base the NetBeans IDE support for Jigsaw on modular JAR files and we need a way to convert any module to modular JAR format. There is method public abstract InputStream fetch(ModuleId mid); in the Repository class. Should not it be public abstract InputStream fetch(ModuleId mid, ModuleType format); so we can request any module in modular JAR format? -jt From chris.hegarty at oracle.com Tue Jul 17 01:55:17 2012 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 17 Jul 2012 08:55:17 +0000 Subject: hg: jigsaw/jigsaw/jdk: Publish and fetch a modular jar to a repository Message-ID: <20120717085558.04420470CB@hg.openjdk.java.net> Changeset: ed49f4a2a06d Author: psandoz Date: 2012-07-17 09:53 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/ed49f4a2a06d Publish and fetch a modular jar to a repository Reviewed-by: alanb, chegar ! src/share/classes/org/openjdk/jigsaw/ModuleFile.java ! src/share/classes/org/openjdk/jigsaw/PublishedRepository.java ! src/share/classes/org/openjdk/jigsaw/RemoteRepository.java ! src/share/classes/org/openjdk/jigsaw/Repository.java ! src/share/classes/org/openjdk/jigsaw/RepositoryCatalog.java ! src/share/classes/org/openjdk/jigsaw/Resolver.java ! src/share/classes/org/openjdk/jigsaw/SimpleLibrary.java ! test/org/openjdk/jigsaw/_PublishedRepository.java ! test/org/openjdk/jigsaw/_RepositoryCatalog.java + test/org/openjdk/jigsaw/repolist-jars.sh From paul.sandoz at oracle.com Tue Jul 17 02:16:06 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 17 Jul 2012 11:16:06 +0200 Subject: Convert to Modular JAR was: Publish and fetch a modular jar to a repository In-Reply-To: <2601914.8Wx6BtPsZb@logoutik> References: <218EBB50-5575-4DA1-BBE2-3D5D2E5E107B@oracle.com> <887F8EF5-B3AC-4AAA-AF1B-DCCF225B86FF@oracle.com> <50045278.5010605@oracle.com> <2601914.8Wx6BtPsZb@logoutik> Message-ID: <28409ED5-567F-4F64-860E-82327C9E5D72@oracle.com> Hi, On Jul 17, 2012, at 10:17 AM, Jaroslav Tulach wrote: > Dne Po 16. ?ervence 2012 18:42:16, Alan Bateman napsal(a): >> On 16/07/2012 17:21, Paul Sandoz wrote: >>> OK, converted to upper case. I have no strong preference on the style, > just wanna be consistent, like with code formatting (but wanna automate that > bit): >>> http://cr.openjdk.java.net/~psandoz/jigsaw/repo-add-jar/webrev.3/ >> >> Thanks looks fine to me. > > Hello Paul, > my comment may not be related to this particular webrev, but I think it is > good time to remind that we plan to base the NetBeans IDE support for Jigsaw > on modular JAR files and we need a way to convert any module to modular JAR > format. > > There is method > > public abstract InputStream fetch(ModuleId mid); > > in the Repository class. Should not it be > > public abstract InputStream fetch(ModuleId mid, ModuleType format); > > so we can request any module in modular JAR format? I did think about transformation but I opted for an initial solution of what you publish is what you get. So it would currently be up to the client to do such a transformation, using a Jigsaw API, TBD as i don't think it exists, but we can easily add an option to jmod and the API, at least that will move in the right direction. If transformation is performed by the repository then we need to think carefully about what to do if the original published content is signed. Maybe extraction of class files/resources is the right way to think about this? since there could be information loss when transforming from jmod to jar. -- A repository could offer an extraction service using the Jigsaw API, that works appropriately with HTTP caching and local file caching e.g. if the URL to a module is: GET /repository/{mid}/module The URL to the class data could be: GET /repository/{mid}/module/classes and there could be a method: InputStream fetchClasses(ModuleId mid, String mediaType); In general the mid location will be a container for multiple content (src docs etc) so we need to work out how to identify that content, perhaps using link relations (as tags) + media types for content negotiation. Paul. From sean.mullan at oracle.com Tue Jul 17 05:12:49 2012 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 17 Jul 2012 08:12:49 -0400 Subject: Convert to Modular JAR was: Publish and fetch a modular jar to a repository In-Reply-To: <28409ED5-567F-4F64-860E-82327C9E5D72@oracle.com> References: <218EBB50-5575-4DA1-BBE2-3D5D2E5E107B@oracle.com> <887F8EF5-B3AC-4AAA-AF1B-DCCF225B86FF@oracle.com> <50045278.5010605@oracle.com> <2601914.8Wx6BtPsZb@logoutik> <28409ED5-567F-4F64-860E-82327C9E5D72@oracle.com> Message-ID: <500556C1.3050709@oracle.com> On 7/17/12 5:16 AM, Paul Sandoz wrote: > Hi, > > On Jul 17, 2012, at 10:17 AM, Jaroslav Tulach wrote: > >> Dne Po 16. ?ervence 2012 18:42:16, Alan Bateman napsal(a): >>> On 16/07/2012 17:21, Paul Sandoz wrote: >>>> OK, converted to upper case. I have no strong preference on the style, >>>> >> just wanna be consistent, like with code formatting (but wanna automate >> that bit): >>>> http://cr.openjdk.java.net/~psandoz/jigsaw/repo-add-jar/webrev.3/ >>> >>> Thanks looks fine to me. >> >> Hello Paul, my comment may not be related to this particular webrev, but I >> think it is good time to remind that we plan to base the NetBeans IDE >> support for Jigsaw on modular JAR files and we need a way to convert any >> module to modular JAR format. >> >> There is method >> >> public abstract InputStream fetch(ModuleId mid); >> >> in the Repository class. Should not it be >> >> public abstract InputStream fetch(ModuleId mid, ModuleType format); >> >> so we can request any module in modular JAR format? > > I did think about transformation but I opted for an initial solution of what > you publish is what you get. So it would currently be up to the client to do > such a transformation, using a Jigsaw API, TBD as i don't think it exists, > but we can easily add an option to jmod and the API, at least that will move > in the right direction. > > If transformation is performed by the repository then we need to think > carefully about what to do if the original published content is signed. Are you talking about being able to extract modules from the library as a modular JAR? If the module is signed, you have a bit of a problem. In order to create a signed modular JAR you would have to re-sign the JAR and this is not possible without having access to the private key, which isn't stored in the library. However, if the primary use case is for NetBeans, I believe you may be able to leverage the KeyStore you use to create signed JARs and use that (probably with some configuration involved to choose the right key). --Sean > > Maybe extraction of class files/resources is the right way to think about > this? since there could be information loss when transforming from jmod to > jar. > From paul.sandoz at oracle.com Tue Jul 17 05:45:38 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 17 Jul 2012 14:45:38 +0200 Subject: Convert to Modular JAR was: Publish and fetch a modular jar to a repository In-Reply-To: <500556C1.3050709@oracle.com> References: <218EBB50-5575-4DA1-BBE2-3D5D2E5E107B@oracle.com> <887F8EF5-B3AC-4AAA-AF1B-DCCF225B86FF@oracle.com> <50045278.5010605@oracle.com> <2601914.8Wx6BtPsZb@logoutik> <28409ED5-567F-4F64-860E-82327C9E5D72@oracle.com> <500556C1.3050709@oracle.com> Message-ID: <6A38A7A9-3F92-47E9-A98E-38D1218F87BB@oracle.com> On Jul 17, 2012, at 2:12 PM, Sean Mullan wrote: > On 7/17/12 5:16 AM, Paul Sandoz wrote: >> Hi, >> >> On Jul 17, 2012, at 10:17 AM, Jaroslav Tulach wrote: >> >>> Dne Po 16. ?ervence 2012 18:42:16, Alan Bateman napsal(a): >>>> On 16/07/2012 17:21, Paul Sandoz wrote: >>>>> OK, converted to upper case. I have no strong preference on the style, >>>>> >>> just wanna be consistent, like with code formatting (but wanna automate >>> that bit): >>>>> http://cr.openjdk.java.net/~psandoz/jigsaw/repo-add-jar/webrev.3/ >>>> >>>> Thanks looks fine to me. >>> >>> Hello Paul, my comment may not be related to this particular webrev, but I >>> think it is good time to remind that we plan to base the NetBeans IDE >>> support for Jigsaw on modular JAR files and we need a way to convert any >>> module to modular JAR format. >>> >>> There is method >>> >>> public abstract InputStream fetch(ModuleId mid); >>> >>> in the Repository class. Should not it be >>> >>> public abstract InputStream fetch(ModuleId mid, ModuleType format); >>> >>> so we can request any module in modular JAR format? >> >> I did think about transformation but I opted for an initial solution of what >> you publish is what you get. So it would currently be up to the client to do >> such a transformation, using a Jigsaw API, TBD as i don't think it exists, >> but we can easily add an option to jmod and the API, at least that will move >> in the right direction. >> >> If transformation is performed by the repository then we need to think >> carefully about what to do if the original published content is signed. > > Are you talking about being able to extract modules from the library as a > modular JAR? We were discussing repositories and fetching modules as modular jar files that were originally uploaded (published) as jmod files. Which, IIUC what you say below will have similar issues related to transforming a signed jmod file into signed modular jar file. AFAICT the primary use-case is to get access to the Java class files of a module. So one can consider it more of an extraction process, which could apply to both library and repositories and i presume both are relevant to NBs. Paul. > If the module is signed, you have a bit of a problem. In order to > create a signed modular JAR you would have to re-sign the JAR and this is not > possible without having access to the private key, which isn't stored in the > library. However, if the primary use case is for NetBeans, I believe you may be > able to leverage the KeyStore you use to create signed JARs and use that > (probably with some configuration involved to choose the right key). > > --Sean >> >> Maybe extraction of class files/resources is the right way to think about >> this? since there could be information loss when transforming from jmod to >> jar. >> > From paul.sandoz at oracle.com Tue Jul 17 07:06:55 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 17 Jul 2012 16:06:55 +0200 Subject: Extract to Modular JAR Re: Convert to Modular JAR was: Publish and fetch a modular jar to a repository In-Reply-To: <28409ED5-567F-4F64-860E-82327C9E5D72@oracle.com> References: <218EBB50-5575-4DA1-BBE2-3D5D2E5E107B@oracle.com> <887F8EF5-B3AC-4AAA-AF1B-DCCF225B86FF@oracle.com> <50045278.5010605@oracle.com> <2601914.8Wx6BtPsZb@logoutik> <28409ED5-567F-4F64-860E-82327C9E5D72@oracle.com> Message-ID: <4E144307-0E79-4419-B2B3-26E2EA4842B1@oracle.com> Hi Baby steps: 1) create a class that extracts a modular jar from a jmod file. This is rather simple using Chris's ModuleFileParser. 2) add a command to jpkg to extract a modular jar from a jmod file 3) add a command to jmod to extract a modular jar from a module installed in a library. 4) add method Repository.fetchClasses The implementation can simple call fetch and hook up with 1) if the module type is jmod. The latter is really an interim solution until this area is overhauled. Paul. On Jul 17, 2012, at 11:16 AM, Paul Sandoz wrote: > Hi, > > On Jul 17, 2012, at 10:17 AM, Jaroslav Tulach wrote: > >> Dne Po 16. ?ervence 2012 18:42:16, Alan Bateman napsal(a): >>> On 16/07/2012 17:21, Paul Sandoz wrote: >>>> OK, converted to upper case. I have no strong preference on the style, >> just wanna be consistent, like with code formatting (but wanna automate that >> bit): >>>> http://cr.openjdk.java.net/~psandoz/jigsaw/repo-add-jar/webrev.3/ >>> >>> Thanks looks fine to me. >> >> Hello Paul, >> my comment may not be related to this particular webrev, but I think it is >> good time to remind that we plan to base the NetBeans IDE support for Jigsaw >> on modular JAR files and we need a way to convert any module to modular JAR >> format. >> >> There is method >> >> public abstract InputStream fetch(ModuleId mid); >> >> in the Repository class. Should not it be >> >> public abstract InputStream fetch(ModuleId mid, ModuleType format); >> >> so we can request any module in modular JAR format? > > I did think about transformation but I opted for an initial solution of what you publish is what you get. So it would currently be up to the client to do such a transformation, using a Jigsaw API, TBD as i don't think it exists, but we can easily add an option to jmod and the API, at least that will move in the right direction. > > If transformation is performed by the repository then we need to think carefully about what to do if the original published content is signed. > > Maybe extraction of class files/resources is the right way to think about this? since there could be information loss when transforming from jmod to jar. > > -- > > A repository could offer an extraction service using the Jigsaw API, that works appropriately with HTTP caching and local file caching e.g. if the URL to a module is: > > GET /repository/{mid}/module > > The URL to the class data could be: > > GET /repository/{mid}/module/classes > > and there could be a method: > > InputStream fetchClasses(ModuleId mid, String mediaType); > > In general the mid location will be a container for multiple content (src docs etc) so we need to work out how to identify that content, perhaps using link relations (as tags) + media types for content negotiation. > > Paul. From mark.reinhold at oracle.com Tue Jul 17 08:57:39 2012 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 17 Jul 2012 08:57:39 -0700 Subject: Late for the train Message-ID: <20120717155739.64B3C1CA6@eggemoggin.niobe.net> As some of you are already aware, I've concluded with regret that Project Jigsaw isn't going to make Java 8 as planned. I've set out my reasoning in a blog entry [1], and I've asked the Java SE 8 EG to consider dropping the module system and modularization from the release [2]. Slipping Jigsaw to Java 9 isn't an easy decision, but I think it's the best of a set of unpleasant options. We've made a lot of progress over the past year, and I'm determined that we do our best to maintain our momentum from here to Java 9. I thank those who've contributed to this effort so far, in ways both large and small, and I hope you'll all be able to stay aboard for the rest of the journey. - Mark [1] http://mreinhold.org/blog/late-for-the-train [2] http://mail.openjdk.java.net/pipermail/java-se-8-spec-observers/2012-July/000001.html From henri.gomez at gmail.com Tue Jul 17 23:54:00 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Wed, 18 Jul 2012 08:54:00 +0200 Subject: Late for the train In-Reply-To: <20120717155739.64B3C1CA6@eggemoggin.niobe.net> References: <20120717155739.64B3C1CA6@eggemoggin.niobe.net> Message-ID: It's sad and will make adoption ever harder for Java 9. For those requiring today modularization, OSGI will be the only solution for Java 7 and 8 and it will be hard to move companies who will adopt it to move back to jigsaw ;( 2012/7/17 : > As some of you are already aware, I've concluded with regret that Project > Jigsaw isn't going to make Java 8 as planned. I've set out my reasoning > in a blog entry [1], and I've asked the Java SE 8 EG to consider dropping > the module system and modularization from the release [2]. > > Slipping Jigsaw to Java 9 isn't an easy decision, but I think it's the > best of a set of unpleasant options. We've made a lot of progress over > the past year, and I'm determined that we do our best to maintain our > momentum from here to Java 9. I thank those who've contributed to this > effort so far, in ways both large and small, and I hope you'll all be > able to stay aboard for the rest of the journey. > > - Mark > > > [1] http://mreinhold.org/blog/late-for-the-train > [2] http://mail.openjdk.java.net/pipermail/java-se-8-spec-observers/2012-July/000001.html From jaroslav.tulach at oracle.com Wed Jul 18 07:44:18 2012 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Wed, 18 Jul 2012 16:44:18 +0200 Subject: Convert to Modular JAR In-Reply-To: <28409ED5-567F-4F64-860E-82327C9E5D72@oracle.com> References: <218EBB50-5575-4DA1-BBE2-3D5D2E5E107B@oracle.com> <2601914.8Wx6BtPsZb@logoutik> <28409ED5-567F-4F64-860E-82327C9E5D72@oracle.com> Message-ID: <1822784.tWEEsblVti@logoutik> Hello Paul, right, I have not thought about signed modules. The IDE does not need signed modules for its internal purposes. That is why it is always OK to export into unsigned JAR files. I've also give second thought to the idea of repository. Now I think the repository should primarily be about listing its content and downloading it to local library[1]. If you want to encourage 3rd party implementations of repositories, it does not make sense to put additional requirements on the implementors. Thus the conversion logic might be too complex to be part of a repository. If the conversion is not part of a repository, then it probably belongs to a library (right)? In such case the IDE could always create a library and load necessary modules into it and then do the conversion. -jt [1] I hope I am not confusing the repository/library terms again. Dne ?t 17. ?ervence 2012 11:16:06, Paul Sandoz napsal(a): > Hi, > > On Jul 17, 2012, at 10:17 AM, Jaroslav Tulach wrote: > > Dne Po 16. ?ervence 2012 18:42:16, Alan Bateman napsal(a): > >> On 16/07/2012 17:21, Paul Sandoz wrote: > >>> OK, converted to upper case. I have no strong preference on the style, > > > > just wanna be consistent, like with code formatting (but wanna automate > > that> > > bit): > >>> http://cr.openjdk.java.net/~psandoz/jigsaw/repo-add-jar/webrev.3/ > >> > >> Thanks looks fine to me. > > > > Hello Paul, > > my comment may not be related to this particular webrev, but I think it is > > good time to remind that we plan to base the NetBeans IDE support for > > Jigsaw on modular JAR files and we need a way to convert any module to > > modular JAR format. > > > > There is method > > > > public abstract InputStream fetch(ModuleId mid); > > > > in the Repository class. Should not it be > > > > public abstract InputStream fetch(ModuleId mid, ModuleType format); > > > > so we can request any module in modular JAR format? > > I did think about transformation but I opted for an initial solution of what > you publish is what you get. So it would currently be up to the client to > do such a transformation, using a Jigsaw API, TBD as i don't think it > exists, but we can easily add an option to jmod and the API, at least that > will move in the right direction. > > If transformation is performed by the repository then we need to think > carefully about what to do if the original published content is signed. > > Maybe extraction of class files/resources is the right way to think about > this? since there could be information loss when transforming from jmod to > jar. From paul.sandoz at oracle.com Wed Jul 18 08:44:04 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 18 Jul 2012 17:44:04 +0200 Subject: Convert to Modular JAR In-Reply-To: <1822784.tWEEsblVti@logoutik> References: <218EBB50-5575-4DA1-BBE2-3D5D2E5E107B@oracle.com> <2601914.8Wx6BtPsZb@logoutik> <28409ED5-567F-4F64-860E-82327C9E5D72@oracle.com> <1822784.tWEEsblVti@logoutik> Message-ID: Hi, On Jul 18, 2012, at 4:44 PM, Jaroslav Tulach wrote: > Hello Paul, > right, I have not thought about signed modules. The IDE does not need signed > modules for its internal purposes. That is why it is always OK to export into > unsigned JAR files. > > I've also give second thought to the idea of repository. Now I think the > repository should primarily be about listing its content and downloading it to > local library[1]. If you want to encourage 3rd party implementations of > repositories, it does not make sense to put additional requirements on the > implementors. Thus the conversion logic might be too complex to be part of a > repository. > > If the conversion is not part of a repository, then it probably belongs to a > library (right)? In such case the IDE could always create a library and load > necessary modules into it and then do the conversion. > > -jt > > [1] I hope I am not confusing the repository/library terms again. > Perhaps :-) a library is a "container" where module files are installed and things are optimized for the execution of applications. An entry point (e.g. "class foo.Main") defined in a module will result in running the resolver and production of a configuration, which may fail. Will NBs need to fetch modules and extract class files for the purpose analysis and *potential* installation into a library? -- A repository is just a collection of module files with a catalog for fast look up. There are currently two implementations of org.openjdk.jigsaw.Repository, a RemoteRepository that supports the file and http URI schemes for the fetching of the catalog and module files, and a PublishedRepostiory that is a file-based repository that also supports the publishing of module files. It's quite easy to support the extraction functionality locally in an implementation of Repository [*]. What i think we require to improve matters is to support a local cache of module files fetched from a remote repository (e.g. like ~/.m2/repository). Then extracted classes can also be cached locally. Currently the RemoteRepository implementation only caches the catalog. I think it is quite easy to support the caching of module files, which is essentially a file-based repository (as supported by PublishedRepository). Hth, Paul. [*] An HTTP repository could also support an optional extraction feature (easy to describe with a service document) and the RemoteRepository implementation can be smart enough to know what to do .e.g make a GET request or perform the work locally. From niftiness at gmail.com Mon Jul 9 07:00:32 2012 From: niftiness at gmail.com (Tim Boudreau) Date: Mon, 9 Jul 2012 10:00:32 -0400 Subject: Modular services with OpenJDK Jigsaw and Guice In-Reply-To: <13556194.iPbhCHo037@logoutik> References: <13556194.iPbhCHo037@logoutik> Message-ID: I think I can now describe how to do this with Guice - it requires a small dirty trick - register a listener which "hears" all injections, and puts the type being injected into a ThreadLocal; then bind a provider which looks in the ThreadLocal to see what to inject. But you will still need a way to iterate the list of types which should be bound, to tell Guice about them at startup. You might be able to write a Key subclass that allows them to be bound without actually loading the classes, though. Guice 3.0's API probably has enough meat on it to do fancier things. It is true that Guice generally wants to know explicitly what bindings are on VM startup - lately the way I deal with this for complex registration is to write an annotation processor which generates some sort of file with a list of bindings, and then read that at runtime. I've also used Lookup as a layer underneath Guice - generally with Guice, either an interface has to specify its implementation with @ImplementedBy, or there must be a Guice module which knows about both the interface and the implementation class and glues them together. So true service "discovery" is out-of-scope for Guice - and Lookup is very handy for a bootstrapping layer which does that, underneath Guice. I don't think lazy loading or late binding was ever something Guice was designed for - its target is server side applications where, in a deployment scenario, it's more important that the application fail fast (i.e. unsatisfied bindings are detected at startup) than that the application start up fast. So generally, you imperatively *tell* Guice about bindings - it is very magic-free. I think this is the correct target for Guice - it is simply solving a different problem for a different kind of application than Lookup is. FYI, if you hg clone http://timboudreau.com/code/useful and look in the guicey/guicey project, you will find an implementation of a Guice Scope over Lookup; you could probably do whatever you want with how the Lookup it uses gets constructed. However, something still needs to bind those types in that scope (see AbstractScope.bindTypes()) - in practice typically there is some well-known object (application main class) which I just annotate with the list of additional types to bind in the appropriate scope (in fact, weirdly, I end up injecting a Scope object). -Tim On Mon, Jul 9, 2012 at 7:49 AM, Jaroslav Tulach wrote: > Dne P? 6. ?ervence 2012 18:43:08, Paul Sandoz napsal(a): > > Something for the weekend: > > > > > http://earthly-powers.blogspot.fr/2012/07/modular-services-with-openjdk-jigs > > aw.html > > Interesting. I was playing with something similar, but with Spring: > http://wiki.apidesign.org/wiki/LookupAndSpring > Translation notes: > - Lookup.getDefault() means something like ServiceLoader.load(all_types) > - @ServiceProvider is "provides service" > > I was trying to do this with Guice as well, but it does not work well. > Guice > would like to know all registered services before its "module" is > constructed > and we were seeking for a lazy binding. However we have not managed to > convince Guice to call us back, when a particular type is needed. We gave > up. > > -jt > > -- http://timboudreau.com From niftiness at gmail.com Tue Jul 10 10:54:13 2012 From: niftiness at gmail.com (Tim Boudreau) Date: Tue, 10 Jul 2012 13:54:13 -0400 Subject: Modular services with OpenJDK Jigsaw and Guice In-Reply-To: <17A28CF7-FE0E-45A2-90BB-59623F62B328@oracle.com> References: <13556194.iPbhCHo037@logoutik> <17A28CF7-FE0E-45A2-90BB-59623F62B328@oracle.com> Message-ID: On Tue, Jul 10, 2012 at 4:38 AM, Paul Sandoz wrote: > Sisu provides extensions to Guice to avoid the need to explicitly bind: > > http://www.eclipse.org/sisu/ > > but i dunno if that can do what you want. > > FWIW i have a preference for explicit bindings, it seems to fit well with > the idea of a module declaration expressing it's interface to consumers. > Yeah, I've done the classpath scanning thing too. It's a bit brute-force and ugly, though. It does give you an additional sanity check on startup - if a class couldn't actually resolve its dependencies or threw an exception in a static initializer, you find that out immediately on startup. When I did this, I would just, say, look up all non-abstract subtypes of some interface which did not have my @Invisible annotation. But I don't think it's worth it - I'd rather use a mechanism like Lookup, or if I need more metadata, write an annotation processor that writes a file into the classpath, and then provide a module that finds and reads all such files, loads classes and binds them. Forcing loading every class the VM can see is overkill - and it should be a clear indication to anybody doing it that they're trying to fit a square peg in a round hole. The thing we're really touching on here is that Service Discovery != Dependency Injection, and sometimes you need both. Trying to shoehorn generic service discovery into Guice doesn't seem like a fabulous idea - it's simply not for that. If you've gotta, gotta, gotta do that, an annotation processor and some mechanism like META-INF/services files will work (ideally with richer metainfo than just a class name). But Guice injection is entirely based around Key[1] - which really just wraps up a type, generic RTTI and optional annotations; when it tries to inject a constructor parameter, it is constructing a Key for that parameter and then comparing it with the keys that the injector knows about. So injection is not polymorphic unless you tell Guice it is - I can call Lookup.lookup(Object.class) and I'll get something or other; if I @Inject Object, it's an error unless something told Guice to bind Object somehow - it will not guess for me (I had to learn this the hard way a few years ago, since I was used to Lookup [2]). One of my favorite things about Guice (as opposed to, say, Spring) is that it is tightly focused on exactly one very specific problem it's there to solve. It isn't a service discovery library, it's a separate-your-configuration-from-your-business-logic library. Probably things that try to abuse Guice to be a service-discovery/auto-wiring platform should not be encouraged, and some simple, clean mechanism like Lookup should be fulfilling that role - with an easy way to wrap a Guice Provider around that mechanism *for specific types*. Auto-wiring is useful and good (but commonly you need a way to override or turn pieces of it off in a test environment, and that aspect is usually implemented as an afterthought or hack when somebody tries to write a test and something explodes - Jarda, how many subclasses are there of Repository in older unit tests for NetBeans that don't directly use FileSystem?). It's good to have the mechanism be configurable and optionally able to be initialized by running code on startup (to solve the test environment problem). But it's really a different problem than Guice solves - it's just that the shape of the solution is deceptively similar. Orthagonal to all of this is the desire not to load classes on startup. That's an optimization. One that's critical for desktop applications, and uninteresting or even harmful for server-side applications (if the process is going to run for months, I care much more about it failing quickly if it's broken than I do about startup time). So probably any service discovery mechanism should be *able* to be completely declarative, but that should not be the only way to initialize things. -Tim [1] http://google-guice.googlecode.com/git/javadoc/com/google/inject/Key.html [2] https://groups.google.com/forum/?fromgroups#!topic/google-guice/wyA1ZijITZU From david.lloyd at redhat.com Tue Jul 17 09:04:33 2012 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 17 Jul 2012 11:04:33 -0500 Subject: Extents of extensibility ("is this thing on?") Message-ID: <50058D11.3020106@redhat.com> Jigsaw still has one glaring hole in it which is a critical flaw: lack of extensibility. There is no abstraction layer which would allow users to define their own module loading and definition scheme. This is directly related to the way the module class loader, module, and module system APIs fit together. Note that this is tied directly to the flawed notion of having a language-level construct for modules, which is ONLY done this way because of the murky "requirement" that modules be "part of the language". As is often the case, this "feature" translates directly into a major constraint: it is impossible to achieve the above. This requirement is senseless; I don't think more needs to be said, as the burden of justification lies with the requirement author. By opening up module loading schemes to the user, the user can leverage the module system's (presumably) fast and powerful linking layer for their own plugin systems and containers - and this also "holds the door" open for a modular progression for Java EE, which is something, I might add, that we have already executed on with great success. We have a ModuleLoader API [1] which provides for one-way delegation (think EE deployments delegating to the static boot module system), module unloading (but only for *your* module loader), and run-time module relinking, as well as being a touchstone for statistics and other run-time class loading management information. We provide a default "boot" implementation which loads static module definitions off of the file system. This API works *really well* for our uses and also allows users to create their own plugin schemes while still defining dependencies and filters in all the same ways that they would for static modules - which really stands to revolutionize how people write plugins. Please consider abstracting module loading out into a separate API concept. It is a good, solid approach. [1] http://docs.jboss.org/jbossmodules/1.1.2.GA/api/index.html?org/jboss/modules/ModuleLoader.html -- - DML From debasish.raychawdhuri at gmail.com Thu Jul 19 09:03:40 2012 From: debasish.raychawdhuri at gmail.com (Debasish Ray Chawdhuri) Date: Thu, 19 Jul 2012 21:33:40 +0530 Subject: Extents of extensibility ("is this thing on?") In-Reply-To: <50058D11.3020106@redhat.com> References: <50058D11.3020106@redhat.com> Message-ID: The points are worth noting, but there are obvious reasons I think for making a language level change. For your stand point, you are only interested in enterprise systems, but the jigsaw project aims to solve a different problem, its beyond enterprise computing. So what would be the difference? 1. Compile time binding: We want to get rid of reflection. We also want our compiler to figure out errors. 2. Module resolution: In your JBoss module, you still need to provide the jars in the classpath, some people don't like classpaths (that includes myself) 3. Installable Programs: Like yum(in Redhat Linux) or apt(in debian). You should simply be able to download and install a module just by knowing its name. It should automatically take care of its dependencies. Given where JavaFX is going (may be some day we would end up writing third person shooter games in java), it seems to be a good idea to make the installation process easier for the non-programmer, and it needs to be platform independent. 4. Your module system would still work. 5. There are added performance advantages (but those alone would not make it reasonable to have Jigsaw): like pre-validation of classes during installation, pre-compilation into native code etc. This would of course bring down the time required to restart an instance since currently all the classes are verified and compiled (to native code) again. On Tue, Jul 17, 2012 at 9:34 PM, David M. Lloyd wrote: > Jigsaw still has one glaring hole in it which is a critical flaw: lack of > extensibility. > > There is no abstraction layer which would allow users to define their own > module loading and definition scheme. This is directly related to the way > the module class loader, module, and module system APIs fit together. > > Note that this is tied directly to the flawed notion of having a > language-level construct for modules, which is ONLY done this way because > of the murky "requirement" that modules be "part of the language". As is > often the case, this "feature" translates directly into a major constraint: > it is impossible to achieve the above. > > This requirement is senseless; I don't think more needs to be said, as the > burden of justification lies with the requirement author. By opening up > module loading schemes to the user, the user can leverage the module > system's (presumably) fast and powerful linking layer for their own plugin > systems and containers - and this also "holds the door" open for a modular > progression for Java EE, which is something, I might add, that we have > already executed on with great success. > > We have a ModuleLoader API [1] which provides for one-way delegation > (think EE deployments delegating to the static boot module system), module > unloading (but only for *your* module loader), and run-time module > relinking, as well as being a touchstone for statistics and other run-time > class loading management information. We provide a default "boot" > implementation which loads static module definitions off of the file system. > > This API works *really well* for our uses and also allows users to create > their own plugin schemes while still defining dependencies and filters in > all the same ways that they would for static modules - which really stands > to revolutionize how people write plugins. > > Please consider abstracting module loading out into a separate API > concept. It is a good, solid approach. > > [1] http://docs.jboss.org/**jbossmodules/1.1.2.GA/api/** > index.html?org/jboss/modules/**ModuleLoader.html > -- > - DML > -- Debasish Ray Chawdhuri http://www.geekyarticles.com/ [A collection of advanced articles on java] From david.lloyd at redhat.com Thu Jul 19 09:38:15 2012 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 19 Jul 2012 11:38:15 -0500 Subject: Extents of extensibility ("is this thing on?") In-Reply-To: References: <50058D11.3020106@redhat.com> Message-ID: <500837F7.1010500@redhat.com> Thanks for your reply. Responses inline. On 07/19/2012 11:03 AM, Debasish Ray Chawdhuri wrote: > The points are worth noting, but there are obvious reasons I think for > making a language level change. For your stand point, you are only > interested in enterprise systems, but the jigsaw project aims to solve a > different problem, its beyond enterprise computing. Though I do work at JBoss, this should not be taken to mean that I'm only looking at the enterprise/application server angle. Thus I respectfully disagree with this point. I have done enough research to convince myself at least that I have a strong understanding of not only the enterprise side of this problem, but also the OS side, the user side, and the platform side. However, if there are points that you feel illustrate a lack of consideration for any particular angle of this problem, do point it out and we can discuss. > So what would be the difference? > > 1. Compile time binding: We want to get rid of reflection. We also want our > compiler to figure out errors. This I have no problem with. But, this also has nothing to do (technically speaking) with the actual implementation of putting module data in as a language construct. Yes it needs to be a construct, but making it part of the JLS is cargo-cultism, or something: it's specified because it "feels right", but it doesn't solve any particular problem that cannot be better solved in other ways. > 2. Module resolution: In your JBoss module, you still need to provide the > jars in the classpath, some people don't like classpaths (that includes > myself) I think that peoples' problems with things like classpaths are not because of what they are, but because of how they have historically been used. Modules have content. Classpaths are simply a way of saying "here's the content". You can call it by another name but you can't change what it is, and it's an essential concept to Jigsaw, JBoss Modules, OSGi and every other module system that can possibly exist. Without content, you have no module. > 3. Installable Programs: Like yum(in Redhat Linux) or apt(in debian). You > should simply be able to download and install a module just by knowing its > name. It should automatically take care of its dependencies. Given where > JavaFX is going (may be some day we would end up writing third person > shooter games in java), it seems to be a good idea to make the installation > process easier for the non-programmer, and it needs to be platform > independent. I agree. We need a balance between ease of use and platform integration though. It should be easy for OS distributors to distribute Java and its modules without having to completely sacrifice their own principles. The installation process should be intuitive and idiomatic for both audiences: OS administrators who are most comfortable with their package system, and Java developers who are most comfortable with Java modules and toolchains. > 4. Your module system would still work. Well, thank you. :) > 5. There are added performance advantages (but those alone would not make > it reasonable to have Jigsaw): like pre-validation of classes during > installation, pre-compilation into native code etc. This would of course > bring down the time required to restart an instance since currently all the > classes are verified and compiled (to native code) again. These kinds of optimizations are important, but I don't think any of these things are specifically predicated on coding module definitions as part of the language, nor are any of these things excluded by including an extensibility API. I have been, and will continue to be, critical of those "requirements" which, rather than give a requirement with use cases to back them up, instead give implementation directives without requirements to back them up. Please be very aware: I am not arguing that JBoss Modules somehow replace Jigsaw - that argument would make no sense. But I do think that a lot of the ideas in JBoss Modules are directly applicable to an SE module system, and in those cases I will continue to use JBoss Modules as an example of how I believe these problems could be solved more effectively than Jigsaw currently solves them. > On Tue, Jul 17, 2012 at 9:34 PM, David M. Lloydwrote: > >> Jigsaw still has one glaring hole in it which is a critical flaw: lack of >> extensibility. >> >> There is no abstraction layer which would allow users to define their own >> module loading and definition scheme. This is directly related to the way >> the module class loader, module, and module system APIs fit together. >> >> Note that this is tied directly to the flawed notion of having a >> language-level construct for modules, which is ONLY done this way because >> of the murky "requirement" that modules be "part of the language". As is >> often the case, this "feature" translates directly into a major constraint: >> it is impossible to achieve the above. >> >> This requirement is senseless; I don't think more needs to be said, as the >> burden of justification lies with the requirement author. By opening up >> module loading schemes to the user, the user can leverage the module >> system's (presumably) fast and powerful linking layer for their own plugin >> systems and containers - and this also "holds the door" open for a modular >> progression for Java EE, which is something, I might add, that we have >> already executed on with great success. >> >> We have a ModuleLoader API [1] which provides for one-way delegation >> (think EE deployments delegating to the static boot module system), module >> unloading (but only for *your* module loader), and run-time module >> relinking, as well as being a touchstone for statistics and other run-time >> class loading management information. We provide a default "boot" >> implementation which loads static module definitions off of the file system. >> >> This API works *really well* for our uses and also allows users to create >> their own plugin schemes while still defining dependencies and filters in >> all the same ways that they would for static modules - which really stands >> to revolutionize how people write plugins. >> >> Please consider abstracting module loading out into a separate API >> concept. It is a good, solid approach. >> >> [1] http://docs.jboss.org/**jbossmodules/1.1.2.GA/api/** >> index.html?org/jboss/modules/**ModuleLoader.html >> -- >> - DML >> > > > -- - DML From debasish.raychawdhuri at gmail.com Thu Jul 19 10:10:28 2012 From: debasish.raychawdhuri at gmail.com (Debasish Ray Chawdhuri) Date: Thu, 19 Jul 2012 22:40:28 +0530 Subject: Extents of extensibility ("is this thing on?") In-Reply-To: References: <50058D11.3020106@redhat.com> <500837F7.1010500@redhat.com> Message-ID: Thanks David, I will use the points index-wise, anyone can follow the > earlier chain. > > 1. I agree with you, in fact there has been a discussion in Jigsaw-dev > regarding other formats for module metadata and leaving the compiler alone. > I supported the idea of creating other formats like JSON. People even came > up with some small JSON parsers. But it did not pass the process [or not > taken so seriously I am not sure]. It would have been easier for other > build aware systems like Maven to use this metadata if the metadata is in > plain text form. > > 2. Yes I know the modules need content. The thing is now the JRE itself > would know where the content is kept instead of us having to tell it where > to find each part. This is by virtue of the idea of a default module > library. The content has been organized now. > > 3. I don't understand how it would break the OS's own package maintaining > system. Java will use java's tools, they would use theirs. It would be > similar, but they don't have to be covered in the same commands. > > 5. Yes I know that those are just added benefits not worth a whole > language level change, as I already mentioned in my first reply. > > > On Thu, Jul 19, 2012 at 10:08 PM, David M. Lloyd wrote: > >> Thanks for your reply. Responses inline. >> >> >> On 07/19/2012 11:03 AM, Debasish Ray Chawdhuri wrote: >> >>> The points are worth noting, but there are obvious reasons I think for >>> making a language level change. For your stand point, you are only >>> interested in enterprise systems, but the jigsaw project aims to solve a >>> different problem, its beyond enterprise computing. >>> >> >> Though I do work at JBoss, this should not be taken to mean that I'm only >> looking at the enterprise/application server angle. Thus I respectfully >> disagree with this point. I have done enough research to convince myself >> at least that I have a strong understanding of not only the enterprise side >> of this problem, but also the OS side, the user side, and the platform >> side. However, if there are points that you feel illustrate a lack of >> consideration for any particular angle of this problem, do point it out and >> we can discuss. >> >> >> So what would be the difference? >>> >>> 1. Compile time binding: We want to get rid of reflection. We also want >>> our >>> compiler to figure out errors. >>> >> >> This I have no problem with. But, this also has nothing to do >> (technically speaking) with the actual implementation of putting module >> data in as a language construct. Yes it needs to be a construct, but >> making it part of the JLS is cargo-cultism, or something: it's specified >> because it "feels right", but it doesn't solve any particular problem that >> cannot be better solved in other ways. >> >> >> 2. Module resolution: In your JBoss module, you still need to provide the >>> jars in the classpath, some people don't like classpaths (that includes >>> myself) >>> >> >> I think that peoples' problems with things like classpaths are not >> because of what they are, but because of how they have historically been >> used. Modules have content. Classpaths are simply a way of saying "here's >> the content". You can call it by another name but you can't change what it >> is, and it's an essential concept to Jigsaw, JBoss Modules, OSGi and every >> other module system that can possibly exist. Without content, you have no >> module. >> >> >> 3. Installable Programs: Like yum(in Redhat Linux) or apt(in debian). You >>> should simply be able to download and install a module just by knowing >>> its >>> name. It should automatically take care of its dependencies. Given where >>> JavaFX is going (may be some day we would end up writing third person >>> shooter games in java), it seems to be a good idea to make the >>> installation >>> process easier for the non-programmer, and it needs to be platform >>> independent. >>> >> >> I agree. We need a balance between ease of use and platform integration >> though. It should be easy for OS distributors to distribute Java and its >> modules without having to completely sacrifice their own principles. The >> installation process should be intuitive and idiomatic for both audiences: >> OS administrators who are most comfortable with their package system, and >> Java developers who are most comfortable with Java modules and toolchains. >> >> >> 4. Your module system would still work. >>> >> >> Well, thank you. :) >> >> >> 5. There are added performance advantages (but those alone would not make >>> it reasonable to have Jigsaw): like pre-validation of classes during >>> installation, pre-compilation into native code etc. This would of course >>> bring down the time required to restart an instance since currently all >>> the >>> classes are verified and compiled (to native code) again. >>> >> >> These kinds of optimizations are important, but I don't think any of >> these things are specifically predicated on coding module definitions as >> part of the language, nor are any of these things excluded by including an >> extensibility API. I have been, and will continue to be, critical of those >> "requirements" which, rather than give a requirement with use cases to back >> them up, instead give implementation directives without requirements to >> back them up. >> >> Please be very aware: I am not arguing that JBoss Modules somehow replace >> Jigsaw - that argument would make no sense. But I do think that a lot of >> the ideas in JBoss Modules are directly applicable to an SE module system, >> and in those cases I will continue to use JBoss Modules as an example of >> how I believe these problems could be solved more effectively than Jigsaw >> currently solves them. >> >> On Tue, Jul 17, 2012 at 9:34 PM, David M. Lloyd* >>> *wrote: >>> >>> Jigsaw still has one glaring hole in it which is a critical flaw: lack >>>> of >>>> extensibility. >>>> >>>> There is no abstraction layer which would allow users to define their >>>> own >>>> module loading and definition scheme. This is directly related to the >>>> way >>>> the module class loader, module, and module system APIs fit together. >>>> >>>> Note that this is tied directly to the flawed notion of having a >>>> language-level construct for modules, which is ONLY done this way >>>> because >>>> of the murky "requirement" that modules be "part of the language". As >>>> is >>>> often the case, this "feature" translates directly into a major >>>> constraint: >>>> it is impossible to achieve the above. >>>> >>>> This requirement is senseless; I don't think more needs to be said, as >>>> the >>>> burden of justification lies with the requirement author. By opening up >>>> module loading schemes to the user, the user can leverage the module >>>> system's (presumably) fast and powerful linking layer for their own >>>> plugin >>>> systems and containers - and this also "holds the door" open for a >>>> modular >>>> progression for Java EE, which is something, I might add, that we have >>>> already executed on with great success. >>>> >>>> We have a ModuleLoader API [1] which provides for one-way delegation >>>> (think EE deployments delegating to the static boot module system), >>>> module >>>> unloading (but only for *your* module loader), and run-time module >>>> relinking, as well as being a touchstone for statistics and other >>>> run-time >>>> class loading management information. We provide a default "boot" >>>> implementation which loads static module definitions off of the file >>>> system. >>>> >>>> This API works *really well* for our uses and also allows users to >>>> create >>>> their own plugin schemes while still defining dependencies and filters >>>> in >>>> all the same ways that they would for static modules - which really >>>> stands >>>> to revolutionize how people write plugins. >>>> >>>> Please consider abstracting module loading out into a separate API >>>> concept. It is a good, solid approach. >>>> >>>> [1] http://docs.jboss.org/****jbossmodules/1.1.2.GA/api/** >>>> index.html?org/jboss/modules/****ModuleLoader.html>>> docs.jboss.org/jbossmodules/1.**1.2.GA/api/index.html?org/** >>>> jboss/modules/ModuleLoader.**html >>>> > >>>> -- >>>> - DML >>>> >>>> >>> >>> >>> >> >> -- >> - DML >> > > > > -- > Debasish Ray Chawdhuri > http://www.geekyarticles.com/ > [A collection of advanced articles on java] > > -- Debasish Ray Chawdhuri http://www.geekyarticles.com/ [A collection of advanced articles on java] From debasish.raychawdhuri at gmail.com Thu Jul 19 10:13:28 2012 From: debasish.raychawdhuri at gmail.com (Debasish Ray Chawdhuri) Date: Thu, 19 Jul 2012 22:43:28 +0530 Subject: Extents of extensibility ("is this thing on?") In-Reply-To: References: <50058D11.3020106@redhat.com> <500837F7.1010500@redhat.com> Message-ID: And I hate this mailing list because the mails don't come with a reply-to address. I sent the mail to your address by mistake. On Thu, Jul 19, 2012 at 10:40 PM, Debasish Ray Chawdhuri < debasish.raychawdhuri at gmail.com> wrote: > > > > Thanks David, I will use the points index-wise, anyone can follow the >> earlier chain. >> >> 1. I agree with you, in fact there has been a discussion in Jigsaw-dev >> regarding other formats for module metadata and leaving the compiler alone. >> I supported the idea of creating other formats like JSON. People even came >> up with some small JSON parsers. But it did not pass the process [or not >> taken so seriously I am not sure]. It would have been easier for other >> build aware systems like Maven to use this metadata if the metadata is in >> plain text form. >> >> 2. Yes I know the modules need content. The thing is now the JRE itself >> would know where the content is kept instead of us having to tell it where >> to find each part. This is by virtue of the idea of a default module >> library. The content has been organized now. >> >> 3. I don't understand how it would break the OS's own package maintaining >> system. Java will use java's tools, they would use theirs. It would be >> similar, but they don't have to be covered in the same commands. >> >> 5. Yes I know that those are just added benefits not worth a whole >> language level change, as I already mentioned in my first reply. >> >> >> On Thu, Jul 19, 2012 at 10:08 PM, David M. Lloyd wrote: >> >>> Thanks for your reply. Responses inline. >>> >>> >>> On 07/19/2012 11:03 AM, Debasish Ray Chawdhuri wrote: >>> >>>> The points are worth noting, but there are obvious reasons I think for >>>> making a language level change. For your stand point, you are only >>>> interested in enterprise systems, but the jigsaw project aims to solve a >>>> different problem, its beyond enterprise computing. >>>> >>> >>> Though I do work at JBoss, this should not be taken to mean that I'm >>> only looking at the enterprise/application server angle. Thus I >>> respectfully disagree with this point. I have done enough research to >>> convince myself at least that I have a strong understanding of not only the >>> enterprise side of this problem, but also the OS side, the user side, and >>> the platform side. However, if there are points that you feel illustrate a >>> lack of consideration for any particular angle of this problem, do point it >>> out and we can discuss. >>> >>> >>> So what would be the difference? >>>> >>>> 1. Compile time binding: We want to get rid of reflection. We also want >>>> our >>>> compiler to figure out errors. >>>> >>> >>> This I have no problem with. But, this also has nothing to do >>> (technically speaking) with the actual implementation of putting module >>> data in as a language construct. Yes it needs to be a construct, but >>> making it part of the JLS is cargo-cultism, or something: it's specified >>> because it "feels right", but it doesn't solve any particular problem that >>> cannot be better solved in other ways. >>> >>> >>> 2. Module resolution: In your JBoss module, you still need to provide >>>> the >>>> jars in the classpath, some people don't like classpaths (that includes >>>> myself) >>>> >>> >>> I think that peoples' problems with things like classpaths are not >>> because of what they are, but because of how they have historically been >>> used. Modules have content. Classpaths are simply a way of saying "here's >>> the content". You can call it by another name but you can't change what it >>> is, and it's an essential concept to Jigsaw, JBoss Modules, OSGi and every >>> other module system that can possibly exist. Without content, you have no >>> module. >>> >>> >>> 3. Installable Programs: Like yum(in Redhat Linux) or apt(in debian). >>>> You >>>> should simply be able to download and install a module just by knowing >>>> its >>>> name. It should automatically take care of its dependencies. Given where >>>> JavaFX is going (may be some day we would end up writing third person >>>> shooter games in java), it seems to be a good idea to make the >>>> installation >>>> process easier for the non-programmer, and it needs to be platform >>>> independent. >>>> >>> >>> I agree. We need a balance between ease of use and platform integration >>> though. It should be easy for OS distributors to distribute Java and its >>> modules without having to completely sacrifice their own principles. The >>> installation process should be intuitive and idiomatic for both audiences: >>> OS administrators who are most comfortable with their package system, and >>> Java developers who are most comfortable with Java modules and toolchains. >>> >>> >>> 4. Your module system would still work. >>>> >>> >>> Well, thank you. :) >>> >>> >>> 5. There are added performance advantages (but those alone would not >>>> make >>>> it reasonable to have Jigsaw): like pre-validation of classes during >>>> installation, pre-compilation into native code etc. This would of course >>>> bring down the time required to restart an instance since currently all >>>> the >>>> classes are verified and compiled (to native code) again. >>>> >>> >>> These kinds of optimizations are important, but I don't think any of >>> these things are specifically predicated on coding module definitions as >>> part of the language, nor are any of these things excluded by including an >>> extensibility API. I have been, and will continue to be, critical of those >>> "requirements" which, rather than give a requirement with use cases to back >>> them up, instead give implementation directives without requirements to >>> back them up. >>> >>> Please be very aware: I am not arguing that JBoss Modules somehow >>> replace Jigsaw - that argument would make no sense. But I do think that a >>> lot of the ideas in JBoss Modules are directly applicable to an SE module >>> system, and in those cases I will continue to use JBoss Modules as an >>> example of how I believe these problems could be solved more effectively >>> than Jigsaw currently solves them. >>> >>> On Tue, Jul 17, 2012 at 9:34 PM, David M. Lloyd >>>> **wrote: >>>> >>>> Jigsaw still has one glaring hole in it which is a critical flaw: lack >>>>> of >>>>> extensibility. >>>>> >>>>> There is no abstraction layer which would allow users to define their >>>>> own >>>>> module loading and definition scheme. This is directly related to the >>>>> way >>>>> the module class loader, module, and module system APIs fit together. >>>>> >>>>> Note that this is tied directly to the flawed notion of having a >>>>> language-level construct for modules, which is ONLY done this way >>>>> because >>>>> of the murky "requirement" that modules be "part of the language". As >>>>> is >>>>> often the case, this "feature" translates directly into a major >>>>> constraint: >>>>> it is impossible to achieve the above. >>>>> >>>>> This requirement is senseless; I don't think more needs to be said, as >>>>> the >>>>> burden of justification lies with the requirement author. By opening >>>>> up >>>>> module loading schemes to the user, the user can leverage the module >>>>> system's (presumably) fast and powerful linking layer for their own >>>>> plugin >>>>> systems and containers - and this also "holds the door" open for a >>>>> modular >>>>> progression for Java EE, which is something, I might add, that we have >>>>> already executed on with great success. >>>>> >>>>> We have a ModuleLoader API [1] which provides for one-way delegation >>>>> (think EE deployments delegating to the static boot module system), >>>>> module >>>>> unloading (but only for *your* module loader), and run-time module >>>>> relinking, as well as being a touchstone for statistics and other >>>>> run-time >>>>> class loading management information. We provide a default "boot" >>>>> implementation which loads static module definitions off of the file >>>>> system. >>>>> >>>>> This API works *really well* for our uses and also allows users to >>>>> create >>>>> their own plugin schemes while still defining dependencies and filters >>>>> in >>>>> all the same ways that they would for static modules - which really >>>>> stands >>>>> to revolutionize how people write plugins. >>>>> >>>>> Please consider abstracting module loading out into a separate API >>>>> concept. It is a good, solid approach. >>>>> >>>>> [1] http://docs.jboss.org/****jbossmodules/1.1.2.GA/api/** >>>>> index.html?org/jboss/modules/****ModuleLoader.html>>>> docs.jboss.org/jbossmodules/1.**1.2.GA/api/index.html?org/** >>>>> jboss/modules/ModuleLoader.**html >>>>> > >>>>> -- >>>>> - DML >>>>> >>>>> >>>> >>>> >>>> >>> >>> -- >>> - DML >>> >> >> >> >> -- >> Debasish Ray Chawdhuri >> http://www.geekyarticles.com/ >> [A collection of advanced articles on java] >> >> > > > -- > Debasish Ray Chawdhuri > http://www.geekyarticles.com/ > [A collection of advanced articles on java] > > -- Debasish Ray Chawdhuri http://www.geekyarticles.com/ [A collection of advanced articles on java] From daniel.latremoliere at gmail.com Thu Jul 19 12:57:12 2012 From: daniel.latremoliere at gmail.com (=?ISO-8859-1?Q?Daniel_Latr=E9moli=E8re?=) Date: Thu, 19 Jul 2012 21:57:12 +0200 Subject: Late for the train In-Reply-To: <20120717155739.64B3C1CA6@eggemoggin.niobe.net> References: <20120717155739.64B3C1CA6@eggemoggin.niobe.net> Message-ID: <50086698.7030301@gmail.com> > As some of you are already aware, I've concluded with regret that Project > Jigsaw isn't going to make Java 8 as planned. I've set out my reasoning > in a blog entry [1], and I've asked the Java SE 8 EG to consider dropping > the module system and modularization from the release [2]. I understand the choice of no modularity in JDK 8 and really hope to see a core profile of Java SE 8. Would it be possible to see a reborn, in JavaSE 8, of JSR 294 superpackages for modularity in user applications running on Java SE 8 (not in code internal to JDK8). Having this would be useful for all developers and need mostly a new java.lang.reflect.Modifier for module access rights. Currently package access right is already externally defined, because ClassLoader is responsible of loading and then choosing (modifying, removing or adding) classes of the package. With a module access right, a ModuleLoader (SuperPackageLoader) can define members of module (SuperPackage) and enforce access rights. Only an unique identifier (organisation, name, version) of module need to be defined, by example in some attributes of the manifest of current JAR (without computing any dependencies resolution nor lifecycle management of module, by letting this to external tools if really used by the developer). It would be useful for developers to have a clean border between potentially public API and always private parts of classes of module. This can already improve code quality, by removing access to some public API not to be called [1], by allowing methods on public classes but callable only from others packages of the same module, without being publicly callable. In future, Jigsaw views can refine access to potentially public API (by selecting some views of it), but code with module access right will always be internal to module and used by nobody else. Hoping for some modularity in source code, even without modularity in deployment, Thanks, Daniel Latr?moli?re. [1]: http://wiki.eclipse.org/Naming_Conventions#Internal_Implementation_Packages From mark.reinhold at oracle.com Thu Jul 19 14:27:47 2012 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 19 Jul 2012 14:27:47 -0700 Subject: Project Jigsaw main page updated Message-ID: <20120719212747.CB2A42D82@eggemoggin.niobe.net> FYI, I updated it and rearranged things a bit to make it more useful to newcomers: http://openjdk.java.net/projects/jigsaw/ . - Mark From mark.reinhold at oracle.com Thu Jul 19 15:02:00 2012 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 19 Jul 2012 15:02:00 -0700 Subject: Late for the train In-Reply-To: daniel.latremoliere@gmail.com; Thu, 19 Jul 2012 21:57:12 +0200; <50086698.7030301@gmail.com> Message-ID: <20120719220200.097D22D82@eggemoggin.niobe.net> 2012/7/19 12:57 -0700, daniel.latremoliere at gmail.com: > ... > > Would it be possible to see a reborn, in JavaSE 8, of JSR 294 superpackages for > modularity in user applications running on Java SE 8 (not in code internal to > JDK8). Having this would be useful for all developers and need mostly a new > java.lang.reflect.Modifier for module access rights. Superpackages aren't quite that simple, I'm afraid. (I'm sure Alex could say more ...). Leaving that particular design direction aside, I don't think it's a good idea to deliver a module system for user applications without, in the same major release, also using that system to modularize the JDK itself. The danger is that if we deliver a module system in release N but don't use it to modularize the platform until release N+1 then we run a big risk of getting something fundamentally wrong in the module system. If that happens then we'd have to fix it in release N+1, and fixing fundamental design flaws after the fact almost always leads to a poor end result. Aside from that, there are less than ten months to go in the Java 8 schedule for work on major features. There just isn't enough time to consider such an alternative in a way that would take into account the varied needs of the entire Java community. Sorry. - Mark From mark.reinhold at oracle.com Thu Jul 19 15:12:38 2012 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 19 Jul 2012 15:12:38 -0700 Subject: Context and expectations Message-ID: <20120719221238.D26832D82@eggemoggin.niobe.net> To quote from the Project Jigsaw main page [1]: The goal of this Project is to design and implement a standard module system for the Java SE Platform, and to apply that system to the Platform itself and to the JDK. Right now this effort is in an exploratory phase in which we are investigating and prototyping various ideas in the context of an in-progress requirements document. That document, together with the overall Jigsaw design, will be among the starting points of an eventual Java Platform Module System JSR. That page also contains pointers to additional working and background documents. The most important of those are the requirements [2] and the "big picture" overview [3], which together describe the context of the design and development work taking place on this list. Please make sure you're familiar with that context before you post to this list. If you don't agree with it, that's fine -- ask questions. If you have a better idea, that's great -- please suggest it. Do not expect, however, that asking questions that've already been answered, attacking the motivations or intelligence of those of us who've been working on this for a long time, casting insults, getting angry, or otherwise behaving impolitely will have any effect other than to set your bozo bit. - Mark [1] http://openjdk.java.net/projects/jigsaw/ [2] http://openjdk.java.net/projects/jigsaw/doc/draft-java-module-system-requirements-12 [3] http://cr.openjdk.java.net/~mr/jigsaw/notes/jigsaw-big-picture-01 From david.lloyd at redhat.com Thu Jul 19 16:05:51 2012 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 19 Jul 2012 18:05:51 -0500 Subject: Context and expectations In-Reply-To: <20120719221238.D26832D82@eggemoggin.niobe.net> References: <20120719221238.D26832D82@eggemoggin.niobe.net> Message-ID: <500892CF.1030600@redhat.com> I certainly hope that this isn't directed at me, as my post specifically calls out the correctness and validity of the requirements, including a suggestion for a better idea as an illustration of the weakness of the requirement, and did not include any insults or anger, especially towards individuals; though it's hard to draw any other conclusion given how rarely anyone posts to the jigsaw list from outside of Oracle. As I've often said in ##java, politeness is always defined in the context of one's local culture. As for me, I'd rather have someone directly say "your idea is wrong and here's why" if they feel they have a strong argument. Rejecting discussion that *you* find impolite *because* you find it impolite is a very insular attitude, and doesn't work well in the greater community which is often far less culturally homogeneous than corporations tend to be. Remember Postel's law. It's far more productive to consider the actual content of the message and reply in good faith - only if a message has no valid content is the "bozo" bit in scope. Also, this isn't Congress, it's a public forum - once a question is "answered", it is not "closed" especially if it relates directly to the validity of requirements or the efficacy of an implementation decision. If you don't allow direct criticism of requirements, the definition and understanding of which are the basis of any good software, you've cut off pretty much all meaningful input from the community, which would make this whole exercise a sham; I'm continuing to give the benefit of the doubt on that point, which is why I keep on trying to work with the Jigsaw team. I do think it is clear that many of the requirements in the requirements document are implementation directives, and I believe this is a poor way to design software. Implementation directives are *derived* from requirements, which in turn are guided by real-world use cases. For each such directive, one must ask, what is the *real* requirement that precipitated it? Chances are there is a very good reason that it seemed necessary to give such a directive; but it's the underlying requirement that has to be identified, because chances are also very good that there are other options to meet it which may be superior (or may not be). One of the key strengths, in my opinion, of Open Source Software is recognition of this basic humility and the opportunity it presents for us to create software greater than we ourselves would be capable of. You (and by "you" I mean "all of us in this business") have to be able to question your own perspective and accept outside views, and yes this *does* mean calling into question your own motivations, *constantly*. Is a requirement there because it specifically solves a known problem or use case, or because it's just something you want? Is there a better or more concise way to express this requirement? The answer to these questions can mean the difference between good and bad software. Often times we *want* something because of an intuitive understanding of the problem - but these things still *must* be expanded and codified, because they nearly always contain weaknesses and prejudices (we all have them; stature or experience level is no guarantee against this). So yes, you could say that I question your motivations, because that's a responsibility incumbent upon anyone who evaluates requirements gathered by another. It's nothing personal, it's just good engineering. On 07/19/2012 05:12 PM, mark.reinhold at oracle.com wrote: > To quote from the Project Jigsaw main page [1]: > > The goal of this Project is to design and implement a standard > module system for the Java SE Platform, and to apply that system > to the Platform itself and to the JDK. > > Right now this effort is in an exploratory phase in which we are > investigating and prototyping various ideas in the context of an > in-progress requirements document. That document, together with > the overall Jigsaw design, will be among the starting points of > an eventual Java Platform Module System JSR. > > That page also contains pointers to additional working and background > documents. The most important of those are the requirements [2] and > the "big picture" overview [3], which together describe the context > of the design and development work taking place on this list. > > Please make sure you're familiar with that context before you post to > this list. If you don't agree with it, that's fine -- ask questions. > If you have a better idea, that's great -- please suggest it. > > Do not expect, however, that asking questions that've already been > answered, attacking the motivations or intelligence of those of us > who've been working on this for a long time, casting insults, getting > angry, or otherwise behaving impolitely will have any effect other > than to set your bozo bit. > > - Mark > > > [1] http://openjdk.java.net/projects/jigsaw/ > [2] http://openjdk.java.net/projects/jigsaw/doc/draft-java-module-system-requirements-12 > [3] http://cr.openjdk.java.net/~mr/jigsaw/notes/jigsaw-big-picture-01 -- - DML From debasish.raychawdhuri at gmail.com Thu Jul 19 16:52:52 2012 From: debasish.raychawdhuri at gmail.com (Debasish Ray Chawdhuri) Date: Fri, 20 Jul 2012 05:22:52 +0530 Subject: Context and expectations In-Reply-To: <500892CF.1030600@redhat.com> References: <20120719221238.D26832D82@eggemoggin.niobe.net> <500892CF.1030600@redhat.com> Message-ID: I would agree with David in this matter, and in face I think we did have a constructive discussion. On Fri, Jul 20, 2012 at 4:35 AM, David M. Lloyd wrote: > I certainly hope that this isn't directed at me, as my post specifically > calls out the correctness and validity of the requirements, including a > suggestion for a better idea as an illustration of the weakness of the > requirement, and did not include any insults or anger, especially towards > individuals; though it's hard to draw any other conclusion given how rarely > anyone posts to the jigsaw list from outside of Oracle. > > As I've often said in ##java, politeness is always defined in the context > of one's local culture. As for me, I'd rather have someone directly say > "your idea is wrong and here's why" if they feel they have a strong > argument. Rejecting discussion that *you* find impolite *because* you find > it impolite is a very insular attitude, and doesn't work well in the > greater community which is often far less culturally homogeneous than > corporations tend to be. Remember Postel's law. It's far more productive > to consider the actual content of the message and reply in good faith - > only if a message has no valid content is the "bozo" bit in scope. > > Also, this isn't Congress, it's a public forum - once a question is > "answered", it is not "closed" especially if it relates directly to the > validity of requirements or the efficacy of an implementation decision. If > you don't allow direct criticism of requirements, the definition and > understanding of which are the basis of any good software, you've cut off > pretty much all meaningful input from the community, which would make this > whole exercise a sham; I'm continuing to give the benefit of the doubt on > that point, which is why I keep on trying to work with the Jigsaw team. > > I do think it is clear that many of the requirements in the requirements > document are implementation directives, and I believe this is a poor way to > design software. Implementation directives are *derived* from > requirements, which in turn are guided by real-world use cases. For each > such directive, one must ask, what is the *real* requirement that > precipitated it? Chances are there is a very good reason that it seemed > necessary to give such a directive; but it's the underlying requirement > that has to be identified, because chances are also very good that there > are other options to meet it which may be superior (or may not be). One of > the key strengths, in my opinion, of Open Source Software is recognition of > this basic humility and the opportunity it presents for us to create > software greater than we ourselves would be capable of. > > You (and by "you" I mean "all of us in this business") have to be able to > question your own perspective and accept outside views, and yes this *does* > mean calling into question your own motivations, *constantly*. Is a > requirement there because it specifically solves a known problem or use > case, or because it's just something you want? Is there a better or more > concise way to express this requirement? The answer to these questions can > mean the difference between good and bad software. Often times we *want* > something because of an intuitive understanding of the problem - but these > things still *must* be expanded and codified, because they nearly always > contain weaknesses and prejudices (we all have them; stature or experience > level is no guarantee against this). > > So yes, you could say that I question your motivations, because that's a > responsibility incumbent upon anyone who evaluates requirements gathered by > another. It's nothing personal, it's just good engineering. > > > On 07/19/2012 05:12 PM, mark.reinhold at oracle.com wrote: > >> To quote from the Project Jigsaw main page [1]: >> >> The goal of this Project is to design and implement a standard >> module system for the Java SE Platform, and to apply that system >> to the Platform itself and to the JDK. >> >> Right now this effort is in an exploratory phase in which we are >> investigating and prototyping various ideas in the context of an >> in-progress requirements document. That document, together with >> the overall Jigsaw design, will be among the starting points of >> an eventual Java Platform Module System JSR. >> >> That page also contains pointers to additional working and background >> documents. The most important of those are the requirements [2] and >> the "big picture" overview [3], which together describe the context >> of the design and development work taking place on this list. >> >> Please make sure you're familiar with that context before you post to >> this list. If you don't agree with it, that's fine -- ask questions. >> If you have a better idea, that's great -- please suggest it. >> >> Do not expect, however, that asking questions that've already been >> answered, attacking the motivations or intelligence of those of us >> who've been working on this for a long time, casting insults, getting >> angry, or otherwise behaving impolitely will have any effect other >> than to set your bozo bit. >> >> - Mark >> >> >> [1] http://openjdk.java.net/**projects/jigsaw/ >> [2] http://openjdk.java.net/**projects/jigsaw/doc/draft-** >> java-module-system-**requirements-12 >> [3] http://cr.openjdk.java.net/~**mr/jigsaw/notes/jigsaw-big-**picture-01 >> > > > -- > - DML > -- Debasish Ray Chawdhuri http://www.geekyarticles.com/ [A collection of advanced articles on java] From alex.buckley at oracle.com Thu Jul 19 16:54:39 2012 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 19 Jul 2012 16:54:39 -0700 Subject: Late for the train In-Reply-To: <20120719220200.097D22D82@eggemoggin.niobe.net> References: <20120719220200.097D22D82@eggemoggin.niobe.net> Message-ID: <50089E3F.7020106@oracle.com> On 7/19/2012 3:02 PM, mark.reinhold at oracle.com wrote: > 2012/7/19 12:57 -0700, daniel.latremoliere at gmail.com: >> ... >> >> Would it be possible to see a reborn, in JavaSE 8, of JSR 294 >> superpackages for modularity in user applications running on Java >> SE 8 (not in code internal to JDK8). Having this would be useful >> for all developers and need mostly a new >> java.lang.reflect.Modifier for module access rights. > > Superpackages aren't quite that simple, I'm afraid. (I'm sure Alex > could say more ...). Package-private access control works by a) embedding package identity in class declarations at compile-time (good enough for a compiler), and b) augmenting that package identity at runtime by recording a type's defining class loader (necessary for the JVM to avoid type spoofing). Module-private access control would work by a) embedding module identity in or near class declarations at compile-time, and b) reifying that module identity when class loaders define classes. (Notice I've said nothing about module dependencies or locating types by searching graphs rather than linear classpaths.) (a) is a big topic that goes far beyond storing a module name/version in a JAR manifest. Because the compiler needs to know every type's module membership (module name _and_ version), and assuming you want to compile multiple modules in one compiler invocation, and assuming you might start compilation with only sources (not JARs), it becomes necessary to rework your Java compiler - a lot. The "Modules and javac" presentation on the OpenJDK Project Jigsaw page goes into detail. (b) is actually a fairly small topic. Since class loaders are god-like in their power, they can associate defined classes with module identities as they see fit, and the JVM can enforce same-module-identity checks on accessor and accessee. It's a small matter of API design and JVM rule tweaking. Of course there needs to be a "front-end" to direct class loaders to associate classes with modules; JAR membership is fine. So module-private access control a.k.a. superpackages is somewhat trickier at compile-time than runtime - the opposite of package-private access control. There was a lot to like in Daniel's assessment, but my observation is that if you're going to reify module membership for access control, then you may as well go the whole way and reify dependencies too - managed dependencies are the heart of modularity and access control is merely the enforcement mechanism. Alex From debasish.raychawdhuri at gmail.com Thu Jul 19 16:56:58 2012 From: debasish.raychawdhuri at gmail.com (Debasish Ray Chawdhuri) Date: Fri, 20 Jul 2012 05:26:58 +0530 Subject: Extents of extensibility ("is this thing on?") In-Reply-To: <500837F7.1010500@redhat.com> References: <50058D11.3020106@redhat.com> <500837F7.1010500@redhat.com> Message-ID: Thanks David, I will use the points index-wise, anyone can follow the earlier chain. 1. I agree with you, in fact there has been a discussion in Jigsaw-dev regarding other formats for module metadata and leaving the compiler alone. I supported the idea of creating other formats like JSON. People even came up with some small JSON parsers. But it did not pass the process [or not taken so seriously I am not sure]. It would have been easier for other build aware systems like Maven to use this metadata if the metadata is in plain text form. 2. Yes I know the modules need content. The thing is now the JRE itself would know where the content is kept instead of us having to tell it where to find each part. This is by virtue of the idea of a default module library. The content has been organized now. 3. I don't understand how it would break the OS's own package maintaining system. Java will use java's tools, they would use theirs. It would be similar, but they don't have to be covered in the same commands. 5. Yes I know that those are just added benefits not worth a whole language level change, as I already mentioned in my first reply. On Thu, Jul 19, 2012 at 10:08 PM, David M. Lloyd wrote: > Thanks for your reply. Responses inline. > > > On 07/19/2012 11:03 AM, Debasish Ray Chawdhuri wrote: > >> The points are worth noting, but there are obvious reasons I think for >> making a language level change. For your stand point, you are only >> interested in enterprise systems, but the jigsaw project aims to solve a >> different problem, its beyond enterprise computing. >> > > Though I do work at JBoss, this should not be taken to mean that I'm only > looking at the enterprise/application server angle. Thus I respectfully > disagree with this point. I have done enough research to convince myself > at least that I have a strong understanding of not only the enterprise side > of this problem, but also the OS side, the user side, and the platform > side. However, if there are points that you feel illustrate a lack of > consideration for any particular angle of this problem, do point it out and > we can discuss. > > > So what would be the difference? >> >> 1. Compile time binding: We want to get rid of reflection. We also want >> our >> compiler to figure out errors. >> > > This I have no problem with. But, this also has nothing to do > (technically speaking) with the actual implementation of putting module > data in as a language construct. Yes it needs to be a construct, but > making it part of the JLS is cargo-cultism, or something: it's specified > because it "feels right", but it doesn't solve any particular problem that > cannot be better solved in other ways. > > > 2. Module resolution: In your JBoss module, you still need to provide the >> jars in the classpath, some people don't like classpaths (that includes >> myself) >> > > I think that peoples' problems with things like classpaths are not because > of what they are, but because of how they have historically been used. > Modules have content. Classpaths are simply a way of saying "here's the > content". You can call it by another name but you can't change what it is, > and it's an essential concept to Jigsaw, JBoss Modules, OSGi and every > other module system that can possibly exist. Without content, you have no > module. > > > 3. Installable Programs: Like yum(in Redhat Linux) or apt(in debian). You >> should simply be able to download and install a module just by knowing its >> name. It should automatically take care of its dependencies. Given where >> JavaFX is going (may be some day we would end up writing third person >> shooter games in java), it seems to be a good idea to make the >> installation >> process easier for the non-programmer, and it needs to be platform >> independent. >> > > I agree. We need a balance between ease of use and platform integration > though. It should be easy for OS distributors to distribute Java and its > modules without having to completely sacrifice their own principles. The > installation process should be intuitive and idiomatic for both audiences: > OS administrators who are most comfortable with their package system, and > Java developers who are most comfortable with Java modules and toolchains. > > > 4. Your module system would still work. >> > > Well, thank you. :) > > > 5. There are added performance advantages (but those alone would not make >> it reasonable to have Jigsaw): like pre-validation of classes during >> installation, pre-compilation into native code etc. This would of course >> bring down the time required to restart an instance since currently all >> the >> classes are verified and compiled (to native code) again. >> > > These kinds of optimizations are important, but I don't think any of these > things are specifically predicated on coding module definitions as part of > the language, nor are any of these things excluded by including an > extensibility API. I have been, and will continue to be, critical of those > "requirements" which, rather than give a requirement with use cases to back > them up, instead give implementation directives without requirements to > back them up. > > Please be very aware: I am not arguing that JBoss Modules somehow replace > Jigsaw - that argument would make no sense. But I do think that a lot of > the ideas in JBoss Modules are directly applicable to an SE module system, > and in those cases I will continue to use JBoss Modules as an example of > how I believe these problems could be solved more effectively than Jigsaw > currently solves them. > > On Tue, Jul 17, 2012 at 9:34 PM, David M. Lloyd** >> wrote: >> >> Jigsaw still has one glaring hole in it which is a critical flaw: lack of >>> extensibility. >>> >>> There is no abstraction layer which would allow users to define their own >>> module loading and definition scheme. This is directly related to the >>> way >>> the module class loader, module, and module system APIs fit together. >>> >>> Note that this is tied directly to the flawed notion of having a >>> language-level construct for modules, which is ONLY done this way because >>> of the murky "requirement" that modules be "part of the language". As is >>> often the case, this "feature" translates directly into a major >>> constraint: >>> it is impossible to achieve the above. >>> >>> This requirement is senseless; I don't think more needs to be said, as >>> the >>> burden of justification lies with the requirement author. By opening up >>> module loading schemes to the user, the user can leverage the module >>> system's (presumably) fast and powerful linking layer for their own >>> plugin >>> systems and containers - and this also "holds the door" open for a >>> modular >>> progression for Java EE, which is something, I might add, that we have >>> already executed on with great success. >>> >>> We have a ModuleLoader API [1] which provides for one-way delegation >>> (think EE deployments delegating to the static boot module system), >>> module >>> unloading (but only for *your* module loader), and run-time module >>> relinking, as well as being a touchstone for statistics and other >>> run-time >>> class loading management information. We provide a default "boot" >>> implementation which loads static module definitions off of the file >>> system. >>> >>> This API works *really well* for our uses and also allows users to create >>> their own plugin schemes while still defining dependencies and filters in >>> all the same ways that they would for static modules - which really >>> stands >>> to revolutionize how people write plugins. >>> >>> Please consider abstracting module loading out into a separate API >>> concept. It is a good, solid approach. >>> >>> [1] http://docs.jboss.org/****jbossmodules/1.1.2.GA/api/** >>> index.html?org/jboss/modules/****ModuleLoader.html>> docs.jboss.org/jbossmodules/1.**1.2.GA/api/index.html?org/** >>> jboss/modules/ModuleLoader.**html >>> > >>> -- >>> - DML >>> >>> >> >> >> > > -- > - DML > -- Debasish Ray Chawdhuri http://www.geekyarticles.com/ [A collection of advanced articles on java] From alex.buckley at oracle.com Thu Jul 19 17:06:08 2012 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 19 Jul 2012 17:06:08 -0700 Subject: Late for the train In-Reply-To: <50089E3F.7020106@oracle.com> References: <20120719220200.097D22D82@eggemoggin.niobe.net> <50089E3F.7020106@oracle.com> Message-ID: <5008A0F0.3080605@oracle.com> On 7/19/2012 4:54 PM, Alex Buckley wrote: > Because the compiler needs to know every type's module membership > (module name _and_ version), and assuming you want to compile > multiple modules in one compiler invocation, and assuming you might > start compilation with only sources (not JARs), it becomes necessary > to rework your Java compiler - a lot. I want to add that this is where the "module declarations in Java source code" theme comes from. A module declaration which gives name and version for the purpose of compile-time and runtime access control is _by definition_ a first-class entity in the Java platform. Hence a module is declared via a Java language construct with syntax similar to constructs which declare other entities (classes, interfaces). Alex From eric at tibco.com Thu Jul 19 17:46:36 2012 From: eric at tibco.com (Eric Johnson) Date: Thu, 19 Jul 2012 17:46:36 -0700 Subject: Late for the train In-Reply-To: <5008A0F0.3080605@oracle.com> References: <20120719220200.097D22D82@eggemoggin.niobe.net> <50089E3F.7020106@oracle.com> <5008A0F0.3080605@oracle.com> Message-ID: <5008AA6C.4000809@tibco.com> Since this has been a pet peeve of mine, this elicits a comment from me: On 7/19/12 5:06 PM, Alex Buckley wrote: > On 7/19/2012 4:54 PM, Alex Buckley wrote: >> Because the compiler needs to know every type's module membership >> (module name _and_ version), and assuming you want to compile >> multiple modules in one compiler invocation, and assuming you might >> start compilation with only sources (not JARs), it becomes necessary >> to rework your Java compiler - a lot. > > I want to add that this is where the "module declarations in Java source > code" theme comes from. The theme, though, is a mis-statement of the problem. The problem statement should use the phrase "module declarations **and** Java source code". The choice of "in" is an implementation choice. The obvious requirement is that both sets of information be used together by the compiler, without dictating the input form of the module declaration. > A module declaration which gives name and version for the purpose of > compile-time and runtime access control is _by definition_ a > first-class entity in the Java platform. Sure, but so is MANIFEST.MF, which carries compile-time information (example, Main-Class), as well as signing information, which must be used by the runtime when a security manager is turned on. > Hence a module is declared via a Java language construct with syntax > similar to constructs which declare other entities (classes, interfaces). And *even if* you think that this should result in changes to the recognized keywords in ".java" files, and an input file that uses a special ".java" name to carry said info, there's still no reason that the output has to be a .class file, after the darn thing is compiled. Those are all implementation choices. And from discussions we've had, there are many folks such as myself that think that those implementation choices come at an unnecessary cost. Different implementation choices might be better. -Eric. From debasish.raychawdhuri at gmail.com Thu Jul 19 17:56:32 2012 From: debasish.raychawdhuri at gmail.com (Debasish Ray Chawdhuri) Date: Fri, 20 Jul 2012 06:26:32 +0530 Subject: Late for the train In-Reply-To: <5008AA6C.4000809@tibco.com> References: <20120719220200.097D22D82@eggemoggin.niobe.net> <50089E3F.7020106@oracle.com> <5008A0F0.3080605@oracle.com> <5008AA6C.4000809@tibco.com> Message-ID: I don't think Main-Class is a compile time information. The compiler has nothing to do with the Main-Class (its just another class), only the runtime is interested in Main-Class. Where as the compiler needs to know the module information to resolve the types. On Fri, Jul 20, 2012 at 6:16 AM, Eric Johnson wrote: > Since this has been a pet peeve of mine, this elicits a comment from me: > > > On 7/19/12 5:06 PM, Alex Buckley wrote: > >> On 7/19/2012 4:54 PM, Alex Buckley wrote: >> >>> Because the compiler needs to know every type's module membership >>> (module name _and_ version), and assuming you want to compile >>> multiple modules in one compiler invocation, and assuming you might >>> start compilation with only sources (not JARs), it becomes necessary >>> to rework your Java compiler - a lot. >>> >> >> I want to add that this is where the "module declarations in Java source >> code" theme comes from. >> > > The theme, though, is a mis-statement of the problem. The problem > statement should use the phrase "module declarations **and** Java source > code". The choice of "in" is an implementation choice. The obvious > requirement is that both sets of information be used together by the > compiler, without dictating the input form of the module declaration. > > > A module declaration which gives name and version for the purpose of >> compile-time and runtime access control is _by definition_ a first-class >> entity in the Java platform. >> > > Sure, but so is MANIFEST.MF, which carries compile-time information > (example, Main-Class), as well as signing information, which must be used > by the runtime when a security manager is turned on. > > > Hence a module is declared via a Java language construct with syntax >> similar to constructs which declare other entities (classes, interfaces). >> > > And *even if* you think that this should result in changes to the > recognized keywords in ".java" files, and an input file that uses a special > ".java" name to carry said info, there's still no reason that the output > has to be a .class file, after the darn thing is compiled. > > Those are all implementation choices. And from discussions we've had, > there are many folks such as myself that think that those implementation > choices come at an unnecessary cost. Different implementation choices might > be better. > > -Eric. > > -- Debasish Ray Chawdhuri http://www.geekyarticles.com/ [A collection of advanced articles on java] From david.bosschaert at gmail.com Thu Jul 19 23:50:01 2012 From: david.bosschaert at gmail.com (David Bosschaert) Date: Fri, 20 Jul 2012 07:50:01 +0100 Subject: Late for the train In-Reply-To: <5008AA6C.4000809@tibco.com> References: <20120719220200.097D22D82@eggemoggin.niobe.net> <50089E3F.7020106@oracle.com> <5008A0F0.3080605@oracle.com> <5008AA6C.4000809@tibco.com> Message-ID: On 20 July 2012 01:46, Eric Johnson wrote: > On 7/19/12 5:06 PM, Alex Buckley wrote: >> Hence a module is declared via a Java language construct with syntax >> similar to constructs which declare other entities (classes, interfaces). > > > And *even if* you think that this should result in changes to the recognized > keywords in ".java" files, and an input file that uses a special ".java" > name to carry said info, there's still no reason that the output has to be a > .class file, after the darn thing is compiled. > > Those are all implementation choices. And from discussions we've had, there > are many folks such as myself that think that those implementation choices > come at an unnecessary cost. Different implementation choices might be > better. +1. Totally agree, Eric. David From david.bosschaert at gmail.com Fri Jul 20 00:19:00 2012 From: david.bosschaert at gmail.com (David Bosschaert) Date: Fri, 20 Jul 2012 08:19:00 +0100 Subject: Extents of extensibility ("is this thing on?") In-Reply-To: References: <50058D11.3020106@redhat.com> <500837F7.1010500@redhat.com> Message-ID: On 20 July 2012 00:56, Debasish Ray Chawdhuri wrote: > 1. I agree with you, in fact there has been a discussion in Jigsaw-dev > regarding other formats for module metadata and leaving the compiler alone. > I supported the idea of creating other formats like JSON. People even came > up with some small JSON parsers. But it did not pass the process [or not > taken so seriously I am not sure]. It would have been easier for other > build aware systems like Maven to use this metadata if the metadata is in > plain text form. The JSON parser for Jigsaw is actually implemented in the OpenJDK Project Penrose forest [1]. Not sure what process you are referring to but it has been reviewed at Penrose, merged and the demos have been updated to use it. Granted we didn't have time yet to update all the tools to use the JSON metadata just yet, but it works at runtime [2] similar to module-info.class but has the benefit of increased extensibility, increased readability without needing to extend the Java language. Jigsaw is free to take these relevant commits from Penrose and add this feature to its codebase. David [1] http://openjdk.java.net/projects/penrose/ [2] see here for two tests that show it in action: http://hg.openjdk.java.net/penrose/jigsaw/jdk/file/507fae0a1d80/test/org/openjdk/jigsaw/hello-json.sh and http://hg.openjdk.java.net/penrose/jigsaw/jdk/file/1d2576346081/test/org/openjdk/jigsaw/hello-json-custom.sh From gnormington at vmware.com Fri Jul 20 03:28:43 2012 From: gnormington at vmware.com (Glyn Normington) Date: Fri, 20 Jul 2012 11:28:43 +0100 Subject: Project Jigsaw main page updated In-Reply-To: <20120719212747.CB2A42D82@eggemoggin.niobe.net> References: <20120719212747.CB2A42D82@eggemoggin.niobe.net> Message-ID: <01FD94DA-C881-42FC-9711-DF9DCDB4C4DF@vmware.com> Thanks for that. Please could you mention the Penrose project as it's closely related to Jigsaw and newcomers wouldn't be aware of it. Regards, Glyn On 19 Jul 2012, at 22:27, mark.reinhold at oracle.com wrote: > FYI, I updated it and rearranged things a bit to make it more useful > to newcomers: http://openjdk.java.net/projects/jigsaw/ . > > - Mark From chris.hegarty at oracle.com Fri Jul 20 04:13:41 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 20 Jul 2012 12:13:41 +0100 Subject: RFR (small): Modularizer should scan whole classpath for services Message-ID: <50093D65.30609@oracle.com> There is a small issue in the Modularizer where some META-INF/service/XXX files are not being correctly copied to the on disk "exploded" modules ( these are used to create the jmod/deb packages ) during the build. The issue is that service providers can be in multiple files/jars in the classpath. For example, there are two META-INF/service/com.sun.jdi.connect.Connector files, one in sa-jdi.jar (for the serviceability agent) and one in tools.jar. It is important to preserve these META-INF files in the jmod/installed modules as they are still used to find services in classpath mode (they do not effect module mode). The above example, com.sun.jdi.connect.Connector, is the only instance of this situation in the JDK that I can find, but I think it is a general problem so I have changed the Modularizer to search the whole classpath when looking for services rather exiting early once one is found. The META-INF/service/XXX are files are then concatenated. http://cr.openjdk.java.net/~chegar/jigsaw/sajdi_webrev.00/webrev/ Note: This issue was noticed when running the com/sun/jdi tests and manifests itself as follows: "java.lang.IllegalArgumentException: No connector named: com.sun.jdi.CommandLineLaunch" Thanks, -Chris. From paul.sandoz at oracle.com Fri Jul 20 05:10:19 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 20 Jul 2012 14:10:19 +0200 Subject: RFR (small): Modularizer should scan whole classpath for services In-Reply-To: <50093D65.30609@oracle.com> References: <50093D65.30609@oracle.com> Message-ID: Hi Chris, Looks OK to me. Paul. On Jul 20, 2012, at 1:13 PM, Chris Hegarty wrote: > > There is a small issue in the Modularizer where some META-INF/service/XXX files are not being correctly copied to the on disk "exploded" modules ( these are used to create the jmod/deb packages ) during the build. > > The issue is that service providers can be in multiple files/jars in the classpath. For example, there are two META-INF/service/com.sun.jdi.connect.Connector files, one in sa-jdi.jar (for the serviceability agent) and one in tools.jar. It is important to preserve these META-INF files in the jmod/installed modules as they are still used to find services in classpath mode (they do not effect module mode). > > The above example, com.sun.jdi.connect.Connector, is the only instance of this situation in the JDK that I can find, but I think it is a general problem so I have changed the Modularizer to search the whole classpath when looking for services rather exiting early once one is found. The META-INF/service/XXX are files are then concatenated. > > http://cr.openjdk.java.net/~chegar/jigsaw/sajdi_webrev.00/webrev/ > > Note: > This issue was noticed when running the com/sun/jdi tests and manifests itself as follows: > "java.lang.IllegalArgumentException: No connector named: > com.sun.jdi.CommandLineLaunch" > > Thanks, > -Chris. > > > From Alan.Bateman at oracle.com Fri Jul 20 05:44:23 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 20 Jul 2012 13:44:23 +0100 Subject: RFR (small): Modularizer should scan whole classpath for services In-Reply-To: <50093D65.30609@oracle.com> References: <50093D65.30609@oracle.com> Message-ID: <500952A7.2020204@oracle.com> On 20/07/2012 12:13, Chris Hegarty wrote: > > There is a small issue in the Modularizer where some > META-INF/service/XXX files are not being correctly copied to the on > disk "exploded" modules ( these are used to create the jmod/deb > packages ) during the build. > > The issue is that service providers can be in multiple files/jars in > the classpath. For example, there are two > META-INF/service/com.sun.jdi.connect.Connector files, one in > sa-jdi.jar (for the serviceability agent) and one in tools.jar. It is > important to preserve these META-INF files in the jmod/installed > modules as they are still used to find services in classpath mode > (they do not effect module mode). > > The above example, com.sun.jdi.connect.Connector, is the only instance > of this situation in the JDK that I can find, but I think it is a > general problem so I have changed the Modularizer to search the whole > classpath when looking for services rather exiting early once one is > found. The META-INF/service/XXX are files are then concatenated. > > http://cr.openjdk.java.net/~chegar/jigsaw/sajdi_webrev.00/webrev/ > > Note: > This issue was noticed when running the com/sun/jdi tests and > manifests itself as follows: > "java.lang.IllegalArgumentException: No connector named: > com.sun.jdi.CommandLineLaunch" > It's good to get this problem fixed as the service configuration file from sa-jdi.jar was overriding the file from tools.jar, leading to the problems with JDI that we have been running into it. The changes look okay to me and we probably don't need to be too fussy with the Modularizer anyway as it will go away once we are on the new build. -Alan. From paul.sandoz at oracle.com Fri Jul 20 07:29:53 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 20 Jul 2012 16:29:53 +0200 Subject: Extents of extensibility ("is this thing on?") In-Reply-To: <50058D11.3020106@redhat.com> References: <50058D11.3020106@redhat.com> Message-ID: <4FFEBA86-BA8A-40CE-834E-B14E68E34065@oracle.com> Hi David, Thanks for sending a link to the JavaDoc. If i could make some loose analogies: - org.jboss.modules.ModuleLoader is similar to org.openjdk.jigsaw.Configuration + Catalog - Module is similar to T extends BaseContext; and - ModuleClassLoader is similar to Loader. There are two instantiations of Configuration, Configuration and Configuration. The former is an install-time configuration (and serialized in a library and used for execution of a main class) and the latter is a compile-time configuration. A configuration is the result of resolving and linking, and linking differs depending on whether one is installing or compiling. Catalog abstracts the layout of modules. Can these Jigsaw abstractions be improved? almost certainly since this is currently prototype code. There are at least two areas that may impact the implementations/abstractions: - compiling and running with a path of jmod, modular jars, and/or exploded compiled modules in addition to modules installed into libraries; and - container support, which would enable that one-way delegation you refer to. FWIW the tests for the resolver create a mock Library (an implementation of Catalog) and build ModuleInfo instances using a ModuleInfoBuilder i.e. not from a module-info.java/class, shocking! :-) Paul. On Jul 17, 2012, at 6:04 PM, David M. Lloyd wrote: > Jigsaw still has one glaring hole in it which is a critical flaw: lack of extensibility. > > There is no abstraction layer which would allow users to define their own module loading and definition scheme. This is directly related to the way the module class loader, module, and module system APIs fit together. > > Note that this is tied directly to the flawed notion of having a language-level construct for modules, which is ONLY done this way because of the murky "requirement" that modules be "part of the language". As is often the case, this "feature" translates directly into a major constraint: it is impossible to achieve the above. > > This requirement is senseless; I don't think more needs to be said, as the burden of justification lies with the requirement author. By opening up module loading schemes to the user, the user can leverage the module system's (presumably) fast and powerful linking layer for their own plugin systems and containers - and this also "holds the door" open for a modular progression for Java EE, which is something, I might add, that we have already executed on with great success. > > We have a ModuleLoader API [1] which provides for one-way delegation (think EE deployments delegating to the static boot module system), module unloading (but only for *your* module loader), and run-time module relinking, as well as being a touchstone for statistics and other run-time class loading management information. We provide a default "boot" implementation which loads static module definitions off of the file system. > > This API works *really well* for our uses and also allows users to create their own plugin schemes while still defining dependencies and filters in all the same ways that they would for static modules - which really stands to revolutionize how people write plugins. > > Please consider abstracting module loading out into a separate API concept. It is a good, solid approach. > > [1] http://docs.jboss.org/jbossmodules/1.1.2.GA/api/index.html?org/jboss/modules/ModuleLoader.html > -- > - DML From mark.reinhold at oracle.com Fri Jul 20 09:07:25 2012 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 20 Jul 2012 09:07:25 -0700 Subject: Project Jigsaw main page updated In-Reply-To: gnormington@vmware.com; Fri, 20 Jul 2012 11:28:43 BST; <01FD94DA-C881-42FC-9711-DF9DCDB4C4DF@vmware.com> Message-ID: <20120720160725.2E6571C2A@eggemoggin.niobe.net> 2012/7/20 3:28 -0700, gnormington at vmware.com: > Thanks for that. Please could you mention the Penrose project as it's > closely related to Jigsaw and newcomers wouldn't be aware of it. Good idea -- done. - Mark From david.lloyd at redhat.com Fri Jul 20 09:39:54 2012 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 20 Jul 2012 11:39:54 -0500 Subject: Extents of extensibility ("is this thing on?") In-Reply-To: <4FFEBA86-BA8A-40CE-834E-B14E68E34065@oracle.com> References: <50058D11.3020106@redhat.com> <4FFEBA86-BA8A-40CE-834E-B14E68E34065@oracle.com> Message-ID: <500989DA.9080606@redhat.com> Thanks for replying, responses inline. On 07/20/2012 09:29 AM, Paul Sandoz wrote: > Hi David, > > Thanks for sending a link to the JavaDoc. > > If i could make some loose analogies: > > - org.jboss.modules.ModuleLoader is similar to > org.openjdk.jigsaw.Configuration + Catalog > > - Module is similar to T extends BaseContext; and > > - ModuleClassLoader is similar to Loader. Thanks, it's helpful to see where you see these equivalencies. > There are two instantiations of Configuration, Configuration > and Configuration. The former is an install-time > configuration (and serialized in a library and used for execution of > a main class) and the latter is a compile-time configuration. A > configuration is the result of resolving and linking, and linking > differs depending on whether one is installing or compiling. > > Catalog abstracts the layout of modules. > > Can these Jigsaw abstractions be improved? almost certainly since > this is currently prototype code. I do disagree with the way the abstractions are structured and expressed. Many (most?) of these abstractions belong in the module API, not in the Jigsaw implementation classes. The module API has to be constrained enough to define a specific behavior; as it stands it is very general. But I don't want to tangent off into specific implementation details: I have many ideas and opinions about how things *should* be structured but that's a different discussion. > There are at least two areas that may impact the > implementations/abstractions: > > - compiling and running with a path of jmod, modular jars, and/or > exploded compiled modules in addition to modules installed into > libraries; and > > - container support, which would enable that one-way delegation you > refer to. This matches my understanding, though it's not just a path when it comes to compilation: allowing a pluggable loader repository even in this case is important to (for example) OS distributions who don't necessarily *want* to coordinate a binary database of installed Java modules with their installation tools, or special build or CI tools which want to set up mock environments for integration testing. > FWIW the tests for the resolver create a mock Library (an > implementation of Catalog) and build ModuleInfo instances using a > ModuleInfoBuilder i.e. not from a module-info.java/class, shocking! > :-) I am curious: how does this behave in terms of java.lang.reflect.Module? Opting to make this a language construct means you need to "feed in" annotations among other things and I don't see where that could happen. This is one place where the fit is wrong IMO: you don't gain anything by having a module be a new reflective construct that you don't already have by drawing a 1:1 correspondence between a Module and a ClassLoader, which you *would* be able to do if not for the erroneous requirement that the individual core JDK pieces be separate modules with the same class loader. That requirement is better written something like: "The core JDK must be distributable in separate components that correspond to X, Y, Z (justification: distro size, ME growth, etc.). The core JDK classes must all present the same class loader (or, a null class loader depending on how that analysis pans out) (justification: compatibility with system class loader based schemes, etc.)". -- - DML From sean.mullan at oracle.com Fri Jul 20 09:58:48 2012 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 20 Jul 2012 12:58:48 -0400 Subject: Review Request: loading JCE providers using ServiceLoader Message-ID: <50098E48.7010903@oracle.com> Please review my code changes to enable JCE providers to be registered and loaded as services using the ServiceLoader API: http://cr.openjdk.java.net/~mullan/jigsaw/webrevs/jce-service/webrev.00/ There is one outstanding issue that needs to be resolved, but I think we can try to resolve this later: You cannot load more than one PKCS11 provider (ex: with different configurations), as currently supported and documented in the PKCS11 guide [1]. Thanks, Sean [1] http://docs.oracle.com/javase/7/docs/technotes/guides/security/p11guide.html From mark.reinhold at oracle.com Fri Jul 20 11:18:04 2012 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 20 Jul 2012 11:18:04 -0700 Subject: Late for the train In-Reply-To: eric@tibco.com; Thu, 19 Jul 2012 17:46:36 PDT; <5008AA6C.4000809@tibco.com> Message-ID: <20120720181804.A010F1C9D@eggemoggin.niobe.net> 2012/7/19 17:46 -0700, eric at tibco.com: > On 7/19/12 5:06 PM, Alex Buckley wrote: >> On 7/19/2012 4:54 PM, Alex Buckley wrote: >>> Because the compiler needs to know every type's module membership >>> (module name _and_ version), and assuming you want to compile >>> multiple modules in one compiler invocation, and assuming you might >>> start compilation with only sources (not JARs), it becomes necessary >>> to rework your Java compiler - a lot. >> >> I want to add that this is where the "module declarations in Java source >> code" theme comes from. > > The theme, though, is a mis-statement of the problem. The problem statement > should use the phrase "module declarations **and** Java source code". The > choice of "in" is an implementation choice. The obvious requirement is that > both sets of information be used together by the compiler, without dictating > the input form of the module declaration. I don't think Alex meant his theme to be taken as a statement of the problem, but rather as a rationale for the particular solution we're exploring here right now. I agree that a purely-stated requirement would not dictate the form of module declarations, leaving a design free to use MANIFEST.MF, use a JSON or XML syntax, extend the Java language, or do something else entirely. For what it's worth, I also agree that the present requirements document is flawed in that it's a mixture of pure requirements and partial design choices. That's due to its heritage as a record of discussions amongst many parties. I expect that revising that document into a more abstract form will be one of the first activities of the Expert Group of the forthcoming Java Platform Module System JSR. > ... > >> Hence a module is declared via a Java language construct with syntax similar >> to constructs which declare other entities (classes, interfaces). > > And *even if* you think that this should result in changes to the recognized > keywords in ".java" files, and an input file that uses a special ".java" name > to carry said info, there's still no reason that the output has to be a .class > file, after the darn thing is compiled. No, there's no reason that it absolutely has to be a class file. There are, however, some good reasons for that choice. One is that existing tools are apt to get very confused if there's suddenly a special kind of Java source file that doesn't produce a corresponding class file when compiled. Sure, that can be handled by updating the tools, but it seems easier just to maintain the invariant that a file whose name ends in ".java" always produces a file whose name ends in ".class" when you compile it. > Those are all implementation choices. And from discussions we've had, there are > many folks such as myself that think that those implementation choices come at > an unnecessary cost. Different implementation choices might be better. You're absolutely right, and the EG might ultimately decide to make a different set of choices. If and when that happens then this Project will change course as appropriate. In the meantime, however, we're focused on exploring a design in which modularity is a language construct, as described in the draft design overview [1]. This approach is markedly different from that of existing Java modularity solutions, and I think it's important to have a good understanding of it ahead of the EG discussion. - Mark [1] http://cr.openjdk.java.net/~mr/jigsaw/notes/jigsaw-big-picture-01 From daniel.latremoliere at gmail.com Fri Jul 20 13:59:58 2012 From: daniel.latremoliere at gmail.com (=?ISO-8859-1?Q?Daniel_Latr=E9moli=E8re?=) Date: Fri, 20 Jul 2012 22:59:58 +0200 Subject: Late for the train In-Reply-To: <20120719220200.097D22D82@eggemoggin.niobe.net> References: <20120719220200.097D22D82@eggemoggin.niobe.net> Message-ID: <5009C6CE.7070704@gmail.com> Le 20/07/2012 00:02, mark.reinhold at oracle.com a ?crit : > Leaving that particular design direction aside, I don't think it's a good > idea to deliver a module system for user applications without, in the > same major release, also using that system to modularize the JDK itself. > > The danger is that if we deliver a module system in release N but don't > use it to modularize the platform until release N+1 then we run a big > risk of getting something fundamentally wrong in the module system. > If that happens then we'd have to fix it in release N+1, and fixing > fundamental design flaws after the fact almost always leads to a poor > end result. Each new version of Java is (near) compatible with previous version, but without update of source code, it will have a technical debt. By example, try-with-resources is very useful and even if Java6 source code can be compiled and executed completely unchanged on Java7, the source code need to be updated to not be in technical debt comparatively to Java7 new source code. For me, an imperfect but reasonable design seems better, even if slightly breaking source code compatibility in N+1 version for correcting some small parts. If Java 1.0 does not existed because memory model has waited Java 1.5 to be rigorously defined, Java would probably not be the most common programming language. I see the gap, between MIDP and JavaSE, full of Android devices for the same problems of abuse of compatibility (particularly lack of a Java mobile/core profile). For me, a fundamental design flaw is less probable if something is designed from external requirements than from internal implementation (a module-private access control is this sort of black-box design, clearly incomplete for implementing a full module system but exactly defined by itself and without expectable need of future semantic change). If existing, it will make a good path for adoption of some modules features in some Java programs. When completed with all others Jigsaw features, it would have all the features of module system but with probably a faster global adoption (big features/projects need time to really be adopted, probably more than the two parts of the same project after cutting it). Some big Oracle projects (e.g. JavaFX) have suggested (and developed tools for) embedding of a specific version of Java runtime in application for controlling compatibility problems, then compatibility is not probably a magical solution even at Oracle. For me, including technical debt, each Java version is correctly compatible with previous version, but not strictly compatible (excepted when Java will be dead or no more evolving usefully) and I see this as good feature because it tell that Java is not dead and add useful features. Including technical debt, source compatibility is never perfect, except for a dead language, then it is (at least for me) acceptable to have possible changes between versions of Java for correcting design errors. Each version already need source changes for reducing technical debt. > Aside from that, there are less than ten months to go in the Java 8 > schedule for work on major features. There just isn't enough time to > consider such an alternative in a way that would take into account the > varied needs of the entire Java community. Sorry. I can perfectly understand this and it is sad because it would be useful to have a small significant part of modularity, for improving source code and starting adoption of modularity in JavaSE, even without the big rest of modularity. Thanks, Daniel. From daniel.latremoliere at gmail.com Fri Jul 20 14:00:47 2012 From: daniel.latremoliere at gmail.com (=?UTF-8?B?RGFuaWVsIExhdHLDqW1vbGnDqHJl?=) Date: Fri, 20 Jul 2012 23:00:47 +0200 Subject: Late for the train In-Reply-To: <50089E3F.7020106@oracle.com> References: <20120719220200.097D22D82@eggemoggin.niobe.net> <50089E3F.7020106@oracle.com> Message-ID: <5009C6FF.6000703@gmail.com> Le 20/07/2012 01:54, Alex Buckley a ?crit : > Package-private access control works by a) embedding package identity > in class declarations at compile-time (good enough for a compiler), > and b) augmenting that package identity at runtime by recording a > type's defining class loader (necessary for the JVM to avoid type > spoofing). > > Module-private access control would work by a) embedding module > identity in or near class declarations at compile-time, and b) > reifying that module identity when class loaders define classes. > (Notice I've said nothing about module dependencies or locating types > by searching graphs rather than linear classpaths.) > > (a) is a big topic that goes far beyond storing a module name/version > in a JAR manifest. Because the compiler needs to know every type's > module membership (module name _and_ version), and assuming you want > to compile multiple modules in one compiler invocation, and assuming > you might start compilation with only sources (not JARs), it becomes > necessary to rework your Java compiler - a lot. The "Modules and > javac" presentation on the OpenJDK Project Jigsaw page goes into detail. > > (b) is actually a fairly small topic. Since class loaders are god-like > in their power, they can associate defined classes with module > identities as they see fit, and the JVM can enforce > same-module-identity checks on accessor and accessee. It's a small > matter of API design and JVM rule tweaking. Of course there needs to > be a "front-end" to direct class loaders to associate classes with > modules; JAR membership is fine. > > So module-private access control a.k.a. superpackages is somewhat > trickier at compile-time than runtime - the opposite of > package-private access control. There was a lot to like in Daniel's > assessment, but my observation is that if you're going to reify module > membership for access control, then you may as well go the whole way > and reify dependencies too - managed dependencies are the heart of > modularity and access control is merely the enforcement mechanism. > > Alex I was only simply hoping for a simple solution for simple developers needing to make exactly one javac invocation per module and particularly avoiding cyclic dependencies between modules as a good practice (more difficult to evolve because needing co-evolution of cyclic modules and simpler after merging in only one module). Co-compilation of module would not be necessary if modules were compilable one by one (no cyclic dependencies). Allowing extensions (like not standardized javac switches or annotations in a module-info.java containing only mandatory name-version) for beginning evaluation of more complex features, like co-compilation of modules, automatic dependencies management, global module configuration of bytecode tools like Findbugs, would be sufficient for preparing future features and test their future specification (replacing, only at this future release, the useful annotations from a org.openjdk.* package by a real language construct). It was only a hope for a simple solution to begin improvements to source code quality (by one small step, not a big jump slow to be adopted). With a small feature added in release, there is much more real-world use-cases, creation of good practices (which seems to me to be more useful for prioritisation of good features than a big project not directly usable on a released stable JVM with vendor-specific annotations). For me, having module access control, even without a full module system seems to be more useful than having public access control with a comment not-to-be-used (and even only this feature is useful by itself, for me). Thanks, Daniel. From daniel.latremoliere at gmail.com Fri Jul 20 14:01:04 2012 From: daniel.latremoliere at gmail.com (=?ISO-8859-1?Q?Daniel_Latr=E9moli=E8re?=) Date: Fri, 20 Jul 2012 23:01:04 +0200 Subject: Context and expectations In-Reply-To: <20120719221238.D26832D82@eggemoggin.niobe.net> References: <20120719221238.D26832D82@eggemoggin.niobe.net> Message-ID: <5009C710.4090006@gmail.com> Le 20/07/2012 00:12, mark.reinhold at oracle.com a ?crit : > To quote from the Project Jigsaw main page [1]: > > The goal of this Project is to design and implement a standard > module system for the Java SE Platform, and to apply that system > to the Platform itself and to the JDK. > [...] > Do not expect, however, that asking questions that've already been > answered, attacking the motivations or intelligence of those of us > who've been working on this for a long time, casting insults, getting > angry, or otherwise behaving impolitely will have any effect other > than to set your bozo bit. > > - Mark Thanks for all the responses. I am sorry if my mail about already-defunct JSR 294 was received as off-topic Jigsaw and over-simplified or insulting to Jigsaw workers. After many years of Java programming, I always like to have very simple code (KISS principle), because maintaining code become easier with highly constrained and state-of-art code (like by verifiers, formatting and rules of programming), without bad effects on performance, etc (if design was good and regularly optimised). Mark, I don't know if I was the target of your comment, but given your response at my mail was the preceding message in the mailing list, I will respond, particularly given I clearly dislike people launching rumours or some other bad sociability behaviour (like in this case, attacking someone without beginning by explicitly telling him or targeting him in the mail containing the attack). I don't think, I had this sort of attitude in my previous mail (I was honestly only interested in fast adoption of the subset of Java modularity which seemed, to me, to have the less risk of bad design). But when I see this sort of diktat without technical justification (like not the right of "attacking the motivations" given the written goal of Jigsaw), the freedom of my brain jump on your suggest of becoming angry. - As a developer, improving my code quality (readability, maintenance, performance, security) by modularity is a valid requirement for me. - For JDK, improving code quality and performance by something like modularity, storage of meta-information for JIT, etc. is a perfectly understandable requirement for me. - A goal of modularizing JDK for modularizing JDK (like approximately said in Jigsaw [1]) is not an understandable requirement for me (cyclic dependency in my brain). I have better understanding of the JavaSE 8 target, of creating a subset of JavaSE (core profile), like Android has already made. I wish you a good work in Jigsaw, hoping to use it sometimes. This is not a criticism against Jigsaw workers, only some lack of trust in big projects too late, with too complex features because too heavy requirements. I prefer simple projects with small core and possibility of extensions; standardizing some core extensions only after real-world testing. For me, bigger is the project at start, slower is the adoption (sometimes, it is even: never is the adoption). Just for clarity, I really like Jigsaw (particularly views) and not really OSGi (most of my current modularization needs are static and not dynamic, then more Jigsaw-like). I always like to be clear, then sorry for my mail if it was inappropriate. I don't know if I am the target of your (Mark) comment, but I am not interested in a mailing list with this sort of rumours (unnamed targets). Then I will unsubscribe of this mailing-list because it is probably better and I dislike writing mail like this (I am not interested in knowing if my bozo bit is set at true or false value). Daniel Latr?moli?re. [1]: The goal of this Project is to design and implement a standard module system for the Java SE Platform, and to apply that system to the Platform itself and to the JDK. From alex.buckley at oracle.com Fri Jul 20 14:27:50 2012 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 20 Jul 2012 14:27:50 -0700 Subject: Late for the train In-Reply-To: <20120720181804.A010F1C9D@eggemoggin.niobe.net> References: <20120720181804.A010F1C9D@eggemoggin.niobe.net> Message-ID: <5009CD56.6000305@oracle.com> On 7/20/2012 11:18 AM, mark.reinhold at oracle.com wrote: > 2012/7/19 17:46 -0700, eric at tibco.com: >> On 7/19/12 5:06 PM, Alex Buckley wrote: >>> On 7/19/2012 4:54 PM, Alex Buckley wrote: >>>> Because the compiler needs to know every type's module membership >>>> (module name _and_ version), and assuming you want to compile >>>> multiple modules in one compiler invocation, and assuming you might >>>> start compilation with only sources (not JARs), it becomes necessary >>>> to rework your Java compiler - a lot. >>> >>> I want to add that this is where the "module declarations in Java source >>> code" theme comes from. >> >> The theme, though, is a mis-statement of the problem. The problem statement >> should use the phrase "module declarations **and** Java source code". The >> choice of "in" is an implementation choice. The obvious requirement is that >> both sets of information be used together by the compiler, without dictating >> the input form of the module declaration. > > I don't think Alex meant his theme to be taken as a statement of the > problem, but rather as a rationale for the particular solution we're > exploring here right now. > > I agree that a purely-stated requirement would not dictate the form of > module declarations, leaving a design free to use MANIFEST.MF, use a JSON > or XML syntax, extend the Java language, or do something else entirely. ... extend the Java _syntax_ ... To be absolutely clear: module membership must be part of the Java language because module membership is to govern access control to module-private types at compile-time and runtime. A separate topic is the syntactic mechanism(s) by which a module is declared, its general membership expressed, and its module-private membership expressed. (Still saying nothing about dependencies to keep things simple.) Alex From mark.reinhold at oracle.com Fri Jul 20 14:38:02 2012 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 20 Jul 2012 14:38:02 -0700 Subject: Context and expectations In-Reply-To: daniel.latremoliere@gmail.com; Fri, 20 Jul 2012 23:01:04 +0200; <5009C710.4090006@gmail.com> Message-ID: <20120720213802.C63EA1C9D@eggemoggin.niobe.net> 2012/7/20 14:01 -0700, daniel.latremoliere at gmail.com: > ... > > I don't know if I was the target of your comment, but given your response at my > mail was the preceding message in the mailing list, I will respond, ... You were in no way the intended target of my comment. I'm sorry that you interpreted it that way. In anticipation of an influx of newcomers to this list as a result of the proposal I made earlier this week, I thought it'd be useful to relay some basic information and set expectations. I don't think that what I said is particularly unusual or controversial for open-source projects. - Mark From daniel.latremoliere at gmail.com Fri Jul 20 15:43:42 2012 From: daniel.latremoliere at gmail.com (=?ISO-8859-1?Q?Daniel_Latr=E9moli=E8re?=) Date: Sat, 21 Jul 2012 00:43:42 +0200 Subject: Context and expectations In-Reply-To: <20120720213802.C63EA1C9D@eggemoggin.niobe.net> References: <20120720213802.C63EA1C9D@eggemoggin.niobe.net> Message-ID: <5009DF1E.2040204@gmail.com> >> ... >> >> I don't know if I was the target of your comment, but given your response at my >> mail was the preceding message in the mailing list, I will respond, ... > You were in no way the intended target of my comment. I'm sorry that > you interpreted it that way. I am sorry for overreacting (I like history and History learn that rumours or unnamed messages has killed many people). Your response on another topic and your lack of response after David and Debasish responses to your mail, triggered mine. In this mailing list and given long and conflictual history of Java modularity, coming back with an old topic like JSR 294 seemed, to me, mostly off-topic for Jigsaw but good fitting for "asking questions that've already been answered" (but I had no other living mailing list for my question). Honestly, I continue to dislike Jigsaw remembered goal: "The goal of this Project is to design and implement a standard module system for the Java SE Platform, and to apply that system to the Platform itself and to the JDK.", because "module" say all or nothing depending of reader, but is not a clear set of potentially independent features (internal improvement of OpenJDK code, abstraction for hiding some parts of implementation, deployment package compatible with RPM/DEB, object with an externally managed lifecycle, storage repository for code and JIT metadata, etc.) coming each with his improvements to developer/sysadmin life (the only real goals of OpenJDK for me) and needing or not new public API/language changes. I would prefer something like "The goal of this Project is to design and implement a module system for the Java SE Platform, to improve abstraction in Java code and increase performance of VM and simplicity of deployment." For me, Java developers has no direct interest to know if Jigsaw is used by OpenJDK itself or not (it is an OpenJDK-implementation detail and not a goal, even if it is a big detail). By example, OpenJDK can use specific extensions to Jigsaw (not public module API) for his own modularisation without any knowledge from Java developer. > In anticipation of an influx of newcomers to this list as a result of > the proposal I made earlier this week, I thought it'd be useful to relay > some basic information and set expectations. I don't think that what I > said is particularly unusual or controversial for open-source projects. I have most frequently seen these rules remembering in the subscription mail for new users or when discussions on mailing list becomes problematic but not when all is normal (then triggering my mail). Sorry. I am sorry for my overreaction, Daniel. From forax at univ-mlv.fr Fri Jul 20 16:16:24 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sat, 21 Jul 2012 01:16:24 +0200 Subject: Context and expectations In-Reply-To: <5009DF1E.2040204@gmail.com> References: <20120720213802.C63EA1C9D@eggemoggin.niobe.net> <5009DF1E.2040204@gmail.com> Message-ID: <5009E6C8.4020606@univ-mlv.fr> On 07/21/2012 12:43 AM, Daniel Latr?moli?re wrote: Hi Daniel, ... > > Honestly, I continue to dislike Jigsaw remembered goal: "The goal of > this Project is to design and implement a standard module system for > the Java SE Platform, and to apply that system to the Platform itself > and to the JDK.", because "module" say all or nothing depending of > reader, but is not a clear set of potentially independent features > (internal improvement of OpenJDK code, abstraction for hiding some > parts of implementation, deployment package compatible with RPM/DEB, > object with an externally managed lifecycle, storage repository for > code and JIT metadata, etc.) coming each with his improvements to > developer/sysadmin life (the only real goals of OpenJDK for me) and > needing or not new public API/language changes. > I would prefer something like "The goal of this Project is to design > and implement a module system for the Java SE Platform, to improve > abstraction in Java code and increase performance of VM and simplicity > of deployment." > For me, Java developers has no direct interest to know if Jigsaw is > used by OpenJDK itself or not (it is an OpenJDK-implementation detail > and not a goal, even if it is a big detail). By example, OpenJDK can > use specific extensions to Jigsaw (not public module API) for his own > modularisation without any knowledge from Java developer. There are several reasons to not do that. You create an artificial barrier between the OpenJDK code and the application code so you raise the entry ticket for anyone that want to provide a patch or fix a bug in the JDK, you force application developers to use their own solution to solve exactly the same problem, so each implementations (the OpenJDK one included) will be less tested. Netbeans has modules, JBoss, Eclipse have modules too. How many kind of modules did you want before thinking that having a good standard module API in the JDK is a good idea. It's better to provide a feature that everybody can use, that is well tested and for the sake of shaping the API, eating our own dog food is in my opinion a very good idea. > Daniel. cheers, R?mi From daniel.latremoliere at gmail.com Sat Jul 21 02:10:28 2012 From: daniel.latremoliere at gmail.com (=?ISO-8859-1?Q?Daniel_Latr=E9moli=E8re?=) Date: Sat, 21 Jul 2012 11:10:28 +0200 Subject: Context and expectations In-Reply-To: <5009E6C8.4020606@univ-mlv.fr> References: <20120720213802.C63EA1C9D@eggemoggin.niobe.net> <5009DF1E.2040204@gmail.com> <5009E6C8.4020606@univ-mlv.fr> Message-ID: <500A7204.1040007@gmail.com> >> >> Honestly, I continue to dislike Jigsaw remembered goal: "The goal of >> this Project is to design and implement a standard module system for >> the Java SE Platform, and to apply that system to the Platform itself >> and to the JDK.", because "module" say all or nothing depending of >> reader, but is not a clear set of potentially independent features >> (internal improvement of OpenJDK code, abstraction for hiding some >> parts of implementation, deployment package compatible with RPM/DEB, >> object with an externally managed lifecycle, storage repository for >> code and JIT metadata, etc.) coming each with his improvements to >> developer/sysadmin life (the only real goals of OpenJDK for me) and >> needing or not new public API/language changes. >> I would prefer something like "The goal of this Project is to design >> and implement a module system for the Java SE Platform, to improve >> abstraction in Java code and increase performance of VM and >> simplicity of deployment." >> For me, Java developers has no direct interest to know if Jigsaw is >> used by OpenJDK itself or not (it is an OpenJDK-implementation detail >> and not a goal, even if it is a big detail). By example, OpenJDK can >> use specific extensions to Jigsaw (not public module API) for his own >> modularisation without any knowledge from Java developer. > > There are several reasons to not do that. You create an artificial > barrier between the OpenJDK code and the application code so you raise > the entry ticket for anyone that want to provide a patch or fix a bug > in the JDK, you force application developers to use their own solution > to solve exactly the same problem, so each implementations (the > OpenJDK one included) will be less tested. > > Netbeans has modules, JBoss, Eclipse have modules too. How many kind > of modules did you want before thinking that having a good standard > module API in the JDK is a good idea. It's better to provide a feature > that everybody can use, that is well tested and for the sake of > shaping the API, eating our own dog food is in my opinion a very good > idea. Hi R?mi, When I have a specific use-case for an Ant script not cleanly solved by currents tasks or a macrodef, I can create my own task (sometimes useful). Am I creating an artificial barrier between developer and code: yes, but it is simpler and more readable than a very complicated Ant process or completely remove Ant replaced by a custom build tool. Even in this case, I use common Ant tasks for 99% of my script and the extension use is clearly defined (by namespace used) and follow in this case the XML syntax. I will not try to give to Ant a complicated task for inclusion in their product, because no other user will use it (specific need). I think this example is the same problem than your suggest, and many projects create own Ant tasks without destroying Ant (even increasing interest in Ant). Yes, Modules are already existing in multiple variants in various products: it's a fact and not a bad fact because it say there is a need for module system. For me, creating a standard is mostly extracting the clearly defined commons parts and improve them to allow better design and let extensions manage uncommon/under-defined parts. When some extensions are commonly used and better defined, they can be improved and included in the standard or at least a profile of standard. I have seen many standards created by concatenating, in one standard, all the existing proposals from each vendor to clearly like short, incomplete and extensible standards improving as good practices help to choose a technical road against business roads (proposed by each vendor). By example when standardizing a module access control in Java (with a ModuleLoader for enforcing the access control and an extensible module-info.java containing only mandatory name-version and annotations for all others extensions), you are attracting all current module systems by giving a new feature (access control in Java language) and you create a first common part to all existing modules systems. Each module system will currently have own annotations, but semantic of annotations can begin converging to allow future inclusion of some common annotations as standard constructs in module-info.java. Replacing in one file per module (module-info.java) the OpenJDK specific annotation of Java 8u_n with a syntax like @View(name="my-view", classes={MyClass.class, ...} ) by a future standard construct in Java 9 like "view my-view {class MyClass; ...}" is a very small work for avoiding technical debt of a major release. Compare this to even Java7 update of existing source code with features like try-with-resources, exception multicatch, switch on strings, impacting all source code or NIO2, JSR292 having very big impact on some code. If you are not trying to replace, in one step, all solutions already existing in the world, but to improve common parts by changing core Java for better integration, each solution can give focus on solving better his problem and another step (Java 9) in standardization will be able to move in core Java some others features, better tested in real-world (module deployment by example). If you are trying to completely replace in one step, then a user of another current module system will not use, even partially, a Java module system when he will see only one simple lacking feature in Jigsaw but potentially used from the other module system (possibly even if it is a simple change of name of the feature). I always like eating our own dog food. But in a module system, for me, "eating his own dog food" is modularizing the module system (standard core always included with some common use-cases; allow extensions for specific use-cases). Then I can read "eating his own dog food"-principle as exactly the opposite of your reading. Simply speaking, what is a "good standard module API" before real-world experiment? Daniel. From Alan.Bateman at oracle.com Sun Jul 22 07:09:25 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 22 Jul 2012 15:09:25 +0100 Subject: Review Request: loading JCE providers using ServiceLoader In-Reply-To: <50098E48.7010903@oracle.com> References: <50098E48.7010903@oracle.com> Message-ID: <500C0995.9040209@oracle.com> On 20/07/2012 17:58, Sean Mullan wrote: > Please review my code changes to enable JCE providers to be registered and > loaded as services using the ServiceLoader API: > > http://cr.openjdk.java.net/~mullan/jigsaw/webrevs/jce-service/webrev.00/ > > There is one outstanding issue that needs to be resolved, but I think we can try > to resolve this later: > > You cannot load more than one PKCS11 provider (ex: with different > configurations), as currently supported and documented in the PKCS11 guide [1]. > > Thanks, > Sean > > [1] http://docs.oracle.com/javase/7/docs/technotes/guides/security/p11guide.html It's good to see this. One thing that I can't quite grok is the how this fits with the list of providers in the java.security file. Would I be correct to say that if you have a new provider then you install the provider module and in addition, and add to the java.security file as above? (the reason being to give it preference order). If so then it's a minor that we need to re-visit the issue of configured preferred order. If we did that then maybe it could be used in class path mode, assuming we could work out a migration from the existing java.security list. Is there is another way to configure provider arguments? Also do you know if is common to configure multiple PKCS11 providers? Just looking at the PKCS11 guide then it includes an example that does this: Provider p = new sun.security.pkcs11.SunPKCS11(configName); I assume we don't want anyone becomes dependent on this class name as it will be not be exported when running with modules. Minor comment in passing but you might have a merge error in cli/Packager.java or maybe you just need the stack trace when there is a CommandException? Also I think the "tries" field in ProviderConfig needs to be checked as it looks to have synchronization issues. I'll try to do a more detailed few in the next few days. -Alan. From Alan.Bateman at oracle.com Sun Jul 22 07:30:12 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 22 Jul 2012 15:30:12 +0100 Subject: Review Request: loading JCE providers using ServiceLoader In-Reply-To: <500C0995.9040209@oracle.com> References: <50098E48.7010903@oracle.com> <500C0995.9040209@oracle.com> Message-ID: <500C0E74.7030200@oracle.com> On 22/07/2012 15:09, Alan Bateman wrote: > If so then it's a minor that we need to re-visit the issue of > configured preferred order. s/minor/reminder/ From sean.mullan at oracle.com Sun Jul 22 13:20:03 2012 From: sean.mullan at oracle.com (Sean Mullan) Date: Sun, 22 Jul 2012 16:20:03 -0400 Subject: Review Request: loading JCE providers using ServiceLoader In-Reply-To: <500C0995.9040209@oracle.com> References: <50098E48.7010903@oracle.com> <500C0995.9040209@oracle.com> Message-ID: <500C6073.1080000@oracle.com> On 7/22/12 10:09 AM, Alan Bateman wrote: > On 20/07/2012 17:58, Sean Mullan wrote: >> Please review my code changes to enable JCE providers to be registered and >> loaded as services using the ServiceLoader API: >> >> http://cr.openjdk.java.net/~mullan/jigsaw/webrevs/jce-service/webrev.00/ >> >> There is one outstanding issue that needs to be resolved, but I think we can try >> to resolve this later: >> >> You cannot load more than one PKCS11 provider (ex: with different >> configurations), as currently supported and documented in the PKCS11 guide [1]. >> >> Thanks, >> Sean >> >> [1] http://docs.oracle.com/javase/7/docs/technotes/guides/security/p11guide.html > It's good to see this. > > One thing that I can't quite grok is the how this fits with the list of > providers in the java.security file. Would I be correct to say that if > you have a new provider then you install the provider module and in > addition, and add to the java.security file as above? (the reason being > to give it preference order). Yes that's the most common case. You can, however, instantiate the provider directly which doesn't require any configuration to the java.security file. > If so then it's a minor that we need to > re-visit the issue of configured preferred order. If we did that then > maybe it could be used in class path mode, assuming we could work out a > migration from the existing java.security list. Actually, the preference order in the java.security file is preserved in either classpath or module mode, since this order is enforced in the provider code (sun.security.jca.ProviderList). It uses the ServiceLoader to find the Provider, but ignores the order. > Is there is another way to configure provider arguments? Not that I know of. > Also do you > know if is common to configure multiple PKCS11 providers? I don't think so, but that's mostly a guess. > Just looking > at the PKCS11 guide then it includes an example that does this: > > Provider p = new sun.security.pkcs11.SunPKCS11(configName); > > I assume we don't want anyone becomes dependent on this class name as it > will be not be exported when running with modules. Good catch. > > Minor comment in passing but you might have a merge error in > cli/Packager.java or maybe you just need the stack trace when there is a > CommandException? Not a merge error. cli/Librarian.java already has this so my change here is just consistent, and it helps when debugging. > Also I think the "tries" field in ProviderConfig needs > to be checked as it looks to have synchronization issues. I'll try to do > a more detailed few in the next few days. I'll take a closer look at that, though that's existing code, I did not do anything to change that. --Sean From Alan.Bateman at oracle.com Sun Jul 22 14:55:36 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 22 Jul 2012 22:55:36 +0100 Subject: Review Request: loading JCE providers using ServiceLoader In-Reply-To: <500C6073.1080000@oracle.com> References: <50098E48.7010903@oracle.com> <500C0995.9040209@oracle.com> <500C6073.1080000@oracle.com> Message-ID: <500C76D8.2040707@oracle.com> On 22/07/2012 21:20, Sean Mullan wrote:On 22/07/2012 21:20, Sean Mullan wrote: > : > Yes that's the most common case. You can, however, instantiate the provider > directly which doesn't require any configuration to the java.security file. Although not in module mode because sun.security.pkcs11.SunPKCS11 and the other types are not exported. In any case, I think the approach is a great start. It also brings up the issue as to whether there should be a way to configure the order of service providers as that is something that comes up all the time. For now I think it's okay to continue with listing them in java.security, it's just that it may have to be re-visited in the future. BTW: One thing I noticed but didn't mention in the original mail is that in the jce.sh test you have a "requires service java.security.Provider" but that isn't needed because it's the base module that is the actual consumer. > : >> Also I think the "tries" field in ProviderConfig needs >> to be checked as it looks to have synchronization issues. I'll try to do >> a more detailed few in the next few days. > I'll take a closer look at that, though that's existing code, I did not do > anything to change that. > I only noticed it because there are changes in this area, might be worth submitting a bug so that someone remembers to look at it. -Alan From mark.reinhold at oracle.com Mon Jul 23 08:26:40 2012 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 23 Jul 2012 08:26:40 -0700 Subject: Context and expectations In-Reply-To: david.lloyd@redhat.com; Thu, 19 Jul 2012 18:05:51 CDT; <500892CF.1030600@redhat.com> Message-ID: <20120723152640.740A5856@eggemoggin.niobe.net> 2012/7/19 16:05 -0700, david.lloyd at redhat.com: > ... > > As I've often said in ##java, politeness is always defined in the > context of one's local culture. It's clear that you have a lot of expertise to bring to this effort, and that's great. Statements that go beyond the bounds of ordinary civil technical discourse, however, are not welcome here or on any other OpenJDK mailing list. That's the local culture in this particular community. I make no claim to know all the answers. I'm happy to have my views and opinions questioned because I usually learn something in the process, and like you I prefer direct arguments to beating about the bush. I do not, however, want to see impolite or insulting language on this list. It drains people's energy, and it discourages participation. As to requirements, as I mentioned on another thread recently I agree that the current document is a mix of requirements and design choices, and it needs a rework. That's the purview of the module-system JSR EG, which will start its work in due course. At the same time, I'm not a big believer in the pure waterfall-style, requirements-driven approach to software engineering. Sometimes, especially in large problem domains where there are many possible solutions, it's worth exploring and prototyping one or more specific new design directions before finishing a proper requirements document. That's what we've been doing here, and we've learned an awful lot in the process. Yes, our approach is based on our particular experiences and intuitions, and no, we don't expect that everyone will agree with it. The EG might ultimately choose an entirely different direction, but whatever happens I think the end result will be better for having been informed by this work. - Mark From mark.reinhold at oracle.com Mon Jul 23 09:39:11 2012 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 23 Jul 2012 09:39:11 -0700 Subject: Review Request: loading JCE providers using ServiceLoader In-Reply-To: sean.mullan@oracle.com; Sun, 22 Jul 2012 16:20:03 EDT; <500C6073.1080000@oracle.com> Message-ID: <20120723163911.D4100856@eggemoggin.niobe.net> 2012/7/22 13:20 -0700, sean.mullan at oracle.com: > On 7/22/12 10:09 AM, Alan Bateman wrote: >> If so then it's a minor that we need to >> re-visit the issue of configured preferred order. If we did that then >> maybe it could be used in class path mode, assuming we could work out a >> migration from the existing java.security list. > > Actually, the preference order in the java.security file is preserved in either > classpath or module mode, since this order is enforced in the provider code > (sun.security.jca.ProviderList). It uses the ServiceLoader to find the Provider, > but ignores the order. So what happens if a provider is available as a service but isn't mentioned in the java.security file? Is it ignored? - Mark From david.lloyd at redhat.com Mon Jul 23 08:43:41 2012 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 23 Jul 2012 10:43:41 -0500 Subject: Context and expectations In-Reply-To: <20120723152640.740A5856@eggemoggin.niobe.net> References: <20120723152640.740A5856@eggemoggin.niobe.net> Message-ID: <500D712D.5000802@redhat.com> On 07/23/2012 10:26 AM, mark.reinhold at oracle.com wrote: > As to requirements, as I mentioned on another thread recently I agree > that the current document is a mix of requirements and design choices, > and it needs a rework. That's the purview of the module-system JSR EG, > which will start its work in due course. I understand now (I think) the aims of your document and efforts, thanks to your recent postings, and that does help me to make sense of the choices and perspective of the project, so thanks for that clarification. > At the same time, I'm not a big believer in the pure waterfall-style, > requirements-driven approach to software engineering. Sometimes, > especially in large problem domains where there are many possible > solutions, it's worth exploring and prototyping one or more specific > new design directions before finishing a proper requirements document. Yeah, I tend to agree believe it or not, though I tend to frame the idea in terms of "understanding the problem". A better understanding of the problem yields better requirements which in turn yield better software. I agree that prototypes can be a very effective tool to allow a better understanding of the problem. > That's what we've been doing here, and we've learned an awful lot in the > process. Yes, our approach is based on our particular experiences and > intuitions, and no, we don't expect that everyone will agree with it. > The EG might ultimately choose an entirely different direction, but > whatever happens I think the end result will be better for having been > informed by this work. I hope so, and I hope that the work I've done in the past and intend to do in the future will also contribute positively to this effort. -- - DML From chris.hegarty at oracle.com Mon Jul 23 09:46:53 2012 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Mon, 23 Jul 2012 16:46:53 +0000 Subject: hg: jigsaw/jigsaw/jdk: Modularizer should scan whole classpath for services Message-ID: <20120723164716.7A4E2471A7@hg.openjdk.java.net> Changeset: 9eaf38868e2d Author: chegar Date: 2012-07-23 17:45 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/9eaf38868e2d Modularizer should scan whole classpath for services Reviewed-by: psandoz, alanb ! make/tools/classanalyzer/src/com/sun/classanalyzer/Modularizer.java ! make/tools/classanalyzer/src/com/sun/classanalyzer/ResourceFile.java ! src/share/classes/com/sun/tools/jdi/SunCommandLineLauncher.java From sean.mullan at oracle.com Tue Jul 24 10:29:20 2012 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 24 Jul 2012 10:29:20 -0700 Subject: Review Request: loading JCE providers using ServiceLoader In-Reply-To: <20120723163911.D4100856@eggemoggin.niobe.net> References: <20120723163911.D4100856@eggemoggin.niobe.net> Message-ID: <500EDB70.3030204@oracle.com> On 7/23/12 9:39 AM, mark.reinhold at oracle.com wrote: > 2012/7/22 13:20 -0700, sean.mullan at oracle.com: >> On 7/22/12 10:09 AM, Alan Bateman wrote: >>> If so then it's a minor that we need to >>> re-visit the issue of configured preferred order. If we did that then >>> maybe it could be used in class path mode, assuming we could work out a >>> migration from the existing java.security list. >> >> Actually, the preference order in the java.security file is preserved in either >> classpath or module mode, since this order is enforced in the provider code >> (sun.security.jca.ProviderList). It uses the ServiceLoader to find the Provider, >> but ignores the order. > > So what happens if a provider is available as a service but isn't > mentioned in the java.security file? Is it ignored? Yes -- if the application is using the 1-argument getInstance method or the 2-argument getInstance method that takes the Provider as a String, ex: MessageDigest.getInstance("SHA-256"); MessageDigest.getInstance("SHA-256", "Sun"); These methods call the Security.getProviders() method to find an appropriate provider from the list of registered providers. Additional Provideras can be registered by calling the Security.addProvider method. But nothing in that API explicitly mentions creating providers from information in the java.security file, so AFAICT, that part is an implementation detail. It's plausible we should automatically add all the Providers available as services to the list of registered providers. However, the one problematic provider with respect to services is the SunPKCS11 provider. This requires a configuration file as input, and that can only be specified by configuring the java.security file, or by instantiating the provider directly with an additional config file parameter: Provider p = new sun.security.pkcs11.SunPKCS11(configName); --Sean From Alan.Bateman at oracle.com Tue Jul 24 20:29:26 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 25 Jul 2012 04:29:26 +0100 Subject: Review Request: loading JCE providers using ServiceLoader In-Reply-To: <500EDB70.3030204@oracle.com> References: <20120723163911.D4100856@eggemoggin.niobe.net> <500EDB70.3030204@oracle.com> Message-ID: <500F6816.9060308@oracle.com> On 24/07/2012 18:29, Sean Mullan wrote: > > It's plausible we should automatically add all the Providers available > as services to the list of registered providers. I think this would make sense because they are otherwise not accessible if they aren't listed in the java.security file (and the approach to instantiate them directly will not work in module because sun.security.pkcs11 and the other sun.* packages are not exported). -Alan. From alan.bateman at oracle.com Wed Jul 25 21:19:10 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 26 Jul 2012 04:19:10 +0000 Subject: hg: jigsaw/jigsaw: 10 new changesets Message-ID: <20120726041911.246F34720D@hg.openjdk.java.net> Changeset: f6a685069274 Author: katleman Date: 2012-07-05 18:43 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/rev/f6a685069274 Added tag jdk8-b46 for changeset 27fa766a2298 ! .hgtags Changeset: c8d320b48626 Author: erikj Date: 2012-07-03 16:11 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/rev/c8d320b48626 7181504: Update of latest build-infra Makefiles Reviewed-by: ohair ! common/autoconf/autogen.sh ! common/autoconf/build-aux/config.guess ! common/autoconf/builddeps.conf.example ! common/autoconf/builddeps.m4 ! common/autoconf/configure ! common/autoconf/configure.ac - common/autoconf/cores.m4 ! common/autoconf/help.m4 ! common/autoconf/platform.m4 ! common/autoconf/spec.gmk.in ! common/bin/compareimage.sh ! common/bin/diffexec.sh ! common/bin/diffjarzip.sh ! common/bin/difflib.sh ! common/makefiles/IdlCompilation.gmk ! common/makefiles/JavaCompilation.gmk ! common/makefiles/MakeBase.gmk ! common/makefiles/Makefile ! common/makefiles/NativeCompilation.gmk - common/makefiles/RMICompile.gmk Changeset: 3156dff953b1 Author: erikj Date: 2012-07-05 18:27 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/rev/3156dff953b1 7182051: Update of latest build-infra Makefiles (missing files) Reviewed-by: ohair + common/autoconf/basics.m4 + common/autoconf/boot-jdk.m4 + common/autoconf/build-aux/autoconf-config.guess + common/autoconf/build-performance.m4 + common/autoconf/generated-configure.sh + common/autoconf/jdk-options.m4 + common/autoconf/libraries.m4 + common/autoconf/source-dirs.m4 + common/autoconf/spec.sh.in + common/autoconf/toolchain.m4 + common/bin/compare-objects.sh ! common/makefiles/IdlCompilation.gmk + common/makefiles/MakeHelpers.gmk ! common/makefiles/NativeCompilation.gmk + common/makefiles/RMICompilation.gmk Changeset: 1dcb4b7b9373 Author: katleman Date: 2012-07-11 16:00 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/rev/1dcb4b7b9373 Merge - common/autoconf/cores.m4 - common/makefiles/RMICompile.gmk Changeset: aaae5471808d Author: katleman Date: 2012-07-12 16:47 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/rev/aaae5471808d Added tag jdk8-b47 for changeset 1dcb4b7b9373 ! .hgtags Changeset: ba77d95ed219 Author: ohair Date: 2012-07-16 11:43 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/rev/ba77d95ed219 7184406: Adjust get_source/hgforest script to allow for trailing // characters Reviewed-by: tbell ! make/scripts/hgforest.sh Changeset: 3f6c72d1c2a6 Author: katleman Date: 2012-07-18 14:18 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/rev/3f6c72d1c2a6 Merge Changeset: 5bc94b775f77 Author: alanb Date: 2012-07-22 19:06 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/rev/5bc94b775f77 Merge ! .hgtags - common/autoconf/cores.m4 - common/makefiles/RMICompile.gmk ! make/scripts/hgforest.sh Changeset: 969c75896558 Author: cl Date: 2012-07-23 12:37 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/rev/969c75896558 Added tag jdk8-b48 for changeset 3f6c72d1c2a6 ! .hgtags Changeset: 6a228c7b18a9 Author: alanb Date: 2012-07-24 16:12 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/rev/6a228c7b18a9 Merge ! .hgtags From alan.bateman at oracle.com Wed Jul 25 21:19:27 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 26 Jul 2012 04:19:27 +0000 Subject: hg: jigsaw/jigsaw/corba: 8 new changesets Message-ID: <20120726041934.CC2C04720E@hg.openjdk.java.net> Changeset: cb31b67326bc Author: katleman Date: 2012-07-05 18:44 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/corba/rev/cb31b67326bc Added tag jdk8-b46 for changeset 30141e598d72 ! .hgtags Changeset: 47adb42076f1 Author: coffeys Date: 2012-06-27 21:09 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/corba/rev/47adb42076f1 7162902: Umbrella port of a number of corba bug fixes from JDK 6 to jdk7u/8 Reviewed-by: lancea ! src/share/classes/com/sun/corba/se/impl/encoding/CachedCodeBase.java ! src/share/classes/com/sun/corba/se/impl/interceptors/PIHandlerImpl.java ! src/share/classes/com/sun/corba/se/impl/interceptors/PINoOpHandlerImpl.java ! src/share/classes/com/sun/corba/se/impl/monitoring/MonitoringManagerFactoryImpl.java ! src/share/classes/com/sun/corba/se/impl/monitoring/MonitoringManagerImpl.java ! src/share/classes/com/sun/corba/se/impl/orb/ORBImpl.java ! src/share/classes/com/sun/corba/se/impl/orbutil/threadpool/ThreadPoolImpl.java ! src/share/classes/com/sun/corba/se/impl/orbutil/threadpool/ThreadPoolManagerImpl.java ! src/share/classes/com/sun/corba/se/impl/orbutil/threadpool/WorkQueueImpl.java ! src/share/classes/com/sun/corba/se/impl/protocol/CorbaMessageMediatorImpl.java ! src/share/classes/com/sun/corba/se/impl/transport/SelectorImpl.java ! src/share/classes/com/sun/corba/se/spi/logging/data/ORBUtil.mc ! src/share/classes/com/sun/corba/se/spi/monitoring/MonitoringManager.java ! src/share/classes/com/sun/corba/se/spi/monitoring/MonitoringManagerFactory.java ! src/share/classes/com/sun/corba/se/spi/orb/ORB.java ! src/share/classes/com/sun/corba/se/spi/orbutil/threadpool/ThreadPool.java ! src/share/classes/com/sun/corba/se/spi/orbutil/threadpool/ThreadPoolManager.java ! src/share/classes/com/sun/corba/se/spi/protocol/PIHandler.java ! src/share/classes/com/sun/corba/se/spi/protocol/RequestDispatcherRegistry.java Changeset: 666efea2df67 Author: lana Date: 2012-07-03 18:23 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/corba/rev/666efea2df67 Merge Changeset: 21e46ea21c6a Author: lana Date: 2012-07-10 11:40 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/corba/rev/21e46ea21c6a Merge Changeset: 7e2b179a5b4d Author: katleman Date: 2012-07-12 16:47 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/corba/rev/7e2b179a5b4d Added tag jdk8-b47 for changeset 21e46ea21c6a ! .hgtags Changeset: ef601ab98ac3 Author: alanb Date: 2012-07-22 19:07 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/corba/rev/ef601ab98ac3 Merge ! .hgtags Changeset: fe44e58a6bdb Author: cl Date: 2012-07-23 12:38 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/corba/rev/fe44e58a6bdb Added tag jdk8-b48 for changeset 7e2b179a5b4d ! .hgtags Changeset: e5a6e9b33b1c Author: alanb Date: 2012-07-24 16:17 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/corba/rev/e5a6e9b33b1c Merge ! .hgtags From alan.bateman at oracle.com Wed Jul 25 21:22:20 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 26 Jul 2012 04:22:20 +0000 Subject: hg: jigsaw/jigsaw/hotspot: 21 new changesets Message-ID: <20120726042314.4F8DD4720F@hg.openjdk.java.net> Changeset: 0c7bb1f4f9c8 Author: katleman Date: 2012-07-05 18:44 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/0c7bb1f4f9c8 Added tag jdk8-b46 for changeset cf37a594c38d ! .hgtags Changeset: fa0c28fabbb1 Author: katleman Date: 2012-07-12 16:48 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/fa0c28fabbb1 Added tag jdk8-b47 for changeset 0c7bb1f4f9c8 ! .hgtags Changeset: bcffa4c5eef6 Author: amurillo Date: 2012-06-29 17:12 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/bcffa4c5eef6 7180882: new hotspot build - hs24-b16 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 3759236eea14 Author: kamg Date: 2012-07-02 10:54 -0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/3759236eea14 7167142: Consider a warning when finding a .hotspotrc or .hotspot_compiler file that isn't used Summary: Send warnings to output stream Reviewed-by: dholmes, fparain ! src/share/vm/compiler/compilerOracle.cpp ! src/share/vm/runtime/arguments.cpp Changeset: d2a62e0f25eb Author: zgu Date: 2012-06-28 17:03 -0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/d2a62e0f25eb 6995781: Native Memory Tracking (Phase 1) 7151532: DCmd for hotspot native memory tracking Summary: Implementation of native memory tracking phase 1, which tracks VM native memory usage, and related DCmd Reviewed-by: acorn, coleenp, fparain ! agent/src/share/classes/sun/jvm/hotspot/utilities/BasicHashtable.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/BasicHashtableEntry.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/Hashtable.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/HashtableBucket.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/HashtableEntry.java ! make/bsd/makefiles/jvmg.make ! make/linux/makefiles/jvmg.make ! make/solaris/makefiles/jvmg.make ! make/windows/makefiles/debug.make ! src/os/bsd/vm/os_bsd.cpp ! src/os/bsd/vm/os_bsd.hpp ! src/os/bsd/vm/os_bsd.inline.hpp ! src/os/bsd/vm/perfMemory_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp ! src/os/linux/vm/os_linux.inline.hpp ! src/os/linux/vm/perfMemory_linux.cpp ! src/os/posix/vm/os_posix.cpp ! src/os/solaris/dtrace/hs_private.d ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/os_solaris.hpp ! src/os/solaris/vm/os_solaris.inline.hpp ! src/os/solaris/vm/perfMemory_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/os_windows.hpp ! src/os/windows/vm/perfMemory_windows.cpp ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/c1/c1_CFGPrinter.cpp ! src/share/vm/c1/c1_Compiler.cpp ! src/share/vm/c1/c1_LinearScan.cpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/classLoader.hpp ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/dictionary.hpp ! src/share/vm/classfile/javaAssertions.cpp ! src/share/vm/classfile/javaAssertions.hpp ! src/share/vm/classfile/loaderConstraints.cpp ! src/share/vm/classfile/loaderConstraints.hpp ! src/share/vm/classfile/placeholders.cpp ! src/share/vm/classfile/placeholders.hpp ! src/share/vm/classfile/resolutionErrors.cpp ! src/share/vm/classfile/resolutionErrors.hpp ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/classfile/symbolTable.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/code/codeBlob.cpp ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/code/stubs.hpp ! src/share/vm/compiler/abstractCompiler.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/compiler/compileLog.cpp ! src/share/vm/compiler/compilerOracle.cpp ! src/share/vm/compiler/oopMap.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/g1/collectionSetChooser.hpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/dirtyCardQueue.hpp ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.cpp ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1MMUTracker.hpp ! src/share/vm/gc_implementation/g1/g1MonitoringSupport.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.hpp ! src/share/vm/gc_implementation/g1/ptrQueue.cpp ! src/share/vm/gc_implementation/g1/satbQueue.cpp ! src/share/vm/gc_implementation/g1/sparsePRT.cpp ! src/share/vm/gc_implementation/g1/sparsePRT.hpp ! src/share/vm/gc_implementation/g1/survRateGroup.cpp ! src/share/vm/gc_implementation/g1/survRateGroup.hpp ! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp ! src/share/vm/gc_implementation/parNew/parGCAllocBuffer.hpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/gc_implementation/parNew/parOopClosures.hpp ! src/share/vm/gc_implementation/parallelScavenge/adjoiningGenerations.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/objectStartArray.cpp ! src/share/vm/gc_implementation/parallelScavenge/objectStartArray.hpp ! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/psGenerationCounters.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweepDecorator.hpp ! src/share/vm/gc_implementation/parallelScavenge/psOldGen.hpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionLAB.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.hpp ! src/share/vm/gc_implementation/parallelScavenge/psVirtualspace.hpp ! src/share/vm/gc_implementation/parallelScavenge/psYoungGen.hpp ! src/share/vm/gc_implementation/shared/adaptiveSizePolicy.hpp ! src/share/vm/gc_implementation/shared/cSpaceCounters.cpp ! src/share/vm/gc_implementation/shared/cSpaceCounters.hpp ! src/share/vm/gc_implementation/shared/collectorCounters.cpp ! src/share/vm/gc_implementation/shared/collectorCounters.hpp ! src/share/vm/gc_implementation/shared/gSpaceCounters.cpp ! src/share/vm/gc_implementation/shared/gSpaceCounters.hpp ! src/share/vm/gc_implementation/shared/gcPolicyCounters.hpp ! src/share/vm/gc_implementation/shared/gcStats.hpp ! src/share/vm/gc_implementation/shared/gcUtil.hpp ! src/share/vm/gc_implementation/shared/generationCounters.cpp ! src/share/vm/gc_implementation/shared/generationCounters.hpp ! src/share/vm/gc_implementation/shared/hSpaceCounters.cpp ! src/share/vm/gc_implementation/shared/hSpaceCounters.hpp ! src/share/vm/gc_implementation/shared/immutableSpace.hpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.hpp ! src/share/vm/gc_implementation/shared/spaceCounters.cpp ! src/share/vm/gc_implementation/shared/spaceCounters.hpp ! src/share/vm/gc_implementation/shared/spaceDecorator.hpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/oopMapCache.cpp ! src/share/vm/interpreter/oopMapCache.hpp ! src/share/vm/libadt/set.cpp ! src/share/vm/libadt/vectset.cpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/allocation.inline.hpp ! src/share/vm/memory/barrierSet.hpp ! src/share/vm/memory/blockOffsetTable.cpp ! src/share/vm/memory/blockOffsetTable.hpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/collectorPolicy.hpp ! src/share/vm/memory/defNewGeneration.hpp ! src/share/vm/memory/filemap.hpp ! src/share/vm/memory/freeBlockDictionary.hpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/genOopClosures.hpp ! src/share/vm/memory/genRemSet.hpp ! src/share/vm/memory/generation.hpp ! src/share/vm/memory/generationSpec.hpp ! src/share/vm/memory/heap.cpp ! src/share/vm/memory/heap.hpp ! src/share/vm/memory/heapInspection.cpp ! src/share/vm/memory/heapInspection.hpp ! src/share/vm/memory/memRegion.hpp ! src/share/vm/memory/permGen.hpp ! src/share/vm/memory/referencePolicy.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp ! src/share/vm/memory/resourceArea.hpp ! src/share/vm/memory/restore.cpp ! src/share/vm/memory/space.hpp ! src/share/vm/memory/tenuredGeneration.cpp ! src/share/vm/memory/threadLocalAllocBuffer.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/constantPoolOop.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/oops/symbol.cpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/runtime.hpp ! src/share/vm/opto/type.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jniCheck.cpp ! src/share/vm/prims/jvmtiClassFileReconstituter.hpp ! src/share/vm/prims/jvmtiCodeBlobEvents.cpp ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiEnvBase.cpp ! src/share/vm/prims/jvmtiEnvBase.hpp ! src/share/vm/prims/jvmtiEnvThreadState.cpp ! src/share/vm/prims/jvmtiEnvThreadState.hpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/prims/jvmtiExtensions.cpp ! src/share/vm/prims/jvmtiGetLoadedClasses.cpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiImpl.hpp ! src/share/vm/prims/jvmtiRawMonitor.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/prims/jvmtiTagMap.hpp ! src/share/vm/prims/jvmtiThreadState.hpp ! src/share/vm/prims/jvmtiUtil.cpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/biasedLocking.cpp ! src/share/vm/runtime/compilationPolicy.hpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/deoptimization.hpp ! src/share/vm/runtime/dtraceJSDT.hpp ! src/share/vm/runtime/fprofiler.cpp ! src/share/vm/runtime/fprofiler.hpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/handles.cpp ! src/share/vm/runtime/handles.hpp ! src/share/vm/runtime/handles.inline.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/jniHandles.hpp ! src/share/vm/runtime/monitorChunk.cpp ! src/share/vm/runtime/monitorChunk.hpp ! src/share/vm/runtime/mutex.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/osThread.hpp ! src/share/vm/runtime/park.cpp ! src/share/vm/runtime/perfData.cpp ! src/share/vm/runtime/perfData.hpp ! src/share/vm/runtime/perfMemory.cpp ! src/share/vm/runtime/reflectionUtils.cpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/safepoint.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/stubCodeGenerator.hpp ! src/share/vm/runtime/sweeper.cpp ! src/share/vm/runtime/task.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/unhandledOops.cpp ! src/share/vm/runtime/vframeArray.cpp ! src/share/vm/runtime/vframeArray.hpp ! src/share/vm/runtime/vframe_hp.cpp ! src/share/vm/runtime/vframe_hp.hpp ! src/share/vm/runtime/virtualspace.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vmThread.hpp ! src/share/vm/runtime/vm_operations.hpp ! src/share/vm/services/attachListener.cpp ! src/share/vm/services/attachListener.hpp ! src/share/vm/services/diagnosticArgument.cpp ! src/share/vm/services/diagnosticArgument.hpp ! src/share/vm/services/diagnosticFramework.hpp ! src/share/vm/services/gcNotifier.cpp ! src/share/vm/services/gcNotifier.hpp ! src/share/vm/services/heapDumper.cpp ! src/share/vm/services/lowMemoryDetector.hpp ! src/share/vm/services/management.cpp + src/share/vm/services/memBaseline.cpp + src/share/vm/services/memBaseline.hpp + src/share/vm/services/memPtr.cpp + src/share/vm/services/memPtr.hpp + src/share/vm/services/memPtrArray.hpp + src/share/vm/services/memRecorder.cpp + src/share/vm/services/memRecorder.hpp + src/share/vm/services/memReporter.cpp + src/share/vm/services/memReporter.hpp + src/share/vm/services/memSnapshot.cpp + src/share/vm/services/memSnapshot.hpp + src/share/vm/services/memTrackWorker.cpp + src/share/vm/services/memTrackWorker.hpp + src/share/vm/services/memTracker.cpp + src/share/vm/services/memTracker.hpp ! src/share/vm/services/memoryManager.cpp ! src/share/vm/services/memoryManager.hpp ! src/share/vm/services/memoryPool.hpp ! src/share/vm/services/memoryService.cpp + src/share/vm/services/nmtDCmd.cpp + src/share/vm/services/nmtDCmd.hpp ! src/share/vm/services/threadService.cpp ! src/share/vm/services/threadService.hpp ! src/share/vm/utilities/array.cpp ! src/share/vm/utilities/array.hpp ! src/share/vm/utilities/bitMap.cpp ! src/share/vm/utilities/decoder.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/events.hpp ! src/share/vm/utilities/exceptions.hpp ! src/share/vm/utilities/growableArray.cpp ! src/share/vm/utilities/growableArray.hpp ! src/share/vm/utilities/hashtable.cpp ! src/share/vm/utilities/hashtable.hpp ! src/share/vm/utilities/hashtable.inline.hpp ! src/share/vm/utilities/histogram.cpp ! src/share/vm/utilities/histogram.hpp ! src/share/vm/utilities/intHisto.cpp ! src/share/vm/utilities/intHisto.hpp ! src/share/vm/utilities/numberSeq.cpp ! src/share/vm/utilities/numberSeq.hpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/stack.hpp ! src/share/vm/utilities/stack.inline.hpp ! src/share/vm/utilities/taskqueue.hpp ! src/share/vm/utilities/vmError.cpp ! src/share/vm/utilities/workgroup.cpp ! src/share/vm/utilities/workgroup.hpp ! src/share/vm/utilities/xmlstream.cpp Changeset: 24b9c7f4cae6 Author: coleenp Date: 2012-07-02 13:11 -0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/24b9c7f4cae6 Merge ! src/share/vm/compiler/compilerOracle.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp ! src/share/vm/memory/universe.hpp ! src/share/vm/opto/type.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/vmError.cpp Changeset: 3f1ab0c19c30 Author: dholmes Date: 2012-07-03 01:41 -0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/3f1ab0c19c30 7179383: MaxDirectMemorySize argument parsing is broken for values >2G Summary: change hotspot flag to be unsigned Reviewed-by: dholmes, sla, fparain, brutisso Contributed-by: Chris Dennis ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 65906dc96aa1 Author: mikael Date: 2012-07-03 17:35 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/65906dc96aa1 7129724: MAC: Core file location is wrong in crash report Summary: Updated core path location to reflect macosx default Reviewed-by: dholmes, kamg ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/posix/vm/os_posix.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/share/vm/runtime/os.hpp Changeset: ace99a6ffc83 Author: coleenp Date: 2012-07-04 15:55 -0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/ace99a6ffc83 7181200: JVM new hashing code breaks SA in product mode Summary: Made new_hash() overloaded rather than a virtual function so SA code doesn't need to be changed. Reviewed-by: kvn, acorn, dholmes, fparain ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/classfile/symbolTable.hpp ! src/share/vm/utilities/hashtable.cpp ! src/share/vm/utilities/hashtable.hpp Changeset: 5a1f452f8f90 Author: sla Date: 2012-06-28 11:37 +0200 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/5a1f452f8f90 7178703: Fix handling of quoted arguments and better error messages in dcmd Reviewed-by: coleenp, mgronlun, rbackman ! src/share/vm/prims/whitebox.cpp ! src/share/vm/services/diagnosticCommand.hpp ! src/share/vm/services/diagnosticFramework.cpp ! src/share/vm/services/diagnosticFramework.hpp ! test/serviceability/ParserTest.java Changeset: 04ade88d9712 Author: fparain Date: 2012-07-09 01:28 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/04ade88d9712 6294277: java -Xdebug crashes on SourceDebugExtension attribute larger than 64K Reviewed-by: sspitsyn, dholmes, coleenp, kamg ! agent/src/share/classes/sun/jvm/hotspot/jdi/ReferenceTypeImpl.java ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/runtime/vmStructs.cpp + test/runtime/6294277/SourceDebugExtension.java + test/runtime/6294277/Test6294277.sh Changeset: 90d5a592ea8f Author: coleenp Date: 2012-07-12 14:26 -0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/90d5a592ea8f Merge ! src/share/vm/compiler/compilerOracle.cpp ! src/share/vm/runtime/arguments.cpp Changeset: d50605d9417e Author: roland Date: 2012-07-02 09:58 +0200 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/d50605d9417e 7177917: Failed test java/lang/Math/PowTests.java Summary: When c2 intrinsifies pow/exp, it should never inline the java implementations. Reviewed-by: kvn ! src/share/vm/opto/library_call.cpp + test/compiler/7177917/Test7177917.java Changeset: 70862d781d01 Author: kvn Date: 2012-07-02 12:59 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/70862d781d01 7180769: assert(tboth->klass_is_exact()) failed: klass should be exact Summary: Use class exactness as part of the condition for class compare optimization instead of assert. Reviewed-by: twisti, roland ! src/share/vm/opto/parse2.cpp Changeset: ae9241bbce4a Author: kvn Date: 2012-07-11 14:50 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/ae9241bbce4a 7181658: CTW: assert(t->meet(t0) == t) failed: Not monotonic Summary: Use uncast node equivalence checks in CmpUNode::sub. Reviewed-by: kvn, twisti Contributed-by: vladimir.x.ivanov at oracle.com ! src/share/vm/opto/subnode.cpp ! src/share/vm/opto/subnode.hpp Changeset: cc787232c4c5 Author: kvn Date: 2012-07-12 14:19 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/cc787232c4c5 Merge Changeset: 66b0450071c1 Author: amurillo Date: 2012-07-13 14:06 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/66b0450071c1 Merge Changeset: 1e26f61bbb52 Author: amurillo Date: 2012-07-13 14:06 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/1e26f61bbb52 Added tag hs24-b16 for changeset 66b0450071c1 ! .hgtags Changeset: 24583e328867 Author: alanb Date: 2012-07-22 20:26 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/24583e328867 Merge ! .hgtags ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/classLoader.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp ! src/share/vm/oops/constantPoolOop.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! 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/prims/unsafe.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: e3619706a725 Author: cl Date: 2012-07-23 12:38 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/e3619706a725 Added tag jdk8-b48 for changeset 1e26f61bbb52 ! .hgtags Changeset: d5affe1b9487 Author: alanb Date: 2012-07-24 16:16 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/d5affe1b9487 Merge ! .hgtags From alan.bateman at oracle.com Wed Jul 25 21:25:10 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 26 Jul 2012 04:25:10 +0000 Subject: hg: jigsaw/jigsaw/jaxp: 9 new changesets Message-ID: <20120726042535.474B947210@hg.openjdk.java.net> Changeset: bf27b857c6ee Author: katleman Date: 2012-07-05 18:44 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxp/rev/bf27b857c6ee Added tag jdk8-b46 for changeset 300f45e99064 ! .hgtags Changeset: 7920ead2cc75 Author: joehw Date: 2012-06-26 15:28 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxp/rev/7920ead2cc75 7166896: DocumentBuilder.parse(String uri) is not IPv6 enabled. It throws MalformedURLException Summary: skip the added international character handling for general paths Reviewed-by: lancea ! src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java Changeset: 219e720a1baa Author: lana Date: 2012-06-26 22:47 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxp/rev/219e720a1baa Merge Changeset: 9cb8be5e6119 Author: lana Date: 2012-07-03 18:24 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxp/rev/9cb8be5e6119 Merge Changeset: 404521944ac9 Author: lana Date: 2012-07-10 11:40 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxp/rev/404521944ac9 Merge Changeset: 1c88da9a1365 Author: katleman Date: 2012-07-12 16:48 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxp/rev/1c88da9a1365 Added tag jdk8-b47 for changeset 404521944ac9 ! .hgtags Changeset: b0b31caed29e Author: alanb Date: 2012-07-22 19:22 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxp/rev/b0b31caed29e Merge ! .hgtags Changeset: a7e6e1048e4c Author: cl Date: 2012-07-23 12:38 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxp/rev/a7e6e1048e4c Added tag jdk8-b48 for changeset 1c88da9a1365 ! .hgtags Changeset: 8adc970057f1 Author: alanb Date: 2012-07-24 16:13 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxp/rev/8adc970057f1 Merge ! .hgtags From alan.bateman at oracle.com Wed Jul 25 21:25:55 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 26 Jul 2012 04:25:55 +0000 Subject: hg: jigsaw/jigsaw/jdk: 37 new changesets Message-ID: <20120726043253.D0E2447213@hg.openjdk.java.net> Changeset: 9d1738ef61d6 Author: katleman Date: 2012-07-05 18:44 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/9d1738ef61d6 Added tag jdk8-b46 for changeset 8d2ed9d58453 ! .hgtags Changeset: 9881db0a65bf Author: prr Date: 2012-06-26 09:38 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/9881db0a65bf 7145771: [macosx] CreateFont/Register.java test fails because of cached results of getAllFonts() Reviewed-by: igor, flar ! src/macosx/classes/sun/awt/CGraphicsEnvironment.java Changeset: c689cc1ef29a Author: prr Date: 2012-06-26 09:53 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/c689cc1ef29a 7176447: Lunix/Solaris fontpath.c : double free(family) Reviewed-by: igor, flar ! src/solaris/native/sun/awt/fontpath.c Changeset: ad126e65ccc5 Author: prr Date: 2012-06-26 09:54 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/ad126e65ccc5 7164282: check for NULL return from malloc is testing wrong variable name. Reviewed-by: igor, flar ! src/windows/native/sun/font/lcdglyph.c Changeset: c960cb8d0f8b Author: lana Date: 2012-06-27 18:39 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/c960cb8d0f8b Merge Changeset: 8e6b8a676596 Author: lana Date: 2012-07-03 20:54 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/8e6b8a676596 Merge Changeset: 7d1eae258183 Author: serb Date: 2012-06-26 13:46 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/7d1eae258183 7142091: [macosx] RFE: Refactoring of peer initialization/disposing Reviewed-by: anthony, art ! src/macosx/classes/sun/lwawt/LWButtonPeer.java ! src/macosx/classes/sun/lwawt/LWCheckboxPeer.java ! src/macosx/classes/sun/lwawt/LWChoicePeer.java ! src/macosx/classes/sun/lwawt/LWComponentPeer.java ! src/macosx/classes/sun/lwawt/LWLabelPeer.java ! src/macosx/classes/sun/lwawt/LWListPeer.java ! src/macosx/classes/sun/lwawt/LWScrollBarPeer.java ! src/macosx/classes/sun/lwawt/LWScrollPanePeer.java ! src/macosx/classes/sun/lwawt/LWTextAreaPeer.java ! src/macosx/classes/sun/lwawt/LWTextComponentPeer.java ! src/macosx/classes/sun/lwawt/LWTextFieldPeer.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/native/sun/awt/AWTWindow.m Changeset: c66b34ec39c3 Author: bagiras Date: 2012-06-26 16:46 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/c66b34ec39c3 7024749: JDK7 b131---a crash in: Java_sun_awt_windows_ThemeReader_isGetThemeTransitionDurationDefined+0x75 Reviewed-by: art, ant ! src/windows/native/sun/windows/awt_Component.cpp ! src/windows/native/sun/windows/awt_Component.h ! src/windows/native/sun/windows/awt_FileDialog.cpp ! src/windows/native/sun/windows/awt_Frame.cpp ! src/windows/native/sun/windows/awt_TextComponent.cpp + test/java/awt/Frame/7024749/bug7024749.java Changeset: 6d37b95f0555 Author: anthony Date: 2012-06-26 17:29 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/6d37b95f0555 7124326: [macosx] An issue similar to autoshutdown one in two AppContexts situation. Summary: Don't add SystemTrayPeer to the peers map Reviewed-by: art, leonidr ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java Changeset: 7cadd5bb6983 Author: lana Date: 2012-06-27 12:54 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/7cadd5bb6983 Merge Changeset: 85f72a4f5f68 Author: rupashka Date: 2012-06-28 14:05 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/85f72a4f5f68 7169111: Unreadable menu bar with Ambiance theme in GTK L&F Reviewed-by: kizune ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKStyleFactory.java ! src/share/classes/javax/swing/plaf/synth/SynthMenuUI.java Changeset: 8a284872ee2d Author: lana Date: 2012-07-03 20:56 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/8a284872ee2d Merge Changeset: ff0da4ea08a2 Author: robm Date: 2012-06-26 13:27 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/ff0da4ea08a2 4244896: (process) Provide System.getPid(), System.killProcess(String pid) Reviewed-by: alanb ! src/share/classes/java/lang/Process.java ! src/solaris/classes/java/lang/UNIXProcess.java.bsd ! src/solaris/classes/java/lang/UNIXProcess.java.linux ! src/solaris/classes/java/lang/UNIXProcess.java.solaris ! src/solaris/native/java/lang/UNIXProcess_md.c ! src/windows/classes/java/lang/ProcessImpl.java ! src/windows/native/java/lang/ProcessImpl_md.c ! test/java/lang/ProcessBuilder/Basic.java + test/java/lang/ProcessBuilder/DestroyTest.java Changeset: 94b525ce3653 Author: dholmes Date: 2012-06-27 01:36 -0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/94b525ce3653 7161229: PriorityBlockingQueue keeps hard reference to last removed element Reviewed-by: dholmes, forax, alanb Contributed-by: Doug Lea
! src/share/classes/java/util/concurrent/PriorityBlockingQueue.java ! test/java/util/concurrent/BlockingQueue/LastElement.java Changeset: 7e9a7400329b Author: lana Date: 2012-06-26 22:59 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/7e9a7400329b Merge Changeset: 2bba577b8ab8 Author: lana Date: 2012-06-27 00:09 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/2bba577b8ab8 Merge Changeset: 612e56cf284c Author: coffeys Date: 2012-06-27 21:10 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/612e56cf284c 6893617: JDK 6 CNCtx always uses the default ORB Reviewed-by: lancea ! src/share/classes/com/sun/jndi/cosnaming/CNCtx.java Changeset: 819258b5002e Author: sherman Date: 2012-06-28 22:44 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/819258b5002e 7175845: jar uf changes file permissions unexpectedly 7177216: native2ascii changes file permissions of input file Summary: undo the File.createTempFile change in jar and native2ascii Reviewed-by: asaha ! src/share/classes/sun/tools/jar/Main.java ! src/share/classes/sun/tools/native2ascii/Main.java + test/sun/tools/native2ascii/Permission.java + test/tools/jar/UpdateJar.java Changeset: 9e15068b6946 Author: jgish Date: 2012-06-29 15:36 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/9e15068b6946 7100996: (spec str) IndexOutOfBoundsException when using a StringBuffer from multiple threads Summary: add usage note to clarify thread safety Reviewed-by: briangoetz, mduigou Contributed-by: jim.gish at oracle.com ! src/share/classes/java/lang/StringBuffer.java Changeset: 9df29b658145 Author: smarks Date: 2012-06-29 16:16 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/9df29b658145 7170938: (str) incorrect wording in doc for String.subSequence Reviewed-by: forax, mduigou Contributed-by: Joe Bowbeer ! src/share/classes/java/lang/String.java Changeset: ecc5dd3790a1 Author: robm Date: 2012-07-02 19:32 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/ecc5dd3790a1 7174887: Deadlock in jndi ldap connection cleanup Reviewed-by: xuelei ! src/share/classes/com/sun/jndi/ldap/Connection.java ! src/share/classes/com/sun/jndi/ldap/LdapClient.java Changeset: b2fc66012451 Author: smarks Date: 2012-07-02 14:11 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/b2fc66012451 7176907: additional warnings cleanup in java.util, java.util.regexp, java.util.zip Reviewed-by: forax, khazra, smarks Contributed-by: Mani Sarkar ! src/share/classes/java/util/InvalidPropertiesFormatException.java ! src/share/classes/java/util/regex/Pattern.java ! src/share/classes/java/util/zip/GZIPInputStream.java Changeset: d375ea39ce9c Author: mullan Date: 2012-07-03 14:56 -0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/d375ea39ce9c 7133344: Document the java.security.properties system property feature in the java.security file Reviewed-by: hawtin, mullan, weijun Contributed-by: jason.uh at oracle.com ! src/share/lib/security/java.security ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows Changeset: 8ccbd5aabeab Author: lana Date: 2012-07-03 18:24 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/8ccbd5aabeab Merge Changeset: 3ae91286f313 Author: xuelei Date: 2012-07-03 20:29 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/3ae91286f313 7180038: regression test failure, SSLEngineBadBufferArrayAccess.java Reviewed-by: weijun ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/SSLEngineBadBufferArrayAccess.java Changeset: d828938945af Author: lana Date: 2012-07-03 20:58 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/d828938945af Merge Changeset: 9957b4759354 Author: lana Date: 2012-07-10 11:41 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/9957b4759354 Merge Changeset: 6df318863178 Author: erikj Date: 2012-07-03 16:10 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/6df318863178 7181504: Update of latest build-infra Makefiles Reviewed-by: ohair ! makefiles/CompileDemos.gmk ! makefiles/CompileJavaClasses.gmk ! makefiles/CompileLaunchers.gmk ! makefiles/CompileNativeLibraries.gmk ! makefiles/CopyFiles.gmk ! makefiles/CopyIntoClasses.gmk ! makefiles/CopySamples.gmk ! makefiles/CreateJars.gmk ! makefiles/GendataBreakIterator.gmk ! makefiles/GendataFontConfig.gmk ! makefiles/GendataHtml32dtd.gmk ! makefiles/GenerateClasses.gmk ! makefiles/GenerateData.gmk ! makefiles/GenerateJavaSources.gmk ! makefiles/GensrcBuffer.gmk ! makefiles/GensrcIcons.gmk + makefiles/GensrcJObjC.gmk ! makefiles/GensrcMisc.gmk ! makefiles/GensrcProperties.gmk ! makefiles/GensrcX11Wrappers.gmk ! makefiles/Images.gmk + makefiles/Import.gmk - makefiles/LegacyMakefiles.gmk ! makefiles/Makefile - makefiles/OldImages.gmk ! makefiles/Tools.gmk - makefiles/com/sun/crypto/provider/Makefile - makefiles/common/Classes.gmk - makefiles/common/Cscope.gmk - makefiles/common/Defs-embedded.gmk - makefiles/common/Defs-linux.gmk - makefiles/common/Defs-macosx.gmk - makefiles/common/Defs-solaris.gmk - makefiles/common/Defs-windows.gmk - makefiles/common/Defs.gmk - makefiles/common/Demo.gmk - makefiles/common/Library.gmk - makefiles/common/Mapfile-vers.gmk - makefiles/common/Modules.gmk - makefiles/common/Program.gmk - makefiles/common/Release-embedded.gmk - makefiles/common/Release-macosx.gmk - makefiles/common/Release.gmk - makefiles/common/Rules.gmk - makefiles/common/Subdirs.gmk - makefiles/common/internal/Defs-corba.gmk - makefiles/common/internal/Defs-jaxp.gmk - makefiles/common/internal/Defs-jaxws.gmk - makefiles/common/internal/Defs-langtools.gmk - makefiles/common/internal/ImportComponents.gmk - makefiles/common/internal/NativeCompileRules.gmk - makefiles/common/internal/Resources.gmk - makefiles/common/shared/Compiler-gcc.gmk - makefiles/common/shared/Compiler-llvm.gmk - makefiles/common/shared/Compiler-msvc.gmk - makefiles/common/shared/Compiler-sun.gmk - makefiles/common/shared/Defs-control.gmk - makefiles/common/shared/Defs-java.gmk - makefiles/common/shared/Defs-javadoc.gmk - makefiles/common/shared/Defs-linux.gmk - makefiles/common/shared/Defs-macosx.gmk - makefiles/common/shared/Defs-solaris.gmk - makefiles/common/shared/Defs-versions.gmk - makefiles/common/shared/Defs-windows.gmk - makefiles/common/shared/Defs.gmk - makefiles/common/shared/Platform.gmk - makefiles/common/shared/PrivateDefs.gmk-example - makefiles/common/shared/Sanity-Settings.gmk - makefiles/java/Makefile - makefiles/java/invoke/Makefile - makefiles/java/redist/Makefile - makefiles/java/redist/sajdi/Makefile - makefiles/javax/crypto/Defs-jce.gmk - makefiles/javax/crypto/Makefile - makefiles/javax/crypto/policy/limited/LIMITED - makefiles/javax/crypto/policy/limited/default_local.policy - makefiles/javax/crypto/policy/limited/exempt_local.policy - makefiles/javax/crypto/policy/unlimited/UNLIMITED - makefiles/javax/crypto/policy/unlimited/default_US_export.policy - makefiles/javax/crypto/policy/unlimited/default_local.policy ! makefiles/mapfiles/libjava/mapfile-vers ! makefiles/mapfiles/libjfr/mapfile-vers ! makefiles/mapfiles/libnio/mapfile-linux ! makefiles/mapfiles/libnio/mapfile-solaris - makefiles/mkdemo/Makefile - makefiles/mkdemo/jni/Makefile - makefiles/mkdemo/jni/Poller/Makefile - makefiles/mkdemo/jvmti/Makefile - makefiles/mkdemo/jvmti/README.txt - makefiles/mkdemo/jvmti/hprof/Makefile - makefiles/mkdemo/jvmti/mapfile-vers - makefiles/mkdemo/management/README.txt - makefiles/sun/jkernel/Makefile - makefiles/sun/security/ec/Makefile - makefiles/sun/security/pkcs11/FILES_c.gmk - makefiles/sun/security/pkcs11/Makefile - makefiles/sun/security/pkcs11/mapfile-vers Changeset: 8cb908672d9e Author: erikj Date: 2012-07-03 11:45 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/8cb908672d9e 7181508: Remove GenerateNativeHeader on awt java file Reviewed-by: ohair ! src/share/classes/java/awt/image/DirectColorModel.java ! src/share/classes/sun/awt/CharsetString.java ! src/share/classes/sun/java2d/pipe/RegionIterator.java ! src/share/native/sun/awt/image/cvutils/img_globals.c Changeset: 6cd68b7bd962 Author: erikj Date: 2012-07-03 16:01 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/6cd68b7bd962 7181501: Add some GenerateNativeHeader annotations and misc Mac adjustments to makefiles Reviewed-by: ohair ! src/macosx/native/jobjc/build.xml ! src/macosx/native/jobjc/src/core/PrimitiveCoder.hs ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/CFType.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Coder.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/FFIType.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Function.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/ID.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Invoke.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/JObjCRuntime.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/MacOSXFramework.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/NSClass.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/NativeArgumentBuffer.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/NativeBuffer.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/NativeObjectLifecycleManager.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Opaque.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Pointer.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/PrimitiveCoder.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/SEL.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Struct.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Subclassing.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/FrameworkClassFile.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/Clazz.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/coders/ComplexCoderDescriptor.java Changeset: 5b0f880eb154 Author: ohair Date: 2012-07-05 13:31 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/5b0f880eb154 Merge - makefiles/LegacyMakefiles.gmk - makefiles/OldImages.gmk - makefiles/com/sun/crypto/provider/Makefile - makefiles/common/Classes.gmk - makefiles/common/Cscope.gmk - makefiles/common/Defs-embedded.gmk - makefiles/common/Defs-linux.gmk - makefiles/common/Defs-macosx.gmk - makefiles/common/Defs-solaris.gmk - makefiles/common/Defs-windows.gmk - makefiles/common/Defs.gmk - makefiles/common/Demo.gmk - makefiles/common/Library.gmk - makefiles/common/Mapfile-vers.gmk - makefiles/common/Modules.gmk - makefiles/common/Program.gmk - makefiles/common/Release-embedded.gmk - makefiles/common/Release-macosx.gmk - makefiles/common/Release.gmk - makefiles/common/Rules.gmk - makefiles/common/Subdirs.gmk - makefiles/common/internal/Defs-corba.gmk - makefiles/common/internal/Defs-jaxp.gmk - makefiles/common/internal/Defs-jaxws.gmk - makefiles/common/internal/Defs-langtools.gmk - makefiles/common/internal/ImportComponents.gmk - makefiles/common/internal/NativeCompileRules.gmk - makefiles/common/internal/Resources.gmk - makefiles/common/shared/Compiler-gcc.gmk - makefiles/common/shared/Compiler-llvm.gmk - makefiles/common/shared/Compiler-msvc.gmk - makefiles/common/shared/Compiler-sun.gmk - makefiles/common/shared/Defs-control.gmk - makefiles/common/shared/Defs-java.gmk - makefiles/common/shared/Defs-javadoc.gmk - makefiles/common/shared/Defs-linux.gmk - makefiles/common/shared/Defs-macosx.gmk - makefiles/common/shared/Defs-solaris.gmk - makefiles/common/shared/Defs-versions.gmk - makefiles/common/shared/Defs-windows.gmk - makefiles/common/shared/Defs.gmk - makefiles/common/shared/Platform.gmk - makefiles/common/shared/PrivateDefs.gmk-example - makefiles/common/shared/Sanity-Settings.gmk - makefiles/java/Makefile - makefiles/java/invoke/Makefile - makefiles/java/redist/Makefile - makefiles/java/redist/sajdi/Makefile - makefiles/javax/crypto/Defs-jce.gmk - makefiles/javax/crypto/Makefile - makefiles/javax/crypto/policy/limited/LIMITED - makefiles/javax/crypto/policy/limited/default_local.policy - makefiles/javax/crypto/policy/limited/exempt_local.policy - makefiles/javax/crypto/policy/unlimited/UNLIMITED - makefiles/javax/crypto/policy/unlimited/default_US_export.policy - makefiles/javax/crypto/policy/unlimited/default_local.policy - makefiles/mkdemo/Makefile - makefiles/mkdemo/jni/Makefile - makefiles/mkdemo/jni/Poller/Makefile - makefiles/mkdemo/jvmti/Makefile - makefiles/mkdemo/jvmti/README.txt - makefiles/mkdemo/jvmti/hprof/Makefile - makefiles/mkdemo/jvmti/mapfile-vers - makefiles/mkdemo/management/README.txt - makefiles/sun/jkernel/Makefile - makefiles/sun/security/ec/Makefile - makefiles/sun/security/pkcs11/FILES_c.gmk - makefiles/sun/security/pkcs11/Makefile - makefiles/sun/security/pkcs11/mapfile-vers Changeset: 00b22b23269a Author: katleman Date: 2012-07-11 16:02 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/00b22b23269a Merge - makefiles/LegacyMakefiles.gmk - makefiles/OldImages.gmk - makefiles/com/sun/crypto/provider/Makefile - makefiles/common/Classes.gmk - makefiles/common/Cscope.gmk - makefiles/common/Defs-embedded.gmk - makefiles/common/Defs-linux.gmk - makefiles/common/Defs-macosx.gmk - makefiles/common/Defs-solaris.gmk - makefiles/common/Defs-windows.gmk - makefiles/common/Defs.gmk - makefiles/common/Demo.gmk - makefiles/common/Library.gmk - makefiles/common/Mapfile-vers.gmk - makefiles/common/Modules.gmk - makefiles/common/Program.gmk - makefiles/common/Release-embedded.gmk - makefiles/common/Release-macosx.gmk - makefiles/common/Release.gmk - makefiles/common/Rules.gmk - makefiles/common/Subdirs.gmk - makefiles/common/internal/Defs-corba.gmk - makefiles/common/internal/Defs-jaxp.gmk - makefiles/common/internal/Defs-jaxws.gmk - makefiles/common/internal/Defs-langtools.gmk - makefiles/common/internal/ImportComponents.gmk - makefiles/common/internal/NativeCompileRules.gmk - makefiles/common/internal/Resources.gmk - makefiles/common/shared/Compiler-gcc.gmk - makefiles/common/shared/Compiler-llvm.gmk - makefiles/common/shared/Compiler-msvc.gmk - makefiles/common/shared/Compiler-sun.gmk - makefiles/common/shared/Defs-control.gmk - makefiles/common/shared/Defs-java.gmk - makefiles/common/shared/Defs-javadoc.gmk - makefiles/common/shared/Defs-linux.gmk - makefiles/common/shared/Defs-macosx.gmk - makefiles/common/shared/Defs-solaris.gmk - makefiles/common/shared/Defs-versions.gmk - makefiles/common/shared/Defs-windows.gmk - makefiles/common/shared/Defs.gmk - makefiles/common/shared/Platform.gmk - makefiles/common/shared/PrivateDefs.gmk-example - makefiles/common/shared/Sanity-Settings.gmk - makefiles/java/Makefile - makefiles/java/invoke/Makefile - makefiles/java/redist/Makefile - makefiles/java/redist/sajdi/Makefile - makefiles/javax/crypto/Defs-jce.gmk - makefiles/javax/crypto/Makefile - makefiles/javax/crypto/policy/limited/LIMITED - makefiles/javax/crypto/policy/limited/default_local.policy - makefiles/javax/crypto/policy/limited/exempt_local.policy - makefiles/javax/crypto/policy/unlimited/UNLIMITED - makefiles/javax/crypto/policy/unlimited/default_US_export.policy - makefiles/javax/crypto/policy/unlimited/default_local.policy - makefiles/mkdemo/Makefile - makefiles/mkdemo/jni/Makefile - makefiles/mkdemo/jni/Poller/Makefile - makefiles/mkdemo/jvmti/Makefile - makefiles/mkdemo/jvmti/README.txt - makefiles/mkdemo/jvmti/hprof/Makefile - makefiles/mkdemo/jvmti/mapfile-vers - makefiles/mkdemo/management/README.txt - makefiles/sun/jkernel/Makefile - makefiles/sun/security/ec/Makefile - makefiles/sun/security/pkcs11/FILES_c.gmk - makefiles/sun/security/pkcs11/Makefile - makefiles/sun/security/pkcs11/mapfile-vers Changeset: 3e4ab821f461 Author: katleman Date: 2012-07-12 16:48 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/3e4ab821f461 Added tag jdk8-b47 for changeset 00b22b23269a ! .hgtags Changeset: 01e359c01084 Author: alanb Date: 2012-07-22 20:26 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/01e359c01084 Merge ! .hgtags - makefiles/LegacyMakefiles.gmk - makefiles/OldImages.gmk - makefiles/com/sun/crypto/provider/Makefile - makefiles/common/Classes.gmk - makefiles/common/Cscope.gmk - makefiles/common/Defs-embedded.gmk - makefiles/common/Defs-linux.gmk - makefiles/common/Defs-macosx.gmk - makefiles/common/Defs-solaris.gmk - makefiles/common/Defs-windows.gmk - makefiles/common/Defs.gmk - makefiles/common/Demo.gmk - makefiles/common/Library.gmk - makefiles/common/Mapfile-vers.gmk - makefiles/common/Modules.gmk - makefiles/common/Program.gmk - makefiles/common/Release-embedded.gmk - makefiles/common/Release-macosx.gmk - makefiles/common/Release.gmk - makefiles/common/Rules.gmk - makefiles/common/Subdirs.gmk - makefiles/common/internal/Defs-corba.gmk - makefiles/common/internal/Defs-jaxp.gmk - makefiles/common/internal/Defs-jaxws.gmk - makefiles/common/internal/Defs-langtools.gmk - makefiles/common/internal/ImportComponents.gmk - makefiles/common/internal/NativeCompileRules.gmk - makefiles/common/internal/Resources.gmk - makefiles/common/shared/Compiler-gcc.gmk - makefiles/common/shared/Compiler-llvm.gmk - makefiles/common/shared/Compiler-msvc.gmk - makefiles/common/shared/Compiler-sun.gmk - makefiles/common/shared/Defs-control.gmk - makefiles/common/shared/Defs-java.gmk - makefiles/common/shared/Defs-javadoc.gmk - makefiles/common/shared/Defs-linux.gmk - makefiles/common/shared/Defs-macosx.gmk - makefiles/common/shared/Defs-solaris.gmk - makefiles/common/shared/Defs-versions.gmk - makefiles/common/shared/Defs-windows.gmk - makefiles/common/shared/Defs.gmk - makefiles/common/shared/Platform.gmk - makefiles/common/shared/PrivateDefs.gmk-example - makefiles/common/shared/Sanity-Settings.gmk - makefiles/java/Makefile - makefiles/java/invoke/Makefile - makefiles/java/redist/Makefile - makefiles/java/redist/sajdi/Makefile - makefiles/javax/crypto/Defs-jce.gmk - makefiles/javax/crypto/Makefile - makefiles/javax/crypto/policy/limited/LIMITED - makefiles/javax/crypto/policy/limited/default_local.policy - makefiles/javax/crypto/policy/limited/exempt_local.policy - makefiles/javax/crypto/policy/unlimited/UNLIMITED - makefiles/javax/crypto/policy/unlimited/default_US_export.policy - makefiles/javax/crypto/policy/unlimited/default_local.policy - makefiles/mkdemo/Makefile - makefiles/mkdemo/jni/Makefile - makefiles/mkdemo/jni/Poller/Makefile - makefiles/mkdemo/jvmti/Makefile - makefiles/mkdemo/jvmti/README.txt - makefiles/mkdemo/jvmti/hprof/Makefile - makefiles/mkdemo/jvmti/mapfile-vers - makefiles/mkdemo/management/README.txt - makefiles/sun/jkernel/Makefile - makefiles/sun/security/ec/Makefile - makefiles/sun/security/pkcs11/FILES_c.gmk - makefiles/sun/security/pkcs11/Makefile - makefiles/sun/security/pkcs11/mapfile-vers ! src/share/classes/sun/tools/jar/Main.java Changeset: 09a79167142c Author: cl Date: 2012-07-23 12:38 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/09a79167142c Added tag jdk8-b48 for changeset 3e4ab821f461 ! .hgtags Changeset: 414bd90b1e1c Author: alanb Date: 2012-07-24 16:15 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/414bd90b1e1c Merge ! .hgtags Changeset: b14b560ca855 Author: alanb Date: 2012-07-25 05:30 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/b14b560ca855 Merge From alan.bateman at oracle.com Wed Jul 25 21:32:47 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 26 Jul 2012 04:32:47 +0000 Subject: hg: jigsaw/jigsaw/jaxws: 5 new changesets Message-ID: <20120726043300.06F0B47214@hg.openjdk.java.net> Changeset: fe6a060afc40 Author: katleman Date: 2012-07-05 18:44 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxws/rev/fe6a060afc40 Added tag jdk8-b46 for changeset ae368a83c240 ! .hgtags Changeset: efb564de8a8e Author: katleman Date: 2012-07-12 16:48 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxws/rev/efb564de8a8e Added tag jdk8-b47 for changeset fe6a060afc40 ! .hgtags Changeset: 6cf57f65dbce Author: alanb Date: 2012-07-22 19:23 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxws/rev/6cf57f65dbce Merge ! .hgtags Changeset: b48865af8ac5 Author: cl Date: 2012-07-23 12:38 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxws/rev/b48865af8ac5 Added tag jdk8-b48 for changeset efb564de8a8e ! .hgtags Changeset: 352f41a3d220 Author: alanb Date: 2012-07-26 05:32 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxws/rev/352f41a3d220 Merge ! .hgtags From sean.mullan at oracle.com Thu Jul 26 08:45:38 2012 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 26 Jul 2012 08:45:38 -0700 Subject: Review Request: loading JCE providers using ServiceLoader In-Reply-To: <500F6816.9060308@oracle.com> References: <20120723163911.D4100856@eggemoggin.niobe.net> <500EDB70.3030204@oracle.com> <500F6816.9060308@oracle.com> Message-ID: <50116622.3080208@oracle.com> On 7/24/12 8:29 PM, Alan Bateman wrote: > On 24/07/2012 18:29, Sean Mullan wrote: >> >> It's plausible we should automatically add all the Providers available >> as services to the list of registered providers. > I think this would make sense because they are otherwise not accessible > if they aren't listed in the java.security file (and the approach to > instantiate them directly will not work in module because > sun.security.pkcs11 and the other sun.* packages are not exported). Yes, though I'd like to hold off on this until we explore further adding the capability to ServiceLoader to order services; otherwise I don't know what order to put these services in. Once that is in place, then we don't really need to look at the java.security file at all. Also, in general this isn't an issue right now since all of the providers we include in the JDK are configured by default in the java.security file, except for SunPKCS11 which is only configured by default on Solaris. But SunPKCS11 is a problem anyway because it requires a config file as input, so we still need to figure out a better way to address that so that it can be loaded as a service. We may still have to have some dependency on the java.security file. --Sean From paul.sandoz at oracle.com Thu Jul 26 10:31:22 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 26 Jul 2012 10:31:22 -0700 Subject: Review Request: loading JCE providers using ServiceLoader In-Reply-To: <50116622.3080208@oracle.com> References: <20120723163911.D4100856@eggemoggin.niobe.net> <500EDB70.3030204@oracle.com> <500F6816.9060308@oracle.com> <50116622.3080208@oracle.com> Message-ID: On Jul 26, 2012, at 8:45 AM, Sean Mullan wrote: > On 7/24/12 8:29 PM, Alan Bateman wrote: >> On 24/07/2012 18:29, Sean Mullan wrote: >>> >>> It's plausible we should automatically add all the Providers available >>> as services to the list of registered providers. >> I think this would make sense because they are otherwise not accessible >> if they aren't listed in the java.security file (and the approach to >> instantiate them directly will not work in module because >> sun.security.pkcs11 and the other sun.* packages are not exported). > > Yes, though I'd like to hold off on this until we explore further adding the capability to ServiceLoader to order services; otherwise I don't know what order to put these services in. Once that is in place, then we don't really need to look at the java.security file at all. > Decentralized ordering is hard. So i think, especially for security, there will need to be some centralized declaration of order of service provider classes. Perhaps this does not require declaration of all such classes, just those that need to be ordered, the order of those not declared is undefined, and depending on the application may or may not be visible when iterating over service instances. In module mode i suppose ordering could be declared by configuring the library. But i think we require this to work in classpath mode and module mode if you want to get rid of the security specific file declaring order. > Also, in general this isn't an issue right now since all of the providers we include in the JDK are configured by default in the java.security file, except for SunPKCS11 which is only configured by default on Solaris. But SunPKCS11 is a problem anyway because it requires a config file as input, so we still need to figure out a better way to address that so that it can be loaded as a service. We may still have to have some dependency on the java.security file. > A level of indirection might work here. Paul. From paul.sandoz at oracle.com Mon Jul 30 21:14:30 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 30 Jul 2012 21:14:30 -0700 Subject: Extents of extensibility ("is this thing on?") In-Reply-To: <500989DA.9080606@redhat.com> References: <50058D11.3020106@redhat.com> <4FFEBA86-BA8A-40CE-834E-B14E68E34065@oracle.com> <500989DA.9080606@redhat.com> Message-ID: <990BB533-9EBB-456F-A2AF-B5EFAEC04D44@oracle.com> Hi, Sorry for the late reply. On Jul 20, 2012, at 9:39 AM, David M. Lloyd wrote: > Thanks for replying, responses inline. > > On 07/20/2012 09:29 AM, Paul Sandoz wrote: >> Hi David, >> >> Thanks for sending a link to the JavaDoc. >> >> If i could make some loose analogies: >> >> - org.jboss.modules.ModuleLoader is similar to >> org.openjdk.jigsaw.Configuration + Catalog >> >> - Module is similar to T extends BaseContext; and >> >> - ModuleClassLoader is similar to Loader. > > Thanks, it's helpful to see where you see these equivalencies. > >> There are two instantiations of Configuration, Configuration >> and Configuration. The former is an install-time >> configuration (and serialized in a library and used for execution of >> a main class) and the latter is a compile-time configuration. A >> configuration is the result of resolving and linking, and linking >> differs depending on whether one is installing or compiling. >> >> Catalog abstracts the layout of modules. >> >> Can these Jigsaw abstractions be improved? almost certainly since >> this is currently prototype code. > > I do disagree with the way the abstractions are structured and expressed. Many (most?) of these abstractions belong in the module API, not in the Jigsaw implementation classes. The module API has to be constrained enough to define a specific behavior; as it stands it is very general. But I don't want to tangent off into specific implementation details: I have many ideas and opinions about how things *should* be structured but that's a different discussion. > I would not read too much into what classes are in what packages at the moment, it is highly likely this will all change. >> There are at least two areas that may impact the >> implementations/abstractions: >> >> - compiling and running with a path of jmod, modular jars, and/or >> exploded compiled modules in addition to modules installed into >> libraries; and >> >> - container support, which would enable that one-way delegation you >> refer to. > > This matches my understanding, though it's not just a path when it comes to compilation: allowing a pluggable loader repository even in this case is important to (for example) OS distributions who don't necessarily *want* to coordinate a binary database of installed Java modules with their installation tools, or special build or CI tools which want to set up mock environments for integration testing. > >> FWIW the tests for the resolver create a mock Library (an >> implementation of Catalog) and build ModuleInfo instances using a >> ModuleInfoBuilder i.e. not from a module-info.java/class, shocking! >> :-) > > I am curious: how does this behave in terms of java.lang.reflect.Module? Annotations are not currently supported in module-info.java and the corresponding ModuleInfo. It's still an open question if that should be the case or not. For those tests i referred to the runtime does not kick in, thus a Module is not instantiated (which is when a module is defined by the ModuleClassLoader). The module CL, Loader, has a Context. It's not the other way around since that association is only relevant at runtime, not at install time or compile time. > Opting to make this a language construct means you need to "feed in" annotations among other things and I don't see where that could happen. This is one place where the fit is wrong IMO: you don't gain anything by having a module be a new reflective construct that you don't already have by drawing a 1:1 correspondence between a Module and a ClassLoader, which you *would* be able to do if not for the erroneous requirement that the individual core JDK pieces be separate modules with the same class loader. I would not go so far as to say erroneous, there are pros/cons. However, i think the cons outweigh the pros, it would simplify the Module system and it's usage if "requires local" did not exist, and IIRC it is likely that the JDK modules will not require it with a careful sprinkling of optional dependencies, services and some VM tweaks. Note that not all modules in the JDK are in the same context and therefore have the same CL, only those for which there remains the issue that they cannot currently be separated. You can see the association between a module and a context by dumping a configuration, for example: $ ./build/macosx-x86_64/bin/jmod dump-config jdk.tools | grep context context +jdk.tools.jaxws context +jdk.management+jdk.management.iiop context +jdk.corba context +jdk.jaxws context +jdk.rmi context +jdk.scripting context +jdk.jta context +jdk.compiler context +jdk.jx.annotations context +jdk.zipfs context +jdk.httpserver context +jdk.tools.jre context +jdk.logging context +jdk.tools.base context +jdk.auth+jdk.base+jdk.desktop+jdk.jndi+jdk.prefs+jdk.tls+sun.charsets+sun.localedata+sun.resources context +jdk.devtools context +jdk.tools context +jdk.jaxp The code which groups modules to a context is in ContextBuilder. It's an easy feature to remove from the resolving and linking process. Paul. > That requirement is better written something like: "The core JDK must be distributable in separate components that correspond to X, Y, Z (justification: distro size, ME growth, etc.). The core JDK classes must all present the same class loader (or, a null class loader depending on how that analysis pans out) (justification: compatibility with system class loader based schemes, etc.)". > > -- > - DML From paul.sandoz at oracle.com Mon Jul 30 21:26:04 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 30 Jul 2012 21:26:04 -0700 Subject: Review Request: loading JCE providers using ServiceLoader In-Reply-To: <50098E48.7010903@oracle.com> References: <50098E48.7010903@oracle.com> Message-ID: Hi Sean, The patch looks OK to me. You have a redundant synchronised block in Provider#doLoadProviderUsingServiceLoader you might want to remove. You might wanna put some comments in as to why you are caching the ServiceLoader instance. IIRC you are trying to reduce the amount of code changes to ProviderList while ensuring service instance selection is efficient, is that so? Paul. On Jul 20, 2012, at 9:58 AM, Sean Mullan wrote: > Please review my code changes to enable JCE providers to be registered and > loaded as services using the ServiceLoader API: > > http://cr.openjdk.java.net/~mullan/jigsaw/webrevs/jce-service/webrev.00/ > > There is one outstanding issue that needs to be resolved, but I think we can try > to resolve this later: > > You cannot load more than one PKCS11 provider (ex: with different > configurations), as currently supported and documented in the PKCS11 guide [1]. > > Thanks, > Sean > > [1] http://docs.oracle.com/javase/7/docs/technotes/guides/security/p11guide.html From mandy.chung at oracle.com Tue Jul 31 17:59:28 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 31 Jul 2012 17:59:28 -0700 Subject: Service provider module resolution Re: Services/configuration/context webrevs In-Reply-To: <339D0144-4FBE-4557-AF2B-68B9CE38257C@oracle.com> References: <4FF5101B.3010907@oracle.com> <339D0144-4FBE-4557-AF2B-68B9CE38257C@oracle.com> Message-ID: <50187F70.5060805@oracle.com> On 7/9/2012 8:52 AM, Paul Sandoz wrote: > Hi, > > The following webrev fixes the nits. Many service-based tests are added to _Configurator.java, which makes most of the service-based *.sh tests redundant so those redundant ones removed. I added a runtime service-based test [*] that ensures correct behavior for all three ServiceLoader methods. > > http://cr.openjdk.java.net/~psandoz/jigsaw/resolver-services/webrev.3/ Looks good. It's good to see the service-based tests added to _Configurator.java and cleanup the services/*.sh tests. Minor comment: test/org/openjdk/jigsaw/_Configurator.java It might be worth adding a test to check that the service provider module's exported package is not visible to the service consumer module (e.g. x requires service S and the context("s at 1") has no remotePackage to the package exported by y that provides S.) L2: typo "2021" -> "2012" ServiceLoaderTest.java nit: L116-118, L124-126, L132-134 - could be refactored out as a method. I'm fine if you prefer to leave it as it is. > > > I also added tests that show the permits behavior is general and not specific to services: > > ... Thanks for adding these tests. It's a general issue. As we discussed it offline today, it'll be addressed in a separate changeset. I know Alan is going to review it too. Once he reviews it, I can push this changeset for you. Mandy