[phillmv]

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.

[jrochkind1]

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

[AnimalMuppet]

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.

[jksmith]

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.

[Consultant32452]

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

[jbooth]

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

[rch]

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.

[eropple]

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.

[rch]

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.

[eropple]

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.

[jebblue]

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.

[rch]

Looks really slick. Thanks!

[jebblue]

Welcome but the guy who invented it, Per Wendel and those who help him maintain it are the ones who deserve the credit. If you're into Lambda's (I'm not yet but trying to bend my mind to want to use them), he's working on adding them for version 2 which should make it even simpler.

[chillax]

Version 2 was released some days ago :-)

[jebblue]

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.

[jebblue]

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

[kasey_junk]

As opposed to?

[phillmv]

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…

[kasey_junk]

import static spark.Spark.*;

public class HelloWorld { public static void main(String[] args) {

      get("/hello", (request, response) -> {
         return "Hello World!";
      });
   
   }
}

[phillmv]

Like I said above, "Granted, this may be easier with newer frameworks, but still." :). Good to see it's you can have some lighter loads.

TFA mentioned this was how Modern Java Web Dev With Instrumentation is Done (worth mentioning that Javaland instrumentation is world class), so just going by the examples he provided.

[kasey_junk]

I think that is more a difference in which frameworks you use as opposed to which language. The examples in the article are using individual components to build out the system. This provides unlimited flexibility and will be very valuable if the system is going to scale in complexity.

My example on the other hand uses Spark, a micro framework that is not very flexible and hides a lot of the complexity, meaning that if your own solution becomes more complex you may have to abandon Spark entirely.

I've seen that dichotomy in every web framework I've encountered.

[phillmv]

>I think that is more a difference in which frameworks you use as opposed to which language.

I don't think it has much to do with which language per se but more to do with what the language community considers acceptable. You can write mostly head-ache free frameworks filled with "magic" in Java like the rest of them, but it's not a strong cultural value.

To turn to the microframeworks example, I can't speak to Spark but in Ruby land it is not hard to flesh out your sinatra app into a more complex beast should the need arise - converting Sinatra half way to a mini Rails is not something I would recommend, but mostly because you lose easy-library support and ease-of-update down the road (you shouldn't be writing your own custom framework period, sort of thing), and not necessarily because of a lack of flexibility.

[bloat]

That's not much different here to the hello world in the article. Lets see...

You import some stuff... check. You create an instance... check. You define a route... check. You define a method to implement the route... check. You return a String... well the example returns a map, and converts it to JSON. You start the app in a main method... check.

Sure the java is a little more wordy and there are some extra params which are not used (the IDE would fill those in automatically when you implement the interface), but the complexity is the just same as far as I can see.

[trengrj]

Got to include ruby!

  require 'sinatra'
  
  get '/' do
    "Hello World!"
  end

[bhauer]

Looking past shorter syntax and names, and a bit of magic to intuit the response content type, that's not a whole lot different from the code that gets Undertow spun up [1]. I suppose if you're worried about syntax and short names, Java is not right for you.

[1] http://undertow.io/