We Keep Coding

Best dynamic language to pair with Java on a Java project

What is the best dynamic language to pair with Java on a large Java project?
We are considering using a dynamic language for tests, controllers, services. Some options are Groovy, JRuby or Jython. What are the pros and cons of each for this? Ideally we'd be able to call Java from the dynamic language as well as call the dynamic language from Java.
EDIT: If it helps, we're using Hibernate with PicoContainer and Webwork.
Thanks,
Alex

There are really three dynamic languages that offer a very seamless interop with Java - scala, groovy and clojure. From there, I'd ask your team which language they would rather work in or have them try a prototype in each language and see what they think.
If the team efficiency isn't important in the beginning, look to what problem each language attempts to solve:
Groovy is going to be very loose but natural to experienced Java developers and allows fast prototype development due to it's duck typing.
Scala is going to enable you to write DSLs making it a good for frameworks and tools where you want to solve the problem in a language more akin to how you would describe the problem.
Clojure is going to impose lisp's functional programming and immutable state concepts and could be a very natural fit for problems in AI, natural language processing, etc.
Finally, I've gone down the path of looking for the perfect language to base projects on and have found there is no perfect language. All of the languages I've mentioned above compile to native JVM byte code and are quite solid. Sometimes you just need to pick a language that might not be as cool as the others but gets you on the way to solving your problem.

I recommend Groovy, principally because it interoperates seamlessly with Java, and is almost a superset of Java, so very easy for a Java developer to learn. I have absolutely no evidence to support this, but based on hearsay, guesswork, and personal experience, I suspect the Groovy community is much larger than that of either JRuby or Jython.
Incidentally, Groovy++ is way too immature to consider for production use, in my opinion.

The answer is, of course, going to depend somewhat on matters of taste and flexibility. If there are folk who don't have experience with Ruby or Python then Groovy is going to have a syntax much closer to Java (in fact it is a superset of Java), and consequently be a much easier sell.
I can't really speak to JRuby as I haven't used it.
Groovy gives you probably the easiest interop with Java of the three you listed. It also has a very nice BDD library in EasyB which I like a lot. On the negative side I don't think the features or syntax of Groovy really hang together very well. It can kind of feel like a whole bunch of separate extensions to Java.
Jython is of course Python so the syntax is different, but also has all the consistency of Python. Interop is very good at the script level but at least used to be a bit awkward if you wanted to write pre-compiled classes in Jython that you call from Java. The other main pro over Groovy for me is that is that you have a real REPL to interact with the Java project.
I would also mention Clojure, the syntax is even more different but the Java interop is excellent, probably the best of all, and again you have a REPL. On the down-side if folk have trouble adjusting to Ruby or Python syntax then a Lisp is probably right out.

Clojure is probably the best dynamic language for controllers and services. (depending on what you mean with "services".
Scala and Groovy++ has the best java interop, but those are not dynamic (well in Groovy++ you decide for yourself what is typed.). Scala has the look and feel of a dynamic language. Scala has good testing frameworks http://www.scalatest.org/ and Specs and AKKA is very mature for services and also has Java APIs

I'd suggest going with Jython. The syntax is clean, and you get whatever additional power/conveniences that Python gives you.
For example, if you were to go with Groovy, you are basically limited to only what Java will give you. Jython would add the powers of Python to that as well.
If it helps any, I've used Jython with Hibernate, SOAP, Corba, and EJBs and it is much easier than doing the same with just plain Java.

What languages would be a good replacement for Java?

I may be posting a premature question, and maybe I'm just freaking out for no reason, but the way Oracle is handling Java is not very promising. I am a nerd who fell in love with Java from the first sight, and use it all the time in my personal/freelance projects but now I am thinking of a replacement.
I am fluent in C#/VB.NET too but I am looking for something more like:
Open Source
Compiled
Cross-Platform
Object Oriented
Large standard library
Extensive documentation
Web development is a major plus
I was thinking about a compromise: Python/Django for web development (or PHP), and Qt for thick client development. Anyone with better thoughts?

Not so long ago, I decided to explore away from the JVM. I set foot on python, and even though i'm nowhere near the expert/ guru level, I dont regret it. Didn't choose C# (considered it) because I consider it to be more of the same. I alredy know (and like a lot) C++, so python seemed like something new, which is what I was looking for.
It fullfils many of your requirements. Particularly, i'm decided not to learn PHP, so the web frameworks in python came in great.
Not to mention, Python has a large community (also see here), always eager to help and teach, which I consider to be very important.
Just my two cents.

Might be worth loking at the other JVM languages - Clojure and Scala are the two I personally think are most promising.
Yes you are on the JVM, but you're pretty independent from Java the langauage and don't have to use any Sun/Oracle implementations if you don't want to.
Having said that - I think that you are worrying a little too much about Java, too many players (including Oracle!) have too much invested to let it go too far off course.

Try Scala. It looks extremely elegant and promising. Being object oriented and sharing a lot with java in a very concise manner.

Everything you said points to C#, except for the Open Source point.
To fix that, there's Mono.

You could try D. My one-sentence description of why it's an awesome language is that its generic programming/compile-time introspection/template metaprogramming facilities are good enough to give you almost flexibility of a duck-typed language, while its execution speed and static type checking rival or exceed C++ and C#.
I think it meets your requirements quite well.
Open source: The frontend to the reference DMD implementation is open source (the back end isn't due to restrictions beyond the author's control). Work is underway to glue the reference frontend to open source backends such as LLVM (LDC) and GCC (GDC). In the case of D1 (the older version of the language) the LLVM port is fairly mature.
Compiled: D is meant to be compiled to native machine code, i.e. raw, inscrutable hexadecimal numbers.
Cross-platform: The reference DMD compiler supports x86 Windows, Linux, Mac OS X and FreeBSD. GDC and LDC will likely support a lot more CPU architectures.
Object oriented: D isn't a "pure" OO language in the Ruby sense of everything being an object, or in the Java sense of not supporting any other paradigm. It does, however, fully support Java-style OO as a subset of the language, along with procedural and functional style programming.
Large standard library: D1 has Tango, which qualifies. D2 has Phobos, which is not "large" yet by modern standards but is larger than C or C++'s standard lib. However, recently there has been a large interest in contributing and Andrei Alexandrescu (its main designer) has accepted several new contributors, including myself.
Extensive documentation: The standard library and language are reasonably well documented at the Digital Mars website. There's also Andrei Alexandrescu's book "The D Programming Language".
Web development: This is an admitted weakness. D doesn't (yet) have a good web framework, though its native unicode support and excellent generic programming support should make writing one relatively easy.

I too would like another Java-like technology to come along. Lately I've been doing Flex/Actionscript. While I really enjoy it, Actionscript technology seriously lacks the elegance that Java has. Adobe can write some good cross platform APIs, but they just don't have the head capital to build elegant languages and compilers. I've also tried Ruby, but the VM for Ruby is really bad. I've gone back to Java after my flirtation with other technologies and I think it's because the language is good enough, but the JVM is by far the best out there.
So do you want to stay with the JVM or do you really want to the leave the JVM altogether? Staying on the JVM there are lots of options: JRuby, Scala, Groovy, Javascript, Clojure are the big players. However, there are tons of great languages that can take advantage of the JVM's features.
Leaving the JVM there are still good options like python, ruby, and erlang. But you give up some of the nice features of the JVM like performance (big one), and the ability to drop down to a nice language like Java if you need speed. Those others mean using C or nothing at all.
I finally stopped worrying about Java's future. Sun did all it could to screw it up and it still turned out pretty darn good. I think Opensource has a lot more influence over Java's success than Oracle or Sun could ever have had.

I can't post comments yet, so I'm posting an answer related to the Python discussion. Though Python isn't compiled to machine code, there is a Python-to-C compiler called Cython, which can compile nearly all valid Python -- closures are finally (!) in the latest development release. It's have a big impact on some parts of the Python commmunity, e.g., I was at Euroscipy recently, and over half the talks mentioned Cython.

I personally don't like PHP, but it does meet all of your requirements. It doesn't officially support compilation but there is the Hip Hop project which compiles PHP to C code. Facebook is currently heading up this project.
That said, I highly discourage you from using it :)

C# is the only thing that will meet your needs and not feel hopelessly archaic, or frustrate with limited library. For open source/non-windows, use mono. It's a good, mature implementation of most of what's important in the CLR.
Some things (WPF, WCF, etc) are "missing" from mono, but these aren't so much part of the platform as they are windows-specific proprietary toolkits. Some of them are being implemented slowly in mono, some aren't. Coming from java you won't miss them because you're looking for a platform and good standard libraries to build upon, not a gui toolkit or whiz-bang communication framework.
As far as a platform to build stuff with that's "like" java and offers similar levels of functionality, C# + CLR is the clearest option.

Using also Cython you get the best of the two worlds , the ability to code in python , the ability to code in C and C++ and of course compile your code and the ability to use both python a c/c++ libraries out of the box. And if you dont like C++ syntax , cython syntax is python syntax and more.
link text

Knowing the fundamentals of Java what is the right approach to learn Groovy?

As my question already implies I want to learn a new language and have read several articles about groovy and its more pragmatic syntax. SO I have choosen Groovy as the language of my choice.
What is a good way to learn a new language like Groovy when I already know the fundamentals of Java. When I understand correctly Groovy will be running in the Java Virtual Machine and allows me to always rely on what I know from Java when I don't know how to solve the problem in Groovy.
I am looking for hints on how to organize a learning track to learn this language. I found that page explaining the differences: http://groovy.codehaus.org/Differences+from+Java But what I am looking for is more a tutorial where I can get through and get introduced to the differences.

There are a couple of articles which have been written with that specific goal in mind: "From Java to Groovy in a few easy steps", part 1 and part 2. They were written by Gillaume Laforge, one of the masterminds behind Groovy. The articles are well written, easy to follow and provide a nice introduction for Java developers. Also, there is the Beginners tutorial in the official Groovy documentation.
Once comfortable with the basics, it's easy to move on to the on-line Groovy task-specific documentation.

Personally I find that referencing an old language that I know to learn a new language is not a good idea. The reason I say this is that in a new language you want to learn to express and use data structures, idioms, style, etc in THAT language. You want to Groovy developers to say that the code is written by a Groovy developer rather than a Java developer.
An example, using Groovy and Java, is that Java developers tend to use a loop for collections, but in Groovy tend to use closure. They may look the same, but they are not. In Java we are applying to data to the code, whereas in Groovy we are applying the code to data. Learning this subtle difference is important to understanding the rest of Groovy API and will help you to grasp that concept.
Also I think that this approach of learning a new language referencing and old might not work that well with other styles of programming like functional.

You might also take a look at this article by James Strachan, the author of Groovy:
http://macstrac.blogspot.com/2009/04/scala-as-long-term-replacement-for.html

Best approach for learning Java after C++?

I've been using C++ for about 6 or 7 years now, and I consider myself fluent in it. I've never bothered with Java until now, but I find myself out of the job (company went under) and I need to expand my skill set. Someone recommended Java, so I am wondering if there is any advice for where somebody like me might start. I am also interested to know what the key aspects of Java are that are most likely to come up in an interview.

There are some popular areas that I think of when we talk about Java
Concepts of OOP: I'm sure this will not be much different from C++:
Class, Abstract Class, Interface,
Polymorphism, Overriding,
Overloading, Inheritance, Static
member, ... Interface will likely be
area that you might want to focus.
Since this is not directly available
in C++, I don't know.
Core Java: Such as the basic syntax and the common classes such
as Math, String, System.out,
Scanner, Basic file I/O, Stream.
Know the concept of Garbage
Collection, Reference Type (since
pointers are not available here.)
Know the Java platform/technologies,
J2SE, J2EE. Basic GUI with Swing and
its layout managers. Web
Applications with Servlet/JSP.
Popular tools, frameworks, and libraries: This may not as
important as above bullets. But
maybe you should know what Eclipse,
Netbeans, Spring, Struts, Hibernate,
EJB, Ant, JUnit, JavaDoc, are for.
You can always search for "C++ to Java" in Google. I'm sure there will plenty of good start points. Don't forget not to put * in front of var name next time you code Java :)

I recommend you read the book Effective Java cover to cover. Not only will you learn lots of good programming practices, but you will also learn more about Java than you otherwise would. Highly recommended. :-)
As a simple example, in Java, rather than rolling bitfields by hand (which is rather painful to do in Java, and for good reason), you use an EnumSet instead. This is documented in Item 32.
BTW, if you don't mind reading a PDF (no DRM) version, it's cheaper than hardcopy too: http://www.informit.com/title/0132345285

There are a number of great "in depth" Java books that will teach you not only Java, but also best programming practices.
If you're just interested in syntax and an introduction to the Class Hierarchy, Java in 24 hours is pretty good. From there, you will know enough to go and explore more on your own.
I highly recommend thinking of a small project to help you learn. In fact, think of a teeny tiny project -- it will turn out much bigger than you think! ;) Maybe a simple shoot-em-up or a Daleks- or Asteroids-alike, or some such.
The main thing being: for an expert-level programmer, don't try to learn Java from a book. You can get introduced to Java via a book, but then you have to go learn on your own (or from another.) It's like learning to drive a car -- you can get the basics from a book, but you need to explore & try stuff, and someone who knows how can be very helpful.
Some things that will help:
Download and bookmark the HTML Java docs. You will reference them often.
Have a small project, a simple game or utility app that you estimate will take a couple of days to write. Spend a couple of weeks writing it ;)
Note that "Java" is 3 things:
Java the programming language. Like C++ or Lisp or Perl.
Java the Class Hierarchy. Like STL or Cocoa.
Java the run-time virtual machine, the JVM.
People use the word "Java" to mean all 3 things, and slip between them without much notice, so pay attention to that, when you start talking Java to people.
Good luck!
(And let us know when your game is available :)

The biggest issue with the C++ to Java conversion is that they're so similar -- you'll find yourself doing C++-isms for a while. But it's no big deal: as suggested, read Josh Bloch's book, and run through the tutorials on java.sun.com and you'll do fine.

In my opinion, Java sets itself apart from C++ in three ways:
Automated memory management
Simplified syntax (and no preprocessor)
The Java standard libraries
As a former C++ guy, the first two shouldn't be a problem. (In fact, I would wager they will strike you as rather refreshing.) To get used to the libraries, I recommend Bruce Eckel's Thinking in Java - the 3rd edition is free to download. Though the beginning chapters will probably be a little too basic, the sections about GUI programming, concurrency, and the various container classes will be very helpful.
Beyond that, the best way to learn any language is to read good code.

I started by reading the Java Language Specification, version 2 at the time (2001).
In my view it is quite readable as specifications go.
Effective Java is good advice.
Java Puzzlers is good to learn corner cases and possible pitfalls.

The Peter Norton's Guide to Java Programming, "Making the Transition from C/C++ to Java".

BGGA closures as a bolt-on solution to java?

Yesterday #headius / Charles Nutter came up with a very interesting idea on twitter:
#danny_l Gafter made the same mistake; I don't mean a forked Java any more than Groovy is a fork. I want a "mostly Java" with closures.
or the reply by #danny_l / Danny Lagrouw:
#headius or could the BGGA prototype be "bolted on" any future version of Java? That might be useful
That really is what I would like to see as well. Can't we have some sort of bytecode preprocessor to make the BGGA prototype work on any modern Java version? I mean scala, Groovy and JRuby have closures and produce valid bytecode!
I would even like to help and put effort in it. Although I don't really know where to start.
(the above is an excerpt of the blogpost I wrote about this topic)
What do others think of this idea?

The word 'preprocessor' takes me back to C++ and it scares me.
There is a weird dichotomy: I celebrate the diverse garden of languages on the JVM, but I think that "Mama Bear" (aka Java) should not become fragmented like this. We need a solid foundation.
That said, I am in favour of BGGA closures. I also think a language should provide its full capabilities. If a team has people who can't handle closures (or generics, or threading (!!)), then that team should police itself through code reviews and static analysis.
Maybe one idea would be to have a compile-time switch to 'disallow' advanced features like this but even that seems a bit harsh.
I think the 'bolt-on' idea is really trying to address the fractured leadership in the Java space. That problem strikes as being more political and diplomatic than technical.

The problem with making these things a bolt on is that you create a fragmented language.
The java language is the smallest part of what makes java, java. The libraries and the culture make up the larger part. Making closures and generics a bolt on means that either they cannot be used in the core libraries or that the core libraries would require the bolt on to be present in the SDK being used. This would at best create fragmentation within the libraries (as some developers work to the core and some require the bolt-on) and at worst would mean that we will start having 'distributions' of java in the manor of java each containing a different set of jars and 'bolt-ons'.
I would say this is the start of a slippery slop I would rather stay off of.