71–80 of 239 posts
With efficient/safer languages like Golang and Rust getting track, I don't see a reason into trying to keep Java around.
I think java made some wrong decision, with bigggest one being very pragmatics generics-addition, resulting in trouble down the road like List not being possible. But I don't think checked exceptions are one of them ;) I don't like too much flexibility in a language that has strong types. If you undermine the type-system, why not code in python? But some additions of Lombok seem worthwile.
> I don't think checked exceptions are one of them While they may not have been the wrong decision, empirical evidence continually shows they add a syntactical burden many devs just work around (e.g. just wrap in a RuntimeException anyways). It's understandable why most modern languages don't consider predictable exceptions as part of the function signatures (though many discourage exceptions altogether in all but th…
Error conditions captured in the type system are a vital part of making code robust. The fact that some developers don't know how to properly handle these error cases doesn't change anything to the soundness of checked exceptions.
My main issue with Java is all the annotation based programming. Some of these are nice and can make the easy case super easy but if you need go even slightly off the easy path you seem to quickly loose all the time gained on the easy path. i.e. @GET(url=" http://host/users/$userid" ) public abstract User getUser(String userid) isn't that much easier than the python requests version but much harder if you need to add…
Yep. I love data classes for the simplicity and utility but pretty soon there are more annotations than java code. In Java I prefer Immutables over Lombok but once you add Jackson annotations, customize the Immutables generated code (@Value.Immutable, @Value.Parameter, etc), add some javax.validation (@NotNull, @NotEmpty) it gets very noisy very quickly. And yet it is still better than writing mutable bean classes by…
Lombok is a useful crutch if you're writing lots of Java code on a day to day basis. However, given how easy it is to use Kotlin alongside Java I would question whether Lombok is the right solution to the problem. Kotlin has data classes which auto generate sensible 'toString' and 'hashCode' methods which is a massive time saver. Really, if you are considering introducing Kotlin to a Java project I'd recommend you ju…
I think java made some wrong decision, with bigggest one being very pragmatics generics-addition, resulting in trouble down the road like List not being possible. But I don't think checked exceptions are one of them ;) I don't like too much flexibility in a language that has strong types. If you undermine the type-system, why not code in python? But some additions of Lombok seem worthwile.
Checked exceptions have often been presented as a mistake on the basis of the ergonomics and workflow problems they cause, not because they are unhelpful when implemented. The problem is that people don't want to break their flow to deal with them, so they don't deal with them by catching/throwing exceptions improperly. EDIT: There's also the fact that Java includes unchecked exceptions, so you can already subvert th…
"Forces API clients to catch exceptions you can't handle."
My observation is that obfuscation frameworks throw a bunch of checked exceptions which are unrecoverable. Which says more about the frameworks than the language.
Hibernate: RDBMS obfuscation framework
Spring: Flow of control obfuscation framework
JAXRS: Exception obfuscation framework
My main issue with Java is all the annotation based programming. Some of these are nice and can make the easy case super easy but if you need go even slightly off the easy path you seem to quickly loose all the time gained on the easy path. i.e. @GET(url=" http://host/users/$userid" ) public abstract User getUser(String userid) isn't that much easier than the python requests version but much harder if you need to add…
Yep. I love data classes for the simplicity and utility but pretty soon there are more annotations than java code. In Java I prefer Immutables over Lombok but once you add Jackson annotations, customize the Immutables generated code (@Value.Immutable, @Value.Parameter, etc), add some javax.validation (@NotNull, @NotEmpty) it gets very noisy very quickly. And yet it is still better than writing mutable bean classes by…
I use the elements of programming from SICP[1] as a litmus test for this kind of frameworks. The main issue with these annotation hacks is that they fail in the area of “means of combination” and “means of abstraction”. For example if you have: @X @Y class Something{} You cannot tell if X & Y can be combined (or how it’s combined), or you cannot easily create an abstraction Z with X and Y (you may be able to do that…
Makes clear and explicit the queasy feeling I get from over reliance on Java annotations.
Lisp macros, for example, fare much better in the "means of combination" and "means of abstraction" tests, I think.
Lombok is a useful crutch if you're writing lots of Java code on a day to day basis. However, given how easy it is to use Kotlin alongside Java I would question whether Lombok is the right solution to the problem. Kotlin has data classes which auto generate sensible 'toString' and 'hashCode' methods which is a massive time saver. Really, if you are considering introducing Kotlin to a Java project I'd recommend you ju…
I see Kotlin as a great choice for these who don't want Java verbosity but can't really get used to read Scala.
Java the language is cool. What the enterprise has done with it is not cool. Writing apps with layer upon layer upon layer upon layer of abstraction is ... self defeating. Then they'll holler, we need to rewrite it! All in the name of finding that one true architecture that can handle any business CR. Blech.
Those decisions were less to do with personal freedom or program simplicity, and more to do with the realities of large scale enterprise development. You end up having to adopt patterns that make individual programmers replaceable, and allow for a standardized pool of candidates with experience in $X framework. The reality is that most companies building Java software just need to be able to hire an average Java programmer to show up every day and manage their huge tangle of business logic.
Java the language is cool. What the enterprise has done with it is not cool. Writing apps with layer upon layer upon layer upon layer of abstraction is ... self defeating. Then they'll holler, we need to rewrite it! All in the name of finding that one true architecture that can handle any business CR. Blech.
How do you feel about Spring? I'm a fan of Java itself as well, but find myself conflicted whenever I use Spring/Boot. It's very nice when it works. But when the magic formula isn't recited correctly....you get frustrated and wind up visiting HN to forget about how unpleasant it is. ahem
XML bean configuration files. Annotations. Implicit code generation. Property and YAML files. Looking for files and resources in "default" locations. Executing code at runtime as the result of adding a dependency, without it ever being explicitly called anywhere.
The result is, you can never really predict what the hell your program is going to do when its running in production. Certainly not by carefully reading and inspecting the Java code you write.