From neugens at redhat.com Mon Aug 4 08:41:22 2014 From: neugens at redhat.com (Mario Torre) Date: Mon, 04 Aug 2014 10:41:22 +0200 Subject: A pkg-config file for OpenJDK In-Reply-To: <53B1503E.7000302@oracle.com> References: <20140626145657.GA2761@redhat.com> <53AD18C9.7070405@oracle.com> <53AD2371.10702@redhat.com> <53B1455D.2000201@oracle.com> <53B14A02.9050905@oracle.com> <53B1503E.7000302@oracle.com> Message-ID: <1407141682.3406.1.camel@nirvana.localdomain> On Mon, 2014-06-30 at 13:55 +0200, dalibor topic wrote: > There was some chatter about packaging OpenJDK 8 profiles on the > debian-java mailing list a few weeks ago.[0] > > Assuming a pkg-config file gets included and installed as part of an > OpenJDK build, I'm just curious if that would cause additional issues to > consider in the case of compact profiles (which may end up being > dpkg/rpm installed in different locations, for example - I can't really > say, since Debian packages haven't hit the repos yet). But I think this is really a packaging issues, upstream should not be concerned that much, other than trying to involve downstream in the process to be as friendly as possible. If compact profiles are an issue, I would say that OpenJDK should ship with a pkg-config for each of the profiles. The whole point of pkg-config is to not worry about where things are installed and what the linking/flags options are, you only need to know the package name, which should be standard across distros. > There is also the side question of how/if this would (need to) work on > other platforms (Solaris, OS X, Windows) which pkg-config claims to work > on. [1] Again, I think this is a job done by pkg-config itself on the specific system, so tweaking the specific content is a distributor responsibility, what OpenJDK should ship is just the template[s]. Cheers, Mario From dalibor.topic at oracle.com Tue Aug 5 15:42:25 2014 From: dalibor.topic at oracle.com (dalibor topic) Date: Tue, 05 Aug 2014 17:42:25 +0200 Subject: A pkg-config file for OpenJDK In-Reply-To: <1407141682.3406.1.camel@nirvana.localdomain> References: <20140626145657.GA2761@redhat.com> <53AD18C9.7070405@oracle.com> <53AD2371.10702@redhat.com> <53B1455D.2000201@oracle.com> <53B14A02.9050905@oracle.com> <53B1503E.7000302@oracle.com> <1407141682.3406.1.camel@nirvana.localdomain> Message-ID: <53E0FB61.2050309@oracle.com> On 04.08.2014 10:41, Mario Torre wrote: > If compact profiles are an issue, I would say that OpenJDK should ship > with a pkg-config for each of the profiles. OK, now let's assume that multiple profiles are installed in parallel. ;) Or, for a not too unusual setup, that multiple JDK/JRE versions are installed in parallel. How does pkg-config pick the 'right' one to link against? Does the first one to install the OpenJDK .pc file win? The last one? Does one need a different .pc file for each major version? For each minor version? If I'm parsing https://bugzilla.redhat.com/show_bug.cgi?id=740762#c27 right it seems that the design of the feature in the context of Fedora is still under discussion. > The whole point of pkg-config is to not worry about where things are > installed and what the linking/flags options are, you only need to know > the package name, which should be standard across distros. OpenJDK 8u typically gets packaged as "openjdk-8" on Debian derived distributions, "java-1.8.0-openjdk" on Fedora derived ones, and presumably something else somewhere else. In addition, the distributions tend to split OpenJDK packages in different ways - See java-1.8.0-openjdk-accessibility java-1.8.0-openjdk-demo java-1.8.0-openjdk-devel java-1.8.0-openjdk-headless java-1.8.0-openjdk-javadoc java-1.8.0-openjdk-src vs. openjdk-8-dbg openjdk-8-demo openjdk-8-doc openjdk-8-jdk openjdk-8-jre openjdk-8-jre-headless openjdk-8-jre-jamvm openjdk-8-jre-zero openjdk-8-source for a Fedora vs. Debian comparison. cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 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 Oracle is committed to developing practices and products that help protect the environment From neugens at redhat.com Tue Aug 5 16:03:15 2014 From: neugens at redhat.com (Mario Torre) Date: Tue, 05 Aug 2014 18:03:15 +0200 Subject: A pkg-config file for OpenJDK In-Reply-To: <53E0FB61.2050309@oracle.com> References: <20140626145657.GA2761@redhat.com> <53AD18C9.7070405@oracle.com> <53AD2371.10702@redhat.com> <53B1455D.2000201@oracle.com> <53B14A02.9050905@oracle.com> <53B1503E.7000302@oracle.com> <1407141682.3406.1.camel@nirvana.localdomain> <53E0FB61.2050309@oracle.com> Message-ID: <1407254595.3406.9.camel@nirvana.localdomain> On Tue, 2014-08-05 at 17:42 +0200, dalibor topic wrote: > On 04.08.2014 10:41, Mario Torre wrote: > > If compact profiles are an issue, I would say that OpenJDK should ship > > with a pkg-config for each of the profiles. > > OK, now let's assume that multiple profiles are installed in parallel. ;) > > Or, for a not too unusual setup, that multiple JDK/JRE versions are > installed in parallel. > > How does pkg-config pick the 'right' one to link against? Does the first > one to install the OpenJDK .pc file win? The last one? Does one need a > different .pc file for each major version? For each minor version? > > If I'm parsing https://bugzilla.redhat.com/show_bug.cgi?id=740762#c27 > right it seems that the design of the feature in the context of Fedora > is still under discussion. > > > The whole point of pkg-config is to not worry about where things are > > installed and what the linking/flags options are, you only need to know > > the package name, which should be standard across distros. > > OpenJDK 8u typically gets packaged as "openjdk-8" on Debian derived > distributions, "java-1.8.0-openjdk" on Fedora derived ones, and > presumably something else somewhere else. > > In addition, the distributions tend to split OpenJDK packages in > different ways - See > > java-1.8.0-openjdk-accessibility > java-1.8.0-openjdk-demo > java-1.8.0-openjdk-devel > java-1.8.0-openjdk-headless > java-1.8.0-openjdk-javadoc > java-1.8.0-openjdk-src > > vs. > > openjdk-8-dbg > openjdk-8-demo > openjdk-8-doc > openjdk-8-jdk > openjdk-8-jre > openjdk-8-jre-headless > openjdk-8-jre-jamvm > openjdk-8-jre-zero > openjdk-8-source > > for a Fedora vs. Debian comparison. Yeah, I see your point, but this is what I meant before by "those are packaging problems", OpenJDK should not be concerned, imho. The only issue OpenJDK should probably address is the naming of itself in the pkg-config template, since this should likely be standard, then everything else will be decided at packaging level[1]. Probably Omair can help us here to better understand what OpenJDK as upstream could do though, since he has more packaging experience than I do, I would also love some feedback from the Debian packagers (or any other distribution that can help her). Cheers, Mario [1] Unless you're going to do the packaging in Debian, then I see why you want to know the answer to those tricky questions ;) From omajid at redhat.com Mon Aug 11 17:13:04 2014 From: omajid at redhat.com (Omair Majid) Date: Mon, 11 Aug 2014 13:13:04 -0400 Subject: A pkg-config file for OpenJDK In-Reply-To: <1407254595.3406.9.camel@nirvana.localdomain> References: <20140626145657.GA2761@redhat.com> <53AD18C9.7070405@oracle.com> <53AD2371.10702@redhat.com> <53B1455D.2000201@oracle.com> <53B14A02.9050905@oracle.com> <53B1503E.7000302@oracle.com> <1407141682.3406.1.camel@nirvana.localdomain> <53E0FB61.2050309@oracle.com> <1407254595.3406.9.camel@nirvana.localdomain> Message-ID: <20140811171303.GD2136@redhat.com> * Mario Torre [2014-08-05 12:05]: > On Tue, 2014-08-05 at 17:42 +0200, dalibor topic wrote: > > On 04.08.2014 10:41, Mario Torre wrote: > > > If compact profiles are an issue, I would say that OpenJDK should ship > > > with a pkg-config for each of the profiles. > > > > OK, now let's assume that multiple profiles are installed in parallel. ;) > > > > Or, for a not too unusual setup, that multiple JDK/JRE versions are > > installed in parallel. > > > > How does pkg-config pick the 'right' one to link against? Does the first > > one to install the OpenJDK .pc file win? The last one? Does one need a > > different .pc file for each major version? For each minor version? I would expect that something like this would be handled similar to how the selection of the correct `java` program is handled in Linux distributions. In case of Fedora, there would be a .pc file for each major version, and the latest installed JDK would 'win'. > > If I'm parsing https://bugzilla.redhat.com/show_bug.cgi?id=740762#c27 > > right it seems that the design of the feature in the context of Fedora > > is still under discussion. Yes, that's true. It looks like some people disagree that a pkg-config file is the right solution. I would like to withdraw this patch for the time being (and possibly resubmit if we (or other distributions) decide it's useful). > > > The whole point of pkg-config is to not worry about where things are > > > installed and what the linking/flags options are, you only need to know > > > the package name, which should be standard across distros. > > > > OpenJDK 8u typically gets packaged as "openjdk-8" on Debian derived > > distributions, "java-1.8.0-openjdk" on Fedora derived ones, and > > presumably something else somewhere else. One of the goals of this pkg-config file is to have a standard 'name': irrespective of your distribution, there would be one name for the pkg-config file that is decided by OpenJDK (that's us here on this mailing list). A distribution can call their package openjdk-8.0 and it would still use the same well-known-name for the pkg-config file. > > In addition, the distributions tend to split OpenJDK packages in > > different ways - See > > > > java-1.8.0-openjdk-accessibility > > java-1.8.0-openjdk-demo > > java-1.8.0-openjdk-devel > > java-1.8.0-openjdk-headless > > java-1.8.0-openjdk-javadoc > > java-1.8.0-openjdk-src > > > > vs. > > > > openjdk-8-dbg > > openjdk-8-demo > > openjdk-8-doc > > openjdk-8-jdk > > openjdk-8-jre > > openjdk-8-jre-headless > > openjdk-8-jre-jamvm > > openjdk-8-jre-zero > > openjdk-8-source > > > > for a Fedora vs. Debian comparison. One thing to note is that this pkg-config file is meant for those compiling (Java and C) code. It is expected that they will need `javac` installed. This is provided by java-1.8.0-openjdk-devel and openjdk-8-jdk in the list above. And both those packages pull down a working JRE too. So, even though the packages are split in funny ways, installing the package that installs javac gets you a working JRE too, and that's basically all you need if you are building Java code. It should really be enough for the pkg-config file too. Other distributions seem to use a similar packaging style: unless there's a monolithic package, the jdk package requires the jre package and builds on that to give everything that's required for someone who wants to compile Java code. > The only issue OpenJDK should probably address is the naming of itself > in the pkg-config template, since this should likely be standard, then > everything else will be decided at packaging level[1]. > > Probably Omair can help us here to better understand what OpenJDK as > upstream could do though, since he has more packaging experience than I > do, I would also love some feedback from the Debian packagers (or any > other distribution that can help her). I have cc'ed Emmanuel Bourg, who is one of the maintainers of OpenJDK 8 in Debian. Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From omajid at redhat.com Tue Aug 26 20:33:01 2014 From: omajid at redhat.com (Omair Majid) Date: Tue, 26 Aug 2014 16:33:01 -0400 Subject: CFV: New Project Kulla In-Reply-To: <53FCC16D.20904@oracle.com> References: <53FCC16D.20904@oracle.com> Message-ID: <20140826203300.GD3617@redhat.com> Vote: Yes * Robert Field [2014-08-26 16:23]: > I hereby propose the creation of Project Kulla [1] with myself as the > Lead and the Compiler Group group as the sponsoring group. > > The goal of the Kulla project is to investigate the creation of a > Read Evaluate Print Loop (REPL) tool for the Java programming > language. For more details see the JEP [2]. Cheers, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From richard.bair at oracle.com Tue Aug 26 21:11:34 2014 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 26 Aug 2014 14:11:34 -0700 Subject: CFV: New Project Kulla In-Reply-To: <53FCC16D.20904@oracle.com> References: <53FCC16D.20904@oracle.com> Message-ID: <00273B82-30BF-4F1B-86E9-AE2C0776FF66@oracle.com> I looked at the JEP, but I didn?t see anything detailing the level of effort. From the list of committers it looks to be massive. Richard On Aug 26, 2014, at 10:18 AM, Robert Field wrote: > I hereby propose the creation of Project Kulla [1] with myself as the > Lead and the Compiler Group group as the sponsoring group. > > The goal of the Kulla project is to investigate the creation of a > Read Evaluate Print Loop (REPL) tool for the Java programming > language. For more details see the JEP [2]. > > The initial Committers will be: > > * Robert Field > * Steve Sides > * Jonathan Gibbons > * Brian Goetz > * Alex Buckley > * Mark Reinhold > * Maurizio Cimadamore > * Vicente Romero > * Jan Lahoda > * Paul Govereau > * Joe Darcy > * Dan Smith > * Iris Clark > * Andrew Gross > * Eric McCorkle > * Joel Borggr?n-Franck > * John R Rose > * Kumar Srinivasan > * Andreas Lundblad > > The project will host at least the following mailing list: > > * kulla-dev for developers > > and may eventually host specification lists if one or more JSRs is > subsequently created. > > The initial source of this project will include some code cloned from > the JDK 9 repository. We will follow a "commit first, review later" > policy, as any inclusion in the JDK repositories will be done by a > "curated merge" where select changes are extracted into new > changesets for incorporation into JDK repositories when they are ready > for inclusion. > > Votes are due by September 10, 2014, 9A GMT. > > Only current OpenJDK Members [3] are eligible to vote on this > motion. Votes must be cast in the open on the discuss list. > Replying to this message is sufficient if your mail program > honors the Reply-To header. > > For Lazy Consensus voting instructions, see [4]. > > > [1] http://openjdk.java.net/projects/#new-project > [2] https://bugs.openjdk.java.net/browse/JDK-8043364 > [3] http://openjdk.java.net/census#members > [4] http://openjdk.java.net/projects/#new-project-vote From neugens.limasoftware at gmail.com Tue Aug 26 21:33:07 2014 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Tue, 26 Aug 2014 23:33:07 +0200 Subject: CFV: New Project Kulla In-Reply-To: <00273B82-30BF-4F1B-86E9-AE2C0776FF66@oracle.com> References: <53FCC16D.20904@oracle.com> <00273B82-30BF-4F1B-86E9-AE2C0776FF66@oracle.com> Message-ID: Yes, and although discussion before proposal is not mandatory, a project of this scale (and importance) should have been discussed a bit in advance I think. The main problem here is that the JEP bug doesn't really contain much details, from the look of it seems like a trivial walk in the park, but then the list of high profile initial contributors is massive. I understand it's mostly a research stage now... Anyway will you investigate runtime code generation? (From the jep it seems likely). What security implications will this have? Will this functionality require a "dev environment", some sort of beanshell for example, or be available on every standard JVM (that is, enabling some kind hot plugging of interpreted code on a server deployment)? Cheers, Mario Il 26/ago/2014 23:12 "Richard Bair" ha scritto: > I looked at the JEP, but I didn?t see anything detailing the level of > effort. From the list of committers it looks to be massive. > > Richard > > On Aug 26, 2014, at 10:18 AM, Robert Field > wrote: > > > I hereby propose the creation of Project Kulla [1] with myself as the > > Lead and the Compiler Group group as the sponsoring group. > > > > The goal of the Kulla project is to investigate the creation of a > > Read Evaluate Print Loop (REPL) tool for the Java programming > > language. For more details see the JEP [2]. > > > > The initial Committers will be: > > > > * Robert Field > > * Steve Sides > > * Jonathan Gibbons > > * Brian Goetz > > * Alex Buckley > > * Mark Reinhold > > * Maurizio Cimadamore > > * Vicente Romero > > * Jan Lahoda > > * Paul Govereau > > * Joe Darcy > > * Dan Smith > > * Iris Clark > > * Andrew Gross > > * Eric McCorkle > > * Joel Borggr?n-Franck > > * John R Rose > > * Kumar Srinivasan > > * Andreas Lundblad > > > > The project will host at least the following mailing list: > > > > * kulla-dev for developers > > > > and may eventually host specification lists if one or more JSRs is > > subsequently created. > > > > The initial source of this project will include some code cloned from > > the JDK 9 repository. We will follow a "commit first, review later" > > policy, as any inclusion in the JDK repositories will be done by a > > "curated merge" where select changes are extracted into new > > changesets for incorporation into JDK repositories when they are ready > > for inclusion. > > > > Votes are due by September 10, 2014, 9A GMT. > > > > Only current OpenJDK Members [3] are eligible to vote on this > > motion. Votes must be cast in the open on the discuss list. > > Replying to this message is sufficient if your mail program > > honors the Reply-To header. > > > > For Lazy Consensus voting instructions, see [4]. > > > > > > [1] http://openjdk.java.net/projects/#new-project > > [2] https://bugs.openjdk.java.net/browse/JDK-8043364 > > [3] http://openjdk.java.net/census#members > > [4] http://openjdk.java.net/projects/#new-project-vote > > From brian.goetz at oracle.com Tue Aug 26 21:49:50 2014 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 26 Aug 2014 17:49:50 -0400 Subject: CFV: New Project Kulla In-Reply-To: References: <53FCC16D.20904@oracle.com> <00273B82-30BF-4F1B-86E9-AE2C0776FF66@oracle.com> Message-ID: <53FD00FE.9080602@oracle.com> > Yes, and although discussion before proposal is not mandatory, a project of > this scale (and importance) should have been discussed a bit in advance I > think. I think you are vastly overestimating the scale. > The main problem here is that the JEP bug doesn't really contain much > details, from the look of it seems like a trivial walk in the park, but > then the list of high profile initial contributors is massive. You are reading way more into this than there is. These are simply the members of the compiler group who are Committers to jdk; this is done because any of these people *might* want to contribute. I think it is on this incorrect inference (many committers -> huge project) that your concerns in the first paragraph rest? From brian.goetz at oracle.com Tue Aug 26 21:50:52 2014 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 26 Aug 2014 17:50:52 -0400 Subject: CFV: New Project Kulla In-Reply-To: <20140826203300.GD3617@redhat.com> References: <53FCC16D.20904@oracle.com> <20140826203300.GD3617@redhat.com> Message-ID: <53FD013C.2080205@oracle.com> Vote: Yes > I hereby propose the creation of Project Kulla [1] with myself as the > Lead and the Compiler Group group as the sponsoring group. > > The goal of the Kulla project is to investigate the creation of a > Read Evaluate Print Loop (REPL) tool for the Java programming > language. For more details see the JEP [2]. From neugens.limasoftware at gmail.com Tue Aug 26 22:02:50 2014 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Wed, 27 Aug 2014 00:02:50 +0200 Subject: CFV: New Project Kulla In-Reply-To: <53FD00FE.9080602@oracle.com> References: <53FCC16D.20904@oracle.com> <00273B82-30BF-4F1B-86E9-AE2C0776FF66@oracle.com> <53FD00FE.9080602@oracle.com> Message-ID: Il 26/ago/2014 23:50 "Brian Goetz" ha scritto: >> >> Yes, and although discussion before proposal is not mandatory, a project of >> this scale (and importance) should have been discussed a bit in advance I >> think. > > > I think you are vastly overestimating the scale. :) there's not much details to base my estimation! > >> The main problem here is that the JEP bug doesn't really contain much >> details, from the look of it seems like a trivial walk in the park, but >> then the list of high profile initial contributors is massive. > > > You are reading way more into this than there is. These are simply the members of the compiler group who are Committers to jdk; this is done because any of these people *might* want to contribute. > > I think it is on this incorrect inference (many committers -> huge project) that your concerns in the first paragraph rest? Yeah, I was a bit surprised indeed (I guess like Richard?) Anyway, I didn't mean to vote no or veto or something, just wanted to know more about the proposal though. Cheers, Mario From john.r.rose at oracle.com Tue Aug 26 22:16:05 2014 From: john.r.rose at oracle.com (John Rose) Date: Tue, 26 Aug 2014 15:16:05 -0700 Subject: CFV: New Project Kulla In-Reply-To: <53FCC16D.20904@oracle.com> References: <53FCC16D.20904@oracle.com> Message-ID: <3ED2E4EA-535E-4FB5-AA19-EA01EB4FB738@oracle.com> Vote: yes ...but only if we use the right bricks: https://ideas.lego.com/projects/39077 :-) On Aug 26, 2014, at 10:18 AM, Robert Field wrote: > I hereby propose the creation of Project Kulla [1] with myself as the > Lead and the Compiler Group group as the sponsoring group From karen.kinnear at oracle.com Tue Aug 26 22:21:20 2014 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Tue, 26 Aug 2014 18:21:20 -0400 Subject: CFV: New Project Kulla In-Reply-To: <53FCC16D.20904@oracle.com> References: <53FCC16D.20904@oracle.com> Message-ID: <9E9FE243-0908-4F8F-B594-9F72400E3602@oracle.com> Vote: yes On Aug 26, 2014, at 1:18 PM, Robert Field wrote: > I hereby propose the creation of Project Kulla [1] with myself as the > Lead and the Compiler Group group as the sponsoring group. > > The goal of the Kulla project is to investigate the creation of a > Read Evaluate Print Loop (REPL) tool for the Java programming > language. For more details see the JEP [2]. > > The initial Committers will be: > > * Robert Field > * Steve Sides > * Jonathan Gibbons > * Brian Goetz > * Alex Buckley > * Mark Reinhold > * Maurizio Cimadamore > * Vicente Romero > * Jan Lahoda > * Paul Govereau > * Joe Darcy > * Dan Smith > * Iris Clark > * Andrew Gross > * Eric McCorkle > * Joel Borggr?n-Franck > * John R Rose > * Kumar Srinivasan > * Andreas Lundblad > > The project will host at least the following mailing list: > > * kulla-dev for developers > > and may eventually host specification lists if one or more JSRs is > subsequently created. > > The initial source of this project will include some code cloned from > the JDK 9 repository. We will follow a "commit first, review later" > policy, as any inclusion in the JDK repositories will be done by a > "curated merge" where select changes are extracted into new > changesets for incorporation into JDK repositories when they are ready > for inclusion. > > Votes are due by September 10, 2014, 9A GMT. > > Only current OpenJDK Members [3] are eligible to vote on this > motion. Votes must be cast in the open on the discuss list. > Replying to this message is sufficient if your mail program > honors the Reply-To header. > > For Lazy Consensus voting instructions, see [4]. > > > [1] http://openjdk.java.net/projects/#new-project > [2] https://bugs.openjdk.java.net/browse/JDK-8043364 > [3] http://openjdk.java.net/census#members > [4] http://openjdk.java.net/projects/#new-project-vote From kumar.x.srinivasan at oracle.com Tue Aug 26 22:26:47 2014 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Tue, 26 Aug 2014 15:26:47 -0700 Subject: CFV: New Project Kulla In-Reply-To: <53FCC16D.20904@oracle.com> References: <53FCC16D.20904@oracle.com> Message-ID: <53FD09A7.7060802@oracle.com> Vote: yes On 8/26/2014 10:18 AM, Robert Field wrote: > I hereby propose the creation of Project Kulla [1] with myself as the > Lead and the Compiler Group group as the sponsoring group. > > The goal of the Kulla project is to investigate the creation of a > Read Evaluate Print Loop (REPL) tool for the Java programming > language. For more details see the JEP [2]. > > The initial Committers will be: > > * Robert Field > * Steve Sides > * Jonathan Gibbons > * Brian Goetz > * Alex Buckley > * Mark Reinhold > * Maurizio Cimadamore > * Vicente Romero > * Jan Lahoda > * Paul Govereau > * Joe Darcy > * Dan Smith > * Iris Clark > * Andrew Gross > * Eric McCorkle > * Joel Borggr?n-Franck > * John R Rose > * Kumar Srinivasan > * Andreas Lundblad > > The project will host at least the following mailing list: > > * kulla-dev for developers > > and may eventually host specification lists if one or more JSRs is > subsequently created. > > The initial source of this project will include some code cloned from > the JDK 9 repository. We will follow a "commit first, review later" > policy, as any inclusion in the JDK repositories will be done by a > "curated merge" where select changes are extracted into new > changesets for incorporation into JDK repositories when they are ready > for inclusion. > > Votes are due by September 10, 2014, 9A GMT. > > Only current OpenJDK Members [3] are eligible to vote on this > motion. Votes must be cast in the open on the discuss list. > Replying to this message is sufficient if your mail program > honors the Reply-To header. > > For Lazy Consensus voting instructions, see [4]. > > > [1] http://openjdk.java.net/projects/#new-project > [2] https://bugs.openjdk.java.net/browse/JDK-8043364 > [3] http://openjdk.java.net/census#members > [4] http://openjdk.java.net/projects/#new-project-vote From richard.bair at oracle.com Tue Aug 26 22:33:38 2014 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 26 Aug 2014 15:33:38 -0700 Subject: CFV: New Project Kulla In-Reply-To: <53FD00FE.9080602@oracle.com> References: <53FCC16D.20904@oracle.com> <00273B82-30BF-4F1B-86E9-AE2C0776FF66@oracle.com> <53FD00FE.9080602@oracle.com> Message-ID: > I think it is on this incorrect inference (many committers -> huge project) that your concerns in the first paragraph rest? Yes. From jaroslav.bachorik at oracle.com Wed Aug 27 07:58:09 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 27 Aug 2014 09:58:09 +0200 Subject: CFV: New Project Kulla In-Reply-To: <53FCC16D.20904@oracle.com> References: <53FCC16D.20904@oracle.com> Message-ID: <53FD8F91.3020001@oracle.com> Vote: yes On Aug 26, 2014, at 1:18 PM, Robert Field wrote: > I hereby propose the creation of Project Kulla [1] with myself as the > Lead and the Compiler Group group as the sponsoring group. > > The goal of the Kulla project is to investigate the creation of a > Read Evaluate Print Loop (REPL) tool for the Java programming > language. For more details see the JEP [2]. > > The initial Committers will be: > > * Robert Field > * Steve Sides > * Jonathan Gibbons > * Brian Goetz > * Alex Buckley > * Mark Reinhold > * Maurizio Cimadamore > * Vicente Romero > * Jan Lahoda > * Paul Govereau > * Joe Darcy > * Dan Smith > * Iris Clark > * Andrew Gross > * Eric McCorkle > * Joel Borggr?n-Franck > * John R Rose > * Kumar Srinivasan > * Andreas Lundblad > > The project will host at least the following mailing list: > > * kulla-dev for developers > > and may eventually host specification lists if one or more JSRs is > subsequently created. > > The initial source of this project will include some code cloned from > the JDK 9 repository. We will follow a "commit first, review later" > policy, as any inclusion in the JDK repositories will be done by a > "curated merge" where select changes are extracted into new > changesets for incorporation into JDK repositories when they are ready > for inclusion. > > Votes are due by September 10, 2014, 9A GMT. > > Only current OpenJDK Members [3] are eligible to vote on this > motion. Votes must be cast in the open on the discuss list. > Replying to this message is sufficient if your mail program > honors the Reply-To header. > > For Lazy Consensus voting instructions, see [4]. > > > [1] http://openjdk.java.net/projects/#new-project > [2] https://bugs.openjdk.java.net/browse/JDK-8043364 > [3] http://openjdk.java.net/census#members > [4] http://openjdk.java.net/projects/#new-project-vote From mikael.gerdin at oracle.com Wed Aug 27 08:19:07 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 27 Aug 2014 10:19:07 +0200 Subject: CFV: New Project Kulla In-Reply-To: <53FCC16D.20904@oracle.com> References: <53FCC16D.20904@oracle.com> Message-ID: <1462253.2UPf8JbSUe@mgerdin03> Vote: yes On Tuesday 26 August 2014 10.18.37 Robert Field wrote: > I hereby propose the creation of Project Kulla [1] with myself as the > Lead and the Compiler Group group as the sponsoring group. > > The goal of the Kulla project is to investigate the creation of a > Read Evaluate Print Loop (REPL) tool for the Java programming > language. For more details see the JEP [2]. > > The initial Committers will be: > > * Robert Field > * Steve Sides > * Jonathan Gibbons > * Brian Goetz > * Alex Buckley > * Mark Reinhold > * Maurizio Cimadamore > * Vicente Romero > * Jan Lahoda > * Paul Govereau > * Joe Darcy > * Dan Smith > * Iris Clark > * Andrew Gross > * Eric McCorkle > * Joel Borggr?n-Franck > * John R Rose > * Kumar Srinivasan > * Andreas Lundblad > > The project will host at least the following mailing list: > > * kulla-dev for developers > > and may eventually host specification lists if one or more JSRs is > subsequently created. > > The initial source of this project will include some code cloned from > the JDK 9 repository. We will follow a "commit first, review later" > policy, as any inclusion in the JDK repositories will be done by a > "curated merge" where select changes are extracted into new > changesets for incorporation into JDK repositories when they are ready > for inclusion. > > Votes are due by September 10, 2014, 9A GMT. > > Only current OpenJDK Members [3] are eligible to vote on this > motion. Votes must be cast in the open on the discuss list. > Replying to this message is sufficient if your mail program > honors the Reply-To header. > > For Lazy Consensus voting instructions, see [4]. > > > [1] http://openjdk.java.net/projects/#new-project > [2] https://bugs.openjdk.java.net/browse/JDK-8043364 > [3] http://openjdk.java.net/census#members > [4] http://openjdk.java.net/projects/#new-project-vote From joel.franck at oracle.com Wed Aug 27 08:57:15 2014 From: joel.franck at oracle.com (Joel Borggren-Franck) Date: Wed, 27 Aug 2014 10:57:15 +0200 Subject: CFV: New Project Kulla In-Reply-To: <53FCC16D.20904@oracle.com> References: <53FCC16D.20904@oracle.com> Message-ID: <20140827085715.GA12844@oracle.com> Vote: yes cheers /Joel On 2014-08-26, Robert Field wrote: > I hereby propose the creation of Project Kulla [1] with myself as the > Lead and the Compiler Group group as the sponsoring group. > > The goal of the Kulla project is to investigate the creation of a > Read Evaluate Print Loop (REPL) tool for the Java programming > language. For more details see the JEP [2]. > > The initial Committers will be: > > * Robert Field > * Steve Sides > * Jonathan Gibbons > * Brian Goetz > * Alex Buckley > * Mark Reinhold > * Maurizio Cimadamore > * Vicente Romero > * Jan Lahoda > * Paul Govereau > * Joe Darcy > * Dan Smith > * Iris Clark > * Andrew Gross > * Eric McCorkle > * Joel Borggr?n-Franck > * John R Rose > * Kumar Srinivasan > * Andreas Lundblad > > The project will host at least the following mailing list: > > * kulla-dev for developers > > and may eventually host specification lists if one or more JSRs is > subsequently created. > > The initial source of this project will include some code cloned from > the JDK 9 repository. We will follow a "commit first, review later" > policy, as any inclusion in the JDK repositories will be done by a > "curated merge" where select changes are extracted into new > changesets for incorporation into JDK repositories when they are ready > for inclusion. > > Votes are due by September 10, 2014, 9A GMT. > > Only current OpenJDK Members [3] are eligible to vote on this > motion. Votes must be cast in the open on the discuss list. > Replying to this message is sufficient if your mail program > honors the Reply-To header. > > For Lazy Consensus voting instructions, see [4]. > > > [1] http://openjdk.java.net/projects/#new-project > [2] https://bugs.openjdk.java.net/browse/JDK-8043364 > [3] http://openjdk.java.net/census#members > [4] http://openjdk.java.net/projects/#new-project-vote From staffan.larsen at oracle.com Wed Aug 27 12:17:35 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 27 Aug 2014 14:17:35 +0200 Subject: CFV: New Project Kulla In-Reply-To: <53FCC16D.20904@oracle.com> References: <53FCC16D.20904@oracle.com> Message-ID: Vote: yes On 26 aug 2014, at 19:18, Robert Field wrote: > I hereby propose the creation of Project Kulla [1] with myself as the > Lead and the Compiler Group group as the sponsoring group. > > The goal of the Kulla project is to investigate the creation of a > Read Evaluate Print Loop (REPL) tool for the Java programming > language. For more details see the JEP [2]. > > The initial Committers will be: > > * Robert Field > * Steve Sides > * Jonathan Gibbons > * Brian Goetz > * Alex Buckley > * Mark Reinhold > * Maurizio Cimadamore > * Vicente Romero > * Jan Lahoda > * Paul Govereau > * Joe Darcy > * Dan Smith > * Iris Clark > * Andrew Gross > * Eric McCorkle > * Joel Borggr?n-Franck > * John R Rose > * Kumar Srinivasan > * Andreas Lundblad > > The project will host at least the following mailing list: > > * kulla-dev for developers > > and may eventually host specification lists if one or more JSRs is > subsequently created. > > The initial source of this project will include some code cloned from > the JDK 9 repository. We will follow a "commit first, review later" > policy, as any inclusion in the JDK repositories will be done by a > "curated merge" where select changes are extracted into new > changesets for incorporation into JDK repositories when they are ready > for inclusion. > > Votes are due by September 10, 2014, 9A GMT. > > Only current OpenJDK Members [3] are eligible to vote on this > motion. Votes must be cast in the open on the discuss list. > Replying to this message is sufficient if your mail program > honors the Reply-To header. > > For Lazy Consensus voting instructions, see [4]. > > > [1] http://openjdk.java.net/projects/#new-project > [2] https://bugs.openjdk.java.net/browse/JDK-8043364 > [3] http://openjdk.java.net/census#members > [4] http://openjdk.java.net/projects/#new-project-vote From Alan.Bateman at oracle.com Wed Aug 27 13:44:32 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 27 Aug 2014 14:44:32 +0100 Subject: CFV: New Project Kulla In-Reply-To: <53FCC16D.20904@oracle.com> References: <53FCC16D.20904@oracle.com> Message-ID: <53FDE0C0.8020901@oracle.com> On 26/08/2014 18:18, Robert Field wrote: > I hereby propose the creation of Project Kulla [1] with myself as the > Lead and the Compiler Group group as the sponsoring group. > Vote: yes From mark.reinhold at oracle.com Wed Aug 27 14:57:20 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 27 Aug 2014 07:57:20 -0700 Subject: CFV: New Project Kulla In-Reply-To: <53FCC16D.20904@oracle.com> References: <53FCC16D.20904@oracle.com> Message-ID: <20140827075720.434370@eggemoggin.niobe.net> Vote: yes - Mark From dalibor.topic at oracle.com Wed Aug 27 15:07:58 2014 From: dalibor.topic at oracle.com (dalibor topic) Date: Wed, 27 Aug 2014 17:07:58 +0200 Subject: CFV: New Project Kulla In-Reply-To: <53FCC16D.20904@oracle.com> References: <53FCC16D.20904@oracle.com> Message-ID: <53FDF44E.3060509@oracle.com> Vote: Yes. cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 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 Oracle is committed to developing practices and products that help protect the environment From joe.darcy at oracle.com Wed Aug 27 15:34:33 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 27 Aug 2014 08:34:33 -0700 Subject: CFV: New Project Kulla In-Reply-To: <53FCC16D.20904@oracle.com> References: <53FCC16D.20904@oracle.com> Message-ID: <53FDFA89.5060602@oracle.com> Vote: yes -Joe On 8/26/2014 10:18 AM, Robert Field wrote: > I hereby propose the creation of Project Kulla [1] with myself as the > Lead and the Compiler Group group as the sponsoring group. > > The goal of the Kulla project is to investigate the creation of a > Read Evaluate Print Loop (REPL) tool for the Java programming > language. For more details see the JEP [2]. > > The initial Committers will be: > > * Robert Field > * Steve Sides > * Jonathan Gibbons > * Brian Goetz > * Alex Buckley > * Mark Reinhold > * Maurizio Cimadamore > * Vicente Romero > * Jan Lahoda > * Paul Govereau > * Joe Darcy > * Dan Smith > * Iris Clark > * Andrew Gross > * Eric McCorkle > * Joel Borggr?n-Franck > * John R Rose > * Kumar Srinivasan > * Andreas Lundblad > > The project will host at least the following mailing list: > > * kulla-dev for developers > > and may eventually host specification lists if one or more JSRs is > subsequently created. > > The initial source of this project will include some code cloned from > the JDK 9 repository. We will follow a "commit first, review later" > policy, as any inclusion in the JDK repositories will be done by a > "curated merge" where select changes are extracted into new > changesets for incorporation into JDK repositories when they are ready > for inclusion. > > Votes are due by September 10, 2014, 9A GMT. > > Only current OpenJDK Members [3] are eligible to vote on this > motion. Votes must be cast in the open on the discuss list. > Replying to this message is sufficient if your mail program > honors the Reply-To header. > > For Lazy Consensus voting instructions, see [4]. > > > [1] http://openjdk.java.net/projects/#new-project > [2] https://bugs.openjdk.java.net/browse/JDK-8043364 > [3] http://openjdk.java.net/census#members > [4] http://openjdk.java.net/projects/#new-project-vote From neugens at redhat.com Wed Aug 27 15:56:56 2014 From: neugens at redhat.com (Mario Torre) Date: Wed, 27 Aug 2014 17:56:56 +0200 Subject: Possible new project: OpenJDK LaF Message-ID: <1409155016.25913.6.camel@nirvana.localdomain> Hi all, First of all, sorry for cross posting... I would like to kindly ask to direct all the replies to this thread to the "discuss" alias if possible. Is a bit of time I'm playing with the idea of implementing a proper GTK3 look and feel for OpenJDK, something to make the jdk look a bit more modern and also take it as an opportunity to solve some of the issues the GTK2 laf has, including some related bugs like this: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=729 I mentored a Summer of Code project last year where we produced a more or less working and complete implementation. It was a student project and the efforts to make it well abstracted and tested are really as close as making a new implementation, however it was great to show that we could have a basic and functional implementation in less than a month of work, the new GTK3 library looks way nicer! At the same time, since Swing will be [very] gradually replaced by JavaFX, I think it would be awesome to have a JavaFX based look and feel, something I started to play with last year as well but then put on hold because of tons of other things to do: https://neugens.wordpress.com/2013/07/21/javafx-look-and-feel-for-swing/ Recently I was convinced though that we should move forward with the Java laf: Swing has still lots to say, and JavaFX is not yet as integrated with OpenJDK as it should be (especially in Linux distribution, although is more popular within the OSX and Windows communities), but before I move forward (and get to propose a JEP for this) I would like some early feedback and gather some ideas/potential interest :) Another possible implementation would be based on QT, which is even cross platform by itself. So to recap, what are your feelings about an official OpenJDK look and feel collection? Cheers, Mario From martijnverburg at gmail.com Wed Aug 27 16:03:42 2014 From: martijnverburg at gmail.com (Martijn Verburg) Date: Wed, 27 Aug 2014 17:03:42 +0100 Subject: Possible new project: OpenJDK LaF In-Reply-To: <1409155016.25913.6.camel@nirvana.localdomain> References: <1409155016.25913.6.camel@nirvana.localdomain> Message-ID: I think a move to GTK 3 would eliminate a class of java/Linux desktop issues we run across today. My concern would be the long term maintenance of this piece... On Wednesday, 27 August 2014, Mario Torre wrote: > Hi all, > > First of all, sorry for cross posting... I would like to kindly ask to > direct all the replies to this thread to the "discuss" alias if > possible. > > Is a bit of time I'm playing with the idea of implementing a proper GTK3 > look and feel for OpenJDK, something to make the jdk look a bit more > modern and also take it as an opportunity to solve some of the issues > the GTK2 laf has, including some related bugs like this: > > http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=729 > > I mentored a Summer of Code project last year where we produced a more > or less working and complete implementation. It was a student project > and the efforts to make it well abstracted and tested are really as > close as making a new implementation, however it was great to show that > we could have a basic and functional implementation in less than a month > of work, the new GTK3 library looks way nicer! > > At the same time, since Swing will be [very] gradually replaced by > JavaFX, I think it would be awesome to have a JavaFX based look and > feel, something I started to play with last year as well but then put on > hold because of tons of other things to do: > > https://neugens.wordpress.com/2013/07/21/javafx-look-and-feel-for-swing/ > > Recently I was convinced though that we should move forward with the > Java laf: Swing has still lots to say, and JavaFX is not yet as > integrated with OpenJDK as it should be (especially in Linux > distribution, although is more popular within the OSX and Windows > communities), but before I move forward (and get to propose a JEP for > this) I would like some early feedback and gather some ideas/potential > interest :) > > Another possible implementation would be based on QT, which is even > cross platform by itself. > > So to recap, what are your feelings about an official OpenJDK look and > feel collection? > > Cheers, > Mario > > > -- Cheers, Martijn From maurizio.cimadamore at oracle.com Wed Aug 27 17:17:08 2014 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 27 Aug 2014 18:17:08 +0100 Subject: CFV: New Project Kulla In-Reply-To: <53FCC16D.20904@oracle.com> References: <53FCC16D.20904@oracle.com> Message-ID: <53FE1294.9040805@oracle.com> Vote: yes! Maurizio On 26/08/14 18:18, Robert Field wrote: > I hereby propose the creation of Project Kulla [1] with myself as the > Lead and the Compiler Group group as the sponsoring group. > > The goal of the Kulla project is to investigate the creation of a > Read Evaluate Print Loop (REPL) tool for the Java programming > language. For more details see the JEP [2]. > > The initial Committers will be: > > * Robert Field > * Steve Sides > * Jonathan Gibbons > * Brian Goetz > * Alex Buckley > * Mark Reinhold > * Maurizio Cimadamore > * Vicente Romero > * Jan Lahoda > * Paul Govereau > * Joe Darcy > * Dan Smith > * Iris Clark > * Andrew Gross > * Eric McCorkle > * Joel Borggr?n-Franck > * John R Rose > * Kumar Srinivasan > * Andreas Lundblad > > The project will host at least the following mailing list: > > * kulla-dev for developers > > and may eventually host specification lists if one or more JSRs is > subsequently created. > > The initial source of this project will include some code cloned from > the JDK 9 repository. We will follow a "commit first, review later" > policy, as any inclusion in the JDK repositories will be done by a > "curated merge" where select changes are extracted into new > changesets for incorporation into JDK repositories when they are ready > for inclusion. > > Votes are due by September 10, 2014, 9A GMT. > > Only current OpenJDK Members [3] are eligible to vote on this > motion. Votes must be cast in the open on the discuss list. > Replying to this message is sufficient if your mail program > honors the Reply-To header. > > For Lazy Consensus voting instructions, see [4]. > > > [1] http://openjdk.java.net/projects/#new-project > [2] https://bugs.openjdk.java.net/browse/JDK-8043364 > [3] http://openjdk.java.net/census#members > [4] http://openjdk.java.net/projects/#new-project-vote From neugens at redhat.com Thu Aug 28 10:04:46 2014 From: neugens at redhat.com (Mario Torre) Date: Thu, 28 Aug 2014 12:04:46 +0200 Subject: Possible new project: OpenJDK LaF In-Reply-To: References: <1409155016.25913.6.camel@nirvana.localdomain> Message-ID: <1409220286.25913.8.camel@nirvana.localdomain> On Wed, 2014-08-27 at 17:03 +0100, Martijn Verburg wrote: > I think a move to GTK 3 would eliminate a class of java/Linux desktop > issues we run across today. My concern would be the long term maintenance > of this piece... Yeah, long term maintenance will surely be some overhead, like anything that is added to the jdk. The way I would target the development is to try to respect the common denominator that works in the most important Linux distribution in their long term support releases (Ubuntu LTS, RHEL 7 and derivatives, etc...). Those distributions have very long term support so it should not be a big problem with moving gtk version. For other variants, where gtk may be more of a moving target, we need to count on users of those system to help out, and we need to talk with gtk maintainers to ensure there's a compatible set of features we need. Eclipse and Mozilla have the same problem and from time to time it comes back to byte them, but that's the way it is unfortunately. I think we should also ensure that the look and feel can be swapped out without harm, for example, avoiding that if the Gnome team ends up rewriting things for the fun of it again, and gtk4 comes out, we can just deploy the gtk3 version of the laf, together with the gtk2 and with whatever the future gives us without it interfere (that is, if is not used, it's like dead code, no classes loaded, no code touched at runtime, nothing). That basically means a very self contained look and feel, which is great because it could be eventually used even on older JDK without troubles as a plugin. Also, I don't thing I would like to make this the default theme (which will be forever Metal) and not even the default native theme, but having some way to configure a system wide default would be neat (I think there's already some flags to drive the selection of the default native theme, never really tried out how this works though). Cheers, Mario > On Wednesday, 27 August 2014, Mario Torre wrote: > > > Hi all, > > > > First of all, sorry for cross posting... I would like to kindly ask to > > direct all the replies to this thread to the "discuss" alias if > > possible. > > > > Is a bit of time I'm playing with the idea of implementing a proper GTK3 > > look and feel for OpenJDK, something to make the jdk look a bit more > > modern and also take it as an opportunity to solve some of the issues > > the GTK2 laf has, including some related bugs like this: > > > > http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=729 > > > > I mentored a Summer of Code project last year where we produced a more > > or less working and complete implementation. It was a student project > > and the efforts to make it well abstracted and tested are really as > > close as making a new implementation, however it was great to show that > > we could have a basic and functional implementation in less than a month > > of work, the new GTK3 library looks way nicer! > > > > At the same time, since Swing will be [very] gradually replaced by > > JavaFX, I think it would be awesome to have a JavaFX based look and > > feel, something I started to play with last year as well but then put on > > hold because of tons of other things to do: > > > > https://neugens.wordpress.com/2013/07/21/javafx-look-and-feel-for-swing/ > > > > Recently I was convinced though that we should move forward with the > > Java laf: Swing has still lots to say, and JavaFX is not yet as > > integrated with OpenJDK as it should be (especially in Linux > > distribution, although is more popular within the OSX and Windows > > communities), but before I move forward (and get to propose a JEP for > > this) I would like some early feedback and gather some ideas/potential > > interest :) > > > > Another possible implementation would be based on QT, which is even > > cross platform by itself. > > > > So to recap, what are your feelings about an official OpenJDK look and > > feel collection? > > > > Cheers, > > Mario > > > > > > > From mihamina.rakotomandimby at rktmb.org Thu Aug 28 11:22:09 2014 From: mihamina.rakotomandimby at rktmb.org (Mihamina Rakotomandimby) Date: Thu, 28 Aug 2014 14:22:09 +0300 Subject: Possible new project: OpenJDK LaF In-Reply-To: <1409155016.25913.6.camel@nirvana.localdomain> References: <1409155016.25913.6.camel@nirvana.localdomain> Message-ID: <53FF10E1.3000805@rktmb.org> On 08/27/2014 06:56 PM, Mario Torre wrote: > I mentored a Summer of Code project last year where we produced a more > or less working and complete implementation. It was a student project > and the efforts to make it well abstracted and tested are really as > close as making a new implementation, however it was great to show that > we could have a basic and functional implementation in less than a month > of work, the new GTK3 library looks way nicer! Although not being a developper, I am a GTK lover and a GTK3 step looks nice to me :-) From steve.x.northover at oracle.com Thu Aug 28 15:20:51 2014 From: steve.x.northover at oracle.com (Stephen F Northover) Date: Thu, 28 Aug 2014 11:20:51 -0400 Subject: Possible new project: OpenJDK LaF In-Reply-To: <1409155016.25913.6.camel@nirvana.localdomain> References: <1409155016.25913.6.camel@nirvana.localdomain> Message-ID: <53FF48D3.2010103@oracle.com> It makes sense to move to GTK3. This is the latest UI technology for GTK and where the focus will go for future development. Eclipse has already moved to GTK3 (but remains compatible with GTK2 when GTK3 is not installed). Steve On 2014-08-27, 11:56 AM, Mario Torre wrote: > Hi all, > > First of all, sorry for cross posting... I would like to kindly ask to > direct all the replies to this thread to the "discuss" alias if > possible. > > Is a bit of time I'm playing with the idea of implementing a proper GTK3 > look and feel for OpenJDK, something to make the jdk look a bit more > modern and also take it as an opportunity to solve some of the issues > the GTK2 laf has, including some related bugs like this: > > http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=729 > > I mentored a Summer of Code project last year where we produced a more > or less working and complete implementation. It was a student project > and the efforts to make it well abstracted and tested are really as > close as making a new implementation, however it was great to show that > we could have a basic and functional implementation in less than a month > of work, the new GTK3 library looks way nicer! > > At the same time, since Swing will be [very] gradually replaced by > JavaFX, I think it would be awesome to have a JavaFX based look and > feel, something I started to play with last year as well but then put on > hold because of tons of other things to do: > > https://neugens.wordpress.com/2013/07/21/javafx-look-and-feel-for-swing/ > > Recently I was convinced though that we should move forward with the > Java laf: Swing has still lots to say, and JavaFX is not yet as > integrated with OpenJDK as it should be (especially in Linux > distribution, although is more popular within the OSX and Windows > communities), but before I move forward (and get to propose a JEP for > this) I would like some early feedback and gather some ideas/potential > interest :) > > Another possible implementation would be based on QT, which is even > cross platform by itself. > > So to recap, what are your feelings about an official OpenJDK look and > feel collection? > > Cheers, > Mario > > From thomas.wuerthinger at oracle.com Fri Aug 29 09:31:02 2014 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Fri, 29 Aug 2014 11:31:02 +0200 Subject: CFV: New Project Kulla In-Reply-To: <53FD00FE.9080602@oracle.com> References: <53FCC16D.20904@oracle.com> <00273B82-30BF-4F1B-86E9-AE2C0776FF66@oracle.com> <53FD00FE.9080602@oracle.com> Message-ID: I think assuming a correlation between number of committers and project size is reasonable. What is the planned relationship of this project with this existing open source Java REPL http://www.javarepl.com/console.html? Thanks, thomas On 26 Aug 2014, at 23:49, Brian Goetz wrote: >> Yes, and although discussion before proposal is not mandatory, a project of >> this scale (and importance) should have been discussed a bit in advance I >> think. > > I think you are vastly overestimating the scale. > >> The main problem here is that the JEP bug doesn't really contain much >> details, from the look of it seems like a trivial walk in the park, but >> then the list of high profile initial contributors is massive. > > You are reading way more into this than there is. These are simply the members of the compiler group who are Committers to jdk; this is done because any of these people *might* want to contribute. > > I think it is on this incorrect inference (many committers -> huge project) that your concerns in the first paragraph rest? > From daniel.latremoliere at gmail.com Fri Aug 29 20:33:27 2014 From: daniel.latremoliere at gmail.com (=?ISO-8859-1?Q?Daniel_Latr=E9moli=E8re?=) Date: Fri, 29 Aug 2014 22:33:27 +0200 Subject: CFV: New Project Kulla In-Reply-To: <53FCC16D.20904@oracle.com> References: <53FCC16D.20904@oracle.com> Message-ID: <5400E397.1080802@gmail.com> > The goal of the Kulla project is to investigate the creation of a > Read Evaluate Print Loop (REPL) tool for the Java programming > language. For more details see the JEP [2]. > > [2] https://bugs.openjdk.java.net/browse/JDK-8043364 Another use case for all developers is build scripts. Currently this can be done with JDK, in JavaScript language using jjs, or in Java language using Janino source class loader (http://docs.codehaus.org/display/JANINO/Advanced ). Having API for build tools replace usefully some domain specific languages like Ant/Maven/Gradle (like JavaFX is better using Java language and not a custom DSL). It can also be useful to avoid temporary small files when building project (replaced by in-memory data/objects) and reduce number of sub-processes launched.