This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Reconsidering gcjx
- From: Tom Tromey <tromey at redhat dot com>
- To: Joe Buck <Joe dot Buck at synopsys dot COM>
- Cc: GCJ Hackers <java at gcc dot gnu dot org>, GCC Mailing List <gcc at gcc dot gnu dot org>
- Date: 27 Jan 2006 13:37:36 -0700
- Subject: Re: Reconsidering gcjx
- References: <m3d5iewn0r.fsf@localhost.localdomain> <20060127165714.GD23212@synopsys.com>
- Reply-to: tromey at redhat dot com
>>>>> "Joe" == Joe Buck <Joe.Buck@synopsys.COM> writes:
Joe> But before fighting the political battles, we should first figure out if
Joe> this is what we really want to do if there weren't political obstacles.
Joe> Let's try coming to a technical consensus first.
I made a list of things which would have to be addressed, based
mostly on this thread.
- Make ecj emit .jar files
- Change ecj's error reporting format
Right now it is quite ugly and doesn't conform to GNU standards.
- Consider putting column numbers in debug info
Though as far as I know, nothing uses this today, so I think this
is low priority.
- Check compile time performance.
We don't want to slow gcj down too much.
- Make bootstrapping simpler.
Some small library refactorings would make it quite simple,
amounting to downloading a single jar file.
- Exception regions as mentioned by Andrew.
I'm not sure what we need to do here.
- Fix variable slot tracking for bytecode
I don't recall exactly what the problem here was.
These last two are already present in today's compiler, though
switching to ecj would exacerbate the situation.
Tom