Re: ASM and gnu.bytecode
Mark We must make sure to properly document the way someone can grab Mark the upstream sources in case we want to pull in bug fixes later. Tom I'll handle this as part of the import. I've got the import working here. I'm going to wait for 0.93 to branch before committing it. Meanwhile, if someone wants it, I can mail the patch and the new sources. The patch also fixes a buglet I noticed -- we put the tool resources into glibj.zip, but not tools.zip. I think it makes sense to put them in the latter as well; it makes tools.zip more self-contained. Tom
Re: ASM and gnu.bytecode
RMS wrote: That license is GPL-compatible, so it is ok to use the code and ok to import it as a package that is not part of GCC but distributed with it. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Re: ASM and gnu.bytecode
Hi Tom, On Tue, 2006-11-28 at 15:42 -0700, Tom Tromey wrote: Tom Ideally we could just import the ASM sources. I thought this idea was Tom rejected, but I can't find a link. I'd like to revisit this, since Tom this is the simplest way to solve the problem. And unfortunately it seems upstream recommends this since they don't promise a stable api. sigh. The code is available from asm.objectweb.org. The license is here: http://asm.objectweb.org/license.html That looks good. I would import whatever version currently works. Later we could import newer versions, as desired, and update our code to match. What is the exact version that works with all our tools atm? I like to go over the sources once and send a report about it to the fsf licensing team so they can OK it for external inclusion (I don't foresee any issues, since it looks like a fairly stable [except for the api...] project with a known upstream). I'd import the code into classpath/tools/external (a new directory created for this purpose) and update the build scripts to match. I wouldn't rename the classes or anything like that. I would just import them using their upstream names. This is ok, I think, because the resulting classes would only end up in tools.zip -- not in glibj.zip. Users setting CLASSPATH could still have problems, but this doesn't seem like a major issue. That means we would be exactly the same as upstream so we can easily update if necessary and it won't 'pollute' the bootclasspath package space which is good. Thanks, Mark signature.asc Description: This is a digitally signed message part
Re: ASM and gnu.bytecode
Mark Wielaard writes: Hi Tom, On Tue, 2006-11-28 at 15:42 -0700, Tom Tromey wrote: Tom Ideally we could just import the ASM sources. I thought this idea was Tom rejected, but I can't find a link. I'd like to revisit this, since Tom this is the simplest way to solve the problem. And unfortunately it seems upstream recommends this since they don't promise a stable api. sigh. The code is available from asm.objectweb.org. The license is here: http://asm.objectweb.org/license.html That looks good. I would import whatever version currently works. Later we could import newer versions, as desired, and update our code to match. What is the exact version that works with all our tools atm? Manifest-Version: 1.0 Ant-Version: Apache Ant 1.6.2 Created-By: 1.5.0_04-b05 (Sun Microsystems Inc.) Implementation-Title: ASM all classes Implementation-Version: 2.2.3 Implementation-Vendor: France Telecom RD Andrew.
Re: ASM and gnu.bytecode
Hi Andrew, On Wed, 2006-11-29 at 10:50 +, Andrew Haley wrote: I would import whatever version currently works. Later we could import newer versions, as desired, and update our code to match. What is the exact version that works with all our tools atm? Implementation-Title: ASM all classes Implementation-Version: 2.2.3 Thanks. I cannot find that as a source download. But it seems they have at least tagged their CVS with ASM_2_2_3 so we could pull the code from there. We must make sure to properly document the way someone can grab the upstream sources in case we want to pull in bug fixes later. Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: ASM and gnu.bytecode
Mark Wielaard writes: Hi Andrew, On Wed, 2006-11-29 at 10:50 +, Andrew Haley wrote: I would import whatever version currently works. Later we could import newer versions, as desired, and update our code to match. What is the exact version that works with all our tools atm? Implementation-Title: ASM all classes Implementation-Version: 2.2.3 Thanks. I cannot find that as a source download. Sigh. Normal practice. But it seems they have at least tagged their CVS with ASM_2_2_3 so we could pull the code from there. We must make sure to properly document the way someone can grab the upstream sources in case we want to pull in bug fixes later. Yep. Andrew.
Re: ASM and gnu.bytecode
Mark == Mark Wielaard [EMAIL PROTECTED] writes: Mark Thanks. I cannot find that as a source download. But it seems they have Mark at least tagged their CVS with ASM_2_2_3 so we could pull the code from Mark there. Updating to the latest release would also be an option for us. Moving our code from using 2.2.3 to using 3.0 or whatever probably would not be overly hard. Mark We must make sure to properly document the way someone can grab Mark the upstream sources in case we want to pull in bug fixes later. I'll handle this as part of the import. Tom
Re: ASM and gnu.bytecode
Andrew == Andrew Haley [EMAIL PROTECTED] writes: Andrew Having gcj depend not only on ASM but also on a *specific version* of Andrew ASM is intolerable. If gnu.bytecode will do the job, we should use Andrew it. I suppose it would be best to import some bytecode library source into Classpath's tools subdirectory. Then we'd be insulated from upstream changes. Yay static linking! Ideally we could just import the ASM sources. I thought this idea was rejected, but I can't find a link. I'd like to revisit this, since this is the simplest way to solve the problem. It would also be easy to just put the right asm.jar on an ftp site somewhere, and have a script to download it. I already checked in a similar script (to gcc svn) to make it easy for GCC developers to get ecj. Failing that we can import GNU Bytecode and switch to that. FWIW the only reason this is my last choice is the amount of work involved. Tom
Re: ASM and gnu.bytecode
Tom Tromey writes: Andrew == Andrew Haley [EMAIL PROTECTED] writes: Andrew Having gcj depend not only on ASM but also on a *specific version* of Andrew ASM is intolerable. If gnu.bytecode will do the job, we should use Andrew it. I suppose it would be best to import some bytecode library source into Classpath's tools subdirectory. Then we'd be insulated from upstream changes. Yay static linking! Ideally we could just import the ASM sources. I thought this idea was rejected, but I can't find a link. I'd like to revisit this, since this is the simplest way to solve the problem. It would also be easy to just put the right asm.jar on an ftp site somewhere, and have a script to download it. I already checked in a similar script (to gcc svn) to make it easy for GCC developers to get ecj. Failing that we can import GNU Bytecode and switch to that. FWIW the only reason this is my last choice is the amount of work involved. One thing that occurred to me today: we could use class loader magic to detect the version of ASM and then do the Right Thing. Eww... Andrew.
Re: ASM and gnu.bytecode
Andrew Haley wrote: Tom Tromey writes: Andrew == Andrew Haley [EMAIL PROTECTED] writes: Andrew Having gcj depend not only on ASM but also on a *specific version* of Andrew ASM is intolerable. If gnu.bytecode will do the job, we should use Andrew it. I suppose it would be best to import some bytecode library source into Classpath's tools subdirectory. Then we'd be insulated from upstream changes. Yay static linking! Ideally we could just import the ASM sources. I thought this idea was rejected, but I can't find a link. I'd like to revisit this, since this is the simplest way to solve the problem. It would also be easy to just put the right asm.jar on an ftp site somewhere, and have a script to download it. I already checked in a similar script (to gcc svn) to make it easy for GCC developers to get ecj. Failing that we can import GNU Bytecode and switch to that. FWIW the only reason this is my last choice is the amount of work involved. One thing that occurred to me today: we could use class loader magic to detect the version of ASM and then do the Right Thing. Eww... Andrew I've got an import of ASM in Kaffe, conveniently named asm153 to match the version of asm required by the then version of what needed it, without causing potential trouble on the $CLASSPATH as such things tend to do. So, importing ASM would be fine for me. cheers, dalibor topic
Re: ASM and gnu.bytecode
Mark asked me to send some more info about this: Tom Ideally we could just import the ASM sources. I thought this idea was Tom rejected, but I can't find a link. I'd like to revisit this, since Tom this is the simplest way to solve the problem. The code is available from asm.objectweb.org. The license is here: http://asm.objectweb.org/license.html I would import whatever version currently works. Later we could import newer versions, as desired, and update our code to match. I'd import the code into classpath/tools/external (a new directory created for this purpose) and update the build scripts to match. I wouldn't rename the classes or anything like that. I would just import them using their upstream names. This is ok, I think, because the resulting classes would only end up in tools.zip -- not in glibj.zip. Users setting CLASSPATH could still have problems, but this doesn't seem like a major issue. Tom
Re: ASM and gnu.bytecode
Only part of RMIC (direct bytecode generation) is really dependent from ASM. That part which supports the source code generation is not dependent, was a separate compiler in the past and can be easily separated apart again. If we do not like ASM, this should make using the alternative replacement easier, as only the bytecode generating part needs to be rewritten. The classes being generated are also relatively simple. Audrius.
Re: ASM and gnu.bytecode
I recently tried to build Classpath and discovered that to build gjavah and grmic, ASM is required. No problem, thought I, and downloaded the latest version. Oddly, that didn't work. So, I downloaded a few more versions of ASM until I found a version that did work: version 2.3. This looked very odd to me, as I would have expected such a utility library to be backwards compatible. But no, it isn't, and there have been discussions about this on the ASM mailing list. To summarize, they have no intention of providing a stable API, ever. Their response when someone points out that they have conflicting requirements for different versions of ASM in the same application, is Tools and frameworks that are using ASM for bytecode processing (e.g. Hibernate, CGLIB, AspectWerkz) should repackage ASM code within their own name space. This can be automated with Jar Jar Links tool. We don't want to package an ASM binary file within Classpath. I imagine we don't want our own copy of the binary either. gcj Version 4.3 will require gjavah, so I want to find a clean solution for this problem. I suggest that we give up on ASM and move to a bytecode manipulation library whose public API isn't going to incompatibly change with every release. I imagine that gnu.bytecode would be a good choice, but am open to other suggestions. Perhaps gnu.bytecode could be part of Classpath. Audrius Meskauskas writes: Only part of RMIC (direct bytecode generation) is really dependent from ASM. That part which supports the source code generation is not dependent, was a separate compiler in the past and can be easily separated apart again. If we do not like ASM, this should make using the alternative replacement easier, as only the bytecode generating part needs to be rewritten. The classes being generated are also relatively simple. OK, that's good. So, my main problem is to free gjavah from ASM. I'll have a look at what might be required. Per, if you're listening: may we incorporate gnu.bytecode within classpath? It surely makes more sense there than as part of Kawa. Andrew.
Re: ASM and gnu.bytecode
Audrius Meskauskas wrote: Only part of RMIC (direct bytecode generation) is really dependent from ASM. That part which supports the source code generation is not dependent, was a separate compiler in the past and can be easily separated apart again. If we do not like ASM, this should make using the alternative replacement easier, as only the bytecode generating part needs to be rewritten. The classes being generated are also relatively simple. The direct bytecode generation is needed for performance and compatibility reasons. If ASM is replaced with gnu.bytecode, then the direct bytecode generation RMIC should be ported rather than removed. FWIW, porting from ASM 1.x to ASM 2.x was not very involved, and the update from 2.x to 3.x was even more trivial: http://lists.gnu.org/archive/html/cp-tools-discuss/2006-03/msg0.html I'm not sure trivial porting work between versions warrants an all-out replacement. Tom
Re: ASM and gnu.bytecode
Andrew Haley wrote: Per, if you're listening: may we incorporate gnu.bytecode within classpath? Absolutely. Might as well get the most recent version from svn: http://www.gnu.org/software/kawa/Getting-Kawa.html However, Tom does have a point that sticking with ASM is probably easier. Kawa probably does make it easier to generate quality code for a compiler (and can do it very fast), but I doubt you'd get much gain using it for rmic, especially since the ASM version more-or-less works. Here is an article I wrote on using gnu.bytecode: http://per.bothner.com/compiling-regexps.html It surely makes more sense there than as part of Kawa. Huh? Kawa needs gnu.bytecode amd can't assume Classpath - at least not yet! -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Re: ASM and gnu.bytecode
Thomas Fitzsimmons writes: Audrius Meskauskas wrote: Only part of RMIC (direct bytecode generation) is really dependent from ASM. That part which supports the source code generation is not dependent, was a separate compiler in the past and can be easily separated apart again. If we do not like ASM, this should make using the alternative replacement easier, as only the bytecode generating part needs to be rewritten. The classes being generated are also relatively simple. The direct bytecode generation is needed for performance and compatibility reasons. If ASM is replaced with gnu.bytecode, then the direct bytecode generation RMIC should be ported rather than removed. FWIW, porting from ASM 1.x to ASM 2.x was not very involved, and the update from 2.x to 3.x was even more trivial: http://lists.gnu.org/archive/html/cp-tools-discuss/2006-03/msg0.html I'm not sure trivial porting work between versions warrants an all-out replacement. Sure it does. At the present time, gcj is mostly self-contained, but we're soon to be adding a new dependency: ecj. We also need gjavah to work, and at the moment that needs ASM. That's one more external dependency for gcj, and one with an unstable API. Having gcj depend not only on ASM but also on a *specific version* of ASM is intolerable. If gnu.bytecode will do the job, we should use it. Andrew.
Re: ASM and gnu.bytecode
Andrew Haley wrote: Having gcj depend not only on ASM but also on a *specific version* of ASM is intolerable. If gnu.bytecode will do the job, we should use it. While gnu.bytecode (along with gnu.math) has been fairly stable for quite a while, and it probably has been the most stable part of Kawa, I have not guaranteed backward compatibility in the past. Of course if other projects start depending on gnu.bytecode, I'll try to not break things! One bonus of using gnu.bytecode: the class gnu.bytecode.dump is a direct clone on jcf-dump. (However, it doesn't have all the features of jcf-dump, and jcf-dump is fast and compact.) -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
