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

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.

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.

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

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

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.

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.

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

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.

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!

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.

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

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

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.

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

It's a questionable framework mashed together with a poorly though out messaging system.

I would rather use Spring Integration, Quasar, or Akka.

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

    user = getUser(1)
    company = getCompany(user.companyId)
    longresult = process(company.getSomething)

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

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.

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.

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

    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();
      }