3 ms·

Java has had a nice focus on "decluttering" improvements lately; I think it's a nice focus to have (if done carefully), as 'verbosity' has always been one of th

Java has had a nice focus on "decluttering" improvements lately; I think it's a nice focus to have (if done carefully), as 'verbosity' has always been one of the supposed pain points of java. I would welcome this JEP in this light. I see this as great for developers already familiar with the language in making code more streamlined. But it's along a similar vein to, say, "anonymous classes can be expressed as lambdas which can in turn be expressed as method references". Or, say, the 'var' keyword as a way to automatically infer the variable type and how memory will be allocated for it, on the basis of the applied constructor. In both cases, the last step may be a nice, simple-looking expression, but it hides a lot of underlying complexity and context, which you need to understand properly to use it effectively. So the part I 'object' to in the wording of the JEP is the educational intent/strategy implied in the summary. For me there is a big difference between something like "introduce complex idea A at a higher level because simpler idea B depends on it", vs "obfuscate the true nature of A to pretend B can be understood in isolation, and deal with the resulting confusion later". Learning works by creating basic blocks of understanding, consolidating them, and then using them to build more complex blocks later on. Relying on a faulty foundation, hoping to come back and re-build it later on is generally not the best educational strategy (in my humble view). So from an educational point of view, for me this does not make my job simpler. If I wanted my students to build a solid foundation of understanding, I would have to first explain what classes are, what static methods are, how methods can NOT in fact live outside a class in java, and only THEN explain that "to make things less verbose, in this VERY specific case, java allows you some syntactic-sugar to hide some of that complexity under a simpler-looking syntax, that would otherwise look weird in standard java". But yes, having said all that, this seems like a nice proposal for the language more generally, that could lead to further similar improvements down the line, and I would be in favour of it! Great work!

pron 4y ago
> obfuscate the true nature of A to pretend B can be understood in isolation, and deal with the resulting confusion later What confusion? All the code in the body of an anonymous class is perfectly valid Java code that you can put in the body of an anonymous class today. There is no new magic here. > I would have to first explain what classes are, what static methods are, how methods can NOT in fact live outside a class in java, and only THEN explain that "to make things less verbose, in this VERY specific case, java allows you some syntactic-sugar to hide some of that complexity under a simpler-looking syntax, that would otherwise look weird in standard java". I don't think you would. There is no syntactic sugar here that Java doesn't already do. The body of an anonymous main class is valid as the body of an anonymous class today -- there is no special magic or any kind of special interpretation of code here -- and the notion of "implicitly supply an unnamed instance of a programming-in-the-large concept" is something Java already does today for packages and modules. Every method lives in a class, every class lives in a package, every package lives in a module. And yet, we don't require you to explicitly declare a package or a module. The current way we treat class declarations is the inconsistent one: it requires a class declaration even when it's not useful. Classes are no more fundamental to how Java "really" works under the covers than modules and class loaders. And yet, Java doesn't force you to learn these concepts before learning what a variable is or what a loop is. There is simply no way to know how Java really works without understanding modules. Modules are what gives actual meaning to access modifiers. Do you teach modules before loops today? Classes (and so static) and access modifiers really are completely meaningless before you have more than one class or more than one object, just as modules are meaningless until you have several of them. We are making Java more consistent in not an explicit invocation of a concept that is only meaningful once you add more context to it.
- tpoacher 4y ago
  > Every method lives in a class, every class lives in a package, every package lives in a module. And yet, we don't require you to explicitly declare a package or a module. The current way we treat class declarations is the inconsistent one: it requires a class declaration even when it's not useful. I hadn't thought it like that. Sure, that makes sense from that angle.

pron 4y ago

> obfuscate the true nature of A to pretend B can be understood in isolation, and deal with the resulting confusion later What confusion? All the code in the body of an anonymous class is perfectly valid Java code that you can put in the body of an anonymous class today. There is no new magic here. > I would have to first explain what classes are, what static methods are, how methods can NOT in fact live outside a class in java, and only THEN explain that "to make things less verbose, in this VERY specific case, java allows you some syntactic-sugar to hide some of that complexity under a simpler-looking syntax, that would otherwise look weird in standard java". I don't think you would. There is no syntactic sugar here that Java doesn't already do. The body of an anonymous main class is valid as the body of an anonymous class today -- there is no special magic or any kind of special interpretation of code here -- and the notion of "implicitly supply an unnamed instance of a programming-in-the-large concept" is something Java already does today for packages and modules. Every method lives in a class, every class lives in a package, every package lives in a module. And yet, we don't require you to explicitly declare a package or a module. The current way we treat class declarations is the inconsistent one: it requires a class declaration even when it's not useful. Classes are no more fundamental to how Java "really" works under the covers than modules and class loaders. And yet, Java doesn't force you to learn these concepts before learning what a variable is or what a loop is. There is simply no way to know how Java really works without understanding modules. Modules are what gives actual meaning to access modifiers. Do you teach modules before loops today? Classes (and so static) and access modifiers really are completely meaningless before you have more than one class or more than one object, just as modules are meaningless until you have several of them. We are making Java more consistent in not an explicit invocation of a concept that is only meaningful once you add more context to it.

tpoacher 4y ago
> Every method lives in a class, every class lives in a package, every package lives in a module. And yet, we don't require you to explicitly declare a package or a module. The current way we treat class declarations is the inconsistent one: it requires a class declaration even when it's not useful. I hadn't thought it like that. Sure, that makes sense from that angle.