Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Better Java – Resources for Writing Modern Java

github.com

Post reply on HN
Print view View original

111–120 of 192 posts

Re: Better Java – Resources for Writing Modern Java

#111

Post by lomnakkus »

mindcrime wrote: post #100

One thing I'd add, is that Java is very amenable to static code analysis, and there are good tools like PMD and FindBugs for Java. I always encourage teams using Java to use one or both. The biggest downside is that you usually have to tweak the rule-sets to avoid getting lots of false positives. And if you get too many false positives then people tend to stop paying attention to the notifications from the tool. On a…

> [...] Java is very amenable to static code analysis [...]. The biggest downside is that you usually have to tweak the rule-sets to avoid getting lots of false positives.

These two statements seem to be in opposition to each other.

(All your advice is spot on. If you let warnings remain in code, you'll just end up accumulating more and more warnings until it's too much to fix. I guess it's a sort of "broken windows" effect.)

Re: Better Java – Resources for Writing Modern Java

#112

Post by owlish »

chii wrote: post #99
owlish wrote: post #64

I used to be a fan of the Builder pattern (or Fluent Interface), but the ease of use for developers comes at the cost of no compile-time checking. Before, you just had to look up the constructor to see which parameters go where, with the benefit of type-checking. Now, you have to look up the Builder's methods to make sure you've filled in all required fields. The only case where I can actually advocate using Builders…

> Now, you have to look up the Builder's methods to make sure you've filled in all required fields. the builder should fail with a good error message if there are required fields you didn't supply to the builder.

This doesn't solve the problem where the parameters aren't checked at compile-time. Now, hopefully all your codepaths are tested so your builder doesn't throw exceptions in production.

Re: Better Java – Resources for Writing Modern Java

#113

Post by asveikau »

harryh wrote: post #39
kodablah wrote: post #3

"If you're using Java 8, you can use the excellent new Optional type. If a value may or may not be present, wrap it in an Optional class like this" While I agree with most things, overuse of Optional like this is an antipattern IMO. Having done a lot of Java 8 development, I find Optional is best for return types, but otherwise forcing callers to wrap values in Optional is unnecessary as opposed to something like Sca…

Keep in mind that Tony Hoare, the inventor of the null pointer, calls this invention his billion dollar mistake. I generally think that he is right and use of null should almost always be avoided.

By all means, have more clumsy, less straightforward ways to represent the lack of a value in your code, because Tony Hoare says so.

Re: Better Java – Resources for Writing Modern Java

#114

Post by [deleted] »

harryh wrote: post #39
kodablah wrote: post #3

"If you're using Java 8, you can use the excellent new Optional type. If a value may or may not be present, wrap it in an Optional class like this" While I agree with most things, overuse of Optional like this is an antipattern IMO. Having done a lot of Java 8 development, I find Optional is best for return types, but otherwise forcing callers to wrap values in Optional is unnecessary as opposed to something like Sca…

Keep in mind that Tony Hoare, the inventor of the null pointer, calls this invention his billion dollar mistake. I generally think that he is right and use of null should almost always be avoided.

[deleted]

Re: Better Java – Resources for Writing Modern Java

#115

Post by rcurry »

nobleach wrote: post #46
agumonkey wrote: post #43

Earlier quoted context omitted.

Mentioning Scala, or clojure or even Haskell to a HR interview leads to raised eyebrows at best. But that was expected. I'm surprised actual devs are still wearing eye blinders.

I'm hiring front end JavaScript developers right now. If I see other language experience on their resume, they're getting a call. My last hire had worked through "Learn You A Haskell" and that was enough for my interest to be piqued. Seeing Python, Ruby, C, ObjectiveC, heck even PHP is enough for me to see they're not just a "I did some Angular tutorials" type of candidate. I'm on this site, so I get a nice smatterin…

I've always been surprised when I run into developers who really don't have an interest in multiple languages, platforms, whatever. But, I think it's something you come to understand, that every profession has people that are just phoning it in every day. Some of the best people I've hired have had no experience in the one technology that I'm hiring for, but their enthusiasm and level of interest has been more than enough for me to want to take a chance on them. It usually works out well.

Re: Better Java – Resources for Writing Modern Java

#116

Post by jay-anderson »

vbezhenar wrote: post #26
hiram112 wrote: post #18

I've seen numerous posts lamenting the use of typical Java Beans. The problem with the struct approach is that numerous tooling / libraries expects beans with typical getter/setters - Jackson Json, Spring binding, etc. Yes it's possible with configurations and/or annotations to get around this, but IMO, saving a few lines of code in exchange for non-default behavior isn't a valid trade-off. Adding a dependency on Lom…

Another problem with struct approach is inconsistency. Sometimes you want a computed property and you use non-trivial getter. Sometimes you want to do some work in setter. And then client's code will look terrible: point.x * point.x + point.getY() * point.getY(). There are other problems: binary incompatibility; non-trivial refactoring when I need to introduce a getter or setter. Java really need lightweight property…

Projects exist to to make a light weight property syntax. The most prominent might be @Getter and @Setter from lombok (https://projectlombok.org/), but there are others which have similar goals (e.g. http://immutables.github.io/, https://github.com/google/auto).

That said, I agree that java _really_ needs something like this built in.

Re: Better Java – Resources for Writing Modern Java

#117

Post by agumonkey »

nobleach wrote: post #46
agumonkey wrote: post #43

Earlier quoted context omitted.

Mentioning Scala, or clojure or even Haskell to a HR interview leads to raised eyebrows at best. But that was expected. I'm surprised actual devs are still wearing eye blinders.

I'm hiring front end JavaScript developers right now. If I see other language experience on their resume, they're getting a call. My last hire had worked through "Learn You A Haskell" and that was enough for my interest to be piqued. Seeing Python, Ruby, C, ObjectiveC, heck even PHP is enough for me to see they're not just a "I did some Angular tutorials" type of candidate. I'm on this site, so I get a nice smatterin…

I should have added that it was IT consulting shops HR I was referring to, not final clients. The further away from the actual jobs, the more buzzwordy it gets. Some might appreciate curiosity and diversity, but in the end they want simple and bankable. They told me, some missions will enjoy jack of all trades type, but the majority of their clients wants framework-specific forces.

Re: Better Java – Resources for Writing Modern Java

#118

Post by monksy »

Cthulhu_ wrote: post #16

Re the first bit about 'struct' style, even better (IMO) is to use Lombok; throw an @Data annotation on your class and all you need to do is put your properties in there (private final if need be). Nobody should be writing those boilerplate constructors, getters and setters. If it's generated by your IDE, use Lombok. The best code is no code.

Thats one of the things that'll happen to you if you start writting groovy code. The whole setter/getter boilerplate thing gets really annoying.

Another groovy-ism.. the whole deal with having to copy properties. (In a groovy class they're threated like a map)

Re: Better Java – Resources for Writing Modern Java

#119

Post by lmm »

hiram112 wrote: post #18

I've seen numerous posts lamenting the use of typical Java Beans. The problem with the struct approach is that numerous tooling / libraries expects beans with typical getter/setters - Jackson Json, Spring binding, etc. Yes it's possible with configurations and/or annotations to get around this, but IMO, saving a few lines of code in exchange for non-default behavior isn't a valid trade-off. Adding a dependency on Lom…

The problem comes when you spot a Bean class and then it isn't. 99.9% of "getX" methods simply read the field. But if you assume that every "getX" method just reads the field, you'll be caught out by the rare one that doesn't - I've seen a production bug happen this way.

Re: Better Java – Resources for Writing Modern Java

#120

Post by pron »

mahmoudimus wrote: post #102
pron wrote: post #98

Earlier quoted context omitted.

When I get some time I'll update the OGMJ. I think the choice of tools mentioned is still very much up-to-date, it's just that some of the APIs used in the examples have been upgraded.

I really like OGMJ, it's definitely a great resource and I recommend it to many new Java developers; however, I disagree re: tools mentioned. After trying dropwizard for a few projects, the superiority of the spring-boot and its various ecosystems just blew me away. Also, while I appreciated Gradle, Maven is just much more supported through the entire eco-system. As a new comer to Java from C++/Python, it made a big…

You're probably right about Spring Boot. I've never been a web developer, and TBH, I've had no direct experience with either Boot or DW other than a simple Hello, World. At the time DW seemed the safer choice simply because it used the JAX-RS standards, and using standards in the Java world (especially good ones like JAX-RS) is a very good idea. But in the meantime Spring Boot has also done the right thing and adopted JAX-RS (at least as an alternate API), so I should add it to the post.

As to Maven vs. Gradle, that turned out to be the most controversial point of the entire guide -- which surprised me. Let me put it this way: both are good and I prefer Gradle. Also, Gradle, while still far behind Maven in terms of adoption, has good momentum. Either is a good choice at this moment, but I would guess that Gradle will take the lead in five years (although it's far from a safe bet).

Post reply on HN