Hello OC

I didnt have to change my file names to .groovy (I just use the compilation
unit to create my source unit closure (from a .java file and it works).
Additionally, there are a few reg ex updates I do to the code before adding
them to the source unit compilation mechanism. This lets me side step the
{} insde annotations problem, the return new line problem, the $ escaping
in a string and other details. This is easy to do, but stuff that needs
type inferencing will not work as well

regards
Saravanan

On Mon, Apr 7, 2025 at 6:59 PM OCsite <o...@ocs.cz> wrote:

> Jochen,
>
> On 7. 4. 2025, at 14:00, Jochen Theodorou <blackd...@gmx.org> wrote:
> I wonder though... why use Groovy to compile Java?
>
>
> My own use case was that I've turned big Java projects to Groovy; the only
> reasonable way I've found was
> 1. to rename all .java sources to .groovy
> 2. to fix things which did not compile at all (in my case luckily pretty
> small number of those)
> 3. incrementally re-write those parts of code which either did not work
> properly [*] or just needed an upgrade to pure and nice Groovy, whilst
> other parts of the same sources [**] did remain (and a little part still
> remains as of today) ugly semicolon- and boilerplate-ridden Java.
>
> [*] Incidentally, by the “return <newline> value” trick I've been bitten
> myself, too :) Long ago I did argue Groovy should have warnings like ObjC
> does — and one of them should happen in these cases when the last line of
> such an ambiguous code ends by a superfluous semicolon (which strongly
> hints it's a Java code), but well, you don't like warnings and thus don't
> have them :)
>
> [**] Since alas Java does not allow splitting big classes to more sources
> (and with Groovy it was complicated before traits, and when traits much
> later came, I could not embrace them, for they clash with my ASTTs), some
> sources were and still are indecently long :( I can't see how those jokers
> in Sun could be stupid enough to design a language without (something
> functionally equivalent to) ObjC categories, especially given Sun did work
> with NeXT on OpenStep, so they _did_ know how a decent and useable OO
> language looks like :(
>
> All the best,
> OC
>
>

Reply via email to