Hi Jordan, thanks for your comment and I totally agree. In the next blog (to be published next week) I mention that people should take a look at Curator and Exhibitor once they understand the basics of ZooKeeper. And if I get some time after that I plan to write a few blogs reworking some of the examples I've used but using Curator, and probably showing that Curator comes with a ton of good production-quality recipes out of the box.

- Scott

Using the Session ID as the method for working around connection issues during node creation is not ideal. It prevents the same ZK connection from being used in multiple threads for the same lock. It's much better to use a GUID. This is what Curator uses.

This one is a few years old and real: https://github.com/jimweirich/rava

Excellent April 1st joke!

http://www.rforge.net/rJava/

(former http://rosuda.org/rJava/ )

Thanks! I read your post at the exact right time. I had to give a presentation, but didn't know if I would have wifi available. I almost went out and bought one of the physical remotes. Your post saved me $18. Thanks!

I started typing out a response but it got too long to post here. I looked around for a way to email it to you but couldn't find one so I posted it on my blog here.

Appreciate any thoughts/comments!

http://cwash.org/2009/11/14/a-response-to-can-java-be-saved/

@Scott

A Newardian post deserves a Newardian reply. :)

I like your language additions. But those kind of additions are going to be happening in the context of the JCP, and many don't have the patience for that. I think some of Spring, Guice, and CDI's enhancements to the programming model are novel ways of evolving given the restrictive "all things to everyone", bureaucratic nature of Java at this stage of the game. I think you can directly attribute people's despise for Java, or maybe more aptly, their enthusiasm for new languages, to the difficulty involved in making language changes to Java. Regardless, there is still a freshness to the innovation in the Java world, but people are looking for it in the wrong place: it's in the programming model, not the language.

Your description of a native property syntax reminded me of another blog I read recently:

http://in.relation.to/Bloggers/WritingAPropertiesFileInJava

Sure, it lacks the punch of a native language feature - but is it that much different than what you're proposing? Do I really need type inference? I see it as easier to read and more powerful to remove the duplication of repeating a variable declaration and constructor call by removing the call to the constructor, as you point out, by not using the new keyword. I can annotate a method as a producer and have the exact instance injected. Again, this is a programming model enhancement that's independently evolved and proven itself.

I think there is still a lot of room for evolution, and a lot of work being done. As you point out, the 800 lb gorilla seems to be continued by-in and enthusiasm from vendors - but most if not all of the real innovation that is occurring in the community is through open source software. It's interesting how you have a rift in the open source space, in how, e.g. the Spring and the Seam teams have approached developing open source. Do you work around the standards, which have tended to be over engineered themselves and riddled with problems? Or is the best plan to evolve a more realistic specification from frameworks that have been tested in the wild? This is a fundamental issue plucking at the heart-strings of Java's future. I believe you alluded to it in a talk on Real World Hibernate Tips I listened to you give not too long ago. There are some big philosophical differences as to how we evolve and innovate in Java. But I'm not sure we need to reconcile the two models - they both have merit in their own right. The fact that there are competing models says to me that there is some competition, and the fate of Java is not yet sealed. The programming model can evolve outside of language features, as we've seen with Spring, Guice, CDI and to a certain extent new JVM languages. And vendors seem to be more open to evolving the programming model than the language at this point.

I certainly welcome any of your thoughts on this. Thanks for the interesting article.

I've been using Java as primary choice language for years in order to satisfy everyday corporate requirements/sh** and starting to have less and less fun. On the other hand all my private projects are done in Python and I enjoy it a lot.

I never questioned Java, nor tried to reinvent some of its over-complexed aspects. But, after reading your post it all came together and its so obvious.
Thanks for awesome post. Cheers!

@andrew Thanks for the info on Python. I've only done very minimal scripting in Python and have only read one beginner book on Python several years ago.

@Scot Yes, you're probably right. During the architecture BOF at the Reston No Fluff Just Stuff conference this past weekend, there were still several people on Java 1.4! And the majority were on Java 5, with only a few on Java 6. That was only a sampling of about 15 people, though. But I never understand why organizations continue to restrict new applications to the same 5+ year old platform that apps developed over 5 years ago were built on. At the least I would think it easier to allow newer apps to run on new versions. And if an organization does any maintenance at all on apps, then perhaps more emphasis should be placed on keeping relatively current with versions. But then again, what do I know? I'm no CIO, CTO, nor do I have control over a multi-million dollar infrastructure.

Wouldn't an organization that will only use Java also be an organization that would be slow to adopt Java 7/8/X? In such an organization, you might be lucky if you can use Java 5 features, let alone something like closures.

Just a note about pythons class constructors; no magic is going on their either. The following is an approximation that simplifies what happens from the outside:

A class statement creates an object that is a descendant of Type. Type implements __call__ to a) call its own __new__ method to create a construct a new instance and then call that instance's __init__ method to initialize that instance. The class object is bound to a name and thus becomes a firstclass callable just like any other.

It only appears to be magic if you've never looked inside.

Tamas and mgr: I actually do use Groovy quite a bit, and I have played with both Scala and Clojure a little bit, mostly by being a reviewer on Venkat Subramaniam's Programming Scala book and Stu Halloway's Programming Clojure book. On a recent project which has been in production since October 2007 we've converted all unit tests to Groovy and about 40% of the production code to Groovy. We've been pleased with the reduction in number of lines of code and boilerplate, and the flexibility we get from Groovy. Note this is not an extremely high-performance high-volume app, rather it is a webapp that talks to an RDBMS mostly, so we haven't seen really any performance issues with Groovy. Plus it is still a Spring/Hibernate webapp with all the goodness (or badness depending on your view) which those entail. The only difference is the language is Groovy not Java.

I agree with mgr: you can use groovy (or Scala, JRuby, Clojure) over JVM, so you'll have all the desired benefits, and still, you can use the Java APIs, framework, etc. On the other hand, Java remains backward compatible.

The two code examples in "Property/Method Handles" are identical :-)

I must say I agree with all your points.
Hope at least properties become a reality.

Have you tried groovy yet? You really should. This is the way to code java the way you want it.
http://groovy.codehaus.org

David Adams: This is a blog post, not an AP news item. Dialectic variation is perfectly acceptable. Especially when the variant in question is dominant in use.

"chomping at the bit"

Champing at the bit. Not "chomping" at the bit.

I think they would probably kill me first. :-)

And let's be honest. There are way, way smarter people than me who probably have campaigned for changes like this and lost. That, or they just went and wrote their own language, which I am not smart enough to do.

You should become a member of the JCP and push for these changes. If anyone could do it, it would be you.

Good points all around.

I do wonder about the language complexity question though, at least from a relative perspective. The author did seem to be making a point of comparison between Java and the languages that preceded it, namely C++, and that it wasn't a significant reduction in complexity. My recurring malloc() nightmares disagree, but it just seemed to move the problems from memory allocation to garbage collection.

Thanks for the JDK link.

Jesse, CloudStatus looks really cool. Thanks for the link.

Kristen, thanks for the info. There's definitely a lot of cool things companies are doing to enable really high availability and scalability. And Joyent looks pretty cool.

Scott,

salesforce.com pioneered transparency for SaaS/PaaS providers with their trust.salesforce.com site.

Also, you may have seen this post from Google's App Engine blog today: http://googleappengine.blogspot.com/2008/08/new-third-party-party-tool-for.html

Scott, You are so right, out tool boxes have become a lot bigger and Joyent's cloud computing is leading the way. I'm not sure if you are aware of this, but Joyent is the official host for Ruby on Rails and their ability to scale over 1 billion page views per month is proving them to be a developers' number one choice for web applications.

Scott, this seems a Mac-specific issue, we are sorry for this creeping into plugin manager - we'll try to work it out ASAP.

Eugene.

Thanks for the warning on this, I'll wait to upgrade for a little longer.

Totally agree that testing getters and setters is sort of silly unless they have side effects. But since it is possible, however unlikely, someone could screw up a setter by writing or modifying and IDE-generated one like so:

public void setIt(String it) { it = it; } // forgot "this"

or whatever, then if I can have an automated way of testing all the silly getters and setters by writing essentially one line of code in my tests, why not do it?

Again, this is such a silly thing but I want good code coverage to make sure my code is tested and that everything works as expected; unfortunately getters and setters are actual code in Java, even though mainly boilerplate, but they still need to work and at least this way you can verify that behavior.

I've just started doing this myself, so I don't know too much yet, other than how quickly I was able to whip up those mocks without really knowing Groovy very well. On my current project we are looking at starting to write tests in Groovy but first have to make sure it all works with Maven2, which we're using as the build tool.

I know, based on talking to other people who are doing it like Neal Ford of ThoughtWorks, that you definitely can unit test your Java code using Groovy, even though I've not yet done that. I am fairly sure the coverage tools will work fine since they are instrumenting your actual Java code, not the tests themselves, so as long as a LOC is executed, Clover, Cobertura, etc. will pick that fact up. And, I know that Neal is huge into delivering systems with close to 100% coverage, so I doubt he'd use Groovy for tests if he couldn't get test coverage. (I am hoping to sneak my laptop to the beach next week and play around with Groovy some more, which pretty much makes me a total geek.)

On my To Do list is to take a careful look at unit testing in Groovy: specifically, can I unit test my Java code using Groovy's unit testing capabilities, and would I want to? Unit tests are a great place for dynamic scripting languages: you're going to be running all of them often, so you're not actually losing anything when you lose static typing, and anything that can make data mocking and set-up easier becomes a huge win.

My biggest concern would be whether code coverage tools would work with Groovy. Any experience on that?

In general, I don't explicit test my getters and setters: I tend to test then en passant while validating more interesting code behavior. My general feeling is that if there is no unit test that I write that makes use of a given getter or setter, I should reconsider whether it is valuable.

The most common exception to this guideline is validating when the setter explodes when null is passed in. I test that pretty religiously, because that variable being null is usually an implicit assumption elsewhere in my code.

A less common exception to this guideline is when I have constructed an intentionally immutable object, and I want to validate that changing the returned object doesn't change the state of my object.

Hi,i have some question ask for you,i want to list the java processes on a remote linux host,but when i use the command " jstatd -J-Djava.security.policy=jstatd.all.policy" to start jstatd processe i got this exception message:
-----------------------
Could not bind /JStatRemoteHost to RMI Registry
java.rmi.ConnectIOException: non-JRMP server at remote endpoint
at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:217)
at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:171)
at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:306)
at sun.rmi.registry.RegistryImpl_Stub.rebind(Unknown Source)
at java.rmi.Naming.rebind(Naming.java:160)
at sun.tools.jstatd.Jstatd.bind(Jstatd.java:40)
at sun.tools.jstatd.Jstatd.main(Jstatd.java:126)
-------------------------
So I changed to port 1982 because I read somewhere that JBoss binds the naming to 1099,code like this:
#rmiregistry 1982&
#jstatd -J-Djava.security.policy=jstatd.all.policy -p 1982
this time jstatd processe can be started,but use "jps -m 192.168.0.102:1982" cannot find JVM process information but got this message "Malformed Host Identifier: 192.168.0.102:1982".I've tried to run jstatd on my windows xp machine, but i didn't find any problems.
How could i solve this problem? Thank you!