Better Java – Resources for Writing Modern Java • Hacker News Board

Re: Better Java – Resources for Writing Modern Java

#31

Post by kilink » Sat, Sep 19, 2015, 11:39 PM UTC

vbezhenar wrote: post #24

trbvm2 wrote: post #20

Dependency Injection (frameworks) -1 Use constructors. This makes perfectly testable classes and is vastly simpler than encouraging more XML as code. Any proper dependency injection framework should work quite well with regular constructors.

Constructors have their problems. First: constructor calling is not readable because Java misses named parameters. It's fine when there are 2-3 dependencies, but not more. Second: circular dependency is not possible. So I prefer to use setter dependencies, as they don't have those problems.

> First: constructor calling is not readable because Java misses named parameters. It's fine when there are 2-3 dependencies, but not more.

If you have more than 2-3 dependencies, it might be time to refactor things, as your class may be doing too many things.

> Second: circular dependency is not possible.

Circular dependencies are possible with constructor injection when using a DI framework (e.g., using a Provider in Guice [1], or the equivalent in Dagger).

[1] https://github.com/google/guice/wiki/CyclicDependencies

Re: Better Java – Resources for Writing Modern Java

#32

Post by jordanpg » Sat, Sep 19, 2015, 11:42 PM UTC

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…

Also, whatever stylistic issues are raised by JavaBeans are largely obviated by modern IDEs.

Re: Better Java – Resources for Writing Modern Java

#33

Post by logn » Sat, Sep 19, 2015, 11:49 PM UTC

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…

> Sometimes you want a computed property and you use non-trivial getter

Then pre-compute it, make it immutable, and expose the variable. And if that ends up being too hard it's probably because you need a builder and/or to group your properties into smaller classes.

Re: Better Java – Resources for Writing Modern Java

#34

Post by trbvm2 » Sun, Sep 20, 2015, 12:00 AM UTC

fizwhiz wrote: post #22

trbvm2 wrote: post #20

Dependency Injection (frameworks) -1 Use constructors. This makes perfectly testable classes and is vastly simpler than encouraging more XML as code. Any proper dependency injection framework should work quite well with regular constructors.

Your comment is unclear. Are you encouraging people to NOT use DI frameworks, or using them only with constructor-based injection?

The latter. DI frameworks are a convenience item, they should probably not have a big effect on the way the code is written. You get most of the benefits of DI just from not new'ing up things within your classes.

The main advantage of keeping the constructors around is that you retain more flexibility in interacting with that bit of code.

Re: Better Java – Resources for Writing Modern Java

#35

Post by barrkel » Sun, Sep 20, 2015, 12:05 AM UTC

logn wrote: post #33

vbezhenar wrote: post #26

Earlier quoted context omitted.

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…

> Sometimes you want a computed property and you use non-trivial getter Then pre-compute it, make it immutable, and expose the variable. And if that ends up being too hard it's probably because you need a builder and/or to group your properties into smaller classes.

Precomputing properties on a hundred million object instances is not cheap.

Re: Better Java – Resources for Writing Modern Java

#36

Post by adpreese » Sun, Sep 20, 2015, 12:07 AM UTC

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.

Re: Better Java – Resources for Writing Modern Java

#37

Post by trbvm2 » Sun, Sep 20, 2015, 12:10 AM UTC

vbezhenar wrote: post #24

trbvm2 wrote: post #20

Dependency Injection (frameworks) -1 Use constructors. This makes perfectly testable classes and is vastly simpler than encouraging more XML as code. Any proper dependency injection framework should work quite well with regular constructors.

Constructors have their problems. First: constructor calling is not readable because Java misses named parameters. It's fine when there are 2-3 dependencies, but not more. Second: circular dependency is not possible. So I prefer to use setter dependencies, as they don't have those problems.

I agree on the first. I'm only advocating for keeping the constructor as the DI entry point. A DI framework can then be used for the convenience they provide in wiring things up at main.

Regarding the second: I think circular dependencies should be avoided whenever possible so I view the difficulty constructors create there as advantage rather than a problem.

https://en.wikipedia.org/wiki/Circular_dependency#Problems_o...

Re: Better Java – Resources for Writing Modern Java

#38

Post by nobleach » Sun, Sep 20, 2015, 12:16 AM UTC

After working at two companies filled with Java devs, I don't think any of them will read this article. I can't speak for all Java devs obviously, but it seems unless the dev is a polyglot, they are just fine living in their Spring/SVN/J2EE/Java5 world. They have no idea what's going on in the software development world. I get so excited whenever I hear any of them mention Clojure or even Scala! They just live with this head in the sand mentality. They hate the front end, they think, "these JavaScript developers will go away someday and we can finally go back to writing JSPs". Currently we've updated our JVMs to 8, and that's a big deal, but we've told our devs NOT to use any features from 8 as we're worried about how GC will perform and since we're about to get geared up into shopping season, now is not the time to use shiny new features.

Re: Better Java – Resources for Writing Modern Java

#39

Post by harryh » Sun, Sep 20, 2015, 12:18 AM UTC

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.

Re: Better Java – Resources for Writing Modern Java

#40

Post by sandGorgon » Sun, Sep 20, 2015, 12:23 AM UTC

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 startups do Java development.