From debasish.raychawdhuri at gmail.com Thu Aug 15 21:14:58 2013 From: debasish.raychawdhuri at gmail.com (Debasish Chawdhuri) Date: Fri, 16 Aug 2013 04:14:58 +0000 (UTC) Subject: Invitation to connect on LinkedIn Message-ID: <39780193.184318241.1376626498280.JavaMail.app@ela4-app0129.prod> LinkedIn ------------ I'd like to add you to my professional network on LinkedIn. - Debasish Debasish Chawdhuri Senior Software Engineer at Oracle India Pvt. Ltd. New Delhi Area, India Confirm that you know Debasish Chawdhuri: https://www.linkedin.com/e/-dlabpt-hkevvg7c-2i/isd/15820581119/Gkvpuzaj/?hs=false&tok=2TRFhF7zIu65U1 -- You are receiving Invitation to Connect emails. Click to unsubscribe: http://www.linkedin.com/e/-dlabpt-hkevvg7c-2i/q38x6Mjwga2JGXHF1_8fc1Ddg6ZCdUFzVjrx7p73bC/goo/jigsaw-dev%40openjdk%2Ejava%2Enet/20061/I5263387843_1/?hs=false&tok=2b29f2lZMu65U1 (c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA. From mark.reinhold at oracle.com Wed Aug 28 09:27:51 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 28 Aug 2013 09:27:51 -0700 Subject: Jigsaw prototype, take 2 Message-ID: <20130828092751.449385@eggemoggin.niobe.net> I've created a new forest, http://hg.openjdk.java.net/jigsaw/jake, where we're going to explore a simplified approach to achieving the goals of this Project. To start, it's just a clone of the current JDK 8 master. Among other things, we're going to see whether we can get away without introducing a distinct "module mode" as we have in the current prototype (which is incompatible, in some narrow yet deep ways, with long-standing behavior) and without doing dependence resolution (since build tools like Maven, Ivy, and Gradle already do that well enough). We remain committed, of course, to this Project's high-level goals: Create a modular and scalable platform, improve performance and security, and define a standard module system. As we work on this new prototype we'll take code from the old one where that makes sense, but we'll also take the opportunity to question earlier design decisions and generally clean things up. I urge onlookers to remember that this is just another prototype. It is likely to evolve swiftly. Its shape and content at any given point in time should not be treated as having any particular bearing on the final result of this Project. - Mark From mark.reinhold at oracle.com Wed Aug 28 09:34:45 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 28 Aug 2013 16:34:45 +0000 Subject: hg: jigsaw/jake/jdk: Laxify jcheck Message-ID: <20130828163546.43EB162367@hg.openjdk.java.net> Changeset: fcbdbe8bd2da Author: mr Date: 2013-08-28 08:49 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fcbdbe8bd2da Laxify jcheck ! .jcheck/conf From mark.reinhold at oracle.com Wed Aug 28 09:37:48 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 28 Aug 2013 16:37:48 +0000 Subject: hg: jigsaw/jake/jdk: jdk.jigsaw.module + unit tests Message-ID: <20130828163831.1AC9C62368@hg.openjdk.java.net> Changeset: a242b5ce121f Author: mr Date: 2013-08-28 09:37 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a242b5ce121f jdk.jigsaw.module + unit tests + src/share/classes/jdk/jigsaw/module/Dependence.java + src/share/classes/jdk/jigsaw/module/Module.java + src/share/classes/jdk/jigsaw/module/ServiceDependence.java + src/share/classes/jdk/jigsaw/module/Version.java + src/share/classes/jdk/jigsaw/module/VersionQuery.java + src/share/classes/jdk/jigsaw/module/View.java + src/share/classes/jdk/jigsaw/module/ViewDependence.java + src/share/classes/jdk/jigsaw/module/ViewId.java + src/share/classes/jdk/jigsaw/module/ViewIdQuery.java + src/share/classes/jdk/jigsaw/module/package-info.java + test/jdk/jigsaw/module/Serial.java + test/jdk/jigsaw/module/TEST.properties + test/jdk/jigsaw/module/_Module.java + test/jdk/jigsaw/module/_ServiceDependence.java + test/jdk/jigsaw/module/_View.java + test/jdk/jigsaw/module/_ViewDependence.java From mark.reinhold at oracle.com Wed Aug 28 11:00:29 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 28 Aug 2013 18:00:29 +0000 Subject: hg: jigsaw/jake/jdk: Enforce constraint: Every package exported by a view must be in that view's module Message-ID: <20130828180052.978A562377@hg.openjdk.java.net> Changeset: 24e8bacfd6fe Author: mr Date: 2013-08-28 11:00 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/24e8bacfd6fe Enforce constraint: Every package exported by a view must be in that view's module ! src/share/classes/jdk/jigsaw/module/Module.java ! test/jdk/jigsaw/module/_Module.java ! test/jdk/jigsaw/module/_View.java From mark.reinhold at oracle.com Wed Aug 28 16:31:57 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 28 Aug 2013 23:31:57 +0000 Subject: hg: jigsaw/jake/jdk: jdk.joptsimple Message-ID: <20130828233236.5DF096238B@hg.openjdk.java.net> Changeset: 3bd5eb5a545f Author: mr Date: 2013-08-28 16:31 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3bd5eb5a545f jdk.joptsimple + src/share/classes/jdk/joptsimple/AbstractOptionSpec.java + src/share/classes/jdk/joptsimple/AlternativeLongOptionSpec.java + src/share/classes/jdk/joptsimple/ArgumentAcceptingOptionSpec.java + src/share/classes/jdk/joptsimple/ArgumentList.java + src/share/classes/jdk/joptsimple/HelpFormatter.java + src/share/classes/jdk/joptsimple/IllegalOptionClusterException.java + src/share/classes/jdk/joptsimple/IllegalOptionSpecificationException.java + src/share/classes/jdk/joptsimple/MultipleArgumentsForOptionException.java + src/share/classes/jdk/joptsimple/NoArgumentOptionSpec.java + src/share/classes/jdk/joptsimple/OptionArgumentConversionException.java + src/share/classes/jdk/joptsimple/OptionException.java + src/share/classes/jdk/joptsimple/OptionMissingRequiredArgumentException.java + src/share/classes/jdk/joptsimple/OptionParser.java + src/share/classes/jdk/joptsimple/OptionParserState.java + src/share/classes/jdk/joptsimple/OptionSet.java + src/share/classes/jdk/joptsimple/OptionSpec.java + src/share/classes/jdk/joptsimple/OptionSpecBuilder.java + src/share/classes/jdk/joptsimple/OptionSpecTokenizer.java + src/share/classes/jdk/joptsimple/OptionSpecVisitor.java + src/share/classes/jdk/joptsimple/OptionalArgumentOptionSpec.java + src/share/classes/jdk/joptsimple/ParserRules.java + src/share/classes/jdk/joptsimple/RequiredArgumentOptionSpec.java + src/share/classes/jdk/joptsimple/UnrecognizedOptionException.java + src/share/classes/jdk/joptsimple/internal/AbbreviationMap.java + src/share/classes/jdk/joptsimple/internal/Classes.java + src/share/classes/jdk/joptsimple/internal/Column.java + src/share/classes/jdk/joptsimple/internal/ColumnWidthCalculator.java + src/share/classes/jdk/joptsimple/internal/ColumnarData.java + src/share/classes/jdk/joptsimple/internal/Reflection.java + src/share/classes/jdk/joptsimple/internal/ReflectionException.java + src/share/classes/jdk/joptsimple/internal/Strings.java + src/share/classes/jdk/joptsimple/internal/ValueConverter.java + src/share/classes/jdk/joptsimple/util/KeyValuePair.java From jaroslav.tulach at oracle.com Wed Aug 28 18:59:46 2013 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Thu, 29 Aug 2013 03:59:46 +0200 Subject: hg: jigsaw/jake/jdk: jdk.joptsimple In-Reply-To: <20130828233236.5DF096238B@hg.openjdk.java.net> References: <20130828233236.5DF096238B@hg.openjdk.java.net> Message-ID: <2267303.N67mQZtL2C@logouticek> Hello. Dne St 28. srpna 2013 23:31:57, mark.reinhold at oracle.com napsal(a): > Changeset: 3bd5eb5a545f > Author: mr > Date: 2013-08-28 16:31 -0700 > URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3bd5eb5a545f > > jdk.joptsimple > > + src/share/classes/jdk/joptsimple/AbstractOptionSpec.java > + src/share/classes/jdk/joptsimple/AlternativeLongOptionSpec.java > + src/share/classes/jdk/joptsimple/ArgumentAcceptingOptionSpec.java > + src/share/classes/jdk/joptsimple/ArgumentList.java > + src/share/classes/jdk/joptsimple/HelpFormatter.java > + src/share/classes/jdk/joptsimple/IllegalOptionClusterException.java > + src/share/classes/jdk/joptsimple/IllegalOptionSpecificationException.java > + src/share/classes/jdk/joptsimple/MultipleArgumentsForOptionException.java > + src/share/classes/jdk/joptsimple/NoArgumentOptionSpec.java > + src/share/classes/jdk/joptsimple/OptionArgumentConversionException.java > + src/share/classes/jdk/joptsimple/OptionException.java Seems the kind of utility everyone has to write once from scratch, right? I did it as well as it seemed no existing parser matches our needs. NetBeans offers standalone, modular, ServiceLoader based, declarative, POSIX complient approach for parsing command line arguments in a single JAR API: http://bits.netbeans.org/dev/javadoc/org-netbeans-modules-sendopts/overview-summary.html available from NetBeans maven repository: http://bits.netbeans.org/maven2/ http://bits.netbeans.org/nexus/content/groups/netbeans/org/netbeans/api/org-netbeans-modules-sendopts/ and easily usable outside of the NetBeans Platform. FYI only. -jt > + > src/share/classes/jdk/joptsimple/OptionMissingRequiredArgumentException.jav > a + src/share/classes/jdk/joptsimple/OptionParser.java > + src/share/classes/jdk/joptsimple/OptionParserState.java > + src/share/classes/jdk/joptsimple/OptionSet.java > + src/share/classes/jdk/joptsimple/OptionSpec.java > + src/share/classes/jdk/joptsimple/OptionSpecBuilder.java > + src/share/classes/jdk/joptsimple/OptionSpecTokenizer.java > + src/share/classes/jdk/joptsimple/OptionSpecVisitor.java > + src/share/classes/jdk/joptsimple/OptionalArgumentOptionSpec.java > + src/share/classes/jdk/joptsimple/ParserRules.java > + src/share/classes/jdk/joptsimple/RequiredArgumentOptionSpec.java > + src/share/classes/jdk/joptsimple/UnrecognizedOptionException.java > + src/share/classes/jdk/joptsimple/internal/AbbreviationMap.java > + src/share/classes/jdk/joptsimple/internal/Classes.java > + src/share/classes/jdk/joptsimple/internal/Column.java > + src/share/classes/jdk/joptsimple/internal/ColumnWidthCalculator.java > + src/share/classes/jdk/joptsimple/internal/ColumnarData.java > + src/share/classes/jdk/joptsimple/internal/Reflection.java > + src/share/classes/jdk/joptsimple/internal/ReflectionException.java > + src/share/classes/jdk/joptsimple/internal/Strings.java > + src/share/classes/jdk/joptsimple/internal/ValueConverter.java > + src/share/classes/jdk/joptsimple/util/KeyValuePair.java From niftiness at gmail.com Wed Aug 28 22:50:28 2013 From: niftiness at gmail.com (Tim Boudreau) Date: Thu, 29 Aug 2013 01:50:28 -0400 Subject: Jigsaw prototype, take 2 In-Reply-To: <20130828092751.449385@eggemoggin.niobe.net> References: <20130828092751.449385@eggemoggin.niobe.net> Message-ID: On Wed, Aug 28, 2013 at 12:27 PM, wrote: > I've created a new forest, http://hg.openjdk.java.net/jigsaw/jake, where > we're going to explore a simplified approach to achieving the goals of > this Project. Simplified how? -Tim -- http://timboudreau.com From mark.reinhold at oracle.com Thu Aug 29 07:35:58 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 29 Aug 2013 07:35:58 -0700 Subject: hg: jigsaw/jake/jdk: jdk.joptsimple In-Reply-To: <2267303.N67mQZtL2C@logouticek> References: <20130828233236.5DF096238B@hg.openjdk.java.net>, <2267303.N67mQZtL2C@logouticek> Message-ID: <20130829073558.626029@eggemoggin.niobe.net> 2013/8/28 11:59 -0700, jaroslav.tulach at oracle.com: > Seems the kind of utility everyone has to write once from scratch, right? I > did it as well as it seemed no existing parser matches our needs. Yes. We didn't write joptsimple; it was written by Paul Holser [1]. It's not perfect, but it's better than all the others I surveyed a couple of years ago. > NetBeans offers standalone, modular, ServiceLoader based, declarative, POSIX > complient approach for parsing command line arguments in a single JAR API: ... I didn't know this -- thanks for pointing it out. I'll take a look. - Mark [1] http://pholser.github.io/jopt-simple/ From chris.hegarty at oracle.com Thu Aug 29 09:32:36 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Thu, 29 Aug 2013 16:32:36 +0000 Subject: hg: jigsaw/jake/jdk: 8023460: OPENJDK build fails due to missing jfr.jar Message-ID: <20130829163318.3F3CC623B8@hg.openjdk.java.net> Changeset: c442171f1d17 Author: dholmes Date: 2013-08-21 05:56 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c442171f1d17 8023460: OPENJDK build fails due to missing jfr.jar Reviewed-by: alanb ! makefiles/Profiles.gmk From eric at tibco.com Thu Aug 29 09:55:13 2013 From: eric at tibco.com (Eric Johnson) Date: Thu, 29 Aug 2013 09:55:13 -0700 Subject: Jigsaw prototype, take 2 In-Reply-To: <20130828092751.449385@eggemoggin.niobe.net> References: <20130828092751.449385@eggemoggin.niobe.net> Message-ID: <521F7CF1.8030904@tibco.com> Hi Mark, On 8/28/13 9:27 AM, mark.reinhold at oracle.com wrote: > We remain committed, of course, to this Project's high-level goals: > Create a modular and scalable platform, improve performance and security, > and define a standard module system. Repeating the same thing over again, and expecting a different result? I'm all for modularizing Java. I'm struggling with the other goals: Improving security: Certainly, we don't want modularization to weaken security, but why is necessary for improved security to be a part of the Jigsaw project? It should be treated as a separate concern (which it is). On top of that, improving security implies a well understood threat model, vulnerabilities, and risks. Since Java is run in so many different places - secured networks, insecure networks, mobile devices, desktop/laptop machines, and via applets, the considerations for each might be radically different. Deserves more careful consideration than as an add-on goal to a modularization project. Only insofar as a modular JRE could exclude all sorts of unneeded/unwanted pieces from particular profiles, that is by definition improved security for downstream deployers, but that's a side-effect of modularity, not a specific goal. Of course it may be a side-effect informed by security considerations (for example, remove JMX, JDBC, CORBA, and applet support from a mobile device), but it isn't, by itself a more secure platform. That's because there will still be deployments that need everything, and modularization by itself won't have changed a thing. Improve performance: Again, modularization shouldn't lose performance. Don't see why it would be an explicit goal to improve performance. As a colleague of mine says, "first get it right, then make it work, then make it fast." Seems like you're jumping ahead to step three with this goal. Define a standard module system: Why? One way of leveraging a modular Java means taking the existing JRE, repackaging it, and removing unwanted parts. That's a building/packaging exercise, and has no run-time implications. So why define a module system? Java already has a standard way to "modularize" a build, via these well known artifacts called "JAR" files. Eric. From jeffmaury at jeffmaury.com Thu Aug 29 12:50:23 2013 From: jeffmaury at jeffmaury.com (Jeff MAURY) Date: Thu, 29 Aug 2013 21:50:23 +0200 Subject: hg: jigsaw/jake/jdk: jdk.joptsimple In-Reply-To: <20130829073558.626029@eggemoggin.niobe.net> References: <20130828233236.5DF096238B@hg.openjdk.java.net> <2267303.N67mQZtL2C@logouticek> <20130829073558.626029@eggemoggin.niobe.net> Message-ID: Did you have a look at JCommander: http://jcommander.org/ Jeff On Thu, Aug 29, 2013 at 4:35 PM, wrote: > 2013/8/28 11:59 -0700, jaroslav.tulach at oracle.com: > > Seems the kind of utility everyone has to write once from scratch, > right? I > > did it as well as it seemed no existing parser matches our needs. > > Yes. We didn't write joptsimple; it was written by Paul Holser [1]. > It's not perfect, but it's better than all the others I surveyed a > couple of years ago. > > > NetBeans offers standalone, modular, ServiceLoader based, declarative, > POSIX > > complient approach for parsing command line arguments in a single JAR > API: ... > > I didn't know this -- thanks for pointing it out. I'll take a look. > > - Mark > > > [1] http://pholser.github.io/jopt-simple/ > -- Jeff MAURY "Legacy code" often differs from its suggested alternative by actually working and scaling. - Bjarne Stroustrup http://www.jeffmaury.com http://riadiscuss.jeffmaury.com http://www.twitter.com/jeffmaury From loskutov at gmx.de Thu Aug 29 13:33:54 2013 From: loskutov at gmx.de (Andrey Loskutov) Date: Thu, 29 Aug 2013 22:33:54 +0200 Subject: Jigsaw prototype, take 2 In-Reply-To: References: Message-ID: On 8/28/13 9:27 AM, mark.reinhold at oracle.com wrote: > We remain committed, of course, to this Project's high-level goals: > Create a modular and scalable platform, improve performance and security, > and define a standard module system. [...] > but we'll also take the opportunity to question earlier > design decisions and generally clean things up. Hi Mark, Might be *now* it's time to look back on existing standards (jar files + OSGI) as an option? Take a chance to "unite" the modularization systems in Java. -- Kind regards, Andrey Loskutov +Andrey: http://plus.google.com/u/0/113794713998126448910 From mark.reinhold at oracle.com Thu Aug 29 13:39:45 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 29 Aug 2013 13:39:45 -0700 Subject: hg: jigsaw/jake/jdk: jdk.joptsimple In-Reply-To: References: <20130828233236.5DF096238B@hg.openjdk.java.net>, <2267303.N67mQZtL2C@logouticek>, <20130829073558.626029@eggemoggin.niobe.net>, Message-ID: <20130829133945.800722@eggemoggin.niobe.net> 2013/8/29 5:50 -0700, jeffmaury at jeffmaury.com: > Did you have a look at JCommander: http://jcommander.org/ Yes. Seemed like overkill, if I recall correctly. - Mark From mandy.chung at oracle.com Thu Aug 29 14:43:04 2013 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 29 Aug 2013 21:43:04 +0000 Subject: hg: jigsaw/jake: Compile modules.{config,group} into serialized form Message-ID: <20130829214304.4BD1B623F7@hg.openjdk.java.net> Changeset: 3945cae520ac Author: mchung Date: 2013-08-29 14:39 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/3945cae520ac Compile modules.{config,group} into serialized form ! .jcheck/conf ! common/autoconf/boot-jdk.m4 ! common/autoconf/configure.ac ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in From mandy.chung at oracle.com Thu Aug 29 14:42:07 2013 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 29 Aug 2013 21:42:07 +0000 Subject: hg: jigsaw/jake/jdk: Compile modules.{config, group} into serialized form Message-ID: <20130829214234.0B120623F6@hg.openjdk.java.net> Changeset: 6bf99c2519a3 Author: mchung Date: 2013-08-29 14:37 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6bf99c2519a3 Compile modules.{config,group} into serialized form + make/modules/modules.config + make/modules/modules.group + make/modules/modules.properties + make/modules/tools/src/com/sun/tools/classanalyzer/ClassAnalyzer.java + make/modules/tools/src/com/sun/tools/classanalyzer/ClassFileReader.java + make/modules/tools/src/com/sun/tools/classanalyzer/ClassPath.java + make/modules/tools/src/com/sun/tools/classanalyzer/Dependence.java + make/modules/tools/src/com/sun/tools/classanalyzer/JigsawModules.java + make/modules/tools/src/com/sun/tools/classanalyzer/Klass.java + make/modules/tools/src/com/sun/tools/classanalyzer/Module.java + make/modules/tools/src/com/sun/tools/classanalyzer/ModuleBuilder.java + make/modules/tools/src/com/sun/tools/classanalyzer/ModuleConfig.java + make/modules/tools/src/com/sun/tools/classanalyzer/Package.java + make/modules/tools/src/com/sun/tools/classanalyzer/Resource.java + make/modules/tools/src/com/sun/tools/classanalyzer/Service.java + make/modules/tools/src/com/sun/tools/classanalyzer/filelist + make/modules/tools/src/com/sun/tools/classanalyzer/resources/classanalyzer.properties ! makefiles/BuildJdk.gmk + makefiles/GenerateModules.gmk + makefiles/ModulesCommon.gmk ! makefiles/profile-rtjar-includes.txt + test/jdk/jigsaw/module/JdkModules.java From mark.reinhold at oracle.com Thu Aug 29 20:55:25 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 29 Aug 2013 20:55:25 -0700 Subject: Jigsaw prototype, take 2 In-Reply-To: References: <20130828092751.449385@eggemoggin.niobe.net>, Message-ID: <20130829205525.391421@eggemoggin.niobe.net> 2013/8/28 15:50 -0700, Tim Boudreau : > On Wed, Aug 28, 2013 at 12:27 PM, wrote: >> I've created a new forest, http://hg.openjdk.java.net/jigsaw/jake, where >> we're going to explore a simplified approach to achieving the goals of >> this Project. > > Simplified how? That's partly answered in the very next paragraph: Among other things, we're going to see whether we can get away without introducing a distinct "module mode" as we have in the current prototype (which is incompatible, in some narrow yet deep ways, with long-standing behavior) and without doing dependence resolution (since build tools like Maven, Ivy, and Gradle already do that well enough). That is, I admit, somewhat cryptic. I'm writing up a longer note that will explain the background and the new approach in more detail. - Mark From tangyong at cn.fujitsu.com Thu Aug 29 20:58:46 2013 From: tangyong at cn.fujitsu.com (Tang Yong) Date: Fri, 30 Aug 2013 12:58:46 +0900 Subject: Jigsaw prototype, take 2 In-Reply-To: <20130829205525.391421@eggemoggin.niobe.net> References: <20130828092751.449385@eggemoggin.niobe.net>, <20130829205525.391421@eggemoggin.niobe.net> Message-ID: <52201876.4060605@cn.fujitsu.com> > That is, I admit, somewhat cryptic. I'm writing up a longer note that > will explain the background and the new approach in more detail. Looking forward to seeing the note very much! Best Regard! Tang mark.reinhold at oracle.com wrote: > 2013/8/28 15:50 -0700, Tim Boudreau : >> On Wed, Aug 28, 2013 at 12:27 PM, wrote: >>> I've created a new forest, http://hg.openjdk.java.net/jigsaw/jake, where >>> we're going to explore a simplified approach to achieving the goals of >>> this Project. >> Simplified how? > > That's partly answered in the very next paragraph: > > Among other things, we're going to see whether we can get away without > introducing a distinct "module mode" as we have in the current prototype > (which is incompatible, in some narrow yet deep ways, with long-standing > behavior) and without doing dependence resolution (since build tools like > Maven, Ivy, and Gradle already do that well enough). > > That is, I admit, somewhat cryptic. I'm writing up a longer note that > will explain the background and the new approach in more detail. > > - Mark > > -- ?????????????????????? Tang Yong Senior Engineer GlassFish Committer (OSGi & OSGi-JavaEE) OSGi Alliance Supporter Blog: http://osgizone.typepad.com/tangyong/ Nanjing Fujitsu NanDa Software Tec CO.,LTD http://www.fujitsu.com/cn/fnst Tel: +86-25-86630566-8310 Fax: +86-25-83317685?????????????? ?????????????????????? From jaroslav.tulach at oracle.com Fri Aug 30 00:16:40 2013 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Fri, 30 Aug 2013 09:16:40 +0200 Subject: jopt-simple & sendopts was: hg: jigsaw/jake/jdk: jdk.joptsimple In-Reply-To: <20130829073558.626029@eggemoggin.niobe.net> References: <20130828233236.5DF096238B@hg.openjdk.java.net> <2267303.N67mQZtL2C@logouticek> <20130829073558.626029@eggemoggin.niobe.net> Message-ID: <2991211.vRpcI42por@logouticek> Dne ?t 29. srpna 2013 07:35:58, mark.reinhold at oracle.com napsal(a): > 2013/8/28 11:59 -0700, jaroslav.tulach at oracle.com: > > Seems the kind of utility everyone has to write once from scratch, right? > > I > > did it as well as it seemed no existing parser matches our needs. > > Yes. We didn't write joptsimple; it was written by Paul Holser [1]. > It's not perfect, but it's better than all the others I surveyed a > couple of years ago. I see. I got confused by a source being commited into the Hg and considered that an attempt to write CLI parser from scratch. > > NetBeans offers standalone, modular, ServiceLoader based, declarative, > > POSIX complient approach for parsing command line arguments in a single > > JAR API: ... > I didn't know this -- thanks for pointing it out. I'll take a look. SendOpts API[2] benefit could be its modularity support - e.g. various modules contribute its options and the system then verifies overall consistency of a command line and distributes the CLI arguments to appropriate modules. If such composition and decomposition is not needed then [1] looks OK and in certain areas (number format of an argument, for example) more powerful. -jt > [1] http://pholser.github.io/jopt-simple/ [2] http://bits.netbeans.org/dev/javadoc/org-netbeans-modules-sendopts/ From greggwon at cox.net Fri Aug 30 06:48:21 2013 From: greggwon at cox.net (Gregg Wonderly) Date: Fri, 30 Aug 2013 08:48:21 -0500 Subject: Jigsaw prototype, take 2 In-Reply-To: References: <20130828092751.449385@eggemoggin.niobe.net>, Message-ID: <5220A2A5.9010700@cox.net> What I dislike the most about tightly bound modularization systems, is deployment and dependency analysis and "requirements" which create a giant slow down in development because things have to be "structured" in particular ways, in order for thing to meet the "systems" requirements. In particular, I dislike anything which mandates non-circular dependencies and other "structural" requirements. There are all kinds of concerns about not being able to compile separate modules with circular dependencies when you start from nothing but source. That's my problem as a developer to resolve, not a modularization system. .Net has this kind of nonsense deeply ingrained and there are all kinds of separate issues that this creates in and of itself. Java has always supported doing something like mkdir classes javac -d classes `find . -name '*.java'` and then using that 'classes' directory as your classpath for subsequent builds. For super massive source trees, that find could of course, be a filtered, smaller list of interfaces, abstract classes and super classes which have the circular dependency issue. And in fact tools can be used to find such circular dependencies, and to then create the "base.jar" needed to remove the circular dependency issue from the rest of the code base. Please, oh please, let us keep the power of the classpath, the power of dynamic loading, and the flexibility of "roll your own classloader", and focus on providing a meta data approach that allows tools to help organize your needs into the use of the things which are the POWER of Java. Gregg Wonderly On 8/29/2013 10:55 PM, mark.reinhold at oracle.com wrote: > 2013/8/28 15:50 -0700, Tim Boudreau : >> On Wed, Aug 28, 2013 at 12:27 PM, wrote: >>> I've created a new forest, http://hg.openjdk.java.net/jigsaw/jake, where >>> we're going to explore a simplified approach to achieving the goals of >>> this Project. >> Simplified how? > That's partly answered in the very next paragraph: > > Among other things, we're going to see whether we can get away without > introducing a distinct "module mode" as we have in the current prototype > (which is incompatible, in some narrow yet deep ways, with long-standing > behavior) and without doing dependence resolution (since build tools like > Maven, Ivy, and Gradle already do that well enough). > > That is, I admit, somewhat cryptic. I'm writing up a longer note that > will explain the background and the new approach in more detail. > > - Mark > From david.bosschaert at gmail.com Fri Aug 30 07:35:02 2013 From: david.bosschaert at gmail.com (David Bosschaert) Date: Fri, 30 Aug 2013 15:35:02 +0100 Subject: Jigsaw prototype, take 2 In-Reply-To: <20130828092751.449385@eggemoggin.niobe.net> References: <20130828092751.449385@eggemoggin.niobe.net> Message-ID: Hi Mark, My understanding is that JEP 161 (http://openjdk.java.net/jeps/161) already addresses many requirements for modularizing the Java runtime. JEP 161 should address the concerns around creating a scalable platform and improve performance. I would like to understand what requirements in addition to JEP 161 this prototype aims to address. Best regards, David On 28 August 2013 17:27, wrote: > I've created a new forest, http://hg.openjdk.java.net/jigsaw/jake, where > we're going to explore a simplified approach to achieving the goals of > this Project. To start, it's just a clone of the current JDK 8 master. > > Among other things, we're going to see whether we can get away without > introducing a distinct "module mode" as we have in the current prototype > (which is incompatible, in some narrow yet deep ways, with long-standing > behavior) and without doing dependence resolution (since build tools like > Maven, Ivy, and Gradle already do that well enough). > > We remain committed, of course, to this Project's high-level goals: > Create a modular and scalable platform, improve performance and security, > and define a standard module system. > > As we work on this new prototype we'll take code from the old one where > that makes sense, but we'll also take the opportunity to question earlier > design decisions and generally clean things up. > > I urge onlookers to remember that this is just another prototype. It is > likely to evolve swiftly. Its shape and content at any given point in > time should not be treated as having any particular bearing on the final > result of this Project. > > - Mark > From alan.bateman at oracle.com Fri Aug 30 08:28:23 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 30 Aug 2013 15:28:23 +0000 Subject: hg: jigsaw/jake/hotspot: Initial push of prototype changes to extend access control Message-ID: <20130830152832.3B9BD62426@hg.openjdk.java.net> Changeset: ab7f904525f4 Author: alanb Date: 2013-08-30 16:15 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/ab7f904525f4 Initial push of prototype changes to extend access control ! make/bsd/makefiles/mapfile-vers-debug ! make/bsd/makefiles/mapfile-vers-product ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! make/solaris/makefiles/mapfile-vers + src/share/vm/classfile/classLoaderExports.cpp + src/share/vm/classfile/classLoaderExports.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp ! src/share/vm/runtime/reflection.cpp From alan.bateman at oracle.com Fri Aug 30 08:30:07 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 30 Aug 2013 15:30:07 +0000 Subject: hg: jigsaw/jake/jdk: Initial push of prototype changes to extend access control Message-ID: <20130830153055.D4E2362427@hg.openjdk.java.net> Changeset: d16537082c23 Author: alanb Date: 2013-08-30 16:17 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d16537082c23 Initial push of prototype changes to extend access control ! makefiles/mapfiles/libjava/mapfile-vers ! src/share/classes/java/lang/ClassLoader.java ! src/share/classes/sun/misc/VM.java ! src/share/javavm/export/jvm.h ! src/share/native/sun/misc/VM.c + test/java/lang/ClassLoader/setPackageAccess/TEST.properties + test/java/lang/ClassLoader/setPackageAccess/org/openjdk/jigsaw/accesscontrol/SetPackageAccess.java + test/java/lang/ClassLoader/setPackageAccess/org/openjdk/jigsaw/accesscontrol/internal/Secret.java + test/java/lang/ClassLoader/setPackageAccess/org/openjdk/jigsaw/accesscontrol/p1/C1.java + test/java/lang/ClassLoader/setPackageAccess/org/openjdk/jigsaw/accesscontrol/p2/C2.java From mark.reinhold at oracle.com Fri Aug 30 09:09:27 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 30 Aug 2013 16:09:27 +0000 Subject: hg: jigsaw/jake/hotspot: Laxify jcheck Message-ID: <20130830160933.1B44B6242A@hg.openjdk.java.net> Changeset: f919f164ef4f Author: mr Date: 2013-08-30 09:09 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f919f164ef4f Laxify jcheck ! .jcheck/conf From david.lloyd at redhat.com Fri Aug 30 12:20:22 2013 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 30 Aug 2013 14:20:22 -0500 Subject: Jigsaw prototype, take 2 In-Reply-To: <20130828092751.449385@eggemoggin.niobe.net> References: <20130828092751.449385@eggemoggin.niobe.net> Message-ID: <5220F076.701@redhat.com> On 08/28/2013 11:27 AM, mark.reinhold at oracle.com wrote: > I've created a new forest, http://hg.openjdk.java.net/jigsaw/jake, where > we're going to explore a simplified approach to achieving the goals of > this Project. To start, it's just a clone of the current JDK 8 master. > > Among other things, we're going to see whether we can get away without > introducing a distinct "module mode" as we have in the current prototype > (which is incompatible, in some narrow yet deep ways, with long-standing > behavior) and without doing dependence resolution (since build tools like > Maven, Ivy, and Gradle already do that well enough). I agree that having a separate module mode is yucky for several reasons, so I'm glad that the Jigsaw team has come to a similar conclusion. I think however that it is a faulty assumption that build system dependency management can work for the runtime. We've seen this firsthand in several different contexts. The set of data is different, and the usage of the dependency information is radically different depending on whether you're compiling, testing, or running, and depending on what other components you have in the system and how you expect them to interact. In addition, many best practices have emerged that (partially or wholly) contradict the original design intent of these systems (OSGi also falls into this category). I think attempting to combine existing build system dependency systems with runtime dependencies in Java just isn't going to work without majorly changing the way these systems organize, store, and use this information. I do however think that relying on an external dependency management mechanism of *some* kind is 100% the way to go - there is no need to build this kind of complex machinery into the language, especially given how quickly we've seen best practices change in this area. > We remain committed, of course, to this Project's high-level goals: > Create a modular and scalable platform, improve performance and security, > and define a standard module system. > > As we work on this new prototype we'll take code from the old one where > that makes sense, but we'll also take the opportunity to question earlier > design decisions and generally clean things up. > > I urge onlookers to remember that this is just another prototype. It is > likely to evolve swiftly. Its shape and content at any given point in > time should not be treated as having any particular bearing on the final > result of this Project. I look forward to seeing how this progresses. -- - DML