An Opinionated Guide to Modern Java, Part 3: Web Development

It&#x27;s funny. An &quot;Introduction to Modern Java Web Development&quot; sounds like a primer for the Play Framework, Scala, and Akka. Each of the examples looks like the starter documentation for Play, in that you&#x27;ve got your json manipulation, routing, connecting to a database, DI, actors, etc.<p>Java devs-- you seriously owe it to yourself to spend the time investigating and ramping up onto Scala and Play. This is where the future of Java web app development is being driven from, by Typesafe and the Play &#x2F; Spray &#x2F;Akka open source developers. You do yourself a great disservice by sticking with Spring, Hibernate, JBoss, and the old standbys.

A very good article; well written and explained.<p>For Java web development, it is worth re-considering Spring Boot though * (<a href="http://projects.spring.io/spring-boot/" rel="nofollow">http:&#x2F;&#x2F;projects.spring.io&#x2F;spring-boot&#x2F;</a>)<p>Spring MVC and Data (et al) powered entirely by annotations, and (e.g.) Thymeleaf for templating, can lead to some fairly powerful yet concise apps.<p>We just started using this where I work, and it&#x27;s a great step forward compared to old style, XML driven Spring MVC and Hibernate.<p>Also Spring Boot does bring quite a lot of support for REST, via RestTemplate&#x2F;RestOperations, along with support for consuming and producing JSON and&#x2F;or XML at the controller levels.<p>* Edit: I say re-considering since the article only briefly mentions it.

I am especially fond of his view on database layers. There&#x27;s JDBC, which is extremely verbose and needs scaffolding to make it usable, and then ORMS, that will quickly fall apart the moment you actually need to do anything interesting with the database.<p>The Spring solution to this problem was always my favorite part of their stack: JDBC template removed most of the error prone boilerplate from JDBC, adds a couple of features, and still lets you write SQL directly, which is probably what you should be doing in almost all the cases where a relational database becomes valuable.<p>I can&#x27;t wait for shops to start to use Java 8. The removal of so much boilerplate when trying to build functional interfaces should make the Java toolsets move forward very quickly.

I think that thread scheduling is really not the high pole in the tent for large numbers of threads. It&#x27;s stacks. If you want to have a million stacks and each is allocated to the highest watermark that thread ever reached you will run out of memory.<p>I suspect that task size has to be smaller than the typical bit of web processing code for context switching overhead to really dominate, or even be expensive enough to matter. That says as much about how expensive common tools and frameworks are as it does about the cost of context switching.

I don&#x27;t get the point of saying that application servers are dead and then... embedding application server within the application. If applications should be isolated they can be easily deployed on different application servers. The result will be the same, with the difference that we get all advantages of easy application deplyment using war files, and some nice tools supporting the whole process.

It&#x27;s great to see how Java web development has progressed. I tried to make a Spring MVC web app work like a decent, modern, readable and productive web application two years ago and it just wasn&#x27;t possible.<p>Anyone interested in modern JVM web development I would still advise to invest time in learning Scala (or Clojure). They can work with your legacy code and libraries, but my productivity and general joy in programming shot through the roof when I started using Scala.

As a modern java developer I was surprised to find no mention of Vert.X which to me seems like one of the most modern and forward-thinking java web frameworks. Not only does it support scaling your app out-of-the-box but also provides a simple way to deal with concurrency.

How does asynchronous futures end up being more complicated or in any way worse than the blocking threaded approach?<p><pre><code> for { user &lt;- asyncGetUser(1) company &lt;- asyncGeCompany(user.companyid) longresult &lt;- asyncProcess(company.getSomething) } yield longresult</code></pre>

Man, am I ever fascinated with the complexity Java devs have to put up with.<p>Maybe it&#x27;s just been a long time since I had to deal with Java-land, but you need to know about <i>so many different things</i> just to get off the ground. Granted, this may be easier with newer frameworks, but still.

You had me until you said Asynchronous I&#x2F;O is faster than Synchronous I&#x2F;O in Java.<p><a href="http://www.mailinator.com/tymaPaulMultithreaded.pdf" rel="nofollow">http:&#x2F;&#x2F;www.mailinator.com&#x2F;tymaPaulMultithreaded.pdf</a>

Great work Ron.These should be a small (or maybe a full) book some day.<p>Java is not my main language, but I liked the Advanced Topic: Blocking vs Non-blocking section and in general have been following Parallel Universe technology stack.<p>If anyone is interested more in the async vs actors, there is a nice new podcast with Ron Pressler, Fred Hebert (Learn You Some Erlang For Great Good author), Kevin Hamond and Zachary Kessin<p><a href="http://mostlyerlang.com/2014/05/15/037-parellel-universe-with-ron-pressler/" rel="nofollow">http:&#x2F;&#x2F;mostlyerlang.com&#x2F;2014&#x2F;05&#x2F;15&#x2F;037-parellel-universe-wit...</a><p>There is a discussion about concurrency, how Quasar works underneath (hint: there is an interesting bytecode transform that takes place during loading), shared state, Erlang, Clojure and Datomic. Anyway, highly recommend.

Thank you for sharing the amazing work. I do not know if there is a part 4 coming or not but do you have a good pattern for validating users&#x27; input?

I will say though, dismissing Rob Von Behren in the area of async vs. sync IO with an anecdotal paragraph is a ballsy move. (i.e. &quot;wrong approach&quot;)

Do you really need to write a controller and all its actions for each resource with Jersey?

Is there a preferred way to submit typos other than in comments?

&gt;Let me put this clearly: asynchronous APIs are always more complicated than blocking APIs..<p>IMO I would rather use a single threaded server and manage synchronicity explicitly with callbacks, composable promises, comprehensions, monads, and &quot;other functional shenanigans&quot; vs having to sync shared state across threads and manage thread pools.