Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

blog.paralleluniverse.co

Post reply on HN
Print view View original

121–130 of 168 posts

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

#121

Post by vorg »

eranation wrote: post #40
mark242 wrote: post #2

It's funny. An "Introduction to Modern Java Web Development" 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've got your json manipulation, routing, connecting to a database, DI, actors, etc. Java devs-- you seriously owe it to yourself to spend the time investigating and ramping up onto Scala and Play. This is where the fut…

My favorite - write Scala (or even Kotlin) with Spring (the new versions of Spring) or - Java EE 6/7 with non standardized Jersey MVC (hope they'll add it in Java EE 8) I think Play / Spray and Akka are great but let's differentiate between the language and the framework. You can write Play / Akka with Java (they added Java 8 support recently) and you can write Spring / Java EE with Scala (I do that all the time and…

> you can write Spring / Java EE with Scala

It'd be nice if we could also write Gradle with Scala, or some other decent JVM language.

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

#122

Post by AnimalMuppet »

jrochkind1 wrote: post #44
phillmv wrote: post #25

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

> but you need to know about so many different things just to get off the ground. I think that's probably true of just about any mature environment these days, isn't it? Nobody wants it to be true. You make something new, thinking, this time i'll do it right, it'll be so simple, easy to get going with. And it is at first. Then you add stuff to deal with all the things that turned out to be pain points, all the edge c…

Yes, it's true of just about any mature environment these days.

And why? Because we want a mature environment to do a bunch of things for us, so that we don't have to (badly) re-implement everything. But the price of that is, we have to learn how to get the framework to do those things for us.

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

#123

Post by pron »

runT1ME wrote: post #113
pron wrote: post #102

Earlier quoted context omitted.

Yep, that's very nice code, except: user = getUser(1) company = getCompany(user.companyId) longresult = process(company.getSomething) is a) simpler (because that's what your normal code looks like), b) performs exactly the same (as fibers basically do the same thing, only transparently), and c) retains context (like ThreadLocal variables). So if that was the only way, I'd say, fine. But once you have lightweight thre…

> simpler (because that's what your normal code looks like) Actually, no. My code will always look like the for comprehension be it async or not, because my 'get' methods will always return an Either, Option or some other monadic context to represent the computation succeeding or not. > performs exactly the same (as fibers basically do the same thing, only transparently), Yes, I agree. > c) retains context (like Thre…

When I learned to program (back in the 80s), I learned that if you want to tell the computer to do operation X and when that's done, do operation Y, you just write both statements one after the other. If you're comfortable using for comprehensions to achieve that same goal -- that's great. To me it seems that your code simply replicates what a thread does. If you have a problem with your thread's implementation -- fix it. If you want the compiler's help -- use the compiler to write the for comprehensions, or monads for you. Personally, I don't think you should need monads for "do X then Y", and neither does Scala, by the way. Scala says that you only need them if you want to say "do X then Y, but don't use OS threads".

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

#124

Post by nostrademons »

jrochkind1 wrote: post #46
rdtsc wrote: post #42

Earlier quoted context omitted.

That is kind of the issue in Go at the moment. They have been oscillating between default stack sizes and also switched from green threads to real OS threads backing goroutines. EDIT: scratch the last statement about Go using OS threads for goroutines. I was thinking of something else. Sometimes on Linux systems, even allocating a large stack size doesn't actually consume that as physical memory. Malloc might give yo…

Someone should really compile a list of all the non-toy languages/environments that started with green threads and switched to native threads, with explanations of what they were trying to do and what happened and why they switched. It seems to be a popular path. Before the next person thinks "oh, this would be so simpler and more problem-free if I use green threads", that person should really review the prior art, h…

Relevant HN thread:

https://news.ycombinator.com/item?id=6977177

BTW, I wonder if Paul Turner's work on fibers will change this equation if/when it makes it into the production kernel.

https://www.youtube.com/watch?v=KXuZi9aeGTw

Google has had very promising initial results with it.

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

#125

Post by zmmmmm »

eip wrote: post #81
java-lang wrote: post #8

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.

I've been stuck using Vert.x for a year and half. I recommend using something else. It's a questionable framework mashed together with a poorly though out messaging system. I would rather use Spring Integration, Quasar, or Akka.

Would be interested in any more concrete description of the problems? I'm considering using Vert.x in a project, mainly because of the polyglot features (ability to be extended by many different people some of who only know Python, others who only know Java and some who might only know Javascript, etc).

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

#126

Post by [deleted] »

eip wrote: post #92
mark242 wrote: post #57

Earlier quoted context omitted.

Blocking in Play should be foreign. On modern hardware architectures, writing code that blocks is the equivalent of throwing up your hands and saying "I can't trust myself to write efficient code so I'll just scale out my hardware and hope for the best". This is how Amazon winds up making so much money off Java developers who get constrained by thread pools and wind up spinning up a million instances of m3.medium mac…

Doing a 'hardComputation' async provides no advantage. The cpu is limited to how much computation it can do and if you have enough of those 'hardComputations' running simultaneously whether sync or async you will hit the limit of the cpu. Async is only beneficial in terms of IO.

[deleted]

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

#127

Post by smoyer »

tristanperry wrote: post #104

A very good article; well written and explained. For Java web development, it is worth re-considering Spring Boot though * ( http://projects.spring.io/spring-boot/ ) 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. We just started using this where I work, and it's a great step forward compared to old style, XML driven…

Full JavaEE development is pretty analogous - POJOs and annotations. I almost gave up on enterprise Java when every EJB required multiple classes, interfaces and often XML configuration too.

Modern JavaEE isn't nearly as heavy as the article seems to think ... but I can't argue with the article's underlying pragmatism. Use the simplest set of tools that accomplish the task!

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

#128

Post by eropple »

rch wrote: post #79
eropple wrote: post #55

Earlier quoted context omitted.

Jersey is very simple to get running, but it has pretty big drawbacks: there's not much you can do with it. Dropwizard and similar ameliorate this a bit, but compared to Play (which does have onboarding challenges) you have a long road to hoe to go from Jersey to a nontrivial app. And, personally, the problems don't end there--I think I'd quit programming before going back to any Java-based hat-on-top-of-JDBC. Scala'…

For the last few years my apps have trending towards components that don't do much individually, but can be made to work well together. I haven't used Jersey on anything major, but it fits the profile I'm looking for. For what it's worth, Akka is even more relevant to what I'm doing.

That's fair, but Jersey's not really very good at many of those individual things. It's not a great tool for a JSON API unless your consumption target is pretty much the same domain library on the other side because you'll end up neck-deep in @JsonProperty. It's not great as a frontend because Freemarker, StringTemplate, and Velocity are all pretty gross.

Play, for me, gives me good tools for doing stuff, and I can make individual services as big or as small as I want.

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

#129

Post by eropple »

eip wrote: post #92
mark242 wrote: post #57

Earlier quoted context omitted.

Blocking in Play should be foreign. On modern hardware architectures, writing code that blocks is the equivalent of throwing up your hands and saying "I can't trust myself to write efficient code so I'll just scale out my hardware and hope for the best". This is how Amazon winds up making so much money off Java developers who get constrained by thread pools and wind up spinning up a million instances of m3.medium mac…

Doing a 'hardComputation' async provides no advantage. The cpu is limited to how much computation it can do and if you have enough of those 'hardComputations' running simultaneously whether sync or async you will hit the limit of the cpu. Async is only beneficial in terms of IO.

Preemptive multitasking makes this much more valuable than you portray it. Play also makes it really easy and you don't have to seriously think about it.

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

#130

Post by jshen »

twic wrote: post #120
jshen wrote: post #93

Earlier quoted context omitted.

Maybe we mean different things by "separated". I want the app server bundled into the app, not an assumed dependency that the app has on the target environment. Rack in the ruby world exposes an API that ruby web apps build on top of, but you never install an app server then install your app into the server.

Aha, yes, that makes sense. I don't think there's anything fundamentally wrong with packaging the app server along with the app. It's just not traditional in the Java world. My preferred solution would be to package the app and the app server as operating system packages, and have the app depend on the app server. That makes the dependency explicit, but doesn't leave you with a gigantic deployable.

Here is one reason I like the bundled approach. I've been using golang recently which compiles into a machine executable. I was building a REST API that many third parties would use. When they wanted to use the API for development all I had to do was send them the bundle and tell them how to start. There were no other dependencies at all. It didn't assume a particular package manager, OS, or anything else. Take this file and execute it, that's it.
Post reply on HN