Hi! On 2022-11-30T23:18:06+1100, Zopolis0 via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: > However, patches 14-19 do need an explanation, as proven by multiple > reviews simply asking why I had made them. I'll send follow up > messages to those.
Well, (at least for some of them) re-work rather than explanations. ;-) Anyway: >> Why is it now considered useful to add this front end back? > > The way I see it, the Java front end was removed due to a lack of > maintenance and improvement. To put it simply, I am going to maintain > and improve it. That is the difference between now and then. There is > more nuance, but that is the gist of it. Ha, nice! As it happens, a few months ago, I started the same task... (... but with very low priority, so have not yet gotten very far...) >> How has the series been validated? > > I'm not exactly sure what you mean by this. Testing; the integrated GCC/Java test suites, as well as possibly any external test suites. To make sure that we're (a) not regressing anything in non-Java GCC, and (b) that we're maintaining the functionality level of the "old" GCC/Java. That said, I found that the integrated GCC/Java test suites are not exactly testing all that should be tested... My approach has been to establish an "old" baseline, and then gradually rebase this onto specific GCC master branch commits, and catch up with tree-wide changes along the way. I've not gotten all too far yet; made a stop to first add more testing to the baseline, so that I can be reasonably sure that GCC/Java doesn't regress in functionality. (It's been sitting in that state for a number of months now...) It may be a somewhat more painful approach in comparison to the "all in one go" approach that you seem to have attempted (?), but it seemed more appropriate for me, as I'm only able to spend occasional small blocks of time on this. >> Would you propose to maintain the front end and libraries in future? > > I have big plans for the library, and plan to maintain that long into > the future. In regards to the actual front-end code, I will do what I > can to make sure it remains at its previous level of function, but > that is about it. I dislike working with the front end code, so I will > fix it, but I will not make sweeping changes to it. I might thus be interested in joining that effort (I'm more interested in the front end and GCC proper parts) -- but, again, this will be low-priority project for me. Grüße Thomas > Just a brief overview of my plans for the frontend and library-- When > GCJ was first introduced it was "the free Java implementation". It was > trying to offer a bytecode compiler, a machine code compiler and a > runtime library. Clearly, this was too much, as it borrowed another > bytecode compiler and runtime library, and even then the runtime > library fell into dissaray. > > Now, we have many pieces of the puzzle. We have a bounty of free Java > bytecode compilers, and a free runtime library. The only thing missing > is a free machine code compiler, which GCJ was and is. I plan to > replace Classpath with the OpenJDK, and double down on the machine > code aspect of GCJ, dropping bytecode and interpreted support. ----------------- Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955
