[RFC] Replace Java with Go in default languages

[Andrew Haley]

On 11/11/2013 09:27 PM, Matthias Klose wrote:
> Am 11.11.2013 11:06, schrieb Andrew Haley:
>> On 11/11/2013 03:22 AM, Jeff Law wrote:
>>> On 11/09/13 08:55, Andrew Haley wrote:
>>>> On 11/09/2013 03:44 PM, Alec Teal wrote:
>>>>> If Java must go, and it must have a replacement Ada makes sense. The
>>>>> issues with Go (sadly, you guys are doing superb work) do make sense.
>>>>>
>>>>> I don't know enough about Java (the GCC front end and such) to know if
>>>>> it should go, if it does go why should it be replaced?
>>>>
>>>> It always was very useful for detecting bugs in GCC: the code flow tends
>>>> to trigger bugs that don't get detected by the usual GCC testsuites.
>>> That's certaily been the case in the past, but I'm seeing less and less 
>>> of that now.  If we can get coverage of the non-call-exceptions paths 
>>> and cut 15% off the build/test cycle, then I think it's worth it.
>>>
>>> I'd even be willing to explicitly make this a trial and reinstate GCJ if 
>>> we find that GCJ is catching problems not caught by the existing default 
>>> language & runtime systems.
>>>
>>> Andrew -- my big question is what's the state of OpenJDK for other 
>>> architectures.  The most obvious being ARM(64), but in general, what's 
>>> the process for bootstrapping OpenJDK on a new target
>>
>> It's no different from porting GCC/libc.  You have to write an
>> assembler back end, the native parts of the runtime library, a
>> bytecode interpreter, relocs for the runtime linker, and the compiler
>> back end.  Call it two programmer-years to get something decent
>> working.
>>
>>> and is GCJ an integral part of that process.
>>
>> We have used GCJ in the past when porting OpenJDK because OpenJDK
>> wasn't cross-compilable, but that's fixed now: we can cross-compile
>> from a host which already has OpenJDK.  So we don't need GCJ for that.
> 
> that's only partly true. Sure, when using an unreleased OpenJDK snapshot
> (leading to OpenJDK 8), then you are probably correct, however doing that for a
> released version of OpenJDK, it is still needed.

Well, yes, but we're talking about legacy systems: for legacy OpenJDK you
need legacy GCJ.  There's no need for a new GCJ for porting new OpenJDK.

Andrew.