Re: Java front-end and library patches.

[Zopolis0 <creatorsmithmdt@gmail.com>]

> * Each patch should have its own explanation of what it is doing and why,
> in the message body (not in an attachment).  Just the commit summary line
> and ChangeLog entries aren't enough, we need the actual substantive commit
> message explaining the patch.

The thing is, most of the patches do not need an explanation. Patches
1-13 are just re-adding code, 20-43 and 47 are just applying treewide
changes that Java missed out on, and patches 44-56 are either
incredibly simple or self-evident. If you feel like any of the listed
patches require an explanation, let me know and I will provide one,
but for now I dont see a reason to explain those.

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.

> 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.

> How has the series been validated?

I'm not exactly sure what you mean by 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.

>  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.