Ask HN: Java FUD
So I go over to Java land, and the feeling is that I need to, to get things running, get to know about Tomcat, Hibernate, Maven and JBoss just to get started.
Now, having used Python+Django, I use to favor simpler solutions over complex ones.
What do you advise me to do? Is this just FUD? Should I try a non-EE Java solution (Lightweight java?), or just embrace the 3-letter acronyms?
[+] [-] mgkimsal|15 years ago|reply
You will need to know Java/Groovy. Groovy can be considered a superset of Java (not 100% technically true, but easy enough to think of that way to get started).
> grails run-app
will run grails in dev mode on its own tomcat.
> grails prod run-app
will run grails in production mode on its own tomcat.
You can proxy Apache on port 80 to the tomcat port (default 8080).
Grails uses Hibernate under the hood, but hides it pretty darn well - you generally won't need to know much about it, or even touch any XML config files - to get started.
You can slowly add more Java libraries as required.
http://www.grails.org/plugin/jaxrs - this is a JAX-RS plugin for Grails which lets you use Jersey as the implementation if you want to ("At the moment, plugin users may choose between Jersey and Restlet as JAX-RS implementations").
The "Play!" framework might be interesting to you too, if you already know some Java, but I prefer Grails overall.
[+] [-] HowardRoark|15 years ago|reply
[+] [-] cscotta|15 years ago|reply
I've somehow become a bit of a devil's advocate for Java lately. Thanks for pinging me - happy to offer a few thoughts.
I've not actually tried using Jersey/JAX, but it looks like a very clean setup for quickly writing low-latency JSON APIs. I'm impressed by the Getting Started example (here: https://jersey.dev.java.net/use/getting-started.html) and find the use of decorators to specify path, methods, and content types creative.
As for the rest, keep in mind that you don't have to use anything that you don't want to. I've done a fair amount of Java development and never actually used Hibernate, Maven, or JBoss. For the most part, the complexity that these tools can introduce, while great for many projects, kind of scares the crap out of me. Like you, I'd always go for the simplest workable solution available.
Jetty is a very nice, simple alternative to Tomcat/JBoss, though I find Tomcat to be rather nice myself. One thing I've come to love about Java deployment is that you're literally deploying just one file (a .jar or .war) rather than hundreds.
If you're looking for a nice, clean ORM, check out ActiveObjects by @djspiewak. Its design is based on the active record pattern, and it's very easy to get up and running with about any database as a backend. I used this on a large project ending a few months ago and had a great experience with it. Daniel's also available via Twitter and IRC and tends to be happy to offer an answer to a quick, informed question. Here's the post he introduced it with (http://www.codecommit.com/blog/java/an-easier-java-orm), and here's the project page. (https://activeobjects.dev.java.net/). I'd also strongly recommend checking out these docs he put together: https://activeobjects.dev.java.net/ActiveObjects.pdf
I really love the "static files + AJAX" approach that you've suggested (it's actually the same one mentioned in the project I referred to above). If you were to build something with Jersey and ActiveObjects, perhaps with a small caching layer in between (either an in-app cache if you'll only have one app server, or memcached), you will have produced a screaming API for your application.
The Play framework (mentioned below) is also very good, and has emerging support for Scala, which I and many others find to be much cleaner and more expressive than the equivalent Java. If you're feeling adventurous, I whipped together a quick little framework for building zippy JSON APIs and simple frontends via a lightweight wrapper around the servlet API. It's called Miso. Here's the info on that (and do ping me if you feel like playing with this - I may have a more recent version): [http://blog.paradoxica.net/post/401365886/hello-miso]. See here for docs, and especially page 6, which shows what a sample controller / API endpoint looks like: http://u.phoreo.com/gx.pdf
Of course, this also depends on whether you actually need that, and how much experience (or desire to learn) you have. If you're comfortable with Python, something like Flask or Piston might be more appropriate. At the same time, I would suggest that those who say that '"x language" or "y framework" makes developers infinitely more productive' aren't offering terribly productive advice, as I find myself about equally productive in Java, Scala, Python, and Ruby, and often opt for Scala or Java unless I'm hammering out something quick and imprecise. That is to say, it's definitely a matter of preference. So, choose what you think will make you most productive, or, choose to learn something new which might be a bit difficult at first, but will also teach you a lot about statically-typed languages and could potentially meet the needs of your application with far fewer resources and lower latency on the server-side for years to come.
Regardless of which path you choose, feel free to hit me up with any questions along the way.
[+] [-] kls|15 years ago|reply
I was a very early adopter of Jersey and JAX-RS and I have to say, it is one of the first API's that I have seen come out of Java that provides the rapid development and prototyping typical of Ruby or Python. If future Java API's take their queue from JAX-RS then Java will again become competitive. I trained a guy just last week on JAX-RS and had him up and running in less that a day. Only truly elegant designs can provide that level of simplicity while exposing the ability to accomplish the task you want without having to make compromises. JAX-RS is a gem in the Java world and I hope that future Java API's will follow suite.
As well Netbeans tooling for JAX-RS goes a long way to reduce development time. You can write a JPA annotated class and Netbeans will gen the schema as well as the REST service. Or you can write the schema and Netbeans will gen the JPA class and the service. While I am generally not a fan of reliance on tooling this is a case where it helps without pooping all over your code.