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

http://blog.paralleluniverse.co/2014/05/15/modern-java-pt3/

by dafnap • 12 years ago

226 162 12 years ago

blog.paralleluniverse.co

mark2424• 12 years ago

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 future of Java web app development is being driven from, by Typesafe and the Play / Spray /Akka open source developers. You do yourself a great disservice by sticking with Spring, Hibernate, JBoss, and the old standbys.

UK-AL• 12 years ago

I put my money on Spring, Hibernate, JBoss lasting longer than Scala, Akka etc.

Those technologies have stayed on, while other trends have come and and go.

tmarthal• 12 years ago

Actually, it is basically Pivotal versus TypeSafe, not just Spring versus Akka or anything like that.

I put my money on TypeSafe.

Pivotal still (05/2014) doesn't have Java8 support for some of it's frameworks (grails https://jira.grails.org/browse/GRAILS-11063 ). TypeSafe pre-released versions of Play that take full advantage of Java8 features.

Given that if you need to run a Java 1.4.2 app on top of JBoss (or Glassfish!) then the types of technologies that these two companies are pushing are solving problems in a different domain.

And arguably the PermGen change in Java8 would benefit Grails/Groovy the most.

pjmlp2• 12 years ago

You do yourself a great disservice by sticking with Spring, Hibernate, JBoss, and the old standbys.

Given the amount of money you get with them, doing consulting in Germany, I think they will stay around for quite a while.

robinhoode• 12 years ago

I'm curious if this is comparable to Rails rates.

mwcampbell4• 12 years ago

The article doesn't even recommend Spring, Hibernate, or JBoss; in fact, it specifically recommends against Hibernate. Instead, it recommends Dropwizard, JDBI, and Dagger among others.

oblio2• 12 years ago

Well, he doesn't recommend any of Spring, Hibernate or JBoss, if you read the article. And I think his point was modern _Java_ development.

jebblue8• 12 years ago

Agreed, Java, JDBC, HTML/CSS/JavaScript - this is my preferred stack, simple, linear, understandable, maintainable.

microtonal• 12 years ago

Been there, done that. In the previous company I worked at, some new projects were done in Play. The result: frequent API changes in Play, bad Maven integration, illogical APIs from the Java perspective (an artefact of Play being written in Scala), little documentation, and I don't know how it is now, but back then it was very had to make a minimal REST application without pulling a lot of baggage in.

We rewrote these applications using JAX-RS (RESTEasy) and they were much simpler, easier to maintain, without API breakage in new framework versions. It just a bunch of methods with annotations. XML and JSON serialization is automatic (via JAXB and Jackson). And you can use the same lightweight ORM as Play (Ebean), since it's an external project.

Well-thought out, mature technology is often better for getting work done than the hype of the day.

bsaul• 12 years ago

I've just started using play for the last two weeks, but so far i really don't understand the critics on java vs scala or the documentation. True, so far i've only dealt with json. / db / file upload & download , but even that covers quite a vast area, and it was pretty obvious that every time play had both a simple and documented way of doing those , even in java.

Ironlink• 12 years ago

I'd rather put my money on Spring learning lessons from Play / Scala / Akka. If they don't, the writing may indeed be on the wall.

eropple5• 12 years ago

I don't feel like Spring can fix the core problems here, unfortunately--they're Java Problems, and Java Problems grow more and more acute as time goes on (though Java 8 is a good step in the right direction).

The pleasant, compositional interaction borne of Scala's syntactical flexibility is why Play's wonderful to use (and Akka as the backend is largely behind-the-scenes). I used to be a detractor early in Play2 because of some large-scale-unfriendly decisions, but they've pretty much all been fixed.

pron12• 12 years ago

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.

eropple5• 12 years ago

Would you mind substantiating why asynchronous code, successful in plenty of places and pretty much every new environment you're likely to run into, is so dogmatically the wrong approach?

mark2424• 12 years ago

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 machines.

This is, imho, what makes Play so fantastic. That you can have def index = Action { hardComputation() } for blocking code, and change it to def index = Action.async { Future { hardComputation() } } and you have magically changed your application to be asynchronous through the request-as-actor paradigm of Play. Play makes it easy to write async code. Play makes it way easier to control configuration for things like thread pools, dispatchers, and the like vs. Jetty. The performance of the nonblocking async code is incredible, and winds up saving a ton of money and developer time.

zak_mc_kracken• 12 years ago

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 in my experience, there is really no clear winner. What's especially interesting is that I can find about the same number of positive things to say about the Scala tool stack (Scala/Typesafe platform/Akka/Play) as I can say negative things about each of them. Every time I'm happy about something in the Scala world, I find something I'm not happy with that counter balances it (tooling, slowness of template recompilation, unprovedness of the actor model, Play's arguable step backward in the v2 compared to v1, etc...).

Java is impossibly verbose and has a very limited type system compared to Scala but man... do I develop things quickly with it. There is close to zero friction to get from nothing to something workable, maintainable and fast. And the tooling is top notch, the environment and compilers are super stable, and Java 8 is numbing a lot of the pain I used to feel. In contrast, I feel that I'm often fighting against the Scala compiler whenever I write Scala code. It feels nice in the end to see how concise and neat the code looks compared to Java, but I'm never really convinced the pain was worth it.

So, back to your original point: I've tried (and continue to experiment with) all these "new" technologies that Scala is claiming to bring to the table, and so far, I'm unconvinced that they are a clear improvement over what we currently use in the Java world.

And given that Scala continues to be a marginal language on the JVM, I don't think I'm the only one doubting that Scala represents the future.

jaxytee3• 12 years ago

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.

mark2424• 12 years ago

Don't take my comment as "quit living in the past". Take it as "here's how exciting the future is". I'm not telling you your startac phone is crap, I'm telling you there's this great new thing called the iPhone/Android/smartphone.

The real benefits of Play and Akka become apparent when a third-party service you send API calls to starts acting flaky. Or when your web service that you offer to clients is suddenly being hit by an iPhone game that just got purchased by a million people. Or when that nasty little bug that winds up throwing an exception from time to time rears its head all of a sudden. Play and Akka give you a resilience that is very hard to come by in the Java world.

Typesafe's home page has, in giant type, "Applications are becoming Reactive" and they are absolutely spot f'ing on. Writing blocking code, waiting on threads, assuming you're running on one JVM, these things are great and all, and very easy to do because all of those templates are built into IntelliJ and you just have to click a few buttons to get all that, but wow, the performance difference once you get into the Play world is just frighteningly good.

wtetzner• 12 years ago

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

krishy• 12 years ago

in that you've got your json manipulation, routing, connecting to a database, DI, actors,

While I agree with you about the others 'json manipulation' is not an area that Play can even be compared to Jersey (Jackson). Jersey transparently converts the request body to the required input type whereas with Play you still have to un-marshal the body while taking care of errors (admiddently that can be 'hidden' away using Action composition but still is work that the developer has to worry about). With Jersey its magic that just works.

eranation• 12 years ago

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 it's working great)

More than that, I have mixed Java / Scala projects and it works like a charm (once you configure maven / gradle correctly that is)

The "new" Spring versions are nothing like it used to be. Also the new Java EE ones. no XML configuration files, all convention over configuration. And I sometimes prefer a @GET + @Path or @RequestMapping annotation over concatenating routes with ~ like they have in Spray.

It's just a matter of preference and personal taste, but let's separate the language discussion with the framework / ecosystem discussion, they are not the same.

vorg2• 12 years ago

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.

ww520• 12 years ago

I don't know. I loved Play Framework 1. Simple, lean, and lightning fast development. Play 2 came out and it looked strange, with various Scala things mixed in. It's a lot more complicate and bloated, and more buggy. The core piece is in Scala. The build is now sbt, yet another different thing to maintain. The template is Scala, slow to develop and slow to compile. The much-touted async feature is a meh. Most web apps don't have a high scalable requirement that async would help. If I really need high performance async support, I would go with Vert.x.

Play 1 was almost perfect. Really hope someone would fork Play 1 and continue with it.

metacity• 12 years ago

Personally I have become quite fond of Ninja Framework ( http://www.ninjaframework.org/ ); as simple as Play, but pure-Java (Java 8 too!). Even has a similar hot-reload mechanism as Play!

jebblue8• 12 years ago

Scala, Lisp, Haskell, Smalltalk do not register in my puny brain. C, C++, C# (which I don't EVER do any more), Java, those resonate and make sense to me. Bash and Python too for scripting.

mushishi• 12 years ago

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.

ninjazee124• 12 years ago

Been there, done that. I switched from Java to Scala and Play. Back to Java 8 and Spring MVC and couldn't be happier to be back.

arielweisberg4• 12 years ago

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 matter. That says as much about how expensive common tools and frameworks are as it does about the cost of context switching.

rdtsc3• 12 years ago

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 you the memory block, but until you actually make function calls or allocate data on the stack, it might not consume the memory.

mwcampbell4• 12 years ago

When did Go switch from green threads to real OS threads backing goroutines, and why? Can you at least point to a mailing list post or version control commit?

jrochkind13• 12 years ago

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, heh.

justinsb2• 12 years ago

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?

arielweisberg4• 12 years ago

Deferred allocation of stack pages only buys you so much. Each thread is going to burst usage causing stack space to be committed and once it is committed the memory is gone until the thread is reclaimed.

If you are in a million thread scenario it is usually because most of them are idle and retaining state for some eventual activity. That also tends to mean that they are long lived.

java-lang3• 12 years ago

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.

oblio2• 12 years ago

Isn't Vert.X async a-la Node?

java-lang3• 12 years ago

It is asynchronous event driven like Node but can process events on multiple threads

eip5• 12 years ago

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.

java-lang3• 12 years ago

Hmm, I find it surprising, hasn't been my experience at all.

zmmmmm2• 12 years ago

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).

namelezz• 12 years ago

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' input?

rdtsc3• 12 years ago

Great work Ron.These should be a small (or maybe a full) book some day.

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.

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

http://mostlyerlang.com/2014/05/15/037-parellel-universe-wit...

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.

zinxq3• 12 years ago

You had me until you said Asynchronous I/O is faster than Synchronous I/O in Java.

http://www.mailinator.com/tymaPaulMultithreaded.pdf

pron12• 12 years ago

That's not what I said, or at least not what I meant. If you have blocking operations (that take a long time), then thread-blocking (as opposed to fiber-blocking or async) IO will require too many threads.

zinxq3• 12 years ago

Agreed - for example a (canonical example) chat application (long lived connections, small amounts of data). But that's still not performance, that's then scalability? As in "how many active chat sessions could one server handle?".

The opposite canonical example being a static, small-file web server. Short connections. How many files can you serve per second?

cpprototypes2• 12 years ago

I've heard of Quasar before and had a general idea of what it is, but didn't look at the documentation carefully until now. My understanding is that I can run arbitrary synchronous code in Fibers? For example, consider the MongoDB client library:

  DBObject r = collection.find(query);

It blocks while getting the results of the query. If I do something like this:

  for (int x=0; x < 100000; x++) {
    new Thread(() -> DBObject r = collection.find(query))).start();
  }

it's going to start 100,000 threads and freeze my computer. However, with Fibers I can do:

  for (int x=0; x < 100000; x++) {
    new Fiber(() -> DBObject r = collection.find(query))).start();
  }

and it will work fine since these are lightweight threads (like Go goroutines). I guess my main question is, can I use arbitrary unmodified synchronous code like this to run in Fibers or would the library have to be modified to support it? In this case, would someone have to update MongoDB library to add support for Fibers?

kasey_junk6• 12 years ago

This article comes up every time someone mentions I/O "speed". You have to be very careful with making blanket claims in either direction.

These tests were a particular kind of network traffic, and were testing for max throughput across many connections. Minimizing latency, smaller message sizes, and/or fewer connections can make the decision to use NIO vs standard IO libraries come down in different places. (Not to mention that you cannot program the standard IO libraries in a no alloc form).

alpeb• 12 years ago

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.

lbarrow• 12 years ago

I worked with rvb closely last year and we always used to make fun of him whenever this debate came up. Then one day we realized he had co-authored a paper with Eric Brewer on the topic: https://www.usenix.org/legacy/events/hotos03/tech/full_paper...

xxs3• 12 years ago

It's highly cited "paper" and just as wrong. Blocking I/O is implemented via poll(), NIO is epoll. Blocking IO has to copy the array at last once (on the stack for <64kb, else malloc/free). Most NIO implementations use heap ByteBuffers and multitude of copies which is their downfall.

Blocking IO cannot have predictable latency under load at very least, you are left at the mercy of OS thread scheduler. Due to various reasons (e.g. mutator threads should not block GC and compiler ones) thread priorities are honored.

I'd argue that a well written NIO (and virtually there are no good open source NIO impl) will beat flat out any blocking. NIO is both faster and offers better/predictable latency under load.

MrBuddyCasino2• 12 years ago

Ok, now I'm curious: what is a good implementation? Also, whats wrong with ByteBuffers? I was under the impression that they are usually memory-mapped and should be 0-copy.

haddr3• 12 years ago

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.

jebblue8• 12 years ago

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.

twic4• 12 years ago

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.

zinxq3• 12 years ago

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. "wrong approach")

pron12• 12 years ago

I've been misunderstood. I have not commented at all about whether sync or async IO is better. I meant that if you have a long operation that blocks for a while, letting it consume a kernel thread is bad.

jaxytee3• 12 years ago

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.

jeremyjh• 12 years ago

Have you used a STM?

simpsond• 12 years ago

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

phillmv4• 12 years ago

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.

kasey_junk6• 12 years ago

As opposed to?

phillmv4• 12 years ago

Well… checkout Flask, for instance:

  from flask import Flask
  app = Flask(__name__)

  @app.route('/')
  def hello_world():
    return 'Hello World!'

  if __name__ == '__main__':
    app.run()

Of course, you still need to know how Python Does Things, and The Thousand Ways To Deploy An App, and Package Management and so on, but for this trivial example it's a lot more conceptually lean than the semi-equivalent offered above. I don't need to know about `Bootstrap<Configuration>` or a `JModernConfiguration`.

It's fair to point out that there will be a corresponding text file or option somewhere else, but…

jbooth• 12 years ago

If all you need is to get a minimal set of code handling HTTP requests, plain servlets aren't much bigger or more complex than most web microframeworks. "Here's your request and response objects, handle it."

rch4• 12 years ago

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.

eropple5• 12 years ago

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's Anorm/Slick have given me enough of the "there's a better way" to make going back really unpalatable.

jebblue8• 12 years ago

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.

jrochkind13• 12 years ago

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 cases and use cases that someone had that seemed reasonable after all, before you know it, it's a monster again.

To get off the ground with Rails 3/4, you sure need to know a lot. That wasn't neccesarily true in Rails 1/2 when some of us got started, and we were able to learn the new stuff gradually as it was added in, but to get started from scratch, let's say you don't even know ruby very well, oy, it's a lot now.

jksmith• 12 years ago

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.

AnimalMuppet• 12 years ago

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.

jebblue8• 12 years ago

That's because, after getting into the air you will be bought and then you will find out that you wish you had started with solid technologies and architectures.

jebblue8• 12 years ago

Could the person or persons who downvoted my comment explain why or what you disagree with here?

DCKing2• 12 years ago

It'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't possible.

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.

thescrewdriver2• 12 years ago

but my productivity and general joy in programming shot through the roof when I started using Scala.

That was exactly my experience. Maintaining Java code from time to time makes me realise just how big the difference is.

moondowner• 12 years ago

You can actually make a good Spring MVC-based webapp (with Thymeleaf, AngularJS and etc.); check out the JHipster Yeoman generator: https://jhipster.github.io/

DCKing2• 12 years ago

Man, I wish that would have existed 2 years ago.

elchief3• 12 years ago

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

elchief3• 12 years ago

I ask because with Spring Data REST, you don't

logn• 12 years ago

For static resources you can load them like this:

    public class WebAppConfig extends ResourceConfig {
      private final String[] mimeTypes;
    
      public WebAppConfig() throws IOException {
        //load static resource from htdocs dir
        Collection<File> files = FileUtils.listFiles(new File("./htdocs"), null, true);
        ArrayList<String> mimeTypeList = new ArrayList<String>();
        for (File file : files) {
          final byte[] contents = FileUtils.readFileToByteArray(file);
          Resource.Builder resourceBuilder = Resource.builder();
          resourceBuilder.path(file.getAbsolutePath().split("/htdocs/")[1]);
          final ResourceMethod.Builder methodBuilder = resourceBuilder.addMethod("GET");
          String mimeType = Files.probeContentType(Paths.get(file.toURI()));
          if (!mimeTypeList.contains(mimeType)) {
            mimeTypeList.add(mimeType);
          }
          methodBuilder.produces(mimeType)
              .handledBy(new Inflector<ContainerRequestContext, byte[]>() {
                @Override
                public byte[] apply(ContainerRequestContext req) {
                  return contents;
                }
              });
          registerResources(resourceBuilder.build());
        }
         
        //load dynamic resources implementing interface Webpage
        register(MultiPartFeature.class);
        Reflections reflections = new Reflections(new ConfigurationBuilder()
            .setUrls(ClasspathHelper.forJavaClassPath())
            .filterInputsBy(new FilterBuilder().include(FilterBuilder.prefix("com.example.mycompany"))));
        Set<Class<? extends Webpage>> webpageClasses = reflections.getSubTypesOf(Webpage.class);
        for (Class<? extends Webpage> webpageClass : webpageClasses) {
          registerResources(Resource.builder(webpageClass).build());
        }
        mimeTypes = mimeTypeList.toArray(new String[0]);
      }
    
      public String[] mimeTypes() {
        return mimeTypes;
      }
    }
    ...

      public synchronized void start() throws Exception {
        WebAppConfig config = new WebAppConfig();
        HttpServer httpServer =
            GrizzlyHttpServerFactory.createHttpServer(URL, config, false);
        CompressionConfig compressionConfig =
            httpServer.getListener("grizzly").getCompressionConfig();
        compressionConfig.setCompressionMode(CompressionConfig.CompressionMode.ON);
        compressionConfig.setCompressionMinSize(1);
        compressionConfig.setCompressableMimeTypes(config.mimeTypes());
        httpServer.start();
        wait();
      }

elchief3• 12 years ago

Thanks, but I was referring to say a dynamic database-backed resource.

With SDR, you have an @Entity, and a @Repository for that entity, and SDR handles the whole HTTP part, i.e. you don't need to write a @Controller to expose the repository.

Just wondering if Jersey has anything similar.

rch4• 12 years ago

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

dafnap• 12 years ago

of course, email us at info@paralleluniverse.co - thanks!

runT1ME4• 12 years ago

How does asynchronous futures end up being more complicated or in any way worse than the blocking threaded approach?

    for { 
       user       <- asyncGetUser(1)
       company    <- asyncGeCompany(user.companyid)
       longresult <- asyncProcess(company.getSomething)
    } yield longresult

saryant4• 12 years ago

His issue seems to be the potential for modifying or referencing mutable state where in the yield block (or map or flatMap or whatever).

It can be a problem. In Akka actors, referencing sender() from a future will be unpredictable because sender() could've changed in the mean time.

I think there are three strong solutions which address this problem:

1) Immutable state. Solves this problem completely but accidental capture remains an issue.

2) Hiding mutable state within actors. I hesitate to present this as a general solution though since it really requires going all-in with actors (I don't consider that to be a bad thing, necessarily).

3) Projects like Scala Spores [1] aim to tackle this at the compiler by capturing mutable references and executing async closures in an immutable environment and prohibiting accidental capturing. IOW, turning accidental capture into a compiler error. I'm excited about this one.

[1] https://speakerdeck.com/heathermiller/spores-distributable-f...

runT1ME4• 12 years ago

You can (and should) use Futures independently of Akka actors. You're correct, hidden mutable state with Actors can be a problem, as with mutable state in general.

pron12• 12 years ago

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 threads, they are always preferred (even Scala now has its own poor-man's lightweight threads in the form of async/await).

runT1ME4• 12 years ago

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 ThreadLocal variables).

Threadlocal variables are almost always code smell. If you find yourself using them, there is almost certainly a better way of accomplishing the same thing.

I don't see how having a Fork/Join threadpool that 'powers' the futures would be any slower than lightweight threads either.

tristanperry• 12 years ago

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 Spring MVC and Hibernate.

Also Spring Boot does bring quite a lot of support for REST, via RestTemplate/RestOperations, along with support for consuming and producing JSON and/or XML at the controller levels.

* Edit: I say re-considering since the article only briefly mentions it.

smoyer• 12 years ago

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!

hibikir• 12 years ago

I am especially fond of his view on database layers. There'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.

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.

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

mahmud• 12 years ago

Again, just use jOOQ. It's beautiful executed design, written by smart people.

http://www.jooq.org/

I never cared for the library until I realized I'm spending a lot of time on the developer's blog; he is prolific and very knowledgeable about everything database and java. Was sold on it soon after.

huherto• 12 years ago

That is precisely why I created this little project. It generates the boiler plate code to leverage jdbcTemplate and organize the data access objects.

http://huherto.github.io/springyRecords/goals/

Also, this fellow HNer has been experimenting with Java 8 features. Pretty cool. https://github.com/benjiman/benjiql

boobsbr• 12 years ago

I think myBatis does something similar, abstracts JDBC and lets you write SQL easily.

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

Related Stories