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

81–90 of 168 posts

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

#81

Post by eip »

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.

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

#82

Post by jshen »

twic wrote: post #77
jebblue wrote: post #69

Earlier quoted context omitted.

One of the problems with application servers is like well, port separation, process isolation, when a change to the context is desired but it might affect all the apps you have to be very careful. Having your web app be its _own_ app is hugely advantageous.

You can, and usually do, do exactly that with app servers. It's true that app servers were originally conceived as a way of hosting multiple apps in a single JVM, but it quickly became apparent that this was a terrible idea, and nobody does it. You run one instance of the app server per app. The app server is really just a great big bundle of useful libraries and a web framework.

so why separate the two if there is always 1 app per app server?

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

#83

Post by alpeb »

zinxq wrote: post #17

You had me until you said Asynchronous I/O is faster than Synchronous I/O in Java. http://www.mailinator.com/tymaPaulMultithreaded.pdf

The Rob Van Behren slide is priceless: dude started building an async server and at the end realised he wrote the foundation for a threading package. I once asked myself the same question and did a little micro benchmark https://github.com/alpeb/io_benchmarks concluding IO was faster. Even so, I ended up doing all my stuff in Scala+Play because it's an immense pleasure and it's so easy to scale.

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

#84

Post by simpsond »

jaxytee wrote: post #23

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

If you keep your data immutable you can have the best of both worlds.

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

#85

Post by Consultant32452 »

jksmith wrote: post #72
jrochkind1 wrote: post #44

Earlier quoted context omitted.

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

It's certainly not true with Go so far in my experience. Download, grab some packages that do specific things, put together a solution. Low noise.

To be honest most of the java code I write is just gluing a bunch of libraries together to accomplish the desired task.

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

#86

Post by justinsb »

rdtsc wrote: post #42
arielweisberg wrote: post #5

I think that thread scheduling is really not the high pole in the tent for large numbers of threads. It'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. 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…

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…

I've been wondering about this as well. Goroutines start with an 8KB stack size now; native threads seem to use an 8MB _virtual_ stack size of which often only one or two pages (of 4KB) will be used. So is the primary remaining advantage of goroutines vs threads the efficiency of the go scheduler?

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

#87

Post by twic »

mwcampbell wrote: post #64
jrochkind1 wrote: post #46

Earlier quoted context omitted.

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…

On the one hand, I've observed that operating system implementers have repeatedly tried and rejected green threads for their pthread implementations (Solaris many-to-many threads and FreeBSD KSEs are both now historical footnotes). In Linux around 2002, there was a new many-to-many pthread implementation called NGPT that was backed by big players like IBM and Intel, until a couple of Red Hat developers (Ulrich Dreppe…

The wheel continues to turn:

http://msdn.microsoft.com/en-us/library/windows/desktop/dd62...

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

#89

Post by wtetzner »

zak_mc_kracken wrote: post #26
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…

First of all, your attitude is off putting and condescending. You don't convince people by telling them "You guys are living in the past, look how I do things, you should do the same". Please enough of that, especially coming from the Scala community. Let's act as professionals and judge tools on their merits instead of instigating flame wars. Second, I'm doing both (web Java at work, web Scala on my spare time) and…

> ... Java 8 is numbing a lot of the pain I used to feel.

Interestingly, the biggest thing I wish I had when writing Java is algebraic data types and pattern matching. A few years ago I would have said it was lambda, but having sum types would make expressing many things so much easier.

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

#90

Post by kasey_junk »

pron wrote: post #75
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…

You should read the end of the post, then. The asynchronous, non-blocking approach, is always wrong. Regardless of your hardware architecture.

I know what you mean by the post and your current assertion that non-blocking is "always" wrong regardless of architecture, but I think there are a few caveats that you really need to apply here.

You are talking about a problem domain where concurrency is what you are scaling and where the things that would block are orders of magnitude slower than processor time.

If you were working in a problem domain where latency is what you are scaling and the blocking calls are on the same order as processor time, non-blocking approaches can be best as the blocking mechanism can still carry overhead even with light weight threads.

Maximizing throughput is another beast entirely as well.

Post reply on HN