I'd hope Eta "just" focuses on compiling GHC's core (not Core) intermediate-representation STG (or C--) into Java bytecode: then, no need to forever catch up re-implementing the ever-evolving language extensions, plus this just gets you all the desugaring / Core-to-Core optimization/simplification roundtrips, custom rewrite-rules, type checking / verification etc pp from GHC. In fact no need for any great checks and verifications, "just" (probably highly intricate in the end) a series of code format transformations.. in theory ;) GHC's various intermediate representations are pretty brilliant and thus I think should be leveraged as much as possible when it comes to new compilation targets and transpilation. Fun fact, seems as of 2002 there was for a while an STG-to-JVM backend.

Now there's issues with this approach too! You'd end up with a massively convoluted set of mappings of Haskell's factory defaults to the JVM's. We're talking the equivalents of `Prelude` module, `base` package, the RTS (garbage collector and much more.. ouch!), and for each and every individual instance deciding where to draw the line between Java's built-ins' semantics and GHC's would be a massive challenge.

What's with GHC's existing LLVM backend, does LLVM not have their own Java byte-code backend(s)? (OTOH, additional major dependencies always kinda bite..)