Hi all,
I had a new idea I wanted to propose for this year's Google's Summer of
Code. I sent this to the Groovy mailing list first for an initial look, so
when you're done reading, you can check out the replies that have already
been sent here
<https://lists.apache.org/thread/95cbxgndhmptxbfobboljfn6yq98lry1>.
However, I wanted to share it with you all here too since the deadline is
coming up soon.
If you find this idea interesting at all, please consider mentoring! And
if you think this just sounds like a worse version of Groovy: it is! Check
out the replies on the Groovy thread to learn why that's actually *really
important* to have in the Java ecosystem.
Motivation:
If you're anything like me, you love Java.
I mean, how could you not: Java is unparalleled when it comes to
readability and structure and *power*. You can track data flow through a
program at a glance, there are a thousand easy-to-use and *intuitive*
libraries, and - as much as I love C++ - there aren't any ambiguous
operators, syntax that's only valid in one specific place, or random macro
usage in the main library functions. You know exactly what something does
just by looking at it, and that's *still* such a breath of fresh air even
in the modern programming space. These new languages try to be as concise
as possible for writing, but they sometimes forget that people have to
*read* the dang thing too, am I right?
But... Java can also be a bit *too* verbose at times, can't it? We only
recently got a concise syntax for POJOs in the form of Records, and they
come with their own set of stipulations that make using them somewhat
niche. And that's not to mention the continued waiting for destructuring
declarations, the getters and setters left floating around in the class,
the endless if-elseif trees checking the same value against different
things that make it so hard to track... There are a few areas of
improvement; let's say that.
Languages like Scala and Kotlin try to remedy this, but they end up with
their own problems like enforced programming models, completely overhauled
libraries that lose the intuitiveness of Java's, and just the overall
learning curve of being a *completely different language*. They *are*
incredibly powerful, but they lose the familiarity that comes with Java.
What we need is the ability to just... *add some stuff to Java*, without
making people learn a whole new language to use it.
So what if we did?
*Proposal: Add Some Stuff To Java*
Essentially, the plan is to make a set of syntactically-sugary-delicious
constructs that transpile to plain ol' Java 8, similar to how TypeScript's
advanced features still compile to ECMA2016.
The biggest thing is to make it as *approachable* as possible. When you
see a new language, you expect to have to learn how to translate your
thoughts to code all over again, so this is intentionally *not a language*,
just a small set of language *extensions*. By transpiling to Java source
code instead of compiling to bytecode, it also allows us to use the
first-class static analysis tools developed by for-profit companies like
Jetbrains without needing to write our own inevitably less-refined versions.
The core principles are *zero overhead* and *improved readability*; this
isn't remaking the wheel, or constructing overhauled libraries, this is
just adding shorthand for ubiquitous features that we wish we could have
saved time doing by hand. It's gotta feel like you're just using a version
of Java from the near future; no syntax weirdness, just more-concise
constructs so it's easier both to write *and* to read.
Things like:
- Getters and setters being *part of the variable declaration*, and
being called via the property name itself;
- If/else-if trees that check the same variable against different things
being allowed to be in the form of a `switchif` statement, similar to
Kotlin's switch statements;
- Python-style group imports with local renaming, so people can still
give their methods and classes descriptive names without being forced to
type the whole thing out *every single time* they want to use it;
- Kotlin-style `with` blocks for the convenience and readability of
"chaining" when chaining isn't an option;
- The `as` keyword so you aren't forced to relearn lisp every time you
want to cast something;
- Destructuring declarations using *annotations* instead of waiting for
pattern matching to come through;
- Operator overloading so we can do things like "accessing lists through
brackets" and "doing boolean algebra in a readable manner", again declared
using annotations so method names remain informative; and
- All syntactic sugar added since Java 8, now available for us living in
the past (and also most of the world, because they don't even *make* a
JRE for the latest version anymore) to use freely too.
This would be accomplished using a Gradle plugin as a preprocessor,
converting any of our JavaPlus constructs to their Java 8 counterparts and
then sending the new source off to javac to be compiled, eliminating the
need for brittle ASM invocations to hook into the compiler directly while
still having fairly low added runtime. For the most part, it would be
simple regex find-and-replace, avoiding any bytecode generation on purpose
so the end user can see exactly what their code is ending up as.
If possible, I'd like to also add the ability to apply the annotation-based
parts to preexisting libraries too, using what's essentially a ".d.ts" file
but for Java. This would allow the convenience factor for advanced users
without *requiring* it of newer ones, but it's likely out of scope for this
project.
To be honest, I'm just tired of having to track down my getters and
setters. If I can replace this:
> private String foo = "bar;
public String getFoo() {
>
return this.foo;
>
}
>
public void setFoo(String newVal) {
>
this.foo = newVal;
>
doOtherThing();
>
}
with this:
> String foo = "bar";
>
get() {
> return foo;
> }
>
set(newVal) {
> foo = newVal;
> doOtherThing();
> }
>
without having to leave my precious Java? And all it takes is banging my
head against some regex for 150 hours? That sounds like a fair trade to me.
I have a full plan formulated with a finalized process for every step, but
this is a "brief" overview of it. For the most part, I just *desperately*
need the input of people who are experienced with this area. Even if you
don't accept this for GSoC, I would still love to chat about it in the
future, because I think it will help Java be just a little bit better for
everyone.
So, what do you think? Does this sound like a good proposal idea? Let me
know your thoughts in the replies; I look forward to your feedback, and I
happily await this being torn apart by people more knowledgeable in the
field than I.
Thank you so much for your time,
Caleb Brandt
About Me:
I'm a hobbyist API developer and fixer of things: if I see something that
I'm able to resolve, I might as well help out. The biggest power of
programming is that if you solve a problem for yourself, you also solve it
for *every single person who will ever live*, which is why I admire
open-source consortiums such as you guys so greatly. You're everything I
wanted to be when I grew up, and I'm applying because you still represent
the hallmark of what good coding is to me: helping people do stuff more
easily, just because you *can*.
I'm a Junior at the University of Central Florida, finishing up my
Bachelor's degree in Computer Science. In my off-time, I make
compatibility mods for Minecraft: optimizing interactions between other
mods using Mixin (a framework for ASM), reflectively exposing APIs for
other developers, patching bugs, and anything else I can do to make the
ecosystem a bit better than how I found it. I also attempt to patch any
bugs I encounter in open-source software; I already spent the time tracking
it down, I might as well take one more step and fix it for *everyone* too.
