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

81–90 of 192 posts

Re: Better Java – Resources for Writing Modern Java

#81

Post by nobleach »

fizwhiz wrote: post #67
nobleach wrote: post #52

Earlier quoted context omitted.

Well, I was an English major, so I'm glad you were engaged by the "diatribe". And if you were unable to piece it together... and I kinda feel bad if you couldn't. I'm referring to Java 8 language features and OpenJDK 1.8. I get the feeling you knew that though and are being pedantic. You've succeeded though, because I responded. Sadly you missed the part where I said, "Not all Java devs obviously". I have read great…

Your comment about the "JVM update" was a non sequitur trailing from your rant, but I'm glad to know that you were indeed referring to JDK 1.8. The fact that you get excited in the event these nebulous java devs have "heard" of Clojure/Scala only comes across as patronizing (but I suspect you weaved that in masterfully and deliberately, given your degree in English.) Your anecdotal fallacy hasn't added anything valua…

You have won at the internet. I'm sure you're a joy to be around. I haven't seen the meaningful response that you've added. You really do seem like a troll. If that's not your intention, that's cool. If it is, well, hey, happy trolling dude!

Edit* Yep, just checked your comment history, you're a troll. God why do people like you exist.....

Re: Better Java – Resources for Writing Modern Java

#83

Post by EdwardDiego »

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…

> Spring binding

Not sure what in particular you're referring to, but Spring supports constructor based dependency injection, and I tend to insist upon it vehemently - getter/setter injection means that you can instantiate your object in an invalid state.

Re: Better Java – Resources for Writing Modern Java

#84

Post by jacques_chester »

sandGorgon wrote: post #40

What web frameworks are you guys using in the Java 8 world that lets you leverage newer language features? Is it still Spring ? Are you guys doing things like Socket.io , etc. And is Hibernate the preferred orm ? Confession: I'm an ex Java programmer, who have been working in rails and python for past several years...so am fairly out of date. I have kept up with things like Dropwizard...but have not seen many other s…

Spring is on Java 7 for the 4.x series.

Spring 5 will take Java 8 as the baseline.

Re: Better Java – Resources for Writing Modern Java

#85

Post by Pyxl101 »

adpreese wrote: post #36
kilink wrote: post #23

I'm surprised he didn't mention AutoValue [1] or Lombok (using @Data and @Builder) in his section about data objects and builders. I prefer AutoValue, but both approaches cut down on a lot of the boilerplate (and they also generate sensible equals(), hashCode(), toString(), etc). It's also kind of a nitpick, but I disagree with his preference for Guava's Maps.newHashMap() vs new HashMap (). I'm pretty sure the only r…

He mentions Lombok in the tools section. And Guava's collection creation methods are part of an intense desire to not use the new key word anywhere in application code.

The other replies kind of hit on this, but I'll expand on it by saying:

The collection creation methods existed because Java could perform type inference on methods but could not on constructors:

  // Java 1.5
  Map map = new HashMap();
  // Guava
  Map map = Maps.newHashMap();
  // Java 1.8 diamond notation
  Map map = new HashMap();

Re: Better Java – Resources for Writing Modern Java

#86

Post by EdwardDiego »

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…

If you have required parameters in a Builder, you're doing it wrong.

Re: Better Java – Resources for Writing Modern Java

#87

Post by EdwardDiego »

ryanseys wrote: post #10

The only way it seems you can be effective with Java is with an IDE to do most of the heavy lifting. What would be better is if Java shipped with more focused command-line tools and better defaults that allow me to productive immediately without the need to learn something as hefty as IntelliJ / Eclipse. This could lessen the barrier of entry to Java and widen community adoption.

What would you use instead of an IDE? Learning Intellij is a lot easier than learning Vim or Emacs.

Re: Better Java – Resources for Writing Modern Java

#88

Post by jacques_chester »

cletus wrote: post #76

I mostly agree with this list but some things I have issues with. The biggest is DI. Having witnessed what a tangled mess large Guice codebases can become where you really have no idea what is providing what I have to say that Spring here gets a bad rap from the all-XML days and (IMHO) it is actually the cleanest and easiest to work with. The author mischaracterizes Spring too: > It has a either code-based wiring or…

> A modern Spring application will have precisely an application context XML file with one line per "bean" eg:

I prefer my Spring applications to look like this:

    @SpringBootApplication
    public class Application { ... }

Re: Better Java – Resources for Writing Modern Java

#89

Post by davnicwil »

mabbo wrote: post #73
meddlepal wrote: post #63

Earlier quoted context omitted.

Can you expand on the later point about final please?

tl;dr: final parameters != immutable and safety, and they look like they ought to. A lot of people write "final" in front of every. single. declaration. And they do that because someone once told them that was good. But then you remember that Java is a language which all non-primitive types are passed by reference, so your 'final' is actually a final reference and not a const immutable object, like you might get in C…

> If someone passes in a final FooBar to a method, and you mutate the FooBar during the method for any reason, then after the method is done the object remains mutated.

Fair enough, but if FooBar is your class there's an easy fix for this - make FooBar immutable. If it's not, make an immutable wrapper object for it.

Very true that relying on untrue assumptions about the immutability of your data will cause hard-to-spot bugs, but the solution is then just to guarantee everything is immutable, and define that as an assumption that cannot be false if everyone on the team follows the pattern.

If somebody does break the pattern, then that, rather than the race condition down the line, is the real bug. The dev who wrote the mutable data class can just have that (re-)explained to them, so it doesn't happen again.

Re: Better Java – Resources for Writing Modern Java

#90

Post by EdwardDiego »

namelezz wrote: post #49

I note that it's not safe to pass Java 8 streams around as streams can be closed when invoking terminal operations. If you pass a stream to a method and do not know whether the method is going to close the stream, it's dangerous to reuse it after the method return.

Well, once a Stream has been consumed, you can't use it again. We have a rule of thumb in my team that our APIs should not consume or return Stream or Optional.
Post reply on HN