My personal opinion on it is that Java's simply a bad first language, and over-taught in schools. It has a lot of language-specific baggage that it thrusts upon you immediately on first use. My preferred first (university-level) language is Racket, because it's got incredibly simple syntax as a LISP, it's radically batteries-included giving a good sandbox to play in, and segues into CS-theory type stuff pretty damn well. It also has the added bonus of minimizing the impact on the subset of the class with non-trivial programming experience, who otherwise can easily get bored hearing stuff they know already, stop paying attention because they assume they know everything already, and then wash out when the real CS-heavy stuff hits.
But a lot of "universities" treat their "CS" programs as glorified trade schools, and want to focus exclusively on industry-applicable languages, and land on Java because Oracle had a great outreach program. Like it or not, many students will be starting their programming journey in Java, and not fucking it up is probably a good idea.
My approach would have been pretty similar to their listed alternative under "Interpret code units as static members", but that probably comes down to differences over the importance of Object-Oriented principals in beginner programming pedagogy.
Barring that, this proposal really isn't bad. It doesn't break existing code, it does its job well enough. I would have liked there to be support for inline subclasses that can be called from within the same anonymous class environment, but I can see how that would create ambiguity with existing code.
I think Java is a fine first language - it has a strongly typed, static runtime with good cross platform support, and stellar backwards compatibility (meaning that you can use decade old code samples as well).
The often touted alternative starting language is C and python, and I believe Java is better than both — C’s mentioned advantage is “learning low level details”, but I don’t see it as necessary, plus C can fail at runtime (or worse, at *some runtime on someone else’s machine) in completely cryptic ways, you may not even realize your program is incorrect until you submit an assignment. I have seen even very smart students be puzzled by it. Also, pointers can be learned afterwards easily, I don’t see it problematic at all.
Python’s problem comes mostly from its dynamically typed nature, it is very hard for new programmers to reason about the runtime state of programs, and why might have it failed on the nth cycle of this loop.
Java is a great in-between. It is not perfect (for example arrays having special syntax is not ideal), but not bad and it being an industry language is just a plus.
> I would have liked there to be support for inline subclasses that can be called from within the same anonymous class environment, but I can see how that would create ambiguity with existing code.
Not sure what you mean by "inline subclasses", but an anonymous main class can contain class declarations -- just as classes, named or anonymous can today. This file would be a complete legal program:
record Foo(int x, int y) {}
class Bar { static void print(Foo f) { System.out.println(f); } }
void main() {
Bar.print(makeFoo());
}
Foo makeFoo() { return new Foo(3, 4); }
Ah, in that case I take that back. I definitely thought you needed to be able to reference the parent class in order to call (classes defined within other classes, can't remember the nomenclature).
There's no need to do that from within the class. It all works just as it would in an anonymous class today. This code, that employs an anonymous class, is valid Java today (you can paste it into jshell):
new Object() {
record Foo(int x, int y) {}
class Bar { static void print(Foo f) { System.out.println(f); } }
void main() {
Bar.print(makeFoo());
}
Foo makeFoo() { return new Foo(3, 4); }
}.main();
This JEP merely brings together two existing ideas in Java:
1. Anonymous classes
2. Unnamed instances of programming-in-the-large concepts are implicitly provided for you (today this is the case only for packages and modules).
There are no new changes or restrictions to Java syntax in the body of the anonymous class.
But a lot of "universities" treat their "CS" programs as glorified trade schools, and want to focus exclusively on industry-applicable languages, and land on Java because Oracle had a great outreach program. Like it or not, many students will be starting their programming journey in Java, and not fucking it up is probably a good idea.
My approach would have been pretty similar to their listed alternative under "Interpret code units as static members", but that probably comes down to differences over the importance of Object-Oriented principals in beginner programming pedagogy.
Barring that, this proposal really isn't bad. It doesn't break existing code, it does its job well enough. I would have liked there to be support for inline subclasses that can be called from within the same anonymous class environment, but I can see how that would create ambiguity with existing code.