BT
x Your opinion matters! Please fill in the InfoQ Survey about your reading habits!

Must Java Have an Answer to Rails?

by Scott Delap on Feb 19, 2007 |
The software industry runs in cycles of comparisons. Features are matched point by point. Entire API groups are developed not only to fill a need but to answer the question does your language have X. This raises the question:

Does Java need an answer to Rails?

There are two trends playing themselves out in response to this question. First there is the concept of simply running the Ruby language and in turn Rails under the JVM. One could argue with this route no other answer is needed. JRuby is fast approaching the capability to run over 95% of Rails tests. The alternative to this approach is recreating the secret ingredients that makes Rails a success in a rival web application framework for Java. Among the items proposed:

Bloggers have been discussing the other concept of creating comparable frameworks in Java that catch the secret combination. Options include Seam, Trails, Sails, and Grails.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

There is an answer by Andreas Andreakis

You dont need Rails to be productive with Java. I use (plain) Java with RIFE and it works perfectly well for me.

Seam by Alexandre Poitras

What about Seam? I though it was one of its goal (bringing RoR simplicity and productivity to the Java EE platform without all the burden)

Java is not the problem by Javier Paniza

Java is not an intrinsically complicate language. The applications, frameworks, specifications, etc. that we develop are complicate, but not Java. I think that is a cultural issue, not a technical one, the GoF patterns, MVC, 3 tiers, distribuite object, etc. we need to do these thing in order to choose the right way. The error is in the Java developers not in Java language.

About Ruby, I personally prefer Java simply because it's a strong typed language, in this way the compiler is always our friend. Remember the the real problem of software is not in the initial development. Remember the Meyer's words about Eiffel vs Smalltalk (a 80s debate).

Re: Java is not the problem by david m

You raise an important point. Java proper is a simple language, but mastering it for complex dev is really about understanding the whole scene. Sometimes this fundamental knowledge is pure wisdom, sometimes its arbitrary history and distracting baggage. Which is hard for a newcomer or someone who wants to get something "straightforward" done.

Sun and the other big names don't seem to be able to get on top of this, solutions like JSF just add more complexity. EJB3 however is a good step.

Some of the new solutions like Rife and Seam are more focused, but there are too many of them and once you get deep enough you find the same assumptions. As time goes by they pick up their own idiosyncracies and you lose the advantages of the Java ecosystem. And few offer the zero turn around time development that other languages offer.

That said, with competition it looks like 2007 will be a good year for Java becoming less complicated, and hopefully it will gain developers rather than lose them.

Re: Java is not the problem by Bill Siggelkow

Ruby *is* as strongly-typed language. Just do a bit of research and you will see. Java is becoming the modern-day equivalent of Cobol. Programming languages evolve just as hardware does. Ruby (and other dynamically-typed languages) allow developers to write less code that does more ... period.

Re: Java is not the problem by Marc Stock

Ruby *is* as strongly-typed language. Just do a bit of research and you will see. Java is becoming the modern-day equivalent of Cobol. Programming languages evolve just as hardware does. Ruby (and other dynamically-typed languages) allow developers to write less code that does more ... period.


1) He meant statically typed and you know it so why are you acting like you don't?

2) For being a Cobol-like language, Java is doing quite well for itself. I don't think anyone has seriously argued that Java is the best language. However, Java has a lot going for it besides its language semantics. Do some research and you will find that the semantics and "neato factor" of the language have little to do with the success of the language.

3) As for writing less code that does more...this is nothing new. It's called Smalltalk. Look into it sometime when you get off your Ruby high-horse. Smalltalk is also "strongly typed". :)

Re: Java is not the problem by Javier Paniza

Sorry,

I mean "static typed". Remember, I said Eiffel vs Smalltalk.

Strongly typed vs Statically typed -- Whats the difference between the two by karan malhi

What is the difference between Strongly typed, Statically typed, manifest type? Strongly typed and statically typed look the same to me. Can anybody shed some light on the details and how java and ruby differ in terms of which category they belong to?

Re: Strongly typed vs Statically typed -- Whats the difference between the by Chris McDermott

Here's good reference on the subject - c2.com/cgi/wiki?TypesOfTyping

I hope that helps answer your question.

Re: Java is not the problem by Lex Luthor

Ruby *is* as strongly-typed language. Just do a bit of research and you will see. Java is becoming the modern-day equivalent of Cobol. Programming languages evolve just as hardware does. Ruby (and other dynamically-typed languages) allow developers to write less code that does more ... period.


1) He meant statically typed and you know it so why are you acting like you don't?


Wow... just.. uhm... wow. Did Mr. Sigglekow's response really demand such hostility? Maybe he doesn't know Eiffel or Smalltalk or simply know what type-ing is used in each?


2) For being a Cobol-like language, Java is doing quite well for itself. I don't think anyone has seriously argued that Java is the best language. However, Java has a lot going for it besides its language semantics. Do some research and you will find that the semantics and "neato factor" of the language have little to do with the success of the language.


Ok, I'll bite -- what exactly does contribute to the success of a language since you imply you have this knowledge? I imagine you'll find far less desirable traits than semantics -- sure you want Java to own up to those?


3) As for writing less code that does more...this is nothing new. It's called Smalltalk. Look into it sometime when you get off your Ruby high-horse. Smalltalk is also "strongly typed". :)


Well, reading his post a little more closely (emphasis mine):

Ruby (and other dynamically-typed languages) allow developers to write less code that does more ... period.

...would seem to imply that Smalltalk could be included in his statement. Naturally, you assume he's a Ruby bigot -- very noble of you. And besides, he was implying Ruby semantics are more concise than Java; not that Ruby is the originator of such things.

It's absolutely amazing how some people will go to no ends to defend their little realm when someone else even implies there might be better alternatives...

Re: Java is not the problem by Bill Siggelkow

It's amazing to me that people get so vehement went it comes to these discussions. The interesting part is that I have been programming in Java since 1996, and earn quite a nice living from Java on a day-to-day basis. I guess I was castigated for not having tunnel vision when I stated my opinion.

Re: Java is not the problem by Floyd Marinescu

Lex - InfoQ does not allow posting under aliases, and we would like to ask that people simply adhere this out of an honour policy. InfoQ is a serious site for serious people who can stand by their name. Unless you are indeed Superman's arch-enemy, I'd ask that you either not post or change your name back.

thanks,

Floyd
InfoQ co-founder

Re: Java is not the problem by Paul Beckford

This static versus dynamic typing nonsense is really boring... If you take the time to look into it then you would see that if you choose you can readilly add static type-checking to any dynamic language, the two issues are orthogonal. Infact the best static type system I've come across belongs to a dynamic language: Strongtalk.

At least Strongtalk doesn't confuse Type (Interface) with Class (Implementation) like many hybrid OO languages do. What always happens in this type of debate is that people tout things they've read or got taught way back in the day as though it is the gospel truth, instead of thinking for themselves.

Large complex systems have been built using both static and dynamic languages so why always the FUD?

Paul.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

13 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT