From ted at tedneward.com Tue Sep 4 21:18:01 2007 From: ted at tedneward.com (Ted Neward) Date: Tue, 4 Sep 2007 21:18:01 -0700 Subject: langtools in b20 In-Reply-To: <46D87D31.8010006@sun.com> References: <46D87D31.8010006@sun.com> Message-ID: <02fe01c7ef73$c1947d00$44bd7700$@com> Where "soon" means....? Do you have any sort of dox on how the langtools project is architected? I know there's been some blog chatter, but I was hoping for something that reflected the state of reality in b20? Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing http://www.tedneward.com > -----Original Message----- > From: compiler-dev-bounces at openjdk.java.net [mailto:compiler-dev- > bounces at openjdk.java.net] On Behalf Of Jonathan Gibbons > Sent: Friday, August 31, 2007 1:42 PM > To: compiler-dev at openjdk.java.net > Subject: langtools in b20 > > Gang, > > Andreas just stopped by my office to tell me that the work for the > langtools/ separation has made it into the master workspace this > morning. This means you all will be able to see it in build 20, coming > soon. > > -- Jon > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.484 / Virus Database: 269.13.1/981 - Release Date: > 8/31/2007 6:13 AM > No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.485 / Virus Database: 269.13.5/988 - Release Date: 9/4/2007 9:14 AM From Jonathan.Gibbons at Sun.COM Tue Sep 4 21:59:32 2007 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Tue, 04 Sep 2007 21:59:32 -0700 Subject: langtools in b20 In-Reply-To: <02fe01c7ef73$c1947d00$44bd7700$@com> References: <46D87D31.8010006@sun.com> <02fe01c7ef73$c1947d00$44bd7700$@com> Message-ID: <3D95F631-D0FE-4750-8EEB-8A8DB16B9FC7@Sun.COM> Ted, Well, the current build available on openjdk.java.net is b19, released aug30, and we're currently on a two week cycle, so you do the math ... There will be some docs regarding langtools in the new langtools area. Specifically, look in the make/ directory and its subdirectories for README files. As for architecture, there's not much "architecture" involved; langtools simply consists of the source code for javac, javadoc, javah, javap, and apt. The source code is laid out the same way it was before, the only thing that is different is that it is in a new workspace (internal for now, separate external repository eventually) and that the build files are different. For this build, we chose to go with Ant, because it is a pure-Java workspace, and to be able to share the same build system with IDEs, such as NetBeans. For compatibility with the rest of the j2se/ workspace, there is a simple Makefile wrapper around the Ant build.xml file as well, but you don't have to use that if you don't want to. The layout of the make/ directory is much the same as now, albeit much simpler. The build.xml file and its wrapper Makefile are in make/. The NetBeans projects are in make/netbeans/*, just like in the j2se/ workspace. There are more NetBeans projects than before. Previously, there were only projects for the compiler and javadoc. Now, there are projects for all the tools, although for various reasons the javadoc tool comes with two projects -- one for the tool itself and one for the standard doclets. Why more projects? Well, as a developer I want to be able to work on any part of this workspace, so there has to be a project for each and every part :-) And, because it is a smaller workspace, we don't have to rely on new features in the upcoming NetBeans 6.0, so you can stick with NetBeans 5.5 if you want, until you're ready to upgrade. Although there are more projects, you can actually browse the entire workspace and build any/all of it from any of the projects. The only difference between the projects is how the UI is hooked up -- for example, in the javac project, the "Clean and Rebuild" button will rebuild javac, whereas in the javadoc project it will rebuild javadoc, and so on. Most of the build smarts is in the main build.xml file, with smaller project-specific build.xml files for each project. For folk who want to build the rest of JDK, you can do it with or without building langtools as well. You can either download and build everything, or you can just download the j2se/ workspace, and point to a previous build of JDK with the ALT_JDK_IMPORT_DIR environment variable. Conceptually, this is similar to the current hotspot/ workspace. You can either build it or import it. If you want to get more into what the implications were for the rest of the build, I can tell you more but this isn't the right place. Suffice it to say that the ugly "recompile" loop in the j2se/ workspace has gone away (hooray!) and that was a major goal of this exercise. The "price" is that the javac source code is constrained to be compilable by the "boot javac" (i.e. from the previous release, currently 1.6.0) and javac, javadoc and javah must all be runnable using "boot java" because they are all used while building j2se/ itself. I hope this answers your questions. Let me know if you have any more. -- Jon P.S. I also note that by coincidence I will be on vacation when b20 is released. It's a coincidence, really! So I'll be around to answer any questions when I get back on the following Monday, assuming I don't get eaten by bears or anything like that. On Sep 4, 2007, at 9:18 PM, Ted Neward wrote: > Where "soon" means....? > > Do you have any sort of dox on how the langtools project is > architected? I > know there's been some blog chatter, but I was hoping for something > that > reflected the state of reality in b20? > > Ted Neward > Java, .NET, XML Services > Consulting, Teaching, Speaking, Writing > http://www.tedneward.com > > >> -----Original Message----- >> From: compiler-dev-bounces at openjdk.java.net [mailto:compiler-dev- >> bounces at openjdk.java.net] On Behalf Of Jonathan Gibbons >> Sent: Friday, August 31, 2007 1:42 PM >> To: compiler-dev at openjdk.java.net >> Subject: langtools in b20 >> >> Gang, >> >> Andreas just stopped by my office to tell me that the work for the >> langtools/ separation has made it into the master workspace this >> morning. This means you all will be able to see it in build 20, >> coming >> soon. >> >> -- Jon >> >> No virus found in this incoming message. >> Checked by AVG Free Edition. >> Version: 7.5.484 / Virus Database: 269.13.1/981 - Release Date: >> 8/31/2007 6:13 AM >> > > No virus found in this outgoing message. > Checked by AVG Free Edition. > Version: 7.5.485 / Virus Database: 269.13.5/988 - Release Date: > 9/4/2007 > 9:14 AM > > From leszekp at Safe-mail.net Wed Sep 5 05:07:09 2007 From: leszekp at Safe-mail.net (leszekp at Safe-mail.net) Date: Wed, 5 Sep 2007 08:07:09 -0400 Subject: javac offsprings and modifications Message-ID: Hello After javac open-sourcing many people have had chance to look into original java compiler internals and work with it. Maybe it would be good to gather information about various offsprings and modifications of javac (either released, under development or planned) and see in what directions it all goes. I know about the following projects based on javac: - kitchen sink - an experimental language - jackpot - java source transformation tool Any other ones you are aware of? Personally I am working on replacing javac hand coded lexer and parser by a framework generated ones (dfa lexer and lalr parser based on annotations) to allow easier experimenting with language features. Leszek From ted at tedneward.com Sat Sep 8 19:34:04 2007 From: ted at tedneward.com (Ted Neward) Date: Sat, 8 Sep 2007 19:34:04 -0700 Subject: langtools in b20 In-Reply-To: <3D95F631-D0FE-4750-8EEB-8A8DB16B9FC7@Sun.COM> References: <46D87D31.8010006@sun.com> <02fe01c7ef73$c1947d00$44bd7700$@com> <3D95F631-D0FE-4750-8EEB-8A8DB16B9FC7@Sun.COM> Message-ID: <0b1301c7f289$e60de4a0$b229ade0$@com> Coolness; next question: how easy would it be to slipstream the KSL project in place of the langtools-javac project? In other words, build a JDK with the KSL compiler instead of javac? Is there any plans to bring those two build systems in sync with one another? Or is that just a pipe dream? :-) Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing http://www.tedneward.com > -----Original Message----- > From: Jonathan.Gibbons at Sun.COM [mailto:Jonathan.Gibbons at Sun.COM] > Sent: Tuesday, September 04, 2007 10:00 PM > To: Ted Neward > Cc: compiler-dev at openjdk.java.net > Subject: Re: langtools in b20 > > Ted, > > Well, the current build available on openjdk.java.net is b19, > released aug30, > and we're currently on a two week cycle, so you do the math ... > > There will be some docs regarding langtools in the new langtools > area. Specifically, > look in the make/ directory and its subdirectories for README files. > > As for architecture, there's not much "architecture" involved; > langtools simply consists > of the source code for javac, javadoc, javah, javap, and apt. The > source code is > laid out the same way it was before, the only thing that is different > is that it is in a new > workspace (internal for now, separate external repository eventually) > and that the > build files are different. > > For this build, we chose to go with Ant, because it is a pure-Java > workspace, and to > be able to share the same build system with IDEs, such as NetBeans. > For compatibility > with the rest of the j2se/ workspace, there is a simple Makefile > wrapper around the Ant > build.xml file as well, but you don't have to use that if you don't > want to. > > The layout of the make/ directory is much the same as now, albeit > much simpler. > The build.xml file and its wrapper Makefile are in make/. The > NetBeans projects > are in make/netbeans/*, just like in the j2se/ workspace. > > There are more NetBeans projects than before. Previously, there were > only projects > for the compiler and javadoc. Now, there are projects for all the > tools, although for > various reasons the javadoc tool comes with two projects -- one for > the tool itself > and one for the standard doclets. Why more projects? Well, as a > developer I want to > be able to work on any part of this workspace, so there has to be a > project for each > and every part :-) > > And, because it is a smaller workspace, we don't have to rely on new > features in the > upcoming NetBeans 6.0, so you can stick with NetBeans 5.5 if you > want, until you're > ready to upgrade. > > Although there are more projects, you can actually browse the entire > workspace and > build any/all of it from any of the projects. The only difference > between the projects is > how the UI is hooked up -- for example, in the javac project, the > "Clean and Rebuild" > button will rebuild javac, whereas in the javadoc project it will > rebuild javadoc, and so on. > Most of the build smarts is in the main build.xml file, with smaller > project-specific build.xml > files for each project. > > For folk who want to build the rest of JDK, you can do it with or > without building > langtools as well. You can either download and build everything, or > you can just > download the j2se/ workspace, and point to a previous build of JDK > with the > ALT_JDK_IMPORT_DIR environment variable. Conceptually, this is > similar to > the current hotspot/ workspace. You can either build it or import it. > If you want to get > more into what the implications were for the rest of the build, I can > tell you more but > this isn't the right place. Suffice it to say that the ugly > "recompile" loop in the j2se/ > workspace has gone away (hooray!) and that was a major goal of this > exercise. > The "price" is that the javac source code is constrained to be > compilable by the > "boot javac" (i.e. from the previous release, currently 1.6.0) and > javac, javadoc and > javah must all be runnable using "boot java" because they are all > used while building > j2se/ itself. > > I hope this answers your questions. Let me know if you have any more. > > -- Jon > > P.S. I also note that by coincidence I will be on vacation when b20 > is released. > It's a coincidence, really! So I'll be around to answer any questions > when I get back > on the following Monday, assuming I don't get eaten by bears or > anything like that. > > > > > On Sep 4, 2007, at 9:18 PM, Ted Neward wrote: > > > Where "soon" means....? > > > > Do you have any sort of dox on how the langtools project is > > architected? I > > know there's been some blog chatter, but I was hoping for something > > that > > reflected the state of reality in b20? > > > > Ted Neward > > Java, .NET, XML Services > > Consulting, Teaching, Speaking, Writing > > http://www.tedneward.com > > > > > >> -----Original Message----- > >> From: compiler-dev-bounces at openjdk.java.net [mailto:compiler-dev- > >> bounces at openjdk.java.net] On Behalf Of Jonathan Gibbons > >> Sent: Friday, August 31, 2007 1:42 PM > >> To: compiler-dev at openjdk.java.net > >> Subject: langtools in b20 > >> > >> Gang, > >> > >> Andreas just stopped by my office to tell me that the work for the > >> langtools/ separation has made it into the master workspace this > >> morning. This means you all will be able to see it in build 20, > >> coming > >> soon. > >> > >> -- Jon > >> > >> No virus found in this incoming message. > >> Checked by AVG Free Edition. > >> Version: 7.5.484 / Virus Database: 269.13.1/981 - Release Date: > >> 8/31/2007 6:13 AM > >> > > > > No virus found in this outgoing message. > > Checked by AVG Free Edition. > > Version: 7.5.485 / Virus Database: 269.13.5/988 - Release Date: > > 9/4/2007 > > 9:14 AM > > > > > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.485 / Virus Database: 269.13.5/988 - Release Date: > 9/4/2007 9:14 AM > No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.485 / Virus Database: 269.13.10/995 - Release Date: 9/8/2007 1:24 PM From Jonathan.Gibbons at Sun.COM Sat Sep 8 22:56:53 2007 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Sat, 08 Sep 2007 22:56:53 -0700 Subject: langtools in b20 In-Reply-To: <0b1301c7f289$e60de4a0$b229ade0$@com> References: <46D87D31.8010006@sun.com> <02fe01c7ef73$c1947d00$44bd7700$@com> <3D95F631-D0FE-4750-8EEB-8A8DB16B9FC7@Sun.COM> <0b1301c7f289$e60de4a0$b229ade0$@com> Message-ID: <6F804F72-1028-409C-81A2-9C1505B4D4BF@Sun.COM> It is my intent to update KSL with langtools once that becomes available, so that langtools and KSL will by definition have the same build system, at least on the main trunk. On Sep 8, 2007, at 7:34 PM, Ted Neward wrote: > Coolness; next question: how easy would it be to slipstream the KSL > project > in place of the langtools-javac project? In other words, build a > JDK with > the KSL compiler instead of javac? Is there any plans to bring > those two > build systems in sync with one another? Or is that just a pipe > dream? :-) > > Ted Neward > Java, .NET, XML Services > Consulting, Teaching, Speaking, Writing > http://www.tedneward.com > > >> -----Original Message----- >> From: Jonathan.Gibbons at Sun.COM [mailto:Jonathan.Gibbons at Sun.COM] >> Sent: Tuesday, September 04, 2007 10:00 PM >> To: Ted Neward >> Cc: compiler-dev at openjdk.java.net >> Subject: Re: langtools in b20 >> >> Ted, >> >> Well, the current build available on openjdk.java.net is b19, >> released aug30, >> and we're currently on a two week cycle, so you do the math ... >> >> There will be some docs regarding langtools in the new langtools >> area. Specifically, >> look in the make/ directory and its subdirectories for README files. >> >> As for architecture, there's not much "architecture" involved; >> langtools simply consists >> of the source code for javac, javadoc, javah, javap, and apt. The >> source code is >> laid out the same way it was before, the only thing that is different >> is that it is in a new >> workspace (internal for now, separate external repository eventually) >> and that the >> build files are different. >> >> For this build, we chose to go with Ant, because it is a pure-Java >> workspace, and to >> be able to share the same build system with IDEs, such as NetBeans. >> For compatibility >> with the rest of the j2se/ workspace, there is a simple Makefile >> wrapper around the Ant >> build.xml file as well, but you don't have to use that if you don't >> want to. >> >> The layout of the make/ directory is much the same as now, albeit >> much simpler. >> The build.xml file and its wrapper Makefile are in make/. The >> NetBeans projects >> are in make/netbeans/*, just like in the j2se/ workspace. >> >> There are more NetBeans projects than before. Previously, there were >> only projects >> for the compiler and javadoc. Now, there are projects for all the >> tools, although for >> various reasons the javadoc tool comes with two projects -- one for >> the tool itself >> and one for the standard doclets. Why more projects? Well, as a >> developer I want to >> be able to work on any part of this workspace, so there has to be a >> project for each >> and every part :-) >> >> And, because it is a smaller workspace, we don't have to rely on new >> features in the >> upcoming NetBeans 6.0, so you can stick with NetBeans 5.5 if you >> want, until you're >> ready to upgrade. >> >> Although there are more projects, you can actually browse the entire >> workspace and >> build any/all of it from any of the projects. The only difference >> between the projects is >> how the UI is hooked up -- for example, in the javac project, the >> "Clean and Rebuild" >> button will rebuild javac, whereas in the javadoc project it will >> rebuild javadoc, and so on. >> Most of the build smarts is in the main build.xml file, with smaller >> project-specific build.xml >> files for each project. >> >> For folk who want to build the rest of JDK, you can do it with or >> without building >> langtools as well. You can either download and build everything, or >> you can just >> download the j2se/ workspace, and point to a previous build of JDK >> with the >> ALT_JDK_IMPORT_DIR environment variable. Conceptually, this is >> similar to >> the current hotspot/ workspace. You can either build it or import it. >> If you want to get >> more into what the implications were for the rest of the build, I can >> tell you more but >> this isn't the right place. Suffice it to say that the ugly >> "recompile" loop in the j2se/ >> workspace has gone away (hooray!) and that was a major goal of this >> exercise. >> The "price" is that the javac source code is constrained to be >> compilable by the >> "boot javac" (i.e. from the previous release, currently 1.6.0) and >> javac, javadoc and >> javah must all be runnable using "boot java" because they are all >> used while building >> j2se/ itself. >> >> I hope this answers your questions. Let me know if you have any more. >> >> -- Jon >> >> P.S. I also note that by coincidence I will be on vacation when b20 >> is released. >> It's a coincidence, really! So I'll be around to answer any questions >> when I get back >> on the following Monday, assuming I don't get eaten by bears or >> anything like that. >> >> >> >> >> On Sep 4, 2007, at 9:18 PM, Ted Neward wrote: >> >>> Where "soon" means....? >>> >>> Do you have any sort of dox on how the langtools project is >>> architected? I >>> know there's been some blog chatter, but I was hoping for something >>> that >>> reflected the state of reality in b20? >>> >>> Ted Neward >>> Java, .NET, XML Services >>> Consulting, Teaching, Speaking, Writing >>> http://www.tedneward.com >>> >>> >>>> -----Original Message----- >>>> From: compiler-dev-bounces at openjdk.java.net [mailto:compiler-dev- >>>> bounces at openjdk.java.net] On Behalf Of Jonathan Gibbons >>>> Sent: Friday, August 31, 2007 1:42 PM >>>> To: compiler-dev at openjdk.java.net >>>> Subject: langtools in b20 >>>> >>>> Gang, >>>> >>>> Andreas just stopped by my office to tell me that the work for the >>>> langtools/ separation has made it into the master workspace this >>>> morning. This means you all will be able to see it in build 20, >>>> coming >>>> soon. >>>> >>>> -- Jon >>>> >>>> No virus found in this incoming message. >>>> Checked by AVG Free Edition. >>>> Version: 7.5.484 / Virus Database: 269.13.1/981 - Release Date: >>>> 8/31/2007 6:13 AM >>>> >>> >>> No virus found in this outgoing message. >>> Checked by AVG Free Edition. >>> Version: 7.5.485 / Virus Database: 269.13.5/988 - Release Date: >>> 9/4/2007 >>> 9:14 AM >>> >>> >> >> No virus found in this incoming message. >> Checked by AVG Free Edition. >> Version: 7.5.485 / Virus Database: 269.13.5/988 - Release Date: >> 9/4/2007 9:14 AM >> > > No virus found in this outgoing message. > Checked by AVG Free Edition. > Version: 7.5.485 / Virus Database: 269.13.10/995 - Release Date: > 9/8/2007 > 1:24 PM > > From ted at tedneward.com Tue Sep 11 22:58:02 2007 From: ted at tedneward.com (Ted Neward) Date: Tue, 11 Sep 2007 22:58:02 -0700 Subject: langtools in b20 In-Reply-To: <6F804F72-1028-409C-81A2-9C1505B4D4BF@Sun.COM> References: <46D87D31.8010006@sun.com> <02fe01c7ef73$c1947d00$44bd7700$@com> <3D95F631-D0FE-4750-8EEB-8A8DB16B9FC7@Sun.COM> <0b1301c7f289$e60de4a0$b229ade0$@com> <6F804F72-1028-409C-81A2-9C1505B4D4BF@Sun.COM> Message-ID: <056501c7f501$e305a980$a910fc80$@com> Speaking of KSL, has anybody ever seen any modifications to it? I haven't seen any, and I've been updating against SVN for a while now. Are they hiding on a branch that everybody but me knows about? Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing http://www.tedneward.com > -----Original Message----- > From: Jonathan.Gibbons at Sun.COM [mailto:Jonathan.Gibbons at Sun.COM] > Sent: Saturday, September 08, 2007 10:57 PM > To: Ted Neward > Cc: compiler-dev at openjdk.java.net > Subject: Re: langtools in b20 > > It is my intent to update KSL with langtools once that becomes > available, > so that langtools and KSL will by definition have the same build > system, > at least on the main trunk. > > > On Sep 8, 2007, at 7:34 PM, Ted Neward wrote: > > > Coolness; next question: how easy would it be to slipstream the KSL > > project > > in place of the langtools-javac project? In other words, build a > > JDK with > > the KSL compiler instead of javac? Is there any plans to bring > > those two > > build systems in sync with one another? Or is that just a pipe > > dream? :-) > > > > Ted Neward > > Java, .NET, XML Services > > Consulting, Teaching, Speaking, Writing > > http://www.tedneward.com > > > > > >> -----Original Message----- > >> From: Jonathan.Gibbons at Sun.COM [mailto:Jonathan.Gibbons at Sun.COM] > >> Sent: Tuesday, September 04, 2007 10:00 PM > >> To: Ted Neward > >> Cc: compiler-dev at openjdk.java.net > >> Subject: Re: langtools in b20 > >> > >> Ted, > >> > >> Well, the current build available on openjdk.java.net is b19, > >> released aug30, > >> and we're currently on a two week cycle, so you do the math ... > >> > >> There will be some docs regarding langtools in the new langtools > >> area. Specifically, > >> look in the make/ directory and its subdirectories for README files. > >> > >> As for architecture, there's not much "architecture" involved; > >> langtools simply consists > >> of the source code for javac, javadoc, javah, javap, and apt. The > >> source code is > >> laid out the same way it was before, the only thing that is > different > >> is that it is in a new > >> workspace (internal for now, separate external repository > eventually) > >> and that the > >> build files are different. > >> > >> For this build, we chose to go with Ant, because it is a pure-Java > >> workspace, and to > >> be able to share the same build system with IDEs, such as NetBeans. > >> For compatibility > >> with the rest of the j2se/ workspace, there is a simple Makefile > >> wrapper around the Ant > >> build.xml file as well, but you don't have to use that if you don't > >> want to. > >> > >> The layout of the make/ directory is much the same as now, albeit > >> much simpler. > >> The build.xml file and its wrapper Makefile are in make/. The > >> NetBeans projects > >> are in make/netbeans/*, just like in the j2se/ workspace. > >> > >> There are more NetBeans projects than before. Previously, there were > >> only projects > >> for the compiler and javadoc. Now, there are projects for all the > >> tools, although for > >> various reasons the javadoc tool comes with two projects -- one for > >> the tool itself > >> and one for the standard doclets. Why more projects? Well, as a > >> developer I want to > >> be able to work on any part of this workspace, so there has to be a > >> project for each > >> and every part :-) > >> > >> And, because it is a smaller workspace, we don't have to rely on new > >> features in the > >> upcoming NetBeans 6.0, so you can stick with NetBeans 5.5 if you > >> want, until you're > >> ready to upgrade. > >> > >> Although there are more projects, you can actually browse the entire > >> workspace and > >> build any/all of it from any of the projects. The only difference > >> between the projects is > >> how the UI is hooked up -- for example, in the javac project, the > >> "Clean and Rebuild" > >> button will rebuild javac, whereas in the javadoc project it will > >> rebuild javadoc, and so on. > >> Most of the build smarts is in the main build.xml file, with smaller > >> project-specific build.xml > >> files for each project. > >> > >> For folk who want to build the rest of JDK, you can do it with or > >> without building > >> langtools as well. You can either download and build everything, or > >> you can just > >> download the j2se/ workspace, and point to a previous build of JDK > >> with the > >> ALT_JDK_IMPORT_DIR environment variable. Conceptually, this is > >> similar to > >> the current hotspot/ workspace. You can either build it or import > it. > >> If you want to get > >> more into what the implications were for the rest of the build, I > can > >> tell you more but > >> this isn't the right place. Suffice it to say that the ugly > >> "recompile" loop in the j2se/ > >> workspace has gone away (hooray!) and that was a major goal of this > >> exercise. > >> The "price" is that the javac source code is constrained to be > >> compilable by the > >> "boot javac" (i.e. from the previous release, currently 1.6.0) and > >> javac, javadoc and > >> javah must all be runnable using "boot java" because they are all > >> used while building > >> j2se/ itself. > >> > >> I hope this answers your questions. Let me know if you have any > more. > >> > >> -- Jon > >> > >> P.S. I also note that by coincidence I will be on vacation when b20 > >> is released. > >> It's a coincidence, really! So I'll be around to answer any > questions > >> when I get back > >> on the following Monday, assuming I don't get eaten by bears or > >> anything like that. > >> > >> > >> > >> > >> On Sep 4, 2007, at 9:18 PM, Ted Neward wrote: > >> > >>> Where "soon" means....? > >>> > >>> Do you have any sort of dox on how the langtools project is > >>> architected? I > >>> know there's been some blog chatter, but I was hoping for something > >>> that > >>> reflected the state of reality in b20? > >>> > >>> Ted Neward > >>> Java, .NET, XML Services > >>> Consulting, Teaching, Speaking, Writing > >>> http://www.tedneward.com > >>> > >>> > >>>> -----Original Message----- > >>>> From: compiler-dev-bounces at openjdk.java.net [mailto:compiler-dev- > >>>> bounces at openjdk.java.net] On Behalf Of Jonathan Gibbons > >>>> Sent: Friday, August 31, 2007 1:42 PM > >>>> To: compiler-dev at openjdk.java.net > >>>> Subject: langtools in b20 > >>>> > >>>> Gang, > >>>> > >>>> Andreas just stopped by my office to tell me that the work for the > >>>> langtools/ separation has made it into the master workspace this > >>>> morning. This means you all will be able to see it in build 20, > >>>> coming > >>>> soon. > >>>> > >>>> -- Jon > >>>> > >>>> No virus found in this incoming message. > >>>> Checked by AVG Free Edition. > >>>> Version: 7.5.484 / Virus Database: 269.13.1/981 - Release Date: > >>>> 8/31/2007 6:13 AM > >>>> > >>> > >>> No virus found in this outgoing message. > >>> Checked by AVG Free Edition. > >>> Version: 7.5.485 / Virus Database: 269.13.5/988 - Release Date: > >>> 9/4/2007 > >>> 9:14 AM > >>> > >>> > >> > >> No virus found in this incoming message. > >> Checked by AVG Free Edition. > >> Version: 7.5.485 / Virus Database: 269.13.5/988 - Release Date: > >> 9/4/2007 9:14 AM > >> > > > > No virus found in this outgoing message. > > Checked by AVG Free Edition. > > Version: 7.5.485 / Virus Database: 269.13.10/995 - Release Date: > > 9/8/2007 > > 1:24 PM > > > > > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.485 / Virus Database: 269.13.10/995 - Release Date: > 9/8/2007 1:24 PM > No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.485 / Virus Database: 269.13.14/1001 - Release Date: 9/11/2007 1:37 PM From forax at univ-mlv.fr Sun Sep 23 13:11:21 2007 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sun, 23 Sep 2007 22:11:21 +0200 Subject: langtools in b20 In-Reply-To: <46D87D31.8010006@sun.com> References: <46D87D31.8010006@sun.com> Message-ID: <46F6C869.9030708@univ-mlv.fr> Jonathan Gibbons a ?crit : > Gang, > > Andreas just stopped by my office to tell me that the work for the > langtools/ separation has made it into the master workspace this > morning. This means you all will be able to see it in build 20, coming > soon. > > -- Jon hi jon, i've tried to port my property workspace into langtool workspace. It seems that all copyright headers are older that the ones of the openjdk compiler workspace. Futhermore, i don't see how to make some modification to javax.lang.model package and compile the compiler with the new build process. cheers, R?mi From Jonathan.Gibbons at Sun.COM Sun Sep 23 14:15:52 2007 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Sun, 23 Sep 2007 14:15:52 -0700 Subject: langtools in b20 In-Reply-To: <46F6C869.9030708@univ-mlv.fr> References: <46D87D31.8010006@sun.com> <46F6C869.9030708@univ-mlv.fr> Message-ID: Hi Remi, I'd like to help but I'll need a bit more to go on. What are the issues you are seeing with the copyright headers? I assume you can edit the files in the javax.lang.model package OK; what problems are you having when you try and compile the workspace? -- Jon On Sep 23, 2007, at 1:11 PM, R?mi Forax wrote: > Jonathan Gibbons a ?crit : >> Gang, >> >> Andreas just stopped by my office to tell me that the work for the >> langtools/ separation has made it into the master workspace this >> morning. This means you all will be able to see it in build 20, >> coming soon. >> >> -- Jon > hi jon, i've tried to port my property workspace into langtool > workspace. > It seems that all copyright headers are older that the ones of the > openjdk > compiler workspace. > > Futhermore, i don't see how to make some modification to > javax.lang.model package > and compile the compiler with the new build process. > > cheers, > R?mi From forax at univ-mlv.fr Sun Sep 23 16:31:56 2007 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 24 Sep 2007 01:31:56 +0200 Subject: langtools in b20 Message-ID: <46F6F76C.8050907@univ-mlv.fr> Jonathan Gibbons a ?crit : > Hi Remi, > > I'd like to help but I'll need a bit more to go on. > > What are the issues you are seeing with the copyright headers? I think copyright headers are not up to date if you compare with the last update of the openjdk/compiler workspace. I don't know if it's a problem or not. > > I assume you can edit the files in the javax.lang.model package OK; yes > what problems are you having when you try and compile the workspace? javax.model.* is a part of JDK so when i compile a patched version javac/tree/JCTree.java, that adds two new trees, the build process use the package javax.model.element of the boot jdk and not the one that you can find in the source folder. > > -- Jon R?mi > > > On Sep 23, 2007, at 1:11 PM, R?mi Forax wrote: > >> Jonathan Gibbons a ?crit : >>> Gang, >>> >>> Andreas just stopped by my office to tell me that the work for the >>> langtools/ separation has made it into the master workspace this >>> morning. This means you all will be able to see it in build 20, >>> coming soon. >>> >>> -- Jon >> hi jon, i've tried to port my property workspace into langtool >> workspace. >> It seems that all copyright headers are older that the ones of the >> openjdk >> compiler workspace. >> >> Futhermore, i don't see how to make some modification to >> javax.lang.model package >> and compile the compiler with the new build process. >> >> cheers, >> R?mi > From Jonathan.Gibbons at Sun.COM Sun Sep 23 16:49:59 2007 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Sun, 23 Sep 2007 16:49:59 -0700 Subject: langtools in b20 In-Reply-To: <46F6F76C.8050907@univ-mlv.fr> References: <46F6F76C.8050907@univ-mlv.fr> Message-ID: On Sep 23, 2007, at 4:31 PM, R?mi Forax wrote: > Jonathan Gibbons a ?crit : >> Hi Remi, >> >> I'd like to help but I'll need a bit more to go on. >> >> What are the issues you are seeing with the copyright headers? > I think copyright headers are not up to date if you compare with > the last update of the openjdk/compiler workspace. > I don't know if it's a problem or not. This is in KSL, right? > >> >> I assume you can edit the files in the javax.lang.model package OK; > yes >> what problems are you having when you try and compile the workspace? > javax.model.* is a part of JDK so when i compile a patched version > javac/tree/JCTree.java, > that adds two new trees, the build process use the package > javax.model.element of the boot jdk and not > the one that you can find in the source folder. The build process should be putting all the necessary files on the command line. Can you provide some script output to show what you are doing and how it is going wrong for you. -- Jon From forax at univ-mlv.fr Sun Sep 23 17:38:39 2007 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 24 Sep 2007 02:38:39 +0200 Subject: langtools in b20 In-Reply-To: References: <46F6F76C.8050907@univ-mlv.fr> Message-ID: <46F7070F.5070804@univ-mlv.fr> Jonathan Gibbons a ?crit : > > On Sep 23, 2007, at 4:31 PM, R?mi Forax wrote: > >> Jonathan Gibbons a ?crit : >>> Hi Remi, >>> >>> I'd like to help but I'll need a bit more to go on. >>> >>> What are the issues you are seeing with the copyright headers? >> I think copyright headers are not up to date if you compare with >> the last update of the openjdk/compiler workspace. >> I don't know if it's a problem or not. > > This is in KSL, right? no, headers of files from https://openjdk.dev.java.net/svn/openjdk/compiler/trunk seems more accurate than headers of files from https://openjdk.dev.java.net/svn/openjdk/jdk/trunk/langtools > >> >>> >>> I assume you can edit the files in the javax.lang.model package OK; >> yes > >>> what problems are you having when you try and compile the workspace? >> javax.model.* is a part of JDK so when i compile a patched version >> javac/tree/JCTree.java, >> that adds two new trees, the build process use the package >> javax.model.element of the boot jdk and not >> the one that you can find in the source folder. > > The build process should be putting all the necessary files on the > command line. Can you provide some script output to show what you are > doing and how it is going wrong for you. ok, it's compile now, i've made "ant clean" and it's working (almost because it seems i forget that "byte data[]" is a valid field declaration, but that is another story) So i think there is a dependency problem with in the build.xml, here is the use case: 1) compile the whole repository "ant" 2) patch the source file (here com.sun.source.tree.TreeVisitor) 3) compile using ant -> some files in /build/bootstrap/classes/ are not recompiled so it fails 3bis) use "ant clean; ant" it compiles > > -- Jon > > it's 2 am here, so i have to go to sleep. cheers, R?mi From Jonathan.Gibbons at Sun.COM Sun Sep 23 18:46:25 2007 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Sun, 23 Sep 2007 18:46:25 -0700 Subject: langtools in b20 In-Reply-To: <46F7070F.5070804@univ-mlv.fr> References: <46F6F76C.8050907@univ-mlv.fr> <46F7070F.5070804@univ-mlv.fr> Message-ID: On Sep 23, 2007, at 5:38 PM, R?mi Forax wrote: > > no, > headers of files from https://openjdk.dev.java.net/svn/openjdk/ > compiler/trunk > seems more accurate than headers of files from https:// > openjdk.dev.java.net/svn/openjdk/jdk/trunk/langtools Thanks for the specific path names; I'' check this out, but it is more likely that the langtools ones are the most accurate; they come from the definitive internal (soon to be external) workspace. Actually, compiler/trunk should be deleted; I'll investigate having that done. >> >>> >>>> >>>> I assume you can edit the files in the javax.lang.model package OK; >>> yes >> >>>> what problems are you having when you try and compile the >>>> workspace? >>> javax.model.* is a part of JDK so when i compile a patched >>> version javac/tree/JCTree.java, >>> that adds two new trees, the build process use the package >>> javax.model.element of the boot jdk and not >>> the one that you can find in the source folder. >> >> The build process should be putting all the necessary files on the >> command line. Can you provide some script output to show what you >> are doing and how it is going wrong for you. > ok, it's compile now, i've made "ant clean" and it's working > (almost because it seems i forget that "byte data[]" is a valid > field declaration, > but that is another story) > > So i think there is a dependency problem with in the build.xml, > here is the use case: > 1) compile the whole repository > "ant" > 2) patch the source file (here com.sun.source.tree.TreeVisitor) > 3) compile using ant > -> some files in /build/bootstrap/classes/ are not recompiled > so it fails > 3bis) use "ant clean; ant" > it compiles OK, thanks; I'll try and recreate that scenario. I'm guessing you were adding methods to TreeVisitor, right? Stupid question, are you just running into the "standard" problem that none of ant/make/javac does a proper job of dependency analysis? If you edit and recompile an interface or abstract class, ant will not know to recompile any subtypes that might need recompiling? I'll really like to see this fixed; it would be a great application for JSR199/269, to obtain and use accurate dependency info. -- Jon From lahoda at gmail.com Mon Sep 24 05:14:52 2007 From: lahoda at gmail.com (Jan Lahoda) Date: Mon, 24 Sep 2007 14:14:52 +0200 Subject: Test single not working anymore? Message-ID: <87d9996a0709240514nde01f77v7cda0b78c4d0af9a@mail.gmail.com> Hi, seems to me that "test-single" (aka Run File on a test) stopped working inside NetBeans. I have a recent build of NetBeans and when I open langtools/make/netbeans/compiler project and open a test, the Run File runs all tests for the javac. Also, "all tests" (Test action on the project) is 45 tests (seems to be configured in langtools/make/build.properties to tools/javac/api). Is this intentional? My OpenJDK is revision 252 from: https://openjdk.dev.java.net/svn/openjdk/jdk/trunk Thanks, Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20070924/d51abe83/attachment.html From Jonathan.Gibbons at Sun.COM Mon Sep 24 07:02:13 2007 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Mon, 24 Sep 2007 07:02:13 -0700 Subject: Test single not working anymore? In-Reply-To: <87d9996a0709240514nde01f77v7cda0b78c4d0af9a@mail.gmail.com> References: <87d9996a0709240514nde01f77v7cda0b78c4d0af9a@mail.gmail.com> Message-ID: Jan, Yes, both of these issues are known. I'm working to fix them. -- Jon On Sep 24, 2007, at 5:14 AM, Jan Lahoda wrote: > Hi, > seems to me that "test-single" (aka Run File on a test) stopped > working inside NetBeans. I have a recent build of NetBeans and when > I open langtools/make/netbeans/compiler project and open a test, > the Run File runs all tests for the javac. Also, "all tests" (Test > action on the project) is 45 tests (seems to be configured in > langtools/make/build.properties to tools/javac/api). Is this > intentional? > > My OpenJDK is revision 252 from: > https://openjdk.dev.java.net/svn/openjdk/jdk/trunk > > Thanks, > Jan > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20070924/55d4fae0/attachment.html From forax at univ-mlv.fr Mon Sep 24 09:42:33 2007 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 24 Sep 2007 18:42:33 +0200 Subject: langtools in b20 In-Reply-To: References: <46F6F76C.8050907@univ-mlv.fr> <46F7070F.5070804@univ-mlv.fr> Message-ID: <46F7E8F9.1020403@univ-mlv.fr> Jonathan Gibbons a ?crit : > > On Sep 23, 2007, at 5:38 PM, R?mi Forax wrote: > >> >> no, >> headers of files from >> https://openjdk.dev.java.net/svn/openjdk/compiler/trunk >> seems more accurate than headers of files from >> https://openjdk.dev.java.net/svn/openjdk/jdk/trunk/langtools > > > Thanks for the specific path names; I'' check this out, but it is more > likely that the langtools ones are the most accurate; they come from > the definitive internal (soon to be external) workspace. Actually, > compiler/trunk should be deleted; I'll investigate having that done. it is deleted, at least marked as deleted. I talk about the headers of the files just before being deleted. ... >> ok, it's compile now, i've made "ant clean" and it's working >> (almost because it seems i forget that "byte data[]" is a valid >> field declaration, >> but that is another story) ok, this is corrected. >> >> So i think there is a dependency problem with in the build.xml, >> here is the use case: >> 1) compile the whole repository >> "ant" >> 2) patch the source file (here com.sun.source.tree.TreeVisitor) >> 3) compile using ant >> -> some files in /build/bootstrap/classes/ are not recompiled >> so it fails >> 3bis) use "ant clean; ant" >> it compiles > > > OK, thanks; I'll try and recreate that scenario. I'm guessing you > were adding methods to TreeVisitor, right? yes > Stupid question, are you just running into the "standard" problem that > none of ant/make/javac does a proper job of dependency analysis? If > you edit and recompile an interface or abstract class, ant will not > know to recompile any subtypes that might need recompiling? no, this is not the standard case, i've patched the interface and all implementations so it should recompile supertype and subtypes. > I'll really like to see this fixed; it would be a great application > for JSR199/269, to obtain and use accurate dependency info. yes, it could be great, especially if it is integrated to ant. > > > > -- Jon > R?mi From forax at univ-mlv.fr Mon Sep 24 09:43:00 2007 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 24 Sep 2007 18:43:00 +0200 Subject: properties patch and ksl Message-ID: <46F7E914.70403@univ-mlv.fr> Ok, my workspace is ready to be commited into a ksl branch, but currently it is based on langtool workspace (as jon, said the most accurate one) and not based on ksl trunk which is out dated. Is there a plan to update ksl to use langtool or perhaps i have to wait and use a future mercurial repository ? R?mi From Jonathan.Gibbons at Sun.COM Mon Sep 24 09:44:11 2007 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Mon, 24 Sep 2007 09:44:11 -0700 Subject: properties patch and ksl In-Reply-To: <46F7E914.70403@univ-mlv.fr> References: <46F7E914.70403@univ-mlv.fr> Message-ID: <46F7E95B.9040508@sun.com> R?mi, I will update KSL with langtools; that had been the plan, there was just low demand, until now. -- Jon R?mi Forax wrote: > Ok, my workspace is ready to be commited into a ksl branch, > but currently it is based on langtool workspace > (as jon, said the most accurate one) and not based on ksl trunk > which is out dated. > > Is there a plan to update ksl to use langtool or > perhaps i have to wait and use a future mercurial repository ? > > R?mi > > From ted at tedneward.com Sat Sep 29 02:59:11 2007 From: ted at tedneward.com (Ted Neward) Date: Sat, 29 Sep 2007 02:59:11 -0700 Subject: Bug in switch around Enums? Message-ID: <05fb01c8027f$658ab370$30a01a50$@com> A good friend of mine just stumped me with this one; forwarding here because I believe it to be a bug in the compiler somewhere. Couldn?t remember if Josh and Neal were on the list, so I added them in CC; sorry for the duplication, guys. Normally, case statements with or without parens around them will compile: int x = 0; switch (x) { case (0): return "ZERO"; case 1 : return "ONE"; } But doing the same for Enum doesn?t compile when parens are there: public class EnumTest { public enum Test { WRAP, STAGGER, ROTATE, NONE }; public static String toString(Test e) { switch (e) { //case (EnumTest.Test.STAGGER): return ?STAGGER?; // this will not compile case WRAP: return "WRAP"; // This, of course, is fine default: return "WTF?!?"; } } } Is this a compiler/parser bug? Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing HYPERLINK "http://www.tedneward.com"http://www.tedneward.com No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.488 / Virus Database: 269.13.33/1034 - Release Date: 9/27/2007 5:00 PM -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20070929/7764c8a3/attachment.html From matthias at mernst.org Sat Sep 29 03:15:21 2007 From: matthias at mernst.org (Matthias Ernst) Date: Sat, 29 Sep 2007 12:15:21 +0200 Subject: Bug in switch around Enums? In-Reply-To: <05fb01c8027f$658ab370$30a01a50$@com> References: <05fb01c8027f$658ab370$30a01a50$@com> Message-ID: <22ec15240709290315g44e8136dx437e5b6f4b1b496b@mail.gmail.com> Ted, according to the JLS it's not a bug. Switch labels can either be constant expressions or enum identifiers: http://java.sun.com/docs/books/jls/third_edition/html/statements.html#14.11 SwitchLabel: case ConstantExpression : case EnumConstantName : default : and constant expression is only defined for primitives and String: http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.28 So (STAGGER) is neither a constant expression nor an enum constant name. Feel free to call me type 1 (http://diveintomark.org/archives/2004/08/16/specs) :-) Matthias From Tom.Ball at Sun.COM Sat Sep 29 08:10:24 2007 From: Tom.Ball at Sun.COM (Tom Ball) Date: Sat, 29 Sep 2007 08:10:24 -0700 Subject: Bug in switch around Enums? In-Reply-To: <22ec15240709290315g44e8136dx437e5b6f4b1b496b@mail.gmail.com> References: <05fb01c8027f$658ab370$30a01a50$@com> <22ec15240709290315g44e8136dx437e5b6f4b1b496b@mail.gmail.com> Message-ID: <46FE6AE0.7020108@sun.com> Okay, it's not a bug since the spec says its not. It is still an unnecessary syntactic inconsistency between constants and enums, however, and inconsistencies like this making the language a little harder to learn (yet another rule to remember). This can't be changed in the compiler until the spec is, but perhaps there is a related pending JSR which can add it as an update. Tom Matthias Ernst wrote: > Ted, > > according to the JLS it's not a bug. > > Switch labels can either be constant expressions or enum identifiers: > > http://java.sun.com/docs/books/jls/third_edition/html/statements.html#14.11 > SwitchLabel: > case ConstantExpression : > case EnumConstantName : > default : > > and constant expression is only defined for primitives and String: > http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.28 > > So (STAGGER) is neither a constant expression nor an enum constant name. > > Feel free to call me type 1 > (http://diveintomark.org/archives/2004/08/16/specs) :-) > > Matthias From brian at slesinsky.org Sat Sep 29 11:42:01 2007 From: brian at slesinsky.org (Brian Slesinsky) Date: Sat, 29 Sep 2007 11:42:01 -0700 Subject: Bug in switch around Enums? In-Reply-To: <46FE6AE0.7020108@sun.com> References: <05fb01c8027f$658ab370$30a01a50$@com> <22ec15240709290315g44e8136dx437e5b6f4b1b496b@mail.gmail.com> <46FE6AE0.7020108@sun.com> Message-ID: <824b0d840709291142p7be9f836y899d7d0fe8ef9d38@mail.gmail.com> Sure, support for constant expressions that return an enum seems like a win. It would also solve a different gotcha. This doesn't work: void doSwitch(MyEnum x) { switch (x) { case MyEnum.FOO: // do something } } This was the first thing I tried (by experiment, rather than reading the spec) and for a short time I was under the impression that enums don't work with switch statements. The same thing happened to one other person I know. Even if the spec isn't changed, clear error messages help. (Although I believe it was IntelliJ that confused me, not javac.) - Brian On 9/29/07, Tom Ball wrote: > Okay, it's not a bug since the spec says its not. It is still an > unnecessary syntactic inconsistency between constants and enums, > however, and inconsistencies like this making the language a little > harder to learn (yet another rule to remember). This can't be changed > in the compiler until the spec is, but perhaps there is a related > pending JSR which can add it as an update. > > Tom > > Matthias Ernst wrote: > > Ted, > > > > according to the JLS it's not a bug. > > > > Switch labels can either be constant expressions or enum identifiers: > > > > http://java.sun.com/docs/books/jls/third_edition/html/statements.html#14.11 > > SwitchLabel: > > case ConstantExpression : > > case EnumConstantName : > > default : > > > > and constant expression is only defined for primitives and String: > > http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.28 > > > > So (STAGGER) is neither a constant expression nor an enum constant name. > > > > Feel free to call me type 1 > > (http://diveintomark.org/archives/2004/08/16/specs) :-) > > > > Matthias > > From Jonathan.Gibbons at Sun.COM Sat Sep 29 13:19:01 2007 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Sat, 29 Sep 2007 13:19:01 -0700 Subject: Bug in switch around Enums? In-Reply-To: <824b0d840709291142p7be9f836y899d7d0fe8ef9d38@mail.gmail.com> References: <05fb01c8027f$658ab370$30a01a50$@com> <22ec15240709290315g44e8136dx437e5b6f4b1b496b@mail.gmail.com> <46FE6AE0.7020108@sun.com> <824b0d840709291142p7be9f836y899d7d0fe8ef9d38@mail.gmail.com> Message-ID: Hey guys, Just a gentle reminder this alias is for developers working on the compiler, and is not intended to be a general forum for discussing the shortcomings of and enhancements to the language itself. -- Jon On Sep 29, 2007, at 11:42 AM, Brian Slesinsky wrote: > Sure, support for constant expressions that return an enum seems > like a win. > > It would also solve a different gotcha. This doesn't work: > > void doSwitch(MyEnum x) { > switch (x) { > case MyEnum.FOO: > // do something > } > } > > This was the first thing I tried (by experiment, rather than reading > the spec) and for a short time I was under the impression that enums > don't work with switch statements. The same thing happened to one > other person I know. Even if the spec isn't changed, clear error > messages help. (Although I believe it was IntelliJ that confused me, > not javac.) > > - Brian > > On 9/29/07, Tom Ball wrote: >> Okay, it's not a bug since the spec says its not. It is still an >> unnecessary syntactic inconsistency between constants and enums, >> however, and inconsistencies like this making the language a little >> harder to learn (yet another rule to remember). This can't be >> changed >> in the compiler until the spec is, but perhaps there is a related >> pending JSR which can add it as an update. >> >> Tom >> >> Matthias Ernst wrote: >>> Ted, >>> >>> according to the JLS it's not a bug. >>> >>> Switch labels can either be constant expressions or enum >>> identifiers: >>> >>> http://java.sun.com/docs/books/jls/third_edition/html/ >>> statements.html#14.11 >>> SwitchLabel: >>> case ConstantExpression : >>> case EnumConstantName : >>> default : >>> >>> and constant expression is only defined for primitives and String: >>> http://java.sun.com/docs/books/jls/third_edition/html/ >>> expressions.html#15.28 >>> >>> So (STAGGER) is neither a constant expression nor an enum >>> constant name. >>> >>> Feel free to call me type 1 >>> (http://diveintomark.org/archives/2004/08/16/specs) :-) >>> >>> Matthias >> >> From joshudson at gmail.com Sun Sep 30 15:08:31 2007 From: joshudson at gmail.com (Joshua Hudson) Date: Sun, 30 Sep 2007 15:08:31 -0700 Subject: How do I compile javac? Message-ID: I downloaded the JDK 7 september source and binary packages. I installed the binary package. How can I compile just javac against the JDK 7 binaries I've already installed. I have a mind to tinker with something. From Jonathan.Gibbons at Sun.COM Sun Sep 30 17:28:28 2007 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Sun, 30 Sep 2007 17:28:28 -0700 Subject: How do I compile javac? In-Reply-To: References: Message-ID: <9A1BD0E0-A4C7-4345-9FBC-2FAD2053CC78@sun.com> The compiler is in the langtools part of the JDK source tree, and there is a Makefile and Ant file there (in langtools/make) that will compile just javac. You do not need the JDK 7 binary package, you can still use JDK 5 to build the compiler. -- Jon On Sep 30, 2007, at 3:08 PM, Joshua Hudson wrote: > I downloaded the JDK 7 september source and binary packages. > I installed the binary package. > > How can I compile just javac against the JDK 7 binaries I've > already installed. > I have a mind to tinker with something.