Can someone explain why developers like var?
It‘s a harmful code smell: It often obfuscates the type, forcing you to actively check for the type and should not be used.
Your IDE can do that?
Rating 26 years of Java changes
41–50 of 327 posts
Re: Rating 26 years of Java changes
#42Can someone explain why developers like var?
Previously (or if you simply don't use var), a lot of java code takes the form of
BeanFactoryBuilder builder = new BeanFactoryBuilder(...);
Re: Rating 26 years of Java changes
#43java.util.Date and java.util.Calendar are the two packages I remember struggling with as a new programmer. Which I guess is solved with java.time after Java 8.
Re: Rating 26 years of Java changes
#44I haven't written much Java but I am learning Kotlin and I really appreciate the language and the whole JVM ecosystem. Yeah yeah, Gradle is complicated but it's waaaaay easier to figure out than my adventures with Cmake, and when I read Java code there is a certain comfort I feel that I don't get with other languages, even ones I'm experienced with like Go. Java feels a bit like a stranger I've known my whole life, same with Kotlin. Perhaps despite all its flaws, there is a certain intrinsic quality to Java that has helped make it so popular.
Re: Rating 26 years of Java changes
#45Definitely 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…
I don't really feel that Java uses proven features.
For example they used checked exceptions. Those definitely do not seem like proven feature. C++ has unchecked exceptions. Almost every other popular language has unchecked exceptions. Java went with checked exceptions and nowadays they are almost universally ignored by developers. I'd say that's a total failure.
Streams another good example. Making functional API for collections is pretty trivial. But they decided to design streams for some kind of very easy parallelisation. This led to extremely complicated implementation, absurdly complicated. And I've yet to encounter a single use-case for this feature. So for very rare feature they complicated the design immensely.
Modules... LoL.
We will see how green threads will work. Most languages adopt much simpler async/await approach. Very few languages implement green threads.
Re: Rating 26 years of Java changes
#46Definitely 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…
I used to joke that the direction spring was heading was that you’d have an application be a boilerplate main method with a dozen lines of annotations. Then I actually encountered this in the wild: we had an app that sent updates from db2 to rabbitmq, and the application literally was just configuration via annotations and no actual Java code other than the usual spring main method.
this is exactly why spring succeeded. I need to run a scheduled job, @EnableScheduling then @Scheduled(cron = “xxxxxx”) - done. I need XYZ, @EnableXYZ the @XYZ… sh*t just works…
Re: Rating 26 years of Java changes
#47Definitely 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…
I used to joke that the direction spring was heading was that you’d have an application be a boilerplate main method with a dozen lines of annotations. Then I actually encountered this in the wild: we had an app that sent updates from db2 to rabbitmq, and the application literally was just configuration via annotations and no actual Java code other than the usual spring main method.
Is that strictly bad, though? Being able to run an enterprise service by setting configuration values declaratively, and get all the guarantees of a well-tested framework, seems like a pretty good thing.
Yes, it’s weird how that’s still Java, but using standard components and only using code as glue where it’s absolutely necessary seems very similar to other engineering disciplines to me.
Re: Rating 26 years of Java changes
#48Re: Rating 26 years of Java changes
#49Can someone explain why developers like var?
It's called type inference and it's the way things should be. You get the same types but you don't have to spell them out everywhere. Java doesn't even go all the way, check OCaml to see full program inference.
OCaml's type inference is truly amazing, makes it such a delight to write statically typed code - reading it on the other hand...
But I think that's easily solved by adding type annotations for the return type of methods - annotating almost anything else is mostly just clutter imo.
Re: Rating 26 years of Java changes
#50I think the author is sleeping on Java assertions. I really like the feature, and it's really one of the features I feel Java got right. The syntax is very expressive, and they can easily be made to generate meaningful exceptions when they fail. It's also neat that it gives the language a canonical way of adding invariant checks that can be removed in production but run in tests or during testing or debugging (with -…
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.