8 ms·

The Modern Java Ecosystem (for the Sinatra or web.py lover)

127 points by smanek 15y ago

rbanffy 15y ago
In general, the code is still impressively verbose. OTOH, it's incredibly short for Java code. I suspect that line/feature added count will increase more quickly than it would with Python or Ruby and it will quickly become a nightmare scenario indistinguishable from a more traditional Java web approach.
- smanek 15y ago
  How would these be any shorter in Python or Ruby? @GET public Collection<Integer> listStudentIds() { return STUDENTS.keySet(); } or @DELETE @Path("{uid: [0-9]+}") public boolean deleteStudent(@PathParam("uid") int uid) { final Student deletedStudent = STUDENTS.remove(uid); if (deletedStudent == null) { throw new WebApplicationException(Response.Status.NOT_FOUND); } else { return true; } } I'll grant that Java programs often become more verbose than their Python/Ruby counterparts - but I would argue that trait can be held to a minimum with the proper libraries and coding style.
  - roestava 15y ago
    With Ruby folks can always try to remove redundancy. :-) I find it amazing that "DRY" has become such a positive pattern when it was touted as one of the driving points of the Ruby on Rails framework. Don't repeat yourself. For instance, Java folks are always ready to throw exceptions instead of letting stuff resolve itself if it doesn't quite work.
    - smanek 15y ago
      In that example I only throw an exception when you try to delete a student who doesn't exist. The reason I do so is that it contains semantic information which is useful for the client. If I returned a fake value - the client would get a 200 response on his attempt to delete a non-existent resource, which is clearly the incorrect behavior. I could return nothing - but then the client would see a 204. So, I choose to throw an exception with a response 'NOT_FOUND' throw new WebApplicationException(Response.Status.NOT_FOUND); so that the client gets a 404 response.
      - hello_moto 15y ago
        Yes, this is only an example. There are a few things I'd like to point out to add to this example: 1) JAX-RS is still new. In the future, they might improve the exception handling or whatnot (so if you return null, they might decided to return 404 ... who knows) 2) We can always wrap all JAX-RS with a Filter. So you can throw JPA level exception (not found) and let the filter catch it and convert it to WebApplicationException(404). Thus in theory, your JAX-RS implementation won't have any RuntimeException explicitly in the code.
      - beamso 15y ago
        I did try and build your code to run the test (I've no idea where the CsvParam and DateParam classes come from) but I think that the following will give you what you want without throwing the exception. @DELETE @Path("{uid: [0-9]+}") public Response deleteStudent(@PathParam("uid") int uid) { final Student deletedStudent = STUDENTS.remove(uid); if (deletedStudent == null) { return Response.status(Response.Status.NOT_FOUND).build(); } else { return Response.ok().entity(true).build(); } }
        smanek 15y ago
        Ah, I see what you mean - thanks! The full (buildable) source code - including the CsvParam and DateParam classes - are here: https://github.com/smanek/students https://github.com/smanek/students
  - waffle_ss 15y ago
    In Ruby, everything evaluates to true except false and nil. Also, the last statement executed is your return value. Therefore your first function could be written as def delete_student(uid) STUDENTS.remove(uid) || raise WebApplicationException.new(Response.Status.NOT_FOUND) end
    - pacala 15y ago
      I have no idea what the annotations mean, but if we use exceptions for transmitting error conditions, then there is no point having a true | exception function. public void deleteStudent(int uid) { if (STUDENTS.remove(uid) == null) { throw new WebApplicationException(Response.Status.NOT_FOUND); } }
    - smanek 15y ago
      I love it! And that is the reason I still write in Python or Lisp when I don't need something (Hadoop, Lucene, etc) from the JVM ;-)
      - jblomo 15y ago
        If you need something from the JVM and want to write Lisp, use Clojure. Checkout Hadoop extensions in Clojure at https://github.com/jblomo/oddjob https://github.com/jblomo/oddjob .
    - mbell 15y ago
      I seem to remember this same feature causing lots of headache in C in the form of subtle bugs mostly the result of this being used in awkward ways. Personally I'd rather have a distinct boolean value to test for, the java version is much more explicit as to exactly what its doing.
      - waffle_ss 15y ago
        Hmm can't say I've ever encountered something like that in Ruby so far. However, if you want a strict boolean it's pretty easy to get: !!STUDENTS.remove(uid)
  - masklinn 15y ago
    First example, Python (keeping a similar API): list_student_ids = get(STUDENTS.keys) # [0] second example, Python: @delete @path(r'{uid: [0-9]+}') def delete_student(uid): if STUDENTS.pop(uid, None): # [0] return True raise WebApplicationException(Response.Status.NOT_FOUND) the last line generally wouldn't be this complex, in Flask you'd just call `flask.abort(404)` (which can be used inline with an `or`, as with waffle_ss's ruby example, but that's not usual/good Python style), in Django it'd be `raise Http404()`. Although in Django you'd really use the `get_object_or_404` shortcut for ORM objects: def delete_student(uid): get_object_or_404(StudentModel, pk=uid).delete() return True And you wouldn't bother with the return since a 200 result would mean the deletion was correctly executed. [0] Used Python's MutableMapping API here, it works slightly differently than Java's equivalent Map interface: `.keys()` returns a sequence of the mapping's keys and `.pop()` asks for a default value to return in case nothing was found there, otherwise it raises `KeyError` if the key was not found)
    - masklinn 15y ago
      An other note: the @path decorator would probably use named groups instead of some sort of DSL, so r'(?P<uid>[0-9]+)' (the `r` prefix is for `r`awstring, so the developer does not have to string-escape each backslash used in the regex among other things)
  - jeltz 15y ago
    You could make it shorter by using something like sinatra[1]. Here is my pseudo-sinatra code. get "/list_student_ids" do STUDENTS.key_set end delete "/delete_student/:uid" do STUDENTS.remove(params[:uid]) or raise WebApplicationException, Response::Status::NOT_FOUND true end 1. http://www.sinatrarb.com/ http://www.sinatrarb.com/
    - nupark2 15y ago
      Your savings here are mainly from removing types. That's another matter entirely.
      - jeltz 15y ago
        I would say they are mainly from removing the need for decorators due to there being a nice lambda function/block syntax. So we can define methods like "get" and "delete" which does the job of the decorators, creating something kind of like a mini-DSL. Some savings through the removal of types, sure, but that is not what I personally see as most import here.
      - masklinn 15y ago
        1. Thing's most of those types provide no value in being spelled out like that. The ones on the methods have documentary advantages, but that's about it, the rest is magical invocations to make a stupid compiler happy. 2. There's also a gain from the framework being able to map things to each other without being told explicitly. `@PathParam("uid")` for instance, it's only there because the framework has no way to match the parameter name `uid` to the URL-extracted parameter `uid`. Likewise with HTTP methods being part of the routing instead of a separate annotation, in part. 3. Java's APIs and type system, such as implicit nulls and not being able to use arbitrary types in boolean contexts
- mbell 15y ago
  It may be slightly more verbose but you have to consider that the Java variant contains much more information in a single location. For example having a single file with methods annotated with @GET or @POST is so much cleaner to me than having routes.rb open in another editor window constantly Ctrl-Fing through it to sort out whats going on.
  - hello_moto 15y ago
    I think that's a matter of preference. I don't mind both styles (after working with Spring MVC 3, Servlet 3, JAX-RS, and Rails)
  - masklinn 15y ago
    > For example having a single file with methods annotated with @GET or @POST is so much cleaner to me than having routes.rb open in another editor window URL mapping is a framework detail, not a language detail — although the framework can be limited by the language. In Sinatra you'd write: get 'someroute' do # do stuff end http://www.sinatrarb.com/intro.html#Routes http://www.sinatrarb.com/intro.html#Routes each style (these and half a dozen others) has its advantages and inconvenients. For instance, separate urls mapping (Rails, Django) give a starting point laying out the structure of the site and make views/controllers easier to reuse (as they're not coupled to URLs)[0], whereas annotating the handler directly gives a better view of where they're involved and how. [0] They also make it simpler to "graft" sub-sites in
- kreek 15y ago
  I've written large Rails and Sinatra apps, as well as a couple Spring apps and straight Java apps. I"m evaluating Play now and even though I usually prefer Ruby to Java, I'm finding Play (with Eclipse configured to be Textmate like) as productive, if not more so, than Rails.
andrewl-hn 15y ago
We use JAX-RS as a primary web framework in our current project and honestly I can't get happier! We use Guava for low-level basic stuff and Google GSON for JSON serialization. It seems to be on par with Jackson from ease-of-use point of view: MyType myVar = gson.fromJson(jsonString); JPA on a back, some basic IoC in the middle (nothing fancy). Mockito and jUnit for tests. All in all it's just a bunch of small layered classes with some bits of annotations and no xml. Well, one web.xml file with single servlet declaration for JAX-RS :) With good IDE (they all are great this days), Maven for dependencies, well-known practices and modern APIs Java isn't that scary or cumbersome anymore. It's just a nice small language. A bit verbose without closures and type inference but still Ok. I should note, though, that we generally use our Java layer as a service provider. We keep main bits of logic on a client side in JavaScript and call Java either for transactions and data, or in cases when something is hard to do on a client. It's just easier that way.
- hello_moto 15y ago
  Be careful with GSON. It by-passes your getter and setter. That alone creates a bit of mismatch because JAXB (which is used by JAX-RS) uses getter/setter by default unless you specified it otherwise. And sometime you do have some logic in your getter/setter for validation or other purposes. I got bitten by this before while it seems like a small thing it's actually a bit problematic. If you're using JPA2, take a look at Spring-Data (formerly Hades). Spring-Data helps you to reduce JPA boilerplate code. The way Spring-Data works is by using a convention: specify your NamedQuery and a Java interface with method name == NamedQuery name. Then magic suddenly happens.
- ww520 15y ago
  I found Jackson is better than GSON at deserializing nested standard object graph automatically. GSON needs me to define all the nested structures.
scorchin 15y ago
For those looking for something more like Sinatra in Java, check out webbit: https://github.com/joewalnes/webbit https://github.com/joewalnes/webbit Here's an example of a simple Websocket chat server: https://gist.github.com/1421652 https://gist.github.com/1421652 Disclaimer: It's an open source project that I have some commits to
- logn 15y ago
  >Disclaimer: It's an open source project that I have some commits to Is that like a 'full disclosure' notice or are we supposed to be terrified of your code?
- simpsond 15y ago
  Webbit looks much more like embedded Jetty and plain servlets than Sinatra. If you really want something like Sinatra in you Java project, wire in Scala and try Scalatra.
hello_moto 15y ago
I'd like to add a few things here. Jersey is an implementation of JAX-RS. It has 3 major pieces: jersey-core, jersey-client, jersey-server. (The name should be obvious what they are for). If you're writing JAX-RS services, you can return a few different formats: XML, JSON, ATOM. All you need to do is to annotate the method with the following annotation: // will return XML or JSON depending on the request from the client. @Produces({ MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON }) This is a big win if you need to support both. - Object to XML conversion is done by JAXB. - Object to JSON conversion is done by Jackson via JAXB. Jersey is part of JavaEE 6 standard (part of your Application Server if it supports it). What's lacking from JavaEE 6 is an MVC framework which is targeted for JavaEE 7. Another key feature is JAX-WS (the plain old SOAP WebService). The nice thing about JavaEE 6 is that the minimum differences in the programming style between JAX-RS and JAX-WS. JAX-RS operates according to resources (e.g.: give me all students, give me student with id=1, delete student with id=1, etc). So some of the examples would be: // Rough pseudo-code, omitting a few JAX-RS annotation public class StudentResource{ @Produces({ MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON }) public <List> all(){} @Produces({ MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON }) public Student get(long id){} } JAX-WS operates according to services (e.g.: initiateInvoiceWorkflow, performPayment, etc). public interface AccountingService{ @WebMethod(operationName="initiateInvoiceWorkflow" ...) Invoice initiateInvoiceWorkFlow(); } // have your implementation... So in theory, you can have something that's called StudentRepository where you can use that repository with both JAX-RS (REST) and JAX-WS (WebService) implementation easily (I've done this and it's quite straightforward) if your "Enterprise client" forces you to do so. The important bit here is testing. You can easily test both JAX-RS and JAX-WS implementation in both unit-test or integration-test. You can easily do unit-test because you don't need to deploy them to the server: they're just normal Java classes. You can do integration test by deploying them to the server and generates the client implementation (in which I'll cover next). The client-side implementation of JAX-RS is also similar to that of JAX-WS programming style. In JAX-WS, you grab a WSDL, throw it to a generator tool that comes with JDK to generate the model (Invoice, Student, etc) and the proxy client-side to call the server-side. Very very straightforward, 5 minute job. In JAX-RS, you'd use jersey-client to perform HTTP call as follow: // url => is a string that points to JAX-RS end-point e.g.: student/1 // header => json? xml? atom? // type => (typeof Student) (well... it's Java). Student student = Client.create().resource(url).accept(header).get(type); Keep in mind that in the client-side, your Student class must have roughly the same structure and must be annotated using JAXB XML annotation (the client-side also relies on JAXB -> Jackson -> Java object conversion for the case of JSON, or just JAXB -> JAva object for the case of XML). So no hacking using XPath or something like that (I work in Ruby once in a while and when I read some of the 3rd-party libraries/gems that implement client-side API against popular service provider, most of the implementations do brute force using XPath querying node element and stuff). PS: Excuse me for the poor formatting, where can I learn to format my comment? UPDATE: fix the format. Oh and one more thing: JAX-RS (Jersey) is just an implementation on top of Servlet. So all of your previous knowledge regarding to Servlet (Context, deployment, URL, Filter) will be definitely useful.
jshen 15y ago
I'm not a big fan of the heavy use of annotations. When an annotation does something other than what I expected it becomes a pain in the butt to figure out why. Also, back in the day, jersey and guice didn't get along because their use of annotations on the same methods conflicted because they both wanted to drive the bus so to speak. This has been resolved, but it left a bad taste in my mouth because there isn't a good solution other than waiting for them to fix it.
- latchkey 15y ago
  Annotations are a huge and important part of Java.
  - jshen 15y ago
    and I pointed out the headaches they caused me. I'm not really sure what point you are trying to make.
    - latchkey 15y ago
      Conflicts in any piece of software are a pain in the butt. That is part of software development though. You say you aren't a big fan of 'heavy use of annotations' but you don't qualify what 'heavy' is so I am guessing that it is pretty much all annotations. How do you make your determination of what annotations are 'ok' and what annotations aren't? Or do you say something like 'oh, I won't use that annotation because it might blow up on me at some later date'? What is your mental process there? Is @GET good or is @POST bad? What about @Inject or @JsonProperty? The 'annotations leave a bad taste in my mouth' statement seems kind of odd to me. Generally, a language feature isn't something that I'm careful about avoiding. I could see making a statement like "I tried to use software product XYZ and it was so full of bugs that I switched to software product ABC." But annotations aren't a software product, they are a language feature that products can take advantage of. It just happens to be that two products you were using had conflicting annotations. No big deal, you still have choices as you can just swap out products. That in itself doesn't make the functionality that annotations provide taste bad. I've met people who have had this view of annotations as being some magical creature. They didn't understand them or how they worked at all. They stuck it in their heads that 'annotations are bad', so we aren't going to use them and aren't going to even bother learning how they might help us. Everything was very black and white. I found this behavior really odd because everything in software development is grey.
mattmiller 15y ago
This is very cool. I am tied to Java b/c of Lucene and the Hadoop ecosystem as well. Some more things I would like to see: -Templating. Something like SimpleTemplate Engine in Bottlepy. http://bottlepy.org/docs/dev/stpl.html http://bottlepy.org/docs/dev/stpl.html -How do I get rid of Tomcat at least for development. I would like to run java -jar MyApp.jar -Dport=8080 and get a live running webapp in my dev environment.
- smanek 15y ago
  Take a look at Jetty (http://www.eclipse.org/jetty/ http://www.eclipse.org/jetty/) for the second option. I tend to use 'mvn tomcat:run' to run my dev server, which I find even easier, fwiw.
- latchkey 15y ago
  I've been using a very little know (and poorly named) template engine called Cambridge Template Engine (http://code.google.com/p/cambridge/ http://code.google.com/p/cambridge/) for my latest company. The documentation is a bit thin, but the code is rock solid and very fast. Combined with JEXL for an expression language, this is one of the best server side engines I've ever used.
- masklinn 15y ago
  > How do I get rid of Tomcat at least for development. Jetty everything. You can even keep it for production.
- benmccann 15y ago
  You can do "java -jar MyApp.jar -Dport=8080" with both Tomcat and Jetty using what they call "embedded mode". I like the Jetty embedded mode much more because it starts up so much faster. The Tomcat embedded mode does have the benefit of an easier to understand API, but it's not worth the speed trade-off for me. Here's examples of both: http://www.benmccann.com/dev-blog/embedded-jetty/ http://www.benmccann.com/dev-blog/embedded-jetty/ http://www.benmccann.com/dev-blog/embedded-tomcat/ http://www.benmccann.com/dev-blog/embedded-tomcat/ I put together an example and uploaded it to GitHub. I'd love feedback on it: https://github.com/benmccann/sprightly https://github.com/benmccann/sprightly P.S. Closure templates are cool because they can be used both client-side and server-side. I'm not aware of other templating languages that have this feature. I haven't used it much yet, but want to experiment with it more when I get time.
ww520 15y ago
For web, Play Framework and Japid template are very good. For distributed clustering, Hazelcast is amazingly good. For massively scalable network services, Netty does a fantastic job.
- latchkey 15y ago
  I'd never heard of Japid before. Thanks for pointing it out. That said, using a backtick character like that seems like a really error prone approach. Definitely not my cup of tea.
  - ww520 15y ago
    That's what I thought as well when I first saw the backtick, but after using it for a while I found it to be perfect. It's rarely used in any other context (besides Lisp). It's really unobtrude, making the rest of the code standing out. It's at an easy to remember place at the keyboard. The parser is good enough to catch any quote or backquote mistakes. It's really an non-issue and you forget about it after a while. A sample, <ul> ` for (a : list) <li>$a ` </ul>
- chaostheory 15y ago
  Since we're on the subject of Play, I'm going to add Akka to this list. In my experience, programming for concurrency (and even distributed concurrency) is just way more enjoyable using Akka.
icandoitbetter 15y ago
>Javascript (which is basically just a Lisp with infix syntax ;-)) No, it's not.
- roryokane 15y ago
  To elaborate, JavaScript doesn’t support macros, which allow arbitrarily powerful semantic abstraction. And JavaScript does not have a regular syntax, so even if it did have macros, you would have to special-case each type of syntax (curly braces, statements, post-++ operators within lines) and handle them specifically. First-class functions and closures do not a Lisp make.
swah 15y ago
But Play 2.0 is moving away from Java Servlets, IIRC... how do the modern solutions compare in that regard?
- mahmud 15y ago
  Play 1.x is NOT based on Java Servlets. No version of Play ever was, never will be. From the BDFL himself: http://iam.guillaume.bort.fr/post/558830013/why-there-is-no-servlets-in-play http://iam.guillaume.bort.fr/post/558830013/why-there-is-no-...
zmmmmm 15y ago
For me, the modern Java ecosystem is more about a sweet combination of groovy at the edges with a minimalist Java core. it seems to be the best combo of static and dynamic typing and capture a lot of the best of both worlds without buying into too much religion or "enterprise" type complexity.

127 points by smanek 15y ago

In general, the code is still impressively verbose. OTOH, it's incredibly short for Java code. I suspect that line/feature added count will increase more quickly than it would with Python or Ruby and it will quickly become a nightmare scenario indistinguishable from a more traditional Java web approach.

smanek 15y ago
How would these be any shorter in Python or Ruby? @GET public Collection<Integer> listStudentIds() { return STUDENTS.keySet(); } or @DELETE @Path("{uid: [0-9]+}") public boolean deleteStudent(@PathParam("uid") int uid) { final Student deletedStudent = STUDENTS.remove(uid); if (deletedStudent == null) { throw new WebApplicationException(Response.Status.NOT_FOUND); } else { return true; } } I'll grant that Java programs often become more verbose than their Python/Ruby counterparts - but I would argue that trait can be held to a minimum with the proper libraries and coding style.
- roestava 15y ago
  With Ruby folks can always try to remove redundancy. :-) I find it amazing that "DRY" has become such a positive pattern when it was touted as one of the driving points of the Ruby on Rails framework. Don't repeat yourself. For instance, Java folks are always ready to throw exceptions instead of letting stuff resolve itself if it doesn't quite work.
  - smanek 15y ago
    In that example I only throw an exception when you try to delete a student who doesn't exist. The reason I do so is that it contains semantic information which is useful for the client. If I returned a fake value - the client would get a 200 response on his attempt to delete a non-existent resource, which is clearly the incorrect behavior. I could return nothing - but then the client would see a 204. So, I choose to throw an exception with a response 'NOT_FOUND' throw new WebApplicationException(Response.Status.NOT_FOUND); so that the client gets a 404 response.
    - hello_moto 15y ago
      Yes, this is only an example. There are a few things I'd like to point out to add to this example: 1) JAX-RS is still new. In the future, they might improve the exception handling or whatnot (so if you return null, they might decided to return 404 ... who knows) 2) We can always wrap all JAX-RS with a Filter. So you can throw JPA level exception (not found) and let the filter catch it and convert it to WebApplicationException(404). Thus in theory, your JAX-RS implementation won't have any RuntimeException explicitly in the code.
    - beamso 15y ago
      I did try and build your code to run the test (I've no idea where the CsvParam and DateParam classes come from) but I think that the following will give you what you want without throwing the exception. @DELETE @Path("{uid: [0-9]+}") public Response deleteStudent(@PathParam("uid") int uid) { final Student deletedStudent = STUDENTS.remove(uid); if (deletedStudent == null) { return Response.status(Response.Status.NOT_FOUND).build(); } else { return Response.ok().entity(true).build(); } }
      - smanek 15y ago
        Ah, I see what you mean - thanks! The full (buildable) source code - including the CsvParam and DateParam classes - are here: https://github.com/smanek/students https://github.com/smanek/students
- waffle_ss 15y ago
  In Ruby, everything evaluates to true except false and nil. Also, the last statement executed is your return value. Therefore your first function could be written as def delete_student(uid) STUDENTS.remove(uid) || raise WebApplicationException.new(Response.Status.NOT_FOUND) end
  - pacala 15y ago
    I have no idea what the annotations mean, but if we use exceptions for transmitting error conditions, then there is no point having a true | exception function. public void deleteStudent(int uid) { if (STUDENTS.remove(uid) == null) { throw new WebApplicationException(Response.Status.NOT_FOUND); } }
  - smanek 15y ago
    I love it! And that is the reason I still write in Python or Lisp when I don't need something (Hadoop, Lucene, etc) from the JVM ;-)
    - jblomo 15y ago
      If you need something from the JVM and want to write Lisp, use Clojure. Checkout Hadoop extensions in Clojure at https://github.com/jblomo/oddjob https://github.com/jblomo/oddjob .
  - mbell 15y ago
    I seem to remember this same feature causing lots of headache in C in the form of subtle bugs mostly the result of this being used in awkward ways. Personally I'd rather have a distinct boolean value to test for, the java version is much more explicit as to exactly what its doing.
    - waffle_ss 15y ago
      Hmm can't say I've ever encountered something like that in Ruby so far. However, if you want a strict boolean it's pretty easy to get: !!STUDENTS.remove(uid)
- masklinn 15y ago
  First example, Python (keeping a similar API): list_student_ids = get(STUDENTS.keys) # [0] second example, Python: @delete @path(r'{uid: [0-9]+}') def delete_student(uid): if STUDENTS.pop(uid, None): # [0] return True raise WebApplicationException(Response.Status.NOT_FOUND) the last line generally wouldn't be this complex, in Flask you'd just call `flask.abort(404)` (which can be used inline with an `or`, as with waffle_ss's ruby example, but that's not usual/good Python style), in Django it'd be `raise Http404()`. Although in Django you'd really use the `get_object_or_404` shortcut for ORM objects: def delete_student(uid): get_object_or_404(StudentModel, pk=uid).delete() return True And you wouldn't bother with the return since a 200 result would mean the deletion was correctly executed. [0] Used Python's MutableMapping API here, it works slightly differently than Java's equivalent Map interface: `.keys()` returns a sequence of the mapping's keys and `.pop()` asks for a default value to return in case nothing was found there, otherwise it raises `KeyError` if the key was not found)
  - masklinn 15y ago
    An other note: the @path decorator would probably use named groups instead of some sort of DSL, so r'(?P<uid>[0-9]+)' (the `r` prefix is for `r`awstring, so the developer does not have to string-escape each backslash used in the regex among other things)
- jeltz 15y ago
  You could make it shorter by using something like sinatra[1]. Here is my pseudo-sinatra code. get "/list_student_ids" do STUDENTS.key_set end delete "/delete_student/:uid" do STUDENTS.remove(params[:uid]) or raise WebApplicationException, Response::Status::NOT_FOUND true end 1. http://www.sinatrarb.com/ http://www.sinatrarb.com/
  - nupark2 15y ago
    Your savings here are mainly from removing types. That's another matter entirely.
    - jeltz 15y ago
      I would say they are mainly from removing the need for decorators due to there being a nice lambda function/block syntax. So we can define methods like "get" and "delete" which does the job of the decorators, creating something kind of like a mini-DSL. Some savings through the removal of types, sure, but that is not what I personally see as most import here.
    - masklinn 15y ago
      1. Thing's most of those types provide no value in being spelled out like that. The ones on the methods have documentary advantages, but that's about it, the rest is magical invocations to make a stupid compiler happy. 2. There's also a gain from the framework being able to map things to each other without being told explicitly. `@PathParam("uid")` for instance, it's only there because the framework has no way to match the parameter name `uid` to the URL-extracted parameter `uid`. Likewise with HTTP methods being part of the routing instead of a separate annotation, in part. 3. Java's APIs and type system, such as implicit nulls and not being able to use arbitrary types in boolean contexts
mbell 15y ago
It may be slightly more verbose but you have to consider that the Java variant contains much more information in a single location. For example having a single file with methods annotated with @GET or @POST is so much cleaner to me than having routes.rb open in another editor window constantly Ctrl-Fing through it to sort out whats going on.
- hello_moto 15y ago
  I think that's a matter of preference. I don't mind both styles (after working with Spring MVC 3, Servlet 3, JAX-RS, and Rails)
- masklinn 15y ago
  > For example having a single file with methods annotated with @GET or @POST is so much cleaner to me than having routes.rb open in another editor window URL mapping is a framework detail, not a language detail — although the framework can be limited by the language. In Sinatra you'd write: get 'someroute' do # do stuff end http://www.sinatrarb.com/intro.html#Routes http://www.sinatrarb.com/intro.html#Routes each style (these and half a dozen others) has its advantages and inconvenients. For instance, separate urls mapping (Rails, Django) give a starting point laying out the structure of the site and make views/controllers easier to reuse (as they're not coupled to URLs)[0], whereas annotating the handler directly gives a better view of where they're involved and how. [0] They also make it simpler to "graft" sub-sites in
kreek 15y ago
I've written large Rails and Sinatra apps, as well as a couple Spring apps and straight Java apps. I"m evaluating Play now and even though I usually prefer Ruby to Java, I'm finding Play (with Eclipse configured to be Textmate like) as productive, if not more so, than Rails.

andrewl-hn 15y ago

We use JAX-RS as a primary web framework in our current project and honestly I can't get happier! We use Guava for low-level basic stuff and Google GSON for JSON serialization. It seems to be on par with Jackson from ease-of-use point of view: MyType myVar = gson.fromJson(jsonString); JPA on a back, some basic IoC in the middle (nothing fancy). Mockito and jUnit for tests. All in all it's just a bunch of small layered classes with some bits of annotations and no xml. Well, one web.xml file with single servlet declaration for JAX-RS :) With good IDE (they all are great this days), Maven for dependencies, well-known practices and modern APIs Java isn't that scary or cumbersome anymore. It's just a nice small language. A bit verbose without closures and type inference but still Ok. I should note, though, that we generally use our Java layer as a service provider. We keep main bits of logic on a client side in JavaScript and call Java either for transactions and data, or in cases when something is hard to do on a client. It's just easier that way.

hello_moto 15y ago
Be careful with GSON. It by-passes your getter and setter. That alone creates a bit of mismatch because JAXB (which is used by JAX-RS) uses getter/setter by default unless you specified it otherwise. And sometime you do have some logic in your getter/setter for validation or other purposes. I got bitten by this before while it seems like a small thing it's actually a bit problematic. If you're using JPA2, take a look at Spring-Data (formerly Hades). Spring-Data helps you to reduce JPA boilerplate code. The way Spring-Data works is by using a convention: specify your NamedQuery and a Java interface with method name == NamedQuery name. Then magic suddenly happens.
ww520 15y ago
I found Jackson is better than GSON at deserializing nested standard object graph automatically. GSON needs me to define all the nested structures.

scorchin 15y ago

For those looking for something more like Sinatra in Java, check out webbit: https://github.com/joewalnes/webbit https://github.com/joewalnes/webbit Here's an example of a simple Websocket chat server: https://gist.github.com/1421652 https://gist.github.com/1421652 Disclaimer: It's an open source project that I have some commits to

logn 15y ago
>Disclaimer: It's an open source project that I have some commits to Is that like a 'full disclosure' notice or are we supposed to be terrified of your code?
simpsond 15y ago
Webbit looks much more like embedded Jetty and plain servlets than Sinatra. If you really want something like Sinatra in you Java project, wire in Scala and try Scalatra.

hello_moto 15y ago

I'd like to add a few things here. Jersey is an implementation of JAX-RS. It has 3 major pieces: jersey-core, jersey-client, jersey-server. (The name should be obvious what they are for). If you're writing JAX-RS services, you can return a few different formats: XML, JSON, ATOM. All you need to do is to annotate the method with the following annotation: // will return XML or JSON depending on the request from the client. @Produces({ MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON }) This is a big win if you need to support both. - Object to XML conversion is done by JAXB. - Object to JSON conversion is done by Jackson via JAXB. Jersey is part of JavaEE 6 standard (part of your Application Server if it supports it). What's lacking from JavaEE 6 is an MVC framework which is targeted for JavaEE 7. Another key feature is JAX-WS (the plain old SOAP WebService). The nice thing about JavaEE 6 is that the minimum differences in the programming style between JAX-RS and JAX-WS. JAX-RS operates according to resources (e.g.: give me all students, give me student with id=1, delete student with id=1, etc). So some of the examples would be: // Rough pseudo-code, omitting a few JAX-RS annotation public class StudentResource{ @Produces({ MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON }) public <List> all(){} @Produces({ MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON }) public Student get(long id){} } JAX-WS operates according to services (e.g.: initiateInvoiceWorkflow, performPayment, etc). public interface AccountingService{ @WebMethod(operationName="initiateInvoiceWorkflow" ...) Invoice initiateInvoiceWorkFlow(); } // have your implementation... So in theory, you can have something that's called StudentRepository where you can use that repository with both JAX-RS (REST) and JAX-WS (WebService) implementation easily (I've done this and it's quite straightforward) if your "Enterprise client" forces you to do so. The important bit here is testing. You can easily test both JAX-RS and JAX-WS implementation in both unit-test or integration-test. You can easily do unit-test because you don't need to deploy them to the server: they're just normal Java classes. You can do integration test by deploying them to the server and generates the client implementation (in which I'll cover next). The client-side implementation of JAX-RS is also similar to that of JAX-WS programming style. In JAX-WS, you grab a WSDL, throw it to a generator tool that comes with JDK to generate the model (Invoice, Student, etc) and the proxy client-side to call the server-side. Very very straightforward, 5 minute job. In JAX-RS, you'd use jersey-client to perform HTTP call as follow: // url => is a string that points to JAX-RS end-point e.g.: student/1 // header => json? xml? atom? // type => (typeof Student) (well... it's Java). Student student = Client.create().resource(url).accept(header).get(type); Keep in mind that in the client-side, your Student class must have roughly the same structure and must be annotated using JAXB XML annotation (the client-side also relies on JAXB -> Jackson -> Java object conversion for the case of JSON, or just JAXB -> JAva object for the case of XML). So no hacking using XPath or something like that (I work in Ruby once in a while and when I read some of the 3rd-party libraries/gems that implement client-side API against popular service provider, most of the implementations do brute force using XPath querying node element and stuff). PS: Excuse me for the poor formatting, where can I learn to format my comment? UPDATE: fix the format. Oh and one more thing: JAX-RS (Jersey) is just an implementation on top of Servlet. So all of your previous knowledge regarding to Servlet (Context, deployment, URL, Filter) will be definitely useful.

jshen 15y ago

I'm not a big fan of the heavy use of annotations. When an annotation does something other than what I expected it becomes a pain in the butt to figure out why. Also, back in the day, jersey and guice didn't get along because their use of annotations on the same methods conflicted because they both wanted to drive the bus so to speak. This has been resolved, but it left a bad taste in my mouth because there isn't a good solution other than waiting for them to fix it.

latchkey 15y ago
Annotations are a huge and important part of Java.
- jshen 15y ago
  and I pointed out the headaches they caused me. I'm not really sure what point you are trying to make.
  - latchkey 15y ago
    Conflicts in any piece of software are a pain in the butt. That is part of software development though. You say you aren't a big fan of 'heavy use of annotations' but you don't qualify what 'heavy' is so I am guessing that it is pretty much all annotations. How do you make your determination of what annotations are 'ok' and what annotations aren't? Or do you say something like 'oh, I won't use that annotation because it might blow up on me at some later date'? What is your mental process there? Is @GET good or is @POST bad? What about @Inject or @JsonProperty? The 'annotations leave a bad taste in my mouth' statement seems kind of odd to me. Generally, a language feature isn't something that I'm careful about avoiding. I could see making a statement like "I tried to use software product XYZ and it was so full of bugs that I switched to software product ABC." But annotations aren't a software product, they are a language feature that products can take advantage of. It just happens to be that two products you were using had conflicting annotations. No big deal, you still have choices as you can just swap out products. That in itself doesn't make the functionality that annotations provide taste bad. I've met people who have had this view of annotations as being some magical creature. They didn't understand them or how they worked at all. They stuck it in their heads that 'annotations are bad', so we aren't going to use them and aren't going to even bother learning how they might help us. Everything was very black and white. I found this behavior really odd because everything in software development is grey.

mattmiller 15y ago

This is very cool. I am tied to Java b/c of Lucene and the Hadoop ecosystem as well. Some more things I would like to see: -Templating. Something like SimpleTemplate Engine in Bottlepy. http://bottlepy.org/docs/dev/stpl.html http://bottlepy.org/docs/dev/stpl.html -How do I get rid of Tomcat at least for development. I would like to run java -jar MyApp.jar -Dport=8080 and get a live running webapp in my dev environment.

smanek 15y ago
Take a look at Jetty (http://www.eclipse.org/jetty/ http://www.eclipse.org/jetty/) for the second option. I tend to use 'mvn tomcat:run' to run my dev server, which I find even easier, fwiw.
latchkey 15y ago
I've been using a very little know (and poorly named) template engine called Cambridge Template Engine (http://code.google.com/p/cambridge/ http://code.google.com/p/cambridge/) for my latest company. The documentation is a bit thin, but the code is rock solid and very fast. Combined with JEXL for an expression language, this is one of the best server side engines I've ever used.
masklinn 15y ago
> How do I get rid of Tomcat at least for development. Jetty everything. You can even keep it for production.
benmccann 15y ago
You can do "java -jar MyApp.jar -Dport=8080" with both Tomcat and Jetty using what they call "embedded mode". I like the Jetty embedded mode much more because it starts up so much faster. The Tomcat embedded mode does have the benefit of an easier to understand API, but it's not worth the speed trade-off for me. Here's examples of both: http://www.benmccann.com/dev-blog/embedded-jetty/ http://www.benmccann.com/dev-blog/embedded-jetty/ http://www.benmccann.com/dev-blog/embedded-tomcat/ http://www.benmccann.com/dev-blog/embedded-tomcat/ I put together an example and uploaded it to GitHub. I'd love feedback on it: https://github.com/benmccann/sprightly https://github.com/benmccann/sprightly P.S. Closure templates are cool because they can be used both client-side and server-side. I'm not aware of other templating languages that have this feature. I haven't used it much yet, but want to experiment with it more when I get time.

ww520 15y ago

For web, Play Framework and Japid template are very good. For distributed clustering, Hazelcast is amazingly good. For massively scalable network services, Netty does a fantastic job.

latchkey 15y ago
I'd never heard of Japid before. Thanks for pointing it out. That said, using a backtick character like that seems like a really error prone approach. Definitely not my cup of tea.
- ww520 15y ago
  That's what I thought as well when I first saw the backtick, but after using it for a while I found it to be perfect. It's rarely used in any other context (besides Lisp). It's really unobtrude, making the rest of the code standing out. It's at an easy to remember place at the keyboard. The parser is good enough to catch any quote or backquote mistakes. It's really an non-issue and you forget about it after a while. A sample, <ul> ` for (a : list) <li>$a ` </ul>
chaostheory 15y ago
Since we're on the subject of Play, I'm going to add Akka to this list. In my experience, programming for concurrency (and even distributed concurrency) is just way more enjoyable using Akka.

icandoitbetter 15y ago

>Javascript (which is basically just a Lisp with infix syntax ;-)) No, it's not.

roryokane 15y ago
To elaborate, JavaScript doesn’t support macros, which allow arbitrarily powerful semantic abstraction. And JavaScript does not have a regular syntax, so even if it did have macros, you would have to special-case each type of syntax (curly braces, statements, post-++ operators within lines) and handle them specifically. First-class functions and closures do not a Lisp make.

swah 15y ago

But Play 2.0 is moving away from Java Servlets, IIRC... how do the modern solutions compare in that regard?

mahmud 15y ago
Play 1.x is NOT based on Java Servlets. No version of Play ever was, never will be. From the BDFL himself: http://iam.guillaume.bort.fr/post/558830013/why-there-is-no-servlets-in-play http://iam.guillaume.bort.fr/post/558830013/why-there-is-no-...

zmmmmm 15y ago

For me, the modern Java ecosystem is more about a sweet combination of groovy at the edges with a minimalist Java core. it seems to be the best combo of static and dynamic typing and capture a lot of the best of both worlds without buying into too much religion or "enterprise" type complexity.