From mparchet at sunrise.ch Mon Sep 8 18:28:52 2014 From: mparchet at sunrise.ch (=?UTF-8?B?TWljaGHDq2wgUGFyY2hldA==?=) Date: Mon, 08 Sep 2014 20:28:52 +0200 Subject: Fwd: Java va python In-Reply-To: References: Message-ID: <540DF564.904@sunrise.ch> -------- Message transf?r? -------- Sujet : Java va python Date : Sun, 7 Sep 2014 01:04:48 +0200 De : Parchet Micha?l Pour : jdk7-dev at openjdk.java.net Hello, I h?ve discordes python and the interactive mode. In python you can also use the multiple inerties and create or remove the property or classe at rustine . I would use the interactive mode with my project Witch there's functions is impenetrable in open jdk ? Thanks for your answer Best regards mparchet From mparchet at sunrise.ch Mon Sep 8 18:56:51 2014 From: mparchet at sunrise.ch (=?UTF-8?B?TWljaGHDq2wgUGFyY2hldA==?=) Date: Mon, 08 Sep 2014 20:56:51 +0200 Subject: CFV: New Project Kulla Message-ID: <540DFBF3.1050405@sunrise.ch> Hello, I would like use this function to debug my paroject. invoke only one method. Open only a JFrame to test it etc,, This function could implements like this. Begin. Ask : "whould you like to save your next commands in a source java file ? y/n" if answer == y show the stop button When the user type enter. If this command is valid Write it in the file When the user click stop. if the file hase been saved ? show message : "your file has been saved to" + absolutefilepath. If answer == n Enter in the normal interactive mode whithout savig commands Please send me news about my idee. I Vote yes at 100% Best regards Micha?l Parchet From aph at redhat.com Tue Sep 9 09:36:52 2014 From: aph at redhat.com (Andrew Haley) Date: Tue, 09 Sep 2014 10:36:52 +0100 Subject: Fwd: Java va python In-Reply-To: <540DF564.904@sunrise.ch> References: <540DF564.904@sunrise.ch> Message-ID: <540ECA34.5070406@redhat.com> On 09/08/2014 07:28 PM, Micha?l Parchet wrote: > I h?ve discordes python and the interactive mode. In python you can also use the multiple inerties and create or remove the property or classe at rustine . > > I would use the interactive mode with my project > > Witch there's functions is impenetrable in open jdk ? Malheureusement, je ne comprends pas. S'il vous pla?t reformuler en anglais. Andrew. From fcassia at gmail.com Tue Sep 9 10:13:59 2014 From: fcassia at gmail.com (Fernando Cassia) Date: Tue, 9 Sep 2014 07:13:59 -0300 Subject: Java va python In-Reply-To: <540DF564.904@sunrise.ch> References: <540DF564.904@sunrise.ch> Message-ID: On Mon, Sep 8, 2014 at 3:28 PM, Micha?l Parchet wrote: > Hello, > > I h?ve discordes python and the interactive mode. In python you can also > use the multiple inerties and create or remove the property or classe at > rustine . > > I would use the interactive mode with my project > > Witch there's functions is impenetrable in open jdk ? > You can use Jython. There's also this Jython Interactive Console with Code Completion https:// code.google.com/p/jythonconsole/ www.jython.org Make sure you use 2.7b3 if you want compatibility with CPython 2.7... FC -- During times of Universal Deceit, telling the truth becomes a revolutionary act Durante ?pocas de Enga?o Universal, decir la verdad se convierte en un Acto Revolucionario - George Orwell From shortcutter at googlemail.com Mon Sep 15 15:13:16 2014 From: shortcutter at googlemail.com (Robert Klemme) Date: Mon, 15 Sep 2014 17:13:16 +0200 Subject: Java va python In-Reply-To: <540DF564.904@sunrise.ch> References: <540DF564.904@sunrise.ch> Message-ID: On Mon, Sep 8, 2014 at 8:28 PM, Micha?l Parchet wrote: > > -------- Message transf?r? -------- > Sujet : Java va python > Date : Sun, 7 Sep 2014 01:04:48 +0200 > De : Parchet Micha?l > Pour : jdk7-dev at openjdk.java.net > I h?ve discordes python and the interactive mode. In python you can also use > the multiple inerties and create or remove the property or classe at rustine > . > > I would use the interactive mode with my project > > Witch there's functions is impenetrable in open jdk ? If you are asking for an interactive Java you can use the http://www.beanshell.org/ Kind regards robert -- [guy, jim].each {|him| remember.him do |as, often| as.you_can - without end} http://blog.rubybestpractices.com/ From pkesseli at outlook.com Fri Sep 19 15:20:02 2014 From: pkesseli at outlook.com (Pascal Kesseli) Date: Fri, 19 Sep 2014 16:20:02 +0100 Subject: Create OpenJDK without "code too large". Message-ID: Hi everyone, I am trying to create a Java compiler from OpenJDK 8 which ignores "compiler.err.limit.code" and "compiler.err.limit.code.too.large.for.try.stmt" errors. I understand there is no flag in javac to disable this - is there a way to remove them from the OpenJDK source, such that methods with more instructions will compile? Thanks, Pascal From aph at redhat.com Fri Sep 19 15:26:50 2014 From: aph at redhat.com (Andrew Haley) Date: Fri, 19 Sep 2014 16:26:50 +0100 Subject: Create OpenJDK without "code too large". In-Reply-To: References: Message-ID: <541C4B3A.6060409@redhat.com> Hi, On 09/19/2014 04:20 PM, Pascal Kesseli wrote: > > I am trying to create a Java compiler from OpenJDK 8 which ignores > "compiler.err.limit.code" and > "compiler.err.limit.code.too.large.for.try.stmt" errors. I understand there > is no flag in javac to disable this - is there a way to remove them from the > OpenJDK source, such that methods with more instructions will compile? Not really. The code size is a VM limitation. Andrew. From pkesseli at outlook.com Fri Sep 19 15:36:42 2014 From: pkesseli at outlook.com (Pascal Kesseli) Date: Fri, 19 Sep 2014 16:36:42 +0100 Subject: AW: Create OpenJDK without "code too large". In-Reply-To: <541C4B3A.6060409@redhat.com> References: <541C4B3A.6060409@redhat.com> Message-ID: Hi Andrew, Thanks for your quick response. Is it merely a formal limit or is it actually necessary, given the way the VM is currently implemented? Could I, with reasonable effort, remove the limit from both VM and compiler? Thanks, Pascal -----Urspr?ngliche Nachricht----- Von: Andrew Haley [mailto:aph at redhat.com] Gesendet: 19 September 2014 16:27 An: Pascal Kesseli; discuss at openjdk.java.net Betreff: Re: Create OpenJDK without "code too large". Hi, On 09/19/2014 04:20 PM, Pascal Kesseli wrote: > > I am trying to create a Java compiler from OpenJDK 8 which ignores > "compiler.err.limit.code" and > "compiler.err.limit.code.too.large.for.try.stmt" errors. I understand > there is no flag in javac to disable this - is there a way to remove > them from the OpenJDK source, such that methods with more instructions will compile? Not really. The code size is a VM limitation. Andrew. From aph at redhat.com Fri Sep 19 15:50:21 2014 From: aph at redhat.com (Andrew Haley) Date: Fri, 19 Sep 2014 16:50:21 +0100 Subject: AW: Create OpenJDK without "code too large". In-Reply-To: References: <541C4B3A.6060409@redhat.com> Message-ID: <541C50BD.4050000@redhat.com> On 09/19/2014 04:36 PM, Pascal Kesseli wrote: > Thanks for your quick response. Is it merely a formal limit or is it > actually necessary, given the way the VM is currently implemented? Could I, > with reasonable effort, remove the limit from both VM and compiler? It'd take a few months to do a proper job. Lots of tools know about this limitation. Andrew. From forax at univ-mlv.fr Fri Sep 19 15:51:56 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 19 Sep 2014 17:51:56 +0200 Subject: Create OpenJDK without "code too large". In-Reply-To: <541C4B3A.6060409@redhat.com> References: <541C4B3A.6060409@redhat.com> Message-ID: <541C511C.4040906@univ-mlv.fr> On 09/19/2014 05:26 PM, Andrew Haley wrote: > Hi, > > On 09/19/2014 04:20 PM, Pascal Kesseli wrote: >> I am trying to create a Java compiler from OpenJDK 8 which ignores >> "compiler.err.limit.code" and >> "compiler.err.limit.code.too.large.for.try.stmt" errors. I understand there >> is no flag in javac to disable this - is there a way to remove them from the >> OpenJDK source, such that methods with more instructions will compile? > Not really. The code size is a VM limitation. Technically, it's more a limitation of the classfile format (.class) than the VM, you can not have more than 65535 bytecode instructions by method. You can try to split method code automatically, Nashorn does that, but usually it's specific to the code you translate to Java. > > Andrew. > > cheers, R?mi From alex.buckley at oracle.com Fri Sep 19 16:57:06 2014 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 19 Sep 2014 09:57:06 -0700 Subject: Create OpenJDK without "code too large". In-Reply-To: <541C511C.4040906@univ-mlv.fr> References: <541C4B3A.6060409@redhat.com> <541C511C.4040906@univ-mlv.fr> Message-ID: <541C6062.9030503@oracle.com> On 9/19/2014 8:51 AM, Remi Forax wrote: > Technically, it's more a limitation of the classfile format (.class) > than the VM, you can not have more than 65535 bytecode instructions > by method. The relevant ClassFile limit is in the Code attribute, but it's not the u4 code_length item. It's the exception_table item which describes the extent of exception handlers with u2 items. See JVMS8 4.7.3. Alex From mike.duigou at oracle.com Fri Sep 19 17:15:46 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 19 Sep 2014 10:15:46 -0700 Subject: RFC: JDK 9 Sandbox Forest Proposal Message-ID: Hello all; I've been instigating internal discussions with the Oracle OpenJDK developers about where to do OpenJDK development work for JEP-scale efforts. The scope, duration, and necessary collaboration of JEP-scale efforts makes it appropriate for collaboration to be done using an open, shared version control system rather than just using privately shared patches. As incubation development work it is not appropriate though for this work to be hosted in the jdk9/dev main-line repos. We need a public place to collaborate on issues and features before they are ready for final integration into the main-line JDK repos. It is possible for any OpenJDK developer to request a new OpenJDK project, but the OpenJDK project process seems entirely too heavy-weight to have full OpenJDK projects and/or forests for every issue, feature, exploration or prototype. The problem is both the creation process overhead for new projects as well as the various ongoing administration and maintenance issues attendant with ongoing projects. For larger efforts it is still entirely appropriate to create an OpenJDK project. An extremely rough guide is that if the result of an effort will be a new JDK module or API package then it is probably big enough to deserve a separate project. For everything smaller, shorter or more speculative than is appropriate for a project this new sandbox forest will provide a comfortable home. This proposal has been through a few rounds of internal review and refinement and I believe is nearly ready for activation. Ideally the new sandbox forest would be available for use in early October. Feedback and suggestions welcome. Cheers, Mike Proposal: - Create a new forest in the JDK 9 project for developers to use for experiments, new features, prototypes or any other non-trivial efforts. Goals: - Open : Use OpenJDK public infrastructure - Low-friction : Minimal start-cost and no delays - Collaboration : Individual efforts can self-organize and self-regulate - Approachable : Community members can easily locate, review, comment and participate - Participation : Open to all JDK 9 Reviewers, Committers and Authors(*) - Light-weight : Minimal required policy, simpler pre-push rules than main-line jdk9/dev forest - Visible : Links from JEP or issue page and sharable URIs to repo, branches and changesets (*) Authors will require a Committer or Reviewer to push changesets for them. Constraints: - Policies are consistent with OpenJDK bylaws and JDK 9 project rule. - Future OpenJDK bylaws changes may make things easier but we won't block waiting for changes. - Use the JDK 9 project membership and roles. Specifics: - New "sandbox" forest in JDK 9 project is a clone/child of jdk9/dev forest. - Eligible committers are JDK 9 committers as this is a forest in the JDK 9 project. - Each repo in the forest has a branch (possibly default) that is lockstep updated from parent jdk9/dev repo via cron job syncing or triggered. - Neither jcheck nor hgupdater is enabled for this forest. - All development happens on branches. Committers can create whatever branches in this forest they wish. Branch names "JEP-XXX" and "JDK-XXXXXXX" are, by courtesy, reserved for use of the corresponding JBS issues. Branch names prefixed with an OpenJDK username and a delimiter, by courtesy, are reserved for use of that OpenJDK user. - JBS allows web links to be associated with issues. This can be used to identify the location of development branch for an issue. - Branch owners determine the pre-commit review policy (if any) for their branches. - Branch owners are responsible for reparenting/rebasing their branch to the provided upstream lockstep-with-dev branch however often they wish. - There will be no pushes or promotions from this forest to any other forest. - Integration to the main-line jdk9/dev forest repos will be via the the current JDK 9 changeset review and approval process. - Nightlies, testing, CI, etc. are the responsibility of the individual branch owners. - Since the work in this forest is unreviewed, experimental, prototype or exploratory there is no commitment whatsoever that anything in this forest eventually be part of JDK 9 or any other release. - The forest will be frozen at the release of JDK 9 and possibly deleted sometime thereafter. Feature owners would be responsible for archiving or migrating anything that they wish to retain. Notice and warning will be given on jdk9-dev mailing list to which all JDK 9 project committers are presumed to subscribe. - Changesets pushed to the sandbox forest do not count as "significant contributions" for the purposes of JDK 9 project role eligibility. Desirable Future Changes: - Allow changesets to be pushed to branches in the sandbox forest by users with Author role. This new privilege would be consistent with other Author privileges such as uploading to cr.openjdk.java.net, editing bug reports, and modifying the wiki. Allowing Authors to push changesets would require a modification to the OpenJDK bylaws so we cannot currently implement this policy. Contributors (in no particular order): Stuart Marks, Alan Bateman, Joe Darcy, Paul Sandoz, Mark Reinhold, John Rose, Brian Beck, Brian Goetz, Roger Riggs and Chris Hegarty all reviewed earlier drafts of this proposal and provided insight and encouragement. From aph at redhat.com Fri Sep 19 15:56:14 2014 From: aph at redhat.com (Andrew Haley) Date: Fri, 19 Sep 2014 16:56:14 +0100 Subject: Create OpenJDK without "code too large". In-Reply-To: <541C511C.4040906@univ-mlv.fr> References: <541C4B3A.6060409@redhat.com> <541C511C.4040906@univ-mlv.fr> Message-ID: <541C521E.3070301@redhat.com> On 09/19/2014 04:51 PM, Remi Forax wrote: > > On 09/19/2014 05:26 PM, Andrew Haley wrote: >> Hi, >> >> On 09/19/2014 04:20 PM, Pascal Kesseli wrote: >>> I am trying to create a Java compiler from OpenJDK 8 which ignores >>> "compiler.err.limit.code" and >>> "compiler.err.limit.code.too.large.for.try.stmt" errors. I understand there >>> is no flag in javac to disable this - is there a way to remove them from the >>> OpenJDK source, such that methods with more instructions will compile? >> Not really. The code size is a VM limitation. > > Technically, it's more a limitation of the classfile format (.class) > than the VM, I don't agree. The limitation is defined in the Java Virtual Machine Specification. Andrew. From kmcguigan at twitter.com Fri Sep 19 19:36:26 2014 From: kmcguigan at twitter.com (Keith McGuigan) Date: Fri, 19 Sep 2014 15:36:26 -0400 Subject: RFC: JDK 9 Sandbox Forest Proposal In-Reply-To: References: Message-ID: This sounds great! Thanks for doing this. On Fri, Sep 19, 2014 at 1:15 PM, Mike Duigou wrote: > Hello all; > > I've been instigating internal discussions with the Oracle OpenJDK > developers about where to do OpenJDK development work for JEP-scale > efforts. The scope, duration, and necessary collaboration of JEP-scale > efforts makes it appropriate for collaboration to be done using an open, > shared version control system rather than just using privately shared > patches. As incubation development work it is not appropriate though for > this work to be hosted in the jdk9/dev main-line repos. We need a public > place to collaborate on issues and features before they are ready for final > integration into the main-line JDK repos. > > It is possible for any OpenJDK developer to request a new OpenJDK project, > but the OpenJDK project process seems entirely too heavy-weight to have > full OpenJDK projects and/or forests for every issue, feature, exploration > or prototype. The problem is both the creation process overhead for new > projects as well as the various ongoing administration and maintenance > issues attendant with ongoing projects. For larger efforts it is still > entirely appropriate to create an OpenJDK project. An extremely rough guide > is that if the result of an effort will be a new JDK module or API package > then it is probably big enough to deserve a separate project. For > everything smaller, shorter or more speculative than is appropriate for a > project this new sandbox forest will provide a comfortable home. > > This proposal has been through a few rounds of internal review and > refinement and I believe is nearly ready for activation. Ideally the new > sandbox forest would be available for use in early October. > > Feedback and suggestions welcome. > > Cheers, > > Mike > > > Proposal: > > - Create a new forest in the JDK 9 project for developers to use for > experiments, new features, prototypes or any other non-trivial efforts. > > > Goals: > > - Open : Use OpenJDK public infrastructure > - Low-friction : Minimal start-cost and no delays > - Collaboration : Individual efforts can self-organize and self-regulate > - Approachable : Community members can easily locate, review, comment and > participate > - Participation : Open to all JDK 9 Reviewers, Committers and Authors(*) > - Light-weight : Minimal required policy, simpler pre-push rules than > main-line jdk9/dev forest > - Visible : Links from JEP or issue page and sharable URIs to repo, > branches and changesets > > (*) Authors will require a Committer or Reviewer to push changesets for > them. > > > Constraints: > > - Policies are consistent with OpenJDK bylaws and JDK 9 project rule. > - Future OpenJDK bylaws changes may make things easier but we won't block > waiting for changes. > - Use the JDK 9 project membership and roles. > > > Specifics: > > - New "sandbox" forest in JDK 9 project is a clone/child of jdk9/dev > forest. > - Eligible committers are JDK 9 committers as this is a forest in the JDK > 9 project. > - Each repo in the forest has a branch (possibly default) that is lockstep > updated from parent jdk9/dev repo via cron job syncing or triggered. > - Neither jcheck nor hgupdater is enabled for this forest. > - All development happens on branches. Committers can create whatever > branches in this forest they wish. Branch names "JEP-XXX" and "JDK-XXXXXXX" > are, by courtesy, reserved for use of the corresponding JBS issues. Branch > names prefixed with an OpenJDK username and a delimiter, by courtesy, are > reserved for use of that OpenJDK user. > - JBS allows web links to be associated with issues. This can be used to > identify the location of development branch for an issue. > - Branch owners determine the pre-commit review policy (if any) for their > branches. > - Branch owners are responsible for reparenting/rebasing their branch to > the provided upstream lockstep-with-dev branch however often they wish. > - There will be no pushes or promotions from this forest to any other > forest. > - Integration to the main-line jdk9/dev forest repos will be via the the > current JDK 9 changeset review and approval process. > - Nightlies, testing, CI, etc. are the responsibility of the individual > branch owners. > - Since the work in this forest is unreviewed, experimental, prototype or > exploratory there is no commitment whatsoever that anything in this forest > eventually be part of JDK 9 or any other release. > - The forest will be frozen at the release of JDK 9 and possibly deleted > sometime thereafter. Feature owners would be responsible for archiving or > migrating anything that they wish to retain. Notice and warning will be > given on jdk9-dev mailing list to which all JDK 9 project committers are > presumed to subscribe. > - Changesets pushed to the sandbox forest do not count as "significant > contributions" for the purposes of JDK 9 project role eligibility. > > > Desirable Future Changes: > > - Allow changesets to be pushed to branches in the sandbox forest by users > with Author role. This new privilege would be consistent with other Author > privileges such as uploading to cr.openjdk.java.net, editing bug reports, > and modifying the wiki. Allowing Authors to push changesets would require a > modification to the OpenJDK bylaws so we cannot currently implement this > policy. > > > Contributors (in no particular order): > > Stuart Marks, Alan Bateman, Joe Darcy, Paul Sandoz, Mark Reinhold, John > Rose, Brian Beck, Brian Goetz, Roger Riggs and Chris Hegarty all reviewed > earlier drafts of this proposal and provided insight and encouragement. > -- [image: twitter-icon-large.png] Keith McGuigan @kamggg kmcguigan at twitter.com From mparchet at sunrise.ch Fri Sep 19 20:19:07 2014 From: mparchet at sunrise.ch (=?utf-8?Q?Parchet_Micha=C3=ABl?=) Date: Fri, 19 Sep 2014 22:19:07 +0200 Subject: Openjdk 9 Message-ID: <5541D63E-2E85-4585-B65F-43FD4EF5EDC6@sunrise.ch> Hi, I'm waiting for open jdk 9 since I have view nothing about open jdk 8 Could you tell me more about it ? Thanks for your answer. Best regards mparchet From forax at univ-mlv.fr Sat Sep 20 08:57:39 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 20 Sep 2014 10:57:39 +0200 Subject: Create OpenJDK without "code too large". In-Reply-To: <541C6062.9030503@oracle.com> References: <541C4B3A.6060409@redhat.com> <541C511C.4040906@univ-mlv.fr> <541C6062.9030503@oracle.com> Message-ID: <541D4183.7060100@univ-mlv.fr> On 09/19/2014 06:57 PM, Alex Buckley wrote: > On 9/19/2014 8:51 AM, Remi Forax wrote: >> Technically, it's more a limitation of the classfile format (.class) >> than the VM, you can not have more than 65535 bytecode instructions >> by method. > > The relevant ClassFile limit is in the Code attribute, but it's not > the u4 code_length item. It's the exception_table item which describes > the extent of exception handlers with u2 items. See JVMS8 4.7.3. also several Code attributes (LineNumberTable, LocalVariableTable, ...) use a 16 bits value as index (usually named start_pc) into the bytecode array limiting in practice the bytecode array to a size of 65535. > > Alex R?mi From martijnverburg at gmail.com Sat Sep 20 16:00:17 2014 From: martijnverburg at gmail.com (Martijn Verburg) Date: Sat, 20 Sep 2014 17:00:17 +0100 Subject: Openjdk 9 In-Reply-To: <5541D63E-2E85-4585-B65F-43FD4EF5EDC6@sunrise.ch> References: <5541D63E-2E85-4585-B65F-43FD4EF5EDC6@sunrise.ch> Message-ID: Hi Parchet, OpenJDK 9 has already been up and running for sometime. Please see jdk9-dev mailing list. Cheers, Martijn On Friday, 19 September 2014, Parchet Micha?l wrote: > Hi, > > I'm waiting for open jdk 9 since I have view nothing about open jdk 8 > Could you tell me more about it ? > > Thanks for your answer. > > Best regards > > mparchet > > > -- Cheers, Martijn From martijnverburg at gmail.com Sat Sep 20 18:14:52 2014 From: martijnverburg at gmail.com (Martijn Verburg) Date: Sat, 20 Sep 2014 19:14:52 +0100 Subject: RFC: JDK 9 Sandbox Forest Proposal In-Reply-To: References: Message-ID: +1 (from an outsider) On Friday, 19 September 2014, Keith McGuigan wrote: > This sounds great! Thanks for doing this. > > On Fri, Sep 19, 2014 at 1:15 PM, Mike Duigou > wrote: > > > Hello all; > > > > I've been instigating internal discussions with the Oracle OpenJDK > > developers about where to do OpenJDK development work for JEP-scale > > efforts. The scope, duration, and necessary collaboration of JEP-scale > > efforts makes it appropriate for collaboration to be done using an open, > > shared version control system rather than just using privately shared > > patches. As incubation development work it is not appropriate though for > > this work to be hosted in the jdk9/dev main-line repos. We need a public > > place to collaborate on issues and features before they are ready for > final > > integration into the main-line JDK repos. > > > > It is possible for any OpenJDK developer to request a new OpenJDK > project, > > but the OpenJDK project process seems entirely too heavy-weight to have > > full OpenJDK projects and/or forests for every issue, feature, > exploration > > or prototype. The problem is both the creation process overhead for new > > projects as well as the various ongoing administration and maintenance > > issues attendant with ongoing projects. For larger efforts it is still > > entirely appropriate to create an OpenJDK project. An extremely rough > guide > > is that if the result of an effort will be a new JDK module or API > package > > then it is probably big enough to deserve a separate project. For > > everything smaller, shorter or more speculative than is appropriate for a > > project this new sandbox forest will provide a comfortable home. > > > > This proposal has been through a few rounds of internal review and > > refinement and I believe is nearly ready for activation. Ideally the new > > sandbox forest would be available for use in early October. > > > > Feedback and suggestions welcome. > > > > Cheers, > > > > Mike > > > > > > Proposal: > > > > - Create a new forest in the JDK 9 project for developers to use for > > experiments, new features, prototypes or any other non-trivial efforts. > > > > > > Goals: > > > > - Open : Use OpenJDK public infrastructure > > - Low-friction : Minimal start-cost and no delays > > - Collaboration : Individual efforts can self-organize and self-regulate > > - Approachable : Community members can easily locate, review, comment > and > > participate > > - Participation : Open to all JDK 9 Reviewers, Committers and Authors(*) > > - Light-weight : Minimal required policy, simpler pre-push rules than > > main-line jdk9/dev forest > > - Visible : Links from JEP or issue page and sharable URIs to repo, > > branches and changesets > > > > (*) Authors will require a Committer or Reviewer to push changesets for > > them. > > > > > > Constraints: > > > > - Policies are consistent with OpenJDK bylaws and JDK 9 project rule. > > - Future OpenJDK bylaws changes may make things easier but we won't block > > waiting for changes. > > - Use the JDK 9 project membership and roles. > > > > > > Specifics: > > > > - New "sandbox" forest in JDK 9 project is a clone/child of jdk9/dev > > forest. > > - Eligible committers are JDK 9 committers as this is a forest in the JDK > > 9 project. > > - Each repo in the forest has a branch (possibly default) that is > lockstep > > updated from parent jdk9/dev repo via cron job syncing or triggered. > > - Neither jcheck nor hgupdater is enabled for this forest. > > - All development happens on branches. Committers can create whatever > > branches in this forest they wish. Branch names "JEP-XXX" and > "JDK-XXXXXXX" > > are, by courtesy, reserved for use of the corresponding JBS issues. > Branch > > names prefixed with an OpenJDK username and a delimiter, by courtesy, are > > reserved for use of that OpenJDK user. > > - JBS allows web links to be associated with issues. This can be used to > > identify the location of development branch for an issue. > > - Branch owners determine the pre-commit review policy (if any) for their > > branches. > > - Branch owners are responsible for reparenting/rebasing their branch to > > the provided upstream lockstep-with-dev branch however often they wish. > > - There will be no pushes or promotions from this forest to any other > > forest. > > - Integration to the main-line jdk9/dev forest repos will be via the the > > current JDK 9 changeset review and approval process. > > - Nightlies, testing, CI, etc. are the responsibility of the individual > > branch owners. > > - Since the work in this forest is unreviewed, experimental, prototype or > > exploratory there is no commitment whatsoever that anything in this > forest > > eventually be part of JDK 9 or any other release. > > - The forest will be frozen at the release of JDK 9 and possibly deleted > > sometime thereafter. Feature owners would be responsible for archiving or > > migrating anything that they wish to retain. Notice and warning will be > > given on jdk9-dev mailing list to which all JDK 9 project committers are > > presumed to subscribe. > > - Changesets pushed to the sandbox forest do not count as "significant > > contributions" for the purposes of JDK 9 project role eligibility. > > > > > > Desirable Future Changes: > > > > - Allow changesets to be pushed to branches in the sandbox forest by > users > > with Author role. This new privilege would be consistent with other > Author > > privileges such as uploading to cr.openjdk.java.net, editing bug > reports, > > and modifying the wiki. Allowing Authors to push changesets would > require a > > modification to the OpenJDK bylaws so we cannot currently implement this > > policy. > > > > > > Contributors (in no particular order): > > > > Stuart Marks, Alan Bateman, Joe Darcy, Paul Sandoz, Mark Reinhold, John > > Rose, Brian Beck, Brian Goetz, Roger Riggs and Chris Hegarty all reviewed > > earlier drafts of this proposal and provided insight and encouragement. > > > > > > -- > > [image: twitter-icon-large.png] > > Keith McGuigan > > @kamggg > > kmcguigan at twitter.com > -- Cheers, Martijn From behrangsa at gmail.com Sun Sep 21 05:45:53 2014 From: behrangsa at gmail.com (Behrang Saeedzadeh) Date: Sun, 21 Sep 2014 15:45:53 +1000 Subject: 2 new feature proposals: class extensions and import aliases Message-ID: Hi all, This is nothing new as there are other languages that have this feature already, but now that Java has syntactical support for closures, etc. I think it would be nice if it was possible to augment classes with custom methods. For example, if I wanted to add a method times(Runnable c) to Integer that runs the given block multiple times so that I could type the following code: 5.times(() -> { System.out.println("Hello, World"); }) All I needed to do was to define an "extension" for Integer: *com.foo.IntegerExtension* *========================* extension IntegerExtension extends Integer { public void times(Runnable r) { for (int i = this; i < count; i++) { c.run(); } } } Then I can activate the IntegerExtension explicitly by importing it into a class: *com.foo.Main* *============* import com.foo.IntegerExtension; public class Main { public static void main(String[] args) { 5.times(() -> { System.out.println("Hello, World"); }) } } Of course this is just to show the idea and the implementation can be quite different. Another *very simple* feature that I wish Java had is importing a class with an alias, similar to Groovy: import java.util.Date; import java.sql.Date as SDate; SDate sDate = ...; Date date = ...; // or import java.awt.Point as Vector; spaceship.move(new Vector(+5, -10)); What do you fellows think? Best regards, Behrang http://www.behrang.org From benjamin.john.evans at gmail.com Sun Sep 21 07:30:51 2014 From: benjamin.john.evans at gmail.com (Ben Evans) Date: Sun, 21 Sep 2014 08:30:51 +0100 Subject: RFC: JDK 9 Sandbox Forest Proposal In-Reply-To: References: Message-ID: Would this be a good place for betterrev to baseline against? & +1 from someone else who doesn't get a vote. On 20 Sep 2014 19:16, "Martijn Verburg" wrote: > +1 (from an outsider) > > On Friday, 19 September 2014, Keith McGuigan > wrote: > > > This sounds great! Thanks for doing this. > > > > On Fri, Sep 19, 2014 at 1:15 PM, Mike Duigou > > wrote: > > > > > Hello all; > > > > > > I've been instigating internal discussions with the Oracle OpenJDK > > > developers about where to do OpenJDK development work for JEP-scale > > > efforts. The scope, duration, and necessary collaboration of JEP-scale > > > efforts makes it appropriate for collaboration to be done using an > open, > > > shared version control system rather than just using privately shared > > > patches. As incubation development work it is not appropriate though > for > > > this work to be hosted in the jdk9/dev main-line repos. We need a > public > > > place to collaborate on issues and features before they are ready for > > final > > > integration into the main-line JDK repos. > > > > > > It is possible for any OpenJDK developer to request a new OpenJDK > > project, > > > but the OpenJDK project process seems entirely too heavy-weight to have > > > full OpenJDK projects and/or forests for every issue, feature, > > exploration > > > or prototype. The problem is both the creation process overhead for new > > > projects as well as the various ongoing administration and maintenance > > > issues attendant with ongoing projects. For larger efforts it is still > > > entirely appropriate to create an OpenJDK project. An extremely rough > > guide > > > is that if the result of an effort will be a new JDK module or API > > package > > > then it is probably big enough to deserve a separate project. For > > > everything smaller, shorter or more speculative than is appropriate > for a > > > project this new sandbox forest will provide a comfortable home. > > > > > > This proposal has been through a few rounds of internal review and > > > refinement and I believe is nearly ready for activation. Ideally the > new > > > sandbox forest would be available for use in early October. > > > > > > Feedback and suggestions welcome. > > > > > > Cheers, > > > > > > Mike > > > > > > > > > Proposal: > > > > > > - Create a new forest in the JDK 9 project for developers to use for > > > experiments, new features, prototypes or any other non-trivial efforts. > > > > > > > > > Goals: > > > > > > - Open : Use OpenJDK public infrastructure > > > - Low-friction : Minimal start-cost and no delays > > > - Collaboration : Individual efforts can self-organize and > self-regulate > > > - Approachable : Community members can easily locate, review, comment > > and > > > participate > > > - Participation : Open to all JDK 9 Reviewers, Committers and > Authors(*) > > > - Light-weight : Minimal required policy, simpler pre-push rules than > > > main-line jdk9/dev forest > > > - Visible : Links from JEP or issue page and sharable URIs to > repo, > > > branches and changesets > > > > > > (*) Authors will require a Committer or Reviewer to push changesets for > > > them. > > > > > > > > > Constraints: > > > > > > - Policies are consistent with OpenJDK bylaws and JDK 9 project rule. > > > - Future OpenJDK bylaws changes may make things easier but we won't > block > > > waiting for changes. > > > - Use the JDK 9 project membership and roles. > > > > > > > > > Specifics: > > > > > > - New "sandbox" forest in JDK 9 project is a clone/child of jdk9/dev > > > forest. > > > - Eligible committers are JDK 9 committers as this is a forest in the > JDK > > > 9 project. > > > - Each repo in the forest has a branch (possibly default) that is > > lockstep > > > updated from parent jdk9/dev repo via cron job syncing or triggered. > > > - Neither jcheck nor hgupdater is enabled for this forest. > > > - All development happens on branches. Committers can create whatever > > > branches in this forest they wish. Branch names "JEP-XXX" and > > "JDK-XXXXXXX" > > > are, by courtesy, reserved for use of the corresponding JBS issues. > > Branch > > > names prefixed with an OpenJDK username and a delimiter, by courtesy, > are > > > reserved for use of that OpenJDK user. > > > - JBS allows web links to be associated with issues. This can be used > to > > > identify the location of development branch for an issue. > > > - Branch owners determine the pre-commit review policy (if any) for > their > > > branches. > > > - Branch owners are responsible for reparenting/rebasing their branch > to > > > the provided upstream lockstep-with-dev branch however often they wish. > > > - There will be no pushes or promotions from this forest to any other > > > forest. > > > - Integration to the main-line jdk9/dev forest repos will be via the > the > > > current JDK 9 changeset review and approval process. > > > - Nightlies, testing, CI, etc. are the responsibility of the individual > > > branch owners. > > > - Since the work in this forest is unreviewed, experimental, prototype > or > > > exploratory there is no commitment whatsoever that anything in this > > forest > > > eventually be part of JDK 9 or any other release. > > > - The forest will be frozen at the release of JDK 9 and possibly > deleted > > > sometime thereafter. Feature owners would be responsible for archiving > or > > > migrating anything that they wish to retain. Notice and warning will be > > > given on jdk9-dev mailing list to which all JDK 9 project committers > are > > > presumed to subscribe. > > > - Changesets pushed to the sandbox forest do not count as "significant > > > contributions" for the purposes of JDK 9 project role eligibility. > > > > > > > > > Desirable Future Changes: > > > > > > - Allow changesets to be pushed to branches in the sandbox forest by > > users > > > with Author role. This new privilege would be consistent with other > > Author > > > privileges such as uploading to cr.openjdk.java.net, editing bug > > reports, > > > and modifying the wiki. Allowing Authors to push changesets would > > require a > > > modification to the OpenJDK bylaws so we cannot currently implement > this > > > policy. > > > > > > > > > Contributors (in no particular order): > > > > > > Stuart Marks, Alan Bateman, Joe Darcy, Paul Sandoz, Mark Reinhold, John > > > Rose, Brian Beck, Brian Goetz, Roger Riggs and Chris Hegarty all > reviewed > > > earlier drafts of this proposal and provided insight and encouragement. > > > > > > > > > > > -- > > > > [image: twitter-icon-large.png] > > > > Keith McGuigan > > > > @kamggg > > > > kmcguigan at twitter.com > > > > > -- > Cheers, > Martijn > From Alan.Bateman at oracle.com Sun Sep 21 17:01:31 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 21 Sep 2014 18:01:31 +0100 Subject: RFC: JDK 9 Sandbox Forest Proposal In-Reply-To: References: Message-ID: <541F046B.7000608@oracle.com> On 21/09/2014 15:41, David Chase wrote: > : > I ran into one specific problem attempting to add stuff to > jdk libraries as part of Panama, which is that the creation > of a new module is error-prone. In my case, it is only > error-prone, I never succeeded, I assume I missed some > crucial step. There isn't a module system in JDK 9 yet, it's going to take time to bring all the pieces in and there is a lot of transition and changes along the way. We tried to make it clear in JEP 200 that until there is a module system in place that it would require maintaining the XML document that defines the modular structure. That's the document that gets translated early in the build now to create the build dependences, it is also used to verify the resulting bits at the end. So it is awkward at the moment but should get much better once we have a module system in place. -Alan. From Alan.Bateman at oracle.com Sun Sep 21 17:20:02 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 21 Sep 2014 18:20:02 +0100 Subject: RFC: JDK 9 Sandbox Forest Proposal In-Reply-To: References: Message-ID: <541F08C2.4070804@oracle.com> On 21/09/2014 08:30, Ben Evans wrote: > Would this be a good place for betterrev to baseline against? > Not wishing to make the contribution workflow any more complicated but I would think it depends on whether it's it a patch for a a specific issue or an idea for a new feature might iterate and evolve in the sandbox project. Some things might be obvious as to which route to take, other things might find the right route after some discussion. -Alan From doug.simon at oracle.com Sun Sep 21 19:19:28 2014 From: doug.simon at oracle.com (Doug Simon) Date: Sun, 21 Sep 2014 21:19:28 +0200 Subject: RFC: JDK 9 Sandbox Forest Proposal In-Reply-To: References: Message-ID: <94E9BFE5-A9CE-4172-8B16-FA46DE551D5B@oracle.com> On Sep 19, 2014, at 7:15 PM, Mike Duigou wrote: > Hello all; > > I've been instigating internal discussions with the Oracle OpenJDK developers about where to do OpenJDK development work for JEP-scale efforts. The scope, duration, and necessary collaboration of JEP-scale efforts makes it appropriate for collaboration to be done using an open, shared version control system rather than just using privately shared patches. As incubation development work it is not appropriate though for this work to be hosted in the jdk9/dev main-line repos. We need a public place to collaborate on issues and features before they are ready for final integration into the main-line JDK repos. > > It is possible for any OpenJDK developer to request a new OpenJDK project, but the OpenJDK project process seems entirely too heavy-weight to have full OpenJDK projects and/or forests for every issue, feature, exploration or prototype. The problem is both the creation process overhead for new projects as well as the various ongoing administration and maintenance issues attendant with ongoing projects. For larger efforts it is still entirely appropriate to create an OpenJDK project. An extremely rough guide is that if the result of an effort will be a new JDK module or API package then it is probably big enough to deserve a separate project. For everything smaller, shorter or more speculative than is appropriate for a project this new sandbox forest will provide a comfortable home. > > This proposal has been through a few rounds of internal review and refinement and I believe is nearly ready for activation. Ideally the new sandbox forest would be available for use in early October. > > Feedback and suggestions welcome. > > Cheers, > > Mike > > > Proposal: > > - Create a new forest in the JDK 9 project for developers to use for experiments, new features, prototypes or any other non-trivial efforts. > > > Goals: > > - Open : Use OpenJDK public infrastructure > - Low-friction : Minimal start-cost and no delays > - Collaboration : Individual efforts can self-organize and self-regulate > - Approachable : Community members can easily locate, review, comment and participate Towards the goal of easier reviewing, are there any plans for adopting a code review tool (such as Crucible) as part of this proposal? -Doug From volker.simonis at gmail.com Mon Sep 22 08:38:29 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 22 Sep 2014 10:38:29 +0200 Subject: RFC: JDK 9 Sandbox Forest Proposal In-Reply-To: References: Message-ID: On Sun, Sep 21, 2014 at 4:41 PM, David Chase wrote: > I vote yes, I have some feedback/questions on the proposal: > > On 2014-09-19, at 1:15 PM, Mike Duigou wrote: >> Goals: >> >> - Open : Use OpenJDK public infrastructure >> - Low-friction : Minimal start-cost and no delays > > I ran into one specific problem attempting to add stuff to > jdk libraries as part of Panama, which is that the creation > of a new module is error-prone. In my case, it is only > error-prone, I never succeeded, I assume I missed some > crucial step. I think we want people to be able to work in > this style because at least one of the IDE tools (NetBeans) > can sometimes get confused when working with a subset of the > source files in java.base. (and even when it works, it?s another > little speedbump on the way to configure NetBeans to work > properly in this case) > > So I think we need to address this and write up a recipe, > including the need to regenerate configure files etc before > commit. Ideally the recipe will contain copy-and-pasteable > commands where that is possible. > >> Specifics: > >> - Neither jcheck nor hgupdater is enabled for this forest. > > Do we want something like jcheck to keep the code moderately > clean ? for example, there?s the personal ?fixit? script > I?ve informally put up for consideration for Codetools (it?s > not a commit hook, it merely checks a bunch of source code > rules and gives you the the option of an automated fix). > This is purely a matter of keeping code clean, on the off > chance that we do include some of it in a future release. > >> - All development happens on branches. > > It would be lovely to have a short tutorial on how we do > this written up and put in an easy-to-access place. > Branching still makes me nervous. > I'm also not familiar with branches. How do branches work in a Mercurial forest? Is it possible to easily develop on a branch if you need to push to different repositories within the whole sandbox forest (i.e. hotspot and jdk). Is it somehow possible to enforce the smae branch on all the repos in a forest? I agree that the OpenJDK project process is much too heavyweight for many smaller project, but in the end you always get a complete forest. I'm just curious if cross repository changes can be easily developed with branches. Thanks, Volker > David > From neugens.limasoftware at gmail.com Mon Sep 22 19:03:23 2014 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Mon, 22 Sep 2014 21:03:23 +0200 Subject: RFC: JDK 9 Sandbox Forest Proposal In-Reply-To: References: Message-ID: I also think that if we start using branches, it will end up being more overhead than using multiple mercurial repositories... Cheers, Mario 2014-09-22 10:38 GMT+02:00 Volker Simonis : > On Sun, Sep 21, 2014 at 4:41 PM, David Chase wrote: >> I vote yes, I have some feedback/questions on the proposal: >> >> On 2014-09-19, at 1:15 PM, Mike Duigou wrote: >>> Goals: >>> >>> - Open : Use OpenJDK public infrastructure >>> - Low-friction : Minimal start-cost and no delays >> >> I ran into one specific problem attempting to add stuff to >> jdk libraries as part of Panama, which is that the creation >> of a new module is error-prone. In my case, it is only >> error-prone, I never succeeded, I assume I missed some >> crucial step. I think we want people to be able to work in >> this style because at least one of the IDE tools (NetBeans) >> can sometimes get confused when working with a subset of the >> source files in java.base. (and even when it works, it?s another >> little speedbump on the way to configure NetBeans to work >> properly in this case) >> >> So I think we need to address this and write up a recipe, >> including the need to regenerate configure files etc before >> commit. Ideally the recipe will contain copy-and-pasteable >> commands where that is possible. >> >>> Specifics: >> >>> - Neither jcheck nor hgupdater is enabled for this forest. >> >> Do we want something like jcheck to keep the code moderately >> clean ? for example, there?s the personal ?fixit? script >> I?ve informally put up for consideration for Codetools (it?s >> not a commit hook, it merely checks a bunch of source code >> rules and gives you the the option of an automated fix). >> This is purely a matter of keeping code clean, on the off >> chance that we do include some of it in a future release. >> >>> - All development happens on branches. >> >> It would be lovely to have a short tutorial on how we do >> this written up and put in an easy-to-access place. >> Branching still makes me nervous. >> > > I'm also not familiar with branches. How do branches work in a > Mercurial forest? Is it possible to easily develop on a branch if you > need to push to different repositories within the whole sandbox forest > (i.e. hotspot and jdk). Is it somehow possible to enforce the smae > branch on all the repos in a forest? I agree that the OpenJDK project > process is much too heavyweight for many smaller project, but in the > end you always get a complete forest. I'm just curious if cross > repository changes can be easily developed with branches. > > Thanks, > Volker > >> David >> -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ Read About us at: http://planet.classpath.org OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/