From Peter.Ahe at Sun.COM Thu May 17 12:34:36 2007 From: Peter.Ahe at Sun.COM (=?ISO-8859-1?Q?Peter_von_der_Ah=E9?=) Date: Thu, 17 May 2007 12:34:36 -0700 Subject: Starting a J2EE server in less than a second Message-ID: Perhaps you saw how fast Glassfish can start up at JavaOne: http://weblogs.java.net/blog/davidvc/archive/2007/05/ glassfish_in_le.html This is very impressive. I have a feeling that the compiler team can play a big role in helping Glassfish achieve the next level: reducing the time it takes to get your application from being edited in NetBeans to loaded and running within the container. Said in another way: Glassfish now totally rocks for static pages; lets make it rock for dynamic pages. Cheers, Peter From wahjava.ml at gmail.com Fri May 18 12:14:29 2007 From: wahjava.ml at gmail.com (=?utf-8?B?4KSG4KS24KWA4KS3IOCktuClgeCkleCljeCksg==?= Ashish Shukla) Date: Sat, 19 May 2007 00:44:29 +0530 Subject: Inaccessible 'javac' SVN repository Message-ID: <20070518191429.GA5886@chatteau.d.lf> Hi, I'm trying to checkout 'javac' sources from SVN as listed on following URL: http://openjdk.java.net/groups/compiler/ The SVN URL listed in that page is following: https://openjdk.dev.java.net/svn/openjdk/compiler/trunk I'm able to browse javac sources via OpenGrok, but not able to checkout them. So, can someone from OpenJDK team correct the SVN repository URL listed in that page ? Thanks in advance, Ashish Shukla -- Ashish Shukla "Wah Java !!" ???? ????? ,= ,-_-. =. webpages: http://wahjava.googlepages.com ((_/)o o(\_)) weblog: http://wahjava.wordpress.com `-'(. .)`-' PGP: 1E00 4679 77E4 F8EE 2E4B 56F2 1F2F 8410 762E 5E74 \_/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20070519/5a891c2a/attachment.bin From Jonathan.Gibbons at Sun.COM Fri May 18 17:10:55 2007 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Fri, 18 May 2007 17:10:55 -0700 Subject: Inaccessible 'javac' SVN repository In-Reply-To: <20070518191429.GA5886@chatteau.d.lf> References: <20070518191429.GA5886@chatteau.d.lf> Message-ID: <464E408F.5090505@sun.com> Ashish, My apologies: the information on the compiler page is currently out of date. To get the compiler files from a Subversion repository, you currently have to go through the main OpenJDK repository, using the instructions liked under the "Subversion" link on the left side of the page. -- Jon ???? ????? Ashish Shukla wrote: > Hi, > > I'm trying to checkout 'javac' sources from SVN as listed on following > URL: > > http://openjdk.java.net/groups/compiler/ > > The SVN URL listed in that page is following: > https://openjdk.dev.java.net/svn/openjdk/compiler/trunk > > I'm able to browse javac sources via OpenGrok, but not able to checkout > them. > > So, can someone from OpenJDK team correct the SVN repository URL listed in that page ? > > Thanks in advance, > Ashish Shukla > From Jonathan.Gibbons at Sun.COM Fri May 18 17:27:12 2007 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Fri, 18 May 2007 17:27:12 -0700 Subject: Where's the compiler? Message-ID: <464E4460.6040500@sun.com> As some of you have noticed, the compiler has moved, and grown a few extra files, and is now called OpenJDK. By which I mean that when we open sourced the compiler sources last year, they were made available in a readonly subversion repository of their own. But the compiler has always been part of JDK, and now that JDK has been open sourced, the compiler source files can be found there, as part of OpenJDK. Look for the Subversion link on the left of the OpenJDK pages. But wait, there's more ... As you know, OpenJDK will sometime soon be changing to use Mercurial, so these Subversion repositories are somewhat temporary anyway. We may continue to make them available for people's convenience after the Mercurial transition, but the real truth will soon be in the Mercurial repositories. But wait, there's more ... In the meantime, there's a hiccup in our ability to update the OpenJDK webpages, because the new pages themselves are in a new Mercurial repository. Once we get access to that one sorted out, we'll update the pages with the latest info. Sorry for the inconvenience; normal service will be resumed as soon as possible. Meantime, we really are trying to make this easier for everyone. -- Jon G From neojia at gmail.com Fri May 18 18:56:38 2007 From: neojia at gmail.com (Neo Jia) Date: Fri, 18 May 2007 20:56:38 -0500 Subject: Where's the compiler? In-Reply-To: <464E4460.6040500@sun.com> References: <464E4460.6040500@sun.com> Message-ID: <5d649bdb0705181856x73c3fd9bu59b7ab61a75999c3@mail.gmail.com> On 5/18/07, Jonathan Gibbons wrote: > As some of you have noticed, the compiler has moved, and grown a few > extra files, and is now called OpenJDK. > > By which I mean that when we open sourced the compiler sources last > year, they were made available in a readonly subversion repository of > their own. But the compiler has always been part of JDK, and now that > JDK has been open sourced, the compiler source files can be found there, > as part of OpenJDK. Look for the Subversion link on the left of the > OpenJDK pages. > > But wait, there's more ... > > As you know, OpenJDK will sometime soon be changing to use Mercurial, so > these Subversion repositories are somewhat temporary anyway. We may > continue to make them available for people's convenience after the > Mercurial transition, but the real truth will soon be in the Mercurial > repositories. Will there be any update for bug database? Thanks, Neo > > But wait, there's more ... > > In the meantime, there's a hiccup in our ability to update the OpenJDK > webpages, because the new pages themselves are in a new Mercurial > repository. Once we get access to that one sorted out, we'll update the > pages with the latest info. > > Sorry for the inconvenience; normal service will be resumed as soon as > possible. Meantime, we really are trying to make this easier for everyone. > > -- Jon G > > > -- I would remember that if researchers were not ambitious probably today we haven't the technology we are using! From Jonathan.Gibbons at Sun.COM Fri May 18 21:02:18 2007 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Fri, 18 May 2007 21:02:18 -0700 Subject: Where's the compiler? In-Reply-To: <5d649bdb0705181856x73c3fd9bu59b7ab61a75999c3@mail.gmail.com> References: <464E4460.6040500@sun.com> <5d649bdb0705181856x73c3fd9bu59b7ab61a75999c3@mail.gmail.com> Message-ID: <46AD4823-BC5F-4F27-87C5-1E39FAABDC9A@Sun.COM> On May 18, 2007, at 6:56 PM, Neo Jia wrote: > > Will there be any update for bug database? > > Thanks, > Neo > Can you give more details what you mean by this? -- Jon From neojia at gmail.com Fri May 18 21:32:52 2007 From: neojia at gmail.com (Neo Jia) Date: Fri, 18 May 2007 23:32:52 -0500 Subject: Where's the compiler? In-Reply-To: <46AD4823-BC5F-4F27-87C5-1E39FAABDC9A@Sun.COM> References: <464E4460.6040500@sun.com> <5d649bdb0705181856x73c3fd9bu59b7ab61a75999c3@mail.gmail.com> <46AD4823-BC5F-4F27-87C5-1E39FAABDC9A@Sun.COM> Message-ID: <5d649bdb0705182132r34b48054sdfcc10a4481c9eb0@mail.gmail.com> On 5/18/07, Jonathan Gibbons wrote: > > On May 18, 2007, at 6:56 PM, Neo Jia wrote: > > > > Will there be any update for bug database? > > > > Thanks, > > Neo > > > > Can you give more details what you mean by this? Jon, Sorry for such confusing question. I am just wondering if Sun would like to replace the current bug database (at least the bug database accessible from outside) to Bugzilla or something else, because for me the current bug database cannot provide enough information, such as status of a bug (open, closed, fixed, assigned), attachment, patches. Thanks, Neo > > -- Jon > -- I would remember that if researchers were not ambitious probably today we haven't the technology we are using! From Jonathan.Gibbons at Sun.COM Fri May 18 21:39:42 2007 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Fri, 18 May 2007 21:39:42 -0700 Subject: Where's the compiler? In-Reply-To: <5d649bdb0705182132r34b48054sdfcc10a4481c9eb0@mail.gmail.com> References: <464E4460.6040500@sun.com> <5d649bdb0705181856x73c3fd9bu59b7ab61a75999c3@mail.gmail.com> <46AD4823-BC5F-4F27-87C5-1E39FAABDC9A@Sun.COM> <5d649bdb0705182132r34b48054sdfcc10a4481c9eb0@mail.gmail.com> Message-ID: <1BAFF940-C2E3-4DC7-B282-0D98B9E90846@Sun.COM> Neo, Since this question isn't specific to compiler development, you'd do better to ask this on the general OpenJDK list, discuss at openjdk.java.net. -- Jon On May 18, 2007, at 9:32 PM, Neo Jia wrote: > On 5/18/07, Jonathan Gibbons wrote: >> >> On May 18, 2007, at 6:56 PM, Neo Jia wrote: >> > >> > Will there be any update for bug database? >> > >> > Thanks, >> > Neo >> > >> >> Can you give more details what you mean by this? > > Jon, > > Sorry for such confusing question. I am just wondering if Sun would > like to replace the > current bug database (at least the bug database accessible from > outside) to Bugzilla or something else, because for me the current bug > database cannot provide enough information, such as status of a bug > (open, closed, fixed, assigned), attachment, patches. > > Thanks, > Neo > >> >> -- Jon >> > > > -- > I would remember that if researchers were not ambitious > probably today we haven't the technology we are using! From wahjava.ml at gmail.com Sun May 20 07:55:06 2007 From: wahjava.ml at gmail.com (=?utf-8?q?=E0=A4=86=E0=A4=B6=E0=A5=80=E0=A4=B7_Ashish?=) Date: Sun, 20 May 2007 20:25:06 +0530 Subject: Inaccessible 'javac' SVN repository In-Reply-To: <464E408F.5090505@sun.com> References: <20070518191429.GA5886@chatteau.d.lf> <464E408F.5090505@sun.com> Message-ID: <200705202025.06379.wahjava.ml@gmail.com> On Saturday 19 May 2007, Jonathan Gibbons wrote: | Ashish, | | My apologies: the information on the compiler page is currently out of | date. No problem. | | To get the compiler files from a Subversion repository, you currently | have to go through the main OpenJDK repository, using the instructions | liked under the "Subversion" link on the left side of the page. Thanks for the reply. | | -- Jon | Ashish Shukla -- Ashish Shukla "Wah Java !!" ???? ????? ,= ,-_-. =. webpages: http://wahjava.googlepages.com ((_/)o o(\_)) weblog: http://wahjava.wordpress.com `-'(. .)`-' PGP: 1E00 4679 77E4 F8EE 2E4B 56F2 1F2F 8410 762E 5E74 \_/ "We've so many people in India,that we're able to route each network packet manually." ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? -- nobotz to wahjava -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20070520/27e663ce/attachment.bin From wahjava at gmail.com Sun May 20 07:45:08 2007 From: wahjava at gmail.com (=?utf-8?q?=E0=A4=86=E0=A4=B6=E0=A5=80=E0=A4=B7_Ashish?=) Date: Sun, 20 May 2007 20:15:08 +0530 Subject: Inaccessible 'javac' SVN repository In-Reply-To: <464E408F.5090505@sun.com> References: <20070518191429.GA5886@chatteau.d.lf> <464E408F.5090505@sun.com> Message-ID: <200705202015.24274.wahjava@gmail.com> On Saturday 19 May 2007, Jonathan Gibbons wrote: | Ashish, | | My apologies: the information on the compiler page is currently out of | date. | | To get the compiler files from a Subversion repository, you currently | have to go through the main OpenJDK repository, using the instructions | liked under the "Subversion" link on the left side of the page. Thanks for the reply. | -- Jon Ashish Shukla -- Ashish Shukla "Wah Java !!" ???? ????? ,= ,-_-. =. webpages: http://wahjava.googlepages.com ((_/)o o(\_)) weblog: http://wahjava.wordpress.com `-'(. .)`-' PGP: 1E00 4679 77E4 F8EE 2E4B 56F2 1F2F 8410 762E 5E74 \_/ "We've so many people in India,that we're able to route each network packet manually." ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? -- nobotz to wahjava -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20070520/63a321b4/attachment.bin From Tom.Marble at Sun.COM Sun May 20 13:25:47 2007 From: Tom.Marble at Sun.COM (Tom Marble) Date: Sun, 20 May 2007 15:25:47 -0500 Subject: test of new Gmane migration Message-ID: <4650AECB.5030005@sun.com> All: Please ignore this test message whose purpose is to confirm that the Gmane gateway has been migrated from the old list to the new list. --Tom From Jonathan.Gibbons at Sun.COM Mon May 21 22:31:55 2007 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Mon, 21 May 2007 22:31:55 -0700 Subject: javac: not just for java? Message-ID: OK, here's the wacky thought for the day ... With KSL, you can experiment with your own "wacky" language features. Except that that if they're wacky you can't call it Java. But if you are still targeting the JVM, wouldn't you want to be able to mix n match Java code and your wacky language, assuming they were sufficiently interoperable. OK, so the premise might be a bit contrived, but assume it for now ... What would it take to mix n match "sufficiently similar" languages in javac? Internally, javac is divided into a number of components,, such as the scanner (or lexer), the parser, "enter" and "member-enter", "attr", "flow", and so on all the way through to "gen". These components can be divided into two groups, according to whether they are language specific or not. Informally, if the components come from the "parser" or "comp" packages, that means they are very specific to the Java language. If they come from "code" or "jvm", they are closer to the JVM. Currently these components are held as singletons in the Context object. But imagine if we introduced a new Language object, that contained the language specific components, and then could put a number of Language objects in the context, indexed by a Language Kind, possibly derived from the filename extension of a source file. (This would need to be expressed in JSR199 terms for the JavaFileManager of course.) So then, when javac goes to parse a file, it uses the file extension to determine a Language object from which it can get a Scanner and Parser. The result would be an object that could be processed through the rest of the compiler's pipeline, using language-specific components as needed, and using language independent components for the types and symbols, and eventually gen. If the languages are sufficiently similar or compatible (no-TM) with Java, it should be able to define how such source files could interoperate with Java source files, and be compiled alongside them. This is clearly just a wacky idea, barely half-baked, and we would have to resolve issues like locating source files on the source path for missing class files. And the javac spec purists might grumble and we'd have to call it something else (kslc, anyone?) but it might prove a way to mix n match KSL variants with real Java code. -- Jon G From ted at tedneward.com Tue May 22 22:37:02 2007 From: ted at tedneward.com (Ted Neward) Date: Tue, 22 May 2007 22:37:02 -0700 Subject: javac: not just for java? In-Reply-To: Message-ID: <057701c79cfc$653cbf00$802ca8c0@XPWork> Would this be just trying to keep different compilers around in memory for different compilation runs, or are you trying to allow for multiple compilers being invoked as part of one compilation pass? The former would seem MUCH more approachable than the latter.... 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: Monday, May 21, 2007 10:32 PM > To: compiler-dev at openjdk.java.net > Subject: javac: not just for java? > > OK, here's the wacky thought for the day ... > > With KSL, you can experiment with your own "wacky" language features. > Except that that if they're wacky you can't call it Java. But if you > are still targeting the JVM, wouldn't you want to be able to mix n > match Java code and your wacky language, assuming they were > sufficiently interoperable. > > OK, so the premise might be a bit contrived, but assume it for now ... > > What would it take to mix n match "sufficiently similar" languages in > javac? > > Internally, javac is divided into a number of components,, such as > the scanner (or lexer), the parser, "enter" and "member-enter", > "attr", "flow", and so on all the way through to "gen". These > components can be divided into two groups, according to whether they > are language specific or not. Informally, if the components come from > the "parser" or "comp" packages, that means they are very specific to > the Java language. If they come from "code" or "jvm", they are closer > to the JVM. > > Currently these components are held as singletons in the Context > object. But imagine if we introduced a new Language object, that > contained the language specific components, and then could put a > number of Language objects in the context, indexed by a Language > Kind, possibly derived from the filename extension of a source file. > (This would need to be expressed in JSR199 terms for the > JavaFileManager of course.) So then, when javac goes to parse a file, > it uses the file extension to determine a Language object from which > it can get a Scanner and Parser. The result would be an object that > could be processed through the rest of the compiler's pipeline, using > language-specific components as needed, and using language > independent components for the types and symbols, and eventually > gen. If the languages are sufficiently similar or compatible (no-TM) > with Java, it should be able to define how such source files could > interoperate with Java source files, and be compiled alongside them. > > This is clearly just a wacky idea, barely half-baked, and we would > have to resolve issues like locating source files on the source path > for missing class files. And the javac spec purists might grumble > and we'd have to call it something else (kslc, anyone?) but it might > prove a way to mix n match KSL variants with real Java code. > > -- Jon G > > > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.467 / Virus Database: 269.7.6/814 - Release Date: 5/21/2007 > 2:01 PM > No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.467 / Virus Database: 269.7.6/814 - Release Date: 5/21/2007 2:01 PM From peter at ahe.dk Tue May 22 22:59:44 2007 From: peter at ahe.dk (=?ISO-8859-1?Q?Peter_Ah=E9?=) Date: Tue, 22 May 2007 22:59:44 -0700 Subject: javac: not just for java? In-Reply-To: <057701c79cfc$653cbf00$802ca8c0@XPWork> References: <057701c79cfc$653cbf00$802ca8c0@XPWork> Message-ID: I think Ted is on to something. If this is just to manage a shared code-base that supports both .java and .ksl files from different command, then I do not see the need to add a language object to context. However, if you want to create a multilingual compiler (mlc) that can compile both files at once, perhaps it makes sense: mlc MyClass.java MyOtherClass.ksl CoolClass.scala The trick would be to get all these files entered at the same time, so they can all have mutual references. Cheers, Peter On 5/22/07, Ted Neward wrote: > Would this be just trying to keep different compilers around in memory for > different compilation runs, or are you trying to allow for multiple > compilers being invoked as part of one compilation pass? The former would > seem MUCH more approachable than the latter.... > > 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: Monday, May 21, 2007 10:32 PM > > To: compiler-dev at openjdk.java.net > > Subject: javac: not just for java? > > > > OK, here's the wacky thought for the day ... > > > > With KSL, you can experiment with your own "wacky" language features. > > Except that that if they're wacky you can't call it Java. But if you > > are still targeting the JVM, wouldn't you want to be able to mix n > > match Java code and your wacky language, assuming they were > > sufficiently interoperable. > > > > OK, so the premise might be a bit contrived, but assume it for now ... > > > > What would it take to mix n match "sufficiently similar" languages in > > javac? > > > > Internally, javac is divided into a number of components,, such as > > the scanner (or lexer), the parser, "enter" and "member-enter", > > "attr", "flow", and so on all the way through to "gen". These > > components can be divided into two groups, according to whether they > > are language specific or not. Informally, if the components come from > > the "parser" or "comp" packages, that means they are very specific to > > the Java language. If they come from "code" or "jvm", they are closer > > to the JVM. > > > > Currently these components are held as singletons in the Context > > object. But imagine if we introduced a new Language object, that > > contained the language specific components, and then could put a > > number of Language objects in the context, indexed by a Language > > Kind, possibly derived from the filename extension of a source file. > > (This would need to be expressed in JSR199 terms for the > > JavaFileManager of course.) So then, when javac goes to parse a file, > > it uses the file extension to determine a Language object from which > > it can get a Scanner and Parser. The result would be an object that > > could be processed through the rest of the compiler's pipeline, using > > language-specific components as needed, and using language > > independent components for the types and symbols, and eventually > > gen. If the languages are sufficiently similar or compatible (no-TM) > > with Java, it should be able to define how such source files could > > interoperate with Java source files, and be compiled alongside them. > > > > This is clearly just a wacky idea, barely half-baked, and we would > > have to resolve issues like locating source files on the source path > > for missing class files. And the javac spec purists might grumble > > and we'd have to call it something else (kslc, anyone?) but it might > > prove a way to mix n match KSL variants with real Java code. > > > > -- Jon G > > > > > > > > No virus found in this incoming message. > > Checked by AVG Free Edition. > > Version: 7.5.467 / Virus Database: 269.7.6/814 - Release Date: 5/21/2007 > > 2:01 PM > > > > No virus found in this outgoing message. > Checked by AVG Free Edition. > Version: 7.5.467 / Virus Database: 269.7.6/814 - Release Date: 5/21/2007 > 2:01 PM > > > From Jonathan.Gibbons at Sun.COM Tue May 22 23:15:37 2007 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Tue, 22 May 2007 23:15:37 -0700 Subject: javac: not just for java? In-Reply-To: References: <057701c79cfc$653cbf00$802ca8c0@XPWork> Message-ID: <89CA68E3-0D9B-4AFB-B9D3-A918EB928320@sun.com> Yes, the thought is to be able to handle mutually referential source files on the command line at the same time,, which is why we would have a Language object yo abstract what it means to parse the files, enter the symbols, do semantic analysis, and so on. -- Jon G On May 22, 2007, at 10:59 PM, Peter Ah? wrote: > I think Ted is on to something. If this is just to manage a shared > code-base that supports both .java and .ksl files from different > command, then I do not see the need to add a language object to > context. However, if you want to create a multilingual compiler (mlc) > that can compile both files at once, perhaps it makes sense: > > mlc MyClass.java MyOtherClass.ksl CoolClass.scala > > The trick would be to get all these files entered at the same time, so > they can all have mutual references. > > Cheers, > Peter > > On 5/22/07, Ted Neward wrote: >> Would this be just trying to keep different compilers around in >> memory for >> different compilation runs, or are you trying to allow for multiple >> compilers being invoked as part of one compilation pass? The >> former would >> seem MUCH more approachable than the latter.... >> >> 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: Monday, May 21, 2007 10:32 PM >> > To: compiler-dev at openjdk.java.net >> > Subject: javac: not just for java? >> > >> > OK, here's the wacky thought for the day ... >> > >> > With KSL, you can experiment with your own "wacky" language >> features. >> > Except that that if they're wacky you can't call it Java. But if >> you >> > are still targeting the JVM, wouldn't you want to be able to mix n >> > match Java code and your wacky language, assuming they were >> > sufficiently interoperable. >> > >> > OK, so the premise might be a bit contrived, but assume it for >> now ... >> > >> > What would it take to mix n match "sufficiently similar" >> languages in >> > javac? >> > >> > Internally, javac is divided into a number of components,, such as >> > the scanner (or lexer), the parser, "enter" and "member-enter", >> > "attr", "flow", and so on all the way through to "gen". These >> > components can be divided into two groups, according to whether >> they >> > are language specific or not. Informally, if the components come >> from >> > the "parser" or "comp" packages, that means they are very >> specific to >> > the Java language. If they come from "code" or "jvm", they are >> closer >> > to the JVM. >> > >> > Currently these components are held as singletons in the Context >> > object. But imagine if we introduced a new Language object, that >> > contained the language specific components, and then could put a >> > number of Language objects in the context, indexed by a Language >> > Kind, possibly derived from the filename extension of a source >> file. >> > (This would need to be expressed in JSR199 terms for the >> > JavaFileManager of course.) So then, when javac goes to parse a >> file, >> > it uses the file extension to determine a Language object from >> which >> > it can get a Scanner and Parser. The result would be an object that >> > could be processed through the rest of the compiler's pipeline, >> using >> > language-specific components as needed, and using language >> > independent components for the types and symbols, and eventually >> > gen. If the languages are sufficiently similar or compatible >> (no-TM) >> > with Java, it should be able to define how such source files could >> > interoperate with Java source files, and be compiled alongside >> them. >> > >> > This is clearly just a wacky idea, barely half-baked, and we would >> > have to resolve issues like locating source files on the source >> path >> > for missing class files. And the javac spec purists might grumble >> > and we'd have to call it something else (kslc, anyone?) but it >> might >> > prove a way to mix n match KSL variants with real Java code. >> > >> > -- Jon G >> > >> > >> > >> > No virus found in this incoming message. >> > Checked by AVG Free Edition. >> > Version: 7.5.467 / Virus Database: 269.7.6/814 - Release Date: >> 5/21/2007 >> > 2:01 PM >> > >> >> No virus found in this outgoing message. >> Checked by AVG Free Edition. >> Version: 7.5.467 / Virus Database: 269.7.6/814 - Release Date: >> 5/21/2007 >> 2:01 PM >> >> >> From peter at ahe.dk Tue May 22 23:20:13 2007 From: peter at ahe.dk (=?ISO-8859-1?Q?Peter_Ah=E9?=) Date: Tue, 22 May 2007 23:20:13 -0700 Subject: javac: not just for java? In-Reply-To: <89CA68E3-0D9B-4AFB-B9D3-A918EB928320@sun.com> References: <057701c79cfc$653cbf00$802ca8c0@XPWork> <89CA68E3-0D9B-4AFB-B9D3-A918EB928320@sun.com> Message-ID: Sounds like an interesting approach and a fun project. I guess it will be easier if all the languages can share the Symbol/Element protocol. Cheers, Peter On 5/22/07, Jonathan Gibbons wrote: > Yes, the thought is to be able to handle mutually referential source > files on the > command line at the same time,, which is why we would have a Language > object > yo abstract what it means to parse the files, enter the symbols, do > semantic analysis, > and so on. > > -- Jon G > > On May 22, 2007, at 10:59 PM, Peter Ah? wrote: > > > I think Ted is on to something. If this is just to manage a shared > > code-base that supports both .java and .ksl files from different > > command, then I do not see the need to add a language object to > > context. However, if you want to create a multilingual compiler (mlc) > > that can compile both files at once, perhaps it makes sense: > > > > mlc MyClass.java MyOtherClass.ksl CoolClass.scala > > > > The trick would be to get all these files entered at the same time, so > > they can all have mutual references. > > > > Cheers, > > Peter > > > > On 5/22/07, Ted Neward wrote: > >> Would this be just trying to keep different compilers around in > >> memory for > >> different compilation runs, or are you trying to allow for multiple > >> compilers being invoked as part of one compilation pass? The > >> former would > >> seem MUCH more approachable than the latter.... > >> > >> 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: Monday, May 21, 2007 10:32 PM > >> > To: compiler-dev at openjdk.java.net > >> > Subject: javac: not just for java? > >> > > >> > OK, here's the wacky thought for the day ... > >> > > >> > With KSL, you can experiment with your own "wacky" language > >> features. > >> > Except that that if they're wacky you can't call it Java. But if > >> you > >> > are still targeting the JVM, wouldn't you want to be able to mix n > >> > match Java code and your wacky language, assuming they were > >> > sufficiently interoperable. > >> > > >> > OK, so the premise might be a bit contrived, but assume it for > >> now ... > >> > > >> > What would it take to mix n match "sufficiently similar" > >> languages in > >> > javac? > >> > > >> > Internally, javac is divided into a number of components,, such as > >> > the scanner (or lexer), the parser, "enter" and "member-enter", > >> > "attr", "flow", and so on all the way through to "gen". These > >> > components can be divided into two groups, according to whether > >> they > >> > are language specific or not. Informally, if the components come > >> from > >> > the "parser" or "comp" packages, that means they are very > >> specific to > >> > the Java language. If they come from "code" or "jvm", they are > >> closer > >> > to the JVM. > >> > > >> > Currently these components are held as singletons in the Context > >> > object. But imagine if we introduced a new Language object, that > >> > contained the language specific components, and then could put a > >> > number of Language objects in the context, indexed by a Language > >> > Kind, possibly derived from the filename extension of a source > >> file. > >> > (This would need to be expressed in JSR199 terms for the > >> > JavaFileManager of course.) So then, when javac goes to parse a > >> file, > >> > it uses the file extension to determine a Language object from > >> which > >> > it can get a Scanner and Parser. The result would be an object that > >> > could be processed through the rest of the compiler's pipeline, > >> using > >> > language-specific components as needed, and using language > >> > independent components for the types and symbols, and eventually > >> > gen. If the languages are sufficiently similar or compatible > >> (no-TM) > >> > with Java, it should be able to define how such source files could > >> > interoperate with Java source files, and be compiled alongside > >> them. > >> > > >> > This is clearly just a wacky idea, barely half-baked, and we would > >> > have to resolve issues like locating source files on the source > >> path > >> > for missing class files. And the javac spec purists might grumble > >> > and we'd have to call it something else (kslc, anyone?) but it > >> might > >> > prove a way to mix n match KSL variants with real Java code. > >> > > >> > -- Jon G > >> > > >> > > >> > > >> > No virus found in this incoming message. > >> > Checked by AVG Free Edition. > >> > Version: 7.5.467 / Virus Database: 269.7.6/814 - Release Date: > >> 5/21/2007 > >> > 2:01 PM > >> > > >> > >> No virus found in this outgoing message. > >> Checked by AVG Free Edition. > >> Version: 7.5.467 / Virus Database: 269.7.6/814 - Release Date: > >> 5/21/2007 > >> 2:01 PM > >> > >> > >> > > From Jonathan.Gibbons at Sun.COM Tue May 22 23:28:07 2007 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Tue, 22 May 2007 23:28:07 -0700 Subject: javac: not just for java? In-Reply-To: References: <057701c79cfc$653cbf00$802ca8c0@XPWork> <89CA68E3-0D9B-4AFB-B9D3-A918EB928320@sun.com> Message-ID: Yes, that is a presumption here, based on the fact that the presumed languages are targeting the JVM in a reasonably sane manner. If they don't share that, there is little point sharing the compilation. -- Jon On May 22, 2007, at 11:20 PM, Peter Ah? wrote: > Sounds like an interesting approach and a fun project. I guess it > will be easier if all the languages can share the Symbol/Element > protocol. > > Cheers, > Peter > > On 5/22/07, Jonathan Gibbons wrote: >> Yes, the thought is to be able to handle mutually referential source >> files on the >> command line at the same time,, which is why we would have a Language >> object >> yo abstract what it means to parse the files, enter the symbols, do >> semantic analysis, >> and so on. >> >> -- Jon G >> >> On May 22, 2007, at 10:59 PM, Peter Ah? wrote: >> >> > I think Ted is on to something. If this is just to manage a shared >> > code-base that supports both .java and .ksl files from different >> > command, then I do not see the need to add a language object to >> > context. However, if you want to create a multilingual compiler >> (mlc) >> > that can compile both files at once, perhaps it makes sense: >> > >> > mlc MyClass.java MyOtherClass.ksl CoolClass.scala >> > >> > The trick would be to get all these files entered at the same >> time, so >> > they can all have mutual references. >> > >> > Cheers, >> > Peter >> > >> > On 5/22/07, Ted Neward wrote: >> >> Would this be just trying to keep different compilers around in >> >> memory for >> >> different compilation runs, or are you trying to allow for >> multiple >> >> compilers being invoked as part of one compilation pass? The >> >> former would >> >> seem MUCH more approachable than the latter.... >> >> >> >> 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: Monday, May 21, 2007 10:32 PM >> >> > To: compiler-dev at openjdk.java.net >> >> > Subject: javac: not just for java? >> >> > >> >> > OK, here's the wacky thought for the day ... >> >> > >> >> > With KSL, you can experiment with your own "wacky" language >> >> features. >> >> > Except that that if they're wacky you can't call it Java. But if >> >> you >> >> > are still targeting the JVM, wouldn't you want to be able to >> mix n >> >> > match Java code and your wacky language, assuming they were >> >> > sufficiently interoperable. >> >> > >> >> > OK, so the premise might be a bit contrived, but assume it for >> >> now ... >> >> > >> >> > What would it take to mix n match "sufficiently similar" >> >> languages in >> >> > javac? >> >> > >> >> > Internally, javac is divided into a number of components,, >> such as >> >> > the scanner (or lexer), the parser, "enter" and "member-enter", >> >> > "attr", "flow", and so on all the way through to "gen". These >> >> > components can be divided into two groups, according to whether >> >> they >> >> > are language specific or not. Informally, if the components come >> >> from >> >> > the "parser" or "comp" packages, that means they are very >> >> specific to >> >> > the Java language. If they come from "code" or "jvm", they are >> >> closer >> >> > to the JVM. >> >> > >> >> > Currently these components are held as singletons in the Context >> >> > object. But imagine if we introduced a new Language object, >> that >> >> > contained the language specific components, and then could put a >> >> > number of Language objects in the context, indexed by a Language >> >> > Kind, possibly derived from the filename extension of a source >> >> file. >> >> > (This would need to be expressed in JSR199 terms for the >> >> > JavaFileManager of course.) So then, when javac goes to parse a >> >> file, >> >> > it uses the file extension to determine a Language object from >> >> which >> >> > it can get a Scanner and Parser. The result would be an >> object that >> >> > could be processed through the rest of the compiler's pipeline, >> >> using >> >> > language-specific components as needed, and using language >> >> > independent components for the types and symbols, and eventually >> >> > gen. If the languages are sufficiently similar or compatible >> >> (no-TM) >> >> > with Java, it should be able to define how such source files >> could >> >> > interoperate with Java source files, and be compiled alongside >> >> them. >> >> > >> >> > This is clearly just a wacky idea, barely half-baked, and we >> would >> >> > have to resolve issues like locating source files on the source >> >> path >> >> > for missing class files. And the javac spec purists might >> grumble >> >> > and we'd have to call it something else (kslc, anyone?) but it >> >> might >> >> > prove a way to mix n match KSL variants with real Java code. >> >> > >> >> > -- Jon G >> >> > >> >> > >> >> > >> >> > No virus found in this incoming message. >> >> > Checked by AVG Free Edition. >> >> > Version: 7.5.467 / Virus Database: 269.7.6/814 - Release Date: >> >> 5/21/2007 >> >> > 2:01 PM >> >> > >> >> >> >> No virus found in this outgoing message. >> >> Checked by AVG Free Edition. >> >> Version: 7.5.467 / Virus Database: 269.7.6/814 - Release Date: >> >> 5/21/2007 >> >> 2:01 PM >> >> >> >> >> >> >> >> From Peter.Kessler at Sun.COM Wed May 23 09:44:07 2007 From: Peter.Kessler at Sun.COM (Peter B. Kessler) Date: Wed, 23 May 2007 09:44:07 -0700 Subject: javac: not just for java? In-Reply-To: References: <057701c79cfc$653cbf00$802ca8c0@XPWork> Message-ID: <46546F57.2030701@Sun.COM> I was thinking this might be useful at another level: for multi-language files with small embedded languages. E.g., if I have SQL constants in my Java code, why shouldn't I have to leave the interpretation of that to runtime? Why can't an SQL compiler jump in at compile time and produce bytecode, runtime calls, etc.? An easy case might be compiling regular expressions at compile time, rather than wasting runtime on that. ... peter Peter Ah? wrote: > I think Ted is on to something. If this is just to manage a shared > code-base that supports both .java and .ksl files from different > command, then I do not see the need to add a language object to > context. However, if you want to create a multilingual compiler (mlc) > that can compile both files at once, perhaps it makes sense: > > mlc MyClass.java MyOtherClass.ksl CoolClass.scala > > The trick would be to get all these files entered at the same time, so > they can all have mutual references. > > Cheers, > Peter > > On 5/22/07, Ted Neward wrote: >> Would this be just trying to keep different compilers around in memory >> for >> different compilation runs, or are you trying to allow for multiple >> compilers being invoked as part of one compilation pass? The former would >> seem MUCH more approachable than the latter.... >> >> 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: Monday, May 21, 2007 10:32 PM >> > To: compiler-dev at openjdk.java.net >> > Subject: javac: not just for java? >> > >> > OK, here's the wacky thought for the day ... >> > >> > With KSL, you can experiment with your own "wacky" language features. >> > Except that that if they're wacky you can't call it Java. But if you >> > are still targeting the JVM, wouldn't you want to be able to mix n >> > match Java code and your wacky language, assuming they were >> > sufficiently interoperable. >> > >> > OK, so the premise might be a bit contrived, but assume it for now ... >> > >> > What would it take to mix n match "sufficiently similar" languages in >> > javac? >> > >> > Internally, javac is divided into a number of components,, such as >> > the scanner (or lexer), the parser, "enter" and "member-enter", >> > "attr", "flow", and so on all the way through to "gen". These >> > components can be divided into two groups, according to whether they >> > are language specific or not. Informally, if the components come from >> > the "parser" or "comp" packages, that means they are very specific to >> > the Java language. If they come from "code" or "jvm", they are closer >> > to the JVM. >> > >> > Currently these components are held as singletons in the Context >> > object. But imagine if we introduced a new Language object, that >> > contained the language specific components, and then could put a >> > number of Language objects in the context, indexed by a Language >> > Kind, possibly derived from the filename extension of a source file. >> > (This would need to be expressed in JSR199 terms for the >> > JavaFileManager of course.) So then, when javac goes to parse a file, >> > it uses the file extension to determine a Language object from which >> > it can get a Scanner and Parser. The result would be an object that >> > could be processed through the rest of the compiler's pipeline, using >> > language-specific components as needed, and using language >> > independent components for the types and symbols, and eventually >> > gen. If the languages are sufficiently similar or compatible (no-TM) >> > with Java, it should be able to define how such source files could >> > interoperate with Java source files, and be compiled alongside them. >> > >> > This is clearly just a wacky idea, barely half-baked, and we would >> > have to resolve issues like locating source files on the source path >> > for missing class files. And the javac spec purists might grumble >> > and we'd have to call it something else (kslc, anyone?) but it might >> > prove a way to mix n match KSL variants with real Java code. >> > >> > -- Jon G From peter at ahe.dk Thu May 24 08:33:52 2007 From: peter at ahe.dk (=?ISO-8859-1?Q?Peter_Ah=E9?=) Date: Thu, 24 May 2007 08:33:52 -0700 Subject: javac: not just for java? In-Reply-To: <4D334D66-2A3E-4780-98EF-FDDEB44E8D23@sun.com> References: <057701c79cfc$653cbf00$802ca8c0@XPWork> <46546F57.2030701@Sun.COM> <4D334D66-2A3E-4780-98EF-FDDEB44E8D23@sun.com> Message-ID: No thanks. I do just fine without them :-) Cheers, Peter On 5/24/07, Jonathan Gibbons wrote: > Hmmm, XML literals, anyone? > > It would be interesting to see if we could leverage such an > architecture if one were in place. > > -- Jon > > > On May 23, 2007, at 9:44 AM, Peter B. Kessler wrote: > > > I was thinking this might be useful at another level: for > > multi-language files with small embedded languages. E.g., > > if I have SQL constants in my Java code, why shouldn't I > > have to leave the interpretation of that to runtime? Why > > can't an SQL compiler jump in at compile time and produce > > bytecode, runtime calls, etc.? An easy case might be > > compiling regular expressions at compile time, rather > > than wasting runtime on that. > > > > ... peter > > > > Peter Ah? wrote: > >> I think Ted is on to something. If this is just to manage a shared > >> code-base that supports both .java and .ksl files from different > >> command, then I do not see the need to add a language object to > >> context. However, if you want to create a multilingual compiler > >> (mlc) > >> that can compile both files at once, perhaps it makes sense: > >> mlc MyClass.java MyOtherClass.ksl CoolClass.scala > >> The trick would be to get all these files entered at the same > >> time, so > >> they can all have mutual references. > >> Cheers, > >> Peter > >> On 5/22/07, Ted Neward wrote: > >>> Would this be just trying to keep different compilers around in > >>> memory for > >>> different compilation runs, or are you trying to allow for multiple > >>> compilers being invoked as part of one compilation pass? The > >>> former would > >>> seem MUCH more approachable than the latter.... > >>> > >>> 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: Monday, May 21, 2007 10:32 PM > >>> > To: compiler-dev at openjdk.java.net > >>> > Subject: javac: not just for java? > >>> > > >>> > OK, here's the wacky thought for the day ... > >>> > > >>> > With KSL, you can experiment with your own "wacky" language > >>> features. > >>> > Except that that if they're wacky you can't call it Java. But > >>> if you > >>> > are still targeting the JVM, wouldn't you want to be able to mix n > >>> > match Java code and your wacky language, assuming they were > >>> > sufficiently interoperable. > >>> > > >>> > OK, so the premise might be a bit contrived, but assume it for > >>> now ... > >>> > > >>> > What would it take to mix n match "sufficiently similar" > >>> languages in > >>> > javac? > >>> > > >>> > Internally, javac is divided into a number of components,, such as > >>> > the scanner (or lexer), the parser, "enter" and "member-enter", > >>> > "attr", "flow", and so on all the way through to "gen". These > >>> > components can be divided into two groups, according to whether > >>> they > >>> > are language specific or not. Informally, if the components > >>> come from > >>> > the "parser" or "comp" packages, that means they are very > >>> specific to > >>> > the Java language. If they come from "code" or "jvm", they are > >>> closer > >>> > to the JVM. > >>> > > >>> > Currently these components are held as singletons in the Context > >>> > object. But imagine if we introduced a new Language object, that > >>> > contained the language specific components, and then could put a > >>> > number of Language objects in the context, indexed by a Language > >>> > Kind, possibly derived from the filename extension of a source > >>> file. > >>> > (This would need to be expressed in JSR199 terms for the > >>> > JavaFileManager of course.) So then, when javac goes to parse a > >>> file, > >>> > it uses the file extension to determine a Language object from > >>> which > >>> > it can get a Scanner and Parser. The result would be an object > >>> that > >>> > could be processed through the rest of the compiler's pipeline, > >>> using > >>> > language-specific components as needed, and using language > >>> > independent components for the types and symbols, and eventually > >>> > gen. If the languages are sufficiently similar or compatible > >>> (no-TM) > >>> > with Java, it should be able to define how such source files could > >>> > interoperate with Java source files, and be compiled alongside > >>> them. > >>> > > >>> > This is clearly just a wacky idea, barely half-baked, and we would > >>> > have to resolve issues like locating source files on the source > >>> path > >>> > for missing class files. And the javac spec purists might grumble > >>> > and we'd have to call it something else (kslc, anyone?) but it > >>> might > >>> > prove a way to mix n match KSL variants with real Java code. > >>> > > >>> > -- Jon G > > > > From patrick.mcnally at pomona.edu Thu May 24 12:50:56 2007 From: patrick.mcnally at pomona.edu (Patrick McNally) Date: Thu, 24 May 2007 12:50:56 -0700 Subject: Disassembler for javac? Message-ID: <177BF2D8-958F-4E14-8314-2C7B0729ABF7@pomona.edu> Hello, Is there a disassembler (preferably open source) that works with the .class files generated by the openjdk javac? Jreversepro seems to complain that the openjdk compiler is of a version that it won't accept. In particular I'm looking for something that would present attributes present in the .class file in a human readable format. Much thanks! -Patrick ------------------------------------------------------------- This message has been scanned by Postini anti-virus software. From trevor at vocaro.com Thu May 24 13:26:40 2007 From: trevor at vocaro.com (Trevor Harmon) Date: Thu, 24 May 2007 13:26:40 -0700 Subject: Disassembler for javac? In-Reply-To: <177BF2D8-958F-4E14-8314-2C7B0729ABF7@pomona.edu> References: <177BF2D8-958F-4E14-8314-2C7B0729ABF7@pomona.edu> Message-ID: On May 24, 2007, at 12:50 PM, Patrick McNally wrote: > Is there a disassembler (preferably open source) that works with > the .class files generated by the openjdk javac? How about javap? > Jreversepro seems to complain that the openjdk compiler is of a > version that it won't accept. Do you mean disassembler or decompiler? If you're looking for a decompiler, JODE (repository version) works fine with the OpenJDK javac. > In particular I'm looking for something that would present > attributes present in the .class file in a human readable format. > Much thanks! Oh, in that case, how about BCEL? I used BCEL to write a utility that would dump annotation data to the console in a human-readable format (identical to the one used in the Java Virtual Machine Specification). Maybe you could modify what I did into something that would work for you: http://volta.svn.sourceforge.net/viewvc/volta/util/dump-annotations/ Trevor From ernst.matthias at gmail.com Sat May 26 06:19:39 2007 From: ernst.matthias at gmail.com (Matthias Ernst) Date: Sat, 26 May 2007 15:19:39 +0200 Subject: Fwd: Right direction? In-Reply-To: <22ec15240705260616me349d4bi6ba922fd3f05d44f@mail.gmail.com> References: <22ec15240705260616me349d4bi6ba922fd3f05d44f@mail.gmail.com> Message-ID: <22ec15240705260619i3910eb21k319df4204895131e@mail.gmail.com> Hi, I've created an experimental feature, namely cascading for void method calls as described on my blog @ http://mernst.org/blog/rss.xml (Firefox only :-( Patches at the end, too. I would be glad to hear some comments what you think about the patches (not the semantics but the implementation) - did I miss something? A hint how I would find out the receiver type for unqualified method calls without duplicating the lookup strategy in Attr#visitApply would be appreciated, too! Thanks Matthias --- comp/Attr.java.orig.txt 2007-05-26 13:55:53.000000000 +0200 +++ comp/Attr.java 2007-05-26 14:15:51.000000000 +0200 @@ -1315,6 +1315,18 @@ restype.tsym); } + // as a special case, o.m() where m is a void method, has type of o + if(restype == Symtab.voidType && !isStatic(TreeInfo.symbol(tree.meth))) { + if(tree.meth.tag != JCTree.SELECT) { + log.warning(tree.meth.pos(), "Cannot (yet) cascade unqualified method call"); + } else { + JCExpression receiver = ((JCFieldAccess) tree.meth).selected; + restype = receiver.type; + } + } + + + // Check that value of resulting type is admissible in the // current context. Also, capture the return type result = check(tree, capture(restype), VAL, pkind, pt); --- comp/TransTypes.java.orig.txt 2007-05-26 13:56:46.000000000 +0200 +++ comp/TransTypes.java 2007-05-26 14:15:51.000000000 +0200 @@ -583,7 +587,8 @@ tree.args = translateArgs(tree.args, argtypes, tree.varargsElement); // Insert casts of method invocation results as needed. - result = retype(tree, mt.getReturnType(), pt); + // mernst: do not use mt.resType as cascading may have changed it + result = retype(tree, types.erasure(tree.type), pt); } public void visitNewClass(JCNewClass tree) { --- jvm/Gen.java.orig.txt 2007-05-26 14:00:07.000000000 +0200 +++ jvm/Gen.java 2007-05-26 14:16:38.000000000 +0200 @@ -1664,14 +1664,24 @@ *************************************************************************/ public void visitApply(JCMethodInvocation tree) { + // Generate code for method. Item m = genExpr(tree.meth, methodType); + + // in case of a cascade, duplicate the receiver + boolean cascaded = ((MethodType)tree.meth.type).restype == Symtab.voidType && tree.type != Symtab.voidType; + Item stackItem = cascaded ? items.makeStackItem(tree.type) : null; + if(cascaded) stackItem.duplicate(); + // Generate code for all arguments, where the expected types are // the parameters of the method's external type (that is, any implicit // outer instance of a super(...) call appears as first parameter). genArgs(tree.args, TreeInfo.symbol(tree.meth).externalType(types).getParameterTypes()); result = m.invoke(); + + // in case of a cascade, the receiver is top of stack now + if(cascaded) result = stackItem; } public void visitConditional(JCConditional tree) { From peter at ahe.dk Sat May 26 09:44:27 2007 From: peter at ahe.dk (=?ISO-8859-1?Q?Peter_Ah=E9?=) Date: Sat, 26 May 2007 09:44:27 -0700 Subject: Right direction? In-Reply-To: <22ec15240705260619i3910eb21k319df4204895131e@mail.gmail.com> References: <22ec15240705260616me349d4bi6ba922fd3f05d44f@mail.gmail.com> <22ec15240705260619i3910eb21k319df4204895131e@mail.gmail.com> Message-ID: Your patch is line wrapped. Could you try to resend it as an attachment? Cheers, Peter On 5/26/07, Matthias Ernst wrote: > Hi, > > I've created an experimental feature, namely cascading for void method > calls as described on my blog @ http://mernst.org/blog/rss.xml > (Firefox only :-( Patches at the end, too. > > I would be glad to hear some comments what you think about the patches > (not the semantics but the implementation) - did I miss something? A > hint how I would find out the receiver type for unqualified method > calls without duplicating the lookup strategy in Attr#visitApply would > be appreciated, too! > > > Thanks > Matthias > > > > --- comp/Attr.java.orig.txt 2007-05-26 13:55:53.000000000 +0200 > +++ comp/Attr.java 2007-05-26 14:15:51.000000000 +0200 > @@ -1315,6 +1315,18 @@ > restype.tsym); > } > + // as a special case, o.m() where m is a void method, has type of o > + if(restype == Symtab.voidType && > !isStatic(TreeInfo.symbol(tree.meth))) { > + if(tree.meth.tag != JCTree.SELECT) { > + log.warning(tree.meth.pos(), "Cannot (yet) > cascade unqualified method call"); > + } else { > + JCExpression receiver = ((JCFieldAccess) > tree.meth).selected; > + restype = receiver.type; > + } > + } > + > + > + > // Check that value of resulting type is admissible in the > // current context. Also, capture the return type > result = check(tree, capture(restype), VAL, pkind, pt); > > --- comp/TransTypes.java.orig.txt 2007-05-26 13:56:46.000000000 +0200 > +++ comp/TransTypes.java 2007-05-26 14:15:51.000000000 +0200 > @@ -583,7 +587,8 @@ > tree.args = translateArgs(tree.args, argtypes, tree.varargsElement); > > // Insert casts of method invocation results as needed. > - result = retype(tree, mt.getReturnType(), pt); > + // mernst: do not use mt.resType as cascading may have changed it > + result = retype(tree, types.erasure(tree.type), pt); > } > > public void visitNewClass(JCNewClass tree) { > > --- jvm/Gen.java.orig.txt 2007-05-26 14:00:07.000000000 +0200 > +++ jvm/Gen.java 2007-05-26 14:16:38.000000000 +0200 > @@ -1664,14 +1664,24 @@ > *************************************************************************/ > > public void visitApply(JCMethodInvocation tree) { > + > // Generate code for method. > Item m = genExpr(tree.meth, methodType); > + > + // in case of a cascade, duplicate the receiver > + boolean cascaded = ((MethodType)tree.meth.type).restype == > Symtab.voidType && tree.type != Symtab.voidType; > + Item stackItem = cascaded ? items.makeStackItem(tree.type) : null; > + if(cascaded) stackItem.duplicate(); > + > // Generate code for all arguments, where the expected types are > // the parameters of the method's external type (that is, any implicit > // outer instance of a super(...) call appears as first parameter). > genArgs(tree.args, > > TreeInfo.symbol(tree.meth).externalType(types).getParameterTypes()); > result = m.invoke(); > + > + // in case of a cascade, the receiver is top of stack now > + if(cascaded) result = stackItem; > } > > public void visitConditional(JCConditional tree) { > From ernst.matthias at gmail.com Sat May 26 09:48:56 2007 From: ernst.matthias at gmail.com (Matthias Ernst) Date: Sat, 26 May 2007 18:48:56 +0200 Subject: Right direction? In-Reply-To: References: <22ec15240705260616me349d4bi6ba922fd3f05d44f@mail.gmail.com> <22ec15240705260619i3910eb21k319df4204895131e@mail.gmail.com> Message-ID: <22ec15240705260948w49db5e5flb1c2ebd8f3c6bd79@mail.gmail.com> On 5/26/07, Peter Ah? wrote: > Your patch is line wrapped. Could you try to resend it as an attachment? > > Cheers, > Peter That should be better. Sorry for that. Matthias -------------- next part -------------- A non-text attachment was scrubbed... Name: patch Type: application/octet-stream Size: 3769 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20070526/aaf047eb/patch.obj From peter at ahe.dk Sat May 26 10:07:26 2007 From: peter at ahe.dk (=?ISO-8859-1?Q?Peter_Ah=E9?=) Date: Sat, 26 May 2007 10:07:26 -0700 Subject: Right direction? In-Reply-To: <22ec15240705260948w49db5e5flb1c2ebd8f3c6bd79@mail.gmail.com> References: <22ec15240705260616me349d4bi6ba922fd3f05d44f@mail.gmail.com> <22ec15240705260619i3910eb21k319df4204895131e@mail.gmail.com> <22ec15240705260948w49db5e5flb1c2ebd8f3c6bd79@mail.gmail.com> Message-ID: Now it is a binary file which means that I cannot view it without adding a few steps. Here are some tips for sending a patch: * make sure that you call it something meaningful, for example, void-method-cascading-v0.1.patch, not file.patch, etc. * make sure that your mail sender does not wrap the the patch (I think you can do this by attaching it as a text file) * make sure that it is displayed inline. * experiment by sending emails to yourself, not the list ;-) The best I can do in Gmail is add .txt to the filename. I have attached the result. Cheers, Peter On 5/26/07, Matthias Ernst wrote: > On 5/26/07, Peter Ah? wrote: > > Your patch is line wrapped. Could you try to resend it as an attachment? > > > > Cheers, > > Peter > > > That should be better. Sorry for that. > > Matthias > > -------------- next part -------------- --- comp/Attr.java.orig.txt 2007-05-26 13:55:53.000000000 +0200 +++ comp/Attr.java 2007-05-26 14:15:51.000000000 +0200 @@ -1315,6 +1315,18 @@ restype.tsym); } + // as a special case, o.m() where m is a void method, has type of o + if(restype == Symtab.voidType && !isStatic(TreeInfo.symbol(tree.meth))) { + if(tree.meth.tag != JCTree.SELECT) { + log.warning(tree.meth.pos(), "Cannot (yet) cascade unqualified method call"); + } else { + JCExpression receiver = ((JCFieldAccess) tree.meth).selected; + restype = receiver.type; + } + } + + + // Check that value of resulting type is admissible in the // current context. Also, capture the return type result = check(tree, capture(restype), VAL, pkind, pt); --- comp/TransTypes.java.orig.txt 2007-05-26 13:56:46.000000000 +0200 +++ comp/TransTypes.java 2007-05-26 14:15:51.000000000 +0200 @@ -25,19 +25,23 @@ package com.sun.tools.javac.comp; -import java.util.*; - +import static com.sun.tools.javac.code.Flags.*; +import static com.sun.tools.javac.code.Kinds.*; import com.sun.tools.javac.code.*; -import com.sun.tools.javac.code.Symbol.*; -import com.sun.tools.javac.tree.*; +import com.sun.tools.javac.code.Symbol.ClassSymbol; +import com.sun.tools.javac.code.Symbol.MethodSymbol; +import com.sun.tools.javac.code.Symbol.TypeSymbol; +import static com.sun.tools.javac.code.TypeTags.*; +import com.sun.tools.javac.tree.JCTree; import com.sun.tools.javac.tree.JCTree.*; +import com.sun.tools.javac.tree.TreeInfo; +import com.sun.tools.javac.tree.TreeMaker; +import com.sun.tools.javac.tree.TreeTranslator; import com.sun.tools.javac.util.*; import com.sun.tools.javac.util.JCDiagnostic.DiagnosticPosition; -import com.sun.tools.javac.util.List; -import static com.sun.tools.javac.code.Flags.*; -import static com.sun.tools.javac.code.Kinds.*; -import static com.sun.tools.javac.code.TypeTags.*; +import java.util.HashMap; +import java.util.Map; /** This pass translates Generic Java to conventional Java. * @@ -583,7 +587,8 @@ tree.args = translateArgs(tree.args, argtypes, tree.varargsElement); // Insert casts of method invocation results as needed. - result = retype(tree, mt.getReturnType(), pt); + // mernst: do not use mt.resType as cascading may have changed it + result = retype(tree, types.erasure(tree.type), pt); } public void visitNewClass(JCNewClass tree) { --- jvm/Gen.java.orig.txt 2007-05-26 14:00:07.000000000 +0200 +++ jvm/Gen.java 2007-05-26 14:16:38.000000000 +0200 @@ -1664,14 +1664,24 @@ *************************************************************************/ public void visitApply(JCMethodInvocation tree) { + // Generate code for method. Item m = genExpr(tree.meth, methodType); + + // in case of a cascade, duplicate the receiver + boolean cascaded = ((MethodType)tree.meth.type).restype == Symtab.voidType && tree.type != Symtab.voidType; + Item stackItem = cascaded ? items.makeStackItem(tree.type) : null; + if(cascaded) stackItem.duplicate(); + // Generate code for all arguments, where the expected types are // the parameters of the method's external type (that is, any implicit // outer instance of a super(...) call appears as first parameter). genArgs(tree.args, TreeInfo.symbol(tree.meth).externalType(types).getParameterTypes()); result = m.invoke(); + + // in case of a cascade, the receiver is top of stack now + if(cascaded) result = stackItem; } public void visitConditional(JCConditional tree) { From James.Gosling at Sun.COM Sat May 26 22:35:38 2007 From: James.Gosling at Sun.COM (James Gosling) Date: Sat, 26 May 2007 22:35:38 -0700 Subject: javac: not just for java? Message-ID: <01F19E25-9DEB-4510-8EDD-A32D7A5CCC9A@sun.com> > What would it take to mix n match "sufficiently similar"languages > in javac? > > Internally, javac is divided into a number of components,, such as > the scanner (or lexer), the parser, "enter" and "member-enter", > "attr", "flow", and so on all the way through to "gen". These > components can be divided into two groups, according to whether they > are language specific or not. Informally, if the components come from > the "parser" or "comp" packages, that means they are very specific to > the Java language. If they come from "code" or "jvm", they are closer > to the JVM. > > Currently these components are held as singletons in the Context > object. But imagine if we introduced a new Language object, that > contained the language specific components, and then could put a > number of Language objects in the context, indexed by a Language > Kind, possibly derived from the filename extension of a source file. Oddly enough, javac once a similar feature. The command line parser would take the file extension and use that to index into a table of objects. It lived most of it's life in an off-to-the-side repository, but was actually checked into the mainline briefly - but it got yanked because of some bugs. It was built by me for the Fortran front end I built: I was trying to see just how weird a language the JVM and javac infrastructure could support. It actually worked very well. I had most of BLAS and LINPACK running when I threw it out (well... I had to start spending time on my real job). Yes, you read right: Fortran. I am sick and twisted. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20070526/bce7e776/attachment.html From robilad at kaffe.org Mon May 28 18:58:15 2007 From: robilad at kaffe.org (Dalibor Topic) Date: Tue, 29 May 2007 03:58:15 +0200 Subject: small fix for makefile for building on linux Message-ID: <465B88B7.8050603@kaffe.org> hi, the attached fix is a small fixlet that lets me use the makefile again for building javac. the patch does three things: * setting SRC_CLASSES to the relative path of the source directories, and * setting ECHO to printf, as that's more useful for posixy systems (and avoids having the build fail due to a spurious -e in the javac.srcfiles file when using bash 3.2.17), and * using BUILD_CLASSES as the location of properties on the classpath, rather than SRC_CLASSES, to avoid wasting time rebuilding the transitive closure of the class library used by javac (and adapting the makefile to deal with things like native or generated classes in that). cheers, dalibor topic -------------- next part -------------- A non-text attachment was scrubbed... Name: javac-makefile-revival.patch Type: text/x-patch Size: 1285 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20070529/5c9f2cff/javac-makefile-revival.patch From Jonathan.Gibbons at Sun.COM Thu May 31 11:33:02 2007 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Thu, 31 May 2007 11:33:02 -0700 Subject: small fix for makefile for building on linux In-Reply-To: <465B88B7.8050603@kaffe.org> References: <465B88B7.8050603@kaffe.org> Message-ID: <465F14DE.9060202@sun.com> Dalibor, Thank you for your suggestions. j2se/src/share/opensource/javac/Makefile is a file was used in the initial Subversion release of the compiler. It is still used in the source bundle available on the OpenJDK site. As such, it is placed in the root directory of that bundle, which is why SRC_CLASSES is as it is. We have also been working on stopping the transitive compilation of the j2se source tree, and you should see those fixes soon. Your point about echo vs printf is well taken. Going forward, we will be focussing on the build.xml file for the compiler, in make/netbeans/compiler. -- Jon Dalibor Topic wrote: > hi, > > the attached fix is a small fixlet that lets me use the makefile again > for building javac. > > the patch does three things: > > * setting SRC_CLASSES to the relative path of the source directories, and > > * setting ECHO to printf, as that's more useful for posixy systems > (and avoids having the build fail due to a spurious -e in the > javac.srcfiles file when using bash 3.2.17), and > > * using BUILD_CLASSES as the location of properties on the classpath, > rather than SRC_CLASSES, to avoid wasting time rebuilding the > transitive closure of the class library used by javac (and adapting > the makefile to deal with things like native or generated classes in > that). > > cheers, > dalibor topic > ------------------------------------------------------------------------ > > Index: j2se/src/share/opensource/javac/Makefile > =================================================================== > --- j2se/src/share/opensource/javac/Makefile (revision 237) > +++ j2se/src/share/opensource/javac/Makefile (working copy) > @@ -34,7 +34,7 @@ > DIST_JAVAC = $(DIST) > ABS_DIST_JAVAC = $(shell cd $(DIST_JAVAC) ; pwd) > SRC_BIN = src/bin > -SRC_CLASSES = src/share/classes > +SRC_CLASSES = ../../../../../j2se/src/share/classes > > #-------------------------------------------------------------------------------- > # > @@ -70,7 +70,7 @@ > # Platform settings specific to Linux > ifeq ($(SYSTEM_UNAME), Linux) > # Intrinsic unix command, with backslash-escaped character interpretation > - ECHO = echo -e > + ECHO = printf "%s " > PLATFORM = linux > endif > > @@ -145,7 +145,7 @@ > $(MKDIR) -p $(BUILD_BOOTCLASSES) > $(JAVAC) -d $(BUILD_BOOTCLASSES) -source $(COMPILER_SOURCE_LEVEL) -g:source,lines @$(BUILD_JAVAC_SRCFILES) > $(MKDIR) -p $(BUILD_CLASSES) > - $(JAVA) -cp $(BUILD_BOOTCLASSES):$(SRC_CLASSES) com.sun.tools.javac.Main \ > + $(JAVA) -cp $(BUILD_BOOTCLASSES):$(BUILD_CLASSES) com.sun.tools.javac.Main \ > -d $(BUILD_CLASSES) -g:source,lines @$(BUILD_JAVAC_SRCFILES) > ( $(ECHO) "Main-Class: com.sun.tools.javac.Main" ; \ > $(ECHO) "Built-By: $$USER" ; \ > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20070531/475ca341/attachment.html From dmytro_sheyko at hotmail.com Thu May 31 07:54:09 2007 From: dmytro_sheyko at hotmail.com (Dmytro Sheyko) Date: Thu, 31 May 2007 17:54:09 +0300 Subject: Right direction? References: <22ec15240705260616me349d4bi6ba922fd3f05d44f@mail.gmail.com> <22ec15240705260619i3910eb21k319df4204895131e@mail.gmail.com> Message-ID: Could you send tests you use as well? PS Just curiosity: Is your experimental feature about http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6373386 (RFE: Method chaining for instance methods that return void )? ----- Original Message ----- From: "Matthias Ernst" To: Sent: Saturday, May 26, 2007 16:19 Subject: Fwd: Right direction? > Hi, > > I've created an experimental feature, namely cascading for void method > calls as described on my blog @ http://mernst.org/blog/rss.xml > (Firefox only :-( Patches at the end, too. > > I would be glad to hear some comments what you think about the patches > (not the semantics but the implementation) - did I miss something? A > hint how I would find out the receiver type for unqualified method > calls without duplicating the lookup strategy in Attr#visitApply would > be appreciated, too! > > > Thanks > Matthias From robilad at kaffe.org Thu May 31 13:07:20 2007 From: robilad at kaffe.org (Dalibor Topic) Date: Thu, 31 May 2007 22:07:20 +0200 Subject: small fix for makefile for building on linux In-Reply-To: <465F14DE.9060202@sun.com> References: <465B88B7.8050603@kaffe.org> <465F14DE.9060202@sun.com> Message-ID: <465F2AF8.7070306@kaffe.org> Jonathan Gibbons wrote: > Dalibor, > > Thank you for your suggestions. > thanks for the fast reply, Jonathan! > j2se/src/share/opensource/javac/Makefile is a file was used in the initial Subversion release of the compiler. It is still used in the source bundle available on the OpenJDK site. As such, it is placed in the root directory of that bundle, which is why SRC_CLASSES is as it is. We have also been working on stopping the transitive compilation of the j2se source tree, and you should see those fixes soon. > ok, looking forward to see them. I'm curious: did you chose to move the respective packages around to fit the build script, or did you use a method like the one I used for the makefile patch? > Going forward, we will be focussing on the build.xml file for the compiler, in make/netbeans/compiler. > cool. I'm going to autoconfiscate the compiler for my own needs, as I explained on my blog, so ... would you be interested in receiving a patch that provides a configure && make && make install build machinery for javac? I'll host it on a google code site, or something else, otherwise. I am trying to figure out where to diff from, and how to keep my set of build system & portability patches small wrt to the javac trunk. cheers, dalibor topic From ernst.matthias at gmail.com Thu May 31 14:28:38 2007 From: ernst.matthias at gmail.com (Matthias Ernst) Date: Thu, 31 May 2007 23:28:38 +0200 Subject: Right direction? In-Reply-To: References: <22ec15240705260616me349d4bi6ba922fd3f05d44f@mail.gmail.com> <22ec15240705260619i3910eb21k319df4204895131e@mail.gmail.com> Message-ID: <22ec15240705311428p4d6b6cd4x1f109376f14308cd@mail.gmail.com> Dmytro, I was not aware of this bug report but yes that is exactly what this is about. I don't have a formal test suite, the test I've used is attached. Matthias On 5/31/07, Dmytro Sheyko wrote: > Could you send tests you use as well? > > PS > Just curiosity: Is your experimental feature about > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6373386 (RFE: Method > chaining for instance methods that return void )? -------------- next part -------------- package test; public class CascadingTest { public static void main(String[] args) { System.out.println(new Sub().m().m2()).println("Yes"); } public void m() { new Runnable() { public void run() { CascadingTest.this.m3().m3(); } }.run(); } public void m3() { } } class Sub extends CascadingTest { public void m2() { CascadingTest p = super.m(); } } From egidijus.vaisnora at nomagic.com Thu May 31 23:09:53 2007 From: egidijus.vaisnora at nomagic.com (Egidijus Vaisnora) Date: Fri, 01 Jun 2007 09:09:53 +0300 Subject: AST Message-ID: <465FB831.5020901@nomagic.com> Hello, I am investigating JCTree with possibility to reuse it and faced some questions which maybe someone will help to resolve. I was not able to find, where Java documentation is mapped and seems any code comments is not mapped either. Is it any possibility to have them? Is any JCTree writer available? I just want to accomplish task - read code, modify, and write back. Thanx, -- Egidijus From brian at slesinsky.org Thu May 31 23:58:38 2007 From: brian at slesinsky.org (Brian Slesinsky) Date: Thu, 31 May 2007 23:58:38 -0700 Subject: AST In-Reply-To: <465FB831.5020901@nomagic.com> References: <465FB831.5020901@nomagic.com> Message-ID: <824b0d840705312358u2e86fb7ar5142459057dbad0@mail.gmail.com> I don't have the code in front of me, but javadoc is definitely in there. It's a bit obscure. For printing code, the javac.tree.Pretty class is a good place to start. It doesn't do a full job of it, but you can learn a lot about the parse tree by reading it. Some other projects you might find interesting: http://jackpot.netbeans.org/ http://spoon.gforge.inria.fr/Doc/FAQ - Brian On 5/31/07, Egidijus Vaisnora wrote: > Hello, > > I am investigating JCTree with possibility to reuse it and faced > some questions which maybe someone will help to resolve. > I was not able to find, where Java documentation is mapped and > seems any code comments is not mapped either. Is it any possibility to > have them? > Is any JCTree writer available? I just want to accomplish task - > read code, modify, and write back. > > Thanx, > -- > Egidijus > From egidijus.vaisnora at nomagiclt.com Thu May 31 23:03:03 2007 From: egidijus.vaisnora at nomagiclt.com (Egidijus Vaisnora) Date: Fri, 01 Jun 2007 09:03:03 +0300 Subject: AST Message-ID: <465FB697.4050107@nomagiclt.com> Hello, I am investigating JCTree with possibility to reuse it and faced some questions which maybe someone will help to resolve. I was not able to find, where Java documentation is mapped and seems any code comments is not mapped either. Is it any possibility to have them? Is any JCTree writer available? I just want to accomplish task - read code, modify, and write back. Thanx, -- Egidijus