Rating 26 years of Java changes
91–100 of 327 posts
Re: Rating 26 years of Java changes
#92Earlier quoted context omitted.
I'm quite surprised that he said asserts are not found in production code. Is that really so? I rarely write Java, but in C code we use asserts (in production code) all the time. It's not uncommon for functions to contain 2 or 3 asserts.
I very rarely see assertions in "real" Java code; I think the author is right - in fact the place I see them the most often is in unit tests where they've been used by mistake in place of an assertion library's methods! I don't know why they're not more popular.
Re: Rating 26 years of Java changes
#93Re: Rating 26 years of Java changes
#94Earlier quoted context omitted.
To me var is what makes modern java somewhat readable and more bearable. It was always a joke that it takes too long to write anything in java because of the excessive syntax repetitions and formalities. To me that joke is heavily based on a reality that modern Java is tackling with this quality of life features.
I get the attraction to var, but I, personally, don't use it, as I feel it makes the code harder to read. Simply, I like (mind, I'm 25 year Java guy so this is all routine to me) to know the types of the variables, the types of what things are returning. var x = func(); doesn't tell me anything. And, yes, I appreciate all comments about verbosity and code clutter and FactoryProxyBuilderImpl, etc. But, for me, not hav…
It does help when writing:
var x = new MyClass();
Because then you avoid repetition. Anyways, I don't ever use "var" to keep the code compatible with Java-8 style programming and easier on the eyes for the same reasons you mention.Re: Rating 26 years of Java changes
#95I'm sorry, please don't hate me (I'm tired and don't have anything better to do) https://files.catbox.moe/ge4el3.png
Re: Rating 26 years of Java changes
#96Definitely underrates the impact of annotations. I'm personally not a fan of the way annotations are used to implicitly wire together applications, but I have to admit the impact. Maybe 5/10 is fair in light of the wide range of positive and extremely negative ways annotations can be used. So many of these features were adopted after they were proven in other languages. You would expect that since Java took such a sl…
Absolutely. It seems that the author never touched Spring, for instance, or a dependency-injection framework of any kind. Annotations allow to do things in a completely different way, removing tons of boilerplate. I'd give annotations 9/10 at least. (And I lost the interest in the rest of the article, given such a level of familiarity with the subject matter.)
Re: Rating 26 years of Java changes
#97I don't know what to make of this list... Very strange reasoning and even stranger results: Streams 1/10?! Lambdas (maybe the biggest enhancement ever) a mere 4/10?! Sorry, but this is just bogus.
Really prefer to have more lines of code and understanding very clearly what each one is doing, than convoluting too many instructions on a single line.
Re: Rating 26 years of Java changes
#98I'm sorry, please don't hate me (I'm tired and don't have anything better to do) https://files.catbox.moe/ge4el3.png
Re: Rating 26 years of Java changes
#99That has got to be one of the most useful recent features. :-)
The pleasure of just copying and paste text in plain ASCII that looks as intended rather than a huge encoded mess of "\r\n"+ concatenations.
But ok, I'm just an ASCII art fan. ^_^
Re: Rating 26 years of Java changes
#100Definitely underrates the impact of annotations. I'm personally not a fan of the way annotations are used to implicitly wire together applications, but I have to admit the impact. Maybe 5/10 is fair in light of the wide range of positive and extremely negative ways annotations can be used. So many of these features were adopted after they were proven in other languages. You would expect that since Java took such a sl…
which is kinda horrifying - it means the framework designers didn't find the language powerful enough to express app logic, and hotglued their own custom arbitrary behavior on top of it. Clear language code should be endeavor to be readable/understandable when printed on a sheet of paper by anyone, acceptable code should be understandable by anyone who knows a bit about the technologies and has some IDE support. Garb…
no single language is ideally suited for every situation, it's not inherently a sign of failure that someone makes a DSL.
and since annotations are part of the language, this is still all "the language is flexible enough to build the framework [despite being wildly different than normal code]" so I don't think it even supports that part.