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

71–80 of 168 posts

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

#71

Post by mushishi »

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…

No, it isn't. I was a Scala enthusiast but experience has taught me to like Java and its maturity and dislike Scala's unstable complexity (maybe it's more stable now than back when I was onboard) but the language by design embraces abstraction building that is nice-looking superficially but deeply hard-to-understand when different features interplay, which also makes the tooling harder to get right.

Also, Spring is not that bad, though sometimes I have hard time to understand some of the initialization/runtime problems. Hibernate and JBoss I rather skip, and use Tomcat and Dalesbred for relational data access.

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

#72

Post by jksmith »

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…

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.

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

#73

Post by jaxytee »

cpprototypes wrote: post #52
jaxytee wrote: post #49

Earlier quoted context omitted.

I don't find mark242's comment off putting or condescending at all. He's just telling is like it is. Of course there are Java developers who can kick ass with Spring, Hibernate, Servlet containers, and war deployments, but all of these tools are huge, bloated, and starting to show their age. Modern frameworks like Play make things simpler for those of us who don't have +7 year JEE experience with Spring and Hibernate…

The comment is off topic since the article is not about Spring or JBoss and it recommends against using Hibernate. The article is about a modern lightweight stack (JAX-RS, Jetty, Dagger, JDBI).

Not it's not, rebutting another poster who is commenting about Play (a modern java web development framework) in a article that is about modern java web development frameworks. Your comment is counter productive to this conversation, and the purpose of Hackernews in general.

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

#74

Post by rch »

jebblue wrote: post #68
rch wrote: post #37

Earlier quoted context omitted.

Jersey is extremely simple to get running, even on App Engine (if you're into that). Getting Flask, uwsgi, and nginx running on OpenShift isn't particularly difficult, but I had to follow a detailed blog post to get it working.

Even simpler, Spark Java. You can't make REST on any platform or in any language I've tried any easier and still be building on a solid foundation.

Looks really slick. Thanks!

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

#75

Post by pron »

mark242 wrote: post #57
pron wrote: post #16

Earlier quoted context omitted.

Author here. As I explain in the article, I cannot recommend any framework that encourages asynchronous code. It's simply the wrong approach, no matter what functional tricks are used to make it more palatable. And the blocking Play APIs both feel foreign to Java, and provide no benefit over the standard, and widely implemented, JAX-RS.

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.

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

#76

Post by ryanobjc »

kasey_junk wrote: post #62
saryant wrote: post #59

Earlier quoted context omitted.

> And unlike him, I have a 30,000 line scala production project under my belt. Everything he says is true, and then some. Ever split up a file into chunks because intellij can't edit it effectively? I have a 20k line Scala project in production and editing it has certainly never been an issue. Why does Intellij have problems with large files?

I've written several large Scala projects and never had Intellij choke on large files.

Incrementally compiling a 3000 line file in 2011 as you edited it.

I'm sure the Jetbrains folks have fixed that right up, but at the time, breaking it into 500 line chunks was required, due to the exponential nature of the slowdown we accomplished.

The basic reality is Scala compiles are slow. Syntax and red-line highlighting isn't cheap, and no amount of brilliant russian IDE developers can totally fix everything.

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

#77

Post by twic »

jebblue wrote: post #69
haddr wrote: post #18

I don'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.

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.

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

#78

Post by jrochkind1 »

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…

It seems like Go uses it's own threads but backed by OS threads, rather than actually pure green threads. Yes?

But yeah, a whole lot of people seem to think "man, OS threads suck, surely we can do better with green threads," only to find out why OS threads suck, and that many developer-years of work have gone into making them not suck more.

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

#79

Post by rch »

eropple wrote: post #55
rch wrote: post #37

Earlier quoted context omitted.

Jersey is extremely simple to get running, even on App Engine (if you're into that). Getting Flask, uwsgi, and nginx running on OpenShift isn't particularly difficult, but I had to follow a detailed blog post to get it working.

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.

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

#80

Post by saryant »

ryanobjc wrote: post #76
kasey_junk wrote: post #62

Earlier quoted context omitted.

I've written several large Scala projects and never had Intellij choke on large files.

Incrementally compiling a 3000 line file in 2011 as you edited it. I'm sure the Jetbrains folks have fixed that right up, but at the time, breaking it into 500 line chunks was required, due to the exponential nature of the slowdown we accomplished. The basic reality is Scala compiles are slow. Syntax and red-line highlighting isn't cheap, and no amount of brilliant russian IDE developers can totally fix everything.

2011 was a long time ago.

scalac certainly isn't fast but I just clean compiled our 20k line project in 75 seconds.

I'm not claiming that's great or anything, I just don't find it to be a showstopper.

Post reply on HN