Hi Caleb,
literally what OC wrote.
Groovy has many hats, and the one you seem to know (and it seems dread)
is it being used to create a non-static DSL for Gradle.
The other two hats are Groovy being used as a script language, and - and
this is the one you should have a closer look at - being used as a full
blown, nearly 100% Java compatible programming language.
What OC writes below is true, Groovy is - by ongoing design, which many
discussions on this mailing list on how to integrate new Java/JVM
features into Groovy attest to - a drop in replacement for Java, aiming
to make Java more Groovy.
When someone finds a Java sample code snippet on the internet, all he
needs to do use it in Groovy is to copy & paste it into his project, and
do a regex search & replace of \s*;\s*$ w an empty string to remove the
redundant semicolons at the end of each line.
Also, while e.g. IntelliJ Support for Groovy is not perfect or
completely bug free, it is still very good, and it does not have the
problems you describe in your last posts: e.g. jumping to definitions of
classes/methods works, even when using standard (= dynamic) Groovy (i.e.
not @CompileStatic/@TypeChecked annotated).
While all JVM languages stand in the long shadow of Java, Groovy is the
second largest of them by many metrics, and support for it is
accordingly high.
(Your trans-compiled Java+ would face problems with IDEs, btw, since no
IDE will understand your extensions, and will therfore only support
Intellisense with regards to the transcompile pure Java code, not Java+.)
But most importantly: You would loose so many great Groovy features,
such as:
1. The multitude of ways to define string constants (multiline,
regex-friendly, etc).
2. Strings with embedded variables (which can even be closures), i.e.
GString|s.
3. The multitude of useful annotations, such as @InheritConstructors,
@Canonical, etc.
4. Newer Groovy convenience features such as e.g.
SV(myLongVariableName), which auto-expands to the GString
"myLongVariableName=$myLongVariableName", which is very useful for
debug logging.
1. (and which is made possible by the underlying Groovy's macro
feature)
5. The clever Closure syntax which allows to pass the last argument of
a method outside of the paramter enclosing brackets if that
parameter is a closure, which allows for the creation of extremely
elegant AND readable APIs.
1. we use e.g. database.withTransaction { /* SQL that shall be
executed within a database transaction bracket */ } for our own
SQL code as well as for Ebean.
2. or database.eachRow(sql) { row -> ... } for code that shall be
applied to each row in a result set.
6. and so forth.
7. all of which have Intellisense support in e.g. IntelliJ.
Getting people to try a different language is a matter of ease of
transition (which Java to Groovy definitely has in troves over any
alternative), as well as enticing new features - it is not about fooling
people into believing that they are still using Java, it is about them
realizing how many cool treasures lie on the other side of the fence,
and no language can make that easier with regards to Java than Groovy G-)
Cheers,
mg
On 25/03/2024 16:34, OCsite wrote:
The vast advantage of Groovy is that you can take a big project, just
rename all *.java to *.groovy, and it will essentially work (well, as
someone already wrote, 99 % — my experience is rather 99.99 %, but
indeed there are things which need fixing and there are a couple of
gotchas, but there's really a very very small number of them). Then
you can work on with the project and gradually change the stupid Java
patterns to the pretty decent Groovy ones, part by part, method by
method and if need be, practically line by line, without losing any
functionality during the process. No other language I know of allows
anything like this.