[eitland]

The biggest issues are less about syntax and more about having to restart containers etc again and again.

But everyone except Play! and a few others seems to be jumping the new syntax bandwagon.

Being a php/python/Java developer I'm afraid I'd trade all improvements after generics for a no restart required jvm

[akeefer]

Depending on why you're restarting your VM, you may want to check out the DCEVM: http://java.net/projects/dcevm

It lets you do arbitrary hotswapping of code, rather than only swapping method bodies. Not appropriate for production at this point, but you can install it on top of any Java 6 version prior to update 26 (not sure about Java 7); it's pretty useful for doing rapid iterations during development of large-scale server apps or swing applications.

[ww520]

Does anyone have the documentation or tutorial for DCEVM? I've looked at it from time to time but never able to figure out how to use it. There's no doc beside the jar file.

[akeefer]

Sorry for the late reply (didn't see the question until now). The DCEVM is just a patched version of the JVM dll/so file that allows the normal hotswap mechanism (triggered by JVMTI) to accept arbitrary class changes, rather than just method body changes. There's no additional mechanism or API, it just makes the already-existing mechanism for hotswapping better. To install it, you just run the installer jar and point it to your jdk. To use it, you just trigger a hotswap as you normally would, which generally means starting your program in debug mode via an IDE, and having the IDE automatically swap changes for you as classes change locally. If you want to do hotswapping without the IDE, that's a bit trickier. Technically, you can write your own JNI code to directly hook into JVMTI and trigger a hotswap (which is what we actually do with our development platform at Guidewire), but the easiest way to do it is generally just to use the debug capabilities of the IDE.

[shelajev]

If your biggest issue with java is about restarting containers/redeploying your app, you should check out JRebel (http://zeroturnaround.com/jrebel). It's a tool (javaagent) that will pick up changes you make to your code and introduce them in your running application. Unlike Play! it supports your application server and your framework stack.

Also it supports picking up changes in the configuration of major frameworks, like spring, for example.

Basically, with JRebel you can develop in java as you would do in python :)

disclaimer: I'm employed by the company that develops JRebel, but this fact doesn't make it any less awesome.

[Roybatty]

No, no, no. Our fancy, schmancy IDEs can produce the code for us, but we still have to read the Java boilerplate.

[Periodic]

Reading Java can be the hardest part about working with it.

When working with Haskell and discussing why you would want to use let vs. where or if vs. guards, Bryan O'Sullivan explained it to me by borrowing a term from journalism: Don't bury the lead.

You want to put what the function does right at the top. The first thing it should tell you is that it prints hello for each person in a list. Then you can put the details of how that's done in definitions below. It allows you to write functions so that they are easy to read and so that the structure of the semantics are separate from the implementation details and the requirements of the system.

Java's rigid boilerplate has always stood in the way. It would be like if every newspaper article had to list all of its sources, with full names and titles at the start of an article and then had to list events in chronological order. They would be mind-numbing to read. Sometimes I just want a good juicy sound byte right in the first sentence so I know why I should be interested.