From Alan.Bateman at oracle.com Wed May 2 07:23:56 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 02 May 2012 15:23:56 +0100 Subject: RFR: jmod remove In-Reply-To: <4F9F02A7.9020604@oracle.com> References: <4F8FD138.9080505@oracle.com> <4F8FFC6A.9010502@oracle.com> <4F996BEB.3050706@oracle.com> <4F996FBC.3080406@oracle.com> <4F997543.8070709@oracle.com> <4F9F02A7.9020604@oracle.com> Message-ID: <4FA1437C.6090604@oracle.com> On 30/04/2012 22:22, Chris Hegarty wrote: > Thanks Jon and Paul, both very good suggestions. > > Updated: > http://cr.openjdk.java.net/~chegar/jigsaw/jmodrm.04/webrev/ Thanks for adding "rm" as a command and fixing the other issues that came up in the first round. I've looked at the latest webrev and it's looks much better. Paul's suggestion to atomically move the module directory to a trash location is good suggestion and I see you've named it ".trash". One comment on moduleTrashDir is that it duplicates the logic for temporary directories and maybe it would be simper to use use Files.createTempDirectory to create a directory in the trash directory. A few minor comments: Library.java defines the mids parameter, not not the dry parameter. SimpleLibrary.remove, you can use try-with-resources at L1501. checkRootsRequire - I wonder if we can find a better name for this method, the logic seems right and should work for service usage too but the name of the method seems a bit odd. Maybe ensureNotPresentInConfiguration or something short? Just on consistency of naming, then with the change then Files defines both deleteTree and deleteAllUnchecked to do a recursive delete which seems a bit inconsistent. Shouldn't Files. deleteUnchecked just return any exception thrown by delete rather than dropping the useful exception that delete throws? Nothing really to do with this patch but ModuleFile.remove(File) could use Files.readAllLines which would remove much of the code. Aside from a bit of clean-up then I think this will be great to have (and urgently needed now because %mids means that we can't rm modules anymore). -Alan From paul.sandoz at oracle.com Wed May 2 09:10:56 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 2 May 2012 18:10:56 +0200 Subject: Resolver and tracing: trace dependency graph node depth not call stack depth Message-ID: <21821249-AFA9-4968-894B-0607403984DF@oracle.com> Hi, Enabling tracing to spit out lots of information (e.g. export JIGSAW_TRACE=1000) is useful to help work out what going on underneath the covers when executing javac/jmod/java. I noticed that the tracing for the Resolver class when traversing the dependency graph is not as i would have expected. The depth of the tracing output corresponds to the depth of the call stack. I expected the depth to correspond to the depth of a node (from the root node) in the dependency graph. Thus i found output is confusing and unintuitive. See the following URL for a webrev that modifies the tracing output to correspond to the depth in the dependency graph: http://cr.openjdk.java.net/~psandoz/jigsaw/resolver-trace/webrev.00/ See below for an example trace output. In this example there are three modules: B that requires A and jdk.httpserver; A with no explicit requires; and C with no explicit requires. It is now much easier to grok the traversal through the dependency graph. Notice the 4 repeating "resolving jdk.desktop at 8-ea requires optional jdk.desktop", which are due to the desktop module requiring optional services which are also provided by the desktop module. In such cases there should be no need to add such nodes to the stack of nodes to further search. I did not notice this from the previous trace output. Paul. | Path-configuring [c@=1.0, a@=1.0, b@=1.0] using catalog javac | resolving ROOT requires b@=1.0 | trying b at 1.0 | - resolving b at 1.0 requires a | - trying a at 1.0 | -- resolving a at 1.0 requires synthesized java.base@>=8 | -- trying java.base | --- resolving jdk.base at 8-ea requires optional sun.charsets | --- trying sun.charsets at 8-ea | ---- resolving sun.charsets at 8-ea requires local jdk.base.internal@=8-ea | ---- resolving sun.charsets at 8-ea requires synthesized java.base@>=7 | --- resolving jdk.base at 8-ea requires optional jdk.zipfs | --- trying jdk.zipfs at 8-ea | ---- resolving jdk.zipfs at 8-ea requires jdk.base@=8-ea | ---- resolving jdk.zipfs at 8-ea requires synthesized java.base@>=7 | --- resolving jdk.base at 8-ea requires optional jdk.jndi | --- trying jdk.jndi at 8-ea | ---- resolving jdk.jndi at 8-ea requires local jdk.auth.internal@=8-ea | ---- trying jdk.auth.internal at 8-ea | ----- resolving jdk.auth at 8-ea requires local jdk.base.internal@=8-ea | ----- resolving jdk.auth at 8-ea requires jdk.logging@=8-ea | ----- trying jdk.logging at 8-ea | ------ resolving jdk.logging at 8-ea requires local jdk.base.internal@=8-ea | ------ resolving jdk.logging at 8-ea requires synthesized java.base@>=7 | ----- resolving jdk.auth at 8-ea requires synthesized java.base@>=7 | ---- resolving jdk.jndi at 8-ea requires local jdk.base.internal@=8-ea | ---- resolving jdk.jndi at 8-ea requires optional jdk.desktop@=8-ea | ---- trying jdk.desktop at 8-ea | ----- resolving jdk.desktop at 8-ea requires optional jdk.desktop | ----- resolving jdk.desktop at 8-ea requires optional jdk.desktop | ----- resolving jdk.desktop at 8-ea requires optional jdk.desktop | ----- resolving jdk.desktop at 8-ea requires optional jdk.desktop | ----- resolving jdk.desktop at 8-ea requires local jdk.base.internal@=8-ea | ----- resolving jdk.desktop at 8-ea requires optional jdk.jaxp@=8-ea | ----- trying jdk.jaxp at 8-ea | ------ resolving jdk.jaxp at 8-ea requires local jdk.base.internal@=8-ea | ------ resolving jdk.jaxp at 8-ea requires synthesized java.base@>=7 | ----- resolving jdk.desktop at 8-ea requires jdk.logging@=8-ea | ----- resolving jdk.desktop at 8-ea requires jdk.prefs@=8-ea | ----- trying jdk.prefs at 8-ea | ------ resolving jdk.prefs at 8-ea requires local jdk.base.internal@=8-ea | ------ resolving jdk.prefs at 8-ea requires jdk.jaxp@=8-ea | ------ resolving jdk.prefs at 8-ea requires synthesized java.base@>=7 | ----- resolving jdk.desktop at 8-ea requires sun.charsets.internal@=8-ea | ----- resolving jdk.desktop at 8-ea requires synthesized java.base@>=7 | ---- resolving jdk.jndi at 8-ea requires jdk.rmi@=8-ea | ---- trying jdk.rmi at 8-ea | ----- resolving jdk.rmi at 8-ea requires local jdk.base.internal@=8-ea | ----- resolving jdk.rmi at 8-ea requires jdk.logging@=8-ea | ----- resolving jdk.rmi at 8-ea requires jdk.tls@=8-ea | ----- trying jdk.tls at 8-ea | ------ resolving jdk.tls at 8-ea requires local jdk.base.internal@=8-ea | ------ resolving jdk.tls at 8-ea requires synthesized java.base@>=7 | ----- resolving jdk.rmi at 8-ea requires synthesized java.base@>=7 | ---- resolving jdk.jndi at 8-ea requires jdk.tls.internal@=8-ea | ---- resolving jdk.jndi at 8-ea requires synthesized java.base@>=7 | --- resolving jdk.base at 8-ea requires local optional jdk.desktop.internal@=8-ea | --- resolving jdk.base at 8-ea requires optional jdk.jaxp@=8-ea | --- resolving jdk.base at 8-ea requires local optional jdk.tls.internal@=8-ea | --- resolving jdk.base at 8-ea requires local optional sun.localedata@=8-ea | --- trying sun.localedata at 8-ea | ---- resolving sun.localedata at 8-ea requires local jdk.base.internal@=8-ea | ---- resolving sun.localedata at 8-ea requires synthesized java.base@>=7 | --- resolving jdk.base at 8-ea requires local optional sun.resources@=8-ea | --- trying sun.resources at 8-ea | ---- resolving sun.resources at 8-ea requires local jdk.base.internal@=8-ea | ---- resolving sun.resources at 8-ea requires synthesized java.base@>=7 | - resolving b at 1.0 requires jdk.httpserver | - trying jdk.httpserver at 8-ea | -- resolving jdk.httpserver at 8-ea requires jdk.base@=8-ea | -- resolving jdk.httpserver at 8-ea requires jdk.logging@=8-ea | -- resolving jdk.httpserver at 8-ea requires jdk.tls@=8-ea | -- resolving jdk.httpserver at 8-ea requires synthesized java.base@>=7 | - resolving b at 1.0 requires synthesized java.base@>=8 | resolving ROOT requires a@=1.0 | resolving ROOT requires c@=1.0 | trying c at 1.0 | - resolving c at 1.0 requires synthesized java.base@>=8 From paul.sandoz at oracle.com Thu May 3 08:13:51 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 3 May 2012 17:13:51 +0200 Subject: Resolver and inefficiencies Message-ID: <3D72AF75-6027-4E82-89CD-E4A3F8D959AE@oracle.com> Hi, This observation may already be known, but i thought i would throw this out here anyway... When the following modules are installed into a library: module a @ 1.0 { requires c @ <= 1.1; requires b; class a.A; } module b @ 1.0 { requires c @ 1.0; class b.B; } module c @ 1.0 { } module c @ 1.1 { } it results in a heck of a lot of searching through the dependency graph (note that the jdk.base dependency is synthesized so there is more going on than shown above). Module a at 1.0 will initially select c at 1.1, but module b at 1.0 requires c at 1.0 so the resolution algorithm will backtrack and eventually try a at 1.0 with c at 1.0. Due to the way the resolver is implemented using the call stack this backtracking is very inefficient when there are optional dependencies. Sub-graphs are re-evaluated multiple times until the call stack eventually unwinds to try a at 1.0 with c at 1.0. One solution is have the error propagate in the return value so the call stack knows whether it should keep unwinding i.e. for conflict with module c it should unwind to the point where the decision to select c at 1.1 was made so c at 1.0 and it's dependencies can be searched. Something tells me this is still not particular efficient and there is probably a better way... Paul. From paul.sandoz at oracle.com Thu May 3 09:31:46 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 3 May 2012 18:31:46 +0200 Subject: javac/jmod discrepency for modular source compilation/install Message-ID: <6CB9ACC7-2F49-4A3A-ACE4-3B6B15347109@oracle.com> Hi, javac will compile a module in modular source layout with a directory name that is different from the module name declared in module-info.java. jmod is not happy: $ jmod install -L lib modules foobar Exception in thread "main" java.lang.Error: modules/foobar/module-info.class is for foo, not foobar Which is correct? Should jmod be a little more permissive? Or should javac be more restrictive? Paul. From david.lloyd at redhat.com Thu May 3 09:44:11 2012 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 03 May 2012 11:44:11 -0500 Subject: Resolver and inefficiencies In-Reply-To: <3D72AF75-6027-4E82-89CD-E4A3F8D959AE@oracle.com> References: <3D72AF75-6027-4E82-89CD-E4A3F8D959AE@oracle.com> Message-ID: <4FA2B5DB.30900@redhat.com> It's funny because version resolution is such an utterly undesirable feature. The downsides are that it's potentially horribly inefficient, and it makes unwarranted assumptions about your runtime environment (for example, that you only want one version of something). The upsides are... well, there are none. Basically there's no point to having two of something installed if you can't use either one. This feature was specified from a magical ivory tower where real use cases don't exist. On 05/03/2012 10:13 AM, Paul Sandoz wrote: > Hi, > > This observation may already be known, but i thought i would throw this out here anyway... > > When the following modules are installed into a library: > > module a @ 1.0 { > requires c @<= 1.1; > requires b; > > class a.A; > } > > module b @ 1.0 { > requires c @ 1.0; > > class b.B; > } > > module c @ 1.0 { } > > module c @ 1.1 { } > > it results in a heck of a lot of searching through the dependency graph (note that the jdk.base dependency is synthesized so there is more going on than shown above). > > Module a at 1.0 will initially select c at 1.1, but module b at 1.0 requires c at 1.0 so the resolution algorithm will backtrack and eventually try a at 1.0 with c at 1.0. > > Due to the way the resolver is implemented using the call stack this backtracking is very inefficient when there are optional dependencies. Sub-graphs are re-evaluated multiple times until the call stack eventually unwinds to try a at 1.0 with c at 1.0. > > One solution is have the error propagate in the return value so the call stack knows whether it should keep unwinding i.e. for conflict with module c it should unwind to the point where the decision to select c at 1.1 was made so c at 1.0 and it's dependencies can be searched. > > Something tells me this is still not particular efficient and there is probably a better way... > > Paul. -- - DML From Alan.Bateman at oracle.com Thu May 3 09:58:55 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 03 May 2012 17:58:55 +0100 Subject: Resolver and inefficiencies In-Reply-To: <3D72AF75-6027-4E82-89CD-E4A3F8D959AE@oracle.com> References: <3D72AF75-6027-4E82-89CD-E4A3F8D959AE@oracle.com> Message-ID: <4FA2B94F.2050908@oracle.com> On 03/05/2012 16:13, Paul Sandoz wrote: > Hi, > > This observation may already be known, but i thought i would throw this out here anyway... > Yes, it's a known problem and the resolver needs work. There was an interesting thread between Jaroslav Tulach and Jeff Glick a few months ago on this topic. While the resolver is only run today at install time, it will eventually need to be run at runtime, say with containers deploying applications at runtime and that usage will clearly need to be very efficient. -Alan. From paul.sandoz at oracle.com Thu May 3 13:40:13 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 3 May 2012 22:40:13 +0200 Subject: Resolver and inefficiencies In-Reply-To: <4FA2B94F.2050908@oracle.com> References: <3D72AF75-6027-4E82-89CD-E4A3F8D959AE@oracle.com> <4FA2B94F.2050908@oracle.com> Message-ID: <4183738A-AA15-4EB5-9C48-BE1A042E4480@oracle.com> On May 3, 2012, at 6:58 PM, Alan Bateman wrote: > On 03/05/2012 16:13, Paul Sandoz wrote: >> Hi, >> >> This observation may already be known, but i thought i would throw this out here anyway... >> > Yes, it's a known problem and the resolver needs work. There was an interesting thread between Jaroslav Tulach and Jeff Glick a few months ago on this topic. OK, i will look through the archives. > While the resolver is only run today at install time, Even then it could potentially blow up javac's/jmod's stack :-) > it will eventually need to be run at runtime, say with containers deploying applications at runtime and that usage will clearly need to be very efficient. > Yes, it seems doable (beyond the obvious of caching the result of resolving certain stuff, like jdk.base). Paul. From pascal at rapicault.net Thu May 3 14:03:40 2012 From: pascal at rapicault.net (Pascal Rapicault) Date: Thu, 3 May 2012 17:03:40 -0400 Subject: Resolver and inefficiencies In-Reply-To: <3D72AF75-6027-4E82-89CD-E4A3F8D959AE@oracle.com> References: <3D72AF75-6027-4E82-89CD-E4A3F8D959AE@oracle.com> Message-ID: <838B4257-8E67-4E75-832E-5BDA7689D408@rapicault.net> Hi My name is Pascal Rapicault. I'm the maintainer of the Eclipse p2 resolver (the dependency resolver used by Eclipse install mechanism). Rather than implementing a resolver from scratch, since the dependency problem is NP complete (I assume the jigsaw also is), we have been using a SAT solver (http://www.sat4j.org) and have been quite happy with it. It is very efficient and scales very well. If this can be helpful, maybe we could find a way to share knowledge on this. Sincerely, Pascal =-=-= Consulting, training, bug fixing On 2012-05-03, at 11:13 AM, Paul Sandoz wrote: > Hi, > > This observation may already be known, but i thought i would throw this out here anyway... > > When the following modules are installed into a library: > > module a @ 1.0 { > requires c @ <= 1.1; > requires b; > > class a.A; > } > > module b @ 1.0 { > requires c @ 1.0; > > class b.B; > } > > module c @ 1.0 { } > > module c @ 1.1 { } > > it results in a heck of a lot of searching through the dependency graph (note that the jdk.base dependency is synthesized so there is more going on than shown above). > > Module a at 1.0 will initially select c at 1.1, but module b at 1.0 requires c at 1.0 so the resolution algorithm will backtrack and eventually try a at 1.0 with c at 1.0. > > Due to the way the resolver is implemented using the call stack this backtracking is very inefficient when there are optional dependencies. Sub-graphs are re-evaluated multiple times until the call stack eventually unwinds to try a at 1.0 with c at 1.0. > > One solution is have the error propagate in the return value so the call stack knows whether it should keep unwinding i.e. for conflict with module c it should unwind to the point where the decision to select c at 1.1 was made so c at 1.0 and it's dependencies can be searched. > > Something tells me this is still not particular efficient and there is probably a better way... > > Paul. From mandy.chung at oracle.com Thu May 3 16:03:57 2012 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 03 May 2012 23:03:57 +0000 Subject: hg: jigsaw/jigsaw: 3 new changesets Message-ID: <20120503230357.ACB2647137@hg.openjdk.java.net> Changeset: 6a6ba0a07f33 Author: katleman Date: 2012-04-19 12:18 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/rev/6a6ba0a07f33 Added tag jdk8-b35 for changeset 5285317ebb4e ! .hgtags Changeset: 47aa0ddc9126 Author: katleman Date: 2012-04-26 14:04 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/rev/47aa0ddc9126 Added tag jdk8-b36 for changeset 6a6ba0a07f33 ! .hgtags Changeset: b7d46abfa8a4 Author: mchung Date: 2012-05-03 15:48 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/rev/b7d46abfa8a4 Merge ! .hgtags From mandy.chung at oracle.com Thu May 3 16:03:54 2012 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 03 May 2012 23:03:54 +0000 Subject: hg: jigsaw/jigsaw/corba: 7 new changesets Message-ID: <20120503230400.E044C47138@hg.openjdk.java.net> Changeset: c6c0b1047985 Author: jmelvin Date: 2012-04-16 17:10 -0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/corba/rev/c6c0b1047985 7130404: [macosx] "os.arch" value should be "x86_64" for compatibility with Apple JDK6 Summary: On Mac OS X, align system property "os.arch" with Apple legacy JDKs. Also, improve os.name string matching by using .contains() method instead of .startsWith(). This fix spans multiple repositories. Reviewed-by: dcubed, phh, ohair, katleman ! make/common/shared/Platform.gmk Changeset: 9cdcc0152526 Author: coffeys Date: 2012-04-20 17:34 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/corba/rev/9cdcc0152526 7161925: sjava files in corba don't have copyright string and legal notice Reviewed-by: chegar Contributed-by: misha.bykov at oracle.com ! src/share/classes/com/sun/corba/se/impl/orbutil/DefineWrapper.sjava ! src/share/classes/com/sun/corba/se/impl/presentation/rmi/IDLTypesUtil_save.sjava Changeset: a5a61f259961 Author: katleman Date: 2012-04-19 12:18 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/corba/rev/a5a61f259961 Added tag jdk8-b35 for changeset e3d735914edd ! .hgtags Changeset: df0c7369a86b Author: lana Date: 2012-04-26 14:14 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/corba/rev/df0c7369a86b Merge Changeset: 83fac66442cf Author: katleman Date: 2012-04-26 14:05 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/corba/rev/83fac66442cf Added tag jdk8-b36 for changeset a5a61f259961 ! .hgtags Changeset: 4a653e435441 Author: lana Date: 2012-05-01 11:29 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/corba/rev/4a653e435441 Merge Changeset: 1207721d6806 Author: mchung Date: 2012-05-03 15:55 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/corba/rev/1207721d6806 Merge ! .hgtags From mandy.chung at oracle.com Thu May 3 16:04:02 2012 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 03 May 2012 23:04:02 +0000 Subject: hg: jigsaw/jigsaw/jaxws: 3 new changesets Message-ID: <20120503230409.A4DE647139@hg.openjdk.java.net> Changeset: 89b36c658e39 Author: katleman Date: 2012-04-19 12:18 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxws/rev/89b36c658e39 Added tag jdk8-b35 for changeset e8afc16522e1 ! .hgtags Changeset: b05a948db1b6 Author: katleman Date: 2012-04-26 14:06 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxws/rev/b05a948db1b6 Added tag jdk8-b36 for changeset 89b36c658e39 ! .hgtags Changeset: 5803502b778e Author: mchung Date: 2012-05-03 15:49 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxws/rev/5803502b778e Merge ! .hgtags From mandy.chung at oracle.com Thu May 3 16:04:01 2012 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 03 May 2012 23:04:01 +0000 Subject: hg: jigsaw/jigsaw/langtools: 9 new changesets Message-ID: <20120503230421.38C114713A@hg.openjdk.java.net> Changeset: 55ae94116e89 Author: jjg Date: 2012-04-06 10:10 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/55ae94116e89 7157626: Create a new test to check major version for a class file Reviewed-by: jjg Contributed-by: sonali.goel at oracle.com + test/tools/javac/classfiles/ClassVersionChecker.java Changeset: 9c429f38ca7e Author: ksrini Date: 2012-04-09 14:31 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/9c429f38ca7e 7156633: (javac) incorrect errors when parsing variable declaration in block statements. Reviewed-by: jjg Contributed-by: jan.lahoda at oracle.com ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/IllegalStartOfStmt.java + test/tools/javac/diags/examples/NotAllowedClass.java + test/tools/javac/diags/examples/NotAllowedVariable.java ! test/tools/javac/parser/JavacParserTest.java Changeset: c35b158e2290 Author: lana Date: 2012-04-10 23:19 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/c35b158e2290 Merge Changeset: 6f0ed5a89c25 Author: mcimadamore Date: 2012-04-11 10:50 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/6f0ed5a89c25 7154127: Inference cleanup: remove bound check analysis from visitors in Types.java Summary: Remove bound checking rules from recursive subtype visitors in Types.java and replace with centralized bound-checking logic Reviewed-by: jjg, dlsmith ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java ! test/tools/javac/Diagnostics/6722234/T6722234b_1.out ! test/tools/javac/Diagnostics/6722234/T6722234b_2.out ! test/tools/javac/Diagnostics/6799605/T6799605.out ! test/tools/javac/cast/7123100/T7123100a.out ! test/tools/javac/diags/examples.not-yet.txt ! test/tools/javac/diags/examples/CantApplyDiamond1.java ! test/tools/javac/diags/examples/IncompatibleTypes1.java + test/tools/javac/diags/examples/InferNoConformingAssignment.java - test/tools/javac/diags/examples/InferredDoNotConformToBounds.java + test/tools/javac/diags/examples/InferredDoNotConformToEq.java + test/tools/javac/diags/examples/InferredDoNotConformToLower.java + test/tools/javac/diags/examples/InferredDoNotConformToUpper.java ! test/tools/javac/diags/examples/InvalidInferredTypes.java ! test/tools/javac/diags/examples/WhereCaptured.java ! test/tools/javac/diags/examples/WhereCaptured1.java + test/tools/javac/diags/examples/WhereFreshTvar.java ! test/tools/javac/generics/diamond/neg/Neg06.out ! test/tools/javac/generics/diamond/neg/Neg07.out ! test/tools/javac/generics/inference/6315770/T6315770.out ! test/tools/javac/generics/inference/6611449/T6611449.out ! test/tools/javac/generics/inference/6638712/T6638712b.out ! test/tools/javac/generics/inference/6638712/T6638712d.out ! test/tools/javac/generics/inference/6638712/T6638712e.out ! test/tools/javac/generics/inference/6650759/T6650759m.out ! test/tools/javac/generics/inference/7086601/T7086601a.out + test/tools/javac/generics/inference/7154127/T7154127.java + test/tools/javac/generics/inference/7154127/T7154127.out Changeset: 068207a80397 Author: katleman Date: 2012-04-19 12:19 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/068207a80397 Added tag jdk8-b35 for changeset defd666a7863 ! .hgtags Changeset: d023d5c3fbd2 Author: lana Date: 2012-04-18 10:22 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/d023d5c3fbd2 Merge - test/tools/javac/diags/examples/InferredDoNotConformToBounds.java Changeset: 94bbaa67686f Author: lana Date: 2012-04-23 16:59 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/94bbaa67686f Merge - test/tools/javac/diags/examples/InferredDoNotConformToBounds.java Changeset: 5891b38985e8 Author: katleman Date: 2012-04-26 14:07 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/5891b38985e8 Added tag jdk8-b36 for changeset 94bbaa67686f ! .hgtags Changeset: 36392a43d96c Author: mchung Date: 2012-05-03 15:49 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/36392a43d96c Merge ! .hgtags ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties - test/tools/javac/diags/examples/InferredDoNotConformToBounds.java From mandy.chung at oracle.com Thu May 3 16:03:58 2012 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 03 May 2012 23:03:58 +0000 Subject: hg: jigsaw/jigsaw/hotspot: 24 new changesets Message-ID: <20120503230451.2FC1B4713B@hg.openjdk.java.net> Changeset: dce0525b7ee5 Author: katleman Date: 2012-04-19 12:18 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/dce0525b7ee5 Added tag jdk8-b35 for changeset f621660a297b ! .hgtags Changeset: 4a32c51458b9 Author: amurillo Date: 2012-04-07 09:06 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/4a32c51458b9 7159842: new hotspot build - hs24-b08 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 19e197e2a1af Author: coleenp Date: 2012-04-05 12:17 -0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/19e197e2a1af 7158988: jvm crashes while debugging on x86_32 and x86_64 Summary: Object pointer is pushed more than once on stack, where GC doesn't expect it. Reviewed-by: coleenp, kvn Contributed-by: axel.siebenborn at sap.com ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp + test/runtime/7158988/FieldMonitor.java + test/runtime/7158988/TestFieldMonitor.sh + test/runtime/7158988/TestPostFieldModification.java Changeset: a4b63a58d295 Author: dcubed Date: 2012-04-09 08:38 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/a4b63a58d295 Merge Changeset: 10c12fb36ed2 Author: sla Date: 2012-04-05 14:16 +0200 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/10c12fb36ed2 7133111: libsaproc debug print should be printed as unsigned long to fit large numbers on 64bit platform Reviewed-by: dcubed, mgronlun, dsamersoff ! agent/src/os/linux/ps_core.c Changeset: 49036505ab5f Author: jiangli Date: 2012-03-29 22:18 -0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/49036505ab5f 7154670: The instanceKlass _implementors[] and _nof_implementors are not needed for non-interface klass. Summary: Change implementor to embedded instanceKlass field. Reviewed-by: sspitsyn, minqi, coleenp ! agent/src/share/classes/sun/jvm/hotspot/jdi/VirtualMachineImpl.java ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciInstanceKlass.hpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/memory/oopFactory.cpp ! src/share/vm/memory/oopFactory.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/oops/instanceKlassKlass.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 5809bf572ba3 Author: jcoomes Date: 2012-03-31 00:05 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/5809bf572ba3 Merge Changeset: 08f8d00f2ae3 Author: bobv Date: 2012-04-10 13:27 -0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/08f8d00f2ae3 Merge ! src/share/vm/classfile/classFileParser.cpp Changeset: 0cea7f13029e Author: dlong Date: 2012-04-12 18:41 -0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/0cea7f13029e Merge Changeset: df4cd4aac5c1 Author: rbackman Date: 2012-04-12 13:24 +0200 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/df4cd4aac5c1 7160924: jvmti: GetPhase returns incorrect phase before VMInit event is issued Reviewed-by: acorn, dcubed ! src/share/vm/runtime/thread.cpp Changeset: 27dab8a7c762 Author: coleenp Date: 2012-04-12 22:03 -0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/27dab8a7c762 7160467: Fix test for 7158988 Summary: Ended up checking in FieldMonitor.java as TestPostFieldModification.java Reviewed-by: kamg ! test/runtime/7158988/TestPostFieldModification.java Changeset: 0f701f572aed Author: coleenp Date: 2012-04-13 08:11 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/0f701f572aed Merge Changeset: c263e0e9f14b Author: dcubed Date: 2012-04-15 15:37 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/c263e0e9f14b Merge Changeset: 0105f367a14c Author: rbackman Date: 2012-03-06 12:36 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/0105f367a14c 7160570: Intrinsification support for tracing framework Reviewed-by: sla, never ! src/os/bsd/vm/osThread_bsd.hpp ! src/os/linux/vm/osThread_linux.hpp ! src/os/solaris/vm/osThread_solaris.hpp ! src/os/windows/vm/osThread_windows.hpp ! 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/classfile/vmSymbols.hpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/opto/runtime.hpp ! src/share/vm/runtime/osThread.hpp ! src/share/vm/trace/traceMacros.hpp Changeset: 5c86f8211d1e Author: brutisso Date: 2012-04-13 01:59 +0200 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/5c86f8211d1e 7160728: Introduce an extra logging level for G1 logging Summary: Added log levels "fine", "finer" and "finest". Let PrintGC map to "fine" and PrintGCDetails map to "finer". Separated out the per worker information in the G1 logging to the "finest" level. Reviewed-by: stefank, jwilhelm, tonyp, johnc ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp + src/share/vm/gc_implementation/g1/g1Log.cpp + src/share/vm/gc_implementation/g1/g1Log.hpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/vm_operations_g1.cpp Changeset: b632e80fc9dc Author: brutisso Date: 2012-04-16 08:57 +0200 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/b632e80fc9dc 4988100: oop_verify_old_oop appears to be dead Summary: removed oop_verify_old_oop and allow_dirty. Also reviewed by: alexlamsl at gmail.com Reviewed-by: jmasa, jwilhelm ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/psOldGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/psOldGen.hpp ! src/share/vm/gc_implementation/parallelScavenge/psYoungGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/psYoungGen.hpp ! src/share/vm/gc_implementation/shared/immutableSpace.cpp ! src/share/vm/gc_implementation/shared/immutableSpace.hpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.hpp ! src/share/vm/gc_implementation/shared/mutableSpace.cpp ! src/share/vm/gc_implementation/shared/mutableSpace.hpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/memory/compactingPermGenGen.cpp ! src/share/vm/memory/compactingPermGenGen.hpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/defNewGeneration.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/generation.cpp ! src/share/vm/memory/generation.hpp ! src/share/vm/memory/space.cpp ! src/share/vm/memory/space.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/instanceRefKlass.cpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/objArrayKlass.hpp ! src/share/vm/oops/oop.cpp ! src/share/vm/oops/oop.hpp ! src/share/vm/runtime/vmThread.cpp Changeset: dde53abda3d6 Author: stefank Date: 2012-04-11 16:18 +0200 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/dde53abda3d6 7160613: VerifyRememberedSets doesn't work with CompressedOops Summary: use load_decode_heap_oop instead of load_decode_heap_oop_not_null Reviewed-by: tonyp, brutisso ! src/share/vm/gc_implementation/parallelScavenge/cardTableExtension.cpp Changeset: 720b6a76dd9d Author: tonyp Date: 2012-04-18 07:21 -0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/720b6a76dd9d 7157073: G1: type change size_t -> uint for region counts / indexes Summary: Change the type of fields / variables / etc. that represent region counts and indeces from size_t to uint. Reviewed-by: iveresov, brutisso, jmasa, jwilhelm ! agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/HeapRegionSeq.java ! agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/HeapRegionSetBase.java ! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp ! src/share/vm/gc_implementation/g1/collectionSetChooser.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp ! src/share/vm/gc_implementation/g1/g1AllocRegion.cpp ! src/share/vm/gc_implementation/g1/g1AllocRegion.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1ErgoVerbose.hpp ! src/share/vm/gc_implementation/g1/g1MonitoringSupport.cpp ! src/share/vm/gc_implementation/g1/g1MonitoringSupport.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.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/heapRegionSeq.inline.hpp ! src/share/vm/gc_implementation/g1/heapRegionSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionSet.hpp ! src/share/vm/gc_implementation/g1/heapRegionSet.inline.hpp ! src/share/vm/gc_implementation/g1/sparsePRT.cpp ! src/share/vm/gc_implementation/g1/vmStructs_g1.hpp Changeset: f7a8920427a6 Author: tonyp Date: 2012-04-18 13:39 -0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/f7a8920427a6 7145441: G1: collection set chooser-related cleanup Summary: Cleanup of the CSet chooser class: standardize on uints for region num and indexes (instead of int, jint, etc.), make the method / field naming style more consistent, remove a lot of dead code. Reviewed-by: johnc, brutisso ! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp ! src/share/vm/gc_implementation/g1/collectionSetChooser.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp Changeset: f3f101a5e59b Author: johnc Date: 2012-04-20 11:41 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/f3f101a5e59b Merge Changeset: dff6e3459210 Author: amurillo Date: 2012-04-20 16:23 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/dff6e3459210 Merge Changeset: 50b4400ca1ec Author: amurillo Date: 2012-04-20 16:23 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/50b4400ca1ec Added tag hs24-b08 for changeset dff6e3459210 ! .hgtags Changeset: bfcf92bfefb8 Author: katleman Date: 2012-04-26 14:05 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/bfcf92bfefb8 Added tag jdk8-b36 for changeset 50b4400ca1ec ! .hgtags Changeset: 8755a5d54819 Author: mchung Date: 2012-05-03 15:48 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/8755a5d54819 Merge ! .hgtags ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/runtime/vmStructs.cpp From mandy.chung at oracle.com Thu May 3 16:04:26 2012 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 03 May 2012 23:04:26 +0000 Subject: hg: jigsaw/jigsaw/jdk: 95 new changesets Message-ID: <20120503232043.840384713D@hg.openjdk.java.net> Changeset: 19c6ad447258 Author: dmocek Date: 2012-04-04 15:57 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/19c6ad447258 7159130: add java/rmi/transport/pinClientSocketFactory to problem list Reviewed-by: smarks ! test/ProblemList.txt Changeset: 92de69b24416 Author: jgish Date: 2012-04-05 13:57 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/92de69b24416 7133806: Typo in Files.newByteChannel javadoc Reviewed-by: chegar ! src/share/classes/java/nio/file/Files.java Changeset: e06ea0dd9207 Author: littlee Date: 2012-04-10 10:17 +0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/e06ea0dd9207 7121314: Behavior mismatch between AbstractCollection.toArray(T[] ) and its spec Reviewed-by: dholmes, mduigou Contributed-by: Sean Zhou , Ulf Zibis , David Holmes ! src/share/classes/java/util/AbstractCollection.java + test/java/util/AbstractCollection/ToArrayTest.java Changeset: 1ffe2565ec06 Author: weijun Date: 2012-04-10 12:15 +0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/1ffe2565ec06 7158329: NPE in sun.security.krb5.Credentials.acquireDefaultCreds() Reviewed-by: valeriep, jjg ! src/share/classes/sun/security/krb5/Credentials.java + test/sun/security/krb5/ccache/EmptyCC.java Changeset: fb52e8bd3718 Author: mgronlun Date: 2012-04-10 10:32 +0200 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/fb52e8bd3718 7154809: JDI: update JDI/JDB debugee commandline option parsing Summary: update debugee commandline parsing Reviewed-by: dcubed, dsamersoff, sla ! src/share/classes/com/sun/tools/example/debug/tty/VMConnection.java Changeset: eec133f2406a Author: jfranck Date: 2012-04-10 10:45 +0200 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/eec133f2406a 7158930: (ann) library support for repeating annotations is not built when compiling the JDK Reviewed-by: ohair, erikj ! make/java/java/reflect/Makefile Changeset: 4fea9a99532f Author: lana Date: 2012-04-10 23:18 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/4fea9a99532f Merge Changeset: d922195b678d Author: dcubed Date: 2012-04-11 07:26 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/d922195b678d 7071907: JDK: Full Debug Symbols Summary: Add initial FDS support to some libraries and programs. Reviewed-by: kamg, fparain, sspitsyn, dsamersoff ! make/com/sun/tools/attach/Makefile ! make/common/Defs-linux.gmk ! make/common/Defs-solaris.gmk ! make/common/Library.gmk ! make/common/Program.gmk ! make/common/Release.gmk ! make/java/instrument/Makefile ! make/java/java_crw_demo/Makefile ! make/java/java_hprof_demo/Makefile ! make/java/main/java/Makefile ! make/java/management/Makefile ! make/java/npt/Makefile ! make/java/verify/Makefile ! make/jpda/jdwp/Makefile ! make/jpda/transport/socket/Makefile ! make/launchers/Makefile.launcher ! make/mkdemo/jvmti/compiledMethodLoad/Makefile ! make/mkdemo/jvmti/gctest/Makefile ! make/mkdemo/jvmti/heapTracker/Makefile ! make/mkdemo/jvmti/heapViewer/Makefile ! make/mkdemo/jvmti/hprof/Makefile ! make/mkdemo/jvmti/minst/Makefile ! make/mkdemo/jvmti/mtrace/Makefile ! make/mkdemo/jvmti/versionCheck/Makefile ! make/mkdemo/jvmti/waiters/Makefile ! make/sun/tracing/dtrace/Makefile Changeset: 10480cf00dcd Author: wetmore Date: 2012-04-11 17:12 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/10480cf00dcd 7157903: JSSE client sockets are very slow Reviewed-by: xuelei ! src/share/classes/sun/security/ssl/AppOutputStream.java ! src/share/classes/sun/security/ssl/EngineOutputRecord.java ! src/share/classes/sun/security/ssl/OutputRecord.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java Changeset: c98a013ec628 Author: youdwei Date: 2012-04-12 15:04 +0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/c98a013ec628 6610897: New constructor in sun.tools.java.ClassPath builds a path using File.separator instead of File.pathSeparator Reviewed-by: alanb ! src/share/classes/sun/tools/java/ClassPath.java + test/sun/tools/classpath/RMICClassPathTest.java Changeset: 642c6d4aaaed Author: sherman Date: 2012-04-12 10:43 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/642c6d4aaaed 7156873: (zipfs) FileSystems.newFileSystem(uri, env) fails for uri with escaped octets Summary: To use URI.getRawSchemeSpecificPart() to get the scheme part of the uri Reviewed-by: alanb, chegar ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystemProvider.java + test/demo/zipfs/ZFSTests.java Changeset: 587243bf0862 Author: sherman Date: 2012-04-12 10:55 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/587243bf0862 7152690: Initialization error with charset SJIS_0213 when security manager is enabled Summary: To use doPrivileged block to wrap the data reading code Reviewed-by: alanb ! src/share/classes/sun/nio/cs/ext/SJIS_0213.java + test/sun/nio/cs/TestSJIS0213_SM.java Changeset: e65a1756d825 Author: sherman Date: 2012-04-12 15:01 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/e65a1756d825 7067045: replaceAll("\u20ac", "$"); causses java.lang.StringIndexOutOfBoundsExceptio Summary: Updated to throw IAE instead. Reviewed-by: lancea ! src/share/classes/java/util/regex/Matcher.java ! test/java/util/regex/RegExTest.java Changeset: 70d82f2a6c11 Author: dcubed Date: 2012-04-12 16:23 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/70d82f2a6c11 7160895: tools/launcher/VersionCheck.java attempts to launch .debuginfo Summary: Do not install .debuginfo files in bin dir. Reviewed-by: ksrini, sspitsyn ! make/common/Program.gmk Changeset: fa26ac92b29e Author: mullan Date: 2012-04-13 09:46 -0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/fa26ac92b29e 7152564: Improve CodeSource.matchLocation(CodeSource) performance 7155693: CodeSource.matchLocation getPort test can be improved Reviewed-by: chegar ! src/share/classes/java/security/CodeSource.java ! test/java/security/CodeSource/Implies.java Changeset: edf10d16af25 Author: mullan Date: 2012-04-13 09:49 -0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/edf10d16af25 Merge Changeset: 7340f4a3c830 Author: vinnie Date: 2012-04-13 19:00 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/7340f4a3c830 7152169: TEST_BUG: sun/security/tools/jarsigner/ec.sh occasionally fail due to keytool error on sparc Reviewed-by: mullan ! src/share/classes/sun/security/ec/ECParameters.java Changeset: 92c6d920efe0 Author: littlee Date: 2012-04-16 11:12 +0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/92c6d920efe0 7161282: Move test/sun/tools/classpath/RMICClassPathTest.java to a more appropriate location Reviewed-by: alanb + test/sun/rmi/rmic/classpath/RMICClassPathTest.java - test/sun/tools/classpath/RMICClassPathTest.java Changeset: c0f34986d1c5 Author: alanb Date: 2012-04-16 20:12 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/c0f34986d1c5 7143744: (se) Stabilize KQueue SelectorProvider and make default on MacOSX Reviewed-by: michaelm, chegar ! src/macosx/classes/sun/nio/ch/DefaultSelectorProvider.java ! src/macosx/classes/sun/nio/ch/KQueueArrayWrapper.java ! src/macosx/classes/sun/nio/ch/KQueueSelectorImpl.java ! src/macosx/classes/sun/nio/ch/KQueueSelectorProvider.java ! src/macosx/native/sun/nio/ch/KQueueArrayWrapper.c ! test/java/nio/channels/Selector/OpRead.java ! test/sun/nio/ch/SelProvider.java Changeset: d09775066f8a Author: dmeetry Date: 2012-04-17 16:13 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/d09775066f8a 7015981: java.net.HttpCookie.domainMatches returns false if domain doesn't start with a dot Reviewed-by: chegar ! src/share/classes/java/net/HttpCookie.java Changeset: b700f85a8f29 Author: robm Date: 2012-04-17 07:14 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/b700f85a8f29 7118373: (se) Potential leak file descriptor when deregistrating at around the same time as an async close Reviewed-by: alanb ! src/share/classes/sun/nio/ch/DatagramChannelImpl.java ! src/share/classes/sun/nio/ch/ServerSocketChannelImpl.java ! src/share/classes/sun/nio/ch/SocketChannelImpl.java ! src/solaris/classes/sun/nio/ch/SinkChannelImpl.java ! src/solaris/classes/sun/nio/ch/SourceChannelImpl.java Changeset: 9c1d7507ca37 Author: alanb Date: 2012-04-17 15:46 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/9c1d7507ca37 7116200: (cs) test/java/nio/charset/coders/StreamTimeout.java fails with "Address already in use" Reviewed-by: alanb, chegar Contributed-by: jim.gish at oracle.com, forax at univ-mlv.fr ! test/java/nio/charset/coders/StreamTimeout.java Changeset: 869f53f58692 Author: sla Date: 2012-04-17 06:45 +0200 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/869f53f58692 7147848: com.sun.management.UnixOperatingSystem uses hardcoded dummy values [macosx] Summary: Provide the missing implementation UnixOperatingSystem on Mac OS X Reviewed-by: dsamersoff, dcubed ! src/solaris/native/com/sun/management/MacosxOperatingSystem.c ! src/solaris/native/com/sun/management/UnixOperatingSystem_md.c ! test/com/sun/management/OperatingSystemMXBean/TestTotalSwap.sh Changeset: 4ce1333232c5 Author: sla Date: 2012-04-17 07:25 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/4ce1333232c5 Merge Changeset: 1d14903b32e8 Author: sla Date: 2012-04-17 08:49 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/1d14903b32e8 Merge Changeset: cce6147632cf Author: dcubed Date: 2012-04-17 09:02 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/cce6147632cf 7159320: change default ZIP_DEBUGINFO_FILES back to '1' after fix for 7133529 is available Reviewed-by: ohair, jmelvin, sspitsyn ! make/common/Defs-linux.gmk ! make/common/Defs-solaris.gmk ! make/common/Defs-windows.gmk Changeset: 6cf68360cfaf Author: joehw Date: 2012-04-17 11:21 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/6cf68360cfaf 7160380: Sync JDK8 with JAXP 1.4.5 Summary: bring JDK8 up to date to what we have in 7u4 Reviewed-by: lancea, 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 + test/java/lang/SecurityManager/CheckPackageAccess.java Changeset: 31c15e2f51ba Author: khazra Date: 2012-04-17 11:59 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/31c15e2f51ba 7152856: TEST_BUG: sun/net/www/protocol/jar/B4957695.java failing on Windows Summary: Remove usage of HTTP Server at test/sun/net/www/httptest Reviewed-by: chegar, alanb ! test/sun/net/www/protocol/jar/B4957695.java Changeset: 1757f049e8c0 Author: khazra Date: 2012-04-17 12:21 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/1757f049e8c0 7157893: Warnings Cleanup in java.util.* Summary: Minor code changes to cleanup warnings in java.util.* Reviewed-by: mduigou, naoto, smarks Contributed-by: Remi Forax ! src/share/classes/java/util/AbstractCollection.java ! src/share/classes/java/util/AbstractList.java ! src/share/classes/java/util/AbstractMap.java ! src/share/classes/java/util/AbstractSet.java ! src/share/classes/java/util/ArrayDeque.java ! src/share/classes/java/util/ArrayList.java ! src/share/classes/java/util/Arrays.java ! src/share/classes/java/util/Calendar.java ! src/share/classes/java/util/Collections.java ! src/share/classes/java/util/ComparableTimSort.java ! src/share/classes/java/util/Currency.java ! src/share/classes/java/util/EnumMap.java ! src/share/classes/java/util/EnumSet.java ! src/share/classes/java/util/HashMap.java ! src/share/classes/java/util/HashSet.java ! src/share/classes/java/util/Hashtable.java ! src/share/classes/java/util/IdentityHashMap.java ! src/share/classes/java/util/IllegalFormatConversionException.java ! src/share/classes/java/util/JumboEnumSet.java ! src/share/classes/java/util/LinkedHashMap.java ! src/share/classes/java/util/Observable.java ! src/share/classes/java/util/PriorityQueue.java ! src/share/classes/java/util/Properties.java ! src/share/classes/java/util/PropertyPermission.java ! src/share/classes/java/util/RegularEnumSet.java ! src/share/classes/java/util/ResourceBundle.java ! src/share/classes/java/util/ServiceLoader.java ! src/share/classes/java/util/TimeZone.java ! src/share/classes/java/util/TreeMap.java ! src/share/classes/java/util/TreeSet.java ! src/share/classes/java/util/WeakHashMap.java Changeset: 9de97594f062 Author: michaelm Date: 2012-04-18 16:04 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/9de97594f062 7162043: Add headless mode tests to problem list [macosx] Reviewed-by: alanb ! test/ProblemList.txt Changeset: 06e4020eebb2 Author: michaelm Date: 2012-04-18 16:05 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/06e4020eebb2 Merge Changeset: 7b023213681c Author: psandoz Date: 2012-04-19 14:05 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/7b023213681c 7162262: (fs) Typo in java.nio.file.Path class description Reviewed-by: alanb ! src/share/classes/java/nio/file/Path.java Changeset: 77b35c5c4b95 Author: jmelvin Date: 2012-04-16 18:09 -0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/77b35c5c4b95 7130404: [macosx] "os.arch" value should be "x86_64" for compatibility with Apple JDK6 Summary: On Mac OS X, align system property "os.arch" with Apple legacy JDKs. Also, improve os.name string matching by using .contains() method instead of .startsWith(). This fix spans multiple repositories. Reviewed-by: dcubed, phh, ohair, katleman ! make/common/Defs-macosx.gmk ! make/common/shared/Platform.gmk ! src/share/classes/java/net/AbstractPlainDatagramSocketImpl.java ! src/share/classes/java/nio/Bits.java ! src/share/classes/java/util/prefs/Preferences.java ! src/share/classes/sun/awt/OSInfo.java ! src/share/classes/sun/font/FontUtilities.java ! src/share/classes/sun/launcher/LauncherHelper.java ! src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java ! src/share/classes/sun/print/PSPrinterJob.java ! src/share/classes/sun/security/jgss/wrapper/SunNativeProvider.java ! src/share/classes/sun/security/krb5/Config.java ! src/share/classes/sun/security/krb5/Credentials.java ! src/share/classes/sun/security/provider/ByteArrayAccess.java ! src/solaris/classes/sun/nio/ch/DefaultAsynchronousChannelProvider.java ! src/solaris/classes/sun/nio/fs/DefaultFileSystemProvider.java ! src/solaris/classes/sun/print/UnixPrintServiceLookup.java ! test/demo/jvmti/DemoRun.java ! test/java/io/File/GetXSpace.java ! test/java/lang/ProcessBuilder/Basic.java ! test/java/lang/ProcessBuilder/Zombies.java ! test/java/lang/invoke/InvokeGenericTest.java ! test/java/lang/management/OperatingSystemMXBean/GetSystemLoadAverage.java ! test/java/nio/channels/FileChannel/Size.java ! test/java/nio/channels/FileChannel/Transfer.java ! test/java/nio/file/FileSystem/Basic.java ! test/sun/nio/ch/SelProvider.java ! test/tools/launcher/TestHelper.java Changeset: 079bb040b2ee Author: coleenp Date: 2012-04-19 10:53 -0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/079bb040b2ee Merge Changeset: 404c8e097ae9 Author: vinnie Date: 2012-04-19 16:58 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/404c8e097ae9 7162823: Modify the list of excluded tests (ProblemList Reviewed-by: alanb ! test/ProblemList.txt Changeset: bc51d0569ccd Author: khazra Date: 2012-04-19 13:26 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/bc51d0569ccd 7162385: TEST_BUG: sun/net/www/protocol/jar/B4957695.java failing again Summary: Enable finding "foo1.jar" Reviewed-by: chegar ! test/sun/net/www/protocol/jar/B4957695.java Changeset: 715f50872ae7 Author: khazra Date: 2012-04-19 18:11 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/715f50872ae7 7158636: InterfaceAddress.getBroadcast() returns invalid broadcast address on WLAN Summary: Update Windows native code to infer WLAN interface type in Windows Vista and later Reviewed-by: chegar, alanb ! src/windows/native/java/net/NetworkInterface.c ! src/windows/native/java/net/NetworkInterface.h Changeset: c3905c1f5da7 Author: zhouyx Date: 2012-04-20 16:11 +0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/c3905c1f5da7 7159982: ZipFile uses static for error message when malformed zip file encountered Reviewed-by: alanb, dholmes ! src/share/native/java/util/zip/ZipFile.c ! src/share/native/java/util/zip/zip_util.c Changeset: ec9876082b4e Author: ksrini Date: 2012-04-22 06:54 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/ec9876082b4e 6981776: Pack200 must support -target 7 bytecodes Summary: pack200 implementation of JSR-200 updated for JSR-292 changes Reviewed-by: jrose, ksrini Contributed-by: john.r.rose at oracle.com, kumar.x.srinivasan at oracle.com ! 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/ConstantPool.java ! src/share/classes/com/sun/java/util/jar/pack/Constants.java ! src/share/classes/com/sun/java/util/jar/pack/Instruction.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/TLGlobals.java ! src/share/classes/com/sun/java/util/jar/pack/Utils.java ! src/share/native/com/sun/java/util/jar/pack/bands.cpp ! src/share/native/com/sun/java/util/jar/pack/bands.h ! src/share/native/com/sun/java/util/jar/pack/constants.h ! src/share/native/com/sun/java/util/jar/pack/defines.h ! src/share/native/com/sun/java/util/jar/pack/unpack.cpp ! src/share/native/com/sun/java/util/jar/pack/unpack.h ! test/tools/pack200/AttributeTests.java ! test/tools/pack200/PackageVersionTest.java ! test/tools/pack200/Utils.java - test/tools/pack200/dyn.jar ! test/tools/pack200/pack200-verifier/data/README ! test/tools/pack200/pack200-verifier/data/golden.jar ! test/tools/pack200/pack200-verifier/make/build.xml ! test/tools/pack200/pack200-verifier/src/xmlkit/ClassReader.java - 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: c2da01f0bdc1 Author: alanb Date: 2012-04-22 19:09 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/c2da01f0bdc1 7163395: jdk8/tl no longer builds on Mac Reviewed-by: chegar, ohair, ksrini - src/macosx/bin/amd64/jvm.cfg + src/macosx/bin/x86_64/jvm.cfg Changeset: 07dab8d9e34a Author: alanb Date: 2012-04-22 19:12 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/07dab8d9e34a Merge - 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: 1980be18d0f8 Author: alanb Date: 2012-04-22 21:22 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/1980be18d0f8 7132924: (dc) DatagramChannel.disconnect throws SocketException with IPv4 socket and IPv6 enabled [macosx] Reviewed-by: chegar ! src/share/classes/sun/nio/ch/DatagramChannelImpl.java ! src/solaris/native/sun/nio/ch/DatagramChannelImpl.c ! src/windows/native/sun/nio/ch/DatagramChannelImpl.c + test/java/nio/channels/DatagramChannel/Disconnect.java Changeset: fd22345bf1bf Author: sla Date: 2012-04-23 16:34 +0200 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/fd22345bf1bf 7163524: Add SecTaskAccess attribute to jstack [macosx] Reviewed-by: dholmes ! make/launchers/Makefile.launcher Changeset: 2c35304e885a Author: youdwei Date: 2012-04-24 21:06 +0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/2c35304e885a 7163865: Performance improvement for DateFormatSymbols.getZoneIndex(String) Reviewed-by: okutsu ! src/share/classes/java/text/DateFormatSymbols.java Changeset: f68c854fa584 Author: ksrini Date: 2012-04-24 10:37 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/f68c854fa584 7151434: java -jar -XX crashes java launcher Reviewed-by: mchung, darcy ! src/share/bin/java.c ! test/tools/launcher/Arrrghs.java ! test/tools/launcher/TestHelper.java Changeset: fcdbd1f34309 Author: khazra Date: 2012-04-24 14:59 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/fcdbd1f34309 7144274: [macosx] Default IPv6 multicast interface is not being set when calling MulticastSocket.joinGroup() Summary: Get default interface for Mac OS X when interface is not set Reviewed-by: chegar ! src/solaris/native/java/net/PlainDatagramSocketImpl.c ! src/solaris/native/java/net/net_util_md.c Changeset: 3e398b549cea Author: khazra Date: 2012-04-25 12:31 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/3e398b549cea 7160242: (prefs) Preferences.remove(null) does not throw NPE [macosx] Summary: Insert null check of argument in remove()'s implementation Reviewed-by: forax, chegar, alanb ! src/macosx/classes/java/util/prefs/MacOSXPreferences.java + test/java/util/prefs/RemoveNullKeyCheck.java Changeset: 108a02a57b75 Author: khazra Date: 2012-04-26 12:04 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/108a02a57b75 7118100: (prefs) Inconsistency when using system and user preference on OSX Lion Summary: Enable user to read/write preferences to persistent storage Reviewed-by: alanb ! src/macosx/classes/java/util/prefs/MacOSXPreferences.java ! src/macosx/classes/java/util/prefs/MacOSXPreferencesFile.java Changeset: cf5b15ae858a Author: ohair Date: 2012-04-12 08:11 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/cf5b15ae858a 7160976: Fix missing file in new build infrastructure: Defs-utils.gmk Reviewed-by: ihse + makefiles/common/shared/Defs-utils.gmk Changeset: 468cf87890bd Author: ohair Date: 2012-04-12 08:11 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/468cf87890bd Merge - 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: 2e3e1356ffbd Author: katleman Date: 2012-04-18 16:39 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/2e3e1356ffbd Merge Changeset: f4a8153b3ce5 Author: katleman Date: 2012-04-19 12:18 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/f4a8153b3ce5 Added tag jdk8-b35 for changeset 2e3e1356ffbd ! .hgtags Changeset: da54364b140c Author: dbuck Date: 2012-03-21 18:41 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/da54364b140c 7104147: the fix for cr6887286 was not appropriate for backporting Summary: Memory leak in the list of ImageObservers watching an object. We use recursion to iterate over the list. So once the list gets too big, we overflow the stack. Fix is to execute a prune operation on ever add, so there is no way we can get indefinite growth of stale nodes. Reviewed-by: prr, flar ! src/share/classes/sun/awt/image/ImageWatched.java + test/sun/awt/image/ImageWatched/AddNoLeak.java Changeset: 604067ec3ced Author: luchsh Date: 2012-03-22 12:47 +0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/604067ec3ced 7152519: Dependency on non-POSIX header file causes portability problem Reviewed-by: prr, igor ! src/solaris/native/sun/awt/fontpath.c ! src/solaris/native/sun/java2d/opengl/OGLFuncs_md.h ! src/solaris/native/sun/java2d/x11/XRBackendNative.c Changeset: 6f9e3ac30764 Author: dbuck Date: 2012-03-30 10:18 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/6f9e3ac30764 7154822: forward port fix for Bug 13645891 to JDK8 jcmd (1024 byte file size limit issue) Summary: Changed so that jcmd breaks input into individual lines and sends each one to the jvm separately. Reviewed-by: dcubed, sla ! src/share/classes/sun/tools/jcmd/JCmd.java + test/sun/tools/jcmd/dcmd-big-script.txt + test/sun/tools/jcmd/jcmd-big-script.sh Changeset: 9383a3749940 Author: prr Date: 2012-04-05 15:14 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/9383a3749940 7159041: Fix for 7152519 causing build breakage. Reviewed-by: igor, jgodinez ! src/solaris/native/sun/java2d/opengl/OGLFuncs_md.h Changeset: a8773780c583 Author: prr Date: 2012-04-05 15:17 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/a8773780c583 7159136: JDK 7 font manager refactoring left JNI header generation and inclusion out of sync Reviewed-by: igor, jgodinez ! make/sun/font/Makefile ! make/sun/font/t2k/Makefile ! src/share/native/sun/font/sunFont.c Changeset: 79612a7c7100 Author: ceisserer Date: 2012-04-09 15:49 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/79612a7c7100 7150134: JCK api/java_awt/Graphics/index.html#DrawLine fails with OOM for jdk8 with XRender pipeline Reviewed-by: prr ! src/solaris/classes/sun/java2d/xr/XRRenderer.java Changeset: 1d8f83fe9e91 Author: lana Date: 2012-04-11 18:52 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/1d8f83fe9e91 Merge ! make/sun/font/Makefile - test/java/io/File/isDirectory/Applet.html - test/sun/nio/cs/OLD/TestX11CS.java - 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: 508ebb79234f Author: lana Date: 2012-04-18 10:16 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/508ebb79234f Merge Changeset: 933ea89bec06 Author: serb Date: 2012-04-05 18:27 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/933ea89bec06 7150105: [macosx] four scroll-buttons don't display. scroll-sliders cursors are TextCursor. Reviewed-by: anthony, art, alexp ! src/macosx/classes/sun/lwawt/LWComponentPeer.java ! src/macosx/classes/sun/lwawt/LWCursorManager.java ! src/macosx/classes/sun/lwawt/LWTextAreaPeer.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/macosx/CCursorManager.java Changeset: 14646df8f386 Author: serb Date: 2012-04-05 19:01 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/14646df8f386 7124401: [macosx] After call Frame dispose() application continues to work Reviewed-by: art, alexp ! test/sun/java2d/X11SurfaceData/SharedMemoryPixmapsTest/SharedMemoryPixmapsTest.java Changeset: c87bdacb109e Author: serb Date: 2012-04-05 19:22 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/c87bdacb109e 7149913: [macosx] Deadlock in LWTextComponentPeer Reviewed-by: anthony, art ! src/macosx/classes/sun/lwawt/LWComponentPeer.java Changeset: 004d53e61c3b Author: serb Date: 2012-04-05 19:43 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/004d53e61c3b 7124528: [macosx] Selection is not cleared properly in text component. Reviewed-by: anthony, art ! src/macosx/classes/sun/lwawt/LWTextFieldPeer.java Changeset: dc0d4cf71dfb Author: serb Date: 2012-04-05 20:38 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/dc0d4cf71dfb 7125657: [macosx] SpreadSheet demo has the broken display when clicking outside of the table. Reviewed-by: alexp, anthony, art ! src/macosx/classes/sun/lwawt/LWRepaintArea.java Changeset: 32d2d5c8c8b9 Author: anthony Date: 2012-04-06 17:03 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/32d2d5c8c8b9 7147435: closed/java/awt/Toolkit/Headless/WrappedToolkitTest/WrappedToolkitTest.sh failed since 7u4b11 Summary: Forward-port the fix from 7u4 and open-source the test Reviewed-by: art + test/java/awt/Toolkit/Headless/WrappedToolkitTest/TestWrapped.java + test/java/awt/Toolkit/Headless/WrappedToolkitTest/WrappedToolkitTest.sh Changeset: 845604a88291 Author: anthony Date: 2012-04-06 17:15 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/845604a88291 7124553: [macosx] Need minimum size for titled Frames and JFrames Summary: Forward-port the fix from 7u4 and also eliminate the grow box since we only support OS X 10.7+ that doesn't require it. Reviewed-by: art, swingler ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/native/sun/awt/AWTWindow.h ! src/macosx/native/sun/awt/AWTWindow.m Changeset: 2e1ea0af8edf Author: anthony Date: 2012-04-06 17:20 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/2e1ea0af8edf 7148275: [macosx] setIconImages() not working correctly (distorted icon when minimized) Summary: Pass all images provided by user code to the system and let it do the right thing Reviewed-by: art, swingler ! src/macosx/classes/sun/lwawt/macosx/CImage.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/native/sun/awt/CImage.m Changeset: 86b611e57ee9 Author: rupashka Date: 2012-04-10 18:53 +0300 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/86b611e57ee9 7146146: Deadlock between subclass of AbstractDocument and UndoManager Reviewed-by: art ! src/share/classes/javax/swing/text/AbstractDocument.java + test/javax/swing/text/AbstractDocument/7146146/bug7146146.java Changeset: 8fe9b93e2474 Author: rupashka Date: 2012-04-10 19:09 +0300 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/8fe9b93e2474 7158712: Synth Property "ComboBox.popupInsets" is ignored Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/synth/SynthComboPopup.java + test/javax/swing/plaf/synth/7158712/bug7158712.java ! test/javax/swing/regtesthelpers/Util.java Changeset: 33c604bf074f Author: serb Date: 2012-04-10 22:09 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/33c604bf074f 7097771: setEnabled does not work for components in disabled containers. Reviewed-by: art, anthony ! src/solaris/classes/sun/awt/X11/XComponentPeer.java + test/java/awt/Component/7097771/bug7097771.java Changeset: 49d2a5eb48b1 Author: leonidr Date: 2012-04-11 21:06 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/49d2a5eb48b1 7124411: [macosx] There's no KEY_TYPED for VK_ESCAPE Reviewed-by: art ! src/macosx/native/sun/awt/AWTEvent.m Changeset: 417ab141f5c0 Author: lana Date: 2012-04-11 18:44 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/417ab141f5c0 Merge - test/java/io/File/isDirectory/Applet.html - test/sun/nio/cs/OLD/TestX11CS.java - 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: 9b4e642a3053 Author: rupashka Date: 2012-04-12 12:48 +0300 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/9b4e642a3053 7160653: test/javax/swing/plaf/synth/7158712/bug7158712.java failed on Ubuntu Reviewed-by: alexp ! test/javax/swing/plaf/synth/7158712/bug7158712.java Changeset: cccb19a3038e Author: leonidr Date: 2012-04-13 20:31 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/cccb19a3038e 7124272: [macosx] VK_DELETE does produce an extraneous character in a TextArea or TextField Reviewed-by: kizune, art ! src/macosx/classes/sun/lwawt/macosx/CPlatformResponder.java ! src/macosx/classes/sun/lwawt/macosx/event/NSEvent.java ! src/macosx/native/sun/awt/AWTEvent.m Changeset: 602398b3a8e7 Author: rupashka Date: 2012-04-15 12:58 +0300 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/602398b3a8e7 7149090: Nimbus:BorderFactory.createTitledBorder() the DEFAULT position of a title is not the same as the TOP Reviewed-by: alexp ! src/share/classes/javax/swing/BorderFactory.java + test/javax/swing/border/Test7149090.java Changeset: 7b0ed75abef4 Author: anthony Date: 2012-04-16 18:36 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/7b0ed75abef4 7080700: numAppContexts is accessed in non-threadsafe way in sun.awt.AppContext Summary: Replace a volatile integer with an AtomicInteger for numAppContexts Reviewed-by: anthony, art, dholmes ! src/share/classes/sun/awt/AppContext.java Changeset: 236c0051dcc7 Author: amenkov Date: 2012-04-16 17:04 +0300 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/236c0051dcc7 7058852: javax/sound/sampled/FileWriter/AlawEncoderSync.java failing intermittently Reviewed-by: prr ! test/javax/sound/sampled/FileWriter/AlawEncoderSync.java Changeset: bc5d80e168f3 Author: amenkov Date: 2012-04-17 13:03 +0300 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/bc5d80e168f3 7100140: [macosx] Test closed/javax/sound/sampled/DirectAudio/bug6400879.java is invalid Reviewed-by: prr + test/javax/sound/sampled/DirectAudio/bug6400879.java Changeset: ca58194c1b0c Author: amenkov Date: 2012-04-17 13:16 +0300 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/ca58194c1b0c Merge Changeset: cb4f5f486c45 Author: kizune Date: 2012-04-17 21:40 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/cb4f5f486c45 7161109: [macosx] JCK AWT interactive test DnDTextDropTest fails on MacOS Reviewed-by: serb ! src/macosx/classes/sun/lwawt/LWComponentPeer.java ! src/macosx/native/sun/awt/CDropTarget.m Changeset: 68be50577be8 Author: dcherepanov Date: 2012-04-18 09:29 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/68be50577be8 7156194: [macosx] Can't type non-ASCII characters into applets Reviewed-by: anthony, art ! src/macosx/classes/sun/lwawt/macosx/CEmbeddedFrame.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformResponder.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformView.java Changeset: 8bfdb214756c Author: leonidr Date: 2012-04-18 21:08 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/8bfdb214756c 7124286: [macosx] Option modifier should work like AltGr as in Apple jdk Reviewed-by: anthony ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/share/classes/javax/swing/text/DefaultEditorKit.java ! src/share/classes/sun/awt/SunToolkit.java Changeset: 96c750783a3d Author: lana Date: 2012-04-18 10:18 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/96c750783a3d Merge Changeset: 38f3f446beff Author: lana Date: 2012-04-18 10:21 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/38f3f446beff Merge Changeset: 45da9cb055ee Author: lana Date: 2012-04-23 16:58 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/45da9cb055ee Merge Changeset: 1cdcca9f3530 Author: lana Date: 2012-04-26 14:21 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/1cdcca9f3530 Merge Changeset: f0842ed897c3 Author: xuelei Date: 2012-04-27 04:25 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/f0842ed897c3 6996372: synchronizing handshaking hash Summary: remove the unnecessary synchronization. Also reviewed by David Schlosnagle (schlosna at gmail.com) Reviewed-by: weijun ! src/share/classes/sun/security/util/DisabledAlgorithmConstraints.java Changeset: c22b2f9066dd Author: alanb Date: 2012-05-01 11:17 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/c22b2f9066dd 7164570: (fs) WatchService queues CREATE event but not DELETE event for very short lived files [sol11] Reviewed-by: chegar ! src/solaris/classes/sun/nio/fs/SolarisWatchService.java + test/java/nio/file/WatchService/MayFlies.java Changeset: 71fdf32fdc65 Author: xuelei Date: 2012-05-01 03:48 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/71fdf32fdc65 7158688: Typo in SSLContext Spec Reviewed-by: weijun, wetmore ! src/share/classes/javax/net/ssl/SSLContext.java Changeset: 9e82ac15ab80 Author: katleman Date: 2012-04-26 14:07 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/9e82ac15ab80 Added tag jdk8-b36 for changeset 45da9cb055ee ! .hgtags Changeset: 6c9c3d7ce9e2 Author: lana Date: 2012-05-01 11:30 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/6c9c3d7ce9e2 Merge Changeset: 46e0bd218fcc Author: mchung Date: 2012-05-01 19:45 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/46e0bd218fcc 7164376: Replace use of sun.security.action.LoadLibraryAction with System.loadLibrary Reviewed-by: alanb, mullan, prr ! src/macosx/classes/apple/launcher/JavaAppLauncher.java ! src/macosx/classes/apple/security/KeychainStore.java ! src/macosx/classes/com/apple/concurrent/LibDispatchNative.java ! src/macosx/classes/com/apple/eawt/Application.java ! src/macosx/classes/com/apple/eio/FileManager.java ! src/macosx/classes/com/apple/laf/AquaFileView.java ! src/macosx/classes/com/apple/laf/AquaLookAndFeel.java ! src/macosx/classes/com/apple/laf/AquaNativeResources.java ! src/macosx/classes/com/apple/laf/ScreenMenu.java ! src/macosx/classes/com/apple/laf/ScreenPopupFactory.java ! src/macosx/classes/java/util/prefs/MacOSXPreferencesFile.java ! src/macosx/classes/sun/awt/CGraphicsEnvironment.java ! src/macosx/classes/sun/lwawt/macosx/CAccessibility.java ! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReader.java ! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageWriter.java ! src/share/classes/com/sun/java/util/jar/pack/NativeUnpack.java ! src/share/classes/java/awt/SplashScreen.java ! src/share/classes/java/awt/Toolkit.java ! src/share/classes/java/awt/event/NativeLibLoader.java ! src/share/classes/java/awt/image/ColorModel.java ! src/share/classes/java/net/AbstractPlainDatagramSocketImpl.java ! src/share/classes/java/net/AbstractPlainSocketImpl.java ! src/share/classes/java/net/DatagramPacket.java ! src/share/classes/java/net/InetAddress.java ! src/share/classes/java/net/NetworkInterface.java ! src/share/classes/sun/awt/NativeLibLoader.java ! src/share/classes/sun/awt/image/JPEGImageDecoder.java ! src/share/classes/sun/awt/image/NativeLibLoader.java ! src/share/classes/sun/java2d/Disposer.java ! src/share/classes/sun/management/ManagementFactoryHelper.java ! src/share/classes/sun/net/sdp/SdpSupport.java ! src/share/classes/sun/net/spi/DefaultProxySelector.java ! src/share/classes/sun/nio/ch/Util.java - src/share/classes/sun/security/action/LoadLibraryAction.java ! src/share/classes/sun/security/krb5/SCDynamicStoreConfig.java ! src/share/classes/sun/security/smartcardio/PCSC.java ! src/share/classes/sun/tracing/dtrace/JVM.java ! src/solaris/classes/sun/management/FileSystemImpl.java ! src/solaris/classes/sun/net/dns/ResolverConfigurationImpl.java ! src/solaris/classes/sun/nio/ch/sctp/SctpChannelImpl.java ! src/solaris/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java ! src/solaris/classes/sun/nio/ch/sctp/SctpServerChannelImpl.java ! src/solaris/classes/sun/print/CUPSPrinter.java ! src/windows/classes/sun/awt/shell/Win32ShellFolderManager2.java ! src/windows/classes/sun/awt/windows/WToolkit.java ! src/windows/classes/sun/management/FileSystemImpl.java ! src/windows/classes/sun/net/dns/ResolverConfigurationImpl.java ! src/windows/classes/sun/print/Win32PrintServiceLookup.java ! src/windows/classes/sun/security/smartcardio/PlatformPCSC.java Changeset: d78c6095dc98 Author: vinnie Date: 2012-05-02 14:50 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/d78c6095dc98 7087021: TEST: com/sun/crypto/provider/Mac/MacClone.java failed on Solaris sparc 5.10 Reviewed-by: mullan ! test/com/sun/crypto/provider/Mac/MacClone.java Changeset: 7975fd483d45 Author: mchung Date: 2012-05-03 15:50 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/7975fd483d45 Merge ! .hgtags ! make/com/sun/tools/attach/Makefile ! make/common/Defs-linux.gmk ! make/common/Defs-solaris.gmk ! make/common/Defs-windows.gmk ! make/common/Library.gmk ! make/common/Program.gmk ! make/common/Release.gmk ! make/common/shared/Platform.gmk ! make/java/instrument/Makefile ! make/java/java_crw_demo/Makefile ! make/java/java_hprof_demo/Makefile ! make/java/main/java/Makefile ! make/java/management/Makefile ! make/java/npt/Makefile ! make/java/verify/Makefile ! make/jpda/transport/socket/Makefile ! make/sun/font/Makefile ! make/sun/font/t2k/Makefile ! make/sun/tracing/dtrace/Makefile - src/macosx/bin/amd64/jvm.cfg ! src/share/bin/java.c ! src/share/classes/java/util/Properties.java ! src/share/classes/java/util/ResourceBundle.java ! src/share/classes/java/util/ServiceLoader.java ! src/share/classes/java/util/prefs/Preferences.java ! src/share/classes/sun/launcher/LauncherHelper.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 From paul.sandoz at oracle.com Fri May 4 04:10:04 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 4 May 2012 13:10:04 +0200 Subject: Resolver and inefficiencies In-Reply-To: <4FA2B5DB.30900@redhat.com> References: <3D72AF75-6027-4E82-89CD-E4A3F8D959AE@oracle.com> <4FA2B5DB.30900@redhat.com> Message-ID: On May 3, 2012, at 6:44 PM, David M. Lloyd wrote: > It's funny because version resolution is such an utterly undesirable feature. The downsides are that it's potentially horribly inefficient, and it makes unwarranted assumptions about your runtime environment (for example, that you only want one version of something). Presumably only one version of some artifact should be visible (and accessible) to something else that requires a compatible version of that artifact, both at compile time and runtime. It's about the scope of one version of something e.g. per VM, per application [*]; or per dependency (for want of a better term). Paul. [*] Two or more applications per JVM can be isolated. > The upsides are... well, there are none. Basically there's no point to having two of something installed if you can't use either one. > > This feature was specified from a magical ivory tower where real use cases don't exist. > From paul.sandoz at oracle.com Fri May 4 07:57:20 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 4 May 2012 16:57:20 +0200 Subject: Example code in JDK8 requiring change for modular function Message-ID: Hi, Looking into java.nio.Files (by chance for other reasons) one comes across: Files.probeContentType http://docs.oracle.com/javase/7/docs/api/java/nio/file/Files.html#probeContentType(java.nio.file.Path) which states: "A given invocation of the Java virtual machine maintains a system-wide list of file type detectors. Installed file type detectors are loaded using the service-provider loading facility defined by the ServiceLoader class. Installed file type detectors are loaded using the system class loader. If the system class loader cannot be found then the extension class loader is used; If the extension class loader cannot be found then the bootstrap class loader is used. File type detectors are typically installed by placing them in a JAR file on the application class path or in the extension directory, the JAR file contains a provider-configuration file named java.nio.file.spi.FileTypeDetector in the resource directory META-INF/services, and the file lists one or more fully-qualified names of concrete subclass of FileTypeDetector that have a zero argument constructor. If the process of locating or instantiating the installed file type detectors fails then an unspecified error is thrown. The ordering that installed providers are located is implementation specific." And the relevant code in Files.java is: private static class FileTypeDetectors{ static final FileTypeDetector defaultFileTypeDetector = sun.nio.fs.DefaultFileTypeDetector.create(); static final List installeDetectors = loadInstalledDetectors(); // loads all installed file type detectors private static List loadInstalledDetectors() { return AccessController .doPrivileged(new PrivilegedAction>() { @Override public List run() { List list = new ArrayList<>(); ServiceLoader loader = ServiceLoader .load(FileTypeDetector.class, ClassLoader.getSystemClassLoader()); for (FileTypeDetector detector: loader) { list.add(detector); } return list; }}); } } When running in "modular mode" the system class loader is the class loader of the entry module, where as what we really want to use is the class loader of the callee (the class loader used to load Files). While ServiceLoader in Jigsaw has been hacked to detect use of the system class loader and switch to the class loader of the callee it would be best to change the call from ServiceLoader.load to ServiceLoader.loadInstalled, which has the same class loading behavior in "classpath mode" and will do the right thing in "modular mode". i.e. where possible remove explicit referral to the system class loader. The javadoc also requires updating to reflect what happens in "modular mode". Further more, this code is caching the services. This is likely to be problematic with containers at runtime, that are started/stopped dynamically, where such a container has a module that provides a service implementations for FileTypeDetector. Paul. From mandy.chung at oracle.com Fri May 4 23:38:40 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 04 May 2012 23:38:40 -0700 Subject: JDK support for VM to read classes from modules in a module library Message-ID: <4FA4CAF0.8000008@oracle.com> Karen and I have been working on implementing the support in the VM and library to read classes from a module library in native and proper system initialization for modules. This will replace the current workaround of using bootclasspath in module mode. I have put together a set of slides [1] to give an overview of this work (thanks to Alex, Karen, and Alan for their feedback and improvements). This work includes several pieces: 1) Jigsaw native library interface that the VM will use to search and read classes from the base module This replaces the existing mechanism in the VM that searches and reads classes from rt.jar and the default bootclasspath (that no longer exists in modular JDK) for loading bootstrap classes. Webrev for the jdk change: http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/module-class-loading/webrev-jigsaw-ms/ Karen will send out the webrev for the VM change separately. The jigsaw native library interface is defined in jigsaw.h and its implementation is in jigsaw.c. The temporary hack in org.openjdk.jigsaw.BootLoader to extend the bootclasspath for the base and other modules is now removed. I have added a few static methods in the Platform class for the system to determine if it's running in module mode, if a given class loader defines system classes, and to get the base module loader (refer below for details). This webrev also includes some minor cleanup in the modularization such as fixing the jdk.desktop requires optional jdk.jaxp that should not be an optional dependency and moving java.text.Bidi class to the base module (Alan has eliminated the bidi to desktop dependency a while ago). 2) system modules to be granted with AllPermissions Today the classes on bootclasspath are granted with AllPermissions. In a modular JDK, we need to a way to determine if it's a system module and grants with AllPermission. Alan has implemented the module URL as the code source to modules and grants all permissions to jdk.* modules, as an interim solution. Sean is looking into different options and a reliable way to identify a system module. Webrev at: http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/module-class-loading/webrev-module-url/ 3) The JDK code needs to be audit for the use of class loader and update for modules as listed in the open issues. We have made changes in a few places in the JDK to fix some of the low hanging fruits that get more of the existing tests to pass when running as modules. a. bootstrap classes skip permission check e.g. ClassLoader.getClassLoader() Today bootstrap classes are loaded by null loader. In module mode, system modules are loaded by non-null module loader. A method Platform.isPlatformLoader(ClassLoader) is added to replace the "cl == null" check. Note that these methods may be more appropriate to live in java.lang or some other class but I add it in Platform class for now. b. Platform.getBaseModuleLoader() - the base module loader is needed when the library code wants to load a class in base's optional dependency (e.g XML) because Class.getClassLoader() currently returns null (see the open issue listed in [1]). c. replace classloader parameter in the Class.forName call from null to an appropriate loader when loading a class that is not in the base module (e.g. management, scripting, etc). Webrev: http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/module-class-loading/webrev-class-loader-fix/ There will be more of this kind of changes required in the jdk and this is just to set a few examples to get going. You can also look at all changes together in this webrev: http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/module-class-loading/webrev-all/ Thanks Mandy [1] http://openjdk.java.net/projects/jigsaw/doc/module-class-loading.pdf From david.holmes at oracle.com Sun May 6 05:36:09 2012 From: david.holmes at oracle.com (David Holmes) Date: Sun, 06 May 2012 22:36:09 +1000 Subject: Example code in JDK8 requiring change for modular function In-Reply-To: References: Message-ID: <4FA67039.7040202@oracle.com> Hi Paul, On 5/05/2012 12:57 AM, Paul Sandoz wrote: > Hi, > > Looking into java.nio.Files (by chance for other reasons) one comes across: > > Files.probeContentType > http://docs.oracle.com/javase/7/docs/api/java/nio/file/Files.html#probeContentType(java.nio.file.Path) > > which states: > > "A given invocation of the Java virtual machine maintains a system-wide list of file type detectors. Installed file type detectors are loaded using the service-provider loading facility defined by the ServiceLoader class. Installed file type detectors are loaded using the system class loader. If the system class loader cannot be found then the extension class loader is used; If the extension class loader cannot be found then the bootstrap class loader is used. File type detectors are typically installed by placing them in a JAR file on the application class path or in the extension directory, the JAR file contains a provider-configuration file named java.nio.file.spi.FileTypeDetector in the resource directory META-INF/services, and the file lists one or more fully-qualified names of concrete subclass of FileTypeDetector that have a zero argument constructor. If the process of locating or instantiating the installed file type detectors fails then an unspecified error is thr! own. The ordering that installed providers are located is implementation specific." > > And the relevant code in Files.java is: > > private static class FileTypeDetectors{ > static final FileTypeDetector defaultFileTypeDetector = > sun.nio.fs.DefaultFileTypeDetector.create(); > static final List installeDetectors = > loadInstalledDetectors(); > > // loads all installed file type detectors > private static List loadInstalledDetectors() { > return AccessController > .doPrivileged(new PrivilegedAction>() { > @Override public List run() { > List list = new ArrayList<>(); > ServiceLoader loader = ServiceLoader > .load(FileTypeDetector.class, ClassLoader.getSystemClassLoader()); > for (FileTypeDetector detector: loader) { > list.add(detector); > } > return list; > }}); > } > } > > When running in "modular mode" the system class loader is the class loader of the entry module, where as what we really want to use is the class loader of the callee (the class loader used to load Files). The system class loader needed not be the classloader of the callee. So if we expect this to use the loader of the callee then the code is broken regardless of module-mode. David ----- > While ServiceLoader in Jigsaw has been hacked to detect use of the system class loader and switch to the class loader of the callee it would be best to change the call from ServiceLoader.load to ServiceLoader.loadInstalled, which has the same class loading behavior in "classpath mode" and will do the right thing in "modular mode". i.e. where possible remove explicit referral to the system class loader. > > The javadoc also requires updating to reflect what happens in "modular mode". > > Further more, this code is caching the services. This is likely to be problematic with containers at runtime, that are started/stopped dynamically, where such a container has a module that provides a service implementations for FileTypeDetector. > > Paul. From Alan.Bateman at oracle.com Sun May 6 07:17:36 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 06 May 2012 15:17:36 +0100 Subject: Example code in JDK8 requiring change for modular function In-Reply-To: <4FA67039.7040202@oracle.com> References: <4FA67039.7040202@oracle.com> Message-ID: <4FA68800.8000307@oracle.com> On 06/05/2012 13:36, David Holmes wrote: > : >> >> When running in "modular mode" the system class loader is the class >> loader of the entry module, where as what we really want to use is >> the class loader of the callee (the class loader used to load Files). > > > The system class loader needed not be the classloader of the callee. > So if we expect this to use the loader of the callee then the code is > broken regardless of module-mode. This code works as specified, if you have a custom file type detector then you put it on the system class path and it will be located. To work with modules it requires changes, including specification changes. This goes for many other areas of the JDK, I assume Paul just picked this one out to start a discussion on the changes that will need to happen across the board. In this case the specification will need to make it clear how it works when running with modules. Implementation-wise it will require the base module to have "requires optional service java.nio.file.spi.FileTypeDetector" in its module declaration and the ServiceLoader usage changed as the legacy system class loader notion doesn't make sense when running with modules. For this case then loadInstalled is fine. It would also be fine to use Files.class.getClassLoader, assuming that it returns a ModuleClassLoader (that's a TBD for the base module in Mandy's slides). -Alan. From david.holmes at oracle.com Sun May 6 20:36:04 2012 From: david.holmes at oracle.com (David Holmes) Date: Mon, 07 May 2012 13:36:04 +1000 Subject: Example code in JDK8 requiring change for modular function In-Reply-To: <4FA68800.8000307@oracle.com> References: <4FA67039.7040202@oracle.com> <4FA68800.8000307@oracle.com> Message-ID: <4FA74324.1010202@oracle.com> On 7/05/2012 12:17 AM, Alan Bateman wrote: > On 06/05/2012 13:36, David Holmes wrote: >> : >>> >>> When running in "modular mode" the system class loader is the class >>> loader of the entry module, where as what we really want to use is >>> the class loader of the callee (the class loader used to load Files). >> >> >> The system class loader needed not be the classloader of the callee. >> So if we expect this to use the loader of the callee then the code is >> broken regardless of module-mode. > This code works as specified, if you have a custom file type detector > then you put it on the system class path and it will be located. Okay - then the expectation is _not_ to use the loader of the callee at all. That's fine. > To work with modules it requires changes, including specification Sure. David ----- > changes. This goes for many other areas of the JDK, I assume Paul just > picked this one out to start a discussion on the changes that will need > to happen across the board. In this case the specification will need to > make it clear how it works when running with modules. > Implementation-wise it will require the base module to have "requires > optional service java.nio.file.spi.FileTypeDetector" in its module > declaration and the ServiceLoader usage changed as the legacy system > class loader notion doesn't make sense when running with modules. For > this case then loadInstalled is fine. It would also be fine to use > Files.class.getClassLoader, assuming that it returns a ModuleClassLoader > (that's a TBD for the base module in Mandy's slides). > > -Alan. From Alan.Bateman at oracle.com Mon May 7 00:31:32 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 07 May 2012 08:31:32 +0100 Subject: Example code in JDK8 requiring change for modular function In-Reply-To: <4FA74324.1010202@oracle.com> References: <4FA67039.7040202@oracle.com> <4FA68800.8000307@oracle.com> <4FA74324.1010202@oracle.com> Message-ID: <4FA77A54.6040806@oracle.com> On 07/05/2012 04:36, David Holmes wrote: > On 7/05/2012 12:17 AM, Alan Bateman wrote: >> On 06/05/2012 13:36, David Holmes wrote: >>> : >>>> >>>> When running in "modular mode" the system class loader is the class >>>> loader of the entry module, where as what we really want to use is >>>> the class loader of the callee (the class loader used to load Files). >>> >>> >>> The system class loader needed not be the classloader of the callee. >>> So if we expect this to use the loader of the callee then the code is >>> broken regardless of module-mode. >> This code works as specified, if you have a custom file type detector >> then you put it on the system class path and it will be located. > > Okay - then the expectation is _not_ to use the loader of the callee > at all. That's fine. I think caller vs. callee has got a bit confused in this discussion. For ServiceLoader usages then the important code is the code that is invoking ServiceLoader. So assume we are running with modules and the application invokes Files.probeContentType to probe the type of a file. This gives us application -> Files.probeContentType -> ... Files$FileTypeDetectors$1.loadInstalledDetectors -> ServiceLoader. If the code is changed to use loadInstalled (one of the choices, not necessarily the best choice here) then ServiceLoader.loadInstalled will need to look at the caller frame. In this case the caller (of ServiceLoader.loadInstalled) is in the base module and the base module will have declared that it requires service java.nio.file.spi.FileTypeDetector. At configuration time then the base module will have been linked with all modules that provide implementations of the service so everything works as expected. Hopefully this is clearer now. -Alan. From paul.sandoz at oracle.com Mon May 7 00:45:50 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 7 May 2012 09:45:50 +0200 Subject: Example code in JDK8 requiring change for modular function In-Reply-To: <4FA77A54.6040806@oracle.com> References: <4FA67039.7040202@oracle.com> <4FA68800.8000307@oracle.com> <4FA74324.1010202@oracle.com> <4FA77A54.6040806@oracle.com> Message-ID: <3A511680-EE3A-4B30-8AA2-197F222DE1C7@oracle.com> On May 7, 2012, at 9:31 AM, Alan Bateman wrote: > On 07/05/2012 04:36, David Holmes wrote: >> On 7/05/2012 12:17 AM, Alan Bateman wrote: >>> On 06/05/2012 13:36, David Holmes wrote: >>>> : >>>>> >>>>> When running in "modular mode" the system class loader is the class >>>>> loader of the entry module, where as what we really want to use is >>>>> the class loader of the callee (the class loader used to load Files). >>>> >>>> >>>> The system class loader needed not be the classloader of the callee. >>>> So if we expect this to use the loader of the callee then the code is >>>> broken regardless of module-mode. >>> This code works as specified, if you have a custom file type detector >>> then you put it on the system class path and it will be located. >> >> Okay - then the expectation is _not_ to use the loader of the callee at all. That's fine. > I think caller vs. callee has got a bit confused in this discussion. For ServiceLoader usages then the important code is the code that is invoking ServiceLoader. So assume we are running with modules and the application invokes Files.probeContentType to probe the type of a file. This gives us application -> Files.probeContentType -> ... Files$FileTypeDetectors$1.loadInstalledDetectors -> ServiceLoader. If the code is changed to use loadInstalled (one of the choices, not necessarily the best choice here) Given that it has not been decided yet whether all classes should return a non-null classloader or only those not in base i think it best practice to try and avoid explicit reference to a classloader if possible. A downside is it's less efficient. Paul. > then ServiceLoader.loadInstalled will need to look at the caller frame. In this case the caller (of ServiceLoader.loadInstalled) is in the base module and the base module will have declared that it requires service java.nio.file.spi.FileTypeDetector. At configuration time then the base module will have been linked with all modules that provide implementations of the service so everything works as expected. Hopefully this is clearer now. > > -Alan. From paul.sandoz at oracle.com Mon May 7 01:06:21 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 7 May 2012 10:06:21 +0200 Subject: Example code in JDK8 requiring change for modular function In-Reply-To: <4FA68800.8000307@oracle.com> References: <4FA67039.7040202@oracle.com> <4FA68800.8000307@oracle.com> Message-ID: <820C47B9-8110-4E93-AC47-39C2C87615FC@oracle.com> On May 6, 2012, at 4:17 PM, Alan Bateman wrote: > On 06/05/2012 13:36, David Holmes wrote: >> : >>> >>> When running in "modular mode" the system class loader is the class loader of the entry module, where as what we really want to use is the class loader of the callee (the class loader used to load Files). >> >> >> The system class loader needed not be the classloader of the callee. So if we expect this to use the loader of the callee then the code is broken regardless of module-mode. > This code works as specified, if you have a custom file type detector then you put it on the system class path and it will be located. > > To work with modules it requires changes, including specification changes. This goes for many other areas of the JDK, I assume Paul just picked this one out to start a discussion on the changes that will need to happen across the board. Yes. Where possible it is convenient to make changes in JDK8 and pull into Jigsaw (makes the merge back easier), as has been the case for other changes. But, for such areas it is gonna be a multi-stage process given the required (but as of yet unspecified) javadoc changes. > In this case the specification will need to make it clear how it works when running with modules. > Implementation-wise it will require the base module to have "requires optional service java.nio.file.spi.FileTypeDetector" in its module declaration and the ServiceLoader usage changed as the legacy system class loader notion doesn't make sense when running with modules. FWIW i verified that is the case today in Jigsaw. Do the generated module-info.java files contain all known providers, or is there still some work to do here? The main concern i have with this example is the caching of the service provider implementations. It is something we will have to revisit. Paul. From Alan.Bateman at oracle.com Mon May 7 01:39:09 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 07 May 2012 09:39:09 +0100 Subject: Example code in JDK8 requiring change for modular function In-Reply-To: <820C47B9-8110-4E93-AC47-39C2C87615FC@oracle.com> References: <4FA67039.7040202@oracle.com> <4FA68800.8000307@oracle.com> <820C47B9-8110-4E93-AC47-39C2C87615FC@oracle.com> Message-ID: <4FA78A2D.6010005@oracle.com> On 07/05/2012 09:06, Paul Sandoz wrote: > : > >> Implementation-wise it will require the base module to have "requires optional service java.nio.file.spi.FileTypeDetector" in its module declaration and the ServiceLoader usage changed as the legacy system class loader notion doesn't make sense when running with modules. > FWIW i verified that is the case today in Jigsaw. Do the generated module-info.java files contain all known providers, or is there still some work to do here? Non-static dependencies are a bit fragile at this point, and will be until we check in the module-info sources. For now it requires making sure that jdk/make/modules/jdk.depconfig is up to date. In this case the issue is that it's in jdk.depconfig as: @Provider(optional) java.nio.file.Files$DefaultFileTypeDetectorHolder -> META-INF/services/java.nio.file.spi.FileTypeDetector but that's not the right inner class name anymore. Apologies about that, I fixed lots of these when adding the services support but I missed this one. > The main concern i have with this example is the caching of the service provider implementations. It is something we will have to revisit. > This specific case was never intended to be dynamic, it's specified to maintain a system-wide list of file type detectors. But as you bring up caching then one observation is that as the user of the service is linked with the service providers at configuration time then caching by the user of ServiceLoader isn't going to change the performance, meaning there isn't really any need for this code to cache the providers when running with modules. I guess the concern you have is the container managed application that comes with their own file type detector, that scenario would require consideration. -Alan From paul.sandoz at oracle.com Mon May 7 01:52:57 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 7 May 2012 10:52:57 +0200 Subject: Example code in JDK8 requiring change for modular function In-Reply-To: <4FA78A2D.6010005@oracle.com> References: <4FA67039.7040202@oracle.com> <4FA68800.8000307@oracle.com> <820C47B9-8110-4E93-AC47-39C2C87615FC@oracle.com> <4FA78A2D.6010005@oracle.com> Message-ID: On May 7, 2012, at 10:39 AM, Alan Bateman wrote: > On 07/05/2012 09:06, Paul Sandoz wrote: >> : >> >>> Implementation-wise it will require the base module to have "requires optional service java.nio.file.spi.FileTypeDetector" in its module declaration and the ServiceLoader usage changed as the legacy system class loader notion doesn't make sense when running with modules. >> FWIW i verified that is the case today in Jigsaw. Do the generated module-info.java files contain all known providers, or is there still some work to do here? > Non-static dependencies are a bit fragile at this point, and will be until we check in the module-info sources. For now it requires making sure that jdk/make/modules/jdk.depconfig is up to date. In this case the issue is that it's in jdk.depconfig as: > > @Provider(optional) > java.nio.file.Files$DefaultFileTypeDetectorHolder -> META-INF/services/java.nio.file.spi.FileTypeDetector > > but that's not the right inner class name anymore. Apologies about that, I fixed lots of these when adding the services support but I missed this one. > If you have not already fixed it by the time you read this email i can do it. >> The main concern i have with this example is the caching of the service provider implementations. It is something we will have to revisit. >> > This specific case was never intended to be dynamic, it's specified to maintain a system-wide list of file type detectors. But as you bring up caching then one observation is that as the user of the service is linked with the service providers at configuration time then caching by the user of ServiceLoader isn't going to change the performance, meaning there isn't really any need for this code to cache the providers when running with modules. I guess the concern you have is the container managed application that comes with their own file type detector, that scenario would require consideration. > Exactly. So this is good example of where we could have two code paths based on a boolean check if running in module mode or not. Paul. From Alan.Bateman at oracle.com Mon May 7 06:13:09 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 07 May 2012 14:13:09 +0100 Subject: Example code in JDK8 requiring change for modular function In-Reply-To: References: <4FA67039.7040202@oracle.com> <4FA68800.8000307@oracle.com> <820C47B9-8110-4E93-AC47-39C2C87615FC@oracle.com> <4FA78A2D.6010005@oracle.com> Message-ID: <4FA7CA65.1020401@oracle.com> On 07/05/2012 09:52, Paul Sandoz wrote: > On May 7, 2012, at 10:39 AM, Alan Bateman wrote: > >> On 07/05/2012 09:06, Paul Sandoz wrote: >>> : >>> >>>> Implementation-wise it will require the base module to have "requires optional service java.nio.file.spi.FileTypeDetector" in its module declaration and the ServiceLoader usage changed as the legacy system class loader notion doesn't make sense when running with modules. >>> FWIW i verified that is the case today in Jigsaw. Do the generated module-info.java files contain all known providers, or is there still some work to do here? >> Non-static dependencies are a bit fragile at this point, and will be until we check in the module-info sources. For now it requires making sure that jdk/make/modules/jdk.depconfig is up to date. In this case the issue is that it's in jdk.depconfig as: >> >> @Provider(optional) >> java.nio.file.Files$DefaultFileTypeDetectorHolder -> META-INF/services/java.nio.file.spi.FileTypeDetector >> >> but that's not the right inner class name anymore. Apologies about that, I fixed lots of these when adding the services support but I missed this one. >> > If you have not already fixed it by the time you read this email i can do it. I'll push a fix for it now so that we don't forget it. -Alan From alan.bateman at oracle.com Mon May 7 06:13:22 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 07 May 2012 13:13:22 +0000 Subject: hg: jigsaw/jigsaw/jdk: jdk.base missing requires optional service java.nio.file.spi.FileTypeDetector Message-ID: <20120507131345.E737D4718D@hg.openjdk.java.net> Changeset: bd170b081acf Author: alanb Date: 2012-05-07 14:10 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/bd170b081acf jdk.base missing requires optional service java.nio.file.spi.FileTypeDetector ! make/modules/jdk.depconfig From mandy.chung at oracle.com Mon May 7 09:34:14 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 07 May 2012 09:34:14 -0700 Subject: Example code in JDK8 requiring change for modular function In-Reply-To: References: <4FA67039.7040202@oracle.com> <4FA68800.8000307@oracle.com> <820C47B9-8110-4E93-AC47-39C2C87615FC@oracle.com> <4FA78A2D.6010005@oracle.com> Message-ID: <4FA7F986.50809@oracle.com> On 5/7/2012 1:52 AM, Paul Sandoz wrote: > So this is good example of where we could have two code paths based on a boolean check if running in module mode or not. It's good that you start looking into this example and others in JDK that will need to handle across the board. FYI. I added a few static methods in org.openjdk.jigsaw.Platform, part of the changes I posted [1]: http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/module-class-loading/webrev-jigsaw-ms/src/share/classes/org/openjdk/jigsaw/Platform.java.sdiff.html Mandy [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2012-May/002498.html From jaroslav.tulach at oracle.com Mon May 7 13:37:37 2012 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Mon, 07 May 2012 22:37:37 +0200 Subject: Resolver and inefficiencies In-Reply-To: <838B4257-8E67-4E75-832E-5BDA7689D408@rapicault.net> References: <3D72AF75-6027-4E82-89CD-E4A3F8D959AE@oracle.com> <838B4257-8E67-4E75-832E-5BDA7689D408@rapicault.net> Message-ID: <2999030.7Zj7shRsD3@logoutik> Dne ?t 3. kv?tna 2012 22:40:13, Paul Sandoz napsal(a): > >> This observation may already be known, but i thought i would throw this > >> out here anyway...> > > Yes, it's a known problem and the resolver needs work. There was an > > interesting thread between Jaroslav Tulach and Jeff Glick a few months > > ago on this topic. > OK, i will look through the archives. Hello Paul, the summary of my current understanding can be found here: http://wiki.apidesign.org/wiki/RangeDependenciesAnalysed Dne ?t 3. kv?tna 2012 17:03:40, Pascal Rapicault napsal(a): > Rather than > implementing a resolver from scratch, since the dependency problem is NP > complete (I assume the jigsaw also is), Hello Pascal, the second part of the above link seems to indicate that the NP completeness can be avoided for compile time/linkage dependencies - if the repository is constructed in incremental fashion. I am not however afraid that including "require service" dependencies will change the game and make it NP-complete again - as it breaks the incremental creation condition. I have no idea right now how the "require service" problem could be made less complex. > we have been using a SAT solver > (http://www.sat4j.org) and have been quite happy with it. It is very > efficient and scales very well. If my above worry is correct, a SAT solver may be needed. -jt From karen.kinnear at oracle.com Mon May 7 17:48:31 2012 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Mon, 7 May 2012 20:48:31 -0400 Subject: JDK support for VM to read classes from modules in a module library In-Reply-To: <4FA4CAF0.8000008@oracle.com> References: <4FA4CAF0.8000008@oracle.com> Message-ID: Webrev for the VM changes: http://cr.openjdk.java.net/~acorn/vm-module-class-loading/webrev/ VM code includes both class loading changes for base module loader, as well as incremental perfdata timer information to help us track detailed class loading performance. thanks, Karen On May 5, 2012, at 2:38 AM, Mandy Chung wrote: > Karen and I have been working on implementing the support in the VM and library to read classes from a module library in native and proper system initialization for modules. This will replace the current workaround of using bootclasspath in module mode. I have put together a set of slides [1] to give an overview of this work (thanks to Alex, Karen, and Alan for their feedback and improvements). > > This work includes several pieces: > 1) Jigsaw native library interface that the VM will use to search and read classes from the base module > > This replaces the existing mechanism in the VM that searches and reads classes from rt.jar and the default bootclasspath (that no longer exists in modular JDK) for loading bootstrap classes. > > Webrev for the jdk change: > http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/module-class-loading/webrev-jigsaw-ms/ > > Karen will send out the webrev for the VM change separately. > > The jigsaw native library interface is defined in jigsaw.h and its implementation is in jigsaw.c. The temporary hack in org.openjdk.jigsaw.BootLoader to extend the bootclasspath for the base and other modules is now removed. I have added a few static methods in the Platform class for the system to determine if it's running in module mode, if a given class loader defines system classes, and to get the base module loader (refer below for details). > > This webrev also includes some minor cleanup in the modularization such as fixing the jdk.desktop requires optional jdk.jaxp that should not be an optional dependency and moving java.text.Bidi class to the base module (Alan has eliminated the bidi to desktop dependency a while ago). > > 2) system modules to be granted with AllPermissions > > Today the classes on bootclasspath are granted with AllPermissions. In a modular JDK, we need to a way to determine if it's a system module and grants with AllPermission. Alan has implemented the module URL as the code source to modules and grants all permissions to jdk.* modules, as an interim solution. Sean is looking into different options and a reliable way to identify a system module. > > Webrev at: > http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/module-class-loading/webrev-module-url/ > > 3) The JDK code needs to be audit for the use of class loader and update for modules as listed in the open issues. We have made changes in a few places in the JDK to fix some of the low hanging fruits that get more of the existing tests to pass when running as modules. > > a. bootstrap classes skip permission check e.g. ClassLoader.getClassLoader() > > Today bootstrap classes are loaded by null loader. In module mode, system modules are loaded by non-null module loader. A method Platform.isPlatformLoader(ClassLoader) is added to replace the "cl == null" check. Note that these methods may be more appropriate to live in java.lang or some other class but I add it in Platform class for now. > > b. Platform.getBaseModuleLoader() - the base module loader is needed when the library > code wants to load a class in base's optional dependency (e.g XML) because Class.getClassLoader() currently returns null (see the open issue listed in [1]). > > c. replace classloader parameter in the Class.forName call from null to an appropriate loader when loading a class that is not in the base module (e.g. management, scripting, etc). > > Webrev: > http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/module-class-loading/webrev-class-loader-fix/ > > There will be more of this kind of changes required in the jdk and this is just to set a few examples to get going. > > You can also look at all changes together in this webrev: > http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/module-class-loading/webrev-all/ > > Thanks > Mandy > [1] http://openjdk.java.net/projects/jigsaw/doc/module-class-loading.pdf From david.holmes at oracle.com Tue May 8 00:22:48 2012 From: david.holmes at oracle.com (David Holmes) Date: Tue, 08 May 2012 17:22:48 +1000 Subject: JDK support for VM to read classes from modules in a module library In-Reply-To: References: <4FA4CAF0.8000008@oracle.com> Message-ID: <4FA8C9C8.9040002@oracle.com> Hi Karen, Skimming through ... In systemDictionary.cpp: 123 if (!HAS_PENDING_EXCEPTION && k != NULL) { 124 instanceKlassHandle ik(THREAD, k); 125 JavaValue result(T_OBJECT); 126 JavaCalls::call_static(&result, 127 ik, 128 vmSymbols::getBaseModuleLoader_name(), 129 vmSymbols::void_module_bootloader_signature(), 130 THREAD); 131 if (HAS_PENDING_EXCEPTION) { 132 UseModuleBootLoader = false; 133 CLEAR_PENDING_EXCEPTION; Should we have some kind of debug/trace/verbose hook here to see the exception from getBaseModuleLoader() ? David ----- On 8/05/2012 10:48 AM, Karen Kinnear wrote: > > Webrev for the VM changes: > http://cr.openjdk.java.net/~acorn/vm-module-class-loading/webrev/ > > VM code includes both class loading changes for base module loader, as well as incremental perfdata timer information > to help us track detailed class loading performance. > > thanks, > Karen > > On May 5, 2012, at 2:38 AM, Mandy Chung wrote: > >> Karen and I have been working on implementing the support in the VM and library to read classes from a module library in native and proper system initialization for modules. This will replace the current workaround of using bootclasspath in module mode. I have put together a set of slides [1] to give an overview of this work (thanks to Alex, Karen, and Alan for their feedback and improvements). >> >> This work includes several pieces: >> 1) Jigsaw native library interface that the VM will use to search and read classes from the base module >> >> This replaces the existing mechanism in the VM that searches and reads classes from rt.jar and the default bootclasspath (that no longer exists in modular JDK) for loading bootstrap classes. >> >> Webrev for the jdk change: >> http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/module-class-loading/webrev-jigsaw-ms/ >> >> Karen will send out the webrev for the VM change separately. >> >> The jigsaw native library interface is defined in jigsaw.h and its implementation is in jigsaw.c. The temporary hack in org.openjdk.jigsaw.BootLoader to extend the bootclasspath for the base and other modules is now removed. I have added a few static methods in the Platform class for the system to determine if it's running in module mode, if a given class loader defines system classes, and to get the base module loader (refer below for details). >> >> This webrev also includes some minor cleanup in the modularization such as fixing the jdk.desktop requires optional jdk.jaxp that should not be an optional dependency and moving java.text.Bidi class to the base module (Alan has eliminated the bidi to desktop dependency a while ago). >> >> 2) system modules to be granted with AllPermissions >> >> Today the classes on bootclasspath are granted with AllPermissions. In a modular JDK, we need to a way to determine if it's a system module and grants with AllPermission. Alan has implemented the module URL as the code source to modules and grants all permissions to jdk.* modules, as an interim solution. Sean is looking into different options and a reliable way to identify a system module. >> >> Webrev at: >> http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/module-class-loading/webrev-module-url/ >> >> 3) The JDK code needs to be audit for the use of class loader and update for modules as listed in the open issues. We have made changes in a few places in the JDK to fix some of the low hanging fruits that get more of the existing tests to pass when running as modules. >> >> a. bootstrap classes skip permission check e.g. ClassLoader.getClassLoader() >> >> Today bootstrap classes are loaded by null loader. In module mode, system modules are loaded by non-null module loader. A method Platform.isPlatformLoader(ClassLoader) is added to replace the "cl == null" check. Note that these methods may be more appropriate to live in java.lang or some other class but I add it in Platform class for now. >> >> b. Platform.getBaseModuleLoader() - the base module loader is needed when the library >> code wants to load a class in base's optional dependency (e.g XML) because Class.getClassLoader() currently returns null (see the open issue listed in [1]). >> >> c. replace classloader parameter in the Class.forName call from null to an appropriate loader when loading a class that is not in the base module (e.g. management, scripting, etc). >> >> Webrev: >> http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/module-class-loading/webrev-class-loader-fix/ >> >> There will be more of this kind of changes required in the jdk and this is just to set a few examples to get going. >> >> You can also look at all changes together in this webrev: >> http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/module-class-loading/webrev-all/ >> >> Thanks >> Mandy >> [1] http://openjdk.java.net/projects/jigsaw/doc/module-class-loading.pdf > From chris.hegarty at oracle.com Tue May 8 09:41:36 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 08 May 2012 17:41:36 +0100 Subject: Heads up, BDB coming, needed to support fast configuration Message-ID: <4FA94CC0.7000408@oracle.com> Hi, A while back it was pointed out that the configuration data for modules with entry points is stored in a highly inefficient manner [1]. It was pointed out at the time that the plan has always been to replace this with a "fast configuration", based on a persistent b-tree implementation. The b-tree implementation that we plan to use is a small footprint implementation of Berkeley DB [2], called Restricted Data Store (RDS). It is a minimal build of Berkeley DB that supports only b-tree access, and provides a simple Java interface to support the functionality required by the runtime (Jigsaw will also use the native interface). I'm currently preparing to push the BDB code to Jigsaw. It will live in its own repository, jigsaw/jigsaw/bdb. This mail is just a heads-up that this will be coming soon. Note that as BDB is provided in some distributions, Linux for example, the changes that are coming can use the installed BDB as an alternative. -Chris. [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2012-March/002292.html [2] http://www.oracle.com/technetwork/products/berkeleydb/overview/index.html From mandy.chung at oracle.com Tue May 8 13:54:40 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 08 May 2012 13:54:40 -0700 Subject: Review request to remove the launcher workaround for tools multiple entry points Message-ID: <4FA98810.3090509@oracle.com> We implemented a temporary workaround for the tools module to contain the multiple entry points [1]. Now with module views support [2], we can remove that workaround: http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/tools-launcher-fix/ This also includes a fix in the launcher that ignores CLASSPATH environment variable if set but -m is specified (launching a modular application). Thanks Mandy [1] http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/2661318d6cfe [2] http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/01d6b2c9d36d From david.holmes at oracle.com Tue May 8 22:15:21 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 09 May 2012 15:15:21 +1000 Subject: Querying module and module file contents Message-ID: <4FA9FD69.3090900@oracle.com> Given an installed module, or a jmod module file, how can I query: a) what types are exported by the module [file] b) what types are contained in the module [file] I want to validate that my module is getting everything packaged up correctly. Also am I right in thinking that the set of types in a module is not declared in the module-info, but simply controlled by the -i option to jpkg? (The module-info only declares exported types, not contained types) Thanks, David From Alan.Bateman at oracle.com Wed May 9 02:03:43 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 09 May 2012 10:03:43 +0100 Subject: Review request to remove the launcher workaround for tools multiple entry points In-Reply-To: <4FA98810.3090509@oracle.com> References: <4FA98810.3090509@oracle.com> Message-ID: <4FAA32EF.8070205@oracle.com> On 08/05/2012 21:54, Mandy Chung wrote: > We implemented a temporary workaround for the tools module to contain > the multiple entry points [1]. Now with module views support [2], > we can remove that workaround: > > http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/tools-launcher-fix/ > > This also includes a fix in the launcher that ignores CLASSPATH > environment variable if set but -m is specified (launching a modular > application). This looks good to me. A minor suggestion is the warning message may be clearer as "CLASSPATH environment variable ignored when -m specified". -Alan From Alan.Bateman at oracle.com Wed May 9 02:37:15 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 09 May 2012 10:37:15 +0100 Subject: Querying module and module file contents In-Reply-To: <4FA9FD69.3090900@oracle.com> References: <4FA9FD69.3090900@oracle.com> Message-ID: <4FAA3ACB.5090401@oracle.com> On 09/05/2012 06:15, David Holmes wrote: > Given an installed module, or a jmod module file, how can I query: > > a) what types are exported by the module [file] > b) what types are contained in the module [file] > > I want to validate that my module is getting everything packaged up > correctly. > > Also am I right in thinking that the set of types in a module is not > declared in the module-info, but simply controlled by the -i option to > jpkg? (The module-info only declares exported types, not contained types) If the module is installed then do you can use "jmod ls -v " and print out the module declaration, including the exports. It may not be exactly what you want as it doesn't print the complete list of contents and so doesn't print out the types that aren't exported, resources, native libraries, commands, etc. I can see how that could be useful and maybe something we should consider, perhaps with a different option. I could imagine an option to verify too, especially with modules that have files, commands for example, that aren't in the module library. As regards jpkg then it's the -m, --natlib, --config etc. commands that specify the actual content. In the case of classes then it will likely be more than the types exported by module. I think you're also asking if there is a way to examine the contents of a jmod module. I can see how this could be useful and maybe we could add something equivalent to dpkg-deb -show and -c. -Alan. From david.holmes at oracle.com Wed May 9 02:42:13 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 09 May 2012 19:42:13 +1000 Subject: Querying module and module file contents In-Reply-To: <4FAA3ACB.5090401@oracle.com> References: <4FA9FD69.3090900@oracle.com> <4FAA3ACB.5090401@oracle.com> Message-ID: <4FAA3BF5.6020707@oracle.com> On 9/05/2012 7:37 PM, Alan Bateman wrote: > On 09/05/2012 06:15, David Holmes wrote: >> Given an installed module, or a jmod module file, how can I query: >> >> a) what types are exported by the module [file] >> b) what types are contained in the module [file] >> >> I want to validate that my module is getting everything packaged up >> correctly. >> >> Also am I right in thinking that the set of types in a module is not >> declared in the module-info, but simply controlled by the -i option to >> jpkg? (The module-info only declares exported types, not contained types) > If the module is installed then do you can use "jmod ls -v " and > print out the module declaration, including the exports. It may not be > exactly what you want as it doesn't print the complete list of contents > and so doesn't print out the types that aren't exported, resources, > native libraries, commands, etc. I can see how that could be useful and > maybe something we should consider, perhaps with a different option. I > could imagine an option to verify too, especially with modules that have > files, commands for example, that aren't in the module library. Right - I really want a way to see the complete contents not just the exported interface. > As regards jpkg then it's the -m, --natlib, --config etc. commands that > specify the actual content. So what is the -i option for: -i, --include Directory of files to be included ??? > In the case of classes then it will likely > be more than the types exported by module. I think you're also asking if > there is a way to examine the contents of a jmod module. I can see how > this could be useful and maybe we could add something equivalent to > dpkg-deb -show and -c. Right. I've just created my jmod file and I want to check it contains what I expect it to. Thanks, David > -Alan. > > > > > > > From paul.sandoz at oracle.com Wed May 9 03:51:36 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 9 May 2012 12:51:36 +0200 Subject: Example code in JDK8 requiring change for modular function In-Reply-To: <4FA7F986.50809@oracle.com> References: <4FA67039.7040202@oracle.com> <4FA68800.8000307@oracle.com> <820C47B9-8110-4E93-AC47-39C2C87615FC@oracle.com> <4FA78A2D.6010005@oracle.com> <4FA7F986.50809@oracle.com> Message-ID: <3D56D481-469B-4308-ACC7-49E8FFF8E2F6@oracle.com> On May 7, 2012, at 6:34 PM, Mandy Chung wrote: > On 5/7/2012 1:52 AM, Paul Sandoz wrote: >> So this is good example of where we could have two code paths based on a boolean check if running in module mode or not. > > > It's good that you start looking into this example and others in JDK that > will need to handle across the board. FYI. I added a few static methods > in org.openjdk.jigsaw.Platform, part of the changes I posted [1]: > http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/module-class-loading/webrev-jigsaw-ms/src/share/classes/org/openjdk/jigsaw/Platform.java.sdiff.html > Thanks. To do general changes in JDK8 we will have to provide some of those static methods, say in a class in sun.misc as a temporary solution until Jigsaw is merged back. e.g. package sun.misc; // This class will be removed after the Jigsaw code base is pushed to JDK8 and classes that depend on this class // and its methods will be updated to utilize the equivalent Jigsaw functionality public class Platform { public static boolean isModuleMode() { return false; } } Paul. > Mandy > > [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2012-May/002498.html > From paul.sandoz at oracle.com Wed May 9 05:27:15 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 9 May 2012 14:27:15 +0200 Subject: Querying module and module file contents In-Reply-To: <4FAA3BF5.6020707@oracle.com> References: <4FA9FD69.3090900@oracle.com> <4FAA3ACB.5090401@oracle.com> <4FAA3BF5.6020707@oracle.com> Message-ID: On May 9, 2012, at 11:42 AM, David Holmes wrote: > >> As regards jpkg then it's the -m, --natlib, --config etc. commands that >> specify the actual content. > > So what is the -i option for: > > -i, --include Directory of files to be included > > ??? > AFAICT from looking at the code this option is only used when creating a debian package. It copies the contents of the included directory into a temporary directory from which the the debian package is built from (see the dpkg-deb --build option). Not being that familiar with debian packaging i have no idea where those files would be extracted to when installing. Paul. From chris.hegarty at oracle.com Wed May 9 07:31:32 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 09 May 2012 15:31:32 +0100 Subject: RFR: jmod remove In-Reply-To: <4FA1437C.6090604@oracle.com> References: <4F8FD138.9080505@oracle.com> <4F8FFC6A.9010502@oracle.com> <4F996BEB.3050706@oracle.com> <4F996FBC.3080406@oracle.com> <4F997543.8070709@oracle.com> <4F9F02A7.9020604@oracle.com> <4FA1437C.6090604@oracle.com> Message-ID: <4FAA7FC4.5050101@oracle.com> Alan, I finally got back to this. Comments inline... Updated webrev: http://cr.openjdk.java.net/~chegar/jigsaw/jmodrm.05/webrev/ > comment on moduleTrashDir is that it duplicates the logic for temporary > directories and maybe it would be simper to use use > Files.createTempDirectory to create a directory in the trash directory. Right, there was an error in my initial change, we only want to generate a unique name here not actually create the directory. If the directory is created there could be a problem when doing the move. I encountered this on some Windows systems. I retained the logic ( same as createTempDirectory ) to generate the name, but it could use UUID or similar. > A few minor comments: > > Library.java defines the mids parameter, not not the dry parameter. Got it, thanks. > SimpleLibrary.remove, you can use try-with-resources at L1501. Done. > checkRootsRequire - I wonder if we can find a better name for this > method, the logic seems right and should work for service usage too but > the name of the method seems a bit odd. Maybe > ensureNotPresentInConfiguration or something short? I went with ensureNotInConfiguration. > Just on consistency of naming, then with the change then Files defines > both deleteTree and deleteAllUnchecked to do a recursive delete which > seems a bit inconsistent. I renamed this to deleteTreeUnchecked. I kept deleteTreeUnchecked as it makes more of an effort to actually delete all the files. Eventually, I think we should remove deleteTree and replace it with deleteTreeUnchecked, but this could be done separately as there may be more discussion around it. > Shouldn't Files. deleteUnchecked just return any exception thrown by > delete rather than dropping the useful exception that delete throws? Reverted to Files.delete and catch the exception. > Nothing really to do with this patch but ModuleFile.remove(File) could > use Files.readAllLines which would remove much of the code. Thanks, done. -Chris. > Aside from a bit of clean-up then I think this will be great to have > (and urgently needed now because %mids means that we can't rm modules > anymore). > > -Alan > From chris.hegarty at oracle.com Wed May 9 07:35:50 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 09 May 2012 15:35:50 +0100 Subject: RFR: jmod remove In-Reply-To: <4FAA7FC4.5050101@oracle.com> References: <4F8FD138.9080505@oracle.com> <4F8FFC6A.9010502@oracle.com> <4F996BEB.3050706@oracle.com> <4F996FBC.3080406@oracle.com> <4F997543.8070709@oracle.com> <4F9F02A7.9020604@oracle.com> <4FA1437C.6090604@oracle.com> <4FAA7FC4.5050101@oracle.com> Message-ID: <4FAA80C6.8010708@oracle.com> just to add... I extended the test to cover the case of content installed outside the module library, and there some issues with newline/whitespace in the output of 'jmod ls' causing problem on Cygwin. The test should be bullet proof now! -Chris. On 09/05/12 15:31, Chris Hegarty wrote: > Alan, > > I finally got back to this. Comments inline... > > Updated webrev: > http://cr.openjdk.java.net/~chegar/jigsaw/jmodrm.05/webrev/ > >> comment on moduleTrashDir is that it duplicates the logic for temporary >> directories and maybe it would be simper to use use >> Files.createTempDirectory to create a directory in the trash directory. > > Right, there was an error in my initial change, we only want to generate > a unique name here not actually create the directory. If the directory > is created there could be a problem when doing the move. I encountered > this on some Windows systems. > > I retained the logic ( same as createTempDirectory ) to generate the > name, but it could use UUID or similar. > >> A few minor comments: >> >> Library.java defines the mids parameter, not not the dry parameter. > > Got it, thanks. > >> SimpleLibrary.remove, you can use try-with-resources at L1501. > > Done. > >> checkRootsRequire - I wonder if we can find a better name for this >> method, the logic seems right and should work for service usage too but >> the name of the method seems a bit odd. Maybe >> ensureNotPresentInConfiguration or something short? > > I went with ensureNotInConfiguration. > >> Just on consistency of naming, then with the change then Files defines >> both deleteTree and deleteAllUnchecked to do a recursive delete which >> seems a bit inconsistent. > > I renamed this to deleteTreeUnchecked. I kept deleteTreeUnchecked as it > makes more of an effort to actually delete all the files. Eventually, I > think we should remove deleteTree and replace it with > deleteTreeUnchecked, but this could be done separately as there may be > more discussion around it. > >> Shouldn't Files. deleteUnchecked just return any exception thrown by >> delete rather than dropping the useful exception that delete throws? > > Reverted to Files.delete and catch the exception. > >> Nothing really to do with this patch but ModuleFile.remove(File) could >> use Files.readAllLines which would remove much of the code. > > Thanks, done. > > -Chris. > >> Aside from a bit of clean-up then I think this will be great to have >> (and urgently needed now because %mids means that we can't rm modules >> anymore). >> >> -Alan >> From paul.sandoz at oracle.com Wed May 9 08:44:56 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 9 May 2012 17:44:56 +0200 Subject: JDK support for VM to read classes from modules in a module library In-Reply-To: <4FA4CAF0.8000008@oracle.com> References: <4FA4CAF0.8000008@oracle.com> Message-ID: <4451731B-6CC9-479D-8F9C-5888D3EF235C@oracle.com> Hi Mandy, Regarding the change to com/sun/jmx/mbeanserver/MXBeanMapping.java: 172 return Class.forName(className, false, MXBeanMapping.class.getClassLoader()); Do you think it would make sense to add the following method to Class: public static Class forName(String className, boolean initialize) { return forName0(className, initialize, ClassLoader.getCallerClassLoader()); } there by removing the explicit reference to the class loader in MXBeanMapping.java. It intuitively feels like a best practice to reduce the cases of explicitly dealing with a class loader. The change to java/lang/management/PlatformComponent.java from: 366 Class.forName(mxbeanInterfaceName, false, null); to: 367 Class.forName(mxbeanInterfaceName); changes the initialization [*] flag from false to true. Is that intended? Paul. [*] i must admit to never quite understanding what this flag means. Java doc states that for initialize parameter "whether the class must be initialized". Is that a constraint or an action? I presume the later. On May 5, 2012, at 8:38 AM, Mandy Chung wrote: > Karen and I have been working on implementing the support in the VM and library to read classes from a module library in native and proper system initialization for modules. This will replace the current workaround of using bootclasspath in module mode. I have put together a set of slides [1] to give an overview of this work (thanks to Alex, Karen, and Alan for their feedback and improvements). > > This work includes several pieces: > 1) Jigsaw native library interface that the VM will use to search and read classes from the base module > > This replaces the existing mechanism in the VM that searches and reads classes from rt.jar and the default bootclasspath (that no longer exists in modular JDK) for loading bootstrap classes. > > Webrev for the jdk change: > http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/module-class-loading/webrev-jigsaw-ms/ > > Karen will send out the webrev for the VM change separately. > > The jigsaw native library interface is defined in jigsaw.h and its implementation is in jigsaw.c. The temporary hack in org.openjdk.jigsaw.BootLoader to extend the bootclasspath for the base and other modules is now removed. I have added a few static methods in the Platform class for the system to determine if it's running in module mode, if a given class loader defines system classes, and to get the base module loader (refer below for details). > > This webrev also includes some minor cleanup in the modularization such as fixing the jdk.desktop requires optional jdk.jaxp that should not be an optional dependency and moving java.text.Bidi class to the base module (Alan has eliminated the bidi to desktop dependency a while ago). > > 2) system modules to be granted with AllPermissions > > Today the classes on bootclasspath are granted with AllPermissions. In a modular JDK, we need to a way to determine if it's a system module and grants with AllPermission. Alan has implemented the module URL as the code source to modules and grants all permissions to jdk.* modules, as an interim solution. Sean is looking into different options and a reliable way to identify a system module. > > Webrev at: > http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/module-class-loading/webrev-module-url/ > > 3) The JDK code needs to be audit for the use of class loader and update for modules as listed in the open issues. We have made changes in a few places in the JDK to fix some of the low hanging fruits that get more of the existing tests to pass when running as modules. > > a. bootstrap classes skip permission check e.g. ClassLoader.getClassLoader() > > Today bootstrap classes are loaded by null loader. In module mode, system modules are loaded by non-null module loader. A method Platform.isPlatformLoader(ClassLoader) is added to replace the "cl == null" check. Note that these methods may be more appropriate to live in java.lang or some other class but I add it in Platform class for now. > > b. Platform.getBaseModuleLoader() - the base module loader is needed when the library > code wants to load a class in base's optional dependency (e.g XML) because Class.getClassLoader() currently returns null (see the open issue listed in [1]). > > c. replace classloader parameter in the Class.forName call from null to an appropriate loader when loading a class that is not in the base module (e.g. management, scripting, etc). > > Webrev: > http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/module-class-loading/webrev-class-loader-fix/ > > There will be more of this kind of changes required in the jdk and this is just to set a few examples to get going. > > You can also look at all changes together in this webrev: > http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/module-class-loading/webrev-all/ > > Thanks > Mandy > [1] http://openjdk.java.net/projects/jigsaw/doc/module-class-loading.pdf From vitalyd at gmail.com Wed May 9 08:53:49 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 9 May 2012 11:53:49 -0400 Subject: JDK support for VM to read classes from modules in a module library In-Reply-To: <4451731B-6CC9-479D-8F9C-5888D3EF235C@oracle.com> References: <4FA4CAF0.8000008@oracle.com> <4451731B-6CC9-479D-8F9C-5888D3EF235C@oracle.com> Message-ID: Hi Paul, That flag is an action, as you state. Basically means whether static initialization should be performed. Vitaly Sent from my phone On May 9, 2012 11:43 AM, "Paul Sandoz" wrote: > Hi Mandy, > > Regarding the change to com/sun/jmx/mbeanserver/MXBeanMapping.java: > > 172 return Class.forName(className, false, > MXBeanMapping.class.getClassLoader()); > > Do you think it would make sense to add the following method to Class: > > public static Class forName(String className, boolean initialize) { > return forName0(className, initialize, > ClassLoader.getCallerClassLoader()); > } > > there by removing the explicit reference to the class loader in > MXBeanMapping.java. It intuitively feels like a best practice to reduce the > cases of explicitly dealing with a class loader. > > > > The change to java/lang/management/PlatformComponent.java from: > > 366 Class.forName(mxbeanInterfaceName, false, > null); > > to: > > 367 Class.forName(mxbeanInterfaceName); > > changes the initialization [*] flag from false to true. Is that intended? > > Paul. > > [*] i must admit to never quite understanding what this flag means. > Java doc states that for initialize parameter "whether the class must be > initialized". Is that a constraint or an action? I presume the later. > > > On May 5, 2012, at 8:38 AM, Mandy Chung wrote: > > > Karen and I have been working on implementing the support in the VM and > library to read classes from a module library in native and proper system > initialization for modules. This will replace the current workaround of > using bootclasspath in module mode. I have put together a set of slides > [1] to give an overview of this work (thanks to Alex, Karen, and Alan for > their feedback and improvements). > > > > This work includes several pieces: > > 1) Jigsaw native library interface that the VM will use to search and > read classes from the base module > > > > This replaces the existing mechanism in the VM that searches and reads > classes from rt.jar and the default bootclasspath (that no longer exists in > modular JDK) for loading bootstrap classes. > > > > Webrev for the jdk change: > > > http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/module-class-loading/webrev-jigsaw-ms/ > > > > Karen will send out the webrev for the VM change separately. > > > > The jigsaw native library interface is defined in jigsaw.h and its > implementation is in jigsaw.c. The temporary hack in > org.openjdk.jigsaw.BootLoader to extend the bootclasspath for the base and > other modules is now removed. I have added a few static methods in the > Platform class for the system to determine if it's running in module mode, > if a given class loader defines system classes, and to get the base module > loader (refer below for details). > > > > This webrev also includes some minor cleanup in the modularization such > as fixing the jdk.desktop requires optional jdk.jaxp that should not be an > optional dependency and moving java.text.Bidi class to the base module > (Alan has eliminated the bidi to desktop dependency a while ago). > > > > 2) system modules to be granted with AllPermissions > > > > Today the classes on bootclasspath are granted with AllPermissions. In > a modular JDK, we need to a way to determine if it's a system module and > grants with AllPermission. Alan has implemented the module URL as the code > source to modules and grants all permissions to jdk.* modules, as an > interim solution. Sean is looking into different options and a reliable > way to identify a system module. > > > > Webrev at: > > > http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/module-class-loading/webrev-module-url/ > > > > 3) The JDK code needs to be audit for the use of class loader and update > for modules as listed in the open issues. We have made changes in a few > places in the JDK to fix some of the low hanging fruits that get more of > the existing tests to pass when running as modules. > > > > a. bootstrap classes skip permission check e.g. > ClassLoader.getClassLoader() > > > > Today bootstrap classes are loaded by null loader. In module mode, > system modules are loaded by non-null module loader. A method > Platform.isPlatformLoader(ClassLoader) is added to replace the "cl == null" > check. Note that these methods may be more appropriate to live in > java.lang or some other class but I add it in Platform class for now. > > > > b. Platform.getBaseModuleLoader() - the base module loader is needed > when the library > > code wants to load a class in base's optional dependency (e.g XML) > because Class.getClassLoader() currently returns null (see the open issue > listed in [1]). > > > > c. replace classloader parameter in the Class.forName call from null to > an appropriate loader when loading a class that is not in the base module > (e.g. management, scripting, etc). > > > > Webrev: > > > http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/module-class-loading/webrev-class-loader-fix/ > > > > There will be more of this kind of changes required in the jdk and this > is just to set a few examples to get going. > > > > You can also look at all changes together in this webrev: > > > http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/module-class-loading/webrev-all/ > > > > Thanks > > Mandy > > [1] http://openjdk.java.net/projects/jigsaw/doc/module-class-loading.pdf > > From mandy.chung at oracle.com Wed May 9 09:52:45 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 09 May 2012 09:52:45 -0700 Subject: JDK support for VM to read classes from modules in a module library In-Reply-To: <4451731B-6CC9-479D-8F9C-5888D3EF235C@oracle.com> References: <4FA4CAF0.8000008@oracle.com> <4451731B-6CC9-479D-8F9C-5888D3EF235C@oracle.com> Message-ID: <4FAAA0DD.5010909@oracle.com> Hi Paul, On 5/9/2012 8:44 AM, Paul Sandoz wrote: > Hi Mandy, > > Regarding the change to com/sun/jmx/mbeanserver/MXBeanMapping.java: > > 172 return Class.forName(className, false, MXBeanMapping.class.getClassLoader()); > > Do you think it would make sense to add the following method to Class: > > public static Class forName(String className, boolean initialize) { > return forName0(className, initialize, ClassLoader.getCallerClassLoader()); > } > > there by removing the explicit reference to the class loader in MXBeanMapping.java. It intuitively feels like a best practice to reduce the cases of explicitly dealing with a class loader. That's a good observation and this new convenient method may be useful (and less to type). One thing I'm not sure about is how common application code calls Class.forName(String, boolean, ClassLoader) with the "initialize" parameter be false. i.e. the case when we only want a class to be loaded but not to call its static initializer. I think it'd be useful to find out how existing code uses Class.forName as additional data to determine if it's worth adding this new convenient method. BTW, I have been talking with Jon to find out the usage of "null" class loader from corpus. I can also gather Class.forName usage and send it to you. > > > The change to java/lang/management/PlatformComponent.java from: > > 366 Class.forName(mxbeanInterfaceName, false, null); > > to: > > 367 Class.forName(mxbeanInterfaceName); > > changes the initialization [*] flag from false to true. Is that intended? mxbeanInterfaceName is an interface which does not have . This change doesn't cause any difference. > > Paul. > > [*] i must admit to never quite understanding what this flag means. > Java doc states that for initialize parameter "whether the class must be initialized". Is that a constraint or an action? I presume the later. Yes, the later - that indicates whether the class static initializer will be invoked or not. Mandy > > On May 5, 2012, at 8:38 AM, Mandy Chung wrote: > >> Karen and I have been working on implementing the support in the VM and library to read classes from a module library in native and proper system initialization for modules. This will replace the current workaround of using bootclasspath in module mode. I have put together a set of slides [1] to give an overview of this work (thanks to Alex, Karen, and Alan for their feedback and improvements). >> >> This work includes several pieces: >> 1) Jigsaw native library interface that the VM will use to search and read classes from the base module >> >> This replaces the existing mechanism in the VM that searches and reads classes from rt.jar and the default bootclasspath (that no longer exists in modular JDK) for loading bootstrap classes. >> >> Webrev for the jdk change: >> http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/module-class-loading/webrev-jigsaw-ms/ >> >> Karen will send out the webrev for the VM change separately. >> >> The jigsaw native library interface is defined in jigsaw.h and its implementation is in jigsaw.c. The temporary hack in org.openjdk.jigsaw.BootLoader to extend the bootclasspath for the base and other modules is now removed. I have added a few static methods in the Platform class for the system to determine if it's running in module mode, if a given class loader defines system classes, and to get the base module loader (refer below for details). >> >> This webrev also includes some minor cleanup in the modularization such as fixing the jdk.desktop requires optional jdk.jaxp that should not be an optional dependency and moving java.text.Bidi class to the base module (Alan has eliminated the bidi to desktop dependency a while ago). >> >> 2) system modules to be granted with AllPermissions >> >> Today the classes on bootclasspath are granted with AllPermissions. In a modular JDK, we need to a way to determine if it's a system module and grants with AllPermission. Alan has implemented the module URL as the code source to modules and grants all permissions to jdk.* modules, as an interim solution. Sean is looking into different options and a reliable way to identify a system module. >> >> Webrev at: >> http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/module-class-loading/webrev-module-url/ >> >> 3) The JDK code needs to be audit for the use of class loader and update for modules as listed in the open issues. We have made changes in a few places in the JDK to fix some of the low hanging fruits that get more of the existing tests to pass when running as modules. >> >> a. bootstrap classes skip permission check e.g. ClassLoader.getClassLoader() >> >> Today bootstrap classes are loaded by null loader. In module mode, system modules are loaded by non-null module loader. A method Platform.isPlatformLoader(ClassLoader) is added to replace the "cl == null" check. Note that these methods may be more appropriate to live in java.lang or some other class but I add it in Platform class for now. >> >> b. Platform.getBaseModuleLoader() - the base module loader is needed when the library >> code wants to load a class in base's optional dependency (e.g XML) because Class.getClassLoader() currently returns null (see the open issue listed in [1]). >> >> c. replace classloader parameter in the Class.forName call from null to an appropriate loader when loading a class that is not in the base module (e.g. management, scripting, etc). >> >> Webrev: >> http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/module-class-loading/webrev-class-loader-fix/ >> >> There will be more of this kind of changes required in the jdk and this is just to set a few examples to get going. >> >> You can also look at all changes together in this webrev: >> http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/module-class-loading/webrev-all/ >> >> Thanks >> Mandy >> [1] http://openjdk.java.net/projects/jigsaw/doc/module-class-loading.pdf From mandy.chung at oracle.com Wed May 9 09:55:56 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 09 May 2012 09:55:56 -0700 Subject: Review request to remove the launcher workaround for tools multiple entry points In-Reply-To: <4FAA32EF.8070205@oracle.com> References: <4FA98810.3090509@oracle.com> <4FAA32EF.8070205@oracle.com> Message-ID: <4FAAA19C.8080101@oracle.com> On 5/9/2012 2:03 AM, Alan Bateman wrote: > This looks good to me. A minor suggestion is the warning message may > be clearer as "CLASSPATH environment variable ignored when -m specified". Thanks for the review. I revised the warning message. Mandy From mandy.chung at oracle.com Wed May 9 10:01:43 2012 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 09 May 2012 17:01:43 +0000 Subject: hg: jigsaw/jigsaw/jdk: Remove the launcher workaround to support multiple entry points for jdk tools Message-ID: <20120509170203.06531471F4@hg.openjdk.java.net> Changeset: ed76e61bfe48 Author: mchung Date: 2012-05-09 10:01 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/ed76e61bfe48 Remove the launcher workaround to support multiple entry points for jdk tools Reviewed-by: alanb ! make/launchers/Makefile ! make/sun/rmi/registry/Makefile ! make/sun/rmi/rmid/Makefile ! make/sun/security/krb5/Makefile ! src/share/bin/emessages.h ! src/share/bin/java.c ! src/share/classes/sun/launcher/LauncherHelper.java From mandy.chung at oracle.com Wed May 9 10:16:10 2012 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 09 May 2012 17:16:10 +0000 Subject: hg: jigsaw/jigsaw/jdk: Remove sajdi.gui from modules.config to workaround missing libsaproc.so issue Message-ID: <20120509171620.E4B12471F5@hg.openjdk.java.net> Changeset: e19ea510cad3 Author: mchung Date: 2012-05-09 10:16 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/e19ea510cad3 Remove sajdi.gui from modules.config to workaround missing libsaproc.so issue ! make/modules/modules.config From forax at univ-mlv.fr Wed May 9 10:29:08 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 09 May 2012 19:29:08 +0200 Subject: JDK support for VM to read classes from modules in a module library In-Reply-To: <4FAAA0DD.5010909@oracle.com> References: <4FA4CAF0.8000008@oracle.com> <4451731B-6CC9-479D-8F9C-5888D3EF235C@oracle.com> <4FAAA0DD.5010909@oracle.com> Message-ID: <4FAAA964.5010803@univ-mlv.fr> On 05/09/2012 06:52 PM, Mandy Chung wrote: > Hi Paul, > > On 5/9/2012 8:44 AM, Paul Sandoz wrote: >> Hi Mandy, >> >> Regarding the change to com/sun/jmx/mbeanserver/MXBeanMapping.java: >> >> 172 return Class.forName(className, false, >> MXBeanMapping.class.getClassLoader()); >> >> Do you think it would make sense to add the following method to Class: >> >> public static Class forName(String className, boolean >> initialize) { >> return forName0(className, initialize, >> ClassLoader.getCallerClassLoader()); >> } >> >> there by removing the explicit reference to the class loader in >> MXBeanMapping.java. It intuitively feels like a best practice to >> reduce the cases of explicitly dealing with a class loader. > > That's a good observation and this new convenient method may be useful > (and less to type). One thing I'm not sure about is how common > application code calls Class.forName(String, boolean, ClassLoader) > with the "initialize" parameter be false. i.e. the case when we only > want a class to be loaded but not to call its static initializer. I > think it'd be useful to find out how existing code uses Class.forName > as additional data to determine if it's worth adding this new > convenient method. BTW, I have been talking with Jon to find out the > usage of "null" class loader from corpus. I can also gather > Class.forName usage and send it to you. In fact, this method is really useful, most of the tools that does bytecode transformation at runtime (most O/R mappers, dynamic language runtimes, profilers, code coverage tools, etc) are now required to compute the stack frame attribute which requires to compute the lower upper bound of a set of types. For that, being able to crawle the type hierachy without loading the static initializer is a must have. > >> >> >> The change to java/lang/management/PlatformComponent.java from: >> >> 366 Class.forName(mxbeanInterfaceName, >> false, null); >> >> to: >> >> 367 Class.forName(mxbeanInterfaceName); >> >> changes the initialization [*] flag from false to true. Is that >> intended? > > mxbeanInterfaceName is an interface which does not have . > This change doesn't cause any > difference. interfaces can have a if you initialize a static final field that store something which is not a primitive type or a String, e.g. an ArrayList. > >> >> Paul. >> >> [*] i must admit to never quite understanding what this flag means. >> Java doc states that for initialize parameter "whether the class must >> be initialized". Is that a constraint or an action? I presume the later. > > Yes, the later - that indicates whether the class static initializer > will be invoked or not. > > Mandy R?mi From mandy.chung at oracle.com Wed May 9 11:11:56 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 09 May 2012 11:11:56 -0700 Subject: JDK support for VM to read classes from modules in a module library In-Reply-To: <4FAAA964.5010803@univ-mlv.fr> References: <4FA4CAF0.8000008@oracle.com> <4451731B-6CC9-479D-8F9C-5888D3EF235C@oracle.com> <4FAAA0DD.5010909@oracle.com> <4FAAA964.5010803@univ-mlv.fr> Message-ID: <4FAAB36C.40807@oracle.com> On 5/9/2012 10:29 AM, R?mi Forax wrote: > > In fact, this method is really useful, most of the tools that does > bytecode transformation at runtime > (most O/R mappers, dynamic language runtimes, profilers, code coverage > tools, etc) > are now required to compute the stack frame attribute which requires > to compute the lower upper bound > of a set of types. For that, being able to crawle the type hierachy > without loading the static initializer > is a must have. Thanks for the information, Remi. In this case, the tool itself does the Class.forName, right? i.e. the caller's class loader is the tool's class loader. Bytecode transformation for modules is one area being investigated. In modules, the tool that does bytecode instrumentation would be loaded by a separate loader and it wants to load classes being instrumented without invoking the static initializer. The key is that the tool module needs the ability to see the types in the modules being instrumented which is yet to be determined. In any case, this is a good example that the new convenient method could help and simplify the code. > interfaces can have a if you initialize a static final field > that store something which is not > a primitive type or a String, e.g. an ArrayList Good point. I was looking at the current list of platform MXBean interfaces (the ones that PlatformComponent class supports). Since we can't (shouldn't) restrict any future mxbean interface to have a static initializer, I should revert this line and keep the initialize parameter to false. Mandy From david.lloyd at redhat.com Wed May 9 11:22:06 2012 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 09 May 2012 13:22:06 -0500 Subject: A discussion about real-world modularity Message-ID: <4FAAB5CE.9020809@redhat.com> Some of you might find this interesting: http://lists.jboss.org/pipermail/jboss-as7-dev/2012-May/005974.html It's a discussion of how real modularity implementations impact real applications and real frameworks which actually exist in the real world today. I'm sure it will prove to be an elucidating discussion, what with its overall shading of reality. -- - DML From chris.hegarty at oracle.com Thu May 10 01:47:03 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 10 May 2012 09:47:03 +0100 Subject: Querying module and module file contents In-Reply-To: <4FAA3BF5.6020707@oracle.com> References: <4FA9FD69.3090900@oracle.com> <4FAA3ACB.5090401@oracle.com> <4FAA3BF5.6020707@oracle.com> Message-ID: <4FAB8087.5040006@oracle.com> On 09/05/2012 10:42, David Holmes wrote: > .... >> In the case of classes then it will likely >> be more than the types exported by module. I think you're also asking if >> there is a way to examine the contents of a jmod module. I can see how >> this could be useful and maybe we could add something equivalent to >> dpkg-deb -show and -c. > > Right. I've just created my jmod file and I want to check it contains > what I expect it to. I've been looking at the jpkg code recently. I'll add this to my list, should be straight forward ( and a really useful addition ). Thanks, -Chris. > > Thanks, > David > >> -Alan. >> >> >> >> >> >> >> From paul.sandoz at oracle.com Thu May 10 01:49:43 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 10 May 2012 10:49:43 +0200 Subject: JDK support for VM to read classes from modules in a module library In-Reply-To: <4FAAA0DD.5010909@oracle.com> References: <4FA4CAF0.8000008@oracle.com> <4451731B-6CC9-479D-8F9C-5888D3EF235C@oracle.com> <4FAAA0DD.5010909@oracle.com> Message-ID: <184F3619-A0A5-4AE1-85BC-D3B35C31B279@oracle.com> On May 9, 2012, at 6:52 PM, Mandy Chung wrote: > Hi Paul, > > On 5/9/2012 8:44 AM, Paul Sandoz wrote: >> Hi Mandy, >> >> Regarding the change to com/sun/jmx/mbeanserver/MXBeanMapping.java: >> >> 172 return Class.forName(className, false, MXBeanMapping.class.getClassLoader()); >> >> Do you think it would make sense to add the following method to Class: >> >> public static Class forName(String className, boolean initialize) { >> return forName0(className, initialize, ClassLoader.getCallerClassLoader()); >> } >> >> there by removing the explicit reference to the class loader in MXBeanMapping.java. It intuitively feels like a best practice to reduce the cases of explicitly dealing with a class loader. > > That's a good observation and this new convenient method may be useful (and less to type). One thing I'm not sure about is how common application code calls Class.forName(String, boolean, ClassLoader) with the "initialize" parameter be false. i.e. the case when we only want a class to be loaded but not to call its static initializer. I think it'd be useful to find out how existing code uses Class.forName as additional data to determine if it's worth adding this new convenient method. OK. > BTW, I have been talking with Jon to find out the usage of "null" class loader from corpus. I hope the usage of that is low. > I can also gather Class.forName usage and send it to you. > Please. (Note: NetBeans is quite fast on the JDK code base now for method use search.) It is clear from looking at the changes to some areas you made (and my comprehension of "initialize") that this is an area often misunderstood (e.g. passing String.class.getClassLoader() to Class.forName). >> >> >> The change to java/lang/management/PlatformComponent.java from: >> >> 366 Class.forName(mxbeanInterfaceName, false, null); >> >> to: >> >> 367 Class.forName(mxbeanInterfaceName); >> >> changes the initialization [*] flag from false to true. Is that intended? > > mxbeanInterfaceName is an interface which does not have . This change doesn't cause any > difference. > Ah! >> >> Paul. >> >> [*] i must admit to never quite understanding what this flag means. >> Java doc states that for initialize parameter "whether the class must be initialized". Is that a constraint or an action? I presume the later. > > Yes, the later - that indicates whether the class static initializer will be invoked or not. > Could we update the JavaDoc :-) @param initialize if true the class will be initialized (specifically the class static initializer will be invoked) [refer to errors on initialization], otherwise the class is not initialized [refer to when it will be initialized]. Thanks, Paul. From david.holmes at oracle.com Thu May 10 02:36:05 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 10 May 2012 19:36:05 +1000 Subject: JDK support for VM to read classes from modules in a module library In-Reply-To: <184F3619-A0A5-4AE1-85BC-D3B35C31B279@oracle.com> References: <4FA4CAF0.8000008@oracle.com> <4451731B-6CC9-479D-8F9C-5888D3EF235C@oracle.com> <4FAAA0DD.5010909@oracle.com> <184F3619-A0A5-4AE1-85BC-D3B35C31B279@oracle.com> Message-ID: <4FAB8C05.1040103@oracle.com> On 10/05/2012 6:49 PM, Paul Sandoz wrote: > On May 9, 2012, at 6:52 PM, Mandy Chung wrote: >>> [*] i must admit to never quite understanding what this flag means. >>> Java doc states that for initialize parameter "whether the class must be initialized". Is that a constraint or an action? I presume the later. >> >> Yes, the later - that indicates whether the class static initializer will be invoked or not. >> > > Could we update the JavaDoc :-) > > @param initialize if true the class will be initialized (specifically the class static initializer will be invoked) [refer to errors on initialization], otherwise the class is not initialized [refer to when it will be initialized]. A better update in my opinion would be to simply say: @param initialize if true the class will be initialized - see JLS 12.4 Seriously, anyone using API's for explicit class loading should have read about classloading and initialization - we're doing them a favour by pointing them to the JLS if they don't understand what class initialization is. David ----- > Thanks, > Paul. From paul.sandoz at oracle.com Thu May 10 02:51:39 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 10 May 2012 11:51:39 +0200 Subject: JDK support for VM to read classes from modules in a module library In-Reply-To: <4FAB8C05.1040103@oracle.com> References: <4FA4CAF0.8000008@oracle.com> <4451731B-6CC9-479D-8F9C-5888D3EF235C@oracle.com> <4FAAA0DD.5010909@oracle.com> <184F3619-A0A5-4AE1-85BC-D3B35C31B279@oracle.com> <4FAB8C05.1040103@oracle.com> Message-ID: <38831281-6D80-4A5C-AFBC-BC72DEB959BA@oracle.com> On May 10, 2012, at 11:36 AM, David Holmes wrote: > On 10/05/2012 6:49 PM, Paul Sandoz wrote: >> On May 9, 2012, at 6:52 PM, Mandy Chung wrote: >>>> [*] i must admit to never quite understanding what this flag means. >>>> Java doc states that for initialize parameter "whether the class must be initialized". Is that a constraint or an action? I presume the later. >>> >>> Yes, the later - that indicates whether the class static initializer will be invoked or not. >>> >> >> Could we update the JavaDoc :-) >> >> @param initialize if true the class will be initialized (specifically the class static initializer will be invoked) [refer to errors on initialization], otherwise the class is not initialized [refer to when it will be initialized]. > > A better update in my opinion would be to simply say: > > @param initialize if true the class will be initialized - see JLS 12.4 > > Seriously, anyone using API's for explicit class loading should have read about classloading and initialization - In an ideal world yes, in the real world most developers don't. I agree pointing to the JLS is a good idea. > we're doing them a favour by pointing them to the JLS if they don't understand what class initialization is. > IMO "favor" is the wrong perspective to look at this. It costs us very little to write some helpful sentence or two (plus a strong recommendation to read relevant JLS section) and it can go a long way to aid developers understanding and reduce errors without requiring them to wade into the JLS. Paul. From Alan.Bateman at oracle.com Thu May 10 04:17:22 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 10 May 2012 12:17:22 +0100 Subject: Preview builds of Jigsaw available Message-ID: <4FABA3C2.2010303@oracle.com> We now have a download page on java.net to host preview builds from Oracle: http://jdk8.java.net/jigsaw/ This should be useful to those that want to try out Project Jigsaw and/or the current prototype of the modular JDK without needing to build it themselves. The preview builds come in two forms: - "JDK modules image". This is essentially equivalent to the normal JDK download except that everything is pre-installed as modules. - The other download choice is for those that wish to experiment with a ready-to-assemble JDK. The download contains an image that is a base runtime and also contains a directory of jmod packages that are the JDK modules. These modules can be installed with the included jmod tool as needed. At this time there isn't a download for Mac OS X, that should come soon (a small issue meant it didn't make the initial push). Another issue is that the Solaris downloads are the 32-bit binaries only for now. As these are preview builds they will of course be issues and bugs. The main issue that people will likely run into is that crypto is currently disabled. There are also several areas in the JDK that require API and implementation changes to work as modules and that will come in time. Thanks to Roger Yeung, David Katleman, Christine Lu from the Release Engineering team in Oracle for making these builds available. At this time we haven't decided how often to update the bundles so it will likely be "as needed" for now. -Alan. From jesse.glick at oracle.com Thu May 10 04:43:57 2012 From: jesse.glick at oracle.com (Jesse Glick) Date: Thu, 10 May 2012 07:43:57 -0400 Subject: Preview builds of Jigsaw available In-Reply-To: <4FABA3C2.2010303@oracle.com> References: <4FABA3C2.2010303@oracle.com> Message-ID: <4FABA9FD.1050305@oracle.com> On 05/10/2012 07:17 AM, Alan Bateman wrote: > As these are preview builds they will of course be issues and bugs. By the way, not sure if this is on anyone's radar but lib/dt.jar is missing last I checked. From Alan.Bateman at oracle.com Thu May 10 04:58:47 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 10 May 2012 12:58:47 +0100 Subject: Preview builds of Jigsaw available In-Reply-To: <4FABA9FD.1050305@oracle.com> References: <4FABA3C2.2010303@oracle.com> <4FABA9FD.1050305@oracle.com> Message-ID: <4FABAD77.1030405@oracle.com> On 10/05/2012 12:43, Jesse Glick wrote: > On 05/10/2012 07:17 AM, Alan Bateman wrote: >> As these are preview builds they will of course be issues and bugs. > > By the way, not sure if this is on anyone's radar but lib/dt.jar is > missing last I checked. Yes, these needs a new home and we will need to figure out the compatibility impact on tools that use lib/dt.jar (same thing with other JAR files that will not exist in a modules image). There are a couple of other things missing too, SA comes to mind. We don't have a complete list at this time but we should have a script in jigsaw/jigsaw soon that will verify that everything gets a new home. -Alan. From paul.sandoz at oracle.com Thu May 10 05:24:52 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 10 May 2012 14:24:52 +0200 Subject: Preview builds of Jigsaw available In-Reply-To: <4FABA3C2.2010303@oracle.com> References: <4FABA3C2.2010303@oracle.com> Message-ID: <134A7DED-D7B7-4F8A-AEE5-765AF42E9963@oracle.com> Hi, Great stuff. > JDK base image + jmod packages: This download contains a minimal "base" runtime and a directory of jmod packages with the JDK modules. The jmod packages can be installed directly via the "jmod install" command, or added to a file or http based module repository and installed automatically when required. Any example on how to do the last part of the above? Paul. On May 10, 2012, at 1:17 PM, Alan Bateman wrote: > > We now have a download page on java.net to host preview builds from Oracle: > > http://jdk8.java.net/jigsaw/ > > This should be useful to those that want to try out Project Jigsaw and/or the current prototype of the modular JDK without needing to build it themselves. > > The preview builds come in two forms: > > - "JDK modules image". This is essentially equivalent to the normal JDK download except that everything is pre-installed as modules. > > - The other download choice is for those that wish to experiment with a ready-to-assemble JDK. The download contains an image that is a base runtime and also contains a directory of jmod packages that are the JDK modules. These modules can be installed with the included jmod tool as needed. > > At this time there isn't a download for Mac OS X, that should come soon (a small issue meant it didn't make the initial push). Another issue is that the Solaris downloads are the 32-bit binaries only for now. > > As these are preview builds they will of course be issues and bugs. The main issue that people will likely run into is that crypto is currently disabled. There are also several areas in the JDK that require API and implementation changes to work as modules and that will come in time. > > Thanks to Roger Yeung, David Katleman, Christine Lu from the Release Engineering team in Oracle for making these builds available. At this time we haven't decided how often to update the bundles so it will likely be "as needed" for now. > > -Alan. From Alan.Bateman at oracle.com Thu May 10 06:45:05 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 10 May 2012 14:45:05 +0100 Subject: A discussion about real-world modularity In-Reply-To: <4FAAB5CE.9020809@redhat.com> References: <4FAAB5CE.9020809@redhat.com> Message-ID: <4FABC661.90304@oracle.com> On 09/05/2012 19:22, David M. Lloyd wrote: > Some of you might find this interesting: > > http://lists.jboss.org/pipermail/jboss-as7-dev/2012-May/005974.html The references to serialization are interesting as we need update serialization to work with modules. I can't quite tell from the link whether you are using the standard serialization protocol or something else. If it is the standard serialization protocol then I'm curious how you get the class loader identity into the stream. -Alan From Alan.Bateman at oracle.com Thu May 10 07:02:15 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 10 May 2012 15:02:15 +0100 Subject: Preview builds of Jigsaw available In-Reply-To: <134A7DED-D7B7-4F8A-AEE5-765AF42E9963@oracle.com> References: <4FABA3C2.2010303@oracle.com> <134A7DED-D7B7-4F8A-AEE5-765AF42E9963@oracle.com> Message-ID: <4FABCA67.2050501@oracle.com> On 10/05/2012 13:24, Paul Sandoz wrote: > Hi, > > Great stuff. > >> *JDK base image + jmod packages*: This download contains a minimal >> "base" runtime and a directory of jmod packages with the JDK modules. >> The jmod packages can be installed directly via the "jmod install" >> command, or added to a file or http based module repository and >> installed automatically when required. > > Any example on how to do the last part of the above? We should create a web page with instructions on how to get going (in addition to the existing Quick Start page). In brief, assuming you have a http server to serve up a module repository then the tool to create and manage the module repository is jrepo. So on the "server" side then you create and populate a module repository with: $ jrepo myrepo create $ jrepo myrepo add jigsaw-pkgs/jmod/*.jmod On the client/device side you start with jre-base-image and use jmod to associate the module library with the module repository on the http server, eg: $ jmod add-repo http://server/myrepo Once you've got this association setup then it means that "jmod install" can download and install from the module repository, including resolving prerequisites. There is also support for repositories on the file system (add-repo allows you to specify a file path or file URL), which is useful for testing purposes. -Alan From david.lloyd at redhat.com Thu May 10 07:10:25 2012 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 10 May 2012 09:10:25 -0500 Subject: A discussion about real-world modularity In-Reply-To: <4FABC661.90304@oracle.com> References: <4FAAB5CE.9020809@redhat.com> <4FABC661.90304@oracle.com> Message-ID: <4FABCC51.5030906@redhat.com> On 05/10/2012 08:45 AM, Alan Bateman wrote: > On 09/05/2012 19:22, David M. Lloyd wrote: >> Some of you might find this interesting: >> >> http://lists.jboss.org/pipermail/jboss-as7-dev/2012-May/005974.html > The references to serialization are interesting as we need update > serialization to work with modules. I can't quite tell from the link > whether you are using the standard serialization protocol or something > else. If it is the standard serialization protocol then I'm curious how > you get the class loader identity into the stream. Yes, and no. This refers to my JBoss Marshalling project which is an alternative serialization API with more optimized implementations - it conforms to the spec in terms of serializable objects but has a number of extensions as well. There are two implementations at the moment - a JDK-compatible protocol as well as a more optimized (for space and speed) protocol. Either way the class data is written using a class resolver. This is basically equivalent to overriding ObjectInputStream#resolve[Proxy]Class() and ObjectOutputStream#annotate[Proxy]Class(). The module identity is written out and re-read and used to select the appropriate class loader. Note that as I state in that mailing, this is often, but not *always* preferred behavior, especially when you have different module environments. -- - DML From chris.hegarty at oracle.com Thu May 10 07:26:05 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 10 May 2012 15:26:05 +0100 Subject: Heads up, BDB coming, needed to support fast configuration In-Reply-To: <4FA94CC0.7000408@oracle.com> References: <4FA94CC0.7000408@oracle.com> Message-ID: <4FABCFFD.9060007@oracle.com> Here is there webrev to support building of the bdb repository. http://cr.openjdk.java.net/~chegar/jigsaw/bdb_webrev.00/webrev/ -Chris. On 08/05/2012 17:41, Chris Hegarty wrote: > Hi, > > A while back it was pointed out that the configuration data for modules > with entry points is stored in a highly inefficient manner [1]. It was > pointed out at the time that the plan has always been to replace this > with a "fast configuration", based on a persistent b-tree implementation. > > The b-tree implementation that we plan to use is a small footprint > implementation of Berkeley DB [2], called Restricted Data Store (RDS). > It is a minimal build of Berkeley DB that supports only b-tree access, > and provides a simple Java interface to support the functionality > required by the runtime (Jigsaw will also use the native interface). I'm > currently preparing to push the BDB code to Jigsaw. It will live in its > own repository, jigsaw/jigsaw/bdb. This mail is just a heads-up that > this will be coming soon. Note that as BDB is provided in some > distributions, Linux for example, the changes that are coming can use > the installed BDB as an alternative. > > -Chris. > > [1] > http://mail.openjdk.java.net/pipermail/jigsaw-dev/2012-March/002292.html > [2] > http://www.oracle.com/technetwork/products/berkeleydb/overview/index.html > From Alan.Bateman at oracle.com Thu May 10 08:36:25 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 10 May 2012 16:36:25 +0100 Subject: RFR: jmod remove In-Reply-To: <4FAA7FC4.5050101@oracle.com> References: <4F8FD138.9080505@oracle.com> <4F8FFC6A.9010502@oracle.com> <4F996BEB.3050706@oracle.com> <4F996FBC.3080406@oracle.com> <4F997543.8070709@oracle.com> <4F9F02A7.9020604@oracle.com> <4FA1437C.6090604@oracle.com> <4FAA7FC4.5050101@oracle.com> Message-ID: <4FABE079.2010100@oracle.com> On 09/05/2012 15:31, Chris Hegarty wrote: > Alan, > > I finally got back to this. Comments inline... > > Updated webrev: > http://cr.openjdk.java.net/~chegar/jigsaw/jmodrm.05/webrev/ We've gone several rounds on this and I think I'm mostly mostly happy. Mandy - do you plan to do another review? I'm happy to push this for Chris once it is final. A couple of small points: Files.deleteTreeUnchecked - the code is still catching the "useful" IOException and throwing a less useful IOException. I would suggest just replacing each one with execs.add(x). In SimpleLibrary.moduleTrashDir it uses SecureRandom but I think that is overkill. A sequence number of java.util.Random should be fine. -Alan. From mandy.chung at oracle.com Thu May 10 09:32:36 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 10 May 2012 09:32:36 -0700 Subject: RFR: jmod remove In-Reply-To: <4FABE079.2010100@oracle.com> References: <4F8FD138.9080505@oracle.com> <4F8FFC6A.9010502@oracle.com> <4F996BEB.3050706@oracle.com> <4F996FBC.3080406@oracle.com> <4F997543.8070709@oracle.com> <4F9F02A7.9020604@oracle.com> <4FA1437C.6090604@oracle.com> <4FAA7FC4.5050101@oracle.com> <4FABE079.2010100@oracle.com> Message-ID: <4FABEDA4.6020307@oracle.com> On 5/10/2012 8:36 AM, Alan Bateman wrote: > We've gone several rounds on this and I think I'm mostly mostly happy. > Mandy - do you plan to do another review? I'm happy to push this for > Chris once it is final. Yes, I have started the review and will finish it today. Mandy From karen.kinnear at oracle.com Thu May 10 11:48:41 2012 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 10 May 2012 14:48:41 -0400 Subject: JDK support for VM to read classes from modules in a module library In-Reply-To: <4FA8C9C8.9040002@oracle.com> References: <4FA4CAF0.8000008@oracle.com> <4FA8C9C8.9040002@oracle.com> Message-ID: <84FEB748-BB17-419D-9CE1-B5B18618152D@oracle.com> David, Thank you - good suggestion, I can add a trace/verbose hook here, under the TraceClassLoading flag . If you don't mind, I'm working on a follow-up and will include improved tracing in that next round of changes. thanks, Karen On May 8, 2012, at 3:22 AM, David Holmes wrote: > Hi Karen, > > Skimming through ... > > In systemDictionary.cpp: > > 123 if (!HAS_PENDING_EXCEPTION && k != NULL) { > 124 instanceKlassHandle ik(THREAD, k); > 125 JavaValue result(T_OBJECT); > 126 JavaCalls::call_static(&result, > 127 ik, > 128 vmSymbols::getBaseModuleLoader_name(), > 129 vmSymbols::void_module_bootloader_signature(), > 130 THREAD); > 131 if (HAS_PENDING_EXCEPTION) { > 132 UseModuleBootLoader = false; > 133 CLEAR_PENDING_EXCEPTION; > > Should we have some kind of debug/trace/verbose hook here to see the exception from getBaseModuleLoader() ? > > David > ----- > > On 8/05/2012 10:48 AM, Karen Kinnear wrote: >> >> Webrev for the VM changes: >> http://cr.openjdk.java.net/~acorn/vm-module-class-loading/webrev/ >> >> VM code includes both class loading changes for base module loader, as well as incremental perfdata timer information >> to help us track detailed class loading performance. >> >> thanks, >> Karen >> >> On May 5, 2012, at 2:38 AM, Mandy Chung wrote: >> >>> Karen and I have been working on implementing the support in the VM and library to read classes from a module library in native and proper system initialization for modules. This will replace the current workaround of using bootclasspath in module mode. I have put together a set of slides [1] to give an overview of this work (thanks to Alex, Karen, and Alan for their feedback and improvements). >>> >>> This work includes several pieces: >>> 1) Jigsaw native library interface that the VM will use to search and read classes from the base module >>> >>> This replaces the existing mechanism in the VM that searches and reads classes from rt.jar and the default bootclasspath (that no longer exists in modular JDK) for loading bootstrap classes. >>> >>> Webrev for the jdk change: >>> http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/module-class-loading/webrev-jigsaw-ms/ >>> >>> Karen will send out the webrev for the VM change separately. >>> >>> The jigsaw native library interface is defined in jigsaw.h and its implementation is in jigsaw.c. The temporary hack in org.openjdk.jigsaw.BootLoader to extend the bootclasspath for the base and other modules is now removed. I have added a few static methods in the Platform class for the system to determine if it's running in module mode, if a given class loader defines system classes, and to get the base module loader (refer below for details). >>> >>> This webrev also includes some minor cleanup in the modularization such as fixing the jdk.desktop requires optional jdk.jaxp that should not be an optional dependency and moving java.text.Bidi class to the base module (Alan has eliminated the bidi to desktop dependency a while ago). >>> >>> 2) system modules to be granted with AllPermissions >>> >>> Today the classes on bootclasspath are granted with AllPermissions. In a modular JDK, we need to a way to determine if it's a system module and grants with AllPermission. Alan has implemented the module URL as the code source to modules and grants all permissions to jdk.* modules, as an interim solution. Sean is looking into different options and a reliable way to identify a system module. >>> >>> Webrev at: >>> http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/module-class-loading/webrev-module-url/ >>> >>> 3) The JDK code needs to be audit for the use of class loader and update for modules as listed in the open issues. We have made changes in a few places in the JDK to fix some of the low hanging fruits that get more of the existing tests to pass when running as modules. >>> >>> a. bootstrap classes skip permission check e.g. ClassLoader.getClassLoader() >>> >>> Today bootstrap classes are loaded by null loader. In module mode, system modules are loaded by non-null module loader. A method Platform.isPlatformLoader(ClassLoader) is added to replace the "cl == null" check. Note that these methods may be more appropriate to live in java.lang or some other class but I add it in Platform class for now. >>> >>> b. Platform.getBaseModuleLoader() - the base module loader is needed when the library >>> code wants to load a class in base's optional dependency (e.g XML) because Class.getClassLoader() currently returns null (see the open issue listed in [1]). >>> >>> c. replace classloader parameter in the Class.forName call from null to an appropriate loader when loading a class that is not in the base module (e.g. management, scripting, etc). >>> >>> Webrev: >>> http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/module-class-loading/webrev-class-loader-fix/ >>> >>> There will be more of this kind of changes required in the jdk and this is just to set a few examples to get going. >>> >>> You can also look at all changes together in this webrev: >>> http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/module-class-loading/webrev-all/ >>> >>> Thanks >>> Mandy >>> [1] http://openjdk.java.net/projects/jigsaw/doc/module-class-loading.pdf >> From kelly.ohair at oracle.com Thu May 10 12:08:08 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Thu, 10 May 2012 12:08:08 -0700 Subject: Heads up, BDB coming, needed to support fast configuration In-Reply-To: <4FABCFFD.9060007@oracle.com> References: <4FA94CC0.7000408@oracle.com> <4FABCFFD.9060007@oracle.com> Message-ID: As far as the current old Makefiles, this looks pretty good and complete. Proof is in the pudding though, (where did that phrase come from?) does it build and work? ;^) And more importantly, we need to integrate BDB building into the build-infra work. I'll CC Erik and Magnus to make sure they see this. May need to add the BDB repository to build-infra. -kto On May 10, 2012, at 7:26 AM, Chris Hegarty wrote: > Here is there webrev to support building of the bdb repository. > http://cr.openjdk.java.net/~chegar/jigsaw/bdb_webrev.00/webrev/ > > -Chris. > > On 08/05/2012 17:41, Chris Hegarty wrote: >> Hi, >> >> A while back it was pointed out that the configuration data for modules >> with entry points is stored in a highly inefficient manner [1]. It was >> pointed out at the time that the plan has always been to replace this >> with a "fast configuration", based on a persistent b-tree implementation. >> >> The b-tree implementation that we plan to use is a small footprint >> implementation of Berkeley DB [2], called Restricted Data Store (RDS). >> It is a minimal build of Berkeley DB that supports only b-tree access, >> and provides a simple Java interface to support the functionality >> required by the runtime (Jigsaw will also use the native interface). I'm >> currently preparing to push the BDB code to Jigsaw. It will live in its >> own repository, jigsaw/jigsaw/bdb. This mail is just a heads-up that >> this will be coming soon. Note that as BDB is provided in some >> distributions, Linux for example, the changes that are coming can use >> the installed BDB as an alternative. >> >> -Chris. >> >> [1] >> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2012-March/002292.html >> [2] >> http://www.oracle.com/technetwork/products/berkeleydb/overview/index.html >> From chris.hegarty at oracle.com Thu May 10 14:04:26 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 10 May 2012 22:04:26 +0100 Subject: Heads up, BDB coming, needed to support fast configuration In-Reply-To: References: <4FA94CC0.7000408@oracle.com> <4FABCFFD.9060007@oracle.com> Message-ID: <4FAC2D5A.70104@oracle.com> Thanks Kelly, I appreciate your time going through this. On 10/05/12 20:08, Kelly O'Hair wrote: > As far as the current old Makefiles, this looks pretty good and complete. > Proof is in the pudding though, (where did that phrase come from?) does it build and work? ;^) It builds on all platforms (even Mac and linux-arm!), with and without the bdb repo where the system has the bdb develop package installed. Partial builds that import from another JDK are still not implemented, I'm not sure if this still makes sense going forward with the new build system. Anyway, this requires further work, not a blocker for an initial push. Oh, here is a link to the main bdb Makefile, maybe you could skim it for obvious problems? http://cr.openjdk.java.net/~chegar/jigsaw/bdb_webrev.00/bdb_repo_webrev/webrev/make/Makefile.html > And more importantly, we need to integrate BDB building into the build-infra work. Yes, of course. I haven't spent any time on this yet since jigsaw current doesn't build with the new build. I know the build-infra folks are working on this. I hope to sync up with them once this is pushed. > I'll CC Erik and Magnus to make sure they see this. May need to add the BDB repository to build-infra. Yes, or we could do it in jigsaw/jigsaw first. It is up to date with the latest jdk8. -Chris. > > -kto > > On May 10, 2012, at 7:26 AM, Chris Hegarty wrote: > >> Here is there webrev to support building of the bdb repository. >> http://cr.openjdk.java.net/~chegar/jigsaw/bdb_webrev.00/webrev/ >> >> -Chris. >> >> On 08/05/2012 17:41, Chris Hegarty wrote: >>> Hi, >>> >>> A while back it was pointed out that the configuration data for modules >>> with entry points is stored in a highly inefficient manner [1]. It was >>> pointed out at the time that the plan has always been to replace this >>> with a "fast configuration", based on a persistent b-tree implementation. >>> >>> The b-tree implementation that we plan to use is a small footprint >>> implementation of Berkeley DB [2], called Restricted Data Store (RDS). >>> It is a minimal build of Berkeley DB that supports only b-tree access, >>> and provides a simple Java interface to support the functionality >>> required by the runtime (Jigsaw will also use the native interface). I'm >>> currently preparing to push the BDB code to Jigsaw. It will live in its >>> own repository, jigsaw/jigsaw/bdb. This mail is just a heads-up that >>> this will be coming soon. Note that as BDB is provided in some >>> distributions, Linux for example, the changes that are coming can use >>> the installed BDB as an alternative. >>> >>> -Chris. >>> >>> [1] >>> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2012-March/002292.html >>> [2] >>> http://www.oracle.com/technetwork/products/berkeleydb/overview/index.html >>> > From chris.hegarty at oracle.com Thu May 10 14:18:11 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 10 May 2012 22:18:11 +0100 Subject: RFR: jmod remove In-Reply-To: <4FABE079.2010100@oracle.com> References: <4F8FD138.9080505@oracle.com> <4F8FFC6A.9010502@oracle.com> <4F996BEB.3050706@oracle.com> <4F996FBC.3080406@oracle.com> <4F997543.8070709@oracle.com> <4F9F02A7.9020604@oracle.com> <4FA1437C.6090604@oracle.com> <4FAA7FC4.5050101@oracle.com> <4FABE079.2010100@oracle.com> Message-ID: <4FAC3093.5050001@oracle.com> On 10/05/12 16:36, Alan Bateman wrote: > : > We've gone several rounds on this and I think I'm mostly mostly happy. > Mandy - do you plan to do another review? I'm happy to push this for > Chris once it is final. > > A couple of small points: > > Files.deleteTreeUnchecked - the code is still catching the "useful" > IOException and throwing a less useful IOException. I would suggest just > replacing each one with execs.add(x). Done. At one point I thought it may be cleaner for tools when reporting an issue, but you're right. > In SimpleLibrary.moduleTrashDir it uses SecureRandom but I think that is > overkill. A sequence number of java.util.Random should be fine. Done. http://cr.openjdk.java.net/~chegar/jigsaw/jmodrm.06/webrev/ Thanks, -Chris. > > -Alan. From mandy.chung at oracle.com Thu May 10 14:59:31 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 10 May 2012 14:59:31 -0700 Subject: RFR: jmod remove In-Reply-To: <4FAA7FC4.5050101@oracle.com> References: <4F8FD138.9080505@oracle.com> <4F8FFC6A.9010502@oracle.com> <4F996BEB.3050706@oracle.com> <4F996FBC.3080406@oracle.com> <4F997543.8070709@oracle.com> <4F9F02A7.9020604@oracle.com> <4FA1437C.6090604@oracle.com> <4FAA7FC4.5050101@oracle.com> Message-ID: <4FAC3A43.1090907@oracle.com> Chris, Looks good in general. Some minor comments below: On 5/9/2012 7:31 AM, Chris Hegarty wrote: > http://cr.openjdk.java.net/~chegar/jigsaw/jmodrm.06/webrev/ Files.java You can also remove L39. L147: Could you just add exc to the "excs" list rather than wrapping it with a new IOException? Librarian.java L317: The "excs" variable is not needed any more. L327: Should warnings normally go to System.err instead of System.out? SimpleLibrary.java L1505: should the remove method accept a declaring ModuleId as a valid argument? I am wondering whether it should allow to remove a module if an alias name or non-default view name is given. Perhaps add a comment and leave it as an open issue to be addressed later. L1546-1548: Another way to perform this check would be: for (ModuleId mid : mids) { if (cf.findContextForModuleName(mid) != null) throw new .... } Would that be more explicit? ModuleFile.java L525: should be aligned 2-space to the left Mandy P.S. I hope to send you my comments this morning so that you can rev it once. I was almost done before going to 11am and got tied up until now. Sorry for causing you to generate another round of webrev. From mandy.chung at oracle.com Thu May 10 16:22:58 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 10 May 2012 16:22:58 -0700 Subject: Heads up, BDB coming, needed to support fast configuration In-Reply-To: <4FABCFFD.9060007@oracle.com> References: <4FA94CC0.7000408@oracle.com> <4FABCFFD.9060007@oracle.com> Message-ID: <4FAC4DD2.5080505@oracle.com> On 5/10/2012 7:26 AM, Chris Hegarty wrote: > Here is there webrev to support building of the bdb repository. > http://cr.openjdk.java.net/~chegar/jigsaw/bdb_webrev.00/webrev/ > > It builds on all platforms (even Mac and linux-arm!), with and without > the bdb repo where the system has the bdb develop package installed. > Partial builds that import from another JDK are still not implemented, > I'm not sure if this still makes sense going forward with the new > build system. Anyway, this requires further work, not a blocker for an > initial push. Great, you built on all platforms + a bonus one (linux-arm)! Have you tried SKIP_BOOT_CYCLE=false build? You said "Partial builds that import from another JDK are still not implemented" - you mean it always requires building the entire forest unless USE_SYSTEM_BDB or ALT_BDB_IMPORT_PATH is specified, right? I can push this for you when it's ready. Minor comments: jdk/make/common/Sanity.gmk Do we plan to enable BDB_IMPORT_CHECK some day to to check the library when make sanity PersistentTreeMap.java L52: "is" a typo? nit: would be good to add a space after // L134: I assume the getStringAndInt method is a helper method for testing purpose only, right? Might be worth to add a comment. Thanks Mandy From chris.hegarty at oracle.com Fri May 11 02:14:29 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 11 May 2012 10:14:29 +0100 Subject: RFR: jmod remove In-Reply-To: <4FAC3A43.1090907@oracle.com> References: <4F8FD138.9080505@oracle.com> <4F8FFC6A.9010502@oracle.com> <4F996BEB.3050706@oracle.com> <4F996FBC.3080406@oracle.com> <4F997543.8070709@oracle.com> <4F9F02A7.9020604@oracle.com> <4FA1437C.6090604@oracle.com> <4FAA7FC4.5050101@oracle.com> <4FAC3A43.1090907@oracle.com> Message-ID: <4FACD875.4040705@oracle.com> On 10/05/12 22:59, Mandy Chung wrote: > Chris, > > Looks good in general. Some minor comments below: Thanks Mandy, I made all your suggested cleanup changes. > L1546-1548: Another way to perform this check would be: > for (ModuleId mid : mids) { > if (cf.findContextForModuleName(mid) != null) > throw new .... > } In its current form the above won't work. findContextForModuleName takes a String module name, what we want to determine is if a particular module id is being used by the configuration. The Configuration itself ( and it's maps ) doesn't directly know what module id is being used, you need to dig a little deeper into the actual contexts. I guess this is somewhat related to whether we want to support alias and/or non-default view names. Let's leave it as is for now. We can revisit it later if necessary. I added a comment. Thanks, -Chris. > On 5/9/2012 7:31 AM, Chris Hegarty wrote: >> http://cr.openjdk.java.net/~chegar/jigsaw/jmodrm.06/webrev/ > > Files.java > You can also remove L39. > L147: Could you just add exc to the "excs" list rather > than wrapping it with a new IOException? > > Librarian.java > L317: The "excs" variable is not needed any more. > L327: Should warnings normally go to System.err instead of > System.out? > > SimpleLibrary.java > L1505: should the remove method accept a declaring ModuleId > as a valid argument? I am wondering whether it should allow > to remove a module if an alias name or non-default view name > is given. Perhaps add a comment and leave it as an open issue > to be addressed later. > > L1546-1548: Another way to perform this check would be: > for (ModuleId mid : mids) { > if (cf.findContextForModuleName(mid) != null) > throw new .... > } > Would that be more explicit? > > ModuleFile.java > L525: should be aligned 2-space to the left > > Mandy > P.S. I hope to send you my comments this morning so that you > can rev it once. I was almost done before going to 11am and > got tied up until now. Sorry for causing you to generate > another round of webrev. > From sanjeeb.sahoo at oracle.com Fri May 11 03:35:46 2012 From: sanjeeb.sahoo at oracle.com (Sahoo) Date: Fri, 11 May 2012 16:05:46 +0530 Subject: A discussion about real-world modularity In-Reply-To: <4FABCC51.5030906@redhat.com> References: <4FAAB5CE.9020809@redhat.com> <4FABC661.90304@oracle.com> <4FABCC51.5030906@redhat.com> Message-ID: <4FACEB82.4020303@oracle.com> On Thursday 10 May 2012 07:40 PM, David M. Lloyd wrote: > Either way the class data is written using a class resolver. This is > basically equivalent to overriding > ObjectInputStream#resolve[Proxy]Class() and > ObjectOutputStream#annotate[Proxy]Class(). The module identity is > written out and re-read and used to select the appropriate class loader. This is how we have solved serialization issue in GlassFish project as well. We write out OSGi bundle information in the stream. Sahoo From alan.bateman at oracle.com Fri May 11 04:05:18 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 11 May 2012 11:05:18 +0000 Subject: hg: jigsaw/jigsaw/bdb: Initial load Message-ID: <20120511110519.413B44727B@hg.openjdk.java.net> Changeset: a1985f14b030 Author: chegar Date: 2012-05-11 10:42 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/bdb/rev/a1985f14b030 Initial load + ASSEMBLY_EXCEPTION + LICENSE + README + THIRD_PARTY_README + dist/Makefile.in + dist/RELEASE + dist/api_flags + dist/api_flags.c + dist/buildpkg + dist/bumprel + dist/clib_port.in + dist/config.guess + dist/config.hin + dist/config.sub + dist/configure + dist/configure.ac + dist/errno.h + dist/gen_inc.awk + dist/gen_msg.awk + dist/install.sh + dist/ltmain.sh + dist/pubdef.in + dist/s_all + dist/s_apiflags + dist/s_config + dist/s_docs + dist/s_include + dist/s_message + dist/s_message_id + dist/s_perm + dist/s_readme + dist/s_sig + dist/s_tags + dist/s_test + dist/s_validate + dist/s_windows + dist/s_windows_dsp + dist/srcfiles.in + make/FILES_c.gmk + make/Makefile + make/libdb.def + make/libdb.rc + src/btree/bt_compare.c + src/btree/bt_conv.c + src/btree/bt_curadj.c + src/btree/bt_cursor.c + src/btree/bt_delete.c + src/btree/bt_method.c + src/btree/bt_open.c + src/btree/bt_put.c + src/btree/bt_reclaim.c + src/btree/bt_recno.c + src/btree/bt_rsearch.c + src/btree/bt_search.c + src/btree/bt_split.c + src/btree/bt_stat.c + src/btree/bt_verify.c + src/clib/getopt.c + src/clib/isalpha.c + src/clib/snprintf.c + src/clib/strsep.c + src/common/clock.c + src/common/crypto_stub.c + src/common/db_byteorder.c + src/common/db_err.c + src/common/db_getlong.c + src/common/db_idspace.c + src/common/db_log2.c + src/common/db_shash.c + src/common/dbt.c + src/common/mkpath.c + src/common/os_method.c + src/common/rds_stub.c + src/common/util_cache.c + src/common/util_log.c + src/common/util_sig.c + src/common/zerofill.c + src/db/db.c + src/db/db_am.c + src/db/db_backup.c + src/db/db_cam.c + src/db/db_conv.c + src/db/db_copy.c + src/db/db_dup.c + src/db/db_iface.c + src/db/db_meta.c + src/db/db_method.c + src/db/db_open.c + src/db/db_overflow.c + src/db/db_ovfl_vrfy.c + src/db/db_pr.c + src/db/db_reclaim.c + src/db/db_remove.c + src/db/db_rename.c + src/db/db_ret.c + src/db/db_setid.c + src/db/db_setlsn.c + src/db/db_sort_multiple.c + src/db/db_stati.c + src/db/db_truncate.c + src/db/db_vrfy.c + src/db/db_vrfy_stub.c + src/db/db_vrfyutil.c + src/db/partition_stub.c + src/dbinc/atomic.h + src/dbinc/btree.h + src/dbinc/clock.h + src/dbinc/crypto.h + src/dbinc/cxx_int.h + src/dbinc/db.in + src/dbinc/db_185.in + src/dbinc/db_am.h + src/dbinc/db_cxx.in + src/dbinc/db_dispatch.h + src/dbinc/db_int.in + src/dbinc/db_join.h + src/dbinc/db_page.h + src/dbinc/db_swap.h + src/dbinc/db_upgrade.h + src/dbinc/db_verify.h + src/dbinc/debug.h + src/dbinc/fop.h + src/dbinc/globals.h + src/dbinc/hash.h + src/dbinc/heap.h + src/dbinc/hmac.h + src/dbinc/lock.h + src/dbinc/log.h + src/dbinc/log_verify.h + src/dbinc/mp.h + src/dbinc/mutex.h + src/dbinc/mutex_int.h + src/dbinc/os.h + src/dbinc/partition.h + src/dbinc/perfmon.h + src/dbinc/qam.h + src/dbinc/queue.h + src/dbinc/region.h + src/dbinc/rep.h + src/dbinc/repmgr.h + src/dbinc/shqueue.h + src/dbinc/tcl_db.h + src/dbinc/txn.h + src/dbinc/win_db.h + src/dbinc/xa.h + src/dbinc_auto/api_flags.in + src/dbinc_auto/btree_auto.h + src/dbinc_auto/btree_ext.h + src/dbinc_auto/clib_ext.h + src/dbinc_auto/common_ext.h + src/dbinc_auto/crdel_auto.h + src/dbinc_auto/crypto_ext.h + src/dbinc_auto/db_auto.h + src/dbinc_auto/db_ext.h + src/dbinc_auto/dbreg_auto.h + src/dbinc_auto/dbreg_ext.h + src/dbinc_auto/env_ext.h + src/dbinc_auto/ext_185_def.in + src/dbinc_auto/ext_185_prot.in + src/dbinc_auto/ext_def.in + src/dbinc_auto/ext_prot.in + src/dbinc_auto/fileops_auto.h + src/dbinc_auto/fileops_ext.h + src/dbinc_auto/hash_auto.h + src/dbinc_auto/hash_ext.h + src/dbinc_auto/heap_auto.h + src/dbinc_auto/heap_ext.h + src/dbinc_auto/hmac_ext.h + src/dbinc_auto/int_def.in + src/dbinc_auto/lock_ext.h + src/dbinc_auto/log_ext.h + src/dbinc_auto/mp_ext.h + src/dbinc_auto/mutex_ext.h + src/dbinc_auto/os_ext.h + src/dbinc_auto/qam_auto.h + src/dbinc_auto/qam_ext.h + src/dbinc_auto/rep_automsg.h + src/dbinc_auto/rep_ext.h + src/dbinc_auto/repmgr_auto.h + src/dbinc_auto/repmgr_automsg.h + src/dbinc_auto/repmgr_ext.h + src/dbinc_auto/sequence_ext.h + src/dbinc_auto/tcl_ext.h + src/dbinc_auto/txn_auto.h + src/dbinc_auto/txn_ext.h + src/dbinc_auto/xa_ext.h + src/env/env_alloc.c + src/env/env_config.c + src/env/env_file.c + src/env/env_globals.c + src/env/env_method.c + src/env/env_name.c + src/env/env_open.c + src/env/env_region.c + src/env/env_sig.c + src/env/env_stat.c + src/fileops/fop_basic.c + src/fileops/fop_util.c + src/hash/hash_func.c + src/hash/hash_stub.c + src/heap/heap_stub.c + src/lock/lock_stub.c + src/log/log_verify_stub.c + src/mp/mp_alloc.c + src/mp/mp_bh.c + src/mp/mp_fget.c + src/mp/mp_fmethod.c + src/mp/mp_fopen.c + src/mp/mp_fput.c + src/mp/mp_fset.c + src/mp/mp_method.c + src/mp/mp_region.c + src/mp/mp_register.c + src/mp/mp_resize.c + src/mp/mp_stat.c + src/mp/mp_sync.c + src/mp/mp_trickle.c + src/mutex/mut_alloc.c + src/mutex/mut_method.c + src/mutex/mut_pthread.c + src/mutex/mut_region.c + src/mutex/mut_stat.c + src/mutex/mut_tas.c + src/mutex/mut_win32.c + src/os/os_abort.c + src/os/os_abs.c + src/os/os_addrinfo.c + src/os/os_alloc.c + src/os/os_clock.c + src/os/os_config.c + src/os/os_cpu.c + src/os/os_ctime.c + src/os/os_dir.c + src/os/os_errno.c + src/os/os_fid.c + src/os/os_flock.c + src/os/os_fsync.c + src/os/os_getenv.c + src/os/os_handle.c + src/os/os_map.c + src/os/os_mkdir.c + src/os/os_open.c + src/os/os_path.c + src/os/os_pid.c + src/os/os_rename.c + src/os/os_root.c + src/os/os_rpath.c + src/os/os_rw.c + src/os/os_seek.c + src/os/os_stack.c + src/os/os_stat.c + src/os/os_tmpdir.c + src/os/os_truncate.c + src/os/os_uid.c + src/os/os_unlink.c + src/os/os_yield.c + src/os_windows/ce_ctime.c + src/os_windows/os_abs.c + src/os_windows/os_clock.c + src/os_windows/os_config.c + src/os_windows/os_cpu.c + src/os_windows/os_dir.c + src/os_windows/os_errno.c + src/os_windows/os_fid.c + src/os_windows/os_flock.c + src/os_windows/os_fsync.c + src/os_windows/os_getenv.c + src/os_windows/os_handle.c + src/os_windows/os_map.c + src/os_windows/os_mkdir.c + src/os_windows/os_open.c + src/os_windows/os_rename.c + src/os_windows/os_rw.c + src/os_windows/os_seek.c + src/os_windows/os_stat.c + src/os_windows/os_truncate.c + src/os_windows/os_unlink.c + src/os_windows/os_yield.c + src/qam/qam_stub.c + src/rep/rep_stub.c + src/repmgr/repmgr_stub.c + src/windows_incl/clib_port.h + src/windows_incl/db.h + src/windows_incl/db_config.h + src/windows_incl/db_int.h + util/db_dump.c + util/db_load.c + util/db_stat.c + util/db_verify.c From paul.sandoz at oracle.com Fri May 11 04:45:59 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 11 May 2012 13:45:59 +0200 Subject: Heads up, BDB coming, needed to support fast configuration In-Reply-To: <4FABCFFD.9060007@oracle.com> References: <4FA94CC0.7000408@oracle.com> <4FABCFFD.9060007@oracle.com> Message-ID: <5CF64427-C9EE-47BC-9A18-C1D4E4F737D7@oracle.com> Hi Chris, In PersistentTreeMap: 131 public synchronized StringAndInt getStringAndInt(String key) Is that mean to be synchronized? other get methods are not. Paul. On May 10, 2012, at 4:26 PM, Chris Hegarty wrote: > Here is there webrev to support building of the bdb repository. > http://cr.openjdk.java.net/~chegar/jigsaw/bdb_webrev.00/webrev/ > > -Chris. From chris.hegarty at oracle.com Fri May 11 05:02:55 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 11 May 2012 13:02:55 +0100 Subject: Heads up, BDB coming, needed to support fast configuration In-Reply-To: <5CF64427-C9EE-47BC-9A18-C1D4E4F737D7@oracle.com> References: <4FA94CC0.7000408@oracle.com> <4FABCFFD.9060007@oracle.com> <5CF64427-C9EE-47BC-9A18-C1D4E4F737D7@oracle.com> Message-ID: <4FACFFEF.7090501@oracle.com> On 11/05/12 12:45, Paul Sandoz wrote: > Hi Chris, > > In PersistentTreeMap: > > 131 public synchronized StringAndInt getStringAndInt(String key) > > > Is that mean to be synchronized? other get methods are not. In the current implementation then, yes. getStringAndInt currently uses String[] and int[] fields to store the retrieved values. These are of course class wide and can only be used by on call at a time ;-( PersistentTreeMap can be used in two ways, one instance per persistent on disk db shared among multiple threads, or one instance per thread. The former would benefit from local String[] and int[] instances, but the later would suffer. This will ultimately depend on how the fast configuration work uses PersistenTreeMap. For now, I think we should leave it as is, and revisit if necessary. Thanks, -Chris. > Paul. > > On May 10, 2012, at 4:26 PM, Chris Hegarty wrote: > >> Here is there webrev to support building of the bdb repository. >> http://cr.openjdk.java.net/~chegar/jigsaw/bdb_webrev.00/webrev/ >> >> -Chris. From paul.sandoz at oracle.com Fri May 11 05:22:28 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 11 May 2012 14:22:28 +0200 Subject: Heads up, BDB coming, needed to support fast configuration In-Reply-To: <4FACFFEF.7090501@oracle.com> References: <4FA94CC0.7000408@oracle.com> <4FABCFFD.9060007@oracle.com> <5CF64427-C9EE-47BC-9A18-C1D4E4F737D7@oracle.com> <4FACFFEF.7090501@oracle.com> Message-ID: <04485C21-BF84-4595-AF69-1C567508C740@oracle.com> On May 11, 2012, at 2:02 PM, Chris Hegarty wrote: > On 11/05/12 12:45, Paul Sandoz wrote: >> Hi Chris, >> >> In PersistentTreeMap: >> >> 131 public synchronized StringAndInt getStringAndInt(String key) >> >> >> Is that mean to be synchronized? other get methods are not. > > In the current implementation then, yes. getStringAndInt currently uses String[] and int[] fields to store the retrieved values. These are of course class wide and can only be used by on call at a time ;-( > Doh! I missed that, thanks. > PersistentTreeMap can be used in two ways, one instance per persistent on disk db shared among multiple threads, or one instance per thread. The former would benefit from local String[] and int[] instances, but the later would suffer. > This will ultimately depend on how the fast configuration work uses PersistenTreeMap. For now, I think we should leave it as is, and revisit if necessary. > OK. Paul. From alan.bateman at oracle.com Fri May 11 05:44:36 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 11 May 2012 12:44:36 +0000 Subject: hg: jigsaw/jigsaw/jdk: jmod remove Message-ID: <20120511124447.4595E4727D@hg.openjdk.java.net> Changeset: e38d4d5251d5 Author: chegar Date: 2012-05-11 13:44 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/e38d4d5251d5 jmod remove Reviewed-by: alanb, mchung ! src/share/classes/org/openjdk/jigsaw/Files.java ! src/share/classes/org/openjdk/jigsaw/Library.java ! src/share/classes/org/openjdk/jigsaw/ModuleFile.java ! src/share/classes/org/openjdk/jigsaw/SimpleLibrary.java ! src/share/classes/org/openjdk/jigsaw/cli/Librarian.java ! test/org/openjdk/jigsaw/MockLibrary.java + test/org/openjdk/jigsaw/cli/jmod-rm.sh From Roger.Riggs at oracle.com Fri May 11 06:11:31 2012 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 11 May 2012 09:11:31 -0400 Subject: Heads up, BDB coming, needed to support fast configuration In-Reply-To: <4FACFFEF.7090501@oracle.com> References: <4FA94CC0.7000408@oracle.com> <4FABCFFD.9060007@oracle.com> <5CF64427-C9EE-47BC-9A18-C1D4E4F737D7@oracle.com> <4FACFFEF.7090501@oracle.com> Message-ID: <4FAD1003.4060407@oracle.com> Hi Chris, Instead of synchronizing the method on the signature the synchronization should be done internally. That will give more flexibility in the future if the internal data structure or interface changes without needing to change the method signature. Roger On 05/11/2012 08:02 AM, Chris Hegarty wrote: > On 11/05/12 12:45, Paul Sandoz wrote: >> Hi Chris, >> >> In PersistentTreeMap: >> >> 131 public synchronized StringAndInt getStringAndInt(String key) >> >> >> Is that mean to be synchronized? other get methods are not. > > In the current implementation then, yes. getStringAndInt currently > uses String[] and int[] fields to store the retrieved values. These > are of course class wide and can only be used by on call at a time ;-( > > PersistentTreeMap can be used in two ways, one instance per persistent > on disk db shared among multiple threads, or one instance per thread. > The former would benefit from local String[] and int[] instances, but > the later would suffer. This will ultimately depend on how the fast > configuration work uses PersistenTreeMap. For now, I think we should > leave it as is, and revisit if necessary. > > Thanks, > -Chris. > >> Paul. >> >> On May 10, 2012, at 4:26 PM, Chris Hegarty wrote: >> >>> Here is there webrev to support building of the bdb repository. >>> http://cr.openjdk.java.net/~chegar/jigsaw/bdb_webrev.00/webrev/ >>> >>> -Chris. From chris.hegarty at oracle.com Fri May 11 06:17:34 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 11 May 2012 14:17:34 +0100 Subject: Heads up, BDB coming, needed to support fast configuration In-Reply-To: <4FAD1003.4060407@oracle.com> References: <4FA94CC0.7000408@oracle.com> <4FABCFFD.9060007@oracle.com> <5CF64427-C9EE-47BC-9A18-C1D4E4F737D7@oracle.com> <4FACFFEF.7090501@oracle.com> <4FAD1003.4060407@oracle.com> Message-ID: <4FAD116E.4060901@oracle.com> On 11/05/12 14:11, Roger Riggs wrote: > Hi Chris, > > Instead of synchronizing the method on the signature the synchronization > should be done internally. That will give more flexibility in the future > if the > internal data structure or interface changes without needing to change > the method signature. Excellent idea Roger. I'll make the change and include it in the next webrev ( I have a minor sanity change resulting from Mandy's earlier comments ). -Chris. > > Roger From Alan.Bateman at oracle.com Fri May 11 06:49:40 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 11 May 2012 14:49:40 +0100 Subject: Heads up, BDB coming, needed to support fast configuration In-Reply-To: <4FAD1003.4060407@oracle.com> References: <4FA94CC0.7000408@oracle.com> <4FABCFFD.9060007@oracle.com> <5CF64427-C9EE-47BC-9A18-C1D4E4F737D7@oracle.com> <4FACFFEF.7090501@oracle.com> <4FAD1003.4060407@oracle.com> Message-ID: <4FAD18F4.7010301@oracle.com> On 11/05/2012 14:11, Roger Riggs wrote: > Hi Chris, > > Instead of synchronizing the method on the signature the synchronization > should be done internally. That will give more flexibility in the > future if the > internal data structure or interface changes without needing to change > the method signature. AFAIK, this isn't considered part of the method signature and so wouldn't be an API change. -Alan. From chris.hegarty at oracle.com Fri May 11 07:07:56 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 11 May 2012 15:07:56 +0100 Subject: Heads up, BDB coming, needed to support fast configuration In-Reply-To: <4FAC4DD2.5080505@oracle.com> References: <4FA94CC0.7000408@oracle.com> <4FABCFFD.9060007@oracle.com> <4FAC4DD2.5080505@oracle.com> Message-ID: <4FAD1D3C.7070505@oracle.com> Updated webrev, comments inline... http://cr.openjdk.java.net/~chegar/jigsaw/bdb_webrev.01/webrev/ On 11/05/12 00:22, Mandy Chung wrote: > ... > Great, you built on all platforms + a bonus one (linux-arm)! Have you > tried SKIP_BOOT_CYCLE=false build? Yeap, SKIP_BOOT_CYCLE=false builds fine. > You said "Partial builds that import > from another JDK are still not implemented" - you mean it always > requires building the entire forest unless USE_SYSTEM_BDB or > ALT_BDB_IMPORT_PATH is specified, right? Right, you got it exactly. Since the import requires the db.h header it is not quite suited for import from a JDK ( the JDK doesn't contain the db.h ). Long term we might want to put this header in a default location. I didn't spend too much time on this since I believe the new build system will not support partial builds as we are use to today. My understanding ( and I could be wrong ) is that a full forest will be required and full build initially. Partial builds will essentially be fast incremental builds, where untouched repos, like bdb for example, can be quickly by passed. I'll work with the build-infra folks to determine the best solution for this going forward. > I can push this for you when it's ready. Minor comments: > > jdk/make/common/Sanity.gmk > Do we plan to enable BDB_IMPORT_CHECK some day to > to check the library when make sanity BDB_IMPORT_CHECK will only be skipped ( false ) when running sanity from the top-level repo. The jdk sanity (when invoked form top) should not check for the header before it has been generated. For jdk (partial) builds then the sanity is always run. This is similar to the hotspot imports. I seen an issue when trying to answer your question. The jdk sanity should always check for db.h when USE_SYSTEM_BDB is set. I updated jdk/make/common/Sanity.gmk and jdk/make/common/shared/Sanity.gmk to support this. > PersistentTreeMap.java > L52: "is" a typo? nit: would be good to add a space after // Thanks, got it. > L134: I assume the getStringAndInt method is a helper method > for testing purpose only, right? Might be worth to add a comment. Hmmm... I'm not sure about this. If it's ok, I'll leave it as it for now, we can revisit later if necessary. -Chris. > > Thanks > Mandy From mandy.chung at oracle.com Fri May 11 09:32:58 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 11 May 2012 09:32:58 -0700 Subject: Heads up, BDB coming, needed to support fast configuration In-Reply-To: <4FAD1D3C.7070505@oracle.com> References: <4FA94CC0.7000408@oracle.com> <4FABCFFD.9060007@oracle.com> <4FAC4DD2.5080505@oracle.com> <4FAD1D3C.7070505@oracle.com> Message-ID: <4FAD3F3A.4050101@oracle.com> On 5/11/2012 7:07 AM, Chris Hegarty wrote: > >> L134: I assume the getStringAndInt method is a helper method >> for testing purpose only, right? Might be worth to add a comment. > > Hmmm... I'm not sure about this. If it's ok, I'll leave it as it for > now, we can revisit later if necessary. I'm fine with what you have. I asked this because I have a comment related to what Paul/Roger has raised about the synchronized getStringAndInt method. I believe you can move 'svala' and 'ivala' to the StringAndInt class as the instance fields to get rid of the synchronization. The getStringAndInt method can pass these fields of a newly created StringAndInt object to the get2 method call and StringAndInt class may provide the accessor methods to get the key and value. Mandy From chris.hegarty at oracle.com Fri May 11 10:11:55 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 11 May 2012 18:11:55 +0100 Subject: Heads up, BDB coming, needed to support fast configuration In-Reply-To: <4FAD3F3A.4050101@oracle.com> References: <4FA94CC0.7000408@oracle.com> <4FABCFFD.9060007@oracle.com> <4FAC4DD2.5080505@oracle.com> <4FAD1D3C.7070505@oracle.com> <4FAD3F3A.4050101@oracle.com> Message-ID: <4FAD485B.4070006@oracle.com> On 11/05/12 17:32, Mandy Chung wrote: >.... > I'm fine with what you have. > > I asked this because I have a comment related to what Paul/Roger has > raised about the synchronized getStringAndInt method. I believe you can > move 'svala' and 'ivala' to the StringAndInt class as the instance > fields to get rid of the synchronization. The getStringAndInt method can > pass these fields of a newly created StringAndInt object to the get2 > method call and StringAndInt class may provide the accessor methods to > get the key and value. Right that would be cleaner, but I'm still reluctant to change until we have more experience with the usage of PersistentTreeMap. The reason I being stubborn here (and it may be completely unfounded) is that I'm expecting each thread to have its own PersistentTreeMap instance, in which case the uncontented lock should be virtually optimized out, but the extra creation of these "holder" arrays may just cause a little more than necessary garbage. That said, I could go either way on this. I see this as more of a performance optimization at some point in the future when we have the fast configuration in. Let me know if you want to change it. -Chris. > > Mandy From Alan.Bateman at oracle.com Fri May 11 11:20:20 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 11 May 2012 19:20:20 +0100 Subject: CFV: New jigsaw Committer: Chris Hegarty Message-ID: <4FAD5864.5060107@oracle.com> I hereby nominate Chris Hegarty to jigsaw Committer. Chris has reviewer role in the jdk6, jdk7, jdk7u, jdk8 projects. He is lead for the sctp project. Chris has contributed several significant changes to this project. Here's the list of changes that I could find (specific links as log?rev=chegar will match the 200+ other changes that he has pushed to jdk7 and jdk8). Support installation of commands, configuration and native libraries outside of module library http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/a22f65ac0b9a Superfluous classes archive created for modules with no files http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/2c2b55c87c8c jdk.ucrypto should be required http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/1c3bbdc93d5d Jigsaw tests intermittently failing on some platforms http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/8df8feaabfa7 Allow ModulesProblemList to be extended http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/830c9470f368 Ensure that native libs and commands are in the right section of jmod file. http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/8927224bf054 jmod remove http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/e38d4d5251d5 Initial BDB load http://hg.openjdk.java.net/jigsaw/jigsaw/bdb/rev/a1985f14b030 Votes are due by May 25, 2012, 12:00 PDT. Only current jigsaw Committers [1] are eligible to vote on this nomination. For Lazy Consensus voting instructions, see [2]. -Alan. [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#committer-vote From mandy.chung at oracle.com Fri May 11 11:36:53 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 11 May 2012 11:36:53 -0700 Subject: CFV: New jigsaw Committer: Chris Hegarty In-Reply-To: <4FAD5864.5060107@oracle.com> References: <4FAD5864.5060107@oracle.com> Message-ID: <4FAD5C45.8050500@oracle.com> Vote: yes Mandy From jonathan.gibbons at oracle.com Fri May 11 11:52:48 2012 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 11 May 2012 11:52:48 -0700 Subject: CFV: New jigsaw Committer: Chris Hegarty In-Reply-To: <4FAD5864.5060107@oracle.com> References: <4FAD5864.5060107@oracle.com> Message-ID: <4FAD6000.1010100@oracle.com> Vote: yes On 05/11/2012 11:20 AM, Alan Bateman wrote: > I hereby nominate Chris Hegarty to jigsaw Committer. > > Chris has reviewer role in the jdk6, jdk7, jdk7u, jdk8 projects. He is > lead for the sctp project. > > Chris has contributed several significant changes to this project. > Here's the list of changes that I could find (specific links as > log?rev=chegar will match the 200+ other changes that he has pushed to > jdk7 and jdk8). > > Support installation of commands, configuration and native libraries > outside of module library > http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/a22f65ac0b9a > > Superfluous classes archive created for modules with no files > http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/2c2b55c87c8c > > jdk.ucrypto should be required > http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/1c3bbdc93d5d > > Jigsaw tests intermittently failing on some platforms > http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/8df8feaabfa7 > > Allow ModulesProblemList to be extended > http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/830c9470f368 > > Ensure that native libs and commands are in the right section of jmod > file. > http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/8927224bf054 > > jmod remove > http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/e38d4d5251d5 > > Initial BDB load > http://hg.openjdk.java.net/jigsaw/jigsaw/bdb/rev/a1985f14b030 > > Votes are due by May 25, 2012, 12:00 PDT. > > Only current jigsaw Committers [1] are eligible to vote on this > nomination. For Lazy Consensus voting instructions, see [2]. > > -Alan. > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote From karen.kinnear at oracle.com Fri May 11 11:57:18 2012 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 11 May 2012 14:57:18 -0400 Subject: CFV: New jigsaw Committer: Chris Hegarty In-Reply-To: <4FAD5864.5060107@oracle.com> References: <4FAD5864.5060107@oracle.com> Message-ID: <3C79F4BB-593C-4C3E-B87F-684462BCB8D6@oracle.com> Vote: yes Karen On May 11, 2012, at 2:20 PM, Alan Bateman wrote: > I hereby nominate Chris Hegarty to jigsaw Committer. > > Chris has reviewer role in the jdk6, jdk7, jdk7u, jdk8 projects. He is lead for the sctp project. > > Chris has contributed several significant changes to this project. Here's the list of changes that I could find (specific links as log?rev=chegar will match the 200+ other changes that he has pushed to jdk7 and jdk8). > > Support installation of commands, configuration and native libraries outside of module library > http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/a22f65ac0b9a > > Superfluous classes archive created for modules with no files > http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/2c2b55c87c8c > > jdk.ucrypto should be required > http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/1c3bbdc93d5d > > Jigsaw tests intermittently failing on some platforms > http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/8df8feaabfa7 > > Allow ModulesProblemList to be extended > http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/830c9470f368 > > Ensure that native libs and commands are in the right section of jmod file. > http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/8927224bf054 > > jmod remove > http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/e38d4d5251d5 > > Initial BDB load > http://hg.openjdk.java.net/jigsaw/jigsaw/bdb/rev/a1985f14b030 > > Votes are due by May 25, 2012, 12:00 PDT. > > Only current jigsaw Committers [1] are eligible to vote on this nomination. For Lazy Consensus voting instructions, see [2]. > > -Alan. > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote From dalibor.topic at oracle.com Fri May 11 13:00:59 2012 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Fri, 11 May 2012 22:00:59 +0200 Subject: CFV: New jigsaw Committer: Chris Hegarty In-Reply-To: <4FAD5864.5060107@oracle.com> References: <4FAD5864.5060107@oracle.com> Message-ID: <4FAD6FFB.2060203@oracle.com> Vote: Yes! cheers. dalibor topic -- Oracle Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Gesch?ftsf?hrer: J?rgen Kunz Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Green Oracle Oracle is committed to developing practices and products that help protect the environment From sean.mullan at oracle.com Fri May 11 13:14:15 2012 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 11 May 2012 16:14:15 -0400 Subject: CFV: New jigsaw Committer: Chris Hegarty In-Reply-To: <4FAD5864.5060107@oracle.com> References: <4FAD5864.5060107@oracle.com> Message-ID: <4FAD7317.6000702@oracle.com> Vote: yes On 5/11/12 2:20 PM, Alan Bateman wrote: > I hereby nominate Chris Hegarty to jigsaw Committer. > > Chris has reviewer role in the jdk6, jdk7, jdk7u, jdk8 projects. He is > lead for the sctp project. > > Chris has contributed several significant changes to this project. > Here's the list of changes that I could find (specific links as > log?rev=chegar will match the 200+ other changes that he has pushed to > jdk7 and jdk8). > > Support installation of commands, configuration and native libraries > outside of module library > http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/a22f65ac0b9a > > Superfluous classes archive created for modules with no files > http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/2c2b55c87c8c > > jdk.ucrypto should be required > http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/1c3bbdc93d5d > > Jigsaw tests intermittently failing on some platforms > http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/8df8feaabfa7 > > Allow ModulesProblemList to be extended > http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/830c9470f368 > > Ensure that native libs and commands are in the right section of jmod file. > http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/8927224bf054 > > jmod remove > http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/e38d4d5251d5 > > Initial BDB load > http://hg.openjdk.java.net/jigsaw/jigsaw/bdb/rev/a1985f14b030 > > Votes are due by May 25, 2012, 12:00 PDT. > > Only current jigsaw Committers [1] are eligible to vote on this > nomination. For Lazy Consensus voting instructions, see [2]. > > -Alan. > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote From david.holmes at oracle.com Sat May 12 05:55:37 2012 From: david.holmes at oracle.com (David Holmes) Date: Sat, 12 May 2012 22:55:37 +1000 Subject: Heads up, BDB coming, needed to support fast configuration In-Reply-To: <4FAD18F4.7010301@oracle.com> References: <4FA94CC0.7000408@oracle.com> <4FABCFFD.9060007@oracle.com> <5CF64427-C9EE-47BC-9A18-C1D4E4F737D7@oracle.com> <4FACFFEF.7090501@oracle.com> <4FAD1003.4060407@oracle.com> <4FAD18F4.7010301@oracle.com> Message-ID: <4FAE5DC9.8020908@oracle.com> On 11/05/2012 11:49 PM, Alan Bateman wrote: > On 11/05/2012 14:11, Roger Riggs wrote: >> Hi Chris, >> >> Instead of synchronizing the method on the signature the synchronization >> should be done internally. That will give more flexibility in the >> future if the >> internal data structure or interface changes without needing to change >> the method signature. > AFAIK, this isn't considered part of the method signature and so > wouldn't be an API change. Correct. "synchronized" on a method is an implementation detail not part of the signature - it can be changed at will. David ----- > -Alan. From leonardoavs at gmail.com Sat May 12 09:32:26 2012 From: leonardoavs at gmail.com (Leonardo Vargas Sandoval) Date: Sat, 12 May 2012 10:32:26 -0600 Subject: Open jmod files with tools like winrar. Message-ID: Hi: Is there any way to open jmod files with tools like winrar? -- Leonardo Andr?s Vargas Sandoval. From vincent.x.ryan at oracle.com Mon May 14 02:12:03 2012 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Mon, 14 May 2012 10:12:03 +0100 Subject: CFV: New jigsaw Committer: Chris Hegarty In-Reply-To: <4FAD5864.5060107@oracle.com> References: <4FAD5864.5060107@oracle.com> Message-ID: <4FB0CC63.7040200@oracle.com> Vote: Yes On 05/11/12 07:20 PM, Alan Bateman wrote: > I hereby nominate Chris Hegarty to jigsaw Committer. > > Chris has reviewer role in the jdk6, jdk7, jdk7u, jdk8 projects. He is > lead for the sctp project. > > Chris has contributed several significant changes to this project. > Here's the list of changes that I could find (specific links as > log?rev=chegar will match the 200+ other changes that he has pushed to > jdk7 and jdk8). > > Support installation of commands, configuration and native libraries > outside of module library > http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/a22f65ac0b9a > > Superfluous classes archive created for modules with no files > http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/2c2b55c87c8c > > jdk.ucrypto should be required > http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/1c3bbdc93d5d > > Jigsaw tests intermittently failing on some platforms > http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/8df8feaabfa7 > > Allow ModulesProblemList to be extended > http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/830c9470f368 > > Ensure that native libs and commands are in the right section of jmod file. > http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/8927224bf054 > > jmod remove > http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/e38d4d5251d5 > > Initial BDB load > http://hg.openjdk.java.net/jigsaw/jigsaw/bdb/rev/a1985f14b030 > > Votes are due by May 25, 2012, 12:00 PDT. > > Only current jigsaw Committers [1] are eligible to vote on this > nomination. For Lazy Consensus voting instructions, see [2]. > > -Alan. > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote From Alan.Bateman at oracle.com Mon May 14 02:36:26 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 14 May 2012 10:36:26 +0100 Subject: Open jmod files with tools like winrar. In-Reply-To: References: Message-ID: <4FB0D21A.6060406@oracle.com> On 12/05/2012 17:32, Leonardo Vargas Sandoval wrote: > Hi: > > Is there any way to open jmod files with tools like winrar? > This came up on another thread recently too, jpkg doesn't currently have the equivalent of dpkg-deb's --show, --contents, --extract, etc. If a format for module files is standardized then I'm sure that tools such as winrar will consider adding support, they probably support some or all of the specific content compression types already. -Alan. From paul.sandoz at oracle.com Mon May 14 03:52:56 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 14 May 2012 12:52:56 +0200 Subject: Jigsaw or JDK8 ? Re: Example code in JDK8 requiring change for modular function In-Reply-To: <3D56D481-469B-4308-ACC7-49E8FFF8E2F6@oracle.com> References: <4FA67039.7040202@oracle.com> <4FA68800.8000307@oracle.com> <820C47B9-8110-4E93-AC47-39C2C87615FC@oracle.com> <4FA78A2D.6010005@oracle.com> <4FA7F986.50809@oracle.com> <3D56D481-469B-4308-ACC7-49E8FFF8E2F6@oracle.com> Message-ID: <757EAE02-51E5-4A4F-B0C1-4A2E596C1B68@oracle.com> Hi, I thought we might get away with pushing certain platform changes for modularity related to Class/ClassLoader/ServiceLoader to the JDK8 forest but i really don't like the idea of a stub Platform class, and we really need to test such changes in classpath *and* modular mode. I want to tackle a bunch of ServiceLoader stuff in one commit some of which may require use of Platform (e.g. no caching of service instances in module mode). Therefore i think it best to wait until your web rev is committed and commit to Jigsaw. Paul. On May 9, 2012, at 12:51 PM, Paul Sandoz wrote: > > On May 7, 2012, at 6:34 PM, Mandy Chung wrote: > >> On 5/7/2012 1:52 AM, Paul Sandoz wrote: >>> So this is good example of where we could have two code paths based on a boolean check if running in module mode or not. >> >> >> It's good that you start looking into this example and others in JDK that >> will need to handle across the board. FYI. I added a few static methods >> in org.openjdk.jigsaw.Platform, part of the changes I posted [1]: >> http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/module-class-loading/webrev-jigsaw-ms/src/share/classes/org/openjdk/jigsaw/Platform.java.sdiff.html >> > > Thanks. > > To do general changes in JDK8 we will have to provide some of those static methods, say in a class in sun.misc as a temporary solution until Jigsaw is merged back. e.g. > > package sun.misc; > > // This class will be removed after the Jigsaw code base is pushed to JDK8 and classes that depend on this class > // and its methods will be updated to utilize the equivalent Jigsaw functionality > public class Platform { > public static boolean isModuleMode() { return false; } > } > > Paul. > >> Mandy >> >> [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2012-May/002498.html >> > From chris.hegarty at oracle.com Mon May 14 05:50:47 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 14 May 2012 13:50:47 +0100 Subject: Open jmod files with tools like winrar. In-Reply-To: <4FB0D21A.6060406@oracle.com> References: <4FB0D21A.6060406@oracle.com> Message-ID: <4FB0FFA7.1020503@oracle.com> On 14/05/2012 10:36, Alan Bateman wrote: > On 12/05/2012 17:32, Leonardo Vargas Sandoval wrote: >> Hi: >> >> Is there any way to open jmod files with tools like winrar? >> > This came up on another thread recently too, jpkg doesn't currently have > the equivalent of dpkg-deb's --show, --contents, --extract, etc. If a I'm looking into this. It shouldn't be difficult, but I'd like to do some refactoring while there. Right now, 'jmod extract ...' will extract the contents of the jmod files to the file system. You can then take a look at them. Actually, it might make more sense for 'extract' to be part of the jpkg command, rather than jmod. -Chris. > format for module files is standardized then I'm sure that tools such as > winrar will consider adding support, they probably support some or all > of the specific content compression types already. > > -Alan. From paul.sandoz at oracle.com Tue May 15 03:30:29 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 15 May 2012 12:30:29 +0200 Subject: Service com.sun.jdi.connect.spi.TransportService missing from jdk.tools Message-ID: <183B5922-4AFF-471C-832F-4C34864A7EEF@oracle.com> Hi, The service com.sun.jdi.connect.spi.TransportService is missing from the jdk.tools generated module-info.java, there is no reference in the jdk/make/modules/jdk.depconfig. Is that intentional? Another, related, service com.sun.jdi.connect.Connector is present in the jdk.tools module-info.java. Paul. From chris.hegarty at oracle.com Tue May 15 04:01:11 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 15 May 2012 12:01:11 +0100 Subject: Service com.sun.jdi.connect.spi.TransportService missing from jdk.tools In-Reply-To: <183B5922-4AFF-471C-832F-4C34864A7EEF@oracle.com> References: <183B5922-4AFF-471C-832F-4C34864A7EEF@oracle.com> Message-ID: <4FB23777.6030108@oracle.com> On 15/05/12 11:30, Paul Sandoz wrote: > Hi, > > The service com.sun.jdi.connect.spi.TransportService is missing from the jdk.tools generated module-info.java, there is no reference in the jdk/make/modules/jdk.depconfig. Is that intentional? I noticed this a while ago too. I think it was just an oversight. I have the trivial patch in my local repo, but didn't get a chance to review it yet. diff -r 8df8feaabfa7 make/modules/jdk.depconfig --- a/make/modules/jdk.depconfig Fri Feb 24 11:54:07 2012 +0000 +++ b/make/modules/jdk.depconfig Tue May 15 11:58:09 2012 +0100 @@ -516,3 +516,4 @@ @Provider(optional) com.sun.tools.jdi.VirtualMachineManagerImpl -> META-INF/services/com.sun.jdi.connect.Connector + com.sun.tools.jdi.VirtualMachineManagerImpl -> META-INF/services/com.sun.jdi.connect.spi.TransportService -Chris. > > Another, related, service com.sun.jdi.connect.Connector is present in the jdk.tools module-info.java. > > Paul. > From Alan.Bateman at oracle.com Tue May 15 04:03:25 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 15 May 2012 12:03:25 +0100 Subject: Service com.sun.jdi.connect.spi.TransportService missing from jdk.tools In-Reply-To: <183B5922-4AFF-471C-832F-4C34864A7EEF@oracle.com> References: <183B5922-4AFF-471C-832F-4C34864A7EEF@oracle.com> Message-ID: <4FB237FD.9090501@oracle.com> On 15/05/2012 11:30, Paul Sandoz wrote: > Hi, > > The service com.sun.jdi.connect.spi.TransportService is missing from the jdk.tools generated module-info.java, there is no reference in the jdk/make/modules/jdk.depconfig. Is that intentional? > > Another, related, service com.sun.jdi.connect.Connector is present in the jdk.tools module-info.java. > > Paul. > It's not intentional as JDI transport services can be installed as service providers. Adding the following to jdk.depconfig should fix it: @Provider(optional) com.sun.tools.jdi.VirtualMachineManagerImpl -> META-INF/services/com.sun.jdi.connect.spi.TransportService -Alan. From mandy.chung at oracle.com Tue May 15 07:44:52 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 15 May 2012 07:44:52 -0700 Subject: Service com.sun.jdi.connect.spi.TransportService missing from jdk.tools In-Reply-To: <4FB237FD.9090501@oracle.com> References: <183B5922-4AFF-471C-832F-4C34864A7EEF@oracle.com> <4FB237FD.9090501@oracle.com> Message-ID: <4FB26BE4.9070106@oracle.com> On 5/15/2012 4:03 AM, Alan Bateman wrote: > It's not intentional as JDI transport services can be installed as > service providers. Adding the following to jdk.depconfig should fix it: > > @Provider(optional) > com.sun.tools.jdi.VirtualMachineManagerImpl -> > META-INF/services/com.sun.jdi.connect.spi.TransportService This should fix it. FYI. jdk.depconfig was created based on some jdk7 old build that required some amount of code inspection. It could miss some new dependencies that were added since it was created. Mandy From alan.bateman at oracle.com Tue May 15 13:05:45 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 15 May 2012 20:05:45 +0000 Subject: hg: jigsaw/jigsaw/jdk: jdk.tools module missing requires optional service com.sun.jdi.connect.spi.TransportService Message-ID: <20120515200604.6E2E847328@hg.openjdk.java.net> Changeset: 4ef0a25952d6 Author: alanb Date: 2012-05-15 21:02 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/4ef0a25952d6 jdk.tools module missing requires optional service com.sun.jdi.connect.spi.TransportService ! make/modules/jdk.depconfig From alan.bateman at oracle.com Wed May 16 08:10:37 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 16 May 2012 15:10:37 +0000 Subject: hg: jigsaw/jigsaw: Build the bdb repository Message-ID: <20120516151037.69B8147352@hg.openjdk.java.net> Changeset: 44cca01887de Author: chegar Date: 2012-05-16 16:02 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/rev/44cca01887de Build the bdb repository ! Makefile ! make/Defs-internal.gmk ! make/README.pre-components + make/bdb-rules.gmk ! make/jdk-rules.gmk ! make/jprt.properties ! make/sanity-rules.gmk ! make/scripts/hgforest.sh From alan.bateman at oracle.com Wed May 16 08:11:19 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 16 May 2012 15:11:19 +0000 Subject: hg: jigsaw/jigsaw/jdk: Build the bdb repository Message-ID: <20120516151138.2BB7347353@hg.openjdk.java.net> Changeset: 9b943f3452ac Author: chegar Date: 2012-05-16 16:02 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/9b943f3452ac Build the bdb repository ! make/common/Sanity.gmk ! make/common/shared/Defs-control.gmk ! make/common/shared/Defs-linux.gmk ! make/common/shared/Defs-macosx.gmk ! make/common/shared/Defs-solaris.gmk ! make/common/shared/Defs-windows.gmk ! make/common/shared/Defs.gmk ! make/common/shared/Sanity-Settings.gmk ! make/common/shared/Sanity.gmk ! make/java/java/Exportedfiles.gmk ! make/java/java/FILES_c.gmk ! make/java/java/FILES_java.gmk ! make/java/java/Makefile ! make/java/java/mapfile-vers ! make/java/redist/Makefile + src/share/classes/org/openjdk/jigsaw/PersistentTreeMap.java + src/share/native/org/openjdk/jigsaw/PersistentTreeMap.c + src/share/native/org/openjdk/jigsaw/PersistentTreeMap.h + src/solaris/native/org/openjdk/jigsaw/PersistentTreeMap_md.c + src/windows/native/org/openjdk/jigsaw/PersistentTreeMap_md.c + test/org/openjdk/jigsaw/PersistentTreeMap/Basher.java + test/org/openjdk/jigsaw/PersistentTreeMap/Basic.java From Alan.Bateman at oracle.com Wed May 16 10:42:10 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 16 May 2012 18:42:10 +0100 Subject: JDK support for VM to read classes from modules in a module library In-Reply-To: <4FA4CAF0.8000008@oracle.com> References: <4FA4CAF0.8000008@oracle.com> Message-ID: <4FB3E6F2.7010107@oracle.com> On 05/05/2012 07:38, Mandy Chung wrote: > : > You can also look at all changes together in this webrev: > > http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/module-class-loading/webrev-all/ > I've gone through the changes in the combined webrev, except for jigsaw.c where I only skimmed it because it's tied to the current configuration and so will change. I think the native interface looks fine, the only minor comment is that I'd probably use typedef struct module. Of the Class.forName usages that have changed then one that didn't look right is Properties where the workaround is to use the loader for the base module to load XMLUtils. Given that XMLUtil is currently in the jaxp module (and I know this isn't quite right either as JAXP is a standalone technology etc.) then I would think that the Properties code will need to do a Class.forName on an exported javax.xml type and use that loader (or alternative use jdk.jaxp). In ServiceLoader you've changed the comment at L515 to "caller's class loader" but it should be "the caller's caller's class loader". I didn't quite get why src/share/native/java/lang/System.c was changed, was this for debugging? Otherwise I look forward to see this in, along with Karen's patch. -Alan From mandy.chung at oracle.com Wed May 16 11:44:02 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 16 May 2012 11:44:02 -0700 Subject: JDK support for VM to read classes from modules in a module library In-Reply-To: <4FB3E6F2.7010107@oracle.com> References: <4FA4CAF0.8000008@oracle.com> <4FB3E6F2.7010107@oracle.com> Message-ID: <4FB3F572.9000300@oracle.com> On 5/16/2012 10:42 AM, Alan Bateman wrote: > On 05/05/2012 07:38, Mandy Chung wrote: >> : >> You can also look at all changes together in this webrev: >> >> http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/module-class-loading/webrev-all/ >> > I've gone through the changes in the combined webrev, except for > jigsaw.c where I only skimmed it because it's tied to the current > configuration and so will change. > > I think the native interface looks fine, the only minor comment is > that I'd probably use typedef struct module. Yes, I should use typedef. > > Of the Class.forName usages that have changed then one that didn't > look right is Properties where the workaround is to use the loader for > the base module to load XMLUtils. Given that XMLUtil is currently in > the jaxp module (and I know this isn't quite right either as JAXP is a > standalone technology etc.) then I would think that the Properties > code will need to do a Class.forName on an exported javax.xml type and > use that loader (or alternative use jdk.jaxp). > We should change Class.forName to look for "javax.xml" type instead of "sun.util.xml.XMLUtils" since XMLUtils will be moved out from jaxp module as JAXP is a standalone technology. The workaround is also related to that Class.forName fails to find a class with a null loader (jdk.base requires jdk.jaxp.internal that exports sun.util.xml) that I leave it as an open issue to be investigated. Are you ok if I push this patch as it is and follow this as a separate patch (probably together with moving out XMLUtils from jdk.jaxp)? > In ServiceLoader you've changed the comment at L515 to "caller's class > loader" but it should be "the caller's caller's class loader". > Would it be better to say "class loader of the caller of ServiceLoader.load* method"? > I didn't quite get why src/share/native/java/lang/System.c was > changed, was this for debugging? > Improve the diagnosibilty. Change to the VM initialization sequence is hard to diagnose. I ran into a bug of mine that causes reading of system properties while it's being initialized. The change was to improve the diagnostic message and the system initialization is evolving during jigsaw development and this might be useful. BTW, the InternalError is only thrown in jigsaw/jigsaw. At some point, we will port this to jdk8 if it's helpful. > Otherwise I look forward to see this in, along with Karen's patch. > Thank you. Mandy From jesse.glick at oracle.com Wed May 16 12:07:57 2012 From: jesse.glick at oracle.com (Jesse Glick) Date: Wed, 16 May 2012 15:07:57 -0400 Subject: JDK support for VM to read classes from modules in a module library In-Reply-To: <4FB3E6F2.7010107@oracle.com> References: <4FA4CAF0.8000008@oracle.com> <4FB3E6F2.7010107@oracle.com> Message-ID: <4FB3FB0D.30802@oracle.com> On 05/16/2012 01:42 PM, Alan Bateman wrote: > [...In Properties] the workaround is to use the loader for the base module to load > XMLUtils. Given that XMLUtil is currently in the jaxp module (and I know this isn't quite right either as JAXP is a standalone technology etc.) then I would think that > the Properties code will need to do a Class.forName on an exported javax.xml type and use that loader (or alternative use jdk.jaxp). You have a module system now, why not clean this up and get rid of the reflection (and cyclic dependency)? module jdk.base { ... view sun.jaxp.bridge { permits jdk.jaxp; export sun.misc; } requires optional service sun.misc.XMLUtils; } package sun.misc; public interface XMLUtils { void load(Properties props, InputStream in) throws IOException, InvalidPropertiesFormatException; void save(Properties props, OutputStream os, String comment, String encoding) throws IOException; } package java.util; public class Properties { ... @RequireOptionalModule("jdk.jaxp") public synchronized void loadFromXML(InputStream in) throws IOException, InvalidPropertiesFormatException { try { ServiceLoader.loadInstalled(XMLUtils.class).iterator().next().load(this, in); } catch (NoSuchElementException x) { throw new ModuleNotPresentException("jdk.jaxp missing", x); } } @RequireOptionalModule("jdk.jaxp") public void storeToXML(OutputStream os, String comment, String encoding) throws IOException { try { ServiceLoader.loadInstalled(XMLUtils.class).iterator().next().save(this, os, comment, encoding); } catch (NoSuchElementException x) { throw new ModuleNotPresentException("jdk.jaxp missing", x); } } } module jdk.jaxp { ... requires sun.jaxp.bridge; provides service sun.misc.XMLUtils with ...; } From jaroslav.tulach at oracle.com Wed May 16 12:44:21 2012 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Wed, 16 May 2012 21:44:21 +0200 Subject: Eliminate cyclic deps was: JDK support for VM to read classes from modules in a module library In-Reply-To: <4FB3FB0D.30802@oracle.com> References: <4FA4CAF0.8000008@oracle.com> <4FB3E6F2.7010107@oracle.com> <4FB3FB0D.30802@oracle.com> Message-ID: <9699673.ZWqLbcu2dK@logoutik> Dne St 16. kv?tna 2012 15:07:57, Jesse Glick napsal(a): > On 05/16/2012 01:42 PM, Alan Bateman wrote: > > [...In Properties] the workaround is to use the loader for the base module > > to load XMLUtils. Given that XMLUtil is currently in the jaxp module (and > > I know this isn't quite right either as JAXP is a standalone technology > > etc.) then I would think that the Properties code will need to do a > > Class.forName on an exported javax.xml type and use that loader (or > > alternative use jdk.jaxp). > You have a module system now, why not clean this up and get rid of the > reflection (and cyclic dependency)? Right. Cyclic dependencies are only needed if a class from depending module sticks out from a public API. Otherwise use ServiceLoader and eliminate cycles. Btw. Jesse's code below is a modern variant of my 2009 suggestion: http://source.apidesign.org/hg/jdk/file/modularize/src/share/classes/java/util/Properties.java#l933 http://source.apidesign.org/hg/jdk/file/modularize/src/share/classes/sun/util/xml/PropertiesXMLUtils.java http://source.apidesign.org/hg/jdk/file/modularize/src/share/classes/sun/util/xml/DefaultPropertiesXMLUtils.java -jt > > module jdk.base { > ... > view sun.jaxp.bridge { > permits jdk.jaxp; > export sun.misc; > } > requires optional service sun.misc.XMLUtils; > } > package sun.misc; > public interface XMLUtils { > void load(Properties props, InputStream in) throws IOException, > InvalidPropertiesFormatException; void save(Properties props, OutputStream > os, String comment, String encoding) throws IOException; } > package java.util; > public class Properties { > ... > @RequireOptionalModule("jdk.jaxp") > public synchronized void loadFromXML(InputStream in) throws IOException, > InvalidPropertiesFormatException { try { > > ServiceLoader.loadInstalled(XMLUtils.class).iterator().next().load(this, > in); } catch (NoSuchElementException x) { > throw new ModuleNotPresentException("jdk.jaxp missing", x); > } > } > @RequireOptionalModule("jdk.jaxp") > public void storeToXML(OutputStream os, String comment, String encoding) > throws IOException { try { > > ServiceLoader.loadInstalled(XMLUtils.class).iterator().next().save(this, > os, comment, encoding); } catch (NoSuchElementException x) { > throw new ModuleNotPresentException("jdk.jaxp missing", x); > } > } > } > module jdk.jaxp { > ... > requires sun.jaxp.bridge; > provides service sun.misc.XMLUtils with ...; > } From mandy.chung at oracle.com Wed May 16 13:39:20 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 16 May 2012 13:39:20 -0700 Subject: JDK support for VM to read classes from modules in a module library In-Reply-To: <4FB3FB0D.30802@oracle.com> References: <4FA4CAF0.8000008@oracle.com> <4FB3E6F2.7010107@oracle.com> <4FB3FB0D.30802@oracle.com> Message-ID: <4FB41078.9010306@oracle.com> On 5/16/2012 12:07 PM, Jesse Glick wrote: > On 05/16/2012 01:42 PM, Alan Bateman wrote: >> [...In Properties] the workaround is to use the loader for the base >> module to load >> XMLUtils. Given that XMLUtil is currently in the jaxp module (and I >> know this isn't quite right either as JAXP is a standalone technology >> etc.) then I would think that >> the Properties code will need to do a Class.forName on an exported >> javax.xml type and use that loader (or alternative use jdk.jaxp). > > You have a module system now, why not clean this up and get rid of the > reflection (and cyclic dependency)? Right - there are opportunities in the jdk code for this kind of clean up but not for this XMLUtils case unfortunately because JAXP is a standalone technology [1] as Alan and I mention. One can install a complete and newer implementation of JAXP to replace the one that was provided in the original implementation of the Java Platform. XMLUtils is our own implementation class or a service interface that is implementation-specific as you propose. JAXP provided by other vendor would not provide the XMLUtils service unless it's part of the specification. Hence we probably have to move sun.util.xml.XMLUtils back to the jdk.base module and it is fine since it only uses the standard jaxp API. Mandy [1] http://docs.oracle.com/javase/6/docs/technotes/guides/standards/ From jesse.glick at oracle.com Wed May 16 14:48:13 2012 From: jesse.glick at oracle.com (Jesse Glick) Date: Wed, 16 May 2012 17:48:13 -0400 Subject: JDK support for VM to read classes from modules in a module library In-Reply-To: <4FB41078.9010306@oracle.com> References: <4FA4CAF0.8000008@oracle.com> <4FB3E6F2.7010107@oracle.com> <4FB3FB0D.30802@oracle.com> <4FB41078.9010306@oracle.com> Message-ID: <4FB4209D.1040704@oracle.com> On 05/16/2012 04:39 PM, Mandy Chung wrote: > JAXP provided by other vendor would not provide the XMLUtils service unless it's part of the specification. No need to touch JAXP itself: module jdk.base { ... view sun.jaxp.bridge { permits sun.jaxp.bridge.impl; // <-- exports sun.misc; } requires optional service sun.misc.XMLUtils; } // jdk.base classes as in first message module jdk.jaxp { // unmodified } module sun.jaxp.bridge.impl { requires jdk.jaxp; // or its vendor substitute requires sun.jaxp.bridge; provides service sun.misc.XMLUtils with sun.misc.XMLUtilsImpl; } package sun.misc; public class XMLUtilsImpl implements XMLUtils { // call javax.xml.** methods } As Yarda's message pointed out, the same bridge module could deal with XML-format Preferences, and you could supply a fallback implementation based on something like NanoXML for use in small environments where JAXP would be overkill. From paul.sandoz at oracle.com Thu May 17 01:01:17 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 17 May 2012 10:01:17 +0200 Subject: JDK support for VM to read classes from modules in a module library In-Reply-To: <4FB4209D.1040704@oracle.com> References: <4FA4CAF0.8000008@oracle.com> <4FB3E6F2.7010107@oracle.com> <4FB3FB0D.30802@oracle.com> <4FB41078.9010306@oracle.com> <4FB4209D.1040704@oracle.com> Message-ID: <8CAF201B-F80A-4D6C-A5D5-FA2B67BA8CEB@oracle.com> +1 on using services rather than reflection (+ special proxy in the Properties class). It makes it much clearer what the dependencies are. For backwards compatibility in classpath mode we should leave XMLUtils alone and use a new service class like sun.util.xml.PropertiesXMLUtils as shown by Yarda. Also in classpath mode we probably don't want to introduce a new "public" [*] extension point, so we should just use the default provider (or explicitly XMLUtils, as is the case today) On May 16, 2012, at 11:48 PM, Jesse Glick wrote: > module sun.jaxp.bridge.impl { > requires jdk.jaxp; // or its vendor substitute Or use java.jaxp where jdk.jaxp will declare: provides java.jaxp Paul. [*] no one depends on sun.misc right? :-) From Alan.Bateman at oracle.com Thu May 17 02:05:56 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 17 May 2012 10:05:56 +0100 Subject: JDK support for VM to read classes from modules in a module library In-Reply-To: <4FB3F572.9000300@oracle.com> References: <4FA4CAF0.8000008@oracle.com> <4FB3E6F2.7010107@oracle.com> <4FB3F572.9000300@oracle.com> Message-ID: <4FB4BF74.8010403@oracle.com> On 16/05/2012 19:44, Mandy Chung wrote: > > We should change Class.forName to look for "javax.xml" type instead of > "sun.util.xml.XMLUtils" since XMLUtils will be moved out from jaxp > module as JAXP is a standalone technology. > > The workaround is also related to that Class.forName fails to find a > class with a null loader (jdk.base requires jdk.jaxp.internal that > exports sun.util.xml) that I leave it as an open issue to be > investigated. Are you ok if I push this patch as it is and follow this > as a separate patch (probably together with moving out XMLUtils from > jdk.jaxp)? Yes, I'm okay with this as the we need to move this forward and get the native interface and VM changes in place. We can come to an agreement on what to do with JAXP in the continuation of the thread. > >> In ServiceLoader you've changed the comment at L515 to "caller's >> class loader" but it should be "the caller's caller's class loader". >> > > Would it be better to say "class loader of the caller of > ServiceLoader.load* method"? That's fine. > >> I didn't quite get why src/share/native/java/lang/System.c was >> changed, was this for debugging? >> > > Improve the diagnosibilty. Change to the VM initialization sequence > is hard to diagnose. I ran into a bug of mine that causes reading of > system properties while it's being initialized. The change was to > improve the diagnostic message and the system initialization is > evolving during jigsaw development and this might be useful. BTW, the > InternalError is only thrown in jigsaw/jigsaw. At some point, we > will port this to jdk8 if it's helpful. My preference is that anything that isn't Jigsaw specific should be pushed upstream to jdk8 so that we aren't carrying too many changes. -Alan. From zhangshj at linux.vnet.ibm.com Thu May 17 02:35:20 2012 From: zhangshj at linux.vnet.ibm.com (Shi Jun Zhang) Date: Thu, 17 May 2012 17:35:20 +0800 Subject: JDK support for VM to read classes from modules in a module library In-Reply-To: References: <4FA4CAF0.8000008@oracle.com> Message-ID: <4FB4C658.8030708@linux.vnet.ibm.com> On 5/8/2012 8:48 AM, Karen Kinnear wrote: > Webrev for the VM changes: > http://cr.openjdk.java.net/~acorn/vm-module-class-loading/webrev/ > > VM code includes both class loading changes for base module loader, as well as incremental perfdata timer information > to help us track detailed class loading performance. > > thanks, > Karen > > On May 5, 2012, at 2:38 AM, Mandy Chung wrote: > >> Karen and I have been working on implementing the support in the VM and library to read classes from a module library in native and proper system initialization for modules. This will replace the current workaround of using bootclasspath in module mode. I have put together a set of slides [1] to give an overview of this work (thanks to Alex, Karen, and Alan for their feedback and improvements). >> >> This work includes several pieces: >> 1) Jigsaw native library interface that the VM will use to search and read classes from the base module >> >> This replaces the existing mechanism in the VM that searches and reads classes from rt.jar and the default bootclasspath (that no longer exists in modular JDK) for loading bootstrap classes. >> >> Webrev for the jdk change: >> http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/module-class-loading/webrev-jigsaw-ms/ >> >> Karen will send out the webrev for the VM change separately. >> >> The jigsaw native library interface is defined in jigsaw.h and its implementation is in jigsaw.c. The temporary hack in org.openjdk.jigsaw.BootLoader to extend the bootclasspath for the base and other modules is now removed. I have added a few static methods in the Platform class for the system to determine if it's running in module mode, if a given class loader defines system classes, and to get the base module loader (refer below for details). >> >> This webrev also includes some minor cleanup in the modularization such as fixing the jdk.desktop requires optional jdk.jaxp that should not be an optional dependency and moving java.text.Bidi class to the base module (Alan has eliminated the bidi to desktop dependency a while ago). >> >> 2) system modules to be granted with AllPermissions >> >> Today the classes on bootclasspath are granted with AllPermissions. In a modular JDK, we need to a way to determine if it's a system module and grants with AllPermission. Alan has implemented the module URL as the code source to modules and grants all permissions to jdk.* modules, as an interim solution. Sean is looking into different options and a reliable way to identify a system module. >> >> Webrev at: >> http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/module-class-loading/webrev-module-url/ >> >> 3) The JDK code needs to be audit for the use of class loader and update for modules as listed in the open issues. We have made changes in a few places in the JDK to fix some of the low hanging fruits that get more of the existing tests to pass when running as modules. >> >> a. bootstrap classes skip permission check e.g. ClassLoader.getClassLoader() >> >> Today bootstrap classes are loaded by null loader. In module mode, system modules are loaded by non-null module loader. A method Platform.isPlatformLoader(ClassLoader) is added to replace the "cl == null" check. Note that these methods may be more appropriate to live in java.lang or some other class but I add it in Platform class for now. >> >> b. Platform.getBaseModuleLoader() - the base module loader is needed when the library >> code wants to load a class in base's optional dependency (e.g XML) because Class.getClassLoader() currently returns null (see the open issue listed in [1]). >> >> c. replace classloader parameter in the Class.forName call from null to an appropriate loader when loading a class that is not in the base module (e.g. management, scripting, etc). >> >> Webrev: >> http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/module-class-loading/webrev-class-loader-fix/ >> >> There will be more of this kind of changes required in the jdk and this is just to set a few examples to get going. >> >> You can also look at all changes together in this webrev: >> http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/module-class-loading/webrev-all/ >> >> Thanks >> Mandy >> [1] http://openjdk.java.net/projects/jigsaw/doc/module-class-loading.pdf Hi Karen, I'm trying your patch but find src/share/vm/classfile/jigsaw.h is missing. -- Regards, Shi Jun Zhang From karen.kinnear at oracle.com Thu May 17 03:49:27 2012 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 17 May 2012 06:49:27 -0400 Subject: JDK support for VM to read classes from modules in a module library In-Reply-To: <4FB4C658.8030708@linux.vnet.ibm.com> References: <4FA4CAF0.8000008@oracle.com> <4FB4C658.8030708@linux.vnet.ibm.com> Message-ID: Shi Jun, Thank you for looking at these change. I just re-uploaded the webrev including the new jigsaw.h file. Apologies for missing the new file the first time. thanks, Karen On May 17, 2012, at 5:35 AM, Shi Jun Zhang wrote: > On 5/8/2012 8:48 AM, Karen Kinnear wrote: >> Webrev for the VM changes: >> http://cr.openjdk.java.net/~acorn/vm-module-class-loading/webrev/ >> >> VM code includes both class loading changes for base module loader, as well as incremental perfdata timer information >> to help us track detailed class loading performance. >> >> thanks, >> Karen >> >> On May 5, 2012, at 2:38 AM, Mandy Chung wrote: >> >>> Karen and I have been working on implementing the support in the VM and library to read classes from a module library in native and proper system initialization for modules. This will replace the current workaround of using bootclasspath in module mode. I have put together a set of slides [1] to give an overview of this work (thanks to Alex, Karen, and Alan for their feedback and improvements). >>> >>> This work includes several pieces: >>> 1) Jigsaw native library interface that the VM will use to search and read classes from the base module >>> >>> This replaces the existing mechanism in the VM that searches and reads classes from rt.jar and the default bootclasspath (that no longer exists in modular JDK) for loading bootstrap classes. >>> >>> Webrev for the jdk change: >>> http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/module-class-loading/webrev-jigsaw-ms/ >>> >>> Karen will send out the webrev for the VM change separately. >>> >>> The jigsaw native library interface is defined in jigsaw.h and its implementation is in jigsaw.c. The temporary hack in org.openjdk.jigsaw.BootLoader to extend the bootclasspath for the base and other modules is now removed. I have added a few static methods in the Platform class for the system to determine if it's running in module mode, if a given class loader defines system classes, and to get the base module loader (refer below for details). >>> >>> This webrev also includes some minor cleanup in the modularization such as fixing the jdk.desktop requires optional jdk.jaxp that should not be an optional dependency and moving java.text.Bidi class to the base module (Alan has eliminated the bidi to desktop dependency a while ago). >>> >>> 2) system modules to be granted with AllPermissions >>> >>> Today the classes on bootclasspath are granted with AllPermissions. In a modular JDK, we need to a way to determine if it's a system module and grants with AllPermission. Alan has implemented the module URL as the code source to modules and grants all permissions to jdk.* modules, as an interim solution. Sean is looking into different options and a reliable way to identify a system module. >>> >>> Webrev at: >>> http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/module-class-loading/webrev-module-url/ >>> >>> 3) The JDK code needs to be audit for the use of class loader and update for modules as listed in the open issues. We have made changes in a few places in the JDK to fix some of the low hanging fruits that get more of the existing tests to pass when running as modules. >>> >>> a. bootstrap classes skip permission check e.g. ClassLoader.getClassLoader() >>> >>> Today bootstrap classes are loaded by null loader. In module mode, system modules are loaded by non-null module loader. A method Platform.isPlatformLoader(ClassLoader) is added to replace the "cl == null" check. Note that these methods may be more appropriate to live in java.lang or some other class but I add it in Platform class for now. >>> >>> b. Platform.getBaseModuleLoader() - the base module loader is needed when the library >>> code wants to load a class in base's optional dependency (e.g XML) because Class.getClassLoader() currently returns null (see the open issue listed in [1]). >>> >>> c. replace classloader parameter in the Class.forName call from null to an appropriate loader when loading a class that is not in the base module (e.g. management, scripting, etc). >>> >>> Webrev: >>> http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/module-class-loading/webrev-class-loader-fix/ >>> >>> There will be more of this kind of changes required in the jdk and this is just to set a few examples to get going. >>> >>> You can also look at all changes together in this webrev: >>> http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/module-class-loading/webrev-all/ >>> >>> Thanks >>> Mandy >>> [1] http://openjdk.java.net/projects/jigsaw/doc/module-class-loading.pdf > > Hi Karen, > > I'm trying your patch but find src/share/vm/classfile/jigsaw.h is missing. > > -- > Regards, > > Shi Jun Zhang > > From Alan.Bateman at oracle.com Thu May 17 05:57:17 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 17 May 2012 13:57:17 +0100 Subject: JDK support for VM to read classes from modules in a module library In-Reply-To: <4FB4209D.1040704@oracle.com> References: <4FA4CAF0.8000008@oracle.com> <4FB3E6F2.7010107@oracle.com> <4FB3FB0D.30802@oracle.com> <4FB41078.9010306@oracle.com> <4FB4209D.1040704@oracle.com> Message-ID: <4FB4F5AD.8030700@oracle.com> On 16/05/2012 22:48, Jesse Glick wrote: > On 05/16/2012 04:39 PM, Mandy Chung wrote: >> JAXP provided by other vendor would not provide the XMLUtils service >> unless it's part of the specification. > > No need to touch JAXP itself: > > module jdk.base { > ... > view sun.jaxp.bridge { > permits sun.jaxp.bridge.impl; // <-- > exports sun.misc; > } > requires optional service sun.misc.XMLUtils; > } > // jdk.base classes as in first message > module jdk.jaxp { > // unmodified > } > module sun.jaxp.bridge.impl { > requires jdk.jaxp; // or its vendor substitute > requires sun.jaxp.bridge; > provides service sun.misc.XMLUtils with sun.misc.XMLUtilsImpl; > } > package sun.misc; > public class XMLUtilsImpl implements XMLUtils { > // call javax.xml.** methods > } > > As Yarda's message pointed out, the same bridge module could deal with > XML-format Preferences, and you could supply a fallback implementation > based on something like NanoXML for use in small environments where > JAXP would be overkill. This is nice in that it eliminates this optional dependency but it means we have another module to deal with. But there is more work required to make JAXP really replaceable. The main issue (I think) is that JAX-WS, its tools, and XML-DSIG rely on internal interfaces that JAXP currently exports via an internal view. I often wonder how this actually works today and whether people are dropping in completely different implementations of JAXP or just newer/older versions that just happen to have the same com.sun.org.** classes. -Alan From paul.sandoz at oracle.com Thu May 17 08:21:56 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 17 May 2012 17:21:56 +0200 Subject: Webrev for JAX-WS/JAXB/SAAJ services Message-ID: <9C6837C5-3582-4AE6-A208-4F0829C43E43@oracle.com> http://cr.openjdk.java.net/~psandoz/jigsaw/jaxws-services/webrev/ This is to make it easier for the team modularizing JAX-WS to experiment with using ServiceLoader. It's still to be determined whether the default service implementations will be declared with: provides service X with Y; in the module declaration e.g. since there is no point loading the default service provider if there is a non-default service provider declared in another module. As a side note it does make we wonder whether there should be a special case for a service, essentially a factory, of which there should be at most one (with an optional fallback to a default when are none). Paul. From karen.kinnear at oracle.com Thu May 17 08:45:04 2012 From: karen.kinnear at oracle.com (karen.kinnear at oracle.com) Date: Thu, 17 May 2012 15:45:04 +0000 Subject: hg: jigsaw/jigsaw/hotspot: 2 new changesets Message-ID: <20120517154509.0BA894738E@hg.openjdk.java.net> Changeset: baa3b116bddd Author: acorn Date: 2012-05-16 18:08 -0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/baa3b116bddd Summary: Initial VM changes to allow loading modules from a module library ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/classLoader.hpp + src/share/vm/classfile/jigsaw.h ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp Changeset: 0bff76062cba Author: acorn Date: 2012-05-17 09:41 -0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/0bff76062cba Summary: Fix jprt properties for open build targets. ! make/jprt.properties From Alan.Bateman at oracle.com Thu May 17 08:52:45 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 17 May 2012 16:52:45 +0100 Subject: Webrev for JAX-WS/JAXB/SAAJ services In-Reply-To: <9C6837C5-3582-4AE6-A208-4F0829C43E43@oracle.com> References: <9C6837C5-3582-4AE6-A208-4F0829C43E43@oracle.com> Message-ID: <4FB51ECD.1070502@oracle.com> On 17/05/2012 16:21, Paul Sandoz wrote: > http://cr.openjdk.java.net/~psandoz/jigsaw/jaxws-services/webrev/ > > This is to make it easier for the team modularizing JAX-WS to experiment with using ServiceLoader. Good, we need to get the JAX-WS changed to use ServiceLoader. I can push this for you. > > It's still to be determined whether the default service implementations will be declared with: > > provides service X with Y; > > in the module declaration e.g. since there is no point loading the default service provider if there is a non-default service provider declared in another module. > > > As a side note it does make we wonder whether there should be a special case for a service, essentially a factory, of which there should be at most one (with an optional fallback to a default when are none). > Alternatively this could consider as setting a preference, or preferred order. This may be something we will have to look into for aliases too. -Alan. From paul.sandoz at oracle.com Thu May 17 09:12:23 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 17 May 2012 18:12:23 +0200 Subject: Webrev for JAX-WS/JAXB/SAAJ services In-Reply-To: <4FB51ECD.1070502@oracle.com> References: <9C6837C5-3582-4AE6-A208-4F0829C43E43@oracle.com> <4FB51ECD.1070502@oracle.com> Message-ID: <77A74618-3A03-48E1-A252-B6CEBBA91BC6@oracle.com> On May 17, 2012, at 5:52 PM, Alan Bateman wrote: > On 17/05/2012 16:21, Paul Sandoz wrote: >> http://cr.openjdk.java.net/~psandoz/jigsaw/jaxws-services/webrev/ >> >> This is to make it easier for the team modularizing JAX-WS to experiment with using ServiceLoader. > Good, we need to get the JAX-WS changed to use ServiceLoader. > > I can push this for you. > Thanks. >> >> It's still to be determined whether the default service implementations will be declared with: >> >> provides service X with Y; >> >> in the module declaration e.g. since there is no point loading the default service provider if there is a non-default service provider declared in another module. >> >> >> As a side note it does make we wonder whether there should be a special case for a service, essentially a factory, of which there should be at most one (with an optional fallback to a default when are none). >> > Alternatively this could consider as setting a preference, or preferred order. This may be something we will have to look into for aliases too. > Yes, e.g. a default provider always occurs after any non-default. The "at most one" service provider may be useful if say there is an API module that requires factory-based services from only one implementation module. It may be considered a conflict if two or more vendor implementations are installed. Paul. From karen.kinnear at oracle.com Thu May 17 09:51:18 2012 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 17 May 2012 12:51:18 -0400 Subject: Request for Review: minor VM class loading change Message-ID: <1CF4443A-EAE6-486C-B21E-6AC59EB05BE0@oracle.com> Please review a minor change for the VM to handle a non-null base module loader. I've also added a new (potentially temporary) API JVM_GetModuleLoader to allow us to incrementally clean up logic that assumes that JVM_GetClassLoader returns null for the bootclasspath. Within the VM, we will continue to use null to represent module classes loaded by the vm. http://cr.openjdk.java.net/~acorn/non-null-module-loader/webrev/ thanks, Karen From david.lloyd at redhat.com Thu May 17 10:03:32 2012 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 17 May 2012 12:03:32 -0500 Subject: Request for Review: minor VM class loading change In-Reply-To: <1CF4443A-EAE6-486C-B21E-6AC59EB05BE0@oracle.com> References: <1CF4443A-EAE6-486C-B21E-6AC59EB05BE0@oracle.com> Message-ID: <4FB52F64.1090406@redhat.com> On 05/17/2012 11:51 AM, Karen Kinnear wrote: > > Please review a minor change for the VM to handle a non-null base module loader. I've also > added a new (potentially temporary) API JVM_GetModuleLoader to allow us to incrementally clean up logic that assumes > that JVM_GetClassLoader returns null for the bootclasspath. > > Within the VM, we will continue to use null to represent module classes loaded by the vm. > > http://cr.openjdk.java.net/~acorn/non-null-module-loader/webrev/ So is the ultimate goal then to move away from having JDK classes always return null for getClassLoader()? Or will that behavior remain? -- - DML From chris.hegarty at oracle.com Thu May 17 10:04:33 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 17 May 2012 18:04:33 +0100 Subject: RFR: jpkg contents/show commands Message-ID: <4FB52FA1.1070305@oracle.com> This change adds two new commands to the packaging tool. 'jpkg show' and 'jpkg contents', which came up on this list a few weeks ago. http://cr.openjdk.java.net/~chegar/jigsaw/jpkg_contents.00/webrev/ Also, included is various cleanup and restructuring, especially to ModuleFile, to put in place a structure to more easily support new compression algorithms. Specifically LZMA. I have a prototype from last year I need to rebase. For now, 'contents' and 'show' are only added jpkg, but I could see that these may be useful before installing a module into the module library, so could be applicable to the jmod command also? Or just jmod? If these new commands are to stay in jpkg long term we should probably change the command that builds the jmod/deb files to create/build, so 'jpkg create ... jmod'. Two specific implementation changes to draw attention to in the webrev: 1) ModuleFile.java (L535 new file). Resources were never being deflated in the module library. They are now. 2) Sean, Can you verify the changes to changes to Singer and ModuleFile.SignatureSection? All jigsaw signing related tests pass. -Chris. From jesse.glick at oracle.com Thu May 17 10:07:35 2012 From: jesse.glick at oracle.com (Jesse Glick) Date: Thu, 17 May 2012 13:07:35 -0400 Subject: Webrev for JAX-WS/JAXB/SAAJ services In-Reply-To: <77A74618-3A03-48E1-A252-B6CEBBA91BC6@oracle.com> References: <9C6837C5-3582-4AE6-A208-4F0829C43E43@oracle.com> <4FB51ECD.1070502@oracle.com> <77A74618-3A03-48E1-A252-B6CEBBA91BC6@oracle.com> Message-ID: <4FB53057.6080300@oracle.com> On 05/17/2012 12:12 PM, Paul Sandoz wrote: > e.g. a default provider always occurs after any non-default. Would seem simpler to not register this provider in module-info.java at all, and just use the simple idiom: for (Service s : ServiceLoader.load(Service.class)) { if (s.handles(arg)) { return s.dealWith(arg); } } // could of course also inline this code: Service s = new DefaultService(); return s.dealWith(arg); From Alan.Bateman at oracle.com Thu May 17 10:25:43 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 17 May 2012 18:25:43 +0100 Subject: Request for Review: minor VM class loading change In-Reply-To: <4FB52F64.1090406@redhat.com> References: <1CF4443A-EAE6-486C-B21E-6AC59EB05BE0@oracle.com> <4FB52F64.1090406@redhat.com> Message-ID: <4FB53497.6090005@oracle.com> On 17/05/2012 18:03, David M. Lloyd wrote: > > So is the ultimate goal then to move away from having JDK classes > always return null for getClassLoader()? Or will that behavior remain? When running with a classpath then everything should work as it does today and so it should return null. When running with modules then the question splits into a question for classes loaded by the "base" module and classes in other platform modules (all would previously have been loaded by the bootstrap class loader and so getClassLoader would have returned null). For the classes in the base module then it's still an open question and there are good questions to have it return a module class loader even though they are actually loaded by the VM built-in bootstrap loader. For classes in other modules then getClassLoader will return the appropriate ModuleClassLoader for that module. -Alan From sean.mullan at oracle.com Thu May 17 10:48:27 2012 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 17 May 2012 13:48:27 -0400 Subject: RFR: jpkg contents/show commands In-Reply-To: <4FB52FA1.1070305@oracle.com> References: <4FB52FA1.1070305@oracle.com> Message-ID: <4FB539EB.8060603@oracle.com> On 5/17/12 1:04 PM, Chris Hegarty wrote: > 2) Sean, > Can you verify the changes to changes to Singer and > ModuleFile.SignatureSection? All jigsaw signing related tests pass. It looks good. --Sean From karen.kinnear at oracle.com Thu May 17 11:42:05 2012 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 17 May 2012 14:42:05 -0400 Subject: Request for Review: minor VM class loading change In-Reply-To: <4FB52F64.1090406@redhat.com> References: <1CF4443A-EAE6-486C-B21E-6AC59EB05BE0@oracle.com> <4FB52F64.1090406@redhat.com> Message-ID: <2D231E9D-A17D-4F8A-8C64-C2D01B5A1B2A@oracle.com> David, Great question and I should have prefaced the code review with a better description of the motivation here. With the JDK split into multiple modules, and each module loaded by a different module loader, it would make sense for JDK classes to return a module loader in response to getClassLoader(). However, we would like to find a way to minimize the impact of the transition to modules on existing applications. So we would like to ask the community's help in understanding how much code in the field depends on a null return from getClassLoader() and what special behavior that triggers. We understand that code today has to be able to handle a null return, and we have had to offer APIs on other classes to work around not having a j.l.ClassLoader object, so yes, we expect there to be code that handles a null return. The question is more whether there are code paths that depend on a null return for specific behavior, and what specifically is that logic counting on. And we would love suggestions on the best way to find out this information. This set of changes and others to follow are intended to help set up an environment for experimenting with the impact of that potential change. thanks, Karen On May 17, 2012, at 1:03 PM, David M. Lloyd wrote: > On 05/17/2012 11:51 AM, Karen Kinnear wrote: >> >> Please review a minor change for the VM to handle a non-null base module loader. I've also >> added a new (potentially temporary) API JVM_GetModuleLoader to allow us to incrementally clean up logic that assumes >> that JVM_GetClassLoader returns null for the bootclasspath. >> >> Within the VM, we will continue to use null to represent module classes loaded by the vm. >> >> http://cr.openjdk.java.net/~acorn/non-null-module-loader/webrev/ > > So is the ultimate goal then to move away from having JDK classes always return null for getClassLoader()? Or will that behavior remain? > > > -- > - DML From mandy.chung at oracle.com Thu May 17 12:48:53 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 17 May 2012 12:48:53 -0700 Subject: Request for Review: minor VM class loading change In-Reply-To: <1CF4443A-EAE6-486C-B21E-6AC59EB05BE0@oracle.com> References: <1CF4443A-EAE6-486C-B21E-6AC59EB05BE0@oracle.com> Message-ID: <4FB55625.4010104@oracle.com> Karen, On 5/17/12 9:51 AM, Karen Kinnear wrote: > Please review a minor change for the VM to handle a non-null base module loader. I've also > added a new (potentially temporary) API JVM_GetModuleLoader to allow us to incrementally clean up logic that assumes > that JVM_GetClassLoader returns null for the bootclasspath. > > Within the VM, we will continue to use null to represent module classes loaded by the vm. > > http://cr.openjdk.java.net/~acorn/non-null-module-loader/webrev/ Looks good except in jni.cpp L397, the extra "NULL;" should be removed. Thanks for the patch that sets up the basis for us to experiment with getClassLoader() to return null vs non-null for classes in jdk.base module (an open issue listed in [1]). It'd be a step toward resolving this open issue. Mandy [1] http://openjdk.java.net/projects/jigsaw/doc/module-class-loading.pdf From karen.kinnear at oracle.com Thu May 17 13:07:09 2012 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 17 May 2012 16:07:09 -0400 Subject: Request for Review: minor VM class loading change In-Reply-To: <4FB55625.4010104@oracle.com> References: <1CF4443A-EAE6-486C-B21E-6AC59EB05BE0@oracle.com> <4FB55625.4010104@oracle.com> Message-ID: Mandy, Good catch. I will fix. thanks, Karen On May 17, 2012, at 3:48 PM, Mandy Chung wrote: > Karen, > > On 5/17/12 9:51 AM, Karen Kinnear wrote: >> Please review a minor change for the VM to handle a non-null base module loader. I've also >> added a new (potentially temporary) API JVM_GetModuleLoader to allow us to incrementally clean up logic that assumes >> that JVM_GetClassLoader returns null for the bootclasspath. >> >> Within the VM, we will continue to use null to represent module classes loaded by the vm. >> >> http://cr.openjdk.java.net/~acorn/non-null-module-loader/webrev/ > > Looks good except in jni.cpp L397, the extra "NULL;" should be removed. > > Thanks for the patch that sets up the basis for us to experiment with getClassLoader() to return null vs non-null for classes in jdk.base module (an open issue listed in [1]). It'd be a step toward resolving this open issue. > > Mandy > [1] http://openjdk.java.net/projects/jigsaw/doc/module-class-loading.pdf From mark.reinhold at oracle.com Thu May 17 17:12:17 2012 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 17 May 2012 17:12:17 -0700 Subject: Resolver and inefficiencies In-Reply-To: pascal@rapicault.net; Thu, 03 May 2012 17:03:40 EDT; <838B4257-8E67-4E75-832E-5BDA7689D408@rapicault.net> Message-ID: <20120518001217.12C8217D4@eggemoggin.niobe.net> 2012/5/3 14:03 -0700, pascal at rapicault.net: > My name is Pascal Rapicault. I'm the maintainer of the Eclipse p2 > resolver (the dependency resolver used by Eclipse install mechanism). > > Rather than implementing a resolver from scratch, since the dependency > problem is NP complete (I assume the jigsaw also is), we have been > using a SAT solver (http://www.sat4j.org) and have been quite happy > with it. It is very efficient and scales very well. > > If this can be helpful, maybe we could find a way to share knowledge on > this. Hi Pascal, nice to meet you. It'd be great if we could learn more about how p2 uses Sat4j. I've been thinking for a while now that we should explore this option for Jigsaw. Even if our resolution problem winds up not being NP-hard, a good SAT solver can likely be more efficient than the simpleminded backtracking algorithm we use now. I found http://wiki.eclipse.org/Equinox_P2_Resolution -- is that the best overview document? - Mark From jaroslav.tulach at oracle.com Fri May 18 00:07:06 2012 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Fri, 18 May 2012 09:07:06 +0200 Subject: No deps on JAXP was: JDK support for VM to read classes from modules in a module library In-Reply-To: <4FB4F5AD.8030700@oracle.com> References: <4FA4CAF0.8000008@oracle.com> <4FB4209D.1040704@oracle.com> <4FB4F5AD.8030700@oracle.com> Message-ID: <1765464.kiN6L90L7J@logoutik> Dne ?t 17. kv?tna 2012 13:57:17, Alan Bateman napsal(a): > > package sun.misc; > > public class XMLUtilsImpl implements XMLUtils { > > > > // call javax.xml.** methods > > > > } > > > > As Yarda's message pointed out, the same bridge module could deal with > > XML-format Preferences, and you could supply a fallback implementation > > based on something like NanoXML for use in small environments where > > JAXP would be overkill. > > This is nice in that it eliminates this optional dependency but it means > we have another module to deal with. Welcome to the modular world. There is no need to be afraid of proliferation of modules if there is a way to track and manage their dependencies. There was a claim that re-use (e.g. finer granularity) complicates use[1] (as it is easier to depend on the whole monolithic piece), but with require service and provide service meta information these two forces can be balanced quite nicely[2]. In case of modularization of JDK I'd advocate focus on as easy re-use as possible. Not only it will turn JDK into set of flexible libraries, but it will also simplify the job for IDEs and javac. Why should anyone working on java.base module sources have to parse JAXP? To give old schoolers equivalent "use" experience with JDK8 as they used to have with JDK7, I think it is enough to have one "JavaSE at 8.0" module with convenient dependencies which those guys can depend on. As far as I understand this is the Jigsaw plan, so balance between use and re-use should be there. Should you agree that elimination of java.base => JAXP linkage dependency is reasonable goal and you just don't want to bother with it now, I'd be happy to try it myself and prepare a patch. -jt [1] http://www.amazon.com/Java-Application-Architecture-Modularity- Development/dp/0321247132/ref=ntt_at_ep_dpt_1 [2] http://wiki.apidesign.org/images/e/ec/Patterns_for_Modularity_II- _Revenge_of_the_Patterns.pdf From chris.hegarty at oracle.com Fri May 18 07:09:15 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 18 May 2012 15:09:15 +0100 Subject: Preview builds of Jigsaw available In-Reply-To: <4FABA3C2.2010303@oracle.com> References: <4FABA3C2.2010303@oracle.com> Message-ID: <4FB6580B.20800@oracle.com> Alan, Do we want to link these preview builds off the main project page? Or maybe I just can't find it. -Chris On 10/05/12 12:17, Alan Bateman wrote: > > We now have a download page on java.net to host preview builds from Oracle: > > http://jdk8.java.net/jigsaw/ > > This should be useful to those that want to try out Project Jigsaw > and/or the current prototype of the modular JDK without needing to build > it themselves. > > The preview builds come in two forms: > > - "JDK modules image". This is essentially equivalent to the normal JDK > download except that everything is pre-installed as modules. > > - The other download choice is for those that wish to experiment with a > ready-to-assemble JDK. The download contains an image that is a base > runtime and also contains a directory of jmod packages that are the JDK > modules. These modules can be installed with the included jmod tool as > needed. > > At this time there isn't a download for Mac OS X, that should come soon > (a small issue meant it didn't make the initial push). Another issue is > that the Solaris downloads are the 32-bit binaries only for now. > > As these are preview builds they will of course be issues and bugs. The > main issue that people will likely run into is that crypto is currently > disabled. There are also several areas in the JDK that require API and > implementation changes to work as modules and that will come in time. > > Thanks to Roger Yeung, David Katleman, Christine Lu from the Release > Engineering team in Oracle for making these builds available. At this > time we haven't decided how often to update the bundles so it will > likely be "as needed" for now. > > -Alan. From alan.bateman at oracle.com Fri May 18 08:27:52 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 18 May 2012 15:27:52 +0000 Subject: hg: jigsaw/jigsaw/jdk: Prepare for JAX-WS to use ServiceLoader Message-ID: <20120518152811.6286B473DD@hg.openjdk.java.net> Changeset: 774db6d6b90f Author: psandoz Date: 2012-05-18 16:27 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/774db6d6b90f Prepare for JAX-WS to use ServiceLoader ! make/modules/jdk.depconfig From sean.mullan at oracle.com Fri May 18 12:48:58 2012 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 18 May 2012 15:48:58 -0400 Subject: Review Request: signed module code restructuring/refactoring Message-ID: <4FB6A7AA.50408@oracle.com> I have restructured and refactored the signed module code. In particular I have removed the ModuleFileVerifier and ModuleFileSigner interfaces (they really didn't add any value) and made a few improvements here and there. webrev: http://cr.openjdk.java.net/~mullan/jigsaw/webrevs/signed-module-refactor/webrev.00/ Thanks, Sean From mandy.chung at oracle.com Fri May 18 13:24:04 2012 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 18 May 2012 20:24:04 +0000 Subject: hg: jigsaw/jigsaw/jdk: 4 new changesets Message-ID: <20120518202455.92494473EE@hg.openjdk.java.net> Changeset: d5768c1041b6 Author: alanb Date: 2012-03-01 11:26 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/d5768c1041b6 Add code source to modules; jdk.* modules granted all permissions by default ! make/modules/modules.config ! make/sun/net/FILES_java.gmk ! src/share/classes/org/openjdk/jigsaw/Loader.java + src/share/classes/sun/net/www/protocol/module/Handler.java Changeset: 7b282c826118 Author: mchung Date: 2012-05-18 12:48 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/7b282c826118 Support for VM to read classes from module library via jigsaw native interface Reviewed-by: alanb, psandoz ! make/java/java/FILES_c.gmk ! make/java/java/mapfile-vers ! make/modules/modules.config ! make/modules/modules.group ! make/modules/modules.properties ! make/modules/optional.depconfig ! src/share/classes/com/sun/jmx/mbeanserver/MXBeanMapping.java ! src/share/classes/com/sun/jmx/remote/internal/IIOPHelper.java ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/ClassLoader.java ! src/share/classes/java/lang/Thread.java ! src/share/classes/java/lang/management/ManagementFactory.java ! src/share/classes/java/lang/management/PlatformComponent.java ! src/share/classes/java/lang/module/ModuleClassLoader.java ! src/share/classes/java/util/Properties.java ! src/share/classes/java/util/ResourceBundle.java ! src/share/classes/java/util/ServiceLoader.java ! src/share/classes/java/util/prefs/Preferences.java ! src/share/classes/javax/script/ScriptEngineManager.java ! src/share/classes/org/openjdk/jigsaw/BootLoader.java ! src/share/classes/org/openjdk/jigsaw/Launcher.java ! src/share/classes/org/openjdk/jigsaw/LoaderPool.java ! src/share/classes/org/openjdk/jigsaw/Platform.java ! src/share/classes/org/openjdk/jigsaw/SimpleLibrary.java ! src/share/classes/sun/font/FontManagerFactory.java ! src/share/classes/sun/management/MappedMXBeanType.java ! src/share/classes/sun/misc/Unsafe.java ! src/share/classes/sun/security/jca/ProviderConfig.java ! src/share/native/common/jdk_util.h + src/share/native/common/jigsaw.c + src/share/native/common/jigsaw.h ! src/share/native/java/lang/System.c ! src/solaris/native/common/jdk_util_md.c ! src/windows/native/common/jdk_util_md.c ! test/org/openjdk/jigsaw/security.sh Changeset: 81d9200293a7 Author: mchung Date: 2012-05-18 12:54 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/81d9200293a7 Remove BootLoader.c - src/share/native/org/openjdk/jigsaw/BootLoader.c Changeset: 1690f9dd8ebd Author: mchung Date: 2012-05-18 12:55 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/1690f9dd8ebd Merge From david.holmes at oracle.com Fri May 18 19:57:06 2012 From: david.holmes at oracle.com (David Holmes) Date: Sat, 19 May 2012 12:57:06 +1000 Subject: hg: jigsaw/jigsaw/jdk: 4 new changesets In-Reply-To: <20120518202455.92494473EE@hg.openjdk.java.net> References: <20120518202455.92494473EE@hg.openjdk.java.net> Message-ID: <4FB70C02.8070300@oracle.com> Mandy, In Class.java: @@ -617,7 +617,8 @@ public final class Class SecurityManager sm = System.getSecurityManager(); if (sm != null) { ClassLoader ccl = ClassLoader.getCallerClassLoader(); - if (ccl != null && ccl != cl && !cl.isAncestor(ccl)) { + // ## Revisit: permission required in module mode + if (ClassLoader.isPlatformClassLoader(ccl) && ccl != cl && !cl.isAncestor(ccl)) { sm.checkPermission(SecurityConstants.GET_CLASSLOADER_PERMISSION); } Shouldn't that be !ClassLoader.isPlatformClassLoader(ccl) BTW there are j.u.c changes in the mainline that will need similar fixups when you sync up again. David On 19/05/2012 6:24 AM, mandy.chung at oracle.com wrote: > Changeset: d5768c1041b6 > Author: alanb > Date: 2012-03-01 11:26 +0000 > URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/d5768c1041b6 > > Add code source to modules; jdk.* modules granted all permissions by default > > ! make/modules/modules.config > ! make/sun/net/FILES_java.gmk > ! src/share/classes/org/openjdk/jigsaw/Loader.java > + src/share/classes/sun/net/www/protocol/module/Handler.java > > Changeset: 7b282c826118 > Author: mchung > Date: 2012-05-18 12:48 -0700 > URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/7b282c826118 > > Support for VM to read classes from module library via jigsaw native interface > Reviewed-by: alanb, psandoz > > ! make/java/java/FILES_c.gmk > ! make/java/java/mapfile-vers > ! make/modules/modules.config > ! make/modules/modules.group > ! make/modules/modules.properties > ! make/modules/optional.depconfig > ! src/share/classes/com/sun/jmx/mbeanserver/MXBeanMapping.java > ! src/share/classes/com/sun/jmx/remote/internal/IIOPHelper.java > ! src/share/classes/java/lang/Class.java > ! src/share/classes/java/lang/ClassLoader.java > ! src/share/classes/java/lang/Thread.java > ! src/share/classes/java/lang/management/ManagementFactory.java > ! src/share/classes/java/lang/management/PlatformComponent.java > ! src/share/classes/java/lang/module/ModuleClassLoader.java > ! src/share/classes/java/util/Properties.java > ! src/share/classes/java/util/ResourceBundle.java > ! src/share/classes/java/util/ServiceLoader.java > ! src/share/classes/java/util/prefs/Preferences.java > ! src/share/classes/javax/script/ScriptEngineManager.java > ! src/share/classes/org/openjdk/jigsaw/BootLoader.java > ! src/share/classes/org/openjdk/jigsaw/Launcher.java > ! src/share/classes/org/openjdk/jigsaw/LoaderPool.java > ! src/share/classes/org/openjdk/jigsaw/Platform.java > ! src/share/classes/org/openjdk/jigsaw/SimpleLibrary.java > ! src/share/classes/sun/font/FontManagerFactory.java > ! src/share/classes/sun/management/MappedMXBeanType.java > ! src/share/classes/sun/misc/Unsafe.java > ! src/share/classes/sun/security/jca/ProviderConfig.java > ! src/share/native/common/jdk_util.h > + src/share/native/common/jigsaw.c > + src/share/native/common/jigsaw.h > ! src/share/native/java/lang/System.c > ! src/solaris/native/common/jdk_util_md.c > ! src/windows/native/common/jdk_util_md.c > ! test/org/openjdk/jigsaw/security.sh > > Changeset: 81d9200293a7 > Author: mchung > Date: 2012-05-18 12:54 -0700 > URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/81d9200293a7 > > Remove BootLoader.c > > - src/share/native/org/openjdk/jigsaw/BootLoader.c > > Changeset: 1690f9dd8ebd > Author: mchung > Date: 2012-05-18 12:55 -0700 > URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/1690f9dd8ebd > > Merge > > From mandy.chung at oracle.com Fri May 18 22:32:58 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 18 May 2012 22:32:58 -0700 Subject: hg: jigsaw/jigsaw/jdk: 4 new changesets In-Reply-To: <4FB70C02.8070300@oracle.com> References: <20120518202455.92494473EE@hg.openjdk.java.net> <4FB70C02.8070300@oracle.com> Message-ID: <4FB7308A.9030404@oracle.com> uOn 5/18/2012 7:57 PM, David Holmes wrote: > Mandy, > > In Class.java: > > @@ -617,7 +617,8 @@ public final class Class > SecurityManager sm = System.getSecurityManager(); > if (sm != null) { > ClassLoader ccl = ClassLoader.getCallerClassLoader(); > - if (ccl != null && ccl != cl && !cl.isAncestor(ccl)) { > + // ## Revisit: permission required in module mode > + if (ClassLoader.isPlatformClassLoader(ccl) && ccl != cl && > !cl.isAncestor(ccl)) { > sm.checkPermission(SecurityConstants.GET_CLASSLOADER_PERMISSION); > } > > Shouldn't that be !ClassLoader.isPlatformClassLoader(ccl) You are right and same bug in ClassLoader.java. Umm... I wonder why I didn't catch this in the tests I ran (I ran jtreg regression tests in hybrid mode, i.e. run within a module). I'm going to work on a fix and add new tests. Thanks for catching it and the heads up for j.u.c. changes. Mandy > > BTW there are j.u.c changes in the mainline that will need similar > fixups when you sync up again. From Alan.Bateman at oracle.com Mon May 21 01:03:51 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 21 May 2012 09:03:51 +0100 Subject: No deps on JAXP was: JDK support for VM to read classes from modules in a module library In-Reply-To: <1765464.kiN6L90L7J@logoutik> References: <4FA4CAF0.8000008@oracle.com> <4FB4209D.1040704@oracle.com> <4FB4F5AD.8030700@oracle.com> <1765464.kiN6L90L7J@logoutik> Message-ID: <4FB9F6E7.4090001@oracle.com> On 18/05/2012 08:07, Jaroslav Tulach wrote: > : > > To give old schoolers equivalent "use" experience with JDK8 as they used to > have with JDK7, I think it is enough to have one "JavaSE at 8.0" module with > convenient dependencies which those guys can depend on. As far as I understand > this is the Jigsaw plan, so balance between use and re-use should be there. > In the current builds then you'll see modules jdk at 8-ea and jdk.jre at 8-ea. These are aggregator modules and they re-export the APIs to give us the equivalent of the JDK and JRE. There are a couple of differences/issues but it essentially means that someone can require jdk.jre to ensure that all modules that comprise Java SE are present. I don't know what the ultimate names will be but one could envisage the jdk.jre be named to "java" or having the alias "java" so that applications can require java>=8. Note that this isn't the default at this time. The default for modules that don't express a synthesized dependency on "java.base", a module that comprise the core APIs. This means that applications or libraries built as modules that require anything more will need to specify their dependencies. -Alan. From paul.sandoz at oracle.com Mon May 21 01:45:07 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 21 May 2012 10:45:07 +0200 Subject: hg: jigsaw/jigsaw/jdk: 4 new changesets In-Reply-To: <4FB7308A.9030404@oracle.com> References: <20120518202455.92494473EE@hg.openjdk.java.net> <4FB70C02.8070300@oracle.com> <4FB7308A.9030404@oracle.com> Message-ID: On May 19, 2012, at 7:32 AM, Mandy Chung wrote: > uOn 5/18/2012 7:57 PM, David Holmes wrote: >> Mandy, >> >> In Class.java: >> >> @@ -617,7 +617,8 @@ public final class Class >> SecurityManager sm = System.getSecurityManager(); >> if (sm != null) { >> ClassLoader ccl = ClassLoader.getCallerClassLoader(); >> - if (ccl != null && ccl != cl && !cl.isAncestor(ccl)) { >> + // ## Revisit: permission required in module mode >> + if (ClassLoader.isPlatformClassLoader(ccl) && ccl != cl && !cl.isAncestor(ccl)) { >> sm.checkPermission(SecurityConstants.GET_CLASSLOADER_PERMISSION); >> } >> >> Shouldn't that be !ClassLoader.isPlatformClassLoader(ccl) > > You are right and same bug in ClassLoader.java. And Thread.java. I dunno if it would make sense to have: Platform.isXLoader(); Where "X" == "NotPlatform" but with a better name. And/or perhaps the pattern: if (!ClassLoader.isPlatformClassLoader(ccl) && ccl != cl && !cl.isAncestor(ccl)) { sm.checkPermission(SecurityConstants.GET_CLASSLOADER_PERMISSION); } could be encapsulated in a static method of ClassLoader? especially if changes in j.u.c do the same. Paul. From Alan.Bateman at oracle.com Mon May 21 01:55:35 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 21 May 2012 09:55:35 +0100 Subject: No deps on JAXP was: JDK support for VM to read classes from modules in a module library In-Reply-To: <1765464.kiN6L90L7J@logoutik> References: <4FA4CAF0.8000008@oracle.com> <4FB4209D.1040704@oracle.com> <4FB4F5AD.8030700@oracle.com> <1765464.kiN6L90L7J@logoutik> Message-ID: <4FBA0307.4050904@oracle.com> On 18/05/2012 08:07, Jaroslav Tulach wrote: > : > > Should you agree that elimination of java.base => JAXP linkage dependency is > reasonable goal and you just don't want to bother with it now, I'd be happy to > try it myself and prepare a patch. > Yes, I think we all agree that eliminating the base->jaxp dependency is a reasonable goal. The troublesome methods are (as you know) Properties.loadfromXML and storeToXML. It may be possible to just re-implement storeToXML so that it doesn't use JAXP. For loadFromXML then a long standing suggestion has been to relax its specification to allow it be implemented with a simple non-validating parser that can parse most properties files in XML format. Whether this eliminates or just reduces the need for JAXP isn't clear at this point but it would be really nice to just not require JAXP. As it stands then it's an optional dependency but not in a clean way (as we've been discussing on this thread) due to sun.util.xml.XMLUtils. So I think the right course of action on this one is to first explore whether we can eliminate the dependency completely, and if not then it brings us to the options that we are discussing on this thread. I would also throw in the pot the dependencies that JAX-WS and XML-DSIG have on internal JAXP clases as that will need to be tackled if JAXP is to be truely replaceable. -Alan. From chris.hegarty at oracle.com Mon May 21 06:28:59 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 21 May 2012 14:28:59 +0100 Subject: RFR: Solaris 64-bit images Message-ID: <4FBA431B.8080902@oracle.com> There is currently an issue with the Solaris 64-bit image. To date Solaris 64-bit bundles need to overlay the 32 bit bundle. This doesn't currently make sense in the modular world and more thought needs to go into how we want to handle this long term. What I have done in the webrev is to temporarily disable the creation of the Solaris 64-bit commands in the amd64/sparcv9 directories, and fixup paths to find the appropriate native libraries. This will build a 64-bit only bundle and jmod files, similar to what we have on other platforms. For now, I think this is a reasonable solution until we can address issues around how to want to handle this long term. http://cr.openjdk.java.net/~chegar/jigsaw/solaris64_webrev.00/webrev/ -Chris. From paul.sandoz at oracle.com Mon May 21 07:29:12 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 21 May 2012 16:29:12 +0200 Subject: RFR: jpkg contents/show commands In-Reply-To: <4FB52FA1.1070305@oracle.com> References: <4FB52FA1.1070305@oracle.com> Message-ID: <04928CFB-9D3C-40E8-B671-5B79B6D2F018@oracle.com> On May 17, 2012, at 7:04 PM, Chris Hegarty wrote: > This change adds two new commands to the packaging tool. 'jpkg show' and 'jpkg contents', which came up on this list a few weeks ago. > > http://cr.openjdk.java.net/~chegar/jigsaw/jpkg_contents.00/webrev/ > You may want to update the JavaDoc on the Packager class. > Also, included is various cleanup and restructuring, especially to ModuleFile, to put in place a structure to more easily support new compression algorithms. Specifically LZMA. I have a prototype from last year I need to rebase. > > For now, 'contents' and 'show' are only added jpkg, but I could see that these may be useful before installing a module into the module library, so could be applicable to the jmod command also? Or just jmod? > Is "jpgk show " the equivalent of "jmod ls -v" for a module id query that matches one module? Seems useful to list the contents of a module installed to a library, but i dunno if it is quite the same thing as listing the contents of the module itself. A useful addition, not suggesting for this patch, is the ability to extract out jar/class files from a jmod package or a module installed into a library. > If these new commands are to stay in jpkg long term we should probably change the command that builds the jmod/deb files to create/build, so 'jpkg create ... jmod'. > Yes. What about for modular jar files? Paul. > Two specific implementation changes to draw attention to in the webrev: > 1) ModuleFile.java (L535 new file). Resources were never being > deflated in the module library. They are now. > 2) Sean, > Can you verify the changes to changes to Singer and > ModuleFile.SignatureSection? All jigsaw signing related tests pass. > > -Chris. From Alan.Bateman at oracle.com Mon May 21 07:40:19 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 21 May 2012 15:40:19 +0100 Subject: RFR: Solaris 64-bit images In-Reply-To: <4FBA431B.8080902@oracle.com> References: <4FBA431B.8080902@oracle.com> Message-ID: <4FBA53D3.9040908@oracle.com> On 21/05/2012 14:28, Chris Hegarty wrote: > There is currently an issue with the Solaris 64-bit image. To date > Solaris 64-bit bundles need to overlay the 32 bit bundle. This doesn't > currently make sense in the modular world and more thought needs to go > into how we want to handle this long term. > > What I have done in the webrev is to temporarily disable the creation > of the Solaris 64-bit commands in the amd64/sparcv9 directories, and > fixup paths to find the appropriate native libraries. This will build > a 64-bit only bundle and jmod files, similar to what we have on other > platforms. > > For now, I think this is a reasonable solution until we can address > issues around how to want to handle this long term. > > http://cr.openjdk.java.net/~chegar/jigsaw/solaris64_webrev.00/webrev/ > > -Chris. Just to add to Chris's comments, these changes gives us a solaris-x64 modules build that has the same layout as what we have for linux-x64, windows-x64, and macosx-x64. There has been suggestions that we should have one image that supports both 32-bit and 64-bit but that raises questions as to whether it has one or two system module libraries. For now having a separate 64-bit image makes the most sense. Chris - I looked at the changes and they look okay to me. I also grabbed the patch and it built a solaris-x64 image as I expected. I'm happy to push the changes for you. One small thing is that we have a couple of tests (launcher and JDI tests come to mind) that launch via amd64/bin or sparcv9/bin. We might need to add them to the ModulesProblemList.txt. -Alan. From chris.hegarty at oracle.com Mon May 21 07:43:15 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 21 May 2012 15:43:15 +0100 Subject: RFR: Solaris 64-bit images In-Reply-To: <4FBA53D3.9040908@oracle.com> References: <4FBA431B.8080902@oracle.com> <4FBA53D3.9040908@oracle.com> Message-ID: <4FBA5483.30008@oracle.com> On 21/05/2012 15:40, Alan Bateman wrote: > On 21/05/2012 14:28, Chris Hegarty wrote: >> There is currently an issue with the Solaris 64-bit image. To date >> Solaris 64-bit bundles need to overlay the 32 bit bundle. This doesn't >> currently make sense in the modular world and more thought needs to go >> into how we want to handle this long term. >> >> What I have done in the webrev is to temporarily disable the creation >> of the Solaris 64-bit commands in the amd64/sparcv9 directories, and >> fixup paths to find the appropriate native libraries. This will build >> a 64-bit only bundle and jmod files, similar to what we have on other >> platforms. >> >> For now, I think this is a reasonable solution until we can address >> issues around how to want to handle this long term. >> >> http://cr.openjdk.java.net/~chegar/jigsaw/solaris64_webrev.00/webrev/ >> >> -Chris. > Just to add to Chris's comments, these changes gives us a solaris-x64 > modules build that has the same layout as what we have for linux-x64, > windows-x64, and macosx-x64. There has been suggestions that we should > have one image that supports both 32-bit and 64-bit but that raises > questions as to whether it has one or two system module libraries. For > now having a separate 64-bit image makes the most sense. > > Chris - I looked at the changes and they look okay to me. I also grabbed > the patch and it built a solaris-x64 image as I expected. I'm happy to > push the changes for you. One small thing is that we have a couple of > tests (launcher and JDI tests come to mind) that launch via amd64/bin or > sparcv9/bin. We might need to add them to the ModulesProblemList.txt. Oh, I didn't notice these tests. Let me look into these and for now I'll add them to the ModulesProblemList.txt. Thanks, -Chris. > > -Alan. From chris.hegarty at oracle.com Mon May 21 07:56:09 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 21 May 2012 15:56:09 +0100 Subject: RFR: Solaris 64-bit images In-Reply-To: <4FBA5483.30008@oracle.com> References: <4FBA431B.8080902@oracle.com> <4FBA53D3.9040908@oracle.com> <4FBA5483.30008@oracle.com> Message-ID: <4FBA5789.7020009@oracle.com> On 21/05/2012 15:43, Chris Hegarty wrote: > .... >> Chris - I looked at the changes and they look okay to me. I also grabbed >> the patch and it built a solaris-x64 image as I expected. I'm happy to >> push the changes for you. One small thing is that we have a couple of >> tests (launcher and JDI tests come to mind) that launch via amd64/bin or >> sparcv9/bin. We might need to add them to the ModulesProblemList.txt. I wonder why these tests invoke the 64-bit launcher directly? I notice most of them use the Process API to launch the java process. Is there an issue with launching with 'bin/java -d64' (and using the dual mode support of the launcher, if required), and redirecting the output or waiting for the process? Otherwise, I don't see why the test don't simply launch 'bin/java'. I guess what I'm asking is if these tests should be changed (to use bin/java) in the jdk8 mainline, rather than added to the problem list ( could be added temporarily of course)? -Chris. > > Oh, I didn't notice these tests. Let me look into these and for now I'll > add them to the ModulesProblemList.txt. > > Thanks, > -Chris. > >> >> -Alan. From chris.hegarty at oracle.com Mon May 21 08:10:28 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 21 May 2012 16:10:28 +0100 Subject: RFR: jpkg contents/show commands In-Reply-To: <04928CFB-9D3C-40E8-B671-5B79B6D2F018@oracle.com> References: <4FB52FA1.1070305@oracle.com> <04928CFB-9D3C-40E8-B671-5B79B6D2F018@oracle.com> Message-ID: <4FBA5AE4.1070004@oracle.com> On 21/05/2012 15:29, Paul Sandoz wrote: > > On May 17, 2012, at 7:04 PM, Chris Hegarty wrote: > >> This change adds two new commands to the packaging tool. 'jpkg show' and 'jpkg contents', which came up on this list a few weeks ago. >> >> http://cr.openjdk.java.net/~chegar/jigsaw/jpkg_contents.00/webrev/ >> > > You may want to update the JavaDoc on the Packager class. Good idea, I'll look at the documentation. >> Also, included is various cleanup and restructuring, especially to ModuleFile, to put in place a structure to more easily support new compression algorithms. Specifically LZMA. I have a prototype from last year I need to rebase. >> >> For now, 'contents' and 'show' are only added jpkg, but I could see that these may be useful before installing a module into the module library, so could be applicable to the jmod command also? Or just jmod? >> > > Is "jpgk show" the equivalent of "jmod ls -v" for a module id query that matches one module? Right, but "jmod ls " can only be run after the module has been installed. It may be nice to know what is in a module before you install? > Seems useful to list the contents of a module installed to a library, but i dunno if it is quite the same thing as listing the contents of the module itself. I see this more of a debugging/sanity tool. This issue was raised on the list a few weeks ago by David [1] who was trying to validate the contents of his built module files. > A useful addition, not suggesting for this patch, is the ability to extract out jar/class files from a jmod package or a module installed into a library. 'jmod extract ' will extract the contents of a module file to the file system. Is this what you are looking for? Or maybe you're asking about something like an export facility from the module library? >> If these new commands are to stay in jpkg long term we should probably change the command that builds the jmod/deb files to create/build, so 'jpkg create ... jmod'. >> > > Yes. > > What about for modular jar files? That's next on my list ;-) I really like the idea of a 'create' command that can take an argument to determine what type of package to create, jpkg create ... [jmod|deb|jar|ips|...] Though, not all options make sense to all package types. We would need to ensure that the options are not confusing. -Chris [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2012-May/002515.html > > Paul. > > >> Two specific implementation changes to draw attention to in the webrev: >> 1) ModuleFile.java (L535 new file). Resources were never being >> deflated in the module library. They are now. >> 2) Sean, >> Can you verify the changes to changes to Singer and >> ModuleFile.SignatureSection? All jigsaw signing related tests pass. >> >> -Chris. > From mandy.chung at oracle.com Mon May 21 08:11:19 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 21 May 2012 08:11:19 -0700 Subject: hg: jigsaw/jigsaw/jdk: 4 new changesets In-Reply-To: References: <20120518202455.92494473EE@hg.openjdk.java.net> <4FB70C02.8070300@oracle.com> <4FB7308A.9030404@oracle.com> Message-ID: <4FBA5B17.2000903@oracle.com> On 5/21/2012 1:45 AM, Paul Sandoz wrote: > On May 19, 2012, at 7:32 AM, Mandy Chung wrote: > >> uOn 5/18/2012 7:57 PM, David Holmes wrote: >>> Mandy, >>> >>> In Class.java: >>> >>> @@ -617,7 +617,8 @@ public final class Class >>> SecurityManager sm = System.getSecurityManager(); >>> if (sm != null) { >>> ClassLoader ccl = ClassLoader.getCallerClassLoader(); >>> - if (ccl != null&& ccl != cl&& !cl.isAncestor(ccl)) { >>> + // ## Revisit: permission required in module mode >>> + if (ClassLoader.isPlatformClassLoader(ccl)&& ccl != cl&& !cl.isAncestor(ccl)) { >>> sm.checkPermission(SecurityConstants.GET_CLASSLOADER_PERMISSION); >>> } >>> >>> Shouldn't that be !ClassLoader.isPlatformClassLoader(ccl) >> You are right and same bug in ClassLoader.java. > And Thread.java. > > I dunno if it would make sense to have: > > Platform.isXLoader(); > > Where "X" == "NotPlatform" but with a better name. I was thinking the same thing when I think of the context of getting the jdk changes be module-loader aware to jdk8 before jigsaw is integrated. > And/or perhaps the pattern: > > if (!ClassLoader.isPlatformClassLoader(ccl)&& ccl != cl&& !cl.isAncestor(ccl)) { > sm.checkPermission(SecurityConstants.GET_CLASSLOADER_PERMISSION); > } > > could be encapsulated in a static method of ClassLoader? especially if changes in j.u.c do the same. Good suggestion. In module mode, it's an open issue which loaders requires the permission to get a class loader, context class loader or its parent since it's not the parent delegation hierarchy, so isAncestor might need to be replaced with something that makes sense in module mode (I'll add a comment). Mandy > Paul. From david.lloyd at redhat.com Mon May 21 08:18:48 2012 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 21 May 2012 10:18:48 -0500 Subject: Request for Review: minor VM class loading change In-Reply-To: <4FB53497.6090005@oracle.com> References: <1CF4443A-EAE6-486C-B21E-6AC59EB05BE0@oracle.com> <4FB52F64.1090406@redhat.com> <4FB53497.6090005@oracle.com> Message-ID: <4FBA5CD8.4050403@redhat.com> On 05/17/2012 12:25 PM, Alan Bateman wrote: > On 17/05/2012 18:03, David M. Lloyd wrote: >> >> So is the ultimate goal then to move away from having JDK classes >> always return null for getClassLoader()? Or will that behavior remain? > When running with a classpath then everything should work as it does > today and so it should return null. So Jigsaw is sticking to the two-mode thing then? > When running with modules then the question splits into a question for > classes loaded by the "base" module and classes in other platform > modules (all would previously have been loaded by the bootstrap class > loader and so getClassLoader would have returned null). For the classes > in the base module then it's still an open question and there are good > questions to have it return a module class loader even though they are > actually loaded by the VM built-in bootstrap loader. In this case, are there any observable differences between having the getClassLoader() method "lie" in this way and having the initiating class loader actually *be* the module class loader? > For classes in other modules then getClassLoader will return the appropriate > ModuleClassLoader for that module. > > -Alan > -- - DML From paul.sandoz at oracle.com Mon May 21 08:30:58 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 21 May 2012 17:30:58 +0200 Subject: RFR: jpkg contents/show commands In-Reply-To: <4FBA5AE4.1070004@oracle.com> References: <4FB52FA1.1070305@oracle.com> <04928CFB-9D3C-40E8-B671-5B79B6D2F018@oracle.com> <4FBA5AE4.1070004@oracle.com> Message-ID: <647BA897-D8DC-4013-9EA9-D10CECCD5A10@oracle.com> On May 21, 2012, at 5:10 PM, Chris Hegarty wrote: > >>> Also, included is various cleanup and restructuring, especially to ModuleFile, to put in place a structure to more easily support new compression algorithms. Specifically LZMA. I have a prototype from last year I need to rebase. >>> >>> For now, 'contents' and 'show' are only added jpkg, but I could see that these may be useful before installing a module into the module library, so could be applicable to the jmod command also? Or just jmod? >>> >> >> Is "jpgk show" the equivalent of "jmod ls -v" for a module id query that matches one module? > > Right, but "jmod ls " can only be run after the module has been installed. It may be nice to know what is in a module before you install? > Agreed, i was more requesting a confirmation of my understanding rather than questioning the value :-) >> Seems useful to list the contents of a module installed to a library, but i dunno if it is quite the same thing as listing the contents of the module itself. > > I see this more of a debugging/sanity tool. This issue was raised on the list a few weeks ago by David [1] who was trying to validate the contents of his built module files. > OK. >> A useful addition, not suggesting for this patch, is the ability to extract out jar/class files from a jmod package or a module installed into a library. > > 'jmod extract ' will extract the contents of a module file to the file system. Is this what you are looking for? Yes, will it always extract to a zip of classes or reuse the same compression in the module e.g. pack200? > Or maybe you're asking about something like an export facility from the module library? > This too. The use-case is for tools and IDEs that need to scan class files i.e. a simple, not very efficient solution, until there are proper APIs in place to help scan for classes in jmod packages and and libraries. >>> If these new commands are to stay in jpkg long term we should probably change the command that builds the jmod/deb files to create/build, so 'jpkg create ... jmod'. >>> >> >> Yes. >> >> What about for modular jar files? > > That's next on my list ;-) I really like the idea of a 'create' command that can take an argument to determine what type of package to create, > jpkg create ... [jmod|deb|jar|ips|...] > Me too. Does it makes sense for the "jar" command to be reused for creating a modular jar? (perhaps in addition to that of jpkg for consistency). Paul. From chris.hegarty at oracle.com Mon May 21 08:45:37 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 21 May 2012 16:45:37 +0100 Subject: RFR: jpkg contents/show commands In-Reply-To: <647BA897-D8DC-4013-9EA9-D10CECCD5A10@oracle.com> References: <4FB52FA1.1070305@oracle.com> <04928CFB-9D3C-40E8-B671-5B79B6D2F018@oracle.com> <4FBA5AE4.1070004@oracle.com> <647BA897-D8DC-4013-9EA9-D10CECCD5A10@oracle.com> Message-ID: <4FBA6321.6030907@oracle.com> On 21/05/2012 16:30, Paul Sandoz wrote: > .... > >>> A useful addition, not suggesting for this patch, is the ability to >>> extract out jar/class files from a jmod package or a module installed >>> into a library. >> >> 'jmod extract ' will extract the contents of a module >> file to the file system. Is this what you are looking for? > > Yes, will it always extract to a zip of classes or reuse the same > compression in the module e.g. pack200? The current implementation extracts to a zip classes archive. >> Or maybe you're asking about something like an export facility from >> the module library? >> > > This too. > > The use-case is for tools and IDEs that need to scan class files i.e. a > simple, not very efficient solution, until there are proper APIs in > place to help scan for classes in jmod packages and and libraries. > > >>>> If these new commands are to stay in jpkg long term we should >>>> probably change the command that builds the jmod/deb files to >>>> create/build, so 'jpkg create ... jmod'. >>>> >>> >>> Yes. >>> >>> What about for modular jar files? >> >> That's next on my list ;-) I really like the idea of a 'create' >> command that can take an argument to determine what type of package to >> create, >> jpkg create ... [jmod|deb|jar|ips|...] >> > > Me too. Does it makes sense for the "jar" command to be reused for > creating a modular jar? (perhaps in addition to that of jpkg for > consistency). Thanks to Mandy we already have support for modular jars in the jar command :-) I think we just need to add it to jpkg for consistency, as you said. :> bin/jar Usage: jar {ctxui}[vfm0MeI] [jar-file] [manifest-file] [entry-point] [module-id] [-C dir] files ... Options: -c create new archive -t list table of contents for archive -x extract named (or all) files from archive -u update existing archive -v generate verbose output on standard output -f specify archive file name -m include manifest information from specified manifest file -e specify application entry point for stand-alone application bundled into an executable jar file -0 store only; use no ZIP compression -M do not create a manifest file for the entries -i generate index information for the specified jar files -C change to the specified directory and include the following file -I specify the module id for this modular JAR. It must match the id declared in module-info.class if exists. If any file is a directory then it is processed recursively. The manifest file name, the archive file name and the entry point name are specified in the same order as the 'm', 'f' and 'e' flags. Example 1: to archive two class files into an archive called classes.jar: jar cvf classes.jar Foo.class Bar.class Example 2: use an existing manifest file 'mymanifest' and archive all the files in the foo/ directory into 'classes.jar': jar cvfm classes.jar mymanifest -C foo/ . Example 3: update an existing jar to a modular JAR jar uvfI classes.jar acme.foo at 1.0 or jar uvf classes.jar module-info.class -Chris. > > Paul. From david.lloyd at redhat.com Mon May 21 08:55:32 2012 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 21 May 2012 10:55:32 -0500 Subject: ClassLoader.getPackages() In-Reply-To: <4F5541DA.5090503@redhat.com> References: <4F5541DA.5090503@redhat.com> Message-ID: <4FBA6574.2080202@redhat.com> On 03/05/2012 04:44 PM, David M. Lloyd wrote: > The JavaDoc for ClassLoader.getPackages() says: > > protected Package[] getPackages() > > Returns all of the Packages defined by this class loader and its ancestors. > > Returns: > The array of Package objects defined by this ClassLoader > > The intention appears to be that the class loader returns all the > packages visible to it. However, it also assumes a strict parent/child > hierarchy of class loaders. > > My question is, how does the Jigsaw project interpret this method? Does > it return only Packages known to it and the parent class loader(s) > (which presumably includes only the "null" class loader)? Or does it > also include the Packages from its dependencies (i.e. the complete set > of visible Packages)? I was wondering if there were any new insights into the answer to this question. -- - DML From Alan.Bateman at oracle.com Mon May 21 10:07:26 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 21 May 2012 18:07:26 +0100 Subject: Request for Review: minor VM class loading change In-Reply-To: <4FBA5CD8.4050403@redhat.com> References: <1CF4443A-EAE6-486C-B21E-6AC59EB05BE0@oracle.com> <4FB52F64.1090406@redhat.com> <4FB53497.6090005@oracle.com> <4FBA5CD8.4050403@redhat.com> Message-ID: <4FBA764E.4030004@oracle.com> On 21/05/2012 16:18, David M. Lloyd wrote: > > So Jigsaw is sticking to the two-mode thing then? There isn't a system/application class loader and delegation to extension and boot class loader when running with modules. Also options such -Xbootclasspath, -classpath. etc. don't really make sense. So this is the reason this although the word "mode" is a bit unfortunate. > : > > In this case, are there any observable differences between having the > getClassLoader() method "lie" in this way and having the initiating > class loader actually *be* the module class loader? > As Karen mentioned in one of the mails, the changes mean we can experiment with this so that we can understand the impact of the change. -Alan. From Alan.Bateman at oracle.com Mon May 21 10:11:18 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 21 May 2012 18:11:18 +0100 Subject: ClassLoader.getPackages() In-Reply-To: <4FBA6574.2080202@redhat.com> References: <4F5541DA.5090503@redhat.com> <4FBA6574.2080202@redhat.com> Message-ID: <4FBA7736.4000008@oracle.com> On 21/05/2012 16:55, David M. Lloyd wrote: > : > I was wondering if there were any new insights into the answer to this > question. > I haven't heard any suggestions but as Package is legacy, and many of the methods don't really make sense now, then it's not clear to me that getPackages make sense either. I think a possible approach would be for ModuleClassLoader to override getPackages so that it is specified to throw an exception or return an empty array. -Alan. From mandy.chung at oracle.com Mon May 21 10:28:08 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 21 May 2012 10:28:08 -0700 Subject: ClassLoader.getPackages() In-Reply-To: <4FBA6574.2080202@redhat.com> References: <4F5541DA.5090503@redhat.com> <4FBA6574.2080202@redhat.com> Message-ID: <4FBA7B28.4020703@oracle.com> On 5/21/2012 8:55 AM, David M. Lloyd wrote: > On 03/05/2012 04:44 PM, David M. Lloyd wrote: >> The JavaDoc for ClassLoader.getPackages() says: >> >> protected Package[] getPackages() >> >> Returns all of the Packages defined by this class loader and its >> ancestors. >> >> Returns: >> The array of Package objects defined by this ClassLoader >> >> The intention appears to be that the class loader returns all the >> packages visible to it. However, it also assumes a strict parent/child >> hierarchy of class loaders. >> >> My question is, how does the Jigsaw project interpret this method? Does >> it return only Packages known to it and the parent class loader(s) >> (which presumably includes only the "null" class loader)? Or does it >> also include the Packages from its dependencies (i.e. the complete set >> of visible Packages)? > What ClassLoader.getPackages() should do in modular world is an open issue [1] that requires further investigation and discussion. As you said, Packages assume a strict parent-delegation hierachy. Also it is tied with JAR manifest where the package information is specified. One thought is that java.lang.Package will not be applicable in module mode and ClassLoader.getPackages() may just throw exception but the question would be how existing applications use java.lang.Package API and its implication. Basically it's yet to determine what the existing ClassLoader methods means in module mode that makes sense and also requires evaluating its impact to existing applications. Mandy [1] http://openjdk.java.net/projects/jigsaw/doc/module-class-loading.pdf From jesse.glick at oracle.com Mon May 21 11:20:20 2012 From: jesse.glick at oracle.com (Jesse Glick) Date: Mon, 21 May 2012 14:20:20 -0400 Subject: ClassLoader.getPackages() In-Reply-To: <4FBA7736.4000008@oracle.com> References: <4F5541DA.5090503@redhat.com> <4FBA6574.2080202@redhat.com> <4FBA7736.4000008@oracle.com> Message-ID: <4FBA8764.2040702@oracle.com> On 05/21/2012 01:11 PM, Alan Bateman wrote: > it's not clear to me that getPackages make sense It doubt it is used much, but it should be possible to return something sensible for getPackage(String) and getPackages() even in module mode. The packages of a module class loader would be those it defines (ClassLoader.packages) plus those accessible to it (i.e. exported) from any modules in its "requires" list, including java.base. FWIW the NetBeans module system implements nearly this behavior [1]. It cannot perfectly implement it without some API changes: Package.getSystemPackages is not public, and ClassLoader.getPackage is protected, so it is not straightforward to collect packages defined in JRE-supplied parent ClassLoader's. Jigsaw would of course not be bound by this problem. Also NB does not currently restrict the result according to visibility (*), though it would probably be easy to do so. (*) As with other nonnative module systems, NB uses visibility - which it can control - as a substitute for accessibility - which it cannot. [1] http://hg.netbeans.org/main-silver/raw-file/default/o.n.bootstrap/src/org/netbeans/ProxyClassLoader.java From kelly.ohair at oracle.com Mon May 21 11:26:33 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Mon, 21 May 2012 11:26:33 -0700 Subject: RFR: Solaris 64-bit images In-Reply-To: <4FBA5789.7020009@oracle.com> References: <4FBA431B.8080902@oracle.com> <4FBA53D3.9040908@oracle.com> <4FBA5483.30008@oracle.com> <4FBA5789.7020009@oracle.com> Message-ID: I think tests that want the 64bit version, should use the regular bin/java -d64 not dive into the bin/sparcv9/ or bin/amd64 directories. Just my opinion. -kto On May 21, 2012, at 7:56 AM, Chris Hegarty wrote: > On 21/05/2012 15:43, Chris Hegarty wrote: >> .... >>> Chris - I looked at the changes and they look okay to me. I also grabbed >>> the patch and it built a solaris-x64 image as I expected. I'm happy to >>> push the changes for you. One small thing is that we have a couple of >>> tests (launcher and JDI tests come to mind) that launch via amd64/bin or >>> sparcv9/bin. We might need to add them to the ModulesProblemList.txt. > > I wonder why these tests invoke the 64-bit launcher directly? I notice most of them use the Process API to launch the java process. Is there an issue with launching with 'bin/java -d64' (and using the dual mode support of the launcher, if required), and redirecting the output or waiting for the process? Otherwise, I don't see why the test don't simply launch 'bin/java'. > > I guess what I'm asking is if these tests should be changed (to use bin/java) in the jdk8 mainline, rather than added to the problem list ( could be added temporarily of course)? > > -Chris. > >> >> Oh, I didn't notice these tests. Let me look into these and for now I'll >> add them to the ModulesProblemList.txt. >> >> Thanks, >> -Chris. >> >>> >>> -Alan. From kelly.ohair at oracle.com Mon May 21 11:34:01 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Mon, 21 May 2012 11:34:01 -0700 Subject: RFR: Solaris 64-bit images In-Reply-To: <4FBA53D3.9040908@oracle.com> References: <4FBA431B.8080902@oracle.com> <4FBA53D3.9040908@oracle.com> Message-ID: On May 21, 2012, at 7:40 AM, Alan Bateman wrote: > On 21/05/2012 14:28, Chris Hegarty wrote: >> There is currently an issue with the Solaris 64-bit image. To date Solaris 64-bit bundles need to overlay the 32 bit bundle. This doesn't currently make sense in the modular world and more thought needs to go into how we want to handle this long term. >> >> What I have done in the webrev is to temporarily disable the creation of the Solaris 64-bit commands in the amd64/sparcv9 directories, and fixup paths to find the appropriate native libraries. This will build a 64-bit only bundle and jmod files, similar to what we have on other platforms. >> >> For now, I think this is a reasonable solution until we can address issues around how to want to handle this long term. >> >> http://cr.openjdk.java.net/~chegar/jigsaw/solaris64_webrev.00/webrev/ >> >> -Chris. > Just to add to Chris's comments, these changes gives us a solaris-x64 modules build that has the same layout as what we have for linux-x64, windows-x64, and macosx-x64. There has been suggestions that we should have one image that supports both 32-bit and 64-bit but that raises questions as to whether it has one or two system module libraries. For now having a separate 64-bit image makes the most sense. > If the solaris 64bit builds will be full jdk builds, that means that those builds will take considerably longer (all the duplicate javac compiles) and the resulting 64bit bundles will be larger. Solaris SPARC is already a long pole on building, this could make it worse. If for the sake of simplicity, if we want to go down this 'full jdk for all' strategy, as a more permanent thing, I'm ok with that. But is that what you are saying? If so, we may need to adjust our SPARC orders and pray that we actually get what we order some day. :^( -kto > Chris - I looked at the changes and they look okay to me. I also grabbed the patch and it built a solaris-x64 image as I expected. I'm happy to push the changes for you. One small thing is that we have a couple of tests (launcher and JDI tests come to mind) that launch via amd64/bin or sparcv9/bin. We might need to add them to the ModulesProblemList.txt. > > -Alan. From Alan.Bateman at oracle.com Mon May 21 11:55:50 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 21 May 2012 19:55:50 +0100 Subject: RFR: Solaris 64-bit images In-Reply-To: References: <4FBA431B.8080902@oracle.com> <4FBA53D3.9040908@oracle.com> Message-ID: <4FBA8FB6.7080300@oracle.com> On 21/05/2012 19:34, Kelly O'Hair wrote: > > If the solaris 64bit builds will be full jdk builds, that means that those builds will take considerably longer (all the duplicate javac compiles) > and the resulting 64bit bundles will be larger. Solaris SPARC is already a long pole on building, this could make it worse. > I think having separate 32-bit and 64-bit images is fine for now. If they are in the same image then it means deciding if the image contains one or two system module libraries and there are issues with both approaches that will take time to figure out. -Alan. From chris.hegarty at oracle.com Mon May 21 13:03:45 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 21 May 2012 21:03:45 +0100 Subject: RFR: Solaris 64-bit images In-Reply-To: References: <4FBA431B.8080902@oracle.com> <4FBA53D3.9040908@oracle.com> <4FBA5483.30008@oracle.com> <4FBA5789.7020009@oracle.com> Message-ID: <4FBA9FA1.5050002@oracle.com> On 21/05/12 19:26, Kelly O'Hair wrote: > I think tests that want the 64bit version, should use the regular bin/java -d64 not dive into the bin/sparcv9/ or bin/amd64 directories. > Just my opinion. Right, this is exactly what I was thinking. I really don't understand why anyone would be executing bin/[sparcv9|amd64]/java directly. Do these tests predate dual launcher support? Or any other historic reason it could be? Anyway, for now I'll just add them to the modules problem list and we can revisit when a more permanent solution for the images is found. -Chris. > > -kto > > On May 21, 2012, at 7:56 AM, Chris Hegarty wrote: > >> On 21/05/2012 15:43, Chris Hegarty wrote: >>> .... >>>> Chris - I looked at the changes and they look okay to me. I also grabbed >>>> the patch and it built a solaris-x64 image as I expected. I'm happy to >>>> push the changes for you. One small thing is that we have a couple of >>>> tests (launcher and JDI tests come to mind) that launch via amd64/bin or >>>> sparcv9/bin. We might need to add them to the ModulesProblemList.txt. >> >> I wonder why these tests invoke the 64-bit launcher directly? I notice most of them use the Process API to launch the java process. Is there an issue with launching with 'bin/java -d64' (and using the dual mode support of the launcher, if required), and redirecting the output or waiting for the process? Otherwise, I don't see why the test don't simply launch 'bin/java'. >> >> I guess what I'm asking is if these tests should be changed (to use bin/java) in the jdk8 mainline, rather than added to the problem list ( could be added temporarily of course)? >> >> -Chris. >> >>> >>> Oh, I didn't notice these tests. Let me look into these and for now I'll >>> add them to the ModulesProblemList.txt. >>> >>> Thanks, >>> -Chris. >>> >>>> >>>> -Alan. > From kelly.ohair at oracle.com Mon May 21 14:46:54 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Mon, 21 May 2012 14:46:54 -0700 Subject: RFR: Solaris 64-bit images In-Reply-To: <4FBA9FA1.5050002@oracle.com> References: <4FBA431B.8080902@oracle.com> <4FBA53D3.9040908@oracle.com> <4FBA5483.30008@oracle.com> <4FBA5789.7020009@oracle.com> <4FBA9FA1.5050002@oracle.com> Message-ID: On May 21, 2012, at 1:03 PM, Chris Hegarty wrote: > On 21/05/12 19:26, Kelly O'Hair wrote: >> I think tests that want the 64bit version, should use the regular bin/java -d64 not dive into the bin/sparcv9/ or bin/amd64 directories. >> Just my opinion. > > Right, this is exactly what I was thinking. I really don't understand why anyone would be executing bin/[sparcv9|amd64]/java directly. > > Do these tests predate dual launcher support? Or any other historic reason it could be? Anyway, for now I'll just add them to the modules problem list and we can revisit when a more permanent solution for the images is found. As I recall, sqe and some developers might have had a style of going after the arch specific binaries, but I don't know why. They won't actually work if the 32bit binaries/libraries/javaruntime (like bin/java) are missing, so it seems silly. I can only assume that they were trying to avoid having to specify -d64? The ProblemList exists to defer these things, so have at it. ;^) -kto > > -Chris. > >> >> -kto >> >> On May 21, 2012, at 7:56 AM, Chris Hegarty wrote: >> >>> On 21/05/2012 15:43, Chris Hegarty wrote: >>>> .... >>>>> Chris - I looked at the changes and they look okay to me. I also grabbed >>>>> the patch and it built a solaris-x64 image as I expected. I'm happy to >>>>> push the changes for you. One small thing is that we have a couple of >>>>> tests (launcher and JDI tests come to mind) that launch via amd64/bin or >>>>> sparcv9/bin. We might need to add them to the ModulesProblemList.txt. >>> >>> I wonder why these tests invoke the 64-bit launcher directly? I notice most of them use the Process API to launch the java process. Is there an issue with launching with 'bin/java -d64' (and using the dual mode support of the launcher, if required), and redirecting the output or waiting for the process? Otherwise, I don't see why the test don't simply launch 'bin/java'. >>> >>> I guess what I'm asking is if these tests should be changed (to use bin/java) in the jdk8 mainline, rather than added to the problem list ( could be added temporarily of course)? >>> >>> -Chris. >>> >>>> >>>> Oh, I didn't notice these tests. Let me look into these and for now I'll >>>> add them to the ModulesProblemList.txt. >>>> >>>> Thanks, >>>> -Chris. >>>> >>>>> >>>>> -Alan. >> From david.holmes at oracle.com Mon May 21 18:55:20 2012 From: david.holmes at oracle.com (David Holmes) Date: Tue, 22 May 2012 11:55:20 +1000 Subject: ClassLoader.getPackages() In-Reply-To: <4FBA7B28.4020703@oracle.com> References: <4F5541DA.5090503@redhat.com> <4FBA6574.2080202@redhat.com> <4FBA7B28.4020703@oracle.com> Message-ID: <4FBAF208.7070009@oracle.com> On 22/05/2012 3:28 AM, Mandy Chung wrote: > What ClassLoader.getPackages() should do in modular world is an open > issue [1] that requires further investigation and discussion. As you > said, Packages assume a strict parent-delegation hierachy. Also it is > tied with JAR manifest where the package information is specified. One > thought is that java.lang.Package will not be applicable in module mode > and ClassLoader.getPackages() may just throw exception but the question > would be how existing applications use java.lang.Package API and its > implication. Basically it's yet to determine what the existing > ClassLoader methods means in module mode that makes sense and also > requires evaluating its impact to existing applications. It seems to me the problem is with the "parent" part of this, not with Packages per-se. More generally I'm yet to see a clear description of how the new module-loader architecture maps into all the existing hierarchical-based classloading semantics - such as permissions. David ----- > Mandy > [1] http://openjdk.java.net/projects/jigsaw/doc/module-class-loading.pdf > From david.holmes at oracle.com Mon May 21 19:01:32 2012 From: david.holmes at oracle.com (David Holmes) Date: Tue, 22 May 2012 12:01:32 +1000 Subject: RFR: Solaris 64-bit images In-Reply-To: <4FBA9FA1.5050002@oracle.com> References: <4FBA431B.8080902@oracle.com> <4FBA53D3.9040908@oracle.com> <4FBA5483.30008@oracle.com> <4FBA5789.7020009@oracle.com> <4FBA9FA1.5050002@oracle.com> Message-ID: <4FBAF37C.1000205@oracle.com> On 22/05/2012 6:03 AM, Chris Hegarty wrote: > On 21/05/12 19:26, Kelly O'Hair wrote: >> I think tests that want the 64bit version, should use the regular >> bin/java -d64 not dive into the bin/sparcv9/ or bin/amd64 directories. >> Just my opinion. > > Right, this is exactly what I was thinking. I really don't understand > why anyone would be executing bin/[sparcv9|amd64]/java directly. > > Do these tests predate dual launcher support? Or any other historic > reason it could be? Anyway, for now I'll just add them to the modules > problem list and we can revisit when a more permanent solution for the > images is found. It might relate to the need to exec another Java process just like the original. Some tests use particular techniques to find the Java under test and that might (just speculating) require knowing for certain whether it was 32-bit or 64-bit, otherwise they would also need to know whether to pass -d64 or not. Examining the tests should make this more clear. David > -Chris. > >> >> -kto >> >> On May 21, 2012, at 7:56 AM, Chris Hegarty wrote: >> >>> On 21/05/2012 15:43, Chris Hegarty wrote: >>>> .... >>>>> Chris - I looked at the changes and they look okay to me. I also >>>>> grabbed >>>>> the patch and it built a solaris-x64 image as I expected. I'm happy to >>>>> push the changes for you. One small thing is that we have a couple of >>>>> tests (launcher and JDI tests come to mind) that launch via >>>>> amd64/bin or >>>>> sparcv9/bin. We might need to add them to the ModulesProblemList.txt. >>> >>> I wonder why these tests invoke the 64-bit launcher directly? I >>> notice most of them use the Process API to launch the java process. >>> Is there an issue with launching with 'bin/java -d64' (and using the >>> dual mode support of the launcher, if required), and redirecting the >>> output or waiting for the process? Otherwise, I don't see why the >>> test don't simply launch 'bin/java'. >>> >>> I guess what I'm asking is if these tests should be changed (to use >>> bin/java) in the jdk8 mainline, rather than added to the problem list >>> ( could be added temporarily of course)? >>> >>> -Chris. >>> >>>> >>>> Oh, I didn't notice these tests. Let me look into these and for now >>>> I'll >>>> add them to the ModulesProblemList.txt. >>>> >>>> Thanks, >>>> -Chris. >>>> >>>>> >>>>> -Alan. >> From sanjeeb.sahoo at oracle.com Mon May 21 20:38:39 2012 From: sanjeeb.sahoo at oracle.com (Sahoo) Date: Tue, 22 May 2012 09:08:39 +0530 Subject: Module of a Class? Message-ID: <4FBB0A3F.60200@oracle.com> Is there an API to find out which module a class belongs to? If yes, what is it? Thanks, Sahoo From mandy.chung at oracle.com Mon May 21 21:50:47 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 21 May 2012 21:50:47 -0700 Subject: Module of a Class? In-Reply-To: <4FBB0A3F.60200@oracle.com> References: <4FBB0A3F.60200@oracle.com> Message-ID: <4FBB1B27.8040804@oracle.com> On 5/21/2012 8:38 PM, Sahoo wrote: > Is there an API to find out which module a class belongs to? If yes, > what is it? > Class.getModule(). Is that something you are looking for? Mandy From sanjeeb.sahoo at oracle.com Mon May 21 22:11:34 2012 From: sanjeeb.sahoo at oracle.com (Sahoo) Date: Tue, 22 May 2012 10:41:34 +0530 Subject: Module of a Class? In-Reply-To: <4FBB1B27.8040804@oracle.com> References: <4FBB0A3F.60200@oracle.com> <4FBB1B27.8040804@oracle.com> Message-ID: <4FBB2006.2080701@oracle.com> On Tuesday 22 May 2012 10:20 AM, Mandy Chung wrote: > On 5/21/2012 8:38 PM, Sahoo wrote: >> Is there an API to find out which module a class belongs to? If yes, >> what is it? >> > > Class.getModule(). Is that something you are looking for? > Yes, I was looking for something of that sort. Now that you told me, I see in the actual jigsaw build. I was looking for something like this in the javadoc of Class linked from jigsaw javadoc page [1] without realizing that the javadocs for non-jigsaw classes actually correspond to non-jigsaw builds. Can this be fixed? Thanks, Sahoo [1] http://cr.openjdk.java.net/~mr/jigsaw/api/ From mandy.chung at oracle.com Mon May 21 23:15:21 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 21 May 2012 23:15:21 -0700 Subject: RFR: jpkg contents/show commands In-Reply-To: <4FB52FA1.1070305@oracle.com> References: <4FB52FA1.1070305@oracle.com> Message-ID: <4FBB2EF9.2080200@oracle.com> Chris, > This change adds two new commands to the packaging tool. 'jpkg show' > and 'jpkg contents', which came up on this list a few weeks ago. > For now, 'contents' and 'show' are only added jpkg, but I could see > that these may be useful before installing a module into the module > library, so could be applicable to the jmod command also? Or just jmod? Showing the contents of a given jmod file would be useful and it can provide a way to check if the packaged jmod file contains the contents as expect without the need to extract the contents. For the 'show' command, what you have is to show module-info. How do you expect the show command is used? I can imagine that jpkg info might be useful to show the information about the jmod file such as size of each section (compressed and uncompressed), and number of subheaders / entries, etc for validation. jpkg is the packaging tool to create jmod, deb, and other formats such as ips, rpm, and modular jar. While the contents and show commands only apply to jmod files (and possibly modular jars), I think it's fine to add these commands in the jpkg tool since I see these commands will typically be used for validating the contents and run by those who create the jmod file. For other native packaging format, it will use the native packaging tool to list the content and show the package information. The contents command currently lists all entries in a given jmod file sorted by their name. So files in one section may be mixed with files in another section, e.g. native libraries, configuration files may be buried among the class entries. It's also hard to tell which file belong to which section. Would it be better to list the contents by section? Commands.java L92: should this static method simply be package-private method? Files.java L363: extra space can be removed. Librarian.java L109-110: how about wrapping these 2 lines differently for better readability? try (OutputStream fout = (ops.equals("-") ? System.out : new FileOutputStream(ops))) L219: a space to separate '|' and 'IOException is missing to be consistent with the existing convention as in L259. L553, 557, 561: '[...]' in the jmod usage output means optional. It's a bit confusing to see "jmod [list|ls] .." to show the short form of a jmod command. How about: jmod list [-v] [-p] [-R] [] or ls jmod identify or id jmod remove [-f] ... or rm Not ideal and any other better way? ModuleFile.java - the refactoring made it not easy to review but the chnage looks okay to me. Minor nits: L351: I think IAE is fine. L429, 459: 4-space indentation L686: a space is needed between while and '('. Better to rename the variable 'b_read' to 'bytes' or 'count'? L693: space after (DataOutput) can be removed. Is there any new test added for these? Mandy On 5/17/2012 10:04 AM, Chris Hegarty wrote: > This change adds two new commands to the packaging tool. 'jpkg show' > and 'jpkg contents', which came up on this list a few weeks ago. > > http://cr.openjdk.java.net/~chegar/jigsaw/jpkg_contents.00/webrev/ > > Also, included is various cleanup and restructuring, especially to > ModuleFile, to put in place a structure to more easily support new > compression algorithms. Specifically LZMA. I have a prototype from > last year I need to rebase. > > For now, 'contents' and 'show' are only added jpkg, but I could see > that these may be useful before installing a module into the module > library, so could be applicable to the jmod command also? Or just jmod? > > If these new commands are to stay in jpkg long term we should probably > change the command that builds the jmod/deb files to create/build, so > 'jpkg create ... jmod'. > > Two specific implementation changes to draw attention to in the webrev: > 1) ModuleFile.java (L535 new file). Resources were never being > deflated in the module library. They are now. > 2) Sean, > Can you verify the changes to changes to Singer and > ModuleFile.SignatureSection? All jigsaw signing related tests pass. > > -Chris. From paul.sandoz at oracle.com Tue May 22 02:15:41 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 22 May 2012 11:15:41 +0200 Subject: RFR: jpkg contents/show commands In-Reply-To: <4FBA6321.6030907@oracle.com> References: <4FB52FA1.1070305@oracle.com> <04928CFB-9D3C-40E8-B671-5B79B6D2F018@oracle.com> <4FBA5AE4.1070004@oracle.com> <647BA897-D8DC-4013-9EA9-D10CECCD5A10@oracle.com> <4FBA6321.6030907@oracle.com> Message-ID: <2044D707-10AF-4B08-B253-ED2EC5ACD891@oracle.com> On May 21, 2012, at 5:45 PM, Chris Hegarty wrote: > > On 21/05/2012 16:30, Paul Sandoz wrote: >> .... >> >>>> A useful addition, not suggesting for this patch, is the ability to >>>> extract out jar/class files from a jmod package or a module installed >>>> into a library. >>> >>> 'jmod extract ' will extract the contents of a module >>> file to the file system. Is this what you are looking for? >> >> Yes, will it always extract to a zip of classes or reuse the same >> compression in the module e.g. pack200? > > The current implementation extracts to a zip classes archive. > OK. >> Me too. Does it makes sense for the "jar" command to be reused for >> creating a modular jar? (perhaps in addition to that of jpkg for >> consistency). > > Thanks to Mandy we already have support for modular jars in the jar command :-) I think we just need to add it to jpkg for consistency, as you said. > Thanks. I just verified i can jar up compiled classes in modular class layout and install such a jar into a library. It has the virtue that it works directly with the ant jar task :-) However, "jrepo add" does not work with modular jar files. When using jar it is up to the user to name the jar file with say the version number. For jpkg i guess it makes sense to use the same naming approach as for creating jmod files. Paul. From paul.sandoz at oracle.com Tue May 22 03:32:18 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 22 May 2012 12:32:18 +0200 Subject: Webrev for JAX-WS/JAXB/SAAJ services In-Reply-To: <4FB53057.6080300@oracle.com> References: <9C6837C5-3582-4AE6-A208-4F0829C43E43@oracle.com> <4FB51ECD.1070502@oracle.com> <77A74618-3A03-48E1-A252-B6CEBBA91BC6@oracle.com> <4FB53057.6080300@oracle.com> Message-ID: On May 17, 2012, at 7:07 PM, Jesse Glick wrote: > On 05/17/2012 12:12 PM, Paul Sandoz wrote: >> e.g. a default provider always occurs after any non-default. > > Would seem simpler to not register this provider in module-info.java at all, and just use the simple idiom: > > for (Service s : ServiceLoader.load(Service.class)) { > if (s.handles(arg)) { > return s.dealWith(arg); > } > } > // could of course also inline this code: > Service s = new DefaultService(); > return s.dealWith(arg); Good point. I was thinking it would be useful to capture simple idioms like this in ServiceLoader. With lambda one could potentially do: ServiceLoader.load(Service.class). filter(s -> s.handles(arg)). getFirstOrElse(() -> new DefaultService()). // this method does not currently exist in lambda dealWith(arg); And with ServiceLoader: // Dunno if there is a short hand for referencing a constructor, DefaultService::? ServiceLoader.firstOrDefault(() -> new DefaultService()) ServiceLoader.findOrDefault(s -> s.handles(arg), () -> new DefaultService()) Paul. From sean.mullan at oracle.com Tue May 22 08:37:49 2012 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 22 May 2012 11:37:49 -0400 Subject: Review Request: signed module code restructuring/refactoring In-Reply-To: <4FB6A7AA.50408@oracle.com> References: <4FB6A7AA.50408@oracle.com> Message-ID: <4FBBB2CD.9030100@oracle.com> Mandy/Alan/Vinnie - can one of you review these changes? Thanks, Sean On 05/18/2012 03:48 PM, Sean Mullan wrote: > I have restructured and refactored the signed module code. In particular I have > removed the ModuleFileVerifier and ModuleFileSigner interfaces (they really > didn't add any value) and made a few improvements here and there. > > webrev: > http://cr.openjdk.java.net/~mullan/jigsaw/webrevs/signed-module-refactor/webrev.00/ > > Thanks, > Sean From chris.hegarty at oracle.com Tue May 22 09:00:34 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 22 May 2012 17:00:34 +0100 Subject: Review Request: signed module code restructuring/refactoring In-Reply-To: <4FBBB2CD.9030100@oracle.com> References: <4FB6A7AA.50408@oracle.com> <4FBBB2CD.9030100@oracle.com> Message-ID: <4FBBB822.4000304@oracle.com> On 22/05/12 16:37, Sean Mullan wrote: > Mandy/Alan/Vinnie - can one of you review these changes? Sean, while I'm not a reviewer, I did start looking at these changes yesterday and hope to complete tomorrow. -Chris. > > Thanks, > Sean > > On 05/18/2012 03:48 PM, Sean Mullan wrote: >> I have restructured and refactored the signed module code. In >> particular I have >> removed the ModuleFileVerifier and ModuleFileSigner interfaces (they >> really >> didn't add any value) and made a few improvements here and there. >> >> webrev: >> http://cr.openjdk.java.net/~mullan/jigsaw/webrevs/signed-module-refactor/webrev.00/ >> >> >> Thanks, >> Sean > From mandy.chung at oracle.com Tue May 22 09:46:17 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 22 May 2012 09:46:17 -0700 Subject: Review Request: signed module code restructuring/refactoring In-Reply-To: <4FBBB2CD.9030100@oracle.com> References: <4FB6A7AA.50408@oracle.com> <4FBBB2CD.9030100@oracle.com> Message-ID: <4FBBC2D9.1020708@oracle.com> On 5/22/2012 8:37 AM, Sean Mullan wrote: > Mandy/Alan/Vinnie - can one of you review these changes? > Yes, I plan to do it today/tomorrow. Mandy > Thanks, > Sean > > On 05/18/2012 03:48 PM, Sean Mullan wrote: >> I have restructured and refactored the signed module code. In >> particular I have >> removed the ModuleFileVerifier and ModuleFileSigner interfaces (they >> really >> didn't add any value) and made a few improvements here and there. >> >> webrev: >> http://cr.openjdk.java.net/~mullan/jigsaw/webrevs/signed-module-refactor/webrev.00/ >> >> >> Thanks, >> Sean > From chris.hegarty at oracle.com Tue May 22 12:13:23 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 22 May 2012 20:13:23 +0100 Subject: RFR: Solaris 64-bit images In-Reply-To: <4FBA53D3.9040908@oracle.com> References: <4FBA431B.8080902@oracle.com> <4FBA53D3.9040908@oracle.com> Message-ID: <4FBBE553.1020203@oracle.com> Alan, Updated webrev putting tests that depend on bin/sparcv9|amd64/java launcher on the modules problem list :-( http://cr.openjdk.java.net/~chegar/jigsaw/solaris64_webrev.01/webrev/ I hope I got them all! There is quite a bit of noise in the jdk_tools test target. I'll try to clean up some of this as I get time. -Chris. On 21/05/12 15:40, Alan Bateman wrote: > On 21/05/2012 14:28, Chris Hegarty wrote: >> There is currently an issue with the Solaris 64-bit image. To date >> Solaris 64-bit bundles need to overlay the 32 bit bundle. This doesn't >> currently make sense in the modular world and more thought needs to go >> into how we want to handle this long term. >> >> What I have done in the webrev is to temporarily disable the creation >> of the Solaris 64-bit commands in the amd64/sparcv9 directories, and >> fixup paths to find the appropriate native libraries. This will build >> a 64-bit only bundle and jmod files, similar to what we have on other >> platforms. >> >> For now, I think this is a reasonable solution until we can address >> issues around how to want to handle this long term. >> >> http://cr.openjdk.java.net/~chegar/jigsaw/solaris64_webrev.00/webrev/ >> >> -Chris. > Just to add to Chris's comments, these changes gives us a solaris-x64 > modules build that has the same layout as what we have for linux-x64, > windows-x64, and macosx-x64. There has been suggestions that we should > have one image that supports both 32-bit and 64-bit but that raises > questions as to whether it has one or two system module libraries. For > now having a separate 64-bit image makes the most sense. > > Chris - I looked at the changes and they look okay to me. I also grabbed > the patch and it built a solaris-x64 image as I expected. I'm happy to > push the changes for you. One small thing is that we have a couple of > tests (launcher and JDI tests come to mind) that launch via amd64/bin or > sparcv9/bin. We might need to add them to the ModulesProblemList.txt. > > -Alan. From Alan.Bateman at oracle.com Tue May 22 13:17:23 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 22 May 2012 21:17:23 +0100 Subject: RFR: Solaris 64-bit images In-Reply-To: <4FBBE553.1020203@oracle.com> References: <4FBA431B.8080902@oracle.com> <4FBA53D3.9040908@oracle.com> <4FBBE553.1020203@oracle.com> Message-ID: <4FBBF453.7070107@oracle.com> On 22/05/2012 20:13, Chris Hegarty wrote: > Alan, > > Updated webrev putting tests that depend on bin/sparcv9|amd64/java > launcher on the modules problem list :-( > > http://cr.openjdk.java.net/~chegar/jigsaw/solaris64_webrev.01/webrev/ > > I hope I got them all! There is quite a bit of noise in the jdk_tools > test target. I'll try to clean up some of this as I get time. That looks fine and is actually less than I expected (I expected all the JDI tests to end up on the tests as they use the same framework that I thought uses the launcher in the ISA directory). -Alan. From mandy.chung at oracle.com Tue May 22 16:19:13 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 22 May 2012 16:19:13 -0700 Subject: Review Request: signed module code restructuring/refactoring In-Reply-To: <4FB6A7AA.50408@oracle.com> References: <4FB6A7AA.50408@oracle.com> Message-ID: <4FBC1EF1.6000900@oracle.com> On 5/18/2012 12:48 PM, Sean Mullan wrote: > I have restructured and refactored the signed module code. In particular I have > removed the ModuleFileVerifier and ModuleFileSigner interfaces (they really > didn't add any value) and made a few improvements here and there. > > webrev: > http://cr.openjdk.java.net/~mullan/jigsaw/webrevs/signed-module-refactor/webrev.00/ I went through the changes and look okay to me. Signer.java L96: is this a leftover from debugging? L322-332: storePassword.destroy() throws DestroyFailedException, keyPassword.destroy() will not be called - should it handle this exception case and destroy keyPassword? SimpleLibrary.java L1167: // XXX - better to use '// ##' convention You removed this comment - is it not applicable any more? 1162 // ## Check policy - is signer trusted and what permissions 1163 // ## should be granted? Mandy From karen.kinnear at oracle.com Tue May 22 17:48:36 2012 From: karen.kinnear at oracle.com (karen.kinnear at oracle.com) Date: Wed, 23 May 2012 00:48:36 +0000 Subject: hg: jigsaw/jigsaw/hotspot: Summary: Allow passing in a non-null module loader to translate to boot loader. Message-ID: <20120523004839.EF5BE47488@hg.openjdk.java.net> Changeset: c51a2d4dada0 Author: acorn Date: 2012-05-18 13:34 -0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/c51a2d4dada0 Summary: Allow passing in a non-null module loader to translate to boot loader. Reviewed-by: mchung ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! make/solaris/makefiles/mapfile-vers ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h From chris.hegarty at oracle.com Wed May 23 03:08:52 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 23 May 2012 11:08:52 +0100 Subject: Review Request: signed module code restructuring/refactoring In-Reply-To: <4FBC1EF1.6000900@oracle.com> References: <4FB6A7AA.50408@oracle.com> <4FBC1EF1.6000900@oracle.com> Message-ID: <4FBCB734.7000900@oracle.com> These changes look fine to me. One comment, ModuleFile.getSignature() no longer ensures that readStart has been called, it could potentially return null. I see all your calls ensure that this won't be the case, just wondering if it should? -Chris. On 23/05/2012 00:19, Mandy Chung wrote: > On 5/18/2012 12:48 PM, Sean Mullan wrote: >> I have restructured and refactored the signed module code. In >> particular I have >> removed the ModuleFileVerifier and ModuleFileSigner interfaces (they >> really >> didn't add any value) and made a few improvements here and there. >> >> webrev: >> http://cr.openjdk.java.net/~mullan/jigsaw/webrevs/signed-module-refactor/webrev.00/ >> > > I went through the changes and look okay to me. > > Signer.java > L96: is this a leftover from debugging? > > L322-332: storePassword.destroy() throws DestroyFailedException, > keyPassword.destroy() will not be called - should it handle > this exception case and destroy keyPassword? > > SimpleLibrary.java > L1167: // XXX - better to use '// ##' convention > > You removed this comment - is it not applicable any more? > > 1162 // ## Check policy - is signer trusted and what permissions > 1163 // ## should be granted? > > Mandy > > > From Alan.Bateman at oracle.com Wed May 23 04:38:07 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 23 May 2012 12:38:07 +0100 Subject: @GenerateNativeHeader In-Reply-To: References: Message-ID: <4FBCCC1F.4060606@oracle.com> I think we need to discuss this one. It adds further compile-time dependencies on the jdk.compiler module. On the surface it is harmless, from another angle is anti-modules and also brings up the topic of dependencies that have scope. My primary concern is that we haven't worked out all the details on the bootstrapping of new build and so additional dependencies from the base module may be problematic. Note that there is already one compile time dependency on this annotation (in sun.nio.ch.IOStatus) but that one is trivially removed. -Alan -------- Original Message -------- Subject: Need reviewer - @GenerateNativeHeader Date: Tue, 22 May 2012 18:14:54 -0700 From: Kelly O'Hair To: build-dev at openjdk.java.net build-dev 7170969: Add @GenerateNativeHeader to classes whose fields need to be exported for JNI http://cr.openjdk.java.net/~ohair/openjdk8/generateHeaders1/webrev/ The new build infrastructure wants to fully automate the generation of the JNI header files (running javah). On classes that have "native" methods this is obvious, but class that only export constants, and whose constants are needed in the JNI native code, we need to mark these classes as needing their native header file generated. This change is adding: import javax.tools.annotation.GenerateNativeHeader; /* No native methods here, but the constants are needed in the supporting JNI code */ @GenerateNativeHeader To any class without a native method, but needing to expose it's constants to the native code. -kto From paul.sandoz at oracle.com Wed May 23 05:47:57 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 23 May 2012 14:47:57 +0200 Subject: hg: jigsaw/jigsaw/hotspot: Summary: Allow passing in a non-null module loader to translate to boot loader. In-Reply-To: <20120523004839.EF5BE47488@hg.openjdk.java.net> References: <20120523004839.EF5BE47488@hg.openjdk.java.net> Message-ID: <81CFA9AC-9E34-4F6A-BDD1-EAB675868A07@oracle.com> Hi Karen, Is is correct to assume that something else needs to happen to make: Object.class.getClassLoader() != null e.g. a tweak to the Class.getClassLoader() method? Paul. On May 23, 2012, at 2:48 AM, karen.kinnear at oracle.com wrote: > Changeset: c51a2d4dada0 > Author: acorn > Date: 2012-05-18 13:34 -0400 > URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/c51a2d4dada0 > > Summary: Allow passing in a non-null module loader to translate to boot loader. > Reviewed-by: mchung > > ! make/linux/makefiles/mapfile-vers-debug > ! make/linux/makefiles/mapfile-vers-product > ! make/solaris/makefiles/mapfile-vers > ! src/share/vm/prims/jni.cpp > ! src/share/vm/prims/jvm.cpp > ! src/share/vm/prims/jvm.h > From alan.bateman at oracle.com Wed May 23 07:23:55 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 23 May 2012 14:23:55 +0000 Subject: hg: jigsaw/jigsaw: Build standalone/complete Solaris 64-bit images Message-ID: <20120523142356.1E5AB4749A@hg.openjdk.java.net> Changeset: c677e7c31af8 Author: chegar Date: 2012-05-23 15:09 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/rev/c677e7c31af8 Build standalone/complete Solaris 64-bit images Reviewed-by: alanb ! make/jprt.properties From alan.bateman at oracle.com Wed May 23 07:25:14 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 23 May 2012 14:25:14 +0000 Subject: hg: jigsaw/jigsaw/jdk: Build standalone/complete Solaris 64-bit images Message-ID: <20120523142532.76D8F4749B@hg.openjdk.java.net> Changeset: 76d6f6ee605c Author: chegar Date: 2012-05-23 15:10 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/76d6f6ee605c Build standalone/complete Solaris 64-bit images Reviewed-by: alanb ! make/common/Program.gmk ! make/common/shared/Defs-java.gmk ! make/common/shared/Defs.gmk ! test/ModulesProblemList.txt From sean.mullan at oracle.com Wed May 23 07:36:25 2012 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 23 May 2012 10:36:25 -0400 Subject: Review Request: signed module code restructuring/refactoring In-Reply-To: <4FBC1EF1.6000900@oracle.com> References: <4FB6A7AA.50408@oracle.com> <4FBC1EF1.6000900@oracle.com> Message-ID: <4FBCF5E9.7020802@oracle.com> On 5/22/12 7:19 PM, Mandy Chung wrote: > On 5/18/2012 12:48 PM, Sean Mullan wrote: >> I have restructured and refactored the signed module code. In particular I have >> removed the ModuleFileVerifier and ModuleFileSigner interfaces (they really >> didn't add any value) and made a few improvements here and there. >> >> webrev: >> http://cr.openjdk.java.net/~mullan/jigsaw/webrevs/signed-module-refactor/webrev.00/ > > I went through the changes and look okay to me. > > Signer.java > L96: is this a leftover from debugging? No. It is useful to determine what is causing an error. Librarian has similar code, but only prints a stack trace if a Command.Exception is thrown. I have changed my code to do the same. > L322-332: storePassword.destroy() throws DestroyFailedException, > keyPassword.destroy() will not be called - should it handle > this exception case and destroy keyPassword? Right - I think we need a try-with-passwords feature :) I'll fix this but practically speaking this is probably not necessary. The OpenJDK implementation of KeyStore.PasswordProtection.destroy() does not throw DestroyFailedException (all it does is fill the char array with zeroes). > SimpleLibrary.java > L1167: // XXX - better to use '// ##' convention > > You removed this comment - is it not applicable any more? > > 1162 // ## Check policy - is signer trusted and what permissions > 1163 // ## should be granted? I was thinking this part through a bit and forgot to update it. It is still applicable and is on my TODO list. I've adjusted the comment to reflect what I am thinking at the moment: // ## TODO: Check policy and determine if signer is trusted // ## and what permissions should be granted. // ## If there is no policy entry, show signers and prompt // ## user to accept before proceeding. --Sean From sean.mullan at oracle.com Wed May 23 08:23:41 2012 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 23 May 2012 11:23:41 -0400 Subject: Review Request: signed module code restructuring/refactoring In-Reply-To: <4FBCB734.7000900@oracle.com> References: <4FB6A7AA.50408@oracle.com> <4FBC1EF1.6000900@oracle.com> <4FBCB734.7000900@oracle.com> Message-ID: <4FBD00FD.2030507@oracle.com> On 5/23/12 6:08 AM, Chris Hegarty wrote: > These changes look fine to me. > > One comment, ModuleFile.getSignature() no longer ensures that readStart > has been called, it could potentially return null. I see all your calls > ensure that this won't be the case, just wondering if it should? Right, I'll restore the original code so that it is consistent with the rest of ModuleFile. I was trying to avoid having to always try/catch the IOException. Also as previously mentioned, I'm a little uncomfortable with some of the ModuleFile API [1]. If it remains as an internal API then it's probably ok. --Sean [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2011-March/001185.html > > -Chris. > > On 23/05/2012 00:19, Mandy Chung wrote: >> On 5/18/2012 12:48 PM, Sean Mullan wrote: >>> I have restructured and refactored the signed module code. In >>> particular I have >>> removed the ModuleFileVerifier and ModuleFileSigner interfaces (they >>> really >>> didn't add any value) and made a few improvements here and there. >>> >>> webrev: >>> http://cr.openjdk.java.net/~mullan/jigsaw/webrevs/signed-module-refactor/webrev.00/ >>> >> >> I went through the changes and look okay to me. >> >> Signer.java >> L96: is this a leftover from debugging? >> >> L322-332: storePassword.destroy() throws DestroyFailedException, >> keyPassword.destroy() will not be called - should it handle >> this exception case and destroy keyPassword? >> >> SimpleLibrary.java >> L1167: // XXX - better to use '// ##' convention >> >> You removed this comment - is it not applicable any more? >> >> 1162 // ## Check policy - is signer trusted and what permissions >> 1163 // ## should be granted? >> >> Mandy >> >> >> From jesse.glick at oracle.com Wed May 23 08:48:19 2012 From: jesse.glick at oracle.com (Jesse Glick) Date: Wed, 23 May 2012 11:48:19 -0400 Subject: "Provided" scope (was: @GenerateNativeHeader) In-Reply-To: <4FBCCC1F.4060606@oracle.com> References: <4FBCCC1F.4060606@oracle.com> Message-ID: <4FBD06C3.3070501@oracle.com> On 05/23/2012 07:38 AM, Alan Bateman wrote: > also brings up the topic of dependencies that have scope I guess this case would be similar to what Maven offers with provided: included in compiler classpath but not expected to be available at runtime (nor packed in WEB-INF/lib/*.jar, nor loaded during unit tests, etc.). Such a feature in Jigsaw would be very handy for using annotations (*) and/or (non-Enum) compile-time constants, especially if javac verified that your usage of the dependency was in fact limited to these language features that cannot cause a NoClassDefFoundError. module-info.class should make no mention of the dependency, so I guess these should not be in module-info.java (**). In other words, you would need to pass some new option TBD to javac: $ javac -provided findbugsAnnotations at 2.0.0 mymodule/src (*) RetentionPolicy.RUNTIME annotations are probably OK - they will behave like CLASS retention in this case, but that is presumably what you wanted. (**) According to its apparent current design, which is just a readable form of module-info.class, not a description of source code or compiler instructions except insofar as these things happen to be inferable from runtime metadata. From mandy.chung at oracle.com Wed May 23 08:52:13 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 23 May 2012 08:52:13 -0700 Subject: hg: jigsaw/jigsaw/hotspot: Summary: Allow passing in a non-null module loader to translate to boot loader. In-Reply-To: <81CFA9AC-9E34-4F6A-BDD1-EAB675868A07@oracle.com> References: <20120523004839.EF5BE47488@hg.openjdk.java.net> <81CFA9AC-9E34-4F6A-BDD1-EAB675868A07@oracle.com> Message-ID: <4FBD07AD.9070604@oracle.com> On 5/23/2012 5:47 AM, Paul Sandoz wrote: > Hi Karen, > > Is is correct to assume that something else needs to happen to make: > > Object.class.getClassLoader() != null > > e.g. a tweak to the Class.getClassLoader() method? That's right. With Karen's change, the VM is able to accept non-null loader for the base module. In the current jigsaw/jdk prototype, it can only take null loader if it requests a class in the base module. My next step is to experiment with Class.getClassLoader() returning non-null and evaluate its implication. Mandy > Paul. > > On May 23, 2012, at 2:48 AM, karen.kinnear at oracle.com wrote: > >> Changeset: c51a2d4dada0 >> Author: acorn >> Date: 2012-05-18 13:34 -0400 >> URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/c51a2d4dada0 >> >> Summary: Allow passing in a non-null module loader to translate to boot loader. >> Reviewed-by: mchung >> >> ! make/linux/makefiles/mapfile-vers-debug >> ! make/linux/makefiles/mapfile-vers-product >> ! make/solaris/makefiles/mapfile-vers >> ! src/share/vm/prims/jni.cpp >> ! src/share/vm/prims/jvm.cpp >> ! src/share/vm/prims/jvm.h >> From karen.kinnear at oracle.com Wed May 23 09:30:18 2012 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Wed, 23 May 2012 12:30:18 -0400 Subject: hg: jigsaw/jigsaw/hotspot: Summary: Allow passing in a non-null module loader to translate to boot loader. In-Reply-To: <4FBD07AD.9070604@oracle.com> References: <20120523004839.EF5BE47488@hg.openjdk.java.net> <81CFA9AC-9E34-4F6A-BDD1-EAB675868A07@oracle.com> <4FBD07AD.9070604@oracle.com> Message-ID: <10682C32-4765-4320-B79A-652BCDF30548@oracle.com> A couple more details on that. 1) As Alan pointed out, for existing applications, they should see no difference. 2) When running with modules, this change is to accept a non-null loader for the base module. There are classes which today load with the vm boot loader, i.e. a null class loader, which are not in the base module and so they would already return a non-null loader. e.g. xml, corba, ... thanks, Karen On May 23, 2012, at 11:52 AM, Mandy Chung wrote: > On 5/23/2012 5:47 AM, Paul Sandoz wrote: >> Hi Karen, >> >> Is is correct to assume that something else needs to happen to make: >> >> Object.class.getClassLoader() != null >> >> e.g. a tweak to the Class.getClassLoader() method? > > That's right. With Karen's change, the VM is able to accept non-null loader for the base module. In the current jigsaw/jdk prototype, it can only take null loader if it requests a class in the base module. > > My next step is to experiment with Class.getClassLoader() returning non-null and evaluate its implication. > > Mandy > >> Paul. >> >> On May 23, 2012, at 2:48 AM, karen.kinnear at oracle.com wrote: >> >>> Changeset: c51a2d4dada0 >>> Author: acorn >>> Date: 2012-05-18 13:34 -0400 >>> URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/c51a2d4dada0 >>> >>> Summary: Allow passing in a non-null module loader to translate to boot loader. >>> Reviewed-by: mchung >>> >>> ! make/linux/makefiles/mapfile-vers-debug >>> ! make/linux/makefiles/mapfile-vers-product >>> ! make/solaris/makefiles/mapfile-vers >>> ! src/share/vm/prims/jni.cpp >>> ! src/share/vm/prims/jvm.cpp >>> ! src/share/vm/prims/jvm.h >>> From paul.sandoz at oracle.com Wed May 23 09:31:34 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 23 May 2012 18:31:34 +0200 Subject: ServiceLoader in the JDK Message-ID: <3A0862E2-67F2-44A1-BD7B-3AE6DB0EF0B2@oracle.com> Hi, Here is some proposed changes in the JDK related to service loader (not tested yet! just want some easily feedback): http://cr.openjdk.java.net/~psandoz/jigsaw/jdk-services/webrev/ I have attempted where possible to tidy things up to avoid an explicit reference to a class loader for common patterns hence the addition of the methods ServiceLoader.loadFromClass, ServiceLoader.loadFromSystem and ServiceLoader.loadFromCaller (when in module mode most ServiceLoader.load* method do the equivalent of the latter). The names could be better. I also improved the dump-config to output local service provides and remote service suppliers (see below for an example). Questionable areas: - I left JMX alone. It is doing lots of funky stuff. Plus will likely require spec changes. - com.sun.tools.jdi.VirtualMachineManagerImpl is loading providers (Connector and TransportService) from the class loader of those classes. This is probably not an issue. But i do wonder if it could be replaced with ServiceLoader.loadFromCaller(). - sun.tools.jconsole.JConsole uses a URL class loader (with a plugin path) from which services are loaded. I suppose one solution here would be something like: if (Platform.isModuleMode()) { // Use ServiceLoader.loadFromCaller(JConsolePlugin.class) and ignore the plugin path } else { // code as before } Does the "jconsole -pluginpath " option make much sense on module mode? Although in general I presume a URLClassLoader could be used like this in module mode (i have not verified). Perhaps we require a -L option. Paul. ServiceTest $ jmod -L build/mlib dump-config mfoo configuration roots = [mfoo at 1.0] context +jdk.logging module jdk.logging at 8-ea [/Users/sandoz/Projects/jdk8/jigsaw/build/macosx-x86_64/lib/modules] view jdk.logging at 8-ea local (79) ... remote (74) context +mfoo module mfoo at 1.0 view mfoo at 1.0 local service providers (1) com.sun.net.httpserver.spi.HttpServerProvider foo.HP local (3) foo.Foo:mfoo at 1.0 foo.HP:mfoo at 1.0 foo.HP$1:mfoo at 1.0 remote (48) context +jdk.httpserver module jdk.httpserver at 8-ea [/Users/sandoz/Projects/jdk8/jigsaw/build/macosx-x86_64/lib/modules] view jdk.httpserver at 8-ea remote service suppliers (1) com.sun.net.httpserver.spi.HttpServerProvider +mfoo local (69) ... remote (51) context +jdk.jaxp module jdk.jaxp at 8-ea [/Users/sandoz/Projects/jdk8/jigsaw/build/macosx-x86_64/lib/modules] view jdk.jaxp at 8-ea view jdk.jaxp.internal at 8-ea local (2335) ... remote (46) context +jdk.rmi module jdk.rmi at 8-ea [/Users/sandoz/Projects/jdk8/jigsaw/build/macosx-x86_64/lib/modules] view jdk.rmid at 8-ea view jdk.rmi.internal at 8-ea view jdk.rmiregistry at 8-ea view jdk.rmi at 8-ea local (243) ... remote (79) context +jdk.auth+jdk.base+jdk.desktop+jdk.jndi+jdk.prefs+jdk.tls+sun.charsets+sun.localedata module sun.localedata at 8-ea [/Users/sandoz/Projects/jdk8/jigsaw/build/macosx-x86_64/lib/modules] view sun.localedata at 8-ea module jdk.tls at 8-ea [/Users/sandoz/Projects/jdk8/jigsaw/build/macosx-x86_64/lib/modules] view jdk.tls.internal at 8-ea view jdk.tls at 8-ea module jdk.base at 8-ea [/Users/sandoz/Projects/jdk8/jigsaw/build/macosx-x86_64/lib/modules] view jdk.base at 8-ea view jdk.base.unsafe at 8-ea view jdk.base.internal at 8-ea view jdk.base.oracle at 8-ea view jdk.jmod at 8-ea module sun.charsets at 8-ea [/Users/sandoz/Projects/jdk8/jigsaw/build/macosx-x86_64/lib/modules] view sun.charsets.internal at 8-ea view sun.charsets at 8-ea module jdk.prefs at 8-ea [/Users/sandoz/Projects/jdk8/jigsaw/build/macosx-x86_64/lib/modules] view jdk.prefs at 8-ea module jdk.jndi at 8-ea [/Users/sandoz/Projects/jdk8/jigsaw/build/macosx-x86_64/lib/modules] view jdk.jndi.internal at 8-ea view jdk.jndi at 8-ea module jdk.auth at 8-ea [/Users/sandoz/Projects/jdk8/jigsaw/build/macosx-x86_64/lib/modules] view jdk.auth.internal at 8-ea view jdk.auth at 8-ea module jdk.desktop at 8-ea [/Users/sandoz/Projects/jdk8/jigsaw/build/macosx-x86_64/lib/modules] view jdk.desktop at 8-ea view jdk.desktop.internal at 8-ea local service providers (6) sun.net.spi.nameservice.NameServiceDescriptor sun.net.spi.nameservice.dns.DNSNameServiceDescriptor javax.print.PrintServiceLookup sun.print.UnixPrintServiceLookup sun.java2d.cmm.PCMM sun.java2d.cmm.lcms.LCMS javax.print.StreamPrintServiceFactory sun.print.PSStreamPrinterFactory sun.java2d.pipe.RenderingEngine sun.java2d.jules.JulesRenderingEngine sun.java2d.pisces.PiscesRenderingEngine java.nio.charset.spi.CharsetProvider sun.nio.cs.ext.ExtendedCharsets local (10920) ... remote (46) From david.lloyd at redhat.com Wed May 23 09:51:39 2012 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 23 May 2012 11:51:39 -0500 Subject: hg: jigsaw/jigsaw/hotspot: Summary: Allow passing in a non-null module loader to translate to boot loader. In-Reply-To: <20120523004839.EF5BE47488@hg.openjdk.java.net> References: <20120523004839.EF5BE47488@hg.openjdk.java.net> Message-ID: <4FBD159B.9040508@redhat.com> On 05/22/2012 07:48 PM, karen.kinnear at oracle.com wrote: > Changeset: c51a2d4dada0 > Author: acorn > Date: 2012-05-18 13:34 -0400 > URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/c51a2d4dada0 > > Summary: Allow passing in a non-null module loader to translate to boot loader. > Reviewed-by: mchung > > ! make/linux/makefiles/mapfile-vers-debug > ! make/linux/makefiles/mapfile-vers-product > ! make/solaris/makefiles/mapfile-vers > ! src/share/vm/prims/jni.cpp > ! src/share/vm/prims/jvm.cpp > ! src/share/vm/prims/jvm.h This change seems to me the wrong way around: since using null as an argument to Class.forName() (and similar) still has to be supported, why not simply have the base module class loader delegate to its parent? This, in combination with "spoofing" the base module's Class.getClassLoader() output, seems like it would suffice. On a related note, most standalone class loaders out in the wild will in fact delegate to their parent. What does this mean when classes that were a part of the core JDK are now in discrete (non-visible) modules? I think this is a major weakness of retroactively modularizing the core. -- - DML From henri.gomez at gmail.com Wed May 23 09:56:11 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Wed, 23 May 2012 09:56:11 -0700 Subject: Berkeley DB required ? Message-ID: Hi to all, I just got the following error during my jigsaw build under OSX : ERROR: You do not have access to valid Berkeley DB header files. Please check your access to /usr/include/db.h and/or check your value of ALT_BDB_HEADERS_PATH, libdb.-dev is frequently pre-installed on many systems, or may be downloaded from your distributions repository or http://www.oracle.com/technetwork/database/berkeleydb/overview/index.html Is it a new requirement ? From david.lloyd at redhat.com Wed May 23 10:04:12 2012 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 23 May 2012 12:04:12 -0500 Subject: ServiceLoader in the JDK In-Reply-To: <3A0862E2-67F2-44A1-BD7B-3AE6DB0EF0B2@oracle.com> References: <3A0862E2-67F2-44A1-BD7B-3AE6DB0EF0B2@oracle.com> Message-ID: <4FBD188C.4040209@redhat.com> On 05/23/2012 11:31 AM, Paul Sandoz wrote: > Hi, > > Here is some proposed changes in the JDK related to service loader > (not tested yet! just want some easily feedback): > > http://cr.openjdk.java.net/~psandoz/jigsaw/jdk-services/webrev/ > > I have attempted where possible to tidy things up to avoid an > explicit reference to a class loader for common patterns hence the > addition of the methods ServiceLoader.loadFromClass, > ServiceLoader.loadFromSystem and ServiceLoader.loadFromCaller (when > in module mode most ServiceLoader.load* method do the equivalent of > the latter). The names could be better. You really don't want to have loadFromCaller(). We experimented with this and found the performance cost to be unjustifiable, especially when you consider what a simple matter it is for the user to pass in their class loader. The recommendation that we make to users in ##java as well as internally and externally here at JBoss is to always use the three-argument form of Class.forName() for this reason as well. Changing load() to depend on the mode is hazardous! There is a lot of code that assumes it is using TCCL. You cannot make TCCL go away. It is *well-established* to mean "the current application", of which there may be more than one in the VM and it may well be a different module than the one calling load() (in fact this is very likely to be the case in Java EE). By depending on mode, the loadFromSystem() semantics are very unintuitive. I would not use this method and would discourage users from using it for this reason. Overall I find this change to be very discouraging, and also very naive. -- - DML From sean.mullan at oracle.com Wed May 23 10:06:19 2012 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 23 May 2012 13:06:19 -0400 Subject: Review Request: signed module code restructuring/refactoring In-Reply-To: <4FB6A7AA.50408@oracle.com> References: <4FB6A7AA.50408@oracle.com> Message-ID: <4FBD190B.9020106@oracle.com> I have posted a second webrev addressing Mandy and Chris' comments at: http://cr.openjdk.java.net/~mullan/jigsaw/webrevs/signed-module-refactor/webrev.01/ Since the comments were all fairly minor/obvious, I will assume I'm ok to push tomorrow if I don't receive any followups. Thanks, Sean On 5/18/12 3:48 PM, Sean Mullan wrote: > I have restructured and refactored the signed module code. In particular I have > removed the ModuleFileVerifier and ModuleFileSigner interfaces (they really > didn't add any value) and made a few improvements here and there. > > webrev: > http://cr.openjdk.java.net/~mullan/jigsaw/webrevs/signed-module-refactor/webrev.00/ > > Thanks, > Sean From Alan.Bateman at oracle.com Wed May 23 10:08:21 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 23 May 2012 18:08:21 +0100 Subject: Berkeley DB required ? In-Reply-To: References: Message-ID: <4FBD1985.1040801@oracle.com> On 23/05/2012 17:56, Henri Gomez wrote: > Hi to all, > > I just got the following error during my jigsaw build under OSX : > > > ERROR: You do not have access to valid Berkeley DB header files. > Please check your access to > /usr/include/db.h > and/or check your value of ALT_BDB_HEADERS_PATH, > libdb.-dev is frequently pre-installed on many systems, > or may be downloaded from your distributions repository or > http://www.oracle.com/technetwork/database/berkeleydb/overview/index.html > > Is it a new requirement ? It's a new repository (jigsaw/jigsaw/bdb). If you sh get_source.sh in the top-level repo then it should clone it for you. -Alan. From mandy.chung at oracle.com Wed May 23 10:29:39 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 23 May 2012 10:29:39 -0700 Subject: Review Request: signed module code restructuring/refactoring In-Reply-To: <4FBD190B.9020106@oracle.com> References: <4FB6A7AA.50408@oracle.com> <4FBD190B.9020106@oracle.com> Message-ID: <4FBD1E83.1010003@oracle.com> On 5/23/2012 10:06 AM, Sean Mullan wrote: > http://cr.openjdk.java.net/~mullan/jigsaw/webrevs/signed-module-refactor/webrev.01/ Looks good. Mandy From jesse.glick at oracle.com Wed May 23 10:38:02 2012 From: jesse.glick at oracle.com (Jesse Glick) Date: Wed, 23 May 2012 13:38:02 -0400 Subject: Caller context (was: ServiceLoader in the JDK) In-Reply-To: <3A0862E2-67F2-44A1-BD7B-3AE6DB0EF0B2@oracle.com> References: <3A0862E2-67F2-44A1-BD7B-3AE6DB0EF0B2@oracle.com> Message-ID: <4FBD207A.2010707@oracle.com> On 05/23/2012 12:31 PM, Paul Sandoz wrote: > ServiceLoader.loadFromCaller A general comment: it would be nice to deprecate APIs whose behavior varies according to the identity of the caller. While these may be convenient, they violate referential transparency. Among other things, this breaks automated refactoring tools: for example, "extract method" into a utility class in a common module could result in a helper method which actually loads different services than original direct calls to ServiceLoader would have! (Depending on how multitenancy gets implemented for something like Java EE based on Jigsaw.) If some sort of "module context" is needed, best to make this explicit. Most simply, add a 'Class caller' parameter. So: for (ServiceLoader.load(Service.class, ThisClient.class)) {...} would iterate all instances of Service provided by modules in the configuration which loads the module defining ThisClient. Of course you could ignore the caller entirely and use a context available statically - i.e. a global (singleton) module configuration, or based on the context class loader as in nonmodular mode, or based on the thread group. Whether such shortcuts would work well under multitenancy is another matter. From Alan.Bateman at oracle.com Wed May 23 11:29:36 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 23 May 2012 19:29:36 +0100 Subject: ServiceLoader in the JDK In-Reply-To: <3A0862E2-67F2-44A1-BD7B-3AE6DB0EF0B2@oracle.com> References: <3A0862E2-67F2-44A1-BD7B-3AE6DB0EF0B2@oracle.com> Message-ID: <4FBD2C90.1060704@oracle.com> On 23/05/2012 17:31, Paul Sandoz wrote: > Hi, > > Here is some proposed changes in the JDK related to service loader (not tested yet! just want some easily feedback): > > http://cr.openjdk.java.net/~psandoz/jigsaw/jdk-services/webrev/ > > I have attempted where possible to tidy things up to avoid an explicit reference to a class loader for common patterns hence the addition of the methods ServiceLoader.loadFromClass, ServiceLoader.loadFromSystem and ServiceLoader.loadFromCaller (when in module mode most ServiceLoader.load* method do the equivalent of the latter). The names could be better. I agree the names are problematic, I'm also not sure that we really need them either. loadFromClass(c) is specified to work like load(c,c.getClassLoader()) but it works differently when working with modules? loadFromSystem is specified to use the system class loader so will be confusing when running with modules. For the 10 or so cases in the JDK then an alternative push the check back to the use sites. I'm also not sure about loadFromCaller. Determining the caller is expensive and at least for the usages in the JDK then load(Class,ClassLoader) should be okay. One other thing about ServiceLoader is that we have to put in a few hacks (to use the caller loader) in order to keep it working with existing code. Once all usages are cleaned then this of course can be re-vistied. Anyway, I scanned the rest of the JDK patch. One thing is that we'll need to work out spec/javadoc changes for many of these cases. I would suggest ignoring JMX for now as it will require a special update. JDI is specified to use Connector and TransportService providers using the defining loader of the Connector and TransportService types so I don't think it requires any changes. Phil may be able to say something about the rendering engine code but I think this is just for switching between rendering engines and that they are will all be loaded by the module loader for the desktop module. Mandy will likely have an opinion on jconsole but my take is that it's mostly replaced by VisualVM now and maybe we don't do anything and run just it with -Xmode:legacy. Having dump-config include the services configuration is a good idea. -Alan. From henri.gomez at gmail.com Wed May 23 13:12:32 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Wed, 23 May 2012 13:12:32 -0700 Subject: Berkeley DB required ? In-Reply-To: <4FBD1985.1040801@oracle.com> References: <4FBD1985.1040801@oracle.com> Message-ID: > It's a new repository (jigsaw/jigsaw/bdb). If you sh get_source.sh in the > top-level repo then it should clone it for you. Hey, good to know, I didn't see it. So BDB could then be redistributed bundled in Jigsaw ? From chris.hegarty at oracle.com Wed May 23 13:49:08 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 23 May 2012 21:49:08 +0100 Subject: Berkeley DB required ? In-Reply-To: References: <4FBD1985.1040801@oracle.com> Message-ID: <4FBD4D44.9040604@oracle.com> On 23/05/12 21:12, Henri Gomez wrote: >> It's a new repository (jigsaw/jigsaw/bdb). If you sh get_source.sh in the >> top-level repo then it should clone it for you. > > Hey, good to know, I didn't see it. Given that BDB is bundled with some distros we support building and running against the system installed BDB, and that's the defacto when the bdb repo is not in your environment. Some of us still use the forest extension ;^) and an fpull will sync bdb even if not initially cloned. > So BDB could then be redistributed bundled in Jigsaw ? We included a small footprint implementation of Berkeley DB, called Restricted Data Store (RDS). It is a minimal build of Berkeley DB that supports only b-tree access, and provides a simple Java interface to support the functionality required by the runtime (Jigsaw will also use the native interface). -Chris. From sean.mullan at oracle.com Wed May 23 14:00:48 2012 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 23 May 2012 17:00:48 -0400 Subject: Process question Message-ID: <4FBD5000.4010500@oracle.com> Is there (or will there be) a convention for listing a reviewer who does not have Reviewer status in a changeset? For example, Chris and Mandy reviewed my most recent webrev. I would like to document that Chris also reviewed it in the changeset, even though Chris does not have Reviewer status. Perhaps this is a general openjdk question, but thought I'd ask it here first. --Sean From sean.mullan at oracle.com Wed May 23 14:29:32 2012 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 23 May 2012 17:29:32 -0400 Subject: Process question In-Reply-To: <4FBD5000.4010500@oracle.com> References: <4FBD5000.4010500@oracle.com> Message-ID: <4FBD56BC.8090608@oracle.com> Chris reminded me that there are no official Reviewers for the jigsaw project. I suppose I will list any author that reviews it then. Though I'm still curious how my question applies to other projects that do have Reviewers, like jdk8. --Sean On 5/23/12 5:00 PM, Sean Mullan wrote: > Is there (or will there be) a convention for listing a reviewer who does not > have Reviewer status in a changeset? For example, Chris and Mandy reviewed my > most recent webrev. I would like to document that Chris also reviewed it in the > changeset, even though Chris does not have Reviewer status. > > Perhaps this is a general openjdk question, but thought I'd ask it here first. > > --Sean From jonathan.gibbons at oracle.com Wed May 23 14:34:08 2012 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 23 May 2012 14:34:08 -0700 Subject: Process question In-Reply-To: <4FBD5000.4010500@oracle.com> References: <4FBD5000.4010500@oracle.com> Message-ID: <4FBD57D0.3080407@oracle.com> On 05/23/2012 02:00 PM, Sean Mullan wrote: > Is there (or will there be) a convention for listing a reviewer who does not > have Reviewer status in a changeset? For example, Chris and Mandy reviewed my > most recent webrev. I would like to document that Chris also reviewed it in the > changeset, even though Chris does not have Reviewer status. > > Perhaps this is a general openjdk question, but thought I'd ask it here first. > > --Sean In other contexts, I have just listed people as a reviewer, assuming they have an OpenJDK username. -- Jon From henri.gomez at gmail.com Wed May 23 14:45:09 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Wed, 23 May 2012 14:45:09 -0700 Subject: Berkeley DB required ? In-Reply-To: <4FBD4D44.9040604@oracle.com> References: <4FBD1985.1040801@oracle.com> <4FBD4D44.9040604@oracle.com> Message-ID: > Given that BDB is bundled with some distros we support building and running > against the system installed BDB, and that's the defacto when the bdb repo > is not in your environment. Some of us still use the forest extension ;^) > and an fpull will sync bdb even if not initially cloned. BDB is not installed on OSX, so I added bdb hg repo to build it. During build I see many reference to /usr/local/BerkeleyDB.5.4 like : ./libtool --mode=link /Applications/Xcode.app/Contents/Developer/usr/bin/llvm-gcc -avoid-version -Os -rpath /usr/local/BerkeleyDB.5.4/lib -o libdb-5.4.la mut_tas.lo partition_stub.lo hash_stub.lo heap_stub.lo qam_stub.lo rep_stub.lo repmgr_stub.lo db_vrfy_stub.lo log_verify_stub.lo mut_alloc.lo mut_method.lo mut_region.lo mut_stat.lo rds_stub.lo lock_stub.lo crypto_stub.lo bt_compare.lo bt_conv.lo bt_curadj.lo bt_cursor.lo bt_delete.lo bt_method.lo bt_open.lo bt_put.lo bt_reclaim.lo bt_recno.lo bt_rsearch.lo bt_search.lo bt_split.lo bt_stat.lo clock.lo db.lo db_am.lo db_byteorder.lo db_cam.lo db_conv.lo db_dup.lo db_err.lo db_getlong.lo db_idspace.lo db_iface.lo db_log2.lo db_meta.lo db_method.lo db_open.lo db_overflow.lo db_pr.lo db_reclaim.lo db_remove.lo db_rename.lo db_ret.lo db_setid.lo db_setlsn.lo db_shash.lo db_sort_multiple.lo db_stati.lo db_truncate.lo dbt.lo env_alloc.lo env_config.lo env_file.lo env_globals.lo env_open.lo env_method.lo env_name.lo env_region.lo env_sig.lo env_stat.lo fop_basic.lo fop_util.lo hash_func.lo mkpath.lo mp_alloc.lo mp_bh.lo mp_fget.lo mp_fmethod.lo mp_fopen.lo mp_fput.lo mp_fset.lo mp_method.lo mp_region.lo mp_register.lo mp_resize.lo mp_stat.lo mp_sync.lo mp_trickle.lo os_abort.lo os_abs.lo os_alloc.lo os_clock.lo os_cpu.lo os_ctime.lo os_config.lo os_dir.lo os_errno.lo os_fid.lo os_flock.lo os_fsync.lo os_getenv.lo os_handle.lo os_map.lo os_method.lo os_mkdir.lo os_open.lo os_path.lo os_pid.lo os_rename.lo os_root.lo os_rpath.lo os_rw.lo os_seek.lo os_stack.lo os_stat.lo os_tmpdir.lo os_truncate.lo os_uid.lo os_unlink.lo os_yield.lo snprintf.lo zerofill.lo \ -lpthread ... libtool: link: /Applications/Xcode.app/Contents/Developer/usr/bin/llvm-gcc -dynamiclib -Wl,-undefined -Wl,dynamic_lookup -o .libs/libdb-5.4.dylib .libs/mut_tas.o .libs/partition_stub.o .libs/hash_stub.o .libs/heap_stub.o .libs/qam_stub.o .libs/rep_stub.o .libs/repmgr_stub.o .libs/db_vrfy_stub.o .libs/log_verify_stub.o .libs/mut_alloc.o .libs/mut_method.o .libs/mut_region.o .libs/mut_stat.o .libs/rds_stub.o .libs/lock_stub.o .libs/crypto_stub.o .libs/bt_compare.o .libs/bt_conv.o .libs/bt_curadj.o .libs/bt_cursor.o .libs/bt_delete.o .libs/bt_method.o .libs/bt_open.o .libs/bt_put.o .libs/bt_reclaim.o .libs/bt_recno.o .libs/bt_rsearch.o .libs/bt_search.o .libs/bt_split.o .libs/bt_stat.o .libs/clock.o .libs/db.o .libs/db_am.o .libs/db_byteorder.o .libs/db_cam.o .libs/db_conv.o .libs/db_dup.o .libs/db_err.o .libs/db_getlong.o .libs/db_idspace.o .libs/db_iface.o .libs/db_log2.o .libs/db_meta.o .libs/db_method.o .libs/db_open.o .libs/db_overflow.o .libs/db_pr.o .libs/db_reclaim.o .libs/db_remove.o .libs/db_rename.o .libs/db_ret.o .libs/db_setid.o .libs/db_setlsn.o .libs/db_shash.o .libs/db_sort_multiple.o .libs/db_stati.o .libs/db_truncate.o .libs/dbt.o .libs/env_alloc.o .libs/env_config.o .libs/env_file.o .libs/env_globals.o .libs/env_open.o .libs/env_method.o .libs/env_name.o .libs/env_region.o .libs/env_sig.o .libs/env_stat.o .libs/fop_basic.o .libs/fop_util.o .libs/hash_func.o .libs/mkpath.o .libs/mp_alloc.o .libs/mp_bh.o .libs/mp_fget.o .libs/mp_fmethod.o .libs/mp_fopen.o .libs/mp_fput.o .libs/mp_fset.o .libs/mp_method.o .libs/mp_region.o .libs/mp_register.o .libs/mp_resize.o .libs/mp_stat.o .libs/mp_sync.o .libs/mp_trickle.o .libs/os_abort.o .libs/os_abs.o .libs/os_alloc.o .libs/os_clock.o .libs/os_cpu.o .libs/os_ctime.o .libs/os_config.o .libs/os_dir.o .libs/os_errno.o .libs/os_fid.o .libs/os_flock.o .libs/os_fsync.o .libs/os_getenv.o .libs/os_handle.o .libs/os_map.o .libs/os_method.o .libs/os_mkdir.o .libs/os_open.o .libs/os_path.o .libs/os_pid.o .libs/os_rename.o .libs/os_root.o .libs/os_rpath.o .libs/os_rw.o .libs/os_seek.o .libs/os_stack.o .libs/os_stat.o .libs/os_tmpdir.o .libs/os_truncate.o .libs/os_uid.o .libs/os_unlink.o .libs/os_yield.o .libs/snprintf.o .libs/zerofill.o -lpthread -Os -install_name /usr/local/BerkeleyDB.5.4/lib/libdb-5.4.dylib -Wl,-single_module libtool: link: ( cd ".libs" && rm -f "libdb-5.4.la" && ln -s "../libdb-5.4.la" "libdb-5.4.la" ) rm -f libdb.a ln -s .libs/libdb-5.4.a libdb.a ... Library loads for: /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jigsaw/workspace/build/macosx-x86_64/lib/libdb-rds.dylib /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jigsaw/workspace/build/macosx-x86_64/lib/libdb-rds.dylib: /usr/local/BerkeleyDB.5.4/lib/libdb-5.4.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0) ... Wondering why dylib is referenced in /usr/local/BerkeleyDB.5.4/lib/libdb-5.4.dylib ? >> So BDB could then be redistributed bundled in Jigsaw ? > > > We included a small footprint implementation of Berkeley DB, called > Restricted Data Store (RDS). It is a minimal build of Berkeley DB that > supports only b-tree access, and provides a simple Java interface to support > the functionality required by the runtime (Jigsaw will also use the native > interface). > > -Chris. From henri.gomez at gmail.com Wed May 23 14:54:36 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Wed, 23 May 2012 14:54:36 -0700 Subject: Berkeley DB required ? In-Reply-To: References: <4FBD1985.1040801@oracle.com> <4FBD4D44.9040604@oracle.com> Message-ID: > Wondering why dylib is referenced in > /usr/local/BerkeleyDB.5.4/lib/libdb-5.4.dylib ? After installation, otool report dependencies on /usr/local/BerkeleyDB.5.4/lib/libdb-5.4.dylib otool -L /Library/Java/JavaVirtualMachines/1.8.0-jigsaw.jdk/Contents/Home/lib/libdb-rds.dylib /Library/Java/JavaVirtualMachines/1.8.0-jigsaw.jdk/Contents/Home/lib/libdb-rds.dylib: /usr/local/BerkeleyDB.5.4/lib/libdb-5.4.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0) Of course there is just no /usr/local/BerkeleyDB.5.4 directory so what's this reference ? From paul.sandoz at oracle.com Wed May 23 15:24:34 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 24 May 2012 00:24:34 +0200 Subject: ServiceLoader in the JDK In-Reply-To: <4FBD188C.4040209@redhat.com> References: <3A0862E2-67F2-44A1-BD7B-3AE6DB0EF0B2@oracle.com> <4FBD188C.4040209@redhat.com> Message-ID: <390DBA40-48BC-4B2C-A362-92406BB7968E@oracle.com> On May 23, 2012, at 7:04 PM, David M. Lloyd wrote: > On 05/23/2012 11:31 AM, Paul Sandoz wrote: >> Hi, >> >> Here is some proposed changes in the JDK related to service loader >> (not tested yet! just want some easily feedback): >> >> http://cr.openjdk.java.net/~psandoz/jigsaw/jdk-services/webrev/ >> >> I have attempted where possible to tidy things up to avoid an >> explicit reference to a class loader for common patterns hence the >> addition of the methods ServiceLoader.loadFromClass, >> ServiceLoader.loadFromSystem and ServiceLoader.loadFromCaller (when >> in module mode most ServiceLoader.load* method do the equivalent of >> the latter). The names could be better. > > You really don't want to have loadFromCaller(). We experimented with this and found the performance cost to be unjustifiable, especially when you consider what a simple matter it is for the user to pass in their class loader. The recommendation that we make to users in ##java as well as internally and externally here at JBoss is to always use the three-argument form of Class.forName() for this reason as well. > Thanks, good to know. > Changing load() to depend on the mode is hazardous! There is a lot of code that assumes it is using TCCL. You cannot make TCCL go away. It is *well-established* to mean "the current application", of which there may be more than one in the VM and it may well be a different module than the one calling load() (in fact this is very likely to be the case in Java EE). > Yes, it's everywhere in EE land. TCCL is currently problematic with modular mode and service loading as the CL of the module declaring the "requires service" needs to be used. The whole area of containers still needs to be fleshed out, including what impact that has on services. > By depending on mode, the loadFromSystem() semantics are very unintuitive. I would not use this method and would discourage users from using it for this reason. > > Overall I find this change to be very discouraging, and also very naive. > No doubt :-) discourage ye not, it's a failed experiment that has received some very useful feedback from yourself and Alan and Jesse. What i am hearing is the approach to try and avoid the caller declaring the class loader and inferring the class loader is the opposite direction of where we should be going with this, and instead either the class loader should be explicitly declared or some other context (as Jesse points out) should be explicitly declared from which the class loader can be efficiently obtained. I also tried to avoid "if (Platform.isModuleMode()) { ... } else { .... }" blocks for code calling ServiceLoader, but perhaps that is unavoidable if it is not possible to be explicit with a single call to ServiceLoader encapsulating classpath and modular mode behaviour. Paul. From david.holmes at oracle.com Wed May 23 16:12:00 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 24 May 2012 09:12:00 +1000 Subject: hg: jigsaw/jigsaw/hotspot: Summary: Allow passing in a non-null module loader to translate to boot loader. In-Reply-To: <4FBD159B.9040508@redhat.com> References: <20120523004839.EF5BE47488@hg.openjdk.java.net> <4FBD159B.9040508@redhat.com> Message-ID: <4FBD6EC0.1060500@oracle.com> On 24/05/2012 2:51 AM, David M. Lloyd wrote: > On 05/22/2012 07:48 PM, karen.kinnear at oracle.com wrote: >> Changeset: c51a2d4dada0 >> Author: acorn >> Date: 2012-05-18 13:34 -0400 >> URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/c51a2d4dada0 >> >> Summary: Allow passing in a non-null module loader to translate to >> boot loader. >> Reviewed-by: mchung >> >> ! make/linux/makefiles/mapfile-vers-debug >> ! make/linux/makefiles/mapfile-vers-product >> ! make/solaris/makefiles/mapfile-vers >> ! src/share/vm/prims/jni.cpp >> ! src/share/vm/prims/jvm.cpp >> ! src/share/vm/prims/jvm.h > > This change seems to me the wrong way around: since using null as an > argument to Class.forName() (and similar) still has to be supported, why > not simply have the base module class loader delegate to its parent? > This, in combination with "spoofing" the base module's > Class.getClassLoader() output, seems like it would suffice. > > On a related note, most standalone class loaders out in the wild will in > fact delegate to their parent. What does this mean when classes that > were a part of the core JDK are now in discrete (non-visible) modules? I > think this is a major weakness of retroactively modularizing the core. I'm still trying to see how things connect but assuming legacy mode I assume there will be something equivalent of the current "system classloader" and I would expect it to have a parent that is the base module loader, and the base module loader knows how to use the module system to find the right module loader for a given class. Is that a reasonable picture? If not what is the actual picture? David Holmes From david.holmes at oracle.com Wed May 23 16:18:17 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 24 May 2012 09:18:17 +1000 Subject: Process question In-Reply-To: <4FBD5000.4010500@oracle.com> References: <4FBD5000.4010500@oracle.com> Message-ID: <4FBD7039.3000208@oracle.com> On 24/05/2012 7:00 AM, Sean Mullan wrote: > Is there (or will there be) a convention for listing a reviewer who does not > have Reviewer status in a changeset? For example, Chris and Mandy reviewed my > most recent webrev. I would like to document that Chris also reviewed it in the > changeset, even though Chris does not have Reviewer status. > > Perhaps this is a general openjdk question, but thought I'd ask it here first. You can list anyone with an openjdk user name as a "reviewer". Depending on the rules of the project one or more of those people must also be a Reviewer. David > --Sean From sean.mullan at oracle.com Wed May 23 17:19:39 2012 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Thu, 24 May 2012 00:19:39 +0000 Subject: hg: jigsaw/jigsaw/jdk: 2 new changesets Message-ID: <20120524002008.28C7F474B4@hg.openjdk.java.net> Changeset: 31e16be113ba Author: mullan Date: 2012-05-23 17:34 -0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/31e16be113ba Summary: Signed Module restructuring and refactoring Reviewed-by: mchung, chegar ! src/share/classes/org/openjdk/jigsaw/ModuleFile.java - src/share/classes/org/openjdk/jigsaw/ModuleFileSigner.java - src/share/classes/org/openjdk/jigsaw/ModuleFileVerifier.java ! src/share/classes/org/openjdk/jigsaw/SignedModule.java ! src/share/classes/org/openjdk/jigsaw/SimpleLibrary.java ! src/share/classes/org/openjdk/jigsaw/cli/Command.java ! src/share/classes/org/openjdk/jigsaw/cli/Signer.java ! test/org/openjdk/jigsaw/cli/ModuleFileTest.java Changeset: ee8827bd5495 Author: mullan Date: 2012-05-23 17:37 -0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/ee8827bd5495 Merge ! src/share/classes/org/openjdk/jigsaw/ModuleFile.java ! src/share/classes/org/openjdk/jigsaw/SimpleLibrary.java - src/share/native/org/openjdk/jigsaw/BootLoader.c From mandy.chung at oracle.com Wed May 23 17:42:31 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 23 May 2012 17:42:31 -0700 Subject: hg: jigsaw/jigsaw/hotspot: Summary: Allow passing in a non-null module loader to translate to boot loader. In-Reply-To: <4FBD159B.9040508@redhat.com> References: <20120523004839.EF5BE47488@hg.openjdk.java.net> <4FBD159B.9040508@redhat.com> Message-ID: <4FBD83F7.9060606@oracle.com> On 5/23/2012 9:51 AM, David M. Lloyd wrote: > > This change seems to me the wrong way around: since using null as an > argument to Class.forName() (and similar) still has to be supported, > why not simply have the base module class loader delegate to its parent? FWIW, the base module class loader does delegate to VM null loader in the implementation. In classpath mode, Class.forName() with a null class loader argument will load classes from the bootclasspath. In module mode, when Class.forName() with a null loader is called, do you expect it loads classes only in the base module or all classes from all jdk modules? > This, in combination with "spoofing" the base module's > Class.getClassLoader() output, seems like it would suffice. > > On a related note, most standalone class loaders out in the wild will > in fact delegate to their parent. What does this mean when classes > that were a part of the core JDK are now in discrete (non-visible) > modules? I think this is a major weakness of retroactively > modularizing the core. > In classpath mode, existing application and class loaders should work as it is today. The platform modularization should be transparent to the classpath mode applications/class loader. In module mode, a relevant question is what module do classes loaded by the non-module class loader belong to? What types are visible to that non-module class loader? One initial proposal is to have classes loaded by a non-module class loader belong to the module in which that class loader is created. Therefore, all types visible to the module will also be visible to that non-module class loader. Details are yet to be fleshed out and prototyped. Mandy From mandy.chung at oracle.com Wed May 23 17:59:22 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 23 May 2012 17:59:22 -0700 Subject: hg: jigsaw/jigsaw/hotspot: Summary: Allow passing in a non-null module loader to translate to boot loader. In-Reply-To: <4FBD6EC0.1060500@oracle.com> References: <20120523004839.EF5BE47488@hg.openjdk.java.net> <4FBD159B.9040508@redhat.com> <4FBD6EC0.1060500@oracle.com> Message-ID: <4FBD87EA.8070003@oracle.com> On 5/23/2012 4:12 PM, David Holmes wrote: > I'm still trying to see how things connect but assuming legacy mode I > assume there will be something equivalent of the current "system > classloader" and I would expect it to have a parent that is the base > module loader, and the base module loader knows how to use the module > system to find the right module loader for a given class. > We now refer "legacy mode" to as "classpath" mode (thanks to Serguei for the better name). "legacy" may be interpreted as obsolete and not supported which is not our intent. In classpath mode, the bootstrap classes will continue to be loaded by the null loader for compatibility reason. So it will load all classes from base, desktop, jaxp, corba, rmi modules etc (not only the base module). Essentially all modules that constitute the rt.jar and classes on the bootclasspath. In module mode, the base module loader plays an important role to find the right module loader for a given class in another module. In classpath mode, it isn't the case. My view is that it no longer needs the base module loader for class loading but we may still need it for getting resources. > Is that a reasonable picture? If not what is the actual picture? I think your question is specifically for classpath mode. My current view is that it will continue to have the bootstrap null loader, extension class loader, and system class loader finding and defining the same set of classes as it is today. There are still module loaders created for the jdk modules but the extension class loader and system class loader will delegate to the right module loader to find a class in the ext directory and classpath. The module loaders for the bootstrap classes are only used to lookup anything other than classes. Karen and I are working on a prototype to find out if there is any issue with this approach. Mandy From david.holmes at oracle.com Wed May 23 18:32:13 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 24 May 2012 11:32:13 +1000 Subject: hg: jigsaw/jigsaw/hotspot: Summary: Allow passing in a non-null module loader to translate to boot loader. In-Reply-To: <4FBD83F7.9060606@oracle.com> References: <20120523004839.EF5BE47488@hg.openjdk.java.net> <4FBD159B.9040508@redhat.com> <4FBD83F7.9060606@oracle.com> Message-ID: <4FBD8F9D.70609@oracle.com> On 24/05/2012 10:42 AM, Mandy Chung wrote: > In module mode, a relevant question is what module do classes loaded by > the non-module class loader belong to? I would say they don't, by definition, belong to a module. But this presumes a hybrid model where you have both "classpath" elements and modules. But the very question indicates such a hybrid model must exist. > What types are visible to that non-module class loader? I'm not sure I understand the question. What types are considered "visible" to a particular class loader today? > One initial proposal is to have classes loaded by a non-module class > loader belong to the module in which that class loader is created. I don't see why they must be considered part of any module. This seems to be creating a distinction between a module as a unit of distribution, and a module as a runtime-entity. I've so far been assuming these are one and the same. David ----- > Therefore, all types visible to the module will also be visible to that > non-module class loader. Details are yet to be fleshed out and prototyped. > Mandy > From jesse.glick at oracle.com Wed May 23 19:10:03 2012 From: jesse.glick at oracle.com (Jesse Glick) Date: Wed, 23 May 2012 22:10:03 -0400 Subject: hg: jigsaw/jigsaw/hotspot: Summary: Allow passing in a non-null module loader to translate to boot loader. In-Reply-To: <4FBD83F7.9060606@oracle.com> References: <20120523004839.EF5BE47488@hg.openjdk.java.net> <4FBD159B.9040508@redhat.com> <4FBD83F7.9060606@oracle.com> Message-ID: <4FBD987B.4050109@oracle.com> On 05/23/2012 08:42 PM, Mandy Chung wrote: > have classes loaded by a non-module class loader belong to the module in which that class loader is created How do you determine "in which" module a ClassLoader is created? You cannot check the implementation class because plenty of code creates a plain URLClassLoader. And checking the call stack in effect when the ClassLoader constructor was called is unreliable. > all types visible to the module will also be visible to that non-module class loader This cannot be right. While most existing class loaders do delegate to one "parent", some delegate to multiple parents, some deliberately avoid delegating to anything more than the bare minimum bootstrap class loader (e.g. to implement something akin to an "isolate"), and some have a hybrid policy impossible to categorize. The default proposal should be that a non-module class loader behave as it does today: 1. Those types are visible to it which its loadClass can load (without defining), whatever that method might do. 2. Those types are accessible which are visible, and either public or otherwise accessible according to Java 7 language rules (e.g. in the same non-sealed package). Of course it would be nice to further restrict accessibility by adding a method to ClassLoader: /** Assuming this loader can load {@code type}, and it is accessible by premodule language rules, should it still be accessible? By default, yes. */ protected boolean canAccess(Class type) {return true;} which ModuleClassLoader would then override to check exports, and a custom ClassLoader written against JDK 8 APIs could also override to help support third-party module systems. (Even nicer would be to pass AccessibleObject rather than Class as the parameter, permitting the module system to export or hide individual elements such as methods if it so desires.) From paul.sandoz at oracle.com Thu May 24 01:03:57 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 24 May 2012 10:03:57 +0200 Subject: hg: jigsaw/jigsaw/hotspot: Summary: Allow passing in a non-null module loader to translate to boot loader. In-Reply-To: <10682C32-4765-4320-B79A-652BCDF30548@oracle.com> References: <20120523004839.EF5BE47488@hg.openjdk.java.net> <81CFA9AC-9E34-4F6A-BDD1-EAB675868A07@oracle.com> <4FBD07AD.9070604@oracle.com> <10682C32-4765-4320-B79A-652BCDF30548@oracle.com> Message-ID: <5CB6CB7D-D836-4D65-BEED-E7C8D03B2B14@oracle.com> On May 23, 2012, at 6:30 PM, Karen Kinnear wrote: > A couple more details on that. > > 1) As Alan pointed out, for existing applications, they should see no difference. > 2) When running with modules, this change is to accept a non-null loader for the base module. > There are classes which today load with the vm boot loader, i.e. a null class loader, which are not > in the base module and so they would already return a non-null loader. e.g. xml, corba, ... > I find it useful to enumerate the modes with an example. Classpath mode (existing apps, *nothing changes*): java.lang.Object.class.getClassLoader() == null && com.sun.net.httpserver.HttpServer.class.getClassLoader() == null; Current Jigsaw modular mode: java.lang.Object.class.getClassLoader() == null && com.sun.net.httpserver.HttpServer.class.getClassLoader() != null; "Karen and Mandy's" tweaked Jigsaw modular mode: java.lang.Object.class.getClassLoader() != null && com.sun.net.httpserver.HttpServer.class.getClassLoader() != null && java.lang.Object.class.getClassLoader() != com.sun.net.httpserver.HttpServer.class.getClassLoader(); Paul. From chris.hegarty at oracle.com Thu May 24 03:04:29 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 24 May 2012 11:04:29 +0100 Subject: Berkeley DB required ? In-Reply-To: References: <4FBD1985.1040801@oracle.com> <4FBD4D44.9040604@oracle.com> Message-ID: <4FBE07AD.6030801@oracle.com> On 23/05/2012 22:54, Henri Gomez wrote: >> Wondering why dylib is referenced in >> /usr/local/BerkeleyDB.5.4/lib/libdb-5.4.dylib ? > > After installation, otool report dependencies on > /usr/local/BerkeleyDB.5.4/lib/libdb-5.4.dylib > > otool -L /Library/Java/JavaVirtualMachines/1.8.0-jigsaw.jdk/Contents/Home/lib/libdb-rds.dylib > > /Library/Java/JavaVirtualMachines/1.8.0-jigsaw.jdk/Contents/Home/lib/libdb-rds.dylib: > /usr/local/BerkeleyDB.5.4/lib/libdb-5.4.dylib (compatibility version > 0.0.0, current version 0.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current > version 159.1.0) > > Of course there is just no /usr/local/BerkeleyDB.5.4 directory so > what's this reference ? This is a bug in the BDB makefile/linker options, for now it should be harmless. I'll take note and resolve it in the next update to bdb. The jigsaw bundled BDB is a stripped down version of the full BDB release. It uses the same configure and makefiles as its larger brother. The full BDB build can produce several native libraries, for supporting SQL API, STL API, C++ API, etc, depending on the options passed to the configure script. These additional libraries have a dependency on the core libdb-XXX.so library. This is achieved by adding an rpath to the default location of the libdb, which happens to be /usr/local/BerkeleyDB.5.4 on Mac OSX. It just happens to be set in a common linker options variable. Since the jigsaw bundled bdb library is standalone and independent of any of the above mentioned additional BDB libraries is does not need this rpath set. -Chris. From paul.sandoz at oracle.com Thu May 24 04:41:47 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 24 May 2012 13:41:47 +0200 Subject: ServiceLoader in the JDK In-Reply-To: <4FBD2C90.1060704@oracle.com> References: <3A0862E2-67F2-44A1-BD7B-3AE6DB0EF0B2@oracle.com> <4FBD2C90.1060704@oracle.com> Message-ID: <7599192B-0DF3-4ADA-8C1F-52401DEA7E46@oracle.com> On May 23, 2012, at 8:29 PM, Alan Bateman wrote: > On 23/05/2012 17:31, Paul Sandoz wrote: >> Hi, >> >> Here is some proposed changes in the JDK related to service loader (not tested yet! just want some easily feedback): >> >> http://cr.openjdk.java.net/~psandoz/jigsaw/jdk-services/webrev/ >> >> I have attempted where possible to tidy things up to avoid an explicit reference to a class loader for common patterns hence the addition of the methods ServiceLoader.loadFromClass, ServiceLoader.loadFromSystem and ServiceLoader.loadFromCaller (when in module mode most ServiceLoader.load* method do the equivalent of the latter). The names could be better. > I agree the names are problematic, I'm also not sure that we really need them either. > > loadFromClass(c) is specified to work like load(c,c.getClassLoader()) but it works differently when working with modules? > Yeah it uses the same hack as for load(Class, ClassLoader) > loadFromSystem is specified to use the system class loader so will be confusing when running with modules. For the 10 or so cases in the JDK then an alternative push the check back to the use sites. > Yes, it was attempting to encapsulate "if (Platform.isModuleMode()) { // do this } else { // do that }" > I'm also not sure about loadFromCaller. Determining the caller is expensive and at least for the usages in the JDK then load(Class,ClassLoader) should be okay. > > One other thing about ServiceLoader is that we have to put in a few hacks (to use the caller loader) in order to keep it working with existing code. Once all usages are cleaned then this of course can be revisited. I knew what was done in load(Class, ClassLoader) was a hack but i was laboring under the misapprehension that the general use of the caller loader was not. So it is clear that all the hacks should go away and in module mode the only call that really makes sense is load(Class, ClassLoader) with the appropriate ClassLoader of the module. So this: ServiceLoader.load(HttpServerProvider.class, ClassLoader.getSystemClassLoader()); Could change to: ServiceLoader.load(HttpServerProvider.class, Platform.isModuleMode() ? HttpServerProvider.class.getClassLoader() : ClassLoader.getSystemClassLoader()); The choice of null or non null for say Object.class.getClassLoader() is clearly going to affect things here for services in the base module. So this: ServiceLoader.load(FileSystemProvider.class, ClassLoader.getSystemClassLoader()); changes to: ServiceLoader.load(FileSystemProvider.class, Platform.isModuleMode() ? Plaform.getBaseModuleLoader() // is this correct? : ClassLoader.getSystemClassLoader()); rather than: ServiceLoader.load(FileSystemProvider.class, Platform.isModuleMode() ? FileSystemProvider.class.getClassLoader() : ClassLoader.getSystemClassLoader()); which would be consistent with the previous example. A helper method on Platform could hide this: ClassLoader getModuleClassLoaderOrFallback(Class c, ClassLoader fallback) { if (Plaform.isModuleMode()) { ClassLoader cl = c.getClassLoader(); return (cl == null) ? getBaseModuleLoader() : cl; } else { return fallback; } } Perhaps we need to introduce an annotation on methods ServiceLoader.load(Class ) and ServiceLoader.loadInstalled(Class ). When compiling in modular mode optional lint like warnings could be given. If such annotations are retained at runtime it should be possible to detect on execution. > Anyway, I scanned the rest of the JDK patch. One thing is that we'll need to work out spec/javadoc changes for many of these cases. > Yes. > I would suggest ignoring JMX for now as it will require a special update. > > JDI is specified to use Connector and TransportService providers using the defining loader of the Connector and TransportService types so I don't think it requires any changes. > OK. > Phil may be able to say something about the rendering engine code but I think this is just for switching between rendering engines and that they are will all be loaded by the module loader for the desktop module. > OK. > Mandy will likely have an opinion on jconsole but my take is that it's mostly replaced by VisualVM now and maybe we don't do anything and run just it with -Xmode:legacy. > > Having dump-config include the services configuration is a good idea. > I will send a specific patch to the list for this. Paul. From Alan.Bateman at oracle.com Thu May 24 05:13:41 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 24 May 2012 13:13:41 +0100 Subject: ServiceLoader in the JDK In-Reply-To: <7599192B-0DF3-4ADA-8C1F-52401DEA7E46@oracle.com> References: <3A0862E2-67F2-44A1-BD7B-3AE6DB0EF0B2@oracle.com> <4FBD2C90.1060704@oracle.com> <7599192B-0DF3-4ADA-8C1F-52401DEA7E46@oracle.com> Message-ID: <4FBE25F5.7070900@oracle.com> On 24/05/2012 12:41, Paul Sandoz wrote: > > So it is clear that all the hacks should go away and in module mode the only call that really makes sense is load(Class, ClassLoader) with the appropriate ClassLoader of the module. The other thing is that we'll need to update ServiceLoader's javadoc to specify how the methods work with modules. The loadInstalled method for example is specified to be the equivalent of load(S,) but there isn't an extension class loader when running with modes. The load(Class) method is also prickly because the TCCL may be set to null or getSystemClassLoader. > > So this: > > ServiceLoader.load(HttpServerProvider.class, ClassLoader.getSystemClassLoader()); > > Could change to: > > ServiceLoader.load(HttpServerProvider.class, Platform.isModuleMode() > ? HttpServerProvider.class.getClassLoader() > : ClassLoader.getSystemClassLoader()); This looks right to me. When running with a classpath then it searches the classpath for providers as before. When running with modules then the httpserver's module declare will "require service HttpServerProvider" and so will be linked to the http server providers that are installed. > > > The choice of null or non null for say Object.class.getClassLoader() is clearly going to affect things here for services in the base module. Yes, that is a good point to include in null vs. module class loader debate and that will decide whether a helper method is required too. > : > > > Perhaps we need to introduce an annotation on methods ServiceLoader.load(Class ) and ServiceLoader.loadInstalled(Class ). When compiling in modular mode optional lint like warnings could be given. If such annotations are retained at runtime it should be possible to detect on execution. > I'm not following you on the need for annotations but load(Class) is clearly a discussion point as the TCCL might be set to something that doesn't make sense when running with modules. -Alan From paul.sandoz at oracle.com Thu May 24 05:33:18 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 24 May 2012 14:33:18 +0200 Subject: ServiceLoader in the JDK In-Reply-To: <4FBE25F5.7070900@oracle.com> References: <3A0862E2-67F2-44A1-BD7B-3AE6DB0EF0B2@oracle.com> <4FBD2C90.1060704@oracle.com> <7599192B-0DF3-4ADA-8C1F-52401DEA7E46@oracle.com> <4FBE25F5.7070900@oracle.com> Message-ID: <8F8CE94A-9D6B-4954-A336-A56534D5146F@oracle.com> On May 24, 2012, at 2:13 PM, Alan Bateman wrote: > On 24/05/2012 12:41, Paul Sandoz wrote: >> >> So it is clear that all the hacks should go away and in module mode the only call that really makes sense is load(Class, ClassLoader) with the appropriate ClassLoader of the module. > The other thing is that we'll need to update ServiceLoader's javadoc to specify how the methods work with modules. Yes, this is related to the annotations. They provide a marker to developers that such methods are problematic and may not do as one expects in module mode. The annotations could also serve the purpose of telling javac to output warnings as it compiles code, in module mode, that references such methods (unless the warnings are suppressed). > The loadInstalled method for example is specified to be the equivalent of load(S,) but there isn't an extension class loader when running with modes. Right this method without the hack is virtually useless in module mode and with the hack is problematic. Perhaps the sane solution here is to use the class loader of the service class. > The load(Class) method is also prickly because the TCCL may be set to null or getSystemClassLoader. > Or something else... >> >> So this: >> >> ServiceLoader.load(HttpServerProvider.class, ClassLoader.getSystemClassLoader()); >> >> Could change to: >> >> ServiceLoader.load(HttpServerProvider.class, Platform.isModuleMode() >> ? HttpServerProvider.class.getClassLoader() >> : ClassLoader.getSystemClassLoader()); > This looks right to me. When running with a classpath then it searches the classpath for providers as before. When running with modules then the httpserver's module declare will "require service HttpServerProvider" and so will be linked to the http server providers that are installed. > >> >> >> The choice of null or non null for say Object.class.getClassLoader() is clearly going to affect things here for services in the base module. > Yes, that is a good point to include in null vs. module class loader debate and that will decide whether a helper method is required too. > Right. OK, i think i have enough to go on for another less naive stab at this. Thanks, Paul. > >> : >> >> >> Perhaps we need to introduce an annotation on methods ServiceLoader.load(Class ) and ServiceLoader.loadInstalled(Class ). When compiling in modular mode optional lint like warnings could be given. If such annotations are retained at runtime it should be possible to detect on execution. >> > I'm not following you on the need for annotations but load(Class) is clearly a discussion point as the TCCL might be set to something that doesn't make sense when running with modules. > > -Alan > > From jesse.glick at oracle.com Thu May 24 05:40:51 2012 From: jesse.glick at oracle.com (Jesse Glick) Date: Thu, 24 May 2012 08:40:51 -0400 Subject: ServiceLoader in the JDK In-Reply-To: <7599192B-0DF3-4ADA-8C1F-52401DEA7E46@oracle.com> References: <3A0862E2-67F2-44A1-BD7B-3AE6DB0EF0B2@oracle.com> <4FBD2C90.1060704@oracle.com> <7599192B-0DF3-4ADA-8C1F-52401DEA7E46@oracle.com> Message-ID: <4FBE2C53.2030900@oracle.com> On 05/24/2012 07:41 AM, Paul Sandoz wrote: > in module mode the only call that really makes sense is load(Class, ClassLoader) with the appropriate ClassLoader of the module. This does not make sense at all. load(Class,ClassLoader) is the one factory in ServiceLoader that has a dependable behavior and it should be left alone to behave as it did in JDK 7, whether running in module mode or not: loader.getResources(PREFIX + service.getName()). It should merely be documented that this variant is not generally what you want when running in module mode, since there is not likely to be any one ClassLoader which can load META-INF/** from every installed module, nor would this even be able to find services registered using "provides service" in module-info.class (*). In other words, this method should continue to work as before for old-style JAR services, and has nothing to do with Jigsaw services. The next question is what to do with load(Class) and loadInstalled(Class). The former picks up an implicit context in the form of the thread context class loader, which will again not be useful at all for Jigsaw services, and the latter seems unusably vague in module mode (making as it does a bogus distinction between the "virtual machine" and the "application"). Probably they both need to be deprecated. That leaves the question of what Jigsaw-aware code should in fact call. Either introduce a new method in ServiceLoader: public static ServiceLoader load(Class service, Class reference); where 'reference' is the caller (**), or generally some class defined by a module which "requires service"; or leave ServiceLoader entirely untouched and define a fresh API which is actually designed to work with Jigsaw services. You will note that the nonstatic members of ServiceLoader not in Iterable are just reload(), which should be unnecessary in module mode - if the module system supports dynamic changes, the service loader ought to be able to get notifications of them automatically. (This method only makes sense when the impl is calling ClassLoader.getResources.) So maybe add to Class: public Iterable services(Class service) { Module m = getModule(); return m != null ? m.somehowLoadProviders(service) : ServiceLoader.load(service); } which would result in the straightforward idiom: for (Interface impl : ThisCaller.class.services(Interface.class)) {...} which would work correctly in module mode and tolerably in classpath mode. (*) Since these are not accompanied by registrations under PREFIX. Even if they were, and there were a ClassLoader with visibility into all modules, getResources(String) would still not work for the case that two modules define distinct service impls using the same FQN, which can easily happen in large apps using multiple versions of third-party libs; I have a longstanding open API RFE in ClassLoader to rectify this. (**) As in earlier messages I am assuming that a Class and hence a Module instance uniquely identifies a module configuration, i.e. set of candidate providers. Someone needs to prototype multitenancy/isolates in Jigsaw to make sure this assumption is actually safe. If two applications are running at once in the VM, both of which happen to use the same version of a particular API module, you would expect that the JVM loads the bytecode for this API just once, yet it is TBD whether there is just one Module instance for this API (and one Class for each FQN in it), or whether each application gets its own private copy of the Module and Class's. If the latter, Class can safely be used as a reference key. But if the former, some other reifiable object must be used to represent "the current application", and there needs to be some way to find this object. These are the kinds of problems you get when using service locators rather than dependency injection. From henri.gomez at gmail.com Thu May 24 05:54:07 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Thu, 24 May 2012 05:54:07 -0700 Subject: Berkeley DB required ? In-Reply-To: <4FBE07AD.6030801@oracle.com> References: <4FBD1985.1040801@oracle.com> <4FBD4D44.9040604@oracle.com> <4FBE07AD.6030801@oracle.com> Message-ID: >> Of course there is just no ?/usr/local/BerkeleyDB.5.4 directory so >> what's this reference ? > > > This is a bug in the BDB makefile/linker options, for now it should be > harmless. I'll take note and resolve it in the next update to bdb. Ok, I notice java worked even without this dylib but want to be sure. > The jigsaw bundled BDB is a stripped down version of the full BDB release. > It uses the same configure and makefiles as its larger brother. The full BDB > build can produce several native libraries, for supporting SQL API, STL API, > C++ API, etc, depending on the options passed to the configure script. These > additional libraries have a dependency on the core libdb-XXX.so library. > This is achieved by adding an rpath to the default location of the libdb, > which happens to be /usr/local/BerkeleyDB.5.4 on Mac OSX. It just happens to > be set in a common linker options variable. Yep, noticed it while building stock Berkeley DB 5.4 on OSX, prefix is defaulted to /usr/local/BerkeleyDB.5.3 > Since the jigsaw bundled bdb library is standalone and independent of any of > the above mentioned additional BDB libraries is does not need this rpath > set. Cool Good, I'll upload latest jigsaw packages to http://code.google.com/p/openjdk-osx-build/. Thanks Chris From david.lloyd at redhat.com Thu May 24 07:24:16 2012 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 24 May 2012 09:24:16 -0500 Subject: ServiceLoader in the JDK In-Reply-To: <4FBE2C53.2030900@oracle.com> References: <3A0862E2-67F2-44A1-BD7B-3AE6DB0EF0B2@oracle.com> <4FBD2C90.1060704@oracle.com> <7599192B-0DF3-4ADA-8C1F-52401DEA7E46@oracle.com> <4FBE2C53.2030900@oracle.com> Message-ID: <4FBE4490.4000201@redhat.com> On 05/24/2012 07:40 AM, Jesse Glick wrote: > On 05/24/2012 07:41 AM, Paul Sandoz wrote: >> in module mode the only call that really makes sense is load(Class, >> ClassLoader) with the appropriate ClassLoader of the module. > > This does not make sense at all. load(Class,ClassLoader) is the one > factory in ServiceLoader that has a dependable behavior and it should > be left alone to behave as it did in JDK 7, whether running in module > mode or not: loader.getResources(PREFIX + service.getName()). It > should merely be documented that this variant is not generally what > you want when running in module mode, since there is not likely to be > any one ClassLoader which can load META-INF/** from every installed > module I believw this to be wrong thinking. Rarely, if ever, do you want to find every implementation of a service in the entire universe. In reality you most often want to find services relative to a specific module/class loader - most often it's the running application but sometimes it's the API module itself or something else altogether. In other words, loading relative to a specified class loader is *nearly always* what you want. This behavior works perfectly today in JDK 7 and should be left alone IMO. > nor would this even be able to find services registered using > "provides service" in module-info.class (*). In other words, this > method should continue to work as before for old-style JAR services, > and has nothing to do with Jigsaw services. > > The next question is what to do with load(Class) and > loadInstalled(Class). The former picks up an implicit context in the > form of the thread context class loader, which will again not be > useful at all for Jigsaw services, and the latter seems unusably > vague in module mode (making as it does a bogus distinction between > the "virtual machine" and the "application"). Probably they both need > to be deprecated. I agree with deprecating loadInstalled(), especially if the concept of an extension class loader is eliminated (better make a note of this for Java EE 7/8/whatever). But the TCCL is still a valid concept - perhaps more so than ever - with modules and should continue to be supported to mean "the current application". > That leaves the question of what Jigsaw-aware code should in fact > call. Either introduce a new method in ServiceLoader: > > public static ServiceLoader load(Class service, Class > reference); Here's the problem. Only in rare cases do you really want to have a concept of JVM-wide service implementations (think implementations of JDK module interfaces). No matter what fancy mechanisms you add this will continue to be the case. Primary reason #1 is that you cannot assume that there is only one class with a given name installed in the system. If you break this, you will cause much suffering. A service spec in the form of a class name is only valid or useful in the context of a module that knows how to load the class with that name AND has linked against the SAME service type as the implementation module. System-wide service implementations logically should be registered by implementation module name with the module which defines the service. > where 'reference' is the caller (**), or generally some class defined > by a module which "requires service"; or leave ServiceLoader entirely > untouched and define a fresh API which is actually designed to work > with Jigsaw services. You will note that the nonstatic members of > ServiceLoader not in Iterable are just reload(), which should be > unnecessary in module mode - if the module system supports dynamic > changes, the service loader ought to be able to get notifications of > them automatically. (This method only makes sense when the impl is > calling ClassLoader.getResources.) So maybe add to Class: > > public Iterable services(Class service) { Module m = > getModule(); return m != null ? m.somehowLoadProviders(service) : > ServiceLoader.load(service); } > > which would result in the straightforward idiom: > > for (Interface impl : ThisCaller.class.services(Interface.class)) > {...} > > which would work correctly in module mode and tolerably in classpath > mode. More automatic caller determination = yuck. > (**) As in earlier messages I am assuming that a Class and hence a > Module instance uniquely identifies a module configuration, i.e. set > of candidate providers. Someone needs to prototype > multitenancy/isolates in Jigsaw to make sure this assumption is > actually safe. If two applications are running at once in the VM, > both of which happen to use the same version of a particular API > module, you would expect that the JVM loads the bytecode for this API > just once, yet it is TBD whether there is just one Module instance > for this API (and one Class for each FQN in it), or whether each > application gets its own private copy of the Module and Class's. You definitely do not want to have modules spitting out private copies of classes. This way lies serious madness. One module should imply one class loader. -- - DML From jesse.glick at oracle.com Thu May 24 07:28:47 2012 From: jesse.glick at oracle.com (Jesse Glick) Date: Thu, 24 May 2012 10:28:47 -0400 Subject: ServiceLoader in the JDK In-Reply-To: <4FBE2C53.2030900@oracle.com> References: <3A0862E2-67F2-44A1-BD7B-3AE6DB0EF0B2@oracle.com> <4FBD2C90.1060704@oracle.com> <7599192B-0DF3-4ADA-8C1F-52401DEA7E46@oracle.com> <4FBE2C53.2030900@oracle.com> Message-ID: <4FBE459F.7050405@oracle.com> On 05/24/2012 08:40 AM, Jesse Glick wrote: > maybe add to Class: > > public Iterable services(Class service) { > Module m = getModule(); > return m != null ? m.somehowLoadProviders(service) : ServiceLoader.load(service); > } or better, add to ClassLoader: protected Iterable services(Class service, Class reference) { return ServiceLoader.load(service); // or .load(service, this)? TBD } with an override in ModuleClassLoader, and to Class: public final Iterable services(Class service) { return getClassLoader().services(service, this); } offering better flexibility for module systems generally. From david.lloyd at redhat.com Thu May 24 07:34:59 2012 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 24 May 2012 09:34:59 -0500 Subject: hg: jigsaw/jigsaw/hotspot: Summary: Allow passing in a non-null module loader to translate to boot loader. In-Reply-To: <4FBD83F7.9060606@oracle.com> References: <20120523004839.EF5BE47488@hg.openjdk.java.net> <4FBD159B.9040508@redhat.com> <4FBD83F7.9060606@oracle.com> Message-ID: <4FBE4713.3070605@redhat.com> On 05/23/2012 07:42 PM, Mandy Chung wrote: > On 5/23/2012 9:51 AM, David M. Lloyd wrote: >> >> This change seems to me the wrong way around: since using null as an >> argument to Class.forName() (and similar) still has to be supported, >> why not simply have the base module class loader delegate to its parent? > > FWIW, the base module class loader does delegate to VM null loader in > the implementation. > > In classpath mode, Class.forName() with a null class loader argument > will load classes from the bootclasspath. In module mode, when > Class.forName() with a null loader is called, do you expect it loads > classes only in the base module or all classes from all jdk modules? Well that's the big question. From a purist point of view, it would make some sense (in module mode) for the null class loader to be existent but empty (or only consisting of classes from the bootclasspath). In reality though I think that breaking the behavior that a null class loader loads JDK classes might be major trouble. That's why I was suggesting a while ago that all of base in fact be a single physical module which could be optionally distributed piecewise, and use filtered down module aliases to represent the individual pieces of it. This way all base modules are on the null/base class loader, you still are fully modularized in any practical sense, *and* you don't have to rewrite scads of JDK code. I've found that the general expectation is that java.* things are available on the null class loader; javax.* things are not really expected to be. So take that information for what it's worth. >> This, in combination with "spoofing" the base module's >> Class.getClassLoader() output, seems like it would suffice. >> >> On a related note, most standalone class loaders out in the wild will >> in fact delegate to their parent. What does this mean when classes >> that were a part of the core JDK are now in discrete (non-visible) >> modules? I think this is a major weakness of retroactively >> modularizing the core. > > In classpath mode, existing application and class loaders should work as > it is today. The platform modularization should be transparent to the > classpath mode applications/class loader. > > In module mode, a relevant question is what module do classes loaded by > the non-module > class loader belong to? What types are visible to that non-module class > loader? I don't think standalone class loader classes should belong to any module. getModule() == null. A module is a specialization of a class loader, not a replacement. > One initial proposal is to have classes loaded by a non-module class > loader belong to the module in which that class loader is created. > Therefore, all types visible to the module will also be visible to that > non-module class loader. Details are yet to be fleshed out and prototyped. If a standalone class loader delegates to, or is a child of, a module class loader, then yes this will happen naturally. In the end it will be up to the class loader as it always has full control. -- - DML From jesse.glick at oracle.com Thu May 24 08:08:45 2012 From: jesse.glick at oracle.com (Jesse Glick) Date: Thu, 24 May 2012 11:08:45 -0400 Subject: ServiceLoader in the JDK In-Reply-To: <4FBE4490.4000201@redhat.com> References: <3A0862E2-67F2-44A1-BD7B-3AE6DB0EF0B2@oracle.com> <4FBD2C90.1060704@oracle.com> <7599192B-0DF3-4ADA-8C1F-52401DEA7E46@oracle.com> <4FBE2C53.2030900@oracle.com> <4FBE4490.4000201@redhat.com> Message-ID: <4FBE4EFD.9030406@oracle.com> On 05/24/2012 10:24 AM, David M. Lloyd wrote: > Rarely, if ever, do you want to > find every implementation of a service in the entire universe. Not the entire universe, but the set of modules loaded in the current module configuration (~ application). That is what Jigsaw "requires service" requests. So if that system is wanted, there needs to be an API call implementing that. > In reality you most often want to find services relative to a specific > module/class loader - most often it's the running application That is exactly what "requires service" means - all services in the running application. Which need not map at all to any particular ClassLoader. (While it might be a particular Module, an "application entry point" module, that module's ClassLoader will _not_ generally be able to load all the app's services unless it happens to declare direct dependencies on every service provider.) > sometimes it's the API module itself Probably pointless, since that would only be able to load services defined in the same module; you might as well statically enumerate them. > or something else altogether. In custom cases you ought to be able to use the existing ServiceLoader.load(Class,ClassLoader) with the same semantics as in JDK 7, i.e. loader.getResources(PREFIX+svc). It is debatable whether this method should also load "provided services" from Jigsaw modules which are visible to the supplied ClassLoader if that is in fact a ModuleClassLoader - that would enable you to load a subset of available services according to a subgraph of the application's dependency graph, conceivably useful but rather more complex and probably an advanced usage. > the TCCL is still a valid concept - perhaps more so than ever - with modules and should continue to be supported to mean "the current application". TBD. It is used in some existing module systems (not OSGi AFAIK) since it sort of works and there is nothing clearly superseding it. It is not entirely clear what types and resources should be visible to it, and it is even less clear how it should behave when multiple modules define a class with the same FQN, which ClassLoader cannot represent. (ClassLoader _can_ represent multiple resources with the same path, but as I mentioned earlier this is not good enough for ServiceLoader since getResources returns a list of URL's with no indication of the "defining loader".) > Only in rare cases do you really want to have a concept of JVM-wide service implementations To the contrary I would say this is the normal case for applications not running in a special multitenancy container such as EE. If you do have multiple apps in the JVM then (as mentioned in my last message) it is up to the module system to somehow ensure they do not interfere with one another, such as by offering distinct Module/Class instances, or using some implicit context like ThreadGroup. Looking for a subset of those service implementations available within the "current" application is another use case but probably more specialized. > you cannot assume that there is only one class with a given name installed in the system No, you cannot, and correct implementations of service loading will not make such an assumption. JDK 7's ServiceLoader is broken in this regard in two ways: (1) absent a richer ClassLoader.getResources, it cannot tell which loader defined a service, so it cannot be sure to load the implementation class from that same loader, mishandling multiple copies of an implementation; (2) it fails to verify that a candidate implementation is actually assignable to the supplied interface, so it produces CCEs if you have multiple copies of the interface. In NetBeans we have a replacement service loader which fixes both these bugs. From david.lloyd at redhat.com Thu May 24 08:43:13 2012 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 24 May 2012 10:43:13 -0500 Subject: ServiceLoader in the JDK In-Reply-To: <4FBE4EFD.9030406@oracle.com> References: <3A0862E2-67F2-44A1-BD7B-3AE6DB0EF0B2@oracle.com> <4FBD2C90.1060704@oracle.com> <7599192B-0DF3-4ADA-8C1F-52401DEA7E46@oracle.com> <4FBE2C53.2030900@oracle.com> <4FBE4490.4000201@redhat.com> <4FBE4EFD.9030406@oracle.com> Message-ID: <4FBE5711.4080204@redhat.com> On 05/24/2012 10:08 AM, Jesse Glick wrote: > On 05/24/2012 10:24 AM, David M. Lloyd wrote: >> Rarely, if ever, do you want to >> find every implementation of a service in the entire universe. > > Not the entire universe, but the set of modules loaded in the current > module configuration (~ application). That is what Jigsaw "requires > service" requests. So if that system is wanted, there needs to be an API > call implementing that. Then you're saying that Jigsaw proposes to introduce a new way to represent the current running application other than by class loader (and, by extension, module)? >> In reality you most often want to find services relative to a specific >> module/class loader - most often it's the running application > > That is exactly what "requires service" means - all services in the > running application. Which need not map at all to any particular > ClassLoader. (While it might be a particular Module, an "application > entry point" module, that module's ClassLoader will _not_ generally be > able to load all the app's services unless it happens to declare direct > dependencies on every service provider.) Do you mean running JVM in this case? >> sometimes it's the API module itself > > Probably pointless, since that would only be able to load services > defined in the same module; you might as well statically enumerate them. This is useful in the case where implementation decisions are made at install time. If an API usually has only a single implementation which makes sense for a platform - but it might be replaceable in special circumstances - this would be a good choice. NIO or JAXP might fall into this category. >> or something else altogether. > > In custom cases you ought to be able to use the existing > ServiceLoader.load(Class,ClassLoader) with the same semantics as in JDK > 7, i.e. loader.getResources(PREFIX+svc). It is debatable whether this > method should also load "provided services" from Jigsaw modules which > are visible to the supplied ClassLoader if that is in fact a > ModuleClassLoader - that would enable you to load a subset of available > services according to a subgraph of the application's dependency graph, > conceivably useful but rather more complex and probably an advanced usage. > >> the TCCL is still a valid concept - perhaps more so than ever - with >> modules and should continue to be supported to mean "the current >> application". > > TBD. It is used in some existing module systems (not OSGi AFAIK) since > it sort of works and there is nothing clearly superseding it. It works pretty well from our experience. Logically, it makes sense to define the running application in terms of a module, be it a JAR run from the command line, a Java EE deployment, a JavaWS execution, or an explicitly named module. It also makes sense to allow a supervisor to be able to change the current application on the fly; TCCL does this just fine. > It is not > entirely clear what types and resources should be visible to it, and it > is even less clear how it should behave when multiple modules define a > class with the same FQN, which ClassLoader cannot represent. Well clearly a module cannot import more than one class with the same name any more than a class loader can. > (ClassLoader _can_ represent multiple resources with the same path, but > as I mentioned earlier this is not good enough for ServiceLoader since > getResources returns a list of URL's with no indication of the "defining > loader".) > >> Only in rare cases do you really want to have a concept of JVM-wide >> service implementations > > To the contrary I would say this is the normal case for applications not > running in a special multitenancy container such as EE. If you do have > multiple apps in the JVM then (as mentioned in my last message) it is up > to the module system to somehow ensure they do not interfere with one > another, such as by offering distinct Module/Class instances, or using > some implicit context like ThreadGroup. Looking for a subset of those > service implementations available within the "current" application is > another use case but probably more specialized. Things like JSF or Hibernate which allow per-application plugins and components represent a very substantial segment of ServiceLoader usage. I don't think it makes sense to treat this as a special advanced case. >> you cannot assume that there is only one class with a given name >> installed in the system > > No, you cannot, and correct implementations of service loading will not > make such an assumption. JDK 7's ServiceLoader is broken in this regard > in two ways: (1) absent a richer ClassLoader.getResources, it cannot > tell which loader defined a service, so it cannot be sure to load the > implementation class from that same loader, mishandling multiple copies > of an implementation; (2) it fails to verify that a candidate > implementation is actually assignable to the supplied interface, so it > produces CCEs if you have multiple copies of the interface. In NetBeans > we have a replacement service loader which fixes both these bugs. I get what you're saying - basically you're speaking to the inability to use getResources to get a list of implementation names while at the same time associating the implementation name with its defining class loader. In practice this hasn't been an issue for us - even with very involved module dependency graphs - since we typically export the service descriptor with the same or lesser scope than its implementation, thus ensuring that any module class loader which can see the descriptor can also see the implementation class. The hair being split here could probably be summarized as the mechanism by which one may load service implementations from two different modules even if the implementation has the same class name. In practice if you have a list of modules, you can iterate them and use the load-with-classloader variant of ServiceLoader and solve this problem neatly. No matter what, you're dealing with iterating all candidate modules for a given service, so you have to know what they are at some level; I don't think that an enhanced getResources is necessary for this (convenient, yes; necessary, no). -- - DML From jesse.glick at oracle.com Thu May 24 09:49:53 2012 From: jesse.glick at oracle.com (Jesse Glick) Date: Thu, 24 May 2012 12:49:53 -0400 Subject: ServiceLoader in the JDK In-Reply-To: <4FBE5711.4080204@redhat.com> References: <3A0862E2-67F2-44A1-BD7B-3AE6DB0EF0B2@oracle.com> <4FBD2C90.1060704@oracle.com> <7599192B-0DF3-4ADA-8C1F-52401DEA7E46@oracle.com> <4FBE2C53.2030900@oracle.com> <4FBE4490.4000201@redhat.com> <4FBE4EFD.9030406@oracle.com> <4FBE5711.4080204@redhat.com> Message-ID: <4FBE66B1.7040104@oracle.com> On 05/24/2012 11:43 AM, David M. Lloyd wrote: > Then you're saying that Jigsaw proposes to introduce a new way to represent the current running application other than by class loader (and, by extension, module)? Well you specify an application module to run from the Java launcher. But this means that various modules will be loaded in the module configuration: 1. The selected module. 2. Its declared dependencies. 3. Transitive dependencies of #2. 4. Perhaps other modules in the library which provide services some of #1-#3 require. Not sure if this has been implemented yet, or if it is rather up to the creator of the app module to enumerate all desired service provider modules somehow - "requires ;" would I guess work even if the provider module exported no types. You could "represent" the running application by the application module's ClassLoader, but this could be quite misleading: that loader can see types in #1 and #2, probably not #3 or (if relevant) #4. >>> sometimes it's the API module itself >> >> Probably pointless, since that would only be able to load services >> defined in the same module; you might as well statically enumerate them. > > This is useful in the case where implementation decisions are made at install time. If an API usually has only a single implementation which makes sense for a platform - > but it might be replaceable in special circumstances - this would be a good choice. NIO or JAXP might fall into this category. But then using the ClassLoader of the API module makes it impossible to replace the default implementation: 1. The replacement implementation is by definition not in the API module. 2. It cannot be in a module the API module depends on, or there would be a cycle. 3. So it would be in some other module (which depends on the API module). But then the ClassLoader of the API module cannot see it. The simplest policy is just to look for any implementations of the service defined in the app. > it makes sense to define the running application in terms of a module Yes, that is a reasonable choice. I am saying that defining the application of terms of that module's ClassLoader is however questionable. >> how [a TCCL] should behave when multiple modules define a >> class with the same FQN, which ClassLoader cannot represent. > > Well clearly a module cannot import more than one class with the same name any more than a class loader can. Of course. But a modular system can contain multiple classes of the same name, so long as namespaces are consistent. (And the module system permits this as a matter of policy - TBD whether Jigsaw will.) In such a case the value of ModuleClassLoader.loadClass(String) is well defined for any module in the app, including the "application module"'s loader, but there is no clear definition of ClassLoader.loadClass(String) for a proposed TCCL, meaning it particular that this TCCL cannot be a ModuleClassLoader. (In the NetBeans module system, there is a special TCCL for ease of use of "legacy" libraries. If you ask it to load a class which multiple enabled modules define, it throws a CNFE with a diagnostic message, rather than arbitrarily load one version and maybe cause problems like CCE down the road.) >> Looking for a subset of those >> service implementations available within the "current" application is >> another use case but probably more specialized. > > Things like JSF or Hibernate which allow per-application plugins and components Again this goes back to how the "application" is defined, and whether the java.lang.Class/java.lang.reflect.Module for e.g. Hibernate is shared for all applications in the JVM or not. There needs to be some easy way for Hibernate code to say "give me all HibernatePlugin instances in the current application". That would be the normal mode of operation for services. Passing an explicit ClassLoader to load just those HibernatePlugin implementations visible starting from that loader is what I would consider an advanced usage. > you're speaking to the inability to use getResources to get a list of implementation names while at the same time associating the > implementation name with its defining class loader. Yes, that is one problem. Fortunately it is pretty easily solved with a minor API change in ClassLoader. Of course this only applies to old-style service registration using META-INF/services/$name, whereas Jigsaw modules declaring "provides service ..." do not use this mechanism (at least currently). > if you have a list of modules, you can iterate them and use the load-with-classloader variant of ServiceLoader You mean for (Module m : somethingTBD()) { for (Plugin p : ServiceLoader.load(Plugin.class, m.getClassLoader())) {...} } ? That is one potential workaround - _if_ a ModuleClassLoader refuses to delegate META-INF/** resource loads to its "parents" (i.e. dependencies). If it does delegate getResources in that way, you will get duplicates. I am not sure if Jigsaw has yet specified the interaction of language accessibility with getResource[s]. From Alan.Bateman at oracle.com Thu May 24 10:05:18 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 24 May 2012 18:05:18 +0100 Subject: ServiceLoader in the JDK In-Reply-To: <4FBE66B1.7040104@oracle.com> References: <3A0862E2-67F2-44A1-BD7B-3AE6DB0EF0B2@oracle.com> <4FBD2C90.1060704@oracle.com> <7599192B-0DF3-4ADA-8C1F-52401DEA7E46@oracle.com> <4FBE2C53.2030900@oracle.com> <4FBE4490.4000201@redhat.com> <4FBE4EFD.9030406@oracle.com> <4FBE5711.4080204@redhat.com> <4FBE66B1.7040104@oracle.com> Message-ID: <4FBE6A4E.7030501@oracle.com> On 24/05/2012 17:49, Jesse Glick wrote: > On 05/24/2012 11:43 AM, David M. Lloyd wrote: >> Then you're saying that Jigsaw proposes to introduce a new way to >> represent the current running application other than by class loader >> (and, by extension, module)? > > Well you specify an application module to run from the Java launcher. > But this means that various modules will be loaded in the module > configuration: > > 1. The selected module. > 2. Its declared dependencies. > 3. Transitive dependencies of #2. > 4. Perhaps other modules in the library which provide services some of > #1-#3 require. Not sure if this has been implemented yet, Yes, it's there (and just to say that everything is loaded lazily, not when the configuration be loaded). -Alan From mandy.chung at oracle.com Thu May 24 11:33:30 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 24 May 2012 11:33:30 -0700 Subject: hg: jigsaw/jigsaw/hotspot: Summary: Allow passing in a non-null module loader to translate to boot loader. In-Reply-To: <4FBE4713.3070605@redhat.com> References: <20120523004839.EF5BE47488@hg.openjdk.java.net> <4FBD159B.9040508@redhat.com> <4FBD83F7.9060606@oracle.com> <4FBE4713.3070605@redhat.com> Message-ID: <4FBE7EFA.1010202@oracle.com> On 5/24/2012 7:34 AM, David M. Lloyd wrote: >> One initial proposal is to have classes loaded by a non-module class >> loader belong to the module in which that class loader is created. >> Therefore, all types visible to the module will also be visible to that >> non-module class loader. Details are yet to be fleshed out and >> prototyped. > > If a standalone class loader delegates to, or is a child of, a module > class loader, then yes this will happen naturally. In the end it will > be up to the class loader as it always has full control. Thank you all for the useful feedback and discussion. This is an area to be thought through and how it impacts migration as well. Mandy From paul.sandoz at oracle.com Thu May 24 12:53:06 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 24 May 2012 21:53:06 +0200 Subject: ServiceLoader in the JDK In-Reply-To: <4FBE2C53.2030900@oracle.com> References: <3A0862E2-67F2-44A1-BD7B-3AE6DB0EF0B2@oracle.com> <4FBD2C90.1060704@oracle.com> <7599192B-0DF3-4ADA-8C1F-52401DEA7E46@oracle.com> <4FBE2C53.2030900@oracle.com> Message-ID: <37DBEB23-44BA-4FEA-851A-897A15C3431D@oracle.com> On May 24, 2012, at 2:40 PM, Jesse Glick wrote: > On 05/24/2012 07:41 AM, Paul Sandoz wrote: >> in module mode the only call that really makes sense is load(Class, ClassLoader) with the appropriate ClassLoader of the module. > > This does not make sense at all. Oh, it's not that bad :-) I think there is a set of behavior for ServiceLoader.load* that does make reasonable sense in modular mode. > load(Class,ClassLoader) is the one factory in ServiceLoader that has a dependable behavior and it should be left alone to behave as it did in JDK 7, whether running in module mode or not: loader.getResources(PREFIX + service.getName()). It should merely be documented that this variant is not generally what you want when running in module mode, since there is not likely to be any one ClassLoader which can load META-INF/** from every installed module, nor would this even be able to find services registered using "provides service" in module-info.class (*). In other words, this method should continue to work as before for old-style JAR services, and has nothing to do with Jigsaw services. > > The next question is what to do with load(Class) and loadInstalled(Class). The former picks up an implicit context in the form of the thread context class loader, which will again not be useful at all for Jigsaw services, and the latter seems unusably vague in module mode (making as it does a bogus distinction between the "virtual machine" and the "application"). Probably they both need to be deprecated. > > That leaves the question of what Jigsaw-aware code should in fact call. Either introduce a new method in ServiceLoader: > > public static ServiceLoader load(Class service, Class reference); > > where 'reference' is the caller (**), or generally some class defined by a module which "requires service"; or leave ServiceLoader entirely untouched and define a fresh API which is actually designed to work with Jigsaw services. You will note that the nonstatic members of ServiceLoader not in Iterable are just reload(), which should be unnecessary in module mode - if the module system supports dynamic changes, the service loader ought to be able to get notifications of them automatically. (This method only makes sense when the impl is calling ClassLoader.getResources.) So maybe add to Class: > > public Iterable services(Class service) { > Module m = getModule(); > return m != null ? m.somehowLoadProviders(service) : ServiceLoader.load(service); > } > Perhaps ServiceLoader.load(service, this.getClassLoader()) instead. FWIW i nearly proposed a method ClassLoader.loadService (as you have done in another email). I think it is valuable to separate out the module service loading functionality from ServiceLoader, e.g. ModuleServiceLoader, then it makes it easier to for us to decide what we can do with it, such use it in ServiceLoader and/or use for any new Class/ClassLoader methods. > which would result in the straightforward idiom: > > for (Interface impl : ThisCaller.class.services(Interface.class)) {...} > > which would work correctly in module mode and tolerably in classpath mode. > > > (*) Since these are not accompanied by registrations under PREFIX. Even if they were, and there were a ClassLoader with visibility into all modules, getResources(String) would still not work for the case that two modules define distinct service impls using the same FQN, which can easily happen in large apps using multiple versions of third-party libs; I have a longstanding open API RFE in ClassLoader to rectify this. > > (**) As in earlier messages I am assuming that a Class and hence a Module instance uniquely identifies a module configuration, i.e. set of candidate providers. Someone needs to prototype multitenancy/isolates in Jigsaw to make sure this assumption is actually safe. If two applications are running at once in the VM, both of which happen to use the same version of a particular API module, you would expect that the JVM loads the bytecode for this API just once, yet it is TBD whether there is just one Module instance for this API (and one Class for each FQN in it), or whether each application gets its own private copy of the Module and Class's. If the latter, Class can safely be used as a reference key. But if the former, some other reifiable object must be used to represent "the current application", and there needs to be some way to find this object. These are the kinds of problems you get when using service locators rather than dependency injection. This container stuff is still all to be determined, but i would expect each container to have it's own configuration (as of Jigsaw today it is not possible to obtain the configuration, or a safe representation of, from a class loader, but it is trivial modification to enable that). The "permits" complicates matters slightly, if that was not relevant we could look up the services from the configuration. Paul. From paul.sandoz at oracle.com Fri May 25 01:35:24 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 25 May 2012 10:35:24 +0200 Subject: Pull parser for jmod packages Message-ID: <051794ED-524A-4B25-B08D-9BCE1E5E4032@oracle.com> Hi At the moment the reader of jmod packages, org.openjdk.jigsaw.ModuleFile.Reader, is tightly bound to reading a module file and extracting out the contents into a directory (and tightly bound to the implementation details of the library contents). How about we develop a module file pull parser? Such a parser can then be used by "jmod install/extract" [1] and by other tools, for example IDEs to more easily extract out the class file contents for analysis. Paul. [1] Arguably "jmod extract" should be "jpkg extract" From paul.sandoz at oracle.com Fri May 25 01:45:37 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 25 May 2012 10:45:37 +0200 Subject: Dump services webrev Message-ID: <87D7286B-9C7D-4A44-B325-65D693F9516D@oracle.com> Hi, See the following for a webrev to dump the services configuration: http://cr.openjdk.java.net/~psandoz/jigsaw/dump-services/webrev/ There is also some other minor stuff sneaking into this web rev related to services in general. Paul. From Alan.Bateman at oracle.com Fri May 25 03:35:38 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 25 May 2012 11:35:38 +0100 Subject: Dump services webrev In-Reply-To: <87D7286B-9C7D-4A44-B325-65D693F9516D@oracle.com> References: <87D7286B-9C7D-4A44-B325-65D693F9516D@oracle.com> Message-ID: <4FBF607A.5080809@oracle.com> On 25/05/2012 09:45, Paul Sandoz wrote: > Hi, > > See the following for a webrev to dump the services configuration: > > http://cr.openjdk.java.net/~psandoz/jigsaw/dump-services/webrev/ > > There is also some other minor stuff sneaking into this web rev related to services in general. > > Paul. The update to the dump-config to print the services configurations looks fine to me, and very useful. I don't know if you wanted comments on the "minor stuff" that sneaked in but here goes ... The change to jdk.depconfig is the beginnings of allowing jconsole have plugins installed as modules but there is more to do, as per the comments you've added to JConsole. My take on this is that -pluginpath isn't really compatible with modules and as jconsole is close to retirement (my words, but it is essentially replaced by VisualVM) then maybe the right thing is to just have jconsole run in -Xmode:legacy mode. Mandy? The change to HttpServerProvider.java is fine but it reminds me that it we have many places in the JDK where you can set a property to select the provider, and if not set then it fallbacks to looking for a service provider. It's come up on discussions here before too. Clearly setting the property to some implementation type that is not visible isn't going to work. However as the service providers will be installed as modules then the property mechanism could potentially be used to choose the provider. So in this case if com.sun.net.httpserver.HttpServerProvider is set to the name of a provider then we could use ServiceLoader to iterate through the providers to fine one with this name. We should check with Phil Race about the sun.java2d.renderer property but I suspect these rendering engines will all be in the desktop module anyway. This is what is in jdk.desktop's module-info now: requires optional service sun.java2d.pipe.RenderingEngine; provides service sun.java2d.pipe.RenderingEngine with sun.java2d.jules.JulesRenderingEngine; provides service sun.java2d.pipe.RenderingEngine with sun.java2d.pisces.PiscesRenderingEngine; Like the HttpServerProvider example it may be that the property is just used to select the service implementation. -Alan. From chris.hegarty at oracle.com Fri May 25 03:37:14 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 25 May 2012 11:37:14 +0100 Subject: Pull parser for jmod packages In-Reply-To: <051794ED-524A-4B25-B08D-9BCE1E5E4032@oracle.com> References: <051794ED-524A-4B25-B08D-9BCE1E5E4032@oracle.com> Message-ID: <4FBF60DA.6000505@oracle.com> On 25/05/2012 09:35, Paul Sandoz wrote: > Hi > > At the moment the reader of jmod packages, org.openjdk.jigsaw.ModuleFile.Reader, is tightly bound to reading a module file and extracting out the contents into a directory (and tightly bound to the implementation details of the library contents). > > How about we develop a module file pull parser? I really like this idea. I was always a little uncomfortable with the tight relationship between the reading of the module file and the writing out of its data. For example, jsign and the changes to support listing the module file contents does some funnies to avoid writing out the actual contents. A pull parser type API may work well here. I'll take a stab at what this would look like ( unless you want to? ). > Such a parser can then be used by "jmod install/extract" [1] and by other tools, for example IDEs to more easily extract out the class file contents for analysis. > > Paul. > > [1] Arguably "jmod extract" should be "jpkg extract" Yes, I agree. If jpkg evolves into a tool for creating and inspecting module files/native packages, then I think 'extract' is better suited in jpkg. -Chris. From paul.sandoz at oracle.com Fri May 25 04:27:31 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 25 May 2012 13:27:31 +0200 Subject: Dump services webrev In-Reply-To: <4FBF607A.5080809@oracle.com> References: <87D7286B-9C7D-4A44-B325-65D693F9516D@oracle.com> <4FBF607A.5080809@oracle.com> Message-ID: <977703C8-1C85-4DBB-9136-E152F99CF462@oracle.com> On May 25, 2012, at 12:35 PM, Alan Bateman wrote: > On 25/05/2012 09:45, Paul Sandoz wrote: >> >> Hi, >> >> See the following for a webrev to dump the services configuration: >> >> http://cr.openjdk.java.net/~psandoz/jigsaw/dump-services/webrev/ >> >> There is also some other minor stuff sneaking into this web rev related to services in general. >> >> Paul. > The update to the dump-config to print the services configurations looks fine to me, and very useful. > Thanks. > I don't know if you wanted comments on the "minor stuff" that sneaked in but here goes ... > Of course! > The change to jdk.depconfig is the beginnings of allowing jconsole have plugins installed as modules but there is more to do, as per the comments you've added to JConsole. My take on this is that -pluginpath isn't really compatible with modules and as jconsole is close to retirement (my words, but it is essentially replaced by VisualVM) then maybe the right thing is to just have jconsole run in -Xmode:legacy mode. Mandy? > Yes, i put it in there as a reminder and because that is about as far as i could take it without further input. Remove the declaration? > The change to HttpServerProvider.java is fine but it reminds me that it we have many places in the JDK where you can set a property to select the provider, and if not set then it fallbacks to looking for a service provider. And them if service providers are present the first one is selected, otherwise if no service providers are present the default (non-reigstered) provider is used. > It's come up on discussions here before too. Clearly setting the property to some implementation type that is not visible isn't going to work. However as the service providers will be installed as modules then the property mechanism could potentially be used to choose the provider. So in this case if com.sun.net.httpserver.HttpServerProvider is set to the name of a provider then we could use ServiceLoader to iterate through the providers to fine one with this name. > I can see why that might be useful, but i find the use of system properties rather hacky, in this context it's seems like out of band information of an application. If there was a way that an entry point could also make a preference on services providers that could formalize things a little better. Also, as we have discussed there are a class of services that are factories. Sometimes it is OK to have more than one present with selection of one loosely defined, other times it only makes sense to have at most one and a configuration error could result (e.g. multiple vendor implementations). If we could change "requires service" to, for example "@Factory requires service" or 'requires factory", then it opens up the possibility to output warnings and errors. > We should check with Phil Race about the sun.java2d.renderer property but I suspect these rendering engines will all be in the desktop module anyway. This is what is in jdk.desktop's module-info now: > > requires optional service sun.java2d.pipe.RenderingEngine; > provides service sun.java2d.pipe.RenderingEngine with sun.java2d.jules.JulesRenderingEngine; > provides service sun.java2d.pipe.RenderingEngine with sun.java2d.pisces.PiscesRenderingEngine; > > Like the HttpServerProvider example it may be that the property is just used to select the service implementation. > I will follow up with Phil. Paul. From Alan.Bateman at oracle.com Fri May 25 05:26:15 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 25 May 2012 13:26:15 +0100 Subject: Dump services webrev In-Reply-To: <977703C8-1C85-4DBB-9136-E152F99CF462@oracle.com> References: <87D7286B-9C7D-4A44-B325-65D693F9516D@oracle.com> <4FBF607A.5080809@oracle.com> <977703C8-1C85-4DBB-9136-E152F99CF462@oracle.com> Message-ID: <4FBF7A67.5070907@oracle.com> On 25/05/2012 12:27, Paul Sandoz wrote: > : > >> It's come up on discussions here before too. Clearly setting the property to some implementation type that is not visible isn't going to work. However as the service providers will be installed as modules then the property mechanism could potentially be used to choose the provider. So in this case if com.sun.net.httpserver.HttpServerProvider is set to the name of a provider then we could use ServiceLoader to iterate through the providers to fine one with this name. >> > I can see why that might be useful, but i find the use of system properties rather hacky, in this context it's seems like out of band information of an application. > > If there was a way that an entry point could also make a preference on services providers that could formalize things a little better. We've tentatively talked here about having some means to configure the order, or minimally which service provider is returned first. It comes up with aliases too. So I would say this is an open question. Many of these APIs specify a system property to select the implementation so we will minimally need this to continue to work when running with a class path (as you have done). When running with modules then there may still be an need to override things, even if we have configured the preferred provider for the application. Several examples come to mind but one is performance testing where you need to specify the provider on a per-run basis. > > Also, as we have discussed there are a class of services that are factories. Sometimes it is OK to have more than one present with selection of one loosely defined, other times it only makes sense to have at most one and a configuration error could result (e.g. multiple vendor implementations). > > If we could change "requires service" to, for example "@Factory requires service" or 'requires factory", then it opens up the possibility to output warnings and errors. At this time then the configuration can ensure that at least one provider is installed but there isn't any way to require only one or at most one. On another thread here (maybe more than one thread) there was also the suggestion that the "provides service" should allow a static factory method to be specified and that method method would return a reference to the provider. It remains to be seen how much is done with services, ServiceLoader, etc. as it's whole project in itself. -Alan From forax at univ-mlv.fr Fri May 25 05:29:12 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Fri, 25 May 2012 14:29:12 +0200 Subject: Pull parser for jmod packages In-Reply-To: <4FBF60DA.6000505@oracle.com> References: <051794ED-524A-4B25-B08D-9BCE1E5E4032@oracle.com> <4FBF60DA.6000505@oracle.com> Message-ID: <4FBF7B18.8070403@univ-mlv.fr> On 05/25/2012 12:37 PM, Chris Hegarty wrote: > On 25/05/2012 09:35, Paul Sandoz wrote: >> Hi >> >> At the moment the reader of jmod packages, >> org.openjdk.jigsaw.ModuleFile.Reader, is tightly bound to reading a >> module file and extracting out the contents into a directory (and >> tightly bound to the implementation details of the library contents). >> >> How about we develop a module file pull parser? > > I really like this idea. I was always a little uncomfortable with the > tight relationship between the reading of the module file and the > writing out of its data. For example, jsign and the changes to support > listing the module file contents does some funnies to avoid writing > out the actual contents. A pull parser type API may work well here. > I'll take a stab at what this would look like ( unless you want to? ). > >> Such a parser can then be used by "jmod install/extract" [1] and by >> other tools, for example IDEs to more easily extract out the class >> file contents for analysis. >> >> Paul. >> >> [1] Arguably "jmod extract" should be "jpkg extract" > > Yes, I agree. If jpkg evolves into a tool for creating and inspecting > module files/native packages, then I think 'extract' is better suited > in jpkg. > > -Chris. yes, great idea ! R?mi From paul.sandoz at oracle.com Fri May 25 05:33:57 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 25 May 2012 14:33:57 +0200 Subject: Pull parser for jmod packages In-Reply-To: <4FBF60DA.6000505@oracle.com> References: <051794ED-524A-4B25-B08D-9BCE1E5E4032@oracle.com> <4FBF60DA.6000505@oracle.com> Message-ID: On May 25, 2012, at 12:37 PM, Chris Hegarty wrote: > On 25/05/2012 09:35, Paul Sandoz wrote: >> Hi >> >> At the moment the reader of jmod packages, org.openjdk.jigsaw.ModuleFile.Reader, is tightly bound to reading a module file and extracting out the contents into a directory (and tightly bound to the implementation details of the library contents). >> >> How about we develop a module file pull parser? > > I really like this idea. I was always a little uncomfortable with the tight relationship between the reading of the module file and the writing out of its data. For example, jsign and the changes to support listing the module file contents does some funnies to avoid writing out the actual contents. A pull parser type API may work well here. I'll take a stab at what this would look like ( unless you want to? ). > This area is your baby, and i guess you will most likely change it for the BDB work so unless you are overloaded, go for it! I also took a quick look at the writing side of this. It may be advantageous to keep that in mind for the signing case you mention. At the moment ModuleFileWriter also seems to be bound to a certain file-based layout for input. But, i think it should be possible to round trip by hooking up the pull parser/reader to the writer, then signing becomes an man-in-the-middle of that process, and ideally the Signer should only have to deal with encoding details of the signing section. I can imagine a module file writer that either keeps references to content (plus the transformation/encoding step), or content in memory, or as temp files on disk until one is ready to commit to the generation of a module file merging it all together as one file and generating the hashes. I notice that a signed module file may break the streaming approach if the signed section is at the end of the module file. Should the signature section be mandated to always occur after the header and module info? I don't know enough about the hashing and signing to know if it is a problem to have a flag in the module header section indicating the signature section is present after the module info section. Do you mind if modify jrepo to support modular jar files? Paul. >> Such a parser can then be used by "jmod install/extract" [1] and by other tools, for example IDEs to more easily extract out the class file contents for analysis. >> >> Paul. >> >> [1] Arguably "jmod extract" should be "jpkg extract" > > Yes, I agree. If jpkg evolves into a tool for creating and inspecting module files/native packages, then I think 'extract' is better suited in jpkg. > > -Chris. From chris.hegarty at oracle.com Fri May 25 06:10:22 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 25 May 2012 14:10:22 +0100 Subject: Pull parser for jmod packages In-Reply-To: References: <051794ED-524A-4B25-B08D-9BCE1E5E4032@oracle.com> <4FBF60DA.6000505@oracle.com> Message-ID: <4FBF84BE.9000401@oracle.com> On 25/05/2012 13:33, Paul Sandoz wrote: > On May 25, 2012, at 12:37 PM, Chris Hegarty wrote: >> On 25/05/2012 09:35, Paul Sandoz wrote: >>> Hi >>> >>> At the moment the reader of jmod packages, org.openjdk.jigsaw.ModuleFile.Reader, is tightly bound to reading a module file and extracting out the contents into a directory (and tightly bound to the implementation details of the library contents). >>> >>> How about we develop a module file pull parser? >> >> I really like this idea. I was always a little uncomfortable with the tight relationship between the reading of the module file and the writing out of its data. For example, jsign and the changes to support listing the module file contents does some funnies to avoid writing out the actual contents. A pull parser type API may work well here. I'll take a stab at what this would look like ( unless you want to? ). >> > > This area is your baby, and i guess you will most likely change it for the BDB work so unless you are overloaded, go for it! > > I also took a quick look at the writing side of this. It may be advantageous to keep that in mind for the signing case you mention. At the moment ModuleFileWriter also seems to be bound to a certain file-based layout for input. But, i think it should be possible to round trip by hooking up the pull parser/reader to the writer, then signing becomes an man-in-the-middle of that process, and ideally the Signer should only have to deal with encoding details of the signing section. > > I can imagine a module file writer that either keeps references to content (plus the transformation/encoding step), or content in memory, or as temp files on disk until one is ready to commit to the generation of a module file merging it all together as one file and generating the hashes. > > I notice that a signed module file may break the streaming approach if the signed section is at the end of the module file. Should the signature section be mandated to always occur after the header and module info? I don't know enough about the hashing and signing to know if it is a problem to have a flag in the module header section indicating the signature section is present after the module info section. Sean added the signing support a good while back. The signature section (if supplied) comes right after the module-info. I believe to support streaming, and also easy verification of section hashes as you read them. http://cr.openjdk.java.net/~mullan/jigsaw/signed-module-file-format I really want to capture this and update the original module-file-format [1], and eventually get it all onto the project page. > Do you mind if modify jrepo to support modular jar files? Absolutely not, this is a great idea ( sorry I did mean to reply to your original mail about this ). I can add it to my list, or if you like please feel free? -Chris. [1] http://cr.openjdk.java.net/~mr/jigsaw/notes/module-file-format/ > > Paul. > > >>> Such a parser can then be used by "jmod install/extract" [1] and by other tools, for example IDEs to more easily extract out the class file contents for analysis. >>> >>> Paul. >>> >>> [1] Arguably "jmod extract" should be "jpkg extract" >> >> Yes, I agree. If jpkg evolves into a tool for creating and inspecting module files/native packages, then I think 'extract' is better suited in jpkg. >> >> -Chris. > From paul.sandoz at oracle.com Fri May 25 06:22:00 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 25 May 2012 15:22:00 +0200 Subject: Pull parser for jmod packages In-Reply-To: <4FBF84BE.9000401@oracle.com> References: <051794ED-524A-4B25-B08D-9BCE1E5E4032@oracle.com> <4FBF60DA.6000505@oracle.com> <4FBF84BE.9000401@oracle.com> Message-ID: On May 25, 2012, at 3:10 PM, Chris Hegarty wrote: >> >> I notice that a signed module file may break the streaming approach if the signed section is at the end of the module file. Should the signature section be mandated to always occur after the header and module info? I don't know enough about the hashing and signing to know if it is a problem to have a flag in the module header section indicating the signature section is present after the module info section. > > Sean added the signing support a good while back. The signature section (if supplied) comes right after the module-info. Yes, you are right, my mistake. >> Do you mind if modify jrepo to support modular jar files? > > Absolutely not, this is a great idea ( sorry I did mean to reply to your original mail about this ). I can add it to my list, or if you like please feel free? > I take this one. Paul. From paul.sandoz at oracle.com Fri May 25 06:32:04 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 25 May 2012 15:32:04 +0200 Subject: Dump services webrev In-Reply-To: <4FBF7A67.5070907@oracle.com> References: <87D7286B-9C7D-4A44-B325-65D693F9516D@oracle.com> <4FBF607A.5080809@oracle.com> <977703C8-1C85-4DBB-9136-E152F99CF462@oracle.com> <4FBF7A67.5070907@oracle.com> Message-ID: <8B871A23-DE95-4D7B-AE2D-ED47F7A1E205@oracle.com> On May 25, 2012, at 2:26 PM, Alan Bateman wrote: > On 25/05/2012 12:27, Paul Sandoz wrote: >> : >> >>> It's come up on discussions here before too. Clearly setting the property to some implementation type that is not visible isn't going to work. However as the service providers will be installed as modules then the property mechanism could potentially be used to choose the provider. So in this case if com.sun.net.httpserver.HttpServerProvider is set to the name of a provider then we could use ServiceLoader to iterate through the providers to fine one with this name. >>> >> I can see why that might be useful, but i find the use of system properties rather hacky, in this context it's seems like out of band information of an application. >> >> If there was a way that an entry point could also make a preference on services providers that could formalize things a little better. > We've tentatively talked here about having some means to configure the order, or minimally which service provider is returned first. It comes up with aliases too. So I would say this is an open question. > > Many of these APIs specify a system property to select the implementation so we will minimally need this to continue to work when running with a class path (as you have done). When running with modules then there may still be an need to override things, even if we have configured the preferred provider for the application. Several examples come to mind but one is performance testing where you need to specify the provider on a per-run basis. > Good point. >> >> Also, as we have discussed there are a class of services that are factories. Sometimes it is OK to have more than one present with selection of one loosely defined, other times it only makes sense to have at most one and a configuration error could result (e.g. multiple vendor implementations). >> >> If we could change "requires service" to, for example "@Factory requires service" or 'requires factory", then it opens up the possibility to output warnings and errors. > At this time then the configuration can ensure that at least one provider is installed but there isn't any way to require only one or at most one. > I am guessing annotations in module-info.java files are not supported (yet perhaps...) making it trickier to prototype. > On another thread here (maybe more than one thread) there was also the suggestion that the "provides service" should allow a static factory method to be specified and that method method would return a reference to the provider. BTW in Jersey we forked ServiceLoader and i modified it to "keep on trucking" if a service could not be instantiated. > It remains to be seen how much is done with services, ServiceLoader, etc. as it's whole project in itself. > Indeed, and there was me thinking "this looks like a manageable chunk of stuff to get started on". Still, given all our discussions on this i can see some useful ways we can make some forward progression. Paul. From sean.mullan at oracle.com Fri May 25 06:47:18 2012 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 25 May 2012 09:47:18 -0400 Subject: Pull parser for jmod packages In-Reply-To: <4FBF84BE.9000401@oracle.com> References: <051794ED-524A-4B25-B08D-9BCE1E5E4032@oracle.com> <4FBF60DA.6000505@oracle.com> <4FBF84BE.9000401@oracle.com> Message-ID: <4FBF8D66.9010807@oracle.com> On 5/25/12 9:10 AM, Chris Hegarty wrote: >> I also took a quick look at the writing side of this. It may be >> advantageous to keep that in mind for the signing case you mention. At the >> moment ModuleFileWriter also seems to be bound to a certain file-based >> layout for input. But, i think it should be possible to round trip by >> hooking up the pull parser/reader to the writer, then signing becomes an >> man-in-the-middle of that process, and ideally the Signer should only have >> to deal with encoding details of the signing section. Keep in mind that the current signed module file format is optimized for streaming as you read, but not as you write. The entire file has to be written out and the hashes calculated/read in order to calculate the signature, thus the Signer basically does a two-pass write in order to do that, once to a temporary file, and the second time to the signed jmod. >> I can imagine a module file writer that either keeps references to content >> (plus the transformation/encoding step), or content in memory, or as temp >> files on disk until one is ready to commit to the generation of a module >> file merging it all together as one file and generating the hashes. >> >> I notice that a signed module file may break the streaming approach if the >> signed section is at the end of the module file. Should the signature >> section be mandated to always occur after the header and module info? I >> don't know enough about the hashing and signing to know if it is a problem >> to have a flag in the module header section indicating the signature >> section is present after the module info section. > > Sean added the signing support a good while back. The signature section (if > supplied) comes right after the module-info. I believe to support streaming, > and also easy verification of section hashes as you read them. > > http://cr.openjdk.java.net/~mullan/jigsaw/signed-module-file-format > > I really want to capture this and update the original module-file-format [1], > and eventually get it all onto the project page. That would be great. There were also a few modifications I recommended we make to the module-file format in order to better support signing: http://mail.openjdk.java.net/pipermail/jigsaw-dev/2011-June/001392.html (Some of these are already implemented). --Sean > >> Do you mind if modify jrepo to support modular jar files? > > Absolutely not, this is a great idea ( sorry I did mean to reply to your > original mail about this ). I can add it to my list, or if you like please > feel free? > > -Chris. > > [1] http://cr.openjdk.java.net/~mr/jigsaw/notes/module-file-format/ > >> >> Paul. >> >> >>>> Such a parser can then be used by "jmod install/extract" [1] and by >>>> other tools, for example IDEs to more easily extract out the class file >>>> contents for analysis. >>>> >>>> Paul. >>>> >>>> [1] Arguably "jmod extract" should be "jpkg extract" >>> >>> Yes, I agree. If jpkg evolves into a tool for creating and inspecting >>> module files/native packages, then I think 'extract' is better suited in >>> jpkg. >>> >>> -Chris. >> From mandy.chung at oracle.com Fri May 25 07:04:41 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 25 May 2012 07:04:41 -0700 Subject: Dump services webrev In-Reply-To: <4FBF607A.5080809@oracle.com> References: <87D7286B-9C7D-4A44-B325-65D693F9516D@oracle.com> <4FBF607A.5080809@oracle.com> Message-ID: <4FBF9179.4070407@oracle.com> On 5/25/2012 3:35 AM, Alan Bateman wrote: > The change to jdk.depconfig is the beginnings of allowing jconsole > have plugins installed as modules but there is more to do, as per the > comments you've added to JConsole. My take on this is that -pluginpath > isn't really compatible with modules and as jconsole is close to > retirement (my words, but it is essentially replaced by VisualVM) then > maybe the right thing is to just have jconsole run in -Xmode:legacy > mode. Mandy? I agree with Alan not to support jconsole -pluginpath with modules since VisualVM essentially is a replacement for it. I'm not sure if jconsole should run in classpath mode though. I doubt if there are many jconsole plugins out there. Can we launch jconsole in classpath mode only if -pluginpath is set? Mandy From Alan.Bateman at oracle.com Fri May 25 07:15:48 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 25 May 2012 15:15:48 +0100 Subject: Dump services webrev In-Reply-To: <4FBF9179.4070407@oracle.com> References: <87D7286B-9C7D-4A44-B325-65D693F9516D@oracle.com> <4FBF607A.5080809@oracle.com> <4FBF9179.4070407@oracle.com> Message-ID: <4FBF9414.3040701@oracle.com> On 25/05/2012 15:04, Mandy Chung wrote: > > I agree with Alan not to support jconsole -pluginpath with modules > since VisualVM essentially is a replacement for it. I'm not sure if > jconsole should run in classpath mode though. I doubt if there are > many jconsole plugins out there. Can we launch jconsole in classpath > mode only if -pluginpath is set? Not without special handling in the launcher, or else having jconsole re-exec itself. I think the simplest thing is to just fail with something like this: "-pluginpath not supported in module path, to use jconsole plugins then re-run with -Xmode:legacy" or something along that lines. -Alan. From mandy.chung at oracle.com Fri May 25 07:59:09 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 25 May 2012 07:59:09 -0700 Subject: Dump services webrev In-Reply-To: <4FBF9414.3040701@oracle.com> References: <87D7286B-9C7D-4A44-B325-65D693F9516D@oracle.com> <4FBF607A.5080809@oracle.com> <4FBF9179.4070407@oracle.com> <4FBF9414.3040701@oracle.com> Message-ID: <4FBF9E3D.8050107@oracle.com> On 5/25/2012 7:15 AM, Alan Bateman wrote: > On 25/05/2012 15:04, Mandy Chung wrote: >> >> I agree with Alan not to support jconsole -pluginpath with modules >> since VisualVM essentially is a replacement for it. I'm not sure if >> jconsole should run in classpath mode though. I doubt if there are >> many jconsole plugins out there. Can we launch jconsole in classpath >> mode only if -pluginpath is set? > Not without special handling in the launcher, or else having jconsole > re-exec itself. I think the simplest thing is to just fail with > something like this: > > "-pluginpath not supported in module path, to use jconsole plugins > then re-run with -Xmode:legacy" > > or something along that lines. > That's one option I thought of as long as -Xmode:legacy (or similar option) is remained (I think possibly). Mandy From paul.sandoz at oracle.com Fri May 25 07:59:59 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 25 May 2012 16:59:59 +0200 Subject: Pull parser for jmod packages In-Reply-To: <4FBF8D66.9010807@oracle.com> References: <051794ED-524A-4B25-B08D-9BCE1E5E4032@oracle.com> <4FBF60DA.6000505@oracle.com> <4FBF84BE.9000401@oracle.com> <4FBF8D66.9010807@oracle.com> Message-ID: On May 25, 2012, at 3:47 PM, Sean Mullan wrote: > On 5/25/12 9:10 AM, Chris Hegarty wrote: >>> I also took a quick look at the writing side of this. It may be >>> advantageous to keep that in mind for the signing case you mention. At the >>> moment ModuleFileWriter also seems to be bound to a certain file-based >>> layout for input. But, i think it should be possible to round trip by >>> hooking up the pull parser/reader to the writer, then signing becomes an >>> man-in-the-middle of that process, and ideally the Signer should only have >>> to deal with encoding details of the signing section. > > Keep in mind that the current signed module file format is optimized for > streaming as you read, but not as you write. Yes, entirely reasonable since there will be many more readers than writers. > The entire file has to be written > out and the hashes calculated/read in order to calculate the signature, thus the > Signer basically does a two-pass write in order to do that, once to a temporary > file, and the second time to the signed jmod. > My guess is that If section encoders, that are delayed computations, are added to a writer and are enacted on committing it should be possible to work in an apparent streaming manner (with IIUC the special knowledge that the signature section is not included in the global hash calculation when writing and reading). Paul. From jesse.glick at oracle.com Fri May 25 09:02:32 2012 From: jesse.glick at oracle.com (Jesse Glick) Date: Fri, 25 May 2012 12:02:32 -0400 Subject: Dump services webrev In-Reply-To: <4FBF607A.5080809@oracle.com> References: <87D7286B-9C7D-4A44-B325-65D693F9516D@oracle.com> <4FBF607A.5080809@oracle.com> Message-ID: <4FBFAD18.1040001@oracle.com> On 05/25/2012 06:35 AM, Alan Bateman wrote: > if com.sun.net.httpserver.HttpServerProvider is set to the name of a provider then we could use ServiceLoader to iterate through the providers Another possibility would be for ServiceLoader to check for a system property with the same (binary) name as the service; if set, and corresponding to the (binary) name of one of the providers, load that one and that one only. Would offer an easy compatibility path for some legacy code. But maybe this should be left to the caller to handle. > requires optional service sun.java2d.pipe.RenderingEngine; > provides service sun.java2d.pipe.RenderingEngine with sun.java2d.jules.JulesRenderingEngine; > provides service sun.java2d.pipe.RenderingEngine with sun.java2d.pisces.PiscesRenderingEngine; If a module provides the service it requires (in fact provides two variants), surely the "optional" keyword is unnecessary? later: > there was also the suggestion that the "provides service" should allow a static factory method to be specified This is very handy, and a good idea if you are dropping the legacy META-INF/services/* format anyway. This avoids the need to create new subclasses for minor variants of a service. You could also allow static final fields - typically the service provider is a singleton with no instance state so there is no real overhead associated with a field. This could be especially convenient in conjunction with lambdas: provides service java.nio.file.spi.FileTypeDetector with my.Utils.DETECTOR; ... package my; public class Utils { public static final FileTypeDetector DETECTOR = (f) -> f.endsWith(".myext") ? "text/mine" : null; } Paul Sandoz wrote: > in Jersey we forked ServiceLoader and i modified it to "keep on trucking" if a service could not be instantiated Same in NetBeans; logs a warning and continues with no impact on the caller. Catching ServiceConfigurationError in each caller would be be a pain, and since it is unchecked it would be easily forgotten, and if forgotten it is unlikely to be noticed during development and come up only in production systems. In Jigsaw the module system should catch most potential problems (e.g. misspelled service name) statically, but the service constructor/factory could still throw an exception I suppose. From mandy.chung at oracle.com Fri May 25 10:09:01 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 25 May 2012 10:09:01 -0700 Subject: Dump services webrev In-Reply-To: <87D7286B-9C7D-4A44-B325-65D693F9516D@oracle.com> References: <87D7286B-9C7D-4A44-B325-65D693F9516D@oracle.com> Message-ID: <4FBFBCAD.7050703@oracle.com> iOn 5/25/2012 1:45 AM, Paul Sandoz wrote: > Hi, > > See the following for a webrev to dump the services configuration: > > http://cr.openjdk.java.net/~psandoz/jigsaw/dump-services/webrev/ Configuration.java - looks good. this is useful to list the service providers in dump-config. L148: formatting nit: the argument to be aligned with the argument in L147 and '{' begins in next line. jdk.depconfig, JConsole.java: as we suggest, best would be to keep the -pluginpath as an option to run in classpath mode and output an error when -pluginpath is used. For now, the error message should suggest to run jconsole with -Xmode:classpath option (we should rename the current -Xmode:legacy launcher flag). Charset.java - this change seems to be a leftover from the previous webrev - do you mean to revert it? RenderingEngine.java - I suspect the system property was for testing and Phil will confirm. FYI. W.r.t. using a system property to override an implementation class, this property mechanism is also used place that does not call ServiceLoader (probably was added predated the service loader mechanism). A while back, I annotated the jdk source to record the non-static dependencies (the webrev was based on jdk7-b72 and need update): http://cr.openjdk.java.net/~mchung/jigsaw/annotated_jdk_webrev/ It included the system property if it supports this property mechanism (some examples): @ClassForName(value={""}, property="com.sun.net.httpserver.HttpServerProvider") @ClassForName(value={"sun.net.www.protocol.*.Handler"}, property="java.protocol.handler.pkgs") @ClassForName(value={"sun.net.www.content.*"}, property="java.content.handler.pkgs") @ClassForName(value={""}, property="java.nio.channels.spi.AsynchronousChannelProvider") @ClassForName(value={"sun.nio.ch.DefaultSelectorProvider"}, property="java.nio.channels.spi.SelectorProvider") @ClassForName(value={""}, property="java.rmi.server.RMIClassLoaderSpi") @ClassForName(value={"sun.security.provider.IdentityDatabase"}, property="system.scope", required=false) @ClassForName(value={"sun.security.provider.PolicyFile"}, property="policy.provider") @ClassForName(value={"java.security.*Spi"}, property="", required=false) @ClassForName(value={""}, property="jdbc.drivers") @ClassForName(value={}, property="java.util.jar.Pack200.*") @ClassForName(value={""}, property="ssl.ServerSocketFactory.provider") @ClassForName(value={""}, property="ssl.SocketFactory.provider") Some are supported and some are private jdk implementation. Anyway, we will have to go through them case by case. Mandy From mandy.chung at oracle.com Fri May 25 10:28:48 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 25 May 2012 10:28:48 -0700 Subject: Pull parser for jmod packages In-Reply-To: References: <051794ED-524A-4B25-B08D-9BCE1E5E4032@oracle.com> <4FBF60DA.6000505@oracle.com> <4FBF84BE.9000401@oracle.com> Message-ID: <4FBFC150.30900@oracle.com> On 5/25/2012 6:22 AM, Paul Sandoz wrote: >>> >> Do you mind if modify jrepo to support modular jar files >> > I take this one. Thanks, that'd be great. The changeset for the modular JAR support is [1] in case you want to reference it. Only jmod and jar tools were updated in that changeset and left jrepo and jpkg forsupport modular JAR later (jpkg CLI was due to be revisited and so better wait before extending it). Mandy [1] http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/bb6f08a993fa From Alan.Bateman at oracle.com Fri May 25 10:43:21 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 25 May 2012 18:43:21 +0100 Subject: Dump services webrev In-Reply-To: <4FBFAD18.1040001@oracle.com> References: <87D7286B-9C7D-4A44-B325-65D693F9516D@oracle.com> <4FBF607A.5080809@oracle.com> <4FBFAD18.1040001@oracle.com> Message-ID: <4FBFC4B9.7010408@oracle.com> On 25/05/2012 17:02, Jesse Glick wrote: > On 05/25/2012 06:35 AM, Alan Bateman wrote: >> if com.sun.net.httpserver.HttpServerProvider is set to the name of a >> provider then we could use ServiceLoader to iterate through the >> providers > > Another possibility would be for ServiceLoader to check for a system > property with the same (binary) name as the service; if set, and > corresponding to the (binary) name of one of the providers, load that > one and that one only. Would offer an easy compatibility path for some > legacy code. But maybe this should be left to the caller to handle. I would leave this to the caller as it will be usage specific as to whether it wants to specify/support an override mechanism. Also there may be cases where the system property is different. As it happens the RenderingEngine is one such case as the property is sun.java2d.renderer rather than sun.java2d.pipe.RenderingEngine. > >> requires optional service sun.java2d.pipe.RenderingEngine; >> provides service sun.java2d.pipe.RenderingEngine with >> sun.java2d.jules.JulesRenderingEngine; >> provides service sun.java2d.pipe.RenderingEngine with >> sun.java2d.pisces.PiscesRenderingEngine; > > If a module provides the service it requires (in fact provides two > variants), surely the "optional" keyword is unnecessary? I think this you are right, or at least you will be right if the property override is changed. > > Same in NetBeans; logs a warning and continues with no impact on the > caller. Catching ServiceConfigurationError in each caller would be be > a pain, and since it is unchecked it would be easily forgotten, and if > forgotten it is unlikely to be noticed during development and come up > only in production systems. In Jigsaw the module system should catch > most potential problems (e.g. misspelled service name) statically, but > the service constructor/factory could still throw an exception I suppose. For Java SE then many APIs specify if/how fail if the instantiation of the provider fails. Exactly how they fail is a bit inconsistent. As examples JAXP defines various *ConfigurationExceptions, NIO is more low level and will throw an unspecified error, and there are others. So I think the right thing it to leave it up to the caller to specify how it behaves in this case, meaning I don't think ServiceLoader should use logging or emit warnings. -Alan. From Alan.Bateman at oracle.com Fri May 25 12:15:49 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 25 May 2012 20:15:49 +0100 Subject: Result: New jigsaw Committer: Chris Hegarty Message-ID: <4FBFDA65.3060900@oracle.com> Voting for Chris Hegarty [1] is now closed. Yes: 6 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. -Alan. [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2012-May/002565.html From paul.sandoz at oracle.com Fri May 25 14:38:29 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 25 May 2012 23:38:29 +0200 Subject: Dump services webrev In-Reply-To: <4FBFC4B9.7010408@oracle.com> References: <87D7286B-9C7D-4A44-B325-65D693F9516D@oracle.com> <4FBF607A.5080809@oracle.com> <4FBFAD18.1040001@oracle.com> <4FBFC4B9.7010408@oracle.com> Message-ID: On May 25, 2012, at 7:43 PM, Alan Bateman wrote: >> >> Same in NetBeans; logs a warning and continues with no impact on the caller. Catching ServiceConfigurationError in each caller would be be a pain, and since it is unchecked it would be easily forgotten, and if forgotten it is unlikely to be noticed during development and come up only in production systems. In Jigsaw the module system should catch most potential problems (e.g. misspelled service name) statically, but the service constructor/factory could still throw an exception I suppose. > For Java SE then many APIs specify if/how fail if the instantiation of the provider fails. Exactly how they fail is a bit inconsistent. As examples JAXP defines various *ConfigurationExceptions, NIO is more low level and will throw an unspecified error, and there are others. So I think the right thing it to leave it up to the caller to specify how it behaves in this case, meaning I don't think ServiceLoader should use logging or emit warnings. > There is a distinction between a service *factory* and a set of services all of which are relevant [*]. For the latter case a rogue service can mess up access to the subset of those that come after it (and that subset is arbitrary and could change for each execution of the VM). I think we need some ability for the developer to control what should be done under such circumstances (e.g. some callback that decides to continue or re-throw). This is a good use-case for ModuleServiceProvider. Paul. [*] This was very common in Jersey hence the support to ignore. One reason why this was required is because developers would often forget to include, on the classpath, the additional dependencies for their component. So hooray for modules! (as long as there are no "requires optional" stuff causing runtime issues). From paul.sandoz at oracle.com Tue May 29 01:53:39 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 29 May 2012 10:53:39 +0200 Subject: Dump services webrev In-Reply-To: <4FBFBCAD.7050703@oracle.com> References: <87D7286B-9C7D-4A44-B325-65D693F9516D@oracle.com> <4FBFBCAD.7050703@oracle.com> Message-ID: <875DA971-AE99-4FC1-9E7A-A1B1FB2A7324@oracle.com> On May 25, 2012, at 7:09 PM, Mandy Chung wrote: > iOn 5/25/2012 1:45 AM, Paul Sandoz wrote: >> Hi, >> >> See the following for a webrev to dump the services configuration: >> >> http://cr.openjdk.java.net/~psandoz/jigsaw/dump-services/webrev/ > > Configuration.java - looks good. this is useful to list the service providers in dump-config. L148: formatting nit: the argument to be aligned with the argument in L147 and '{' begins in next line. > I presume the best practice is to stick to the same style in the source itself. Is there a recommended style guide available? any tools to help apply such a guide (e.g. in NetBeans)? See end of email for a diff of this code (correct formatting requires viewing in a fixed space font). Let's leave the rest of the code changes out of this revision. > jdk.depconfig, JConsole.java: as we suggest, best would be to keep the -pluginpath as an option to run in classpath mode and output an error when -pluginpath is used. For now, the error message should suggest to run jconsole with -Xmode:classpath option (we should rename the current -Xmode:legacy launcher flag). > OK. > Charset.java - this change seems to be a leftover from the previous webrev - do you mean to revert it? > No, i just removed an unused field. > RenderingEngine.java - I suspect the system property was for testing and Phil will confirm. > > FYI. W.r.t. using a system property to override an implementation class, this property mechanism is also used place that does not call ServiceLoader (probably was added predated the service loader mechanism). A while back, I annotated the jdk source to record the non-static dependencies (the webrev was based on jdk7-b72 and need update): > http://cr.openjdk.java.net/~mchung/jigsaw/annotated_jdk_webrev/ > Did you use some tool to help identify and make code changes? > It included the system property if it supports this property mechanism (some examples): > @ClassForName(value={""}, property="com.sun.net.httpserver.HttpServerProvider") > @ClassForName(value={"sun.net.www.protocol.*.Handler"}, property="java.protocol.handler.pkgs") > @ClassForName(value={"sun.net.www.content.*"}, property="java.content.handler.pkgs") > @ClassForName(value={""}, property="java.nio.channels.spi.AsynchronousChannelProvider") > @ClassForName(value={"sun.nio.ch.DefaultSelectorProvider"}, property="java.nio.channels.spi.SelectorProvider") > @ClassForName(value={""}, property="java.rmi.server.RMIClassLoaderSpi") > @ClassForName(value={"sun.security.provider.IdentityDatabase"}, property="system.scope", required=false) > @ClassForName(value={"sun.security.provider.PolicyFile"}, property="policy.provider") > @ClassForName(value={"java.security.*Spi"}, property="", required=false) > @ClassForName(value={""}, property="jdbc.drivers") > @ClassForName(value={}, property="java.util.jar.Pack200.*") > @ClassForName(value={""}, property="ssl.ServerSocketFactory.provider") > @ClassForName(value={""}, property="ssl.SocketFactory.provider") > > Some are supported and some are private jdk implementation. Anyway, we will have to go through them case by case. > Yes, tricky work. Paul. > Mandy jdk $ hg diff src/share/classes/org/openjdk/jigsaw/Configuration.java diff -r 1690f9dd8ebd src/share/classes/org/openjdk/jigsaw/Configuration.java --- a/src/share/classes/org/openjdk/jigsaw/Configuration.java Fri May 18 12:55:26 2012 -0700 +++ b/src/share/classes/org/openjdk/jigsaw/Configuration.java Tue May 29 10:42:15 2012 +0200 @@ -144,7 +144,27 @@ this.contextForName = new HashMap(); } + private void dumpServices(String title, Map> services, + PrintStream out) + { + if (!services.isEmpty()) { + out.format(" %s (%d)%n", title, services.size()); + + for (Map.Entry> service : services.entrySet()) { + Set names = service.getValue(); + out.format(" %s (%d)%n", service.getKey(), names.size()); + for (String name : names) { + out.format(" %s%n", name); + } + } + } + } + private void dump(Context cx, boolean all, PrintStream out) { + dumpServices("local service providers", cx.services(), out); + + dumpServices("remote service suppliers", cx.serviceSuppliers(), out); + if (!cx.localClasses().isEmpty()) { Set classes = new TreeSet<>(cx.localClasses()); out.format(" local (%d)", classes.size()); From paul.sandoz at oracle.com Tue May 29 02:05:57 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 29 May 2012 11:05:57 +0200 Subject: Service provider factory Re: Dump services webrev In-Reply-To: <4FBFAD18.1040001@oracle.com> References: <87D7286B-9C7D-4A44-B325-65D693F9516D@oracle.com> <4FBF607A.5080809@oracle.com> <4FBFAD18.1040001@oracle.com> Message-ID: <0BC25097-48D4-49C8-97A7-E2806CF7214A@oracle.com> On May 25, 2012, at 6:02 PM, Jesse Glick wrote: >> there was also the suggestion that the "provides service" should allow a static factory method to be specified > > This is very handy, and a good idea if you are dropping the legacy META-INF/services/* format anyway. This avoids the need to create new subclasses for minor variants of a service. > > You could also allow static final fields - typically the service provider is a singleton with no instance state so there is no real overhead associated with a field. This could be especially convenient in conjunction with lambdas: > > provides service java.nio.file.spi.FileTypeDetector with my.Utils.DETECTOR; > ... > package my; > public class Utils { > public static final FileTypeDetector DETECTOR = (f) -> f.endsWith(".myext") ? "text/mine" : null; > } If we cannot reference fields because there is no language syntax to do so we might be able to reuse the lambda method reference syntax: provides service java.nio.file.spi.FileTypeDetector with my.Utils::detector; ... package my; public class Utils { private static final FileTypeDetector DETECTOR = (f) -> f.endsWith(".myext") ? "text/mine" : null; public static final FileTypeDetector detector() = { return DETECTOR; } } Paul. From alan.bateman at oracle.com Tue May 29 04:17:41 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 29 May 2012 11:17:41 +0000 Subject: hg: jigsaw/jigsaw: 12 new changesets Message-ID: <20120529111741.D600B47589@hg.openjdk.java.net> Changeset: afeeed8e5f8c Author: ihse Date: 2012-04-30 12:13 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/rev/afeeed8e5f8c 7165277: Fix missing execute permission issue running logger.sh Reviewed-by: ohair ! common/autoconf/configure ! common/autoconf/configure.ac Changeset: b2972095a4b1 Author: katleman Date: 2012-05-02 15:46 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/rev/b2972095a4b1 Merge Changeset: 2eeb9fac7dfc Author: katleman Date: 2012-05-09 13:07 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/rev/2eeb9fac7dfc Added tag jdk8-b37 for changeset b2972095a4b1 ! .hgtags Changeset: 2f06b15e2439 Author: ewendeli Date: 2012-05-03 14:17 +0200 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/rev/2f06b15e2439 7154130: Add Mac OS X Instructions to README-builds.html Reviewed-by: ohair Contributed-by: edvard.wendelin at oracle.com ! README-builds.html Changeset: d939bd0ab13c Author: katleman Date: 2012-05-09 16:12 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/rev/d939bd0ab13c Merge Changeset: b67bdaca36c2 Author: katleman Date: 2012-05-10 10:24 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/rev/b67bdaca36c2 Added tag jdk8-b38 for changeset d939bd0ab13c ! .hgtags Changeset: 955a3e8ed4f0 Author: ohair Date: 2012-05-10 08:26 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/rev/955a3e8ed4f0 7167593: Changed get_source.sh to allow for getting full oracle jdk repo forest Reviewed-by: erikj, asaha, chegar, sla, dholmes, mbykov, coleenp ! get_source.sh ! make/scripts/hgforest.sh Changeset: 8a4e92c10a9a Author: ohair Date: 2012-05-11 17:52 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/rev/8a4e92c10a9a 7167976: Fix broken get_source.sh script Reviewed-by: tbell ! make/scripts/hgforest.sh Changeset: 8927dd68aee3 Author: katleman Date: 2012-05-16 22:06 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/rev/8927dd68aee3 Merge Changeset: a2b2d435f1d2 Author: katleman Date: 2012-05-17 06:20 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/rev/a2b2d435f1d2 Added tag jdk8-b39 for changeset 8927dd68aee3 ! .hgtags Changeset: 1a8c7c530f8a Author: katleman Date: 2012-05-24 16:15 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/rev/1a8c7c530f8a Added tag jdk8-b40 for changeset a2b2d435f1d2 ! .hgtags Changeset: a7d848e81cda Author: alanb Date: 2012-05-28 19:42 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/rev/a7d848e81cda Merge ! .hgtags ! make/scripts/hgforest.sh From alan.bateman at oracle.com Tue May 29 04:17:51 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 29 May 2012 11:17:51 +0000 Subject: hg: jigsaw/jigsaw/corba: 6 new changesets Message-ID: <20120529111755.4308C4758A@hg.openjdk.java.net> Changeset: 2d2f6b0f855b Author: katleman Date: 2012-05-09 13:07 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/corba/rev/2d2f6b0f855b Added tag jdk8-b37 for changeset 83fac66442cf ! .hgtags Changeset: b8cbfb31139f Author: katleman Date: 2012-05-09 13:11 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/corba/rev/b8cbfb31139f Merge Changeset: 785af00e2827 Author: katleman Date: 2012-05-10 10:24 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/corba/rev/785af00e2827 Added tag jdk8-b38 for changeset b8cbfb31139f ! .hgtags Changeset: 56d030e5035f Author: katleman Date: 2012-05-17 06:20 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/corba/rev/56d030e5035f Added tag jdk8-b39 for changeset 785af00e2827 ! .hgtags Changeset: 113f0d5f0a08 Author: katleman Date: 2012-05-24 16:15 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/corba/rev/113f0d5f0a08 Added tag jdk8-b40 for changeset 56d030e5035f ! .hgtags Changeset: 579f13b80121 Author: alanb Date: 2012-05-28 16:39 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/corba/rev/579f13b80121 Merge ! .hgtags From alan.bateman at oracle.com Tue May 29 04:21:56 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 29 May 2012 11:21:56 +0000 Subject: hg: jigsaw/jigsaw/hotspot: 54 new changesets Message-ID: <20120529112345.D6EE24758B@hg.openjdk.java.net> Changeset: 4ee58fcab520 Author: katleman Date: 2012-05-09 13:07 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/4ee58fcab520 Added tag jdk8-b37 for changeset bfcf92bfefb8 ! .hgtags Changeset: 3c91f2c9fd21 Author: amurillo Date: 2012-04-20 17:13 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/3c91f2c9fd21 7163193: new hotspot build - hs24-b09 Reviewed-by: jcoomes ! make/hotspot_version Changeset: f3a4ee95783b Author: kevinw Date: 2012-04-20 14:55 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/f3a4ee95783b 7162488: VM not printing unknown -XX options Reviewed-by: dholmes, kamg ! src/share/vm/runtime/arguments.cpp + test/runtime/7162488/Test7162488.sh Changeset: 29ee40a082d3 Author: sla Date: 2012-04-23 13:30 +0200 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/29ee40a082d3 7162063: libsaproc debug print should format size_t correctly on 64bit platform Reviewed-by: rbackman, mgronlun, dholmes ! agent/src/os/linux/ps_core.c Changeset: f33c4d0f4c9e Author: dcubed Date: 2012-04-23 11:03 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/f33c4d0f4c9e Merge Changeset: d652a62d6e03 Author: dcubed Date: 2012-03-23 11:50 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/d652a62d6e03 7102323: RFE: enable Full Debug Symbols Phase 1 on Solaris Summary: Add support for ENABLE_FULL_DEBUG_SYMBOLS and ZIP_DEBUGINFO_FILES build flags. Add support for .diz files. Reviewed-by: dholmes, ohair, sspitsyn ! make/Makefile ! make/linux/Makefile ! make/linux/makefiles/buildtree.make ! make/linux/makefiles/defs.make ! make/linux/makefiles/gcc.make ! make/linux/makefiles/jsig.make ! make/linux/makefiles/saproc.make ! make/linux/makefiles/vm.make ! make/solaris/Makefile ! make/solaris/makefiles/buildtree.make ! make/solaris/makefiles/defs.make ! make/solaris/makefiles/dtrace.make ! make/solaris/makefiles/jsig.make ! make/solaris/makefiles/saproc.make ! make/solaris/makefiles/sparcWorks.make ! make/solaris/makefiles/vm.make ! make/windows/build.make ! make/windows/makefiles/compile.make ! make/windows/makefiles/debug.make ! make/windows/makefiles/defs.make ! make/windows/makefiles/fastdebug.make ! make/windows/makefiles/product.make ! make/windows/makefiles/sa.make Changeset: 744728c16316 Author: dcubed Date: 2012-04-03 09:48 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/744728c16316 7158067: FDS: ENABLE_FULL_DEBUG_SYMBOLS flag should only affect product builds Summary: Build option FULL_DEBUG_SYMBOLS=0 only affects product builds. Reviewed-by: ohair, jmelvin, sspitsyn ! make/Makefile ! make/linux/Makefile ! make/linux/makefiles/defs.make ! make/solaris/Makefile ! make/solaris/makefiles/defs.make ! make/windows/makefiles/defs.make Changeset: 74c359c4a9e5 Author: dcubed Date: 2012-04-24 15:20 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/74c359c4a9e5 Merge ! make/Makefile ! make/linux/Makefile ! make/linux/makefiles/buildtree.make ! make/linux/makefiles/defs.make ! make/linux/makefiles/gcc.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/buildtree.make ! make/solaris/makefiles/defs.make ! make/solaris/makefiles/sparcWorks.make ! make/solaris/makefiles/vm.make ! make/windows/build.make ! make/windows/makefiles/compile.make ! make/windows/makefiles/debug.make ! make/windows/makefiles/defs.make ! make/windows/makefiles/fastdebug.make ! make/windows/makefiles/product.make Changeset: d6c393b0164b Author: dcubed Date: 2012-04-25 15:06 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/d6c393b0164b 7164344: enabling ZIP_DEBUGINFO_FILES causes unexpected test failures on Solaris and Windows Summary: Disable FDS by default on Solaris; disable ZIP_DEBUGINFO_FILES by default on Windows. Reviewed-by: acorn, sspitsyn ! make/solaris/makefiles/defs.make ! make/windows/makefiles/defs.make Changeset: 973046802b6f Author: dlong Date: 2012-04-26 16:24 -0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/973046802b6f 7162955: Attach api on Solaris, too many open files Summary: Release server-side socket after client receives it. Reviewed-by: sla, dsamersoff, dcubed, acorn Contributed-by: dean.long at oracle.com ! src/os/solaris/vm/attachListener_solaris.cpp Changeset: 6f0612ea55ce Author: jprovino Date: 2012-05-02 15:47 -0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/6f0612ea55ce Merge Changeset: 9f059abe8cf2 Author: jmasa Date: 2012-03-29 19:46 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/9f059abe8cf2 7131629: Generalize the CMS free list code Summary: Make the FreeChunk, FreeList, TreeList, and BinaryTreeDictionary classes usable outside CMS. Reviewed-by: brutisso, johnc, jwilhelm Contributed-by: coleen.phillimore at oracle.com - src/share/vm/gc_implementation/concurrentMarkSweep/binaryTreeDictionary.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/binaryTreeDictionary.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsPermGen.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsPermGen.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp - src/share/vm/gc_implementation/concurrentMarkSweep/freeBlockDictionary.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/freeBlockDictionary.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/freeChunk.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/freeList.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/freeList.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp + src/share/vm/memory/binaryTreeDictionary.cpp + src/share/vm/memory/binaryTreeDictionary.hpp + src/share/vm/memory/freeBlockDictionary.cpp + src/share/vm/memory/freeBlockDictionary.hpp + src/share/vm/memory/freeList.cpp + src/share/vm/memory/freeList.hpp ! src/share/vm/memory/generationSpec.cpp ! src/share/vm/precompiled/precompiled.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 8a2e5a6a19a4 Author: johnc Date: 2012-04-25 10:23 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/8a2e5a6a19a4 7143490: G1: Remove HeapRegion::_top_at_conc_mark_count Summary: Removed the HeapRegion::_top_at_conc_mark_count field. It is no longer needed as a result of the changes for 6888336 and 7127706. Refactored the closures that finalize and verify the liveness counting data so that common functionality was placed into a base class. Reviewed-by: brutisso, tonyp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegion.inline.hpp Changeset: f69a5d43dc19 Author: jmasa Date: 2012-04-25 09:55 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/f69a5d43dc19 7164144: Fix variable naming style in freeBlockDictionary.* and binaryTreeDictionary* Summary: Fix naming style to be consistent with the predominant hotspot style. Reviewed-by: ysr, brutisso ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/freeChunk.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/promotionInfo.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/promotionInfo.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp ! src/share/vm/gc_implementation/shared/allocationStats.hpp ! src/share/vm/memory/binaryTreeDictionary.cpp ! src/share/vm/memory/binaryTreeDictionary.hpp ! src/share/vm/memory/freeBlockDictionary.cpp ! src/share/vm/memory/freeBlockDictionary.hpp ! src/share/vm/memory/freeList.cpp ! src/share/vm/memory/freeList.hpp Changeset: ee89f2110312 Author: jmasa Date: 2012-04-25 15:51 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/ee89f2110312 Merge Changeset: 48fac5d60c3c Author: brutisso Date: 2012-04-25 12:36 +0200 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/48fac5d60c3c 7163848: G1: Log GC Cause for a GC Reviewed-by: johnc, jwilhelm, jmasa ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp Changeset: bb18e8eecb7e Author: jcoomes Date: 2012-05-04 10:46 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/bb18e8eecb7e 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 Changeset: 7d5ec8bf38d1 Author: amurillo Date: 2012-05-04 14:10 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/7d5ec8bf38d1 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 Changeset: 4e6554041847 Author: amurillo Date: 2012-05-04 14:10 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/4e6554041847 Added tag hs24-b09 for changeset 7d5ec8bf38d1 ! .hgtags Changeset: 637c3f5f068f Author: amurillo Date: 2012-05-09 14:06 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/637c3f5f068f Merge ! .hgtags Changeset: 3c394919ca69 Author: katleman Date: 2012-05-10 10:25 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/3c394919ca69 Added tag jdk8-b38 for changeset 637c3f5f068f ! .hgtags Changeset: 36538fd1225e Author: amurillo Date: 2012-05-04 15:26 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/36538fd1225e 7166615: new hotspot build - hs24-b10 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 8bafad97cd26 Author: jiangli Date: 2012-05-02 13:21 -0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/8bafad97cd26 7158552: The instanceKlsss::_host_klass is only needed for anonymous class for JSR 292 support. Summary: Change the _host_klass to be conditionally created embedded instanceKlass field. Reviewed-by: jrose, coleenp, dholmes ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/memory/oopFactory.cpp ! src/share/vm/memory/oopFactory.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/oops/instanceKlassKlass.hpp Changeset: 38b4116b6766 Author: jprovino Date: 2012-05-05 10:24 -0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/38b4116b6766 Merge Changeset: c7ed11779ce8 Author: jiangli Date: 2012-04-10 09:31 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/c7ed11779ce8 7159772: instanceKlass::all_fields_count() returns incorrect total field count Summary: Fix instanceKlass::all_fields_count() bug. Reviewed-by: kvn, never Contributed-by: Jiangli Zhou ! src/share/vm/oops/instanceKlass.hpp Changeset: 3576af4cb939 Author: iveresov Date: 2012-04-11 19:15 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/3576af4cb939 7160539: JDeveloper crashes on 64-bit Windows Summary: x64 C1 needs to zero upper 32bits when doing l2i conversion Reviewed-by: never, kvn ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp Changeset: 847da049d62f Author: never Date: 2012-04-17 11:04 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/847da049d62f 7162094: LateInlineCallGenerator::do_late_inline crashed on uninitialized _call_node Reviewed-by: never, twisti Contributed-by: nils.eliasson at oracle.com ! src/share/vm/opto/callGenerator.cpp Changeset: df3d4a91f7f6 Author: never Date: 2012-04-18 16:08 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/df3d4a91f7f6 7161796: PhaseStringOpts::fetch_static_field tries to fetch field from the Klass instead of the mirror Reviewed-by: twisti ! src/share/vm/opto/stringopts.cpp Changeset: ec15e8f6e4f1 Author: twisti Date: 2012-04-24 12:15 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/ec15e8f6e4f1 7157695: Add windows implementation of socket interface Reviewed-by: kvn, dholmes, twisti Contributed-by: Nils Eliasson ! src/os/windows/vm/jvm_windows.h ! src/os/windows/vm/os_windows.cpp Changeset: dc682d9431f3 Author: kvn Date: 2012-05-07 12:37 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/dc682d9431f3 7160610: Unknown Native Code compilation issue Summary: When constructing input vector use type of vector's operation which use it since element's sizes should match. Reviewed-by: never, twisti ! src/share/vm/opto/superword.cpp + test/compiler/7160610/Test7160610.java Changeset: 3a97daec1b34 Author: kvn Date: 2012-05-08 15:47 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/3a97daec1b34 7167266: missing copyright notes in 3rd party code Summary: add missing copyright notes to the regression test file. Reviewed-by: twisti, johnc ! test/compiler/7070134/Stemmer.java Changeset: 2766551175a0 Author: kvn Date: 2012-05-09 10:54 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/2766551175a0 Merge ! src/share/vm/oops/instanceKlass.hpp Changeset: a05a695ea044 Author: stefank Date: 2012-05-10 11:27 +0200 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/a05a695ea044 7167437: Can't build on linux without precompiled headers Reviewed-by: brutisso, mgerdin ! src/share/vm/memory/space.hpp ! src/share/vm/memory/space.inline.hpp Changeset: f47478089efc Author: brutisso Date: 2012-05-10 14:16 +0200 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/f47478089efc 7167069: 6 VM flags crash the VM when queried via jinfo Summary: Added missing double format to Flag::print_as_flag() Reviewed-by: dholmes, stefank, coleenp ! src/share/vm/runtime/globals.cpp + test/runtime/7167069/PrintAsFlag.java Changeset: 5799726c54d7 Author: jcoomes Date: 2012-05-11 06:37 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/5799726c54d7 Merge Changeset: 73147e6c4881 Author: amurillo Date: 2012-05-11 14:47 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/73147e6c4881 Merge Changeset: 96a403721094 Author: amurillo Date: 2012-05-11 14:47 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/96a403721094 Added tag hs24-b10 for changeset 73147e6c4881 ! .hgtags Changeset: 26423ef693ac Author: katleman Date: 2012-05-17 06:20 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/26423ef693ac Added tag jdk8-b39 for changeset 96a403721094 ! .hgtags Changeset: 56d1af561395 Author: amurillo Date: 2012-05-11 14:54 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/56d1af561395 7168247: new hotspot build - hs24-b11 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 35e504cb49a6 Author: collins Date: 2012-05-11 11:30 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/35e504cb49a6 7167625: Adjustments for SE-Embedded build process Summary: Simple change to the SE-Embedded build rules that should not affect any other OpenJDK users. Reviewed-by: kvn, dholmes ! make/linux/makefiles/vm.make ! src/share/vm/runtime/arguments.cpp Changeset: fada85d11d92 Author: jprovino Date: 2012-05-16 13:33 -0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/fada85d11d92 Merge Changeset: 8f972594effc Author: kvn Date: 2012-05-14 09:36 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/8f972594effc 6924259: Remove String.count/String.offset Summary: Allow a version of String class that doesn't have count and offset fields. Reviewed-by: never, coleenp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/memory/dump.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/stringopts.cpp ! src/share/vm/opto/stringopts.hpp Changeset: de0cc3dd9f10 Author: kvn Date: 2012-05-17 09:50 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/de0cc3dd9f10 Merge Changeset: 3a22b77e755a Author: brutisso Date: 2012-05-14 17:32 +0200 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/3a22b77e755a 7161545: G1: Minor cleanups to the G1 logging Summary: Rename "to-space-overflow" to "to-space-exhausted", Introduce one decimal point in the size format, Add Sum to the aggregate and re-order the entries, Add number of GC workers to the log output Reviewed-by: johnc, jwilhelm ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 78a1b285cda8 Author: mikael Date: 2012-05-15 00:56 +0200 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/78a1b285cda8 7158457: division by zero in adaptiveweightedaverage Summary: Add ceiling to AdaptiveWeightedAverage Reviewed-by: ysr, iveresov ! src/share/vm/gc_implementation/shared/gcUtil.cpp ! src/share/vm/gc_implementation/shared/gcUtil.hpp Changeset: 33e366609904 Author: johnc Date: 2012-05-14 21:07 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/33e366609904 Merge Changeset: 1096fc5a52eb Author: johnc Date: 2012-05-15 09:49 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/1096fc5a52eb 7168294: G1: Some Full GCs incorrectly report GC cause as "No GC" Summary: GC cause was not being set by the VM_G1CollectForAllocation VM operation. Reviewed-by: jmasa, ysr, brutisso ! src/share/vm/gc_implementation/g1/vm_operations_g1.cpp Changeset: cdfa5139bd58 Author: brutisso Date: 2012-05-15 22:26 +0200 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/cdfa5139bd58 7169056: Add gigabyte unit to proper_unit_for_byte_size() and byte_size_in_proper_unit() Reviewed-by: jwilhelm, johnc, dholmes ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 9d679effd28c Author: brutisso Date: 2012-05-15 10:25 +0200 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/9d679effd28c 7166894: Add gc cause to GC logging for all collectors Reviewed-by: mgerdin, johnc ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_interface/gcCause.hpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.hpp Changeset: cdeda3fd141e Author: jcoomes Date: 2012-05-18 10:27 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/cdeda3fd141e Merge ! src/share/vm/runtime/arguments.cpp Changeset: 14b0e07ab9a6 Author: amurillo Date: 2012-05-18 14:50 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/14b0e07ab9a6 Merge Changeset: ff9decc8235d Author: amurillo Date: 2012-05-18 14:50 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/ff9decc8235d Added tag hs24-b11 for changeset 14b0e07ab9a6 ! .hgtags Changeset: 48064e53e997 Author: katleman Date: 2012-05-24 16:15 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/48064e53e997 Added tag jdk8-b40 for changeset ff9decc8235d ! .hgtags Changeset: 065f79fc56b2 Author: alanb Date: 2012-05-28 19:43 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/065f79fc56b2 Merge ! .hgtags ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/vmSymbols.hpp - 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/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp From alan.bateman at oracle.com Tue May 29 04:26:14 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 29 May 2012 11:26:14 +0000 Subject: hg: jigsaw/jigsaw/jaxp: 7 new changesets Message-ID: <20120529112633.0CED44758C@hg.openjdk.java.net> Changeset: aabc08ea546f Author: ohair Date: 2012-04-30 16:03 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxp/rev/aabc08ea546f 7165312: Fix jaxp source movement for new build-infra Reviewed-by: ohrstrom ! makefiles/Makefile Changeset: 90204bfab4e2 Author: katleman Date: 2012-05-02 15:47 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxp/rev/90204bfab4e2 Merge Changeset: 5bbe0cb6f2f2 Author: katleman Date: 2012-05-09 13:07 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxp/rev/5bbe0cb6f2f2 Added tag jdk8-b37 for changeset 90204bfab4e2 ! .hgtags Changeset: f95fdbe525c8 Author: katleman Date: 2012-05-10 10:25 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxp/rev/f95fdbe525c8 Added tag jdk8-b38 for changeset 5bbe0cb6f2f2 ! .hgtags Changeset: 9ecfdbd6aed4 Author: katleman Date: 2012-05-17 06:20 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxp/rev/9ecfdbd6aed4 Added tag jdk8-b39 for changeset f95fdbe525c8 ! .hgtags Changeset: 6f5c0e17415d Author: katleman Date: 2012-05-24 16:15 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxp/rev/6f5c0e17415d Added tag jdk8-b40 for changeset 9ecfdbd6aed4 ! .hgtags Changeset: 2102e572f316 Author: alanb Date: 2012-05-28 16:38 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxp/rev/2102e572f316 Merge ! .hgtags From alan.bateman at oracle.com Tue May 29 04:26:40 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 29 May 2012 11:26:40 +0000 Subject: hg: jigsaw/jigsaw/jaxws: 5 new changesets Message-ID: <20120529112652.8CAD14758D@hg.openjdk.java.net> Changeset: ac1ba3b56775 Author: katleman Date: 2012-05-09 13:07 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxws/rev/ac1ba3b56775 Added tag jdk8-b37 for changeset b05a948db1b6 ! .hgtags Changeset: 7f6b44fd3034 Author: katleman Date: 2012-05-10 10:25 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxws/rev/7f6b44fd3034 Added tag jdk8-b38 for changeset ac1ba3b56775 ! .hgtags Changeset: 09a0ddda03cb Author: katleman Date: 2012-05-17 06:20 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxws/rev/09a0ddda03cb Added tag jdk8-b39 for changeset 7f6b44fd3034 ! .hgtags Changeset: f2072b164b05 Author: katleman Date: 2012-05-24 16:15 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxws/rev/f2072b164b05 Added tag jdk8-b40 for changeset 09a0ddda03cb ! .hgtags Changeset: 523c0a0c3409 Author: alanb Date: 2012-05-28 16:38 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxws/rev/523c0a0c3409 Merge ! .hgtags From alan.bateman at oracle.com Tue May 29 04:27:06 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 29 May 2012 11:27:06 +0000 Subject: hg: jigsaw/jigsaw/jdk: 101 new changesets Message-ID: <20120529114458.ADDD34758E@hg.openjdk.java.net> Changeset: 8e3fb7dd21cd Author: skovatch Date: 2012-04-25 12:18 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/8e3fb7dd21cd 7128699: Fix bundle name so it contains the bugfix number in the name. Reviewed-by: robilad ! make/common/Release-macosx.gmk Changeset: 919be2f7fd6e Author: cgruszka Date: 2012-04-27 14:37 -0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/919be2f7fd6e Merge Changeset: 762661efef30 Author: jgodinez Date: 2012-04-24 13:29 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/762661efef30 7157659: [macosx] Landscape Printing orientation doesn't work Reviewed-by: bae, prr ! src/macosx/native/sun/awt/PrinterView.m Changeset: cdaadcc2c6a4 Author: jgodinez Date: 2012-04-26 13:16 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/cdaadcc2c6a4 7013850: Please change the mnemonic assignment system to avoid translation issue Reviewed-by: prr, mfang ! src/share/classes/sun/print/ServiceDialog.java ! src/share/classes/sun/print/resources/serviceui.properties ! src/share/classes/sun/print/resources/serviceui_de.properties ! src/share/classes/sun/print/resources/serviceui_es.properties ! src/share/classes/sun/print/resources/serviceui_fr.properties ! src/share/classes/sun/print/resources/serviceui_it.properties ! src/share/classes/sun/print/resources/serviceui_ja.properties ! src/share/classes/sun/print/resources/serviceui_ko.properties ! src/share/classes/sun/print/resources/serviceui_pt_BR.properties ! src/share/classes/sun/print/resources/serviceui_sv.properties ! src/share/classes/sun/print/resources/serviceui_zh_CN.properties ! src/share/classes/sun/print/resources/serviceui_zh_TW.properties Changeset: c2d29a375871 Author: lana Date: 2012-04-26 18:25 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/c2d29a375871 Merge Changeset: 4a19075bb989 Author: lana Date: 2012-05-02 09:53 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/4a19075bb989 Merge Changeset: 44beb8a52aec Author: zhouyx Date: 2012-04-20 10:34 +0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/44beb8a52aec 7129742: Unable to view focus in Non-Editable TextArea Summary: Make sure the cursor is visible by setVisible(true) Reviewed-by: rupashka, alexp ! src/solaris/classes/sun/awt/X11/XTextAreaPeer.java ! src/solaris/classes/sun/awt/X11/XTextFieldPeer.java + test/java/awt/TextArea/TextAreaCaretVisibilityTest/bug7129742.java Changeset: dfa2ea47257d Author: luchsh Date: 2012-04-20 13:13 +0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/dfa2ea47257d 7055065: NullPointerException when sorting JTable with empty cell Reviewed-by: rupashka ! src/share/classes/javax/swing/JTable.java + test/javax/swing/JTable/7055065/bug7055065.java Changeset: 738b32fc3ef1 Author: anthony Date: 2012-04-24 17:47 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/738b32fc3ef1 7150109: [macosx] the Frame showed incomplete. Summary: Open-source the tests Reviewed-by: art + test/java/awt/Frame/FrameStateTest/FrameStateTest.html + test/java/awt/Frame/FrameStateTest/FrameStateTest.java Changeset: 9ed029a0326d Author: anthony Date: 2012-04-24 19:12 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/9ed029a0326d 7163898: add isLoggable() check to doLog() Summary: Add the check and return immediately if it's false Reviewed-by: anthony, mchung, sla Contributed-by: Nicolas Carranza ! src/share/classes/sun/util/logging/PlatformLogger.java Changeset: 4a0f6ef43a09 Author: anthony Date: 2012-04-24 20:39 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/4a0f6ef43a09 7131021: [macosx] Consider using system properties to pass arguments from the launcher to AWT/SplashScreen Summary: Document the environment variables and add tests Reviewed-by: ksrini ! src/macosx/bin/java_md_macosx.c + test/tools/launcher/EnvironmentVariables.java ! test/tools/launcher/TestHelper.java + test/tools/launcher/TestSpecialArgs.java Changeset: 36fd5078198b Author: alexsch Date: 2012-04-25 16:48 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/36fd5078198b 7163482: [macosx] Regtest closed/javax/swing/JTree/4908142/bug4908142.java intermittent failure Reviewed-by: rupashka + test/javax/swing/JTree/4908142/bug4908142.java Changeset: f1d1dab11a06 Author: leonidr Date: 2012-04-25 18:15 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/f1d1dab11a06 7154480: [macosx] Not all popup menu items are visible Reviewed-by: art ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/share/classes/javax/swing/JPopupMenu.java ! src/share/classes/sun/awt/SunToolkit.java Changeset: 340cda7e1430 Author: luchsh Date: 2012-04-26 12:39 +0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/340cda7e1430 7154030: java.awt.Component.hide() does not repaint parent component Reviewed-by: rupashka ! src/share/classes/javax/swing/JComponent.java + test/javax/swing/JComponent/7154030/bug7154030.java Changeset: 6314933aeaa9 Author: alexp Date: 2012-04-26 21:16 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/6314933aeaa9 7124210: [macosx] Replacing text in a TextField does generate an extra TextEvent Reviewed-by: serb ! src/macosx/classes/sun/lwawt/LWTextAreaPeer.java ! src/macosx/classes/sun/lwawt/LWTextComponentPeer.java ! src/macosx/classes/sun/lwawt/LWTextFieldPeer.java Changeset: 4184e5cbf46e Author: alexp Date: 2012-04-26 21:25 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/4184e5cbf46e 7124328: [macosx] javax.swing.JDesktopPane.getAllFramesInLayer returns unexpected value Reviewed-by: anthony ! src/share/classes/javax/swing/JDesktopPane.java Changeset: d148d3d194af Author: lana Date: 2012-04-26 18:15 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/d148d3d194af Merge Changeset: bbbf4e63562b Author: dcherepanov Date: 2012-05-02 13:53 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/bbbf4e63562b 7154062: [macosx] Mouse cursor isn't updated in applets Reviewed-by: anthony, art ! src/macosx/classes/sun/lwawt/macosx/CCursorManager.java ! src/macosx/classes/sun/lwawt/macosx/CEmbeddedFrame.java ! src/macosx/native/sun/awt/CCursorManager.m Changeset: 0fad89bd606b Author: alexsch Date: 2012-05-02 17:54 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/0fad89bd606b 7154048: [macosx] At least drag twice, the toolbar can be dragged to the left side Reviewed-by: anthony, leonidr ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/native/sun/awt/AWTView.h ! src/macosx/native/sun/awt/AWTView.m ! src/macosx/native/sun/awt/AWTWindow.h ! src/macosx/native/sun/awt/AWTWindow.m + test/java/awt/Mouse/EnterExitEvents/DragWindowOutOfFrameTest.java + test/java/awt/Mouse/EnterExitEvents/DragWindowTest.java + test/java/awt/Mouse/EnterExitEvents/ResizingFrameTest.java ! test/java/awt/regtesthelpers/Util.java Changeset: f906d6068b43 Author: lana Date: 2012-05-02 09:54 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/f906d6068b43 Merge Changeset: 717582c056f3 Author: lana Date: 2012-05-02 10:17 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/717582c056f3 Merge - src/macosx/bin/amd64/jvm.cfg - src/share/classes/sun/security/action/LoadLibraryAction.java ! test/tools/launcher/TestHelper.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: bc0f9e693620 Author: lana Date: 2012-05-08 13:08 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/bc0f9e693620 Merge - src/macosx/bin/amd64/jvm.cfg - 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: 185821106403 Author: katleman Date: 2012-05-09 13:07 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/185821106403 Added tag jdk8-b37 for changeset 9e82ac15ab80 ! .hgtags Changeset: c45f3509a707 Author: katleman Date: 2012-05-09 13:13 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/c45f3509a707 Merge - src/macosx/bin/amd64/jvm.cfg - 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: b5726775b0d8 Author: katleman Date: 2012-05-10 10:25 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/b5726775b0d8 Added tag jdk8-b38 for changeset c45f3509a707 ! .hgtags Changeset: c2d9166f3284 Author: ihse Date: 2012-05-11 08:21 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/c2d9166f3284 7168208: Change use of @ in one sed command involving paths to different character Reviewed-by: ohair ! make/common/Release.gmk Changeset: 8d665b69ebf1 Author: mfang Date: 2012-05-15 11:46 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/8d665b69ebf1 7157855: jvisualvm.1 not included in binaries Reviewed-by: katleman, thurka ! make/common/Release.gmk Changeset: b6f529117521 Author: katleman Date: 2012-05-16 22:07 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/b6f529117521 Merge Changeset: 47cd90bf0f66 Author: katleman Date: 2012-05-17 06:20 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/47cd90bf0f66 Added tag jdk8-b39 for changeset b6f529117521 ! .hgtags Changeset: 7c4eed4b6c19 Author: bae Date: 2012-05-21 14:04 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/7c4eed4b6c19 7124400: [macosx] CGraphicsDevice.getConfigurations() returns reference to member (does not copy configs) Reviewed-by: anthony, kizune ! src/macosx/classes/sun/awt/CGraphicsDevice.java ! test/java/awt/GraphicsDevice/CloneConfigsTest.java Changeset: 416b3a498e71 Author: bae Date: 2012-05-21 14:53 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/416b3a498e71 7154088: [macosx] Regression: Component.createImage do not inherits component attributes Reviewed-by: art, kizune ! src/macosx/classes/sun/lwawt/LWComponentPeer.java Changeset: 1b90a0113359 Author: lana Date: 2012-05-21 11:20 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/1b90a0113359 Merge Changeset: c31eeeda3ed1 Author: serb Date: 2012-05-03 18:29 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/c31eeeda3ed1 7160623: [macosx] Editable TextArea/TextField are blocking GUI applications from exit Reviewed-by: anthony, art ! src/macosx/classes/sun/lwawt/LWComponentPeer.java ! src/macosx/classes/sun/lwawt/LWTextComponentPeer.java Changeset: a420895ee2c3 Author: leonidr Date: 2012-05-03 19:22 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/a420895ee2c3 7124376: [macosx] Modal dialog lost focus Reviewed-by: anthony ! 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/AWTView.m ! src/macosx/native/sun/awt/AWTWindow.h ! src/macosx/native/sun/awt/AWTWindow.m Changeset: 95c8b63a3c47 Author: kizune Date: 2012-05-03 21:54 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/95c8b63a3c47 7148289: [macosx] Deadlock in sun.lwawt.macosx.CWrapper$NSScreen.visibleFrame Reviewed-by: leonidr ! src/macosx/classes/sun/lwawt/macosx/CToolkitThreadBlockedHandler.java ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/macosx/native/sun/awt/LWCToolkit.m Changeset: a714e2e2b257 Author: alexsch Date: 2012-05-04 13:15 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/a714e2e2b257 7024963: Notepad demo: remove non-translatable resources from Notepad.properties file Reviewed-by: rupashka ! src/share/demo/jfc/Notepad/Notepad.java ! src/share/demo/jfc/Notepad/resources/Notepad.properties + src/share/demo/jfc/Notepad/resources/system.properties Changeset: 4cc873e28c78 Author: bagiras Date: 2012-05-04 18:42 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/4cc873e28c78 7146237: closed/java/awt/Focus/SetFocusTraversalKeysTest/SetFocusTraversalTest.html failed since 1.8.0b19 Reviewed-by: art, anthony ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java ! src/share/classes/java/awt/KeyboardFocusManager.java ! src/share/classes/javax/swing/JComponent.java Changeset: 0feee4541f67 Author: serb Date: 2012-05-04 21:25 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/0feee4541f67 7147055: [macosx] Cursors are changing over a blocked window; also blinking Reviewed-by: art, kizune ! src/macosx/classes/sun/lwawt/LWCursorManager.java Changeset: 912e666b4e1d Author: serb Date: 2012-05-10 20:05 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/912e666b4e1d 7080109: Dialog.show() lacks doPrivileged() to access system event queue Reviewed-by: art, anthony ! src/share/classes/java/awt/Dialog.java + test/java/awt/Dialog/ModalDialogPermission/ModalDialogPermission.java + test/java/awt/Dialog/ModalDialogPermission/java.policy Changeset: 18842bb6676a Author: lana Date: 2012-05-10 11:47 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/18842bb6676a Merge - src/macosx/bin/amd64/jvm.cfg - 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: 4f39a13e74c6 Author: anthony Date: 2012-05-11 16:11 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/4f39a13e74c6 7166437: [macosx] Support for Window.Type.UTILITY on the Mac Summary: Apply the native UTILITY style for UTILITY Java windows Reviewed-by: art ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java Changeset: 689c0cd214e8 Author: anthony Date: 2012-05-11 20:37 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/689c0cd214e8 7149062: [macosx] dock menu don't show available frames Summary: Inherit from either NSWindow for normal windows or NSPanel for utility windows Reviewed-by: skovatch, swingler ! src/macosx/native/sun/awt/AWTView.m ! src/macosx/native/sun/awt/AWTWindow.h ! src/macosx/native/sun/awt/AWTWindow.m Changeset: 3b8635e357e9 Author: alexsch Date: 2012-05-12 12:01 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/3b8635e357e9 7024965: Stylepad demo: remove non-translatable resources from Stylepad.properties file Reviewed-by: alexp ! src/share/demo/jfc/Notepad/Notepad.java + src/share/demo/jfc/Notepad/resources/NotepadSystem.properties - src/share/demo/jfc/Notepad/resources/system.properties Changeset: cc8d1cc533bf Author: alexp Date: 2012-05-12 17:46 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/cc8d1cc533bf 7149005: [macosx] Java Control Panel's UI controls are distorted when draging scroll bar. Reviewed-by: serb ! src/macosx/classes/com/apple/laf/AquaButtonLabeledUI.java Changeset: 69301efaac91 Author: ant Date: 2012-05-12 18:50 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/69301efaac91 7110683: Issues with some KeyboardFocusManager method Reviewed-by: ahgross ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/DefaultKeyboardFocusManager.java ! src/share/classes/java/awt/KeyboardFocusManager.java ! src/share/classes/java/awt/Window.java Changeset: 28ec5b811aa2 Author: dcherepanov Date: 2012-05-15 15:04 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/28ec5b811aa2 7168550: [macosx] duplicate OGL context state changes related to vertex cache Reviewed-by: bae, swingler ! src/macosx/native/sun/java2d/opengl/CGLSurfaceData.m ! src/share/native/sun/java2d/opengl/OGLContext.h ! src/share/native/sun/java2d/opengl/OGLTextRenderer.c ! src/share/native/sun/java2d/opengl/OGLVertexCache.c ! src/share/native/sun/java2d/opengl/OGLVertexCache.h Changeset: cad0bb1a9bdb Author: dcherepanov Date: 2012-05-16 13:15 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/cad0bb1a9bdb 7124337: [macosx] FileDialog fails to select multiple files Reviewed-by: anthony, swingler ! src/macosx/classes/sun/lwawt/macosx/CFileDialog.java ! src/macosx/native/sun/awt/CFileDialog.h ! src/macosx/native/sun/awt/CFileDialog.m ! src/share/classes/java/awt/FileDialog.java ! src/share/classes/sun/awt/AWTAccessor.java ! src/solaris/classes/sun/awt/X11/GtkFileDialogPeer.java ! src/solaris/classes/sun/awt/X11/XFileDialogPeer.java ! src/windows/classes/sun/awt/windows/WFileDialogPeer.java Changeset: 7c0b390ab5f9 Author: anthony Date: 2012-05-16 14:28 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/7c0b390ab5f9 7168851: [macosx] Netbeans crashes in CImage.nativeCreateNSImageFromArray Summary: Eliminate unnecessary -release call Reviewed-by: dcherepanov ! src/macosx/native/sun/awt/CImage.m Changeset: 3c819d638e36 Author: alexsch Date: 2012-05-16 16:27 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/3c819d638e36 7169226: NLS: Please change the mnemonic assignment system for windows and motif properties Reviewed-by: rupashka ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_de.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_es.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_fr.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_it.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_ja.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_ko.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_pt_BR.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_sv.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_zh_CN.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_zh_TW.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_de.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_es.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_fr.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_it.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_ja.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_ko.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_pt_BR.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_sv.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_zh_CN.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_zh_TW.properties Changeset: 19edcc438203 Author: alexsch Date: 2012-05-16 18:11 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/19edcc438203 7158928: [macosx] NLS: Please change the mnemonic assignment system Reviewed-by: rupashka, serb ! make/com/apple/osxui/Makefile ! make/common/internal/Resources.gmk ! src/macosx/classes/com/apple/laf/AquaLookAndFeel.java ! src/macosx/classes/com/apple/laf/resources/aqua.properties Changeset: 731ee59c6ba2 Author: alexsch Date: 2012-05-17 14:27 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/731ee59c6ba2 7148281: [macosx] JTabbedPane tabs with HTML text do not render correctly Reviewed-by: kizune ! src/macosx/classes/com/apple/laf/AquaTabbedPaneUI.java Changeset: f9217bd87199 Author: rupashka Date: 2012-05-17 15:41 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/f9217bd87199 7166322: closed/javax/swing/text/html/HTMLEditorKit/4242228/bug4242228.java failed since 1.8.0b36 Reviewed-by: alexsch + test/javax/swing/text/html/HTMLEditorKit/4242228/bug4242228.java Changeset: c00d6508afce Author: ant Date: 2012-05-17 21:27 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/c00d6508afce 7142565: [macosx] Many special keys processed twice in text fields Summary: forward port from 7u4 Reviewed-by: anthony ! src/macosx/native/sun/awt/AWTView.m Changeset: 17c5e1a12965 Author: ant Date: 2012-05-17 21:31 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/17c5e1a12965 7154072: [macosx] swallowing key events Summary: forward posrt from 7u4 Reviewed-by: anthony ! src/macosx/native/sun/awt/AWTView.m Changeset: ef77fa799b34 Author: ant Date: 2012-05-17 21:48 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/ef77fa799b34 7125044: [macosx] Test failure because Component.transferFocus() works differently in applet and application. Summary: forward port from 7u4 Reviewed-by: art ! src/share/classes/java/awt/Dialog.java ! src/share/classes/java/awt/Frame.java ! src/share/classes/java/awt/Window.java ! src/share/classes/javax/swing/JApplet.java ! src/share/classes/javax/swing/JDialog.java ! src/share/classes/javax/swing/JFrame.java ! src/share/classes/javax/swing/JInternalFrame.java ! src/share/classes/javax/swing/JWindow.java ! src/share/classes/javax/swing/UIManager.java ! src/share/classes/sun/awt/SunToolkit.java + test/java/awt/Focus/FocusTraversalPolicy/InitialFTP.java + test/java/awt/Focus/FocusTraversalPolicy/InitialFTP_AWT.java + test/java/awt/Focus/FocusTraversalPolicy/InitialFTP_Swing.java + test/java/awt/event/KeyEvent/SwallowKeyEvents/SwallowKeyEvents.java Changeset: 5976b5848554 Author: ant Date: 2012-05-17 22:10 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/5976b5848554 7145768: [macosx] Regression: failure in b11 of ModalDialogInFocusEventTest Summary: forward port from 7u4 Reviewed-by: art ! src/macosx/classes/sun/lwawt/LWComponentPeer.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java Changeset: 1d75ff45586e Author: ant Date: 2012-05-17 22:21 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/1d75ff45586e 7145827: [macosx] JCK failure in b11: FocusableWindow3 Summary: forward posrt from 7u4 Reviewed-by: art ! src/macosx/classes/sun/lwawt/LWWindowPeer.java Changeset: 2eca75e0a063 Author: dcherepanov Date: 2012-05-18 19:39 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/2eca75e0a063 7156191: [macosx] Can't type into applet demos in Pivot Reviewed-by: art ! src/macosx/classes/sun/lwawt/macosx/CEmbeddedFrame.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformResponder.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformView.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java Changeset: 1ee12bca4823 Author: rupashka Date: 2012-05-21 18:55 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/1ee12bca4823 7168144: No appropriate CCC request for changes introduced by 7154030 Reviewed-by: alexsch ! src/share/classes/javax/swing/JComponent.java Changeset: 967b38bfd5c1 Author: ant Date: 2012-05-22 01:12 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/967b38bfd5c1 7170427: setGlobalCurrentFocusCycleRoot unexpectedly throws SecurityException Reviewed-by: art ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java ! src/share/classes/java/awt/KeyboardFocusManager.java Changeset: 5b2095d7a60b Author: lana Date: 2012-05-21 11:41 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/5b2095d7a60b Merge ! src/macosx/classes/sun/lwawt/LWComponentPeer.java Changeset: bb2cefc89bc0 Author: forax Date: 2012-05-02 20:01 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/bb2cefc89bc0 7165102: Only run assertion on Integer autoboxing cache size once Reviewed-by: darcy, alanb ! src/share/classes/java/lang/Integer.java Changeset: 531ebfd8eb65 Author: jgish Date: 2012-05-02 21:46 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/531ebfd8eb65 7160714: Strange or obsolete @see tags in some exception java.util javadoc Reviewed-by: mduigou, dholmes, alanb ! src/share/classes/java/util/NoSuchElementException.java Changeset: 4580652d9828 Author: lancea Date: 2012-05-04 16:00 -0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/4580652d9828 7166598: FilteredRowSetImpl can result in Invalid Cursor Position Reviewed-by: lancea Contributed-by: Knut Anders Hatlen ! src/share/classes/com/sun/rowset/FilteredRowSetImpl.java Changeset: 41d3f7509e00 Author: xuelei Date: 2012-05-04 17:28 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/41d3f7509e00 7153184: NullPointerException when calling SSLEngineImpl.getSupportedCipherSuites Reviewed-by: weijun ! src/share/classes/sun/security/ssl/SSLContextImpl.java Changeset: 62557a1336c0 Author: zhouyx Date: 2012-05-07 16:43 +0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/62557a1336c0 7166048: Remove the embeded epoll data structure. Reviewed-by: alanb ! src/solaris/native/sun/nio/ch/EPollArrayWrapper.c Changeset: b26c04717735 Author: robm Date: 2012-05-07 13:34 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/b26c04717735 7166687: InetAddress.getLocalHost().getHostName() returns FQDN Reviewed-by: chegar ! src/solaris/native/java/net/Inet6AddressImpl.c Changeset: 48513d156965 Author: dholmes Date: 2012-05-08 02:59 -0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/48513d156965 7103570: AtomicIntegerFieldUpdater does not work when SecurityManager is installed Summary: Perform class.getField inside a doPrivileged block Reviewed-by: chegar, psandoz ! src/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicLongFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java + test/java/util/concurrent/atomic/AtomicUpdaters.java Changeset: af209a223b6b Author: sherman Date: 2012-05-08 10:57 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/af209a223b6b 7014640: To add a metachar \R for line ending and character classes for vertical/horizontal ws \v \V \h \H Summary: added propsoed constructs Reviewed-by: alanb ! src/share/classes/java/util/regex/Pattern.java ! test/java/util/regex/RegExTest.java Changeset: 1ece20885be4 Author: sherman Date: 2012-05-08 11:16 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/1ece20885be4 7157656: (zipfs) SeekableByteChannel to entry in zip file always reports its position as 0 Summary: updated SeekableByteChannel.read() to count the bytes read correctly Reviewed-by: sherman Contributed-by: paul.sandoz at oracle.com ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java ! test/demo/zipfs/ZipFSTester.java ! test/demo/zipfs/basic.sh Changeset: fbf98cbd2e6b Author: xuelei Date: 2012-05-08 17:56 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/fbf98cbd2e6b 7167092: Need to put the return clause in the synchronized block Summary: a regression fix for bug 7153184 Reviewed-by: wetmore ! src/share/classes/sun/security/ssl/SSLContextImpl.java Changeset: 0f63f3390ac9 Author: xuelei Date: 2012-05-08 18:08 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/0f63f3390ac9 7166570: JSSE certificate validation has started to fail for certificate chains Reviewed-by: wetmore ! src/share/classes/sun/security/validator/SimpleValidator.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/BasicConstraints.java Changeset: abb63b7357a1 Author: luchsh Date: 2012-05-09 11:19 +0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/abb63b7357a1 7165722: Invalid path in MemoryMonitor demo's README.txt Reviewed-by: alanb, sla ! src/share/demo/management/MemoryMonitor/README.txt Changeset: 5e8caf6984f5 Author: ksrini Date: 2012-05-09 07:28 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/5e8caf6984f5 7166955: (pack200) JNI_GetCreatedJavaVMs needs additional checking Reviewed-by: alanb, dholmes, ksrini Contributed-by: youdwei at linux.vnet.ibm.com ! src/share/native/com/sun/java/util/jar/pack/jni.cpp Changeset: 59121a4c71c6 Author: khazra Date: 2012-05-09 11:14 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/59121a4c71c6 7165118: (prefs) AbstractPreferences.remove(null) does not throw NPE Summary: Insert null argument check in AbstractPreferences.remove() Reviewed-by: dholmes, chegar, alanb ! src/share/classes/java/util/prefs/AbstractPreferences.java ! test/java/util/prefs/RemoveNullKeyCheck.java Changeset: 6438f1277df6 Author: wetmore Date: 2012-05-09 16:33 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/6438f1277df6 7167362: SecureRandom.init should be converted, amendment to 7084245 Reviewed-by: sherman ! src/share/classes/sun/security/provider/SecureRandom.java Changeset: 5152c832745a Author: khazra Date: 2012-05-09 16:55 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/5152c832745a 7096436: (sc) SocketChannel.connect fails on Windows 8 when channel configured non-blocking Summary: Set localAddress only when connection is established Reviewed-by: alanb ! src/share/classes/sun/nio/ch/SocketChannelImpl.java Changeset: fdf5e15293e6 Author: coffeys Date: 2012-05-10 10:45 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/fdf5e15293e6 7163470: Build fails if javax.crypto src files not present Reviewed-by: valeriep ! make/com/oracle/security/ucrypto/Makefile ! make/common/shared/Defs-java.gmk ! make/sun/security/ec/Makefile ! make/sun/security/mscapi/Makefile ! make/sun/security/pkcs11/Makefile ! makefiles/com/oracle/security/ucrypto/Makefile ! makefiles/common/shared/Defs-java.gmk ! makefiles/sun/security/ec/Makefile ! makefiles/sun/security/mscapi/Makefile ! makefiles/sun/security/pkcs11/Makefile Changeset: 3e3017eba8ac Author: valeriep Date: 2012-05-08 17:57 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/3e3017eba8ac 4963723: Implement SHA-224 Summary: Add support for SHA-224, SHA224withRSA, SHA224withECDSA, HmacSHA224 and OAEPwithSHA-224AndMGF1Padding. Reviewed-by: vinnie ! src/share/classes/com/sun/crypto/provider/HmacCore.java ! src/share/classes/com/sun/crypto/provider/HmacMD5.java ! src/share/classes/com/sun/crypto/provider/HmacPKCS12PBESHA1.java ! src/share/classes/com/sun/crypto/provider/HmacSHA1.java ! src/share/classes/com/sun/crypto/provider/KeyGeneratorCore.java ! src/share/classes/com/sun/crypto/provider/OAEPParameters.java ! src/share/classes/com/sun/crypto/provider/SunJCE.java ! src/share/classes/java/security/spec/MGF1ParameterSpec.java ! src/share/classes/java/security/spec/PSSParameterSpec.java ! src/share/classes/sun/security/ec/ECDSASignature.java ! src/share/classes/sun/security/ec/SunECEntries.java ! src/share/classes/sun/security/pkcs11/P11Digest.java ! src/share/classes/sun/security/pkcs11/P11Mac.java ! src/share/classes/sun/security/pkcs11/P11Signature.java ! src/share/classes/sun/security/pkcs11/SunPKCS11.java ! src/share/classes/sun/security/pkcs11/wrapper/Functions.java ! src/share/classes/sun/security/provider/DigestBase.java ! src/share/classes/sun/security/provider/MD2.java ! src/share/classes/sun/security/provider/MD4.java ! src/share/classes/sun/security/provider/MD5.java ! src/share/classes/sun/security/provider/SHA.java ! src/share/classes/sun/security/provider/SHA2.java ! src/share/classes/sun/security/provider/SHA5.java ! src/share/classes/sun/security/provider/SunEntries.java ! src/share/classes/sun/security/rsa/RSASignature.java ! src/share/classes/sun/security/rsa/SunRsaSignEntries.java ! src/share/classes/sun/security/x509/AlgorithmId.java ! src/windows/classes/sun/security/mscapi/RSASignature.java ! src/windows/classes/sun/security/mscapi/SunMSCAPI.java ! test/com/sun/crypto/provider/Cipher/RSA/TestOAEP.java ! test/com/sun/crypto/provider/Cipher/RSA/TestOAEPParameterSpec.java ! test/com/sun/crypto/provider/Cipher/RSA/TestOAEPWithParams.java ! test/com/sun/crypto/provider/KeyGenerator/Test4628062.java ! test/com/sun/crypto/provider/Mac/MacClone.java ! test/com/sun/crypto/provider/Mac/MacKAT.java ! test/sun/security/mscapi/SignUsingNONEwithRSA.java ! test/sun/security/mscapi/SignUsingSHA2withRSA.java ! test/sun/security/pkcs11/MessageDigest/DigestKAT.java ! test/sun/security/pkcs11/MessageDigest/TestCloning.java ! test/sun/security/pkcs11/Signature/TestRSAKeyLength.java ! test/sun/security/pkcs11/ec/TestCurves.java ! test/sun/security/pkcs11/rsa/TestKeyPairGenerator.java ! test/sun/security/pkcs11/rsa/TestSignatures.java ! test/sun/security/provider/MessageDigest/DigestKAT.java ! test/sun/security/provider/MessageDigest/Offsets.java ! test/sun/security/provider/MessageDigest/TestSHAClone.java ! test/sun/security/rsa/TestKeyPairGenerator.java ! test/sun/security/rsa/TestSignatures.java Changeset: dfce31760a2f Author: valeriep Date: 2012-05-08 18:57 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/dfce31760a2f Merge Changeset: 9f8210f23773 Author: valeriep Date: 2012-05-10 11:19 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/9f8210f23773 Merge Changeset: c5a07e3dca63 Author: youdwei Date: 2012-05-11 16:20 +0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/c5a07e3dca63 7163874: InetAddress.isReachable should support pinging 0.0.0.0 Reviewed-by: alanb, chegar ! src/share/native/java/net/net_util.h ! src/solaris/native/java/net/Inet4AddressImpl.c ! src/solaris/native/java/net/Inet6AddressImpl.c ! src/solaris/native/java/net/net_util_md.c + test/java/net/Inet4Address/PingThis.java Changeset: 3e83229a3779 Author: coffeys Date: 2012-05-11 10:09 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/3e83229a3779 7167359: (tz) SEGV on solaris if TZ variable not set Reviewed-by: okutsu ! src/solaris/native/java/util/TimeZone_md.c Changeset: 944676ef3c58 Author: mduigou Date: 2012-05-11 11:31 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/944676ef3c58 7071826: Avoid benign race condition in initialization of UUID Summary: Avoids mostly benign but sometimes expensive race condition on initialization of UUID.numberGenerator which is used by UUID.randomUUID() Reviewed-by: alanb, chegar ! src/share/classes/java/util/UUID.java ! test/java/util/UUID/UUIDTest.java Changeset: 85d7677a75bf Author: lana Date: 2012-05-11 12:53 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/85d7677a75bf Merge Changeset: f131d4361faf Author: olagneau Date: 2012-05-11 14:13 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/f131d4361faf 7144861: speed up RMI activation tests Reviewed-by: alanb, smarks, dholmes, dmocek ! test/java/rmi/activation/checkusage/CheckUsage.java ! test/java/rmi/testlibrary/ActivationLibrary.java ! test/java/rmi/testlibrary/JavaVM.java ! test/java/rmi/testlibrary/RMID.java ! test/java/rmi/testlibrary/StreamPipe.java ! test/sun/rmi/runtime/Log/6409194/NoConsoleOutput.java Changeset: df3152beef2f Author: xuelei Date: 2012-05-14 07:26 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/df3152beef2f 7167988: PKIX CertPathBuilder in reverse mode doesn't work if more than one trust anchor is specified Reviewed-by: mullan ! src/share/classes/sun/security/provider/certpath/SunCertPathBuilder.java + test/sun/security/provider/certpath/ReverseBuilder/ReverseBuild.java Changeset: df33f5f750ec Author: dsamersoff Date: 2012-05-15 16:46 +0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/df33f5f750ec 7164191: properties.putAll API may fail with ConcurrentModifcationException on multi-thread scenario Reviewed-by: dholmes, sla Contributed-by: Deven You ! src/share/classes/sun/management/Agent.java + test/sun/management/AgentCMETest.java Changeset: 9a18e318f95a Author: khazra Date: 2012-05-15 11:51 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/9a18e318f95a 7164636: (prefs) Cleanup src/macosx/classes/java/util/prefs Summary: Remove rawtype usages and other code cleanup Reviewed-by: chegar, briangoetz ! src/macosx/classes/java/util/prefs/MacOSXPreferences.java ! src/macosx/classes/java/util/prefs/MacOSXPreferencesFactory.java ! src/macosx/classes/java/util/prefs/MacOSXPreferencesFile.java Changeset: 332bebb463d1 Author: alanb Date: 2012-05-16 12:43 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/332bebb463d1 7168505: (bf) MappedByteBuffer.load does not load buffer's content into memory Reviewed-by: mduigou, forax ! src/share/classes/java/nio/MappedByteBuffer.java Changeset: ce165aa48dcb Author: dcubed Date: 2012-05-17 06:26 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/ce165aa48dcb 7168520: No jdk8 TL Nightly linux builds due to broken link in b39-2012-05-13_231 Summary: ZIP libjsig.debuginfo links into libjsig.diz files since aurora doesn't like dangling symlinks Reviewed-by: katleman ! make/java/redist/Makefile Changeset: 178c480998b1 Author: robm Date: 2012-05-17 22:42 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/178c480998b1 7168110: Misleading jstack error message Reviewed-by: alanb, dsamersoff ! src/windows/native/sun/tools/attach/WindowsVirtualMachine.c Changeset: 9fe6ebbe5895 Author: xuelei Date: 2012-05-17 21:59 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/9fe6ebbe5895 7145960: sun/security/mscapi/ShortRSAKey1024.sh failing on windows Reviewed-by: vinnie, wetmore ! test/sun/security/mscapi/ShortRSAKey1024.sh ! test/sun/security/mscapi/ShortRSAKey512.sh ! test/sun/security/mscapi/ShortRSAKey768.sh Changeset: af1030be726a Author: valeriep Date: 2012-05-18 12:29 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/af1030be726a 7169496: Problem with the SHA-224 support for SunMSCAPI provider Summary: Remove SHA224withRSA signature from SunMSCAPI provider due to lack of windows support. Reviewed-by: vinnie ! src/windows/classes/sun/security/mscapi/RSASignature.java ! src/windows/classes/sun/security/mscapi/SunMSCAPI.java ! test/sun/security/mscapi/SignUsingNONEwithRSA.java ! test/sun/security/mscapi/SignUsingSHA2withRSA.java Changeset: 72af24348b2b Author: weijun Date: 2012-05-21 15:40 +0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/72af24348b2b 7170308: timing error in the krb5 test SSL.java Reviewed-by: xuelei ! test/sun/security/krb5/auto/SSL.java Changeset: 9cb304dd71d4 Author: alanb Date: 2012-05-21 10:41 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/9cb304dd71d4 7170203: TEST_BUG: test/java/nio/MappedByteBuffer/Truncate.java failing intermittently Reviewed-by: chegar ! test/java/nio/MappedByteBuffer/Truncate.java Changeset: f109feb13698 Author: ksrini Date: 2012-05-21 09:40 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/f109feb13698 7170087: tools/launcher/Arrghs.java test has wrong bugID for 7151434 Reviewed-by: ohair ! test/tools/launcher/Arrrghs.java Changeset: 0a1ef7e07e01 Author: sla Date: 2012-05-21 19:28 +0200 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/0a1ef7e07e01 7167157: jcmd command file parsing does not respect the "stop" command Reviewed-by: alanb, dsamersoff, nloodin ! src/share/classes/sun/tools/jcmd/JCmd.java Changeset: b88fc3359dc7 Author: lana Date: 2012-05-21 11:44 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/b88fc3359dc7 Merge Changeset: 7def50698e78 Author: katleman Date: 2012-05-24 16:15 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/7def50698e78 Added tag jdk8-b40 for changeset b88fc3359dc7 ! .hgtags Changeset: b3bccd7d176b Author: alanb Date: 2012-05-28 19:43 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/b3bccd7d176b Merge ! .hgtags ! make/com/apple/osxui/Makefile ! make/com/oracle/security/ucrypto/Makefile ! make/common/Release.gmk ! make/common/shared/Defs-java.gmk ! make/java/redist/Makefile ! make/sun/security/ec/Makefile ! make/sun/security/mscapi/Makefile ! make/sun/security/pkcs11/Makefile ! src/share/classes/java/util/prefs/AbstractPreferences.java ! src/share/classes/sun/security/provider/SecureRandom.java From alan.bateman at oracle.com Tue May 29 04:47:32 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 29 May 2012 11:47:32 +0000 Subject: hg: jigsaw/jigsaw/langtools: 10 new changesets Message-ID: <20120529114754.7BED44758F@hg.openjdk.java.net> Changeset: 1f224f160aa8 Author: katleman Date: 2012-05-09 13:08 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/1f224f160aa8 Added tag jdk8-b37 for changeset 5891b38985e8 ! .hgtags Changeset: a9f547c218d9 Author: katleman Date: 2012-05-10 10:25 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/a9f547c218d9 Added tag jdk8-b38 for changeset 1f224f160aa8 ! .hgtags Changeset: 8b869afd2eb4 Author: katleman Date: 2012-05-17 06:20 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/8b869afd2eb4 Added tag jdk8-b39 for changeset a9f547c218d9 ! .hgtags Changeset: d10db3576c08 Author: ksrini Date: 2012-05-04 07:55 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/d10db3576c08 7166010: (javac) JavacMessager incorrectly restores log source file Reviewed-by: jjg Contributed-by: jan.lahoda at oracle.com ! src/share/classes/com/sun/tools/javac/processing/JavacMessager.java + test/tools/javac/processing/messager/MessagerDiags.java Changeset: 833bab705918 Author: ksrini Date: 2012-05-10 12:32 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/833bab705918 7159445: (javac) emits inaccurate diagnostics for enhanced for-loops Reviewed-by: jjg Contributed-by: jan.lahoda at oracle.com ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/ForeachBadInitialization.java ! test/tools/javac/parser/JavacParserTest.java Changeset: 96a8278e323c Author: sundar Date: 2012-05-11 20:06 +0530 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/96a8278e323c 7166990: java/compiler Inherited interfaces using generics sometimes looses the generic type Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Lower.java + test/tools/javac/TryWithResources/T7164542.java Changeset: 885806e74240 Author: lana Date: 2012-05-11 12:53 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/885806e74240 Merge Changeset: 86e0dad6aadf Author: lana Date: 2012-05-21 11:44 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/86e0dad6aadf Merge Changeset: 179fa85aeefa Author: katleman Date: 2012-05-24 16:16 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/179fa85aeefa Added tag jdk8-b40 for changeset 86e0dad6aadf ! .hgtags Changeset: c0f9452ab55c Author: alanb Date: 2012-05-28 19:43 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/c0f9452ab55c Merge ! .hgtags ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties From alan.bateman at oracle.com Tue May 29 06:11:51 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 29 May 2012 13:11:51 +0000 Subject: hg: jigsaw/jigsaw/jdk: JDBC in module-mode fails with UnsatisfiedLinkError Message-ID: <20120529131206.1343E47591@hg.openjdk.java.net> Changeset: 2575dd3ad043 Author: alanb Date: 2012-05-29 14:11 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/2575dd3ad043 JDBC in module-mode fails with UnsatisfiedLinkError Also jdk.jdbc missing "requires optional service javax.sql.rowset.RowSetFactory" ! make/modules/jdk.depconfig ! src/share/classes/java/sql/DriverManager.java From paul.sandoz at oracle.com Tue May 29 07:21:27 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 29 May 2012 16:21:27 +0200 Subject: Audio/Midi services Fwd: CR 7172234 Created, P2 java/jigsaw Lot of sound test failed due UnsatisfiedLinkError for com.sun.media.sound.* classes References: <1132073.1338214278338.JavaMail.sbladm@swsblss4-new.central.sun.com> Message-ID: <95506678-30E3-47B6-B9A7-EA1F63DFB047@oracle.com> Hi, There are a bunch of audio and midi services that are missing declarations in jdk.desktop. In AudioSystem.java: private static List getMixerProviders() { return getProviders(MixerProvider.class); } private static List getFormatConversionProviders() { return getProviders(FormatConversionProvider.class); } private static List getAudioFileReaders() { return getProviders(AudioFileReader.class); } private static List getAudioFileWriters() { return getProviders(AudioFileWriter.class); } In MidiSystem.java: private static List getMidiDeviceProviders() { return getProviders(MidiDeviceProvider.class); } private static List getSoundbankReaders() { return getProviders(SoundbankReader.class); } private static List getMidiFileWriters() { return getProviders(MidiFileWriter.class); } private static List getMidiFileReaders() { return getProviders(MidiFileReader.class); } I dunno if this is contributing to some of the failed tests. Paul. Begin forwarded message: > From: maksim.khramov at oracle.com > Subject: CR 7172234 Created, P2 java/jigsaw Lot of sound test failed due UnsatisfiedLinkError for com.sun.media.sound.* classes > Date: May 28, 2012 4:11:18 PM GMT+02:00 > To: mark.reinhold at oracle.com, mandy.chung at oracle.com, chris.hegarty at oracle.com, jigsaw-dev_ww_grp at oracle.com, leonid.kuskov at oracle.com, maksim.khramov at oracle.com, ursqe_bugs_ww_grp at oracle.com, dmitry.bessonov at oracle.com, jonathan.gibbons at oracle.com, ekaterina.pavlova at oracle.com > > Sun Confidential: Internal only > > *Synopsis*: Lot of sound test failed due UnsatisfiedLinkError for com.sun.media.sound.* classes > > Bugster: http://bt2ws.central.sun.com/loadcr.jnlp?jnlp_url=http://bugster.central.sun.com/&arg=7172234 > CrPrint: http://bt2ws.central.sun.com/CrPrint?id=7172234 > Monaco: http://monaco.us.oracle.com/detail.jsf?cr=7172234 > > > *Change Request ID*: 7172234 > > *Synopsis*: Lot of sound test failed due UnsatisfiedLinkError for com.sun.media.sound.* classes > > Product: java > Category: java > Subcategory: jigsaw > Type: Defect > Subtype: > Status: 1-Dispatched > Substatus: > Priority: 2-High > Introduced In Release: > Introduced In Build: > Responsible Manager: frances.ho at oracle.com > Responsible Engineer: > Initial Evaluator: jigsaw-dev_ww_grp at oracle.com > Keywords: test-sound > > === *Description* ============================================================ > Lot of sound test failed due UnsatisfiedLinkError for com.sun.media.sound.* classes > > [2012-05-28T13:13:04.93] java.lang.reflect.InvocationTargetException > [2012-05-28T13:13:04.93] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > [2012-05-28T13:13:04.93] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > [2012-05-28T13:13:04.93] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > [2012-05-28T13:13:04.93] at java.lang.reflect.Method.invoke(Method.java:474) > [2012-05-28T13:13:04.93] at helper.ModuleTestRunWrapper.main(ModuleTestRunWrapper.java:47) > [2012-05-28T13:13:04.93] Caused by: java.lang.NoClassDefFoundError: com/sun/media/sound/Toolkit > [2012-05-28T13:13:04.93] at ToolkitTests.contructorTests(ToolkitTests.java:50) > [2012-05-28T13:13:04.93] at ToolkitTests.main(ToolkitTests.java:36) > ... > > > See more in comments... > > *** (#1 of 1): 2012-05-28 14:07:46 GMT+00:00 maksim.khramov at oracle.com > > > === *Public Comments* ======================================================== > > === *Comments* =============================================================== > Testsuite name: Sound > > JDK/JRE tested: build 1.8.0-ea-jigsaw-nightly-h430-20120524-b36-b00 > OS/architecture: Solaris 10 amd64 > Reproducible: Always > Reproducible on machine: stt-12.ru.oracle.com > > Test results log: > http://vice.russia.sun.com/results/1.8.0/jigsaw/b01/sound/tonga.output/Tonga.log.log > Specific tests location: /net/vice/export/home0/results/1.8.0/jigsaw/b01/sound/ResultsDir/* > Lot of tests filed due UnsatisfiedLinkError exception for classes from com.sun.media.sound. package > See test ToolkitTests failure log: > java.lang.reflect.InvocationTargetException > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:474) > at helper.ModuleTestRunWrapper.main(ModuleTestRunWrapper.java:47) > Caused by: java.lang.NoClassDefFoundError: com/sun/media/sound/Toolkit > at ToolkitTests.contructorTests(ToolkitTests.java:50) > at ToolkitTests.main(ToolkitTests.java:36) > ... 5 more > Caused by: java.lang.ClassNotFoundException: com.sun.media.sound.Toolkit > at java.net.URLClassLoader$1.run(URLClassLoader.java:359) > at java.net.URLClassLoader$1.run(URLClassLoader.java:348) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:347) > at java.lang.ClassLoader.loadClass(ClassLoader.java:424) > at java.lang.ClassLoader.loadClass(ClassLoader.java:357) > ... 7 more > java.lang.NoClassDefFoundError: com/sun/media/sound/Toolkit > at ToolkitTests.contructorTests(ToolkitTests.java:50) > at ToolkitTests.main(ToolkitTests.java:36) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:474) > at helper.ModuleTestRunWrapper.main(ModuleTestRunWrapper.java:47) > Caused by: java.lang.ClassNotFoundException: com.sun.media.sound.Toolkit > at java.net.URLClassLoader$1.run(URLClassLoader.java:359) > at java.net.URLClassLoader$1.run(URLClassLoader.java:348) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:347) > at java.lang.ClassLoader.loadClass(ClassLoader.java:424) > at java.lang.ClassLoader.loadClass(ClassLoader.java:357) > ... 7 more > > but jar command shows these classes.. ex: > ./jar tf ../lib/modules/jdk.desktop/8-ea/classes | grep com/sun/media/sound/Toolkit > shows > com/sun/media/sound/Toolkit.class > > *** (#1 of 1): 2012-05-28 14:07:46 GMT+00:00 maksim.khramov at oracle.com > > > === *Evaluation* ============================================================= > > === *Suggested Fix* ========================================================== > > === *Workaround* ============================================================= > > === *Justification* ========================================================== > Priority changed from [] to [2-High] > Lot of tests failed > maksim.khramov at oracle.com 2012-05-28 14:07:46 GMT > > *** (#1 of 1): 2012-05-28 14:07:46 GMT+00:00 maksim.khramov at oracle.com > > > === *Additional Details* ===================================================== > Targeted Release: > Commit To Fix In Build: > Fixed In Build: > Integrated In Build: > Verified In Build: > See Also: > Duplicate of: > Hooks: > Hook1: > Hook2: > Hook3: > Hook4: > Hook5: > Hook6: > Interest List: ursqe_bugs_ww_grp at oracle.com > Program Management: > Root Cause: > Is a Security Vulnerability?: No > Fix Affects Documentation: No > Fix Affects Localization: No > Reported by: > > === *History* ================================================================ > Date Submitted: 2012-05-28 14:07:46 GMT+00:00 > Submitted By: maksim.khramov at oracle.com > > Status Changed Date Updated Updated By > > > === *Solution* =============================================================== > > > === *Service Request* ======================================================== > ID: 1-806611308 > Customer: > Account Name: JavaSoft > Customer Contact: javase-sqe > Customer Contact Role: S-System Test > Customer Contact Type: I-Internal (SMI) Customer > Impact: Significant > Functionality: Primary > Severity: 2 > Synopsis: > Product Name: java > Product Release: 8 > Product Build: > Operating System: solaris_10 > Hardware: x64 > Reference Number: > Sun Contact: maksim.khramov at oracle.com > Status: Open > Source: BugTraq2 > Reproducible: > Submitted By: maksim.khramov at oracle.com > Submitted Date: 2012-05-28 14:07:46 GMT+00:00 > Description: > > > === *Activity* =============================================================== > > > === *Multiple Release (MR) Cluster* - 0 ====================================== > > > === *Escalations* ============================================================ > From Alan.Bateman at oracle.com Tue May 29 07:40:25 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 29 May 2012 15:40:25 +0100 Subject: Dump services webrev In-Reply-To: <875DA971-AE99-4FC1-9E7A-A1B1FB2A7324@oracle.com> References: <87D7286B-9C7D-4A44-B325-65D693F9516D@oracle.com> <4FBFBCAD.7050703@oracle.com> <875DA971-AE99-4FC1-9E7A-A1B1FB2A7324@oracle.com> Message-ID: <4FC4DFD9.9070002@oracle.com> On 29/05/2012 09:53, Paul Sandoz wrote: > : > I presume the best practice is to stick to the same style in the source itself. Is there a recommended style guide available? any tools to help apply such a guide (e.g. in NetBeans)? There is a lot of inconsistency in the JDK so I would suggest just keep the changes locally consistent. > : > > > jdk $ hg diff src/share/classes/org/openjdk/jigsaw/Configuration.java > diff -r 1690f9dd8ebd src/share/classes/org/openjdk/jigsaw/Configuration.java > --- a/src/share/classes/org/openjdk/jigsaw/Configuration.java Fri May 18 12:55:26 2012 -0700 > +++ b/src/share/classes/org/openjdk/jigsaw/Configuration.java Tue May 29 10:42:15 2012 +0200 > @@ -144,7 +144,27 @@ > this.contextForName = new HashMap(); > } > > + private void dumpServices(String title, Map> services, > + PrintStream out) > + { > + if (!services.isEmpty()) { > + out.format(" %s (%d)%n", title, services.size()); > + > + for (Map.Entry> service : services.entrySet()) { > + Set names = service.getValue(); > + out.format(" %s (%d)%n", service.getKey(), names.size()); > + for (String name : names) { > + out.format(" %s%n", name); > + } > + } > + } > + } > + > private void dump(Context cx, boolean all, PrintStream out) { > + dumpServices("local service providers", cx.services(), out); > + > + dumpServices("remote service suppliers", cx.serviceSuppliers(), out); > + > if (!cx.localClasses().isEmpty()) { > Set classes = new TreeSet<>(cx.localClasses()); > out.format(" local (%d)", classes.size()); This looks fine to me and I'm happy to push it for you. -Alan. From Alan.Bateman at oracle.com Tue May 29 08:04:48 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 29 May 2012 16:04:48 +0100 Subject: Dump services webrev In-Reply-To: References: <87D7286B-9C7D-4A44-B325-65D693F9516D@oracle.com> <4FBF607A.5080809@oracle.com> <4FBFAD18.1040001@oracle.com> <4FBFC4B9.7010408@oracle.com> Message-ID: <4FC4E590.7070805@oracle.com> On 25/05/2012 22:38, Paul Sandoz wrote: > : > There is a distinction between a service *factory* and a set of services all of which are relevant [*]. For the latter case a rogue service can mess up access to the subset of those that come after it (and that subset is arbitrary and could change for each execution of the VM). > > I think we need some ability for the developer to control what should be done under such circumstances (e.g. some callback that decides to continue or re-throw). This is a good use-case for ModuleServiceProvider. > I agree that provider interfaces that are themselves factories are less likely to fail at instantiation time. I also agree there will be cases where you want to take some action, log or emit an warning for example, and attempt to continue. However I'm not convinced that it will be can be reliable in the face of a rogue service though, especially if it goes into a loop or hits a resource error. As it stands we have the SCE and while not pretty, it at least gives the caller some control. It's probably not worth adding policy support to ServiceLoader but may be something for a replacement in the future if we decide to go in that direction. -Alan. From paul.sandoz at oracle.com Tue May 29 08:59:19 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 29 May 2012 17:59:19 +0200 Subject: Dump services webrev In-Reply-To: <4FC4E590.7070805@oracle.com> References: <87D7286B-9C7D-4A44-B325-65D693F9516D@oracle.com> <4FBF607A.5080809@oracle.com> <4FBFAD18.1040001@oracle.com> <4FBFC4B9.7010408@oracle.com> <4FC4E590.7070805@oracle.com> Message-ID: On May 29, 2012, at 5:04 PM, Alan Bateman wrote: > On 25/05/2012 22:38, Paul Sandoz wrote: >> : >> There is a distinction between a service *factory* and a set of services all of which are relevant [*]. For the latter case a rogue service can mess up access to the subset of those that come after it (and that subset is arbitrary and could change for each execution of the VM). >> >> I think we need some ability for the developer to control what should be done under such circumstances (e.g. some callback that decides to continue or re-throw). This is a good use-case for ModuleServiceProvider. >> > I agree that provider interfaces that are themselves factories are less likely to fail at instantiation time. I also agree there will be cases where you want to take some action, log or emit an warning for example, and attempt to continue. However I'm not convinced that it will be can be reliable in the face of a rogue service though, especially if it goes into a loop or hits a resource error. As it stands we have the SCE and while not pretty, it at least gives the caller some control. Yes, limited control. If i could distill this down it is really about whether there should be control over the propagation of the SCE. Paul. > It's probably not worth adding policy support to ServiceLoader but may be something for a replacement in the future if we decide to go in that direction. > > -Alan. From chris.hegarty at oracle.com Tue May 29 13:45:26 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 29 May 2012 21:45:26 +0100 Subject: RFR: Try to install already installed jmod/modular jar issue Message-ID: <4FC53566.80703@oracle.com> Trivial issue that crept in whereby if you try to install an already installed module it will actually remove it! If a module is already installed ( or there is a view or alias with a similar name ) the addition to the module directory will fail. The error handling code incorrectly assumes that the requested module should be removed. Trivial change to only attempt removal after the addition to the module directory has succeeded, i.e. only if there has been a change to the actual library or meta data. http://cr.openjdk.java.net/~chegar/jigsaw/doubleInstall_webrev.00/webrev/ -Chris. From mandy.chung at oracle.com Tue May 29 13:53:59 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 29 May 2012 13:53:59 -0700 Subject: Dump services webrev In-Reply-To: <875DA971-AE99-4FC1-9E7A-A1B1FB2A7324@oracle.com> References: <87D7286B-9C7D-4A44-B325-65D693F9516D@oracle.com> <4FBFBCAD.7050703@oracle.com> <875DA971-AE99-4FC1-9E7A-A1B1FB2A7324@oracle.com> Message-ID: <4FC53767.2050405@oracle.com> On 5/29/2012 1:53 AM, Paul Sandoz wrote: > >> http://cr.openjdk.java.net/~mchung/jigsaw/annotated_jdk_webrev/ > Did you use some tool to help identify and make code changes? I only used NetBeans (and also grep) and annotated the code while inspecting the code for these dependencies. There are some patterns we could build a tool to identify and make code changes but I can't think of a good way to identify all cases. Since the post-processing modularization and generating module-info.java at build time is temporary, I didn't spend too much time on it as I expect that the jdk changes to the non-static dependencies would be limited and should be manageable once I did the first pass. > jdk $ hg diff src/share/classes/org/openjdk/jigsaw/Configuration.java > diff -r 1690f9dd8ebd src/share/classes/org/openjdk/jigsaw/Configuration.java > --- a/src/share/classes/org/openjdk/jigsaw/Configuration.java Fri May 18 12:55:26 2012 -0700 > +++ b/src/share/classes/org/openjdk/jigsaw/Configuration.java Tue May 29 10:42:15 2012 +0200 > @@ -144,7 +144,27 @@ > this.contextForName = new HashMap(); > } > > + private void dumpServices(String title, Map> services, > + PrintStream out) > + { > + if (!services.isEmpty()) { > + out.format(" %s (%d)%n", title, services.size()); > + > + for (Map.Entry> service : services.entrySet()) { > + Set names = service.getValue(); > + out.format(" %s (%d)%n", service.getKey(), names.size()); > + for (String name : names) { > + out.format(" %s%n", name); > + } > + } > + } > + } > + > private void dump(Context cx, boolean all, PrintStream out) { > + dumpServices("local service providers", cx.services(), out); > + > + dumpServices("remote service suppliers", cx.serviceSuppliers(), out); > + > if (!cx.localClasses().isEmpty()) { > Set classes = new TreeSet<>(cx.localClasses()); > out.format(" local (%d)", classes.size()); Looks fine to me. Thanks Mandy Mandy From alan.bateman at oracle.com Wed May 30 05:01:13 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 30 May 2012 12:01:13 +0000 Subject: hg: jigsaw/jigsaw/jdk: Adding services configuration to dump-config output Message-ID: <20120530120132.41EA3475B6@hg.openjdk.java.net> Changeset: 68564a2f4750 Author: psandoz Date: 2012-05-30 13:00 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/68564a2f4750 Adding services configuration to dump-config output Reviewed-by: mchung, alanb ! src/share/classes/org/openjdk/jigsaw/Configuration.java From Alan.Bateman at oracle.com Wed May 30 06:33:52 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 30 May 2012 14:33:52 +0100 Subject: RFR: Try to install already installed jmod/modular jar issue In-Reply-To: <4FC53566.80703@oracle.com> References: <4FC53566.80703@oracle.com> Message-ID: <4FC621C0.3070400@oracle.com> On 29/05/2012 21:45, Chris Hegarty wrote: > Trivial issue that crept in whereby if you try to install an already > installed module it will actually remove it! > > If a module is already installed ( or there is a view or alias with a > similar name ) the addition to the module directory will fail. The > error handling code incorrectly assumes that the requested module > should be removed. > > Trivial change to only attempt removal after the addition to the > module directory has succeeded, i.e. only if there has been a change > to the actual library or meta data. > > http://cr.openjdk.java.net/~chegar/jigsaw/doubleInstall_webrev.00/webrev/ > > -Chris. This is somewhat amusing, it's good that you spotted it. The changes look okay to me. -Alan. From paul.sandoz at oracle.com Wed May 30 07:41:05 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 30 May 2012 16:41:05 +0200 Subject: Patch for audi/midi services Re: Audio/Midi services Fwd: CR 7172234 Created, P2 java/jigsaw Lot of sound test failed due UnsatisfiedLinkError for com.sun.media.sound.* classes In-Reply-To: <95506678-30E3-47B6-B9A7-EA1F63DFB047@oracle.com> References: <1132073.1338214278338.JavaMail.sbladm@swsblss4-new.central.sun.com> <95506678-30E3-47B6-B9A7-EA1F63DFB047@oracle.com> Message-ID: <3791C0A8-130E-4D99-870F-BD1E91ECF85C@oracle.com> Hi, See end of email for a patch to add the audi/midi services. Here is some sampled output from dump-config for the desktop context (proof that is it working): local service providers (14) javax.sound.midi.spi.MidiFileWriter (1) com.sun.media.sound.StandardMidiFileWriter javax.sound.midi.spi.MidiFileReader (1) com.sun.media.sound.StandardMidiFileReader javax.sound.sampled.spi.MixerProvider (2) com.sun.media.sound.PortMixerProvider com.sun.media.sound.DirectAudioDeviceProvider javax.sound.sampled.spi.AudioFileReader (5) com.sun.media.sound.AuFileReader com.sun.media.sound.AiffFileReader com.sun.media.sound.WaveFileReader com.sun.media.sound.WaveFloatFileReader com.sun.media.sound.SoftMidiAudioFileReader javax.sound.sampled.spi.FormatConversionProvider (4) com.sun.media.sound.AudioFloatFormatConverter com.sun.media.sound.UlawCodec com.sun.media.sound.AlawCodec com.sun.media.sound.PCMtoPCMCodec javax.sound.sampled.spi.AudioFileWriter (3) com.sun.media.sound.AuFileWriter com.sun.media.sound.AiffFileWriter com.sun.media.sound.WaveFileWriter javax.sound.midi.spi.MidiDeviceProvider (4) com.sun.media.sound.RealTimeSequencerProvider com.sun.media.sound.MidiOutDeviceProvider com.sun.media.sound.MidiInDeviceProvider com.sun.media.sound.SoftProvider javax.sound.midi.spi.SoundbankReader (4) com.sun.media.sound.SF2SoundbankReader com.sun.media.sound.DLSSoundbankReader com.sun.media.sound.AudioFileSoundbankReader com.sun.media.sound.JARSoundbankReader It seems the pattern in jdk.depconfig is to always use optional, so i kept it like that, but since there are always services for the audi/midi cases, we don't need it to be optional, correct? Paul. $ hg diff diff -r 68564a2f4750 make/modules/jdk.depconfig --- a/make/modules/jdk.depconfig Wed May 30 13:00:52 2012 +0100 +++ b/make/modules/jdk.depconfig Wed May 30 16:36:43 2012 +0200 @@ -542,3 +542,27 @@ @Provider(optional) javax.xml.soap.SOAPFactory -> META-INF/services/javax.xml.soap.SOAPFactory + at Provider(optional) + javax.sound.midi.spi.MidiDeviceProvider -> META-INF/services/javax.sound.midi.spi.MidiDeviceProvider + + at Provider(optional) + javax.sound.midi.spi.MidiFileReader -> META-INF/services/javax.sound.midi.spi.MidiFileReader + + at Provider(optional) + javax.sound.midi.spi.MidiFileWriter -> META-INF/services/javax.sound.midi.spi.MidiFileWriter + + at Provider(optional) + javax.sound.midi.spi.SoundbankReader -> META-INF/services/javax.sound.midi.spi.SoundbankReader + + at Provider(optional) + javax.sound.sampled.spi.AudioFileReader -> META-INF/services/javax.sound.sampled.spi.AudioFileReader + + at Provider(optional) + javax.sound.sampled.spi.AudioFileWriter -> META-INF/services/javax.sound.sampled.spi.AudioFileWriter + + at Provider(optional) + javax.sound.sampled.spi.FormatConversionProvider -> META-INF/services/javax.sound.sampled.spi.FormatConversionProvider + + at Provider(optional) + javax.sound.sampled.spi.MixerProvider -> META-INF/services/javax.sound.sampled.spi.MixerProvider + From Alan.Bateman at oracle.com Wed May 30 08:52:32 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 30 May 2012 16:52:32 +0100 Subject: Patch for audi/midi services Re: Audio/Midi services Fwd: CR 7172234 Created, P2 java/jigsaw Lot of sound test failed due UnsatisfiedLinkError for com.sun.media.sound.* classes In-Reply-To: <3791C0A8-130E-4D99-870F-BD1E91ECF85C@oracle.com> References: <1132073.1338214278338.JavaMail.sbladm@swsblss4-new.central.sun.com> <95506678-30E3-47B6-B9A7-EA1F63DFB047@oracle.com> <3791C0A8-130E-4D99-870F-BD1E91ECF85C@oracle.com> Message-ID: <4FC64240.8010305@oracle.com> On 30/05/2012 15:41, Paul Sandoz wrote: > : > > It seems the pattern in jdk.depconfig is to always use optional, so i kept it like that, but since there are always services for the audi/midi cases, we don't need it to be optional, correct? > Most (perhaps all) usages of ServiceLoader in the JDK also have a fallback to a default implementation when there aren't any service providers (service implementations) installed. So assuming this is how it specified then then "requires optional service ..." is right. I'm not familiar with the JavaSound API. If the specification requires that there be at least one service provider then the module declaration should be "requires service ..." and the resolver will fail with " No implementations of service .." if there aren't any implementations. As we don't have the module-info source files checked in then it means @Provider in the jdk.depconfig file. I don't think we have any cases like that yet but it will require the META-INF/services to be present in order for the class analyzer to generate the "provides service ..." in the module declaration. -Alan From paul.sandoz at oracle.com Wed May 30 09:04:38 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 30 May 2012 18:04:38 +0200 Subject: Patch for audi/midi services Re: Audio/Midi services Fwd: CR 7172234 Created, P2 java/jigsaw Lot of sound test failed due UnsatisfiedLinkError for com.sun.media.sound.* classes In-Reply-To: <4FC64240.8010305@oracle.com> References: <1132073.1338214278338.JavaMail.sbladm@swsblss4-new.central.sun.com> <95506678-30E3-47B6-B9A7-EA1F63DFB047@oracle.com> <3791C0A8-130E-4D99-870F-BD1E91ECF85C@oracle.com> <4FC64240.8010305@oracle.com> Message-ID: <2F44DDDC-DF4E-4CA1-A299-97E3F2E7D2F7@oracle.com> On May 30, 2012, at 5:52 PM, Alan Bateman wrote: > On 30/05/2012 15:41, Paul Sandoz wrote: >> : >> >> It seems the pattern in jdk.depconfig is to always use optional, so i kept it like that, but since there are always services for the audi/midi cases, we don't need it to be optional, correct? >> > Most (perhaps all) usages of ServiceLoader in the JDK also have a fallback to a default implementation when there aren't any service providers (service implementations) installed. So assuming this is how it specified then then "requires optional service ..." is right. > Without a deeper look at the code and JavaDoc i cannot completely tell. So optional seems like the right choice for now. > I'm not familiar with the JavaSound API. If the specification requires that there be at least one service provider then the module declaration should be "requires service ..." and the resolver will fail with " No implementations of service .." if there aren't any implementations. As we don't have the module-info source files checked in then it means @Provider in the jdk.depconfig file. I don't think we have any cases like that yet but it will require the META-INF/services to be present in order for the class analyzer to generate the "provides service ..." in the module declaration. > Yes, all the midi/sound requires/provides in the desktop module are generated as i would expect. Paul. From mandy.chung at oracle.com Wed May 30 10:15:05 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 30 May 2012 10:15:05 -0700 Subject: Patch for audi/midi services Re: Audio/Midi services Fwd: CR 7172234 Created, P2 java/jigsaw Lot of sound test failed due UnsatisfiedLinkError for com.sun.media.sound.* classes In-Reply-To: <3791C0A8-130E-4D99-870F-BD1E91ECF85C@oracle.com> References: <1132073.1338214278338.JavaMail.sbladm@swsblss4-new.central.sun.com> <95506678-30E3-47B6-B9A7-EA1F63DFB047@oracle.com> <3791C0A8-130E-4D99-870F-BD1E91ECF85C@oracle.com> Message-ID: <4FC65599.80700@oracle.com> On 5/30/2012 7:41 AM, Paul Sandoz wrote: > It seems the pattern in jdk.depconfig is to always use optional, so i kept it like that, but since there are always services for the audi/midi cases, we don't need it to be optional, correct? I scanned on javax.sound.midi.MidiSystem and looked at the javadoc for MidiSystem.getMidiDevice. It throws MidiUnavailableException if not available. It seems to me that these are optional services and JDK does ship its default. It's fine to keep them as optional and we should confirm with the client team once they review the module-info. > Paul. > > $ hg diff > diff -r 68564a2f4750 make/modules/jdk.depconfig > --- a/make/modules/jdk.depconfig Wed May 30 13:00:52 2012 +0100 > +++ b/make/modules/jdk.depconfig Wed May 30 16:36:43 2012 +0200 > @@ -542,3 +542,27 @@ > @Provider(optional) > javax.xml.soap.SOAPFactory -> META-INF/services/javax.xml.soap.SOAPFactory > > + at Provider(optional) > + javax.sound.midi.spi.MidiDeviceProvider -> META-INF/services/javax.sound.midi.spi.MidiDeviceProvider > + > + at Provider(optional) > + javax.sound.midi.spi.MidiFileReader -> META-INF/services/javax.sound.midi.spi.MidiFileReader > + > + at Provider(optional) > + javax.sound.midi.spi.MidiFileWriter -> META-INF/services/javax.sound.midi.spi.MidiFileWriter > + > + at Provider(optional) > + javax.sound.midi.spi.SoundbankReader -> META-INF/services/javax.sound.midi.spi.SoundbankReader > + > + at Provider(optional) > + javax.sound.sampled.spi.AudioFileReader -> META-INF/services/javax.sound.sampled.spi.AudioFileReader > + > + at Provider(optional) > + javax.sound.sampled.spi.AudioFileWriter -> META-INF/services/javax.sound.sampled.spi.AudioFileWriter > + > + at Provider(optional) > + javax.sound.sampled.spi.FormatConversionProvider -> META-INF/services/javax.sound.sampled.spi.FormatConversionProvider > + > + at Provider(optional) > + javax.sound.sampled.spi.MixerProvider -> META-INF/services/javax.sound.sampled.spi.MixerProvider > + Looks good. I will push this patch for you.Sorry for missing them and there may not have jdk regression tests uncovering this problem. There are two more service configuration files for JAXWS that are not listed in jdk.depconfig. Do you mind taking a look at them and maybe already be covered in the JAXWS modularization effort? META-INF/services/com.sun.tools.internal.ws.wscompile.Plugin META-INF/services/com.sun.tools.internal.xjc.Plugin Thanks Mandy From mandy.chung at oracle.com Wed May 30 10:54:17 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 30 May 2012 10:54:17 -0700 Subject: RFR: Try to install already installed jmod/modular jar issue In-Reply-To: <4FC53566.80703@oracle.com> References: <4FC53566.80703@oracle.com> Message-ID: <4FC65EC9.1020003@oracle.com> On 5/29/2012 1:45 PM, Chris Hegarty wrote: > Trivial issue that crept in whereby if you try to install an already > installed module it will actually remove it! > > If a module is already installed ( or there is a view or alias with a > similar name ) the addition to the module directory will fail. The > error handling code incorrectly assumes that the requested module > should be removed. > > Trivial change to only attempt removal after the addition to the > module directory has succeeded, i.e. only if there has been a change > to the actual library or meta data. > > http://cr.openjdk.java.net/~chegar/jigsaw/doubleInstall_webrev.00/webrev/ Thanks for catching this issue and adding a test case is good. Looks fine to me. Nit: SimpleLibrary.java L1163 - missing space before '='. Mandy From paul.sandoz at oracle.com Wed May 30 23:32:53 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 31 May 2012 08:32:53 +0200 Subject: Patch for audi/midi services Re: Audio/Midi services Fwd: CR 7172234 Created, P2 java/jigsaw Lot of sound test failed due UnsatisfiedLinkError for com.sun.media.sound.* classes In-Reply-To: <4FC65599.80700@oracle.com> References: <1132073.1338214278338.JavaMail.sbladm@swsblss4-new.central.sun.com> <95506678-30E3-47B6-B9A7-EA1F63DFB047@oracle.com> <3791C0A8-130E-4D99-870F-BD1E91ECF85C@oracle.com> <4FC65599.80700@oracle.com> Message-ID: <9D2DCF82-A0D8-4AD6-9D8A-5421C57ABDE9@oracle.com> On May 30, 2012, at 7:15 PM, Mandy Chung wrote: > On 5/30/2012 7:41 AM, Paul Sandoz wrote: >> It seems the pattern in jdk.depconfig is to always use optional, so i kept it like that, but since there are always services for the audi/midi cases, we don't need it to be optional, correct? > > I scanned on javax.sound.midi.MidiSystem and looked at the javadoc for MidiSystem.getMidiDevice. It throws MidiUnavailableException if not available. It seems to me that these are optional services and JDK does ship its default. It's fine to keep them as optional and we should confirm with the client team once they review the module-info. > OK. >> + at Provider(optional) >> + javax.sound.sampled.spi.MixerProvider -> META-INF/services/javax.sound.sampled.spi.MixerProvider >> + > > Looks good. I will push this patch for you. Thanks. > Sorry for missing them and there may not have jdk regression tests uncovering this problem. > No need to apologize! After routing around a little bit in the internals of the JDK i appreciate just how big this is collection of software is. Easy to miss stuff. > There are two more service configuration files for JAXWS that are not listed in jdk.depconfig. Do you mind taking a look at them and maybe already be covered in the JAXWS modularization effort? > Will do. > META-INF/services/com.sun.tools.internal.ws.wscompile.Plugin > META-INF/services/com.sun.tools.internal.xjc.Plugin > I did look at bit at these with the JAX-WS team. At the time we were unsure how the tooling would work with annotation processors (APs), so we left this are alone. Subsequently we checked that the jaxb/jax-ws tooling explicitly registered an AP so the tools should be OK in module mode. I will double check with the JAX-WS team but i think we can declare these services in the jdk.tools.jaxws module. Later we will most likely need to separate into JAX-WS and JAXB tool modules. Paul. From chris.hegarty at oracle.com Thu May 31 00:08:08 2012 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Thu, 31 May 2012 07:08:08 +0000 Subject: hg: jigsaw/jigsaw/jdk: Install of already installed module file incorrectly removes Message-ID: <20120531070836.4788647642@hg.openjdk.java.net> Changeset: 82cfb0e749f4 Author: chegar Date: 2012-05-31 08:07 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/82cfb0e749f4 Install of already installed module file incorrectly removes Reviewed-by: alanb, mchung ! src/share/classes/org/openjdk/jigsaw/SimpleLibrary.java ! test/org/openjdk/jigsaw/cli/jmod-basic.sh From artem.ananiev at oracle.com Thu May 31 03:16:03 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 31 May 2012 14:16:03 +0400 Subject: Patch for audi/midi services Re: Audio/Midi services Fwd: CR 7172234 Created, P2 java/jigsaw Lot of sound test failed due UnsatisfiedLinkError for com.sun.media.sound.* classes In-Reply-To: <4FC65599.80700@oracle.com> References: <1132073.1338214278338.JavaMail.sbladm@swsblss4-new.central.sun.com> <95506678-30E3-47B6-B9A7-EA1F63DFB047@oracle.com> <3791C0A8-130E-4D99-870F-BD1E91ECF85C@oracle.com> <4FC65599.80700@oracle.com> Message-ID: <4FC744E3.3000707@oracle.com> On 5/30/2012 9:15 PM, Mandy Chung wrote: > On 5/30/2012 7:41 AM, Paul Sandoz wrote: >> It seems the pattern in jdk.depconfig is to always use optional, so i >> kept it like that, but since there are always services for the >> audi/midi cases, we don't need it to be optional, correct? > > I scanned on javax.sound.midi.MidiSystem and looked at the javadoc for > MidiSystem.getMidiDevice. It throws MidiUnavailableException if not > available. It seems to me that these are optional services and JDK does > ship its default. It's fine to keep them as optional and we should > confirm with the client team once they review the module-info. I'm just subscribed to this mailing list, and don't quite understand the patch, so my comments may look really lame... Right now JDK provides default implementations of some JavaSound services, but strictly speaking it's not forced by JavaSound APIs: there may be no service providers by default. Thanks, Artem >> Paul. >> >> $ hg diff >> diff -r 68564a2f4750 make/modules/jdk.depconfig >> --- a/make/modules/jdk.depconfig Wed May 30 13:00:52 2012 +0100 >> +++ b/make/modules/jdk.depconfig Wed May 30 16:36:43 2012 +0200 >> @@ -542,3 +542,27 @@ >> @Provider(optional) >> javax.xml.soap.SOAPFactory -> >> META-INF/services/javax.xml.soap.SOAPFactory >> >> + at Provider(optional) >> + javax.sound.midi.spi.MidiDeviceProvider -> >> META-INF/services/javax.sound.midi.spi.MidiDeviceProvider >> + >> + at Provider(optional) >> + javax.sound.midi.spi.MidiFileReader -> >> META-INF/services/javax.sound.midi.spi.MidiFileReader >> + >> + at Provider(optional) >> + javax.sound.midi.spi.MidiFileWriter -> >> META-INF/services/javax.sound.midi.spi.MidiFileWriter >> + >> + at Provider(optional) >> + javax.sound.midi.spi.SoundbankReader -> >> META-INF/services/javax.sound.midi.spi.SoundbankReader >> + >> + at Provider(optional) >> + javax.sound.sampled.spi.AudioFileReader -> >> META-INF/services/javax.sound.sampled.spi.AudioFileReader >> + >> + at Provider(optional) >> + javax.sound.sampled.spi.AudioFileWriter -> >> META-INF/services/javax.sound.sampled.spi.AudioFileWriter >> + >> + at Provider(optional) >> + javax.sound.sampled.spi.FormatConversionProvider -> >> META-INF/services/javax.sound.sampled.spi.FormatConversionProvider >> + >> + at Provider(optional) >> + javax.sound.sampled.spi.MixerProvider -> >> META-INF/services/javax.sound.sampled.spi.MixerProvider >> + > > Looks good. I will push this patch for you.Sorry for missing them and > there may not have jdk regression tests uncovering this problem. > > There are two more service configuration files for JAXWS that are not > listed in jdk.depconfig. Do you mind taking a look at them and maybe > already be covered in the JAXWS modularization effort? > > META-INF/services/com.sun.tools.internal.ws.wscompile.Plugin > META-INF/services/com.sun.tools.internal.xjc.Plugin > > Thanks > Mandy From Alan.Bateman at oracle.com Thu May 31 06:16:45 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 31 May 2012 14:16:45 +0100 Subject: Patch for audi/midi services Re: Audio/Midi services Fwd: CR 7172234 Created, P2 java/jigsaw Lot of sound test failed due UnsatisfiedLinkError for com.sun.media.sound.* classes In-Reply-To: <4FC744E3.3000707@oracle.com> References: <1132073.1338214278338.JavaMail.sbladm@swsblss4-new.central.sun.com> <95506678-30E3-47B6-B9A7-EA1F63DFB047@oracle.com> <3791C0A8-130E-4D99-870F-BD1E91ECF85C@oracle.com> <4FC65599.80700@oracle.com> <4FC744E3.3000707@oracle.com> Message-ID: <4FC76F3D.9090503@oracle.com> On 31/05/2012 11:16, Artem Ananiev wrote: > > I'm just subscribed to this mailing list, and don't quite understand > the patch, so my comments may look really lame... Right now JDK > provides default implementations of some JavaSound services, but > strictly speaking it's not forced by JavaSound APIs: there may be no > service providers by default. Thanks Artem, in that case "optional" is correct. (As background, we don't have the module-info source files checked in yet, they are generated during the build yet. These configuration files that you see us editing are by a tool that is run in the build to generate them - this will eventually go away). -Alan From mandy.chung at oracle.com Thu May 31 09:25:45 2012 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 31 May 2012 16:25:45 +0000 Subject: hg: jigsaw/jigsaw/jdk: 2 new changesets Message-ID: <20120531162624.433B34764C@hg.openjdk.java.net> Changeset: cae9047d08c3 Author: Paul Sandoz Date: 2012-05-31 16:49 +0200 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/cae9047d08c3 Add audio and midi related services ! make/modules/jdk.depconfig Changeset: 3607a27a6d18 Author: mchung Date: 2012-05-31 09:25 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/3607a27a6d18 Merge