Skip to main content

What non-Java language are you most interested in running on the JVM?

JRuby
21% (417 votes)
Groovy
27% (544 votes)
Jython
12% (229 votes)
JavaScript
12% (248 votes)
Visual Basic
5% (97 votes)
Something else
10% (196 votes)
Not interested
13% (257 votes)
Total votes: 1988

Comments

Groovy and Grails

I just picked it up as well and bought both books. I am studying now to try and make it useful in my work. I think it is going to be a terrific tool.

Scala

+1

LINQ

OK, so this is not a language, but I would like to see LINQ like features in Java.

Scala

+=1

Scala

+=1

Scala

+10

Scala

+10

VB or Excel macros

One of the most common, if not the most common, script language used is Excel. Talk to almost any accountant or business type, and they will have written Excel macros. Excel macros use to be taught as a course in Business school, and still might. [Some reports have said that there are more lines of code in Excel, then any other language, even more then COBAL] If I want to expose my application to business individuals, I want them to use a syntax they know and are comfortable.

Scala, JRuby, Groovy, Scheme, F3 ...

Scala, JRuby, Groovy, Scheme, F3 ... Regarding the future of languages on the JVM, I hope that: 1) more dynamic and/or weakly-typed languages gain a strong user-base on the JVM. (Obviously I'm not alone there!) 2) at the same time, Java retains its static, strongly-typed character. I don't want to see inconsistent new syntax tacked onto Java, resulting in a Perl-like "too-many ways to do it" mess. If people want closures, great (I do), why not use Groovy or JRuby? (If backwards-compatibility allowed, I would actually like to see Java become more strict - eg. variables declared private and final by default). 3) that with the current rapid improvements in performance, Desktop APIs and the JSR-296 Swing Application Framework, Swing becomes the GUI Toolkit of choice for languages like (J)Ruby and (now that Sun's Java implementation is GPL) maybe even Python (in the form of Jython). Now that would be interesting ...

Scala, JRuby, Groovy, Scheme, F3 ...

Closures have nothing to do with static vs. dynamic typing. I think we all agree that Java itself should stay static. But some of us would like closures, too, instead of having to continue doing insane code duplication or workarounds. I'm also a big TOOWTDI person, and closures (ideally with continuations for turning things into external generators) are the way to do it.

Scala, JRuby, Groovy, Scheme, F3 ...

I apologize for my poorly worded comment. I do realize that: 1) Closures are a completely separate issue from static -v- dynamic typing. 2) A Java without strong and static typing would simply not be Java. What I really should have said was: I don't want to see features from other languages - be they dynamic (Ruby, Groovy), static (C#) or otherwise (SQL) - bolted onto Java in an unsympathetic manner. Also I don't want to see Java's syntax relaxed for the sake of convenience. For me, these would make doing things in Java in the most simple, robust, consistant, secure and performant way, less intuitive. In general, it might be safer to let Java be Java and let new languages provide new features ... I feel this way because I was disappointed by the compile-time only implementation of Generics - the added complexity did not seem worth it due to the compromises made. So I wonder how well other new features can be retrofitted into Java when breaking backward-compatibility is not an option ... Regarding Closures: I wish they had been in Java from the start - they would have been much neater and much more powerful than Inner Classes ... if they can be implemented without introducing unintutive special cases, then I hope they make it into Java 7 ... though I would regret that Java would become less TOOWTDI because Inner Classes can be used (less neatly) in places where it would be be neater to use Closures ... To end with unambiguously positive note: with Sun's Java going GPL and the growing support of "Non-Java" languages on the JVM, this feels like really exciting time for the Java Platform ...

C, E, Fortress, Fortan, and Beanshell

Yes, yes, and yes. I would also add C, E, Fortress, Fortan, and Beanshell to your list.

C, E, Fortress, Fortan, and Beanshell

Yeah BeanShell deserves a mention. While developing, I often keep a BeanShell console open for simple on-the-fly experimenting - to see whether things behave as I think they will from reading the API doc ... And I when I find the time, I will be taking Fortress for a spin ...

bash

System scripts in Java ...

What about Scala?

Let's list Scala in the languages we most like to run in the JVM!

What about BeanShell and F3 ?

Delphi or Object Pascal ?

Would it be possible to implement a language that uses pointers? If so, it would be wonderful to be able to use Delphi or Object Pascal in conjunction with Java.

Other languages?

Scheme, of course!!

BeanShell is missing

Despite all the talking on scripting languages I only see an advantage in BeanShell as a kind of hands on Java. Once I often used Perl, but never again, since Java added regular expressions. Other scripting languages just are not my thing. I tried Ruby and Python. They have nice ideas, but then why learn all these new idioms. I invest my time and interest in Java APIs :-) It is better to know one thing very well than to know many variations to achieve the same thing. I am no computer scientist, but use computer programming just as a tool for science and as a hobby

C# maybe

I might be interested in a C# implementation that runs in a JVM, but little else. Scripting languages just aren't my thing and VB? (brrrrr).

C# maybe

I would also be very interested in C#.

C# maybe

I agree, too - or, better yet, Smalltalk!

C# maybe

I concur, C# could be a really nice language to use next to Java and the plethora of scripting languages for the lighter work. The C# spec itself (the language spec, not the classlibs) are defined in an open standard, right?

C# maybe

yes, C# is an ISO candidate (maybe approved already) AFAIK.

VB

VB... But the project is dead.....

If it runs on the JVM, it's not a non-Java language

Am I right? Once it runs, it is either being interpreted in Java, in which case you're running Java, or it is bytecode. The bytecode and the JVM are integral parts of Java. So even if the source code was not in "the Java language" (as we formally call it), it's not a NON-Java language either.

OK, it's semantics... and syntax, of course.

If it runs on the JVM, it's not a non-Java language

Then I guess by that logic all scripting languages written in C are actually C languages. Or perhaps they're assembly language dialects? The JVM is a machine. Bytecodes are its instructions. An implementation of a language for the JVM is just as non-Java as an implementation for x86 is non-assembly.

If it runs on the JVM, it's not a non-Java language

The term Java, among other things, designates both the language and the platform. So the title is correct and should be meant as "what non-Java language would you like to see running in the Java platform?"

The oldie is still a goodie...

...BeanShell.