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

71–80 of 192 posts

Re: Better Java – Resources for Writing Modern Java

#71

Post by potatosareok »

carsongross wrote: post #25

There is some good stuff in here, and a lot of bad. SparkJava (mentioned) is the great hope for sane java web development: http://sparkjava.com/ Having to convert out to streams for data structure manipulation with lambdas is insane. It would have been very healthy for the core java team to pull in someone with a lot of ruby experience so they could get that API right. Too bad: the JVM and associated tools are fantas…

Have you seen Goldman Sachs collection library? I've been using it for my Java work for last year and found it to work well. Put's a lot of useful methods onto the Collection objects themselves.

Re: Better Java – Resources for Writing Modern Java

#72

Post by potatosareok »

eddiezane wrote: post #56

This is a really great resource and I'll certainly be embracing some of it. I attend quite a few university hackathons as a mentor/sponsor and one of my goals has been to paint Java in a better light as it doesn't have the best reputation in that circuit. I'm always telling people that their goal should be to build something cool and learn something new. It's much easier to teach someone how to build their first weba…

Looking at Spark framework I'm wondering about your thought of Spark vs Spring Boot. I've not used Spark but I find Spring Boot lets you get an app of the ground quickly, is part of massive Spring ecosystem which gives you a lot of other advantages (for example, Mongo template might be very useful for Hackathon project). Beyond that RestController automatic integration with Jackson can quickly let you bring up a JSON based webservice.

Also I'm not a fan of how in your example the entire app routing/logic is basically crammed into a single main method. I know it might be simple demo app that you're trying to show off Twilo but I don't think you're doing favor by structuring like that.

What do you feel are the benefits of Spark vs Spring Boot (or Dropwizard I guess). In my mind the only reason I wouldn't use Spring-Boot for a new project in Java is if I wanted to use something like Play! since supposedly using Play!/Scala and futures integrate very nicely into that.

Re: Better Java – Resources for Writing Modern Java

#73

Post by mabbo »

meddlepal wrote: post #63
mabbo wrote: post #61

95% agree with these opinions, but have a few disagreements, or perhaps the author had missed some great stuff. Two main ones: Mockito is, IMHO, much nicer than jMock. And Immutability is good, but 'final' is... complicated. I find it's often over used by people who don't know why they're using it.

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.

Just this week, that exact problem caused my team an entire day of headaches. Two methods were being called concurrently using Futures, passing the same object to each method. One method mutated the object slightly, the other relied on it having not been mutated. Hello race condition. I was so proud to have solved it, until I realized I'm the dolt who wrote the bug in the first place.

Silly, I know. But the point is that final makes you feel safe when you might not be.

Re: Better Java – Resources for Writing Modern Java

#74

Post by habosa »

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 this problem, the library you're using is incorrectly using the Builder pattern. All required parameters should be in the constructor of the builder. Then the other methods on the builder should be optional configuration. For instance on Android you often see a builder that takes a `Context` in the constructor because that's almost always required.

Re: Better Java – Resources for Writing Modern Java

#75

Post by mabbo »

zatkin wrote: post #2

Streams are questionable in performance vs non-stream approaches. I haven't found an article that details performance differences, but I will say that I personally tried doing things using streams and doing the same things using non-streams and have had mixed results, one being faster than the other in some cases.

The benefits of streams isn't performance improvements for the CPU, but performance improvements for the developer.

Re: Better Java – Resources for Writing Modern Java

#76

Post by cletus »

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 XML configuration-based wiring.

Actually Spring can use a mix of XML code configuration and auto-wiring.

A modern Spring application will have precisely an application context XML file with one line per "bean" eg:
and that's it. Note: there's no classpath scanning. Auto-wiring takes care of the rest. This has two big advantages (over Guice in particular):

1. Everything is in one place. If it's not instantiated here it doesn't exist. Guice can be many levels deep and tends to descend into ModuleBuilders and conditional logic in modules (which the docs recommend against but tends to be used extensively anyway); and

2. Testing. Testing is incredibly easy. I'm talking functional testing here, even integration testing. You simply include another XML file that overrides any definitions from the first. Everything else remains the same.

Testing with Guice can be horrendous and once you start making extensive use of Modules.override() you should abandon all hope.

I'm glad to see this post recommend Maven. It's fun to bash Maven but most detractors ignore the huge benefit that applies to any shop with lots of devs: Maven is opinionated. That's a plus not a minus. Seen one Maven Web application and you've seen them all. There's no really weird directory layout because someone decided they just had to be different.

Lastly Play. I really tried to like Play. I really did. But as of Play 2.0+ it became a Scala not a Java framework. It may still work with Java but some things just require you to know something about Scala. That's a huge negative IMHO. I'm not interested in Scala. Nobody is.

Plus the auto-compile feature of Play tended to randomly break with indecipherable error messages for no readily apparent reasons such that you couldn't tell if it was a bug or not. I get enough of that with C++ template programming thank you.

I also agree that the two books the author recommends are probably the two most important Java books in existence.

Re: Better Java – Resources for Writing Modern Java

#77

Post by habosa »

nobleach wrote: post #38

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 t…

That's a shame. Java is my favorite language because it has the right balance of strictness (although Go is starting to take over for me). When written correctly, Java can be amazingly productive because you learn so much at compile time but the tools (IDEs) make it so that you can autocomplete away most of the verbosity.

Re: Better Java – Resources for Writing Modern Java

#78

Post by rbolkey »

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…

Have to agree here. The article's use of Optional is well intentioned, but shows use of the construct in a way that it was not intended. It should be used minimally, and only as a return value to signify the absence of a value. When you notice that Optional is not serializable, this starts to sink in.

Here are some more thorough treatments: http://stackoverflow.com/a/23464794 http://blog.jhades.org/java-8-how-to-use-optional/

Re: Better Java – Resources for Writing Modern Java

#79

Post by adevine »

userbinator wrote: post #62
harryh wrote: post #39

Earlier quoted context omitted.

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.

Despite what he says, I don't think Hoare actually invented the "null pointer", as address 0 for "not exists" or "end of list" was probably a common convention ever since linked structures existed and independently discovered by many others. (The other convention would be the all-bits-1 value, but I'd assume that testing for 0 was easier and thus more widely adopted. Also, "0 = nothing" makes great sense.) IMHO Optio…

Yeah, Optionals came from other languages, not originally Java.

IMO the problem with Optionals is that they'll never suffice unless they are part of the language itself, like in Swift. As this article pointed out, Optionals aren't supported in any existing APIs, so you still have to do a ton of null-checking everywhere. And there is nothing that guarantees an Optional reference itself can't be null, which is why you really want language-level support.

Re: Better Java – Resources for Writing Modern Java

#80

Post by nobleach »

habosa wrote: post #77
nobleach wrote: post #38

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 t…

That's a shame. Java is my favorite language because it has the right balance of strictness (although Go is starting to take over for me). When written correctly, Java can be amazingly productive because you learn so much at compile time but the tools (IDEs) make it so that you can autocomplete away most of the verbosity.

Java as a language is totally fine! It has everything one might need. The culture totally sucks. Oracle leads the march toward what is the "standard". Jersey is a great leap out of this.
Post reply on HN