Disclaimer: this does not currently work. The front-end and library compile successfully, but fail to link at the very end. This is due to a regression caused by 1dedc12d186a110854537e1279b4e6c29f2df35a, which I have been unable to solve.
Nevertheless, I am posting this patch series for two reasons. Firstly, to get feedback and reviews on the 56 already existing patches, even though most are just re-adding code or making idiomatic changes, so that when the final issue is solved everything has already been approved (hopefully) and the merge is good to go. Secondly, to get assistance with the final issue, because it is simply beyond me, and history has shown that asking for help via gcc-patches will yield nothing. You'll need libtool 2.4.7 and a bleeding-edge version of bdwgc to build it, in case anyone planned to do some testing. Answers to the questions asked on my last patch series leading email: > 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. > Which version is the basis of the one being added back...? The exact same one that was removed from GCC, with the version taken being the one right before it was removed. > 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. > Would you re-open any bugs against the front end or libraries that were > closed...as a result of it being removed from the tree...? Good point, I hadn't thought of that. It makes sense to re-open them, as they are by definition valid again, although I may have difficulty with the frontend ones, as that is not my strong suit. 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.