Regardless of whether it's necessary or not, it's kind of expected knowledge to have as a programmer. Around here you'll find a lot more anti-Java sentiment than in most places (and most of it is probably justified), but I still doubt you could find many expert hackers here that don't know how to code Java. Everyone hates it because everyone has to use it from time to time, kind of like C.

At the moment, the ten most popular languages are (according to http://www.tiobe.com/index.php/content/paperinfo/tpci/index.... and whatever metric they use):

1) Java

2) C

3) PHP

4) C++

5) (Visual) Basic

6) C#

7) Python

8) Perl

9) JavaScript

10) Ruby

Given that Java is #1 on that list, I'd find it hard to call some time spent learning it wasted, you're just going to run across it too much, at conferences, in papers, in code that you inherit, in libraries you have to interact with or debug, etc.

Besides, if you know C or C++ it won't take very long to learn the syntax, and the libraries are worth learning because you'll use them in any JVM language anyways. If you don't know C/C++...well, um, add another one to your list, every programmer should have at least a basic understanding of some flavor of C for the same reasons they should know some Java.

If you do start with Java, make sure you actually use Java tools for the job, though, at least once you have the basics down; if you're coding Java in a text editor, even a good one, you're making things far more difficult than they need to be, because it's a language where tools are absolutely crucial if you don't want to drive yourself crazy. Whether it's Eclipse, Netbeans, or IntelliJ, you haven't really learned Java if you haven't learned how to use one of them well.

Errm... if you're going to quote me programming language statistics, please use my own: they're better than TIOBE's:-)

http://www.langpop.com

I agree though, that a cursory knowledge of Java is probably helpful in this day and age.

> library integration

Presumably the whole point of using a language that runs on the JVM is that you can use libraries written in Java.

In an ideal world, you should be able to use libraries written in any jvm-based language. It seems to me this isn't easily possible today with most jvm-based languages but maybe I'm wrong.

Yes, but Java is the middle-man providing the FFI, and implementing bindings to whatever library written in whatever language on top of the JVM is a lot easier. And it will get a lot more easier with the upcoming invokedynamic support (since right now the reflection mechanisms for calling methods are very slow).

Attila Szegedi is also working on a MOP for dynamic languages, which, if integrated by language designers, will make it possible to instantiate classes and call methods from modules written in other languages (much like the DLR, but with a different architecture) ... see here ... http://dynalang.sourceforge.net/

In an ideal world the would be no need for Java being the middle-man.

That project was founded in 2007. The last release is from 2008. Has anybody ever adopted it?

> In an ideal world the would be no need for Java being the middle-man.

Not possible, ideal world or not.

Programming languages have different type-systems. First of all you can't have the VM optimize for all of them, so the priority is always the primary language (Java for the JVM, or C# for .NET).

The second problem is that those type-systems have behaviors defined either at compile-time, or at runtime.

For instance, in Haskell a method is resolved / specialized on the use-site (based on the arguments provided) at compile-time, since by design, all types are known. If you call that same method from Java, you can't use the same interface ... you'll probably call a proxy, that based on the types provided (at runtime this time) it would find the right method and call it (with a call-site cache to optimize future calls).

Another example ... Common Lisp has multi-dispatching. It makes sense for Lisp, but not so much for Ruby. And Java has single-dispatching too. Simulating multi-dispatching on top of the JVM is not easy (it will be easier with invokedynamic and MethodHandles) ... and even if some kind of multi-dispatching was implemented, which one? Asymmetric or symmetric?

The only way to communicate with a language efficiently is trough the standardization of a MOP. But that's also hard to define because of the same reasons ... the author of IronScheme for example was considering dropping support for the DLR because it wasn't a good match.

Progress is going slowly since every

That project was founded in 2007. The last release is from 2008. Has anybody ever adopted it?

If you'll look at the repository, there are regular commits. I'm following the "JVM languages" google group, and the author is communicating regularly with people like John Rose (JVM / invokedynamic) and Charles Oliver Nutter (JRuby) among others, getting feedback, providing feedback, and Charles even attempted an integration of JRuby at some point. I don't really know the state of that.

In the case of such a project you have to please everyone, being a complicated matter from both a political and technical point of view.

If you are truly interested in such things, you can always scratch your own itch ;)

I wouldn't say "not possible". Interoperability between java and groovy is quite good. It's to some degree true for clojure and scala -- two languages I haven't used myself yet. There are example snippets around in the Internet that demonstrate that a combination of groovy/scala/clojure/jruby is possible. So the situation isn't that bad.

Ok, but to create a wrapper for the Java library, you probably need to grok Java enough to read the documentation and create some code that sits on top of it.

With JRuby (and I think scala and clojure as well) you only need to know the API and how to get the class or jar file onto you load path.

There are times when a Java method demands a specific Java type and JRuby does not automatically convert correctly, but mostly the use of Java libs from JRuby is pretty trivial, and the only time I've had to write Java to wrap anything was when I wanted a nicer API for some 3rd-party crypto libs and adding a few methods to the Java source was easier for me.