An Opinionated Guide to Modern Java Development, Part 1(blog.paralleluniverse.co)
blog.paralleluniverse.co
An Opinionated Guide to Modern Java Development, Part 1
http://blog.paralleluniverse.co/2014/05/01/modern-java/
396 comments
I like the changes in Java 8, but I'm concerned about Java fragmentation between Oracle/OpenJDK and Android. It seems Android is stuck on Java 1.6 (since Dalvik is not "true Java" and is more like a VM that happens to implement a language very similar to Java 1.6). There's now a huge gap between 1.6 and 1.8. It's not just syntax like lambda and default methods. It's also the supporting API changes in collections (streams) and others. Dalvik was based on Apache Harmony which is a dead project and will never get the Java 8 API changes implemented. Does anyone know if Google is going to do something about Java 8 and Android?
I'm back to java after having an unsatisfying experience 2 years ago with Spring MVC, (this time i use the "play framework"), and it seems to confirm my intuition that the language itself is really just fine.
The problem lies more in bloated frameworks and corporate culture where everything needs to be standardized, regulated, and the purpose of a mandatory non-free training session.
Add to that the fact that every single topic is covered by at least 3 or 4 libraries, and you get a more complete view of the situation.
Add to that the fact that every single topic is covered by at least 3 or 4 libraries, and you get a more complete view of the situation.
One of my opinions these days on javadoc is that you should be minimalist. Have nothing to say about the return type? Don't add @return. Same for @param. Just a sentence about the method/field/class? Just a single line /* * ... */ is fine. Have nothing of value to say on a method/field/class (e.g. a getter), don't add javadoc at all. I'm growing weary of large files with tons of redundant javadoc lines to make some checkstyle/pmd rule happy.
> But the modern Java developer uses Gradle
I'm a little skeptical of this. More like the developer in the future uses Gradle. Usually when I go to a project's home page, I see documentation on how to include the Maven dependency, not the Gradle dependency. It's pretty obvious how to convert one format to the other, but my point is I think most people are using Maven.
I'm a little skeptical of this. More like the developer in the future uses Gradle. Usually when I go to a project's home page, I see documentation on how to include the Maven dependency, not the Gradle dependency. It's pretty obvious how to convert one format to the other, but my point is I think most people are using Maven.
The #1 thing you need to make Java usable is to abandon the JavaBean conventions. When every field requires 8 lines of boilerplate it's no wonder the code looks ugly (YAGNI, and if you do need it it's two keystrokes in your IDE to "encapsulate field"). public final fields are fine, and can get your data classes something close to readable.
I'd stick with maven for the build rather than Gradle; it's completely declarative and all the tools understand it. Learning a new language just to configure your build tool seems excessive.
I'd stick with maven for the build rather than Gradle; it's completely declarative and all the tools understand it. Learning a new language just to configure your build tool seems excessive.
I'm using Java for the first time because of Android. I had played with Java when it first came out but have stayed with C/C++/C# for almost everything.
I have to say that my Java experience isn't as unpleasant as I thought it would be. I always thought C# is what Java should have been but after learning a little idiomatic Java the reality is quite okay, really.
I have to say that my Java experience isn't as unpleasant as I thought it would be. I always thought C# is what Java should have been but after learning a little idiomatic Java the reality is quite okay, really.
That pluggable type system looks amazing. One thing that's weird to me is how java included a new Optional type (seems similar to Haskell's Maybe), but the compiler (afaik) doesn't prevent you from setting an Optional field to null. Something about that doesn't feel right. (Side Note: Optional isn't serializeable. Also... what's the best practice for using Optional when I'm using JPA? Can it be used in my Entities?)
I believe Jetbrains/Intellij-IDEA has created annotations for @NotNull/@Nullable, but afaik these just create warnings in the IDE. Maybe you can configure IDEA to mark these as compiler errors, but I don't know if my peers using netbeans/sublime/whatever would be able to notice when they write code that IDEA will refuse to compile.
I want compilation to FAIL in these cases.
I believe Jetbrains/Intellij-IDEA has created annotations for @NotNull/@Nullable, but afaik these just create warnings in the IDE. Maybe you can configure IDEA to mark these as compiler errors, but I don't know if my peers using netbeans/sublime/whatever would be able to notice when they write code that IDEA will refuse to compile.
I want compilation to FAIL in these cases.
A lot of people love to hate on Java, but it's a surprisingly dynamic language and there is a ton of great testing, networking, and many other libraries available.
One of the things I appreciate about Java is the ability to take large teams and just have their stuff work together, without having unhuman discipline around super subtle rules (eg: C++)
Also, IntelliJ is a must have!
One of the things I appreciate about Java is the ability to take large teams and just have their stuff work together, without having unhuman discipline around super subtle rules (eg: C++)
Also, IntelliJ is a must have!
I love Java, especially Java 8. But as the article points out, what frustrates me is threading. You can't do much without quickly running into threading issues. I played audio files in a game I made and it created up to 2,000 threads and crashed. Once I wrapped audio in an explicitly created thread this issue magically went away. Any kind of UI, timers, file I/O and network activity also involves threads.
The really horrible thing about these threads in Java is how hard it is to not share memory across them, because if you do terrible things happen. In other platforms you don't have to involve threads unless you want to, and you definitely aren't boxed into a situation where it becomes easy to accidentally share memory across theads.
I like Go's way of handling this. node.js is single threaded but the event loop makes it possible to do non-blocking IO without crazy Jave thread issues. Using synchronized, atomic properties and locks is not the right way to do these things as your code gets really complicated when trying to do basic things.
That gets me to my other pet peeve with Java. Just how much boiler plate there is to do basic things like opening up encrypted TLS TCP connections. Tons of cruft.
Anyway, having said that, I love Java and use it, but these things need addressing. I like Scala's Akka, I hope Java comes around and improves the horrible thread situation. I will have to check out Quasar. I know I just need to become more familiar with threading in Java in general. I'm actually pretty new to Java.
The really horrible thing about these threads in Java is how hard it is to not share memory across them, because if you do terrible things happen. In other platforms you don't have to involve threads unless you want to, and you definitely aren't boxed into a situation where it becomes easy to accidentally share memory across theads.
I like Go's way of handling this. node.js is single threaded but the event loop makes it possible to do non-blocking IO without crazy Jave thread issues. Using synchronized, atomic properties and locks is not the right way to do these things as your code gets really complicated when trying to do basic things.
That gets me to my other pet peeve with Java. Just how much boiler plate there is to do basic things like opening up encrypted TLS TCP connections. Tons of cruft.
Anyway, having said that, I love Java and use it, but these things need addressing. I like Scala's Akka, I hope Java comes around and improves the horrible thread situation. I will have to check out Quasar. I know I just need to become more familiar with threading in Java in general. I'm actually pretty new to Java.
Good article, lots of opinions but the title forewarns. For me, Eclipse is still very good and if anything, more stable than in earlier years. I've tried NetBeans and the free IntelliJ but though those are fine, Eclipse is better for me. The real trick is to _not_ store your code in the workspace (which is ironically where the project wizards default to unless you change it). Store your code in as an example, svn for Subversion, git for Git, etc. Use the workspace as just a shell to manage Eclipse preferences and such.
The biggest take I have from this post is that apparently they have created go-like lightweight threads for the JVM with Quasar (http://docs.paralleluniverse.co/quasar/) which is really interesting.
If I understand correctly, Quasar uses bytecode instrumentation to enable user-mode threads for the JVM, and they claim they did benchmarks that show X6 to X12 better performance than native JVM threads: http://blog.paralleluniverse.co/2014/02/06/fibers-threads-st...
This is really something that caught my attention.
If I understand correctly, Quasar uses bytecode instrumentation to enable user-mode threads for the JVM, and they claim they did benchmarks that show X6 to X12 better performance than native JVM threads: http://blog.paralleluniverse.co/2014/02/06/fibers-threads-st...
This is really something that caught my attention.
Something that really resonates with me from the linked PDF ("Blue-collar language") published in 1997:
> What I found most interesting in watching people use Java was that they used it in a way similar to rapid prototyping languages. They just whacked something together. I was initially surprised by that, because Java is a very strongly typed system, and dynamic typing is often considered one of the real requirements of a rapid prototyping environment. [...] you find out fast when something goes wrong.
Despite working in JS and Python, sometimes I feel more comfortable hacking something up in Java, because every missing method or undefined variable is an unavoidable short-term TODO.
> What I found most interesting in watching people use Java was that they used it in a way similar to rapid prototyping languages. They just whacked something together. I was initially surprised by that, because Java is a very strongly typed system, and dynamic typing is often considered one of the real requirements of a rapid prototyping environment. [...] you find out fast when something goes wrong.
Despite working in JS and Python, sometimes I feel more comfortable hacking something up in Java, because every missing method or undefined variable is an unavoidable short-term TODO.
I appreciate the modern Java style espoused here, it's much further away from the horrible overdesigned & pointless configuration style I often see with Java.
However, the author doesn't really understand why C++ and dismisses it quickly. The short answer is C++ gives control and abstraction on demand, an unusual combination. Java trades control in exchange for GC.
However, the author doesn't really understand why C++ and dismisses it quickly. The short answer is C++ gives control and abstraction on demand, an unusual combination. Java trades control in exchange for GC.
Ironically the Java ecosystem could stand to use some garbage collection of its own: there's a ton of old, outdated info out there that both colors people's impressions of the language and teaches new players a whole manner of bad habits. I appreciate what this article's going for and hope there'll be follow-ups.
I use Java daily and though there's undoubtedly room for improvement (I'm looking forward to when tooling better supports stuff added in Java 8), I think a lot of the negativity that surrounds it is undeserved. There's definitely bloated XML-infested frameworks out there but the core's a real workhorse.
I use Java daily and though there's undoubtedly room for improvement (I'm looking forward to when tooling better supports stuff added in Java 8), I think a lot of the negativity that surrounds it is undeserved. There's definitely bloated XML-infested frameworks out there but the core's a real workhorse.
> In this example, Java is rather annoying, especially when it comes to testing the type of a message with instanceof and casting objects from one type to another.
Using instanceof is an antipattern 99% of the time, easily avoided with proper API design. In this case a simple enum type would help with appropriate getType() method on the event; or a polymorphic event API with dedicated method types for each event (LifecycleEvent marker interface with ExitEvent subtype containing onExitEvent(ExitMessage m), etc), or ... or ...
Writing an intro to Java + touting your company's API + blaming Java for yourco's API problems: seems like bad form.
Which reminds me: can someone explain how actors is any different than using messages and queues for concurrent programming? Unless it also implies "magic translation of messages to method calls" which makes me uncomfortable (bad memories of CORBA/Web services)
Using instanceof is an antipattern 99% of the time, easily avoided with proper API design. In this case a simple enum type would help with appropriate getType() method on the event; or a polymorphic event API with dedicated method types for each event (LifecycleEvent marker interface with ExitEvent subtype containing onExitEvent(ExitMessage m), etc), or ... or ...
Writing an intro to Java + touting your company's API + blaming Java for yourco's API problems: seems like bad form.
Which reminds me: can someone explain how actors is any different than using messages and queues for concurrent programming? Unless it also implies "magic translation of messages to method calls" which makes me uncomfortable (bad memories of CORBA/Web services)
It's ironic, I'm slowly trying to move my development over to scala. I'll likely integrate gradle in to my stack (still use maven =/ mainly because I know all of its weird quirks)
What have people's experiences with gradle been? I'm not a huge fan of groovy hence why I stayed away from it.
What have people's experiences with gradle been? I'm not a huge fan of groovy hence why I stayed away from it.
The position of things like Netty and Undertow at the top of the techempower benchmarks has me a little intrigued. How much hassle is it to write websites with servlets like that?
I went from Java to Scala and am back to Java 8, and couldn't be happier with my choice. We are also using the latest Spring 4 framework which plays well with Java 8.
A lot of the Spring + Java haters haven't really looked at all the improvements have happened to both Spring and Java recently, either that or they just like to bounce off what they read online without any actual experience.
It's a solid stack for a backend, and I have built the whole platform on in without a hitch.
A lot of the Spring + Java haters haven't really looked at all the improvements have happened to both Spring and Java recently, either that or they just like to bounce off what they read online without any actual experience.
It's a solid stack for a backend, and I have built the whole platform on in without a hitch.
What about dependency injection in modern java - is Guice or spring still the de facto standard?
I have come full circle in a way. I started learning Java in school and built a few, small things for Android and the desktop. Then I was "all like;" I am going to learn the hotness which was(is?) Node. Node is what it is and I didn't really care for it. Then I moved on to Python and I really like it. Python is awesome for many, many things but GUI applications are not one of them. I have since returned to some Android development and I am diving into a CRUD web app in Java. Simple stuff, but it needs to be fast.
Looking forward to part 2 and more!
Looking forward to part 2 and more!
Why do people seem to think "opinionated" is a virtue these days?
>But the modern Java developer uses Gradle...there are quite a few things that are quite, though not very, common, but still require dropping down to imperative Groovy.
This is the first time I have heard of Gradle, but why would I use a build tool that requires me to learn Groovy. If I already know Java I wont be learning something new just to build a Java project.
I find a lot of development tools/frameworks make me learn B just to get started with A, its really frustrating for someone with limited experience IMHO.
This is the first time I have heard of Gradle, but why would I use a build tool that requires me to learn Groovy. If I already know Java I wont be learning something new just to build a Java project.
I find a lot of development tools/frameworks make me learn B just to get started with A, its really frustrating for someone with limited experience IMHO.
I have to agree with the first comment on the blog. Gradle is strictly worse than Maven - it's basically Ant reinvented with Groovy. It leads itself to poorly maintained, complex build files, and the only good parts are the bits that use Maven under the hood (so just use maven ;-)). It's also slow.
Also, if you seriously want to use an Actor framework in Java, you should use Akka - the lead devs really know their stuff, and are active in Java concurrency circles (JSR-166).
Also, if you seriously want to use an Actor framework in Java, you should use Akka - the lead devs really know their stuff, and are active in Java concurrency circles (JSR-166).
I'd like to hear thoughts on CheckedExceptions in part 2. IMO, they are a disaster - most projects degrade into all methods having a "throws Exception" clause. But I'm not sure if there is any consensus on how the CheckedException haters like myself work around them. I use Runtime exceptions everywhere, but it's a pain/boilerplate to convert them.
Not a single mention of Guice or even dependency injection?
Seems like a gaping omission in a guide that claims to be about "modern" Java.
Seems like a gaping omission in a guide that claims to be about "modern" Java.
> ...simplicity of Maven...
Did I read that right?
Did I read that right?
Does anyone here do Java development sans IDE -- like, say, with Emacs?
If you have come to this post expecting to read something related to modern Java for the web, and have come back unsatisfied, then here is something to make up for that: yeoman's jhipster generator: http://jhipster.github.io/
Presentation: http://jhipster.github.io/presentation/
Presentation: http://jhipster.github.io/presentation/
What did the Eclipse team do so wrong to fall so fast?
Also, what are Maven's fatal flaws? I don't consider XML a flaw.
Also, what are Maven's fatal flaws? I don't consider XML a flaw.
Another great Java resource (though admittedly the current edition is focused on Java 7) is "The Well-Grounded Java Developer" by Evans & Verburg [1].
[1]: http://www.manning.com/evans/
[1]: http://www.manning.com/evans/