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:
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:
- Ruby the Language
- It is "opinionated software". (Countered)
- Simplicity
- Convention Over Configuration
- Community
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.
/filters:no_upscale()/sponsorship/topic/c1372aee-0449-48ce-bab0-1b645fe8025e/QConLonndonLogoRSB-1667564544484.png)
/presentations/java-compiler-intermediate-representation/en/smallimage/chris_seaton-s-1679038354209.jpg)
/presentations/jfr-observability/en/smallimage/Ben Evans-s-1675024642432.jpg)
/articles/graalvm-java-compilers-openjdk/en/smallimage/small-image-jdk-2023-1671096273181.jpg)
/articles/java-jvm-trends-2022/en/smallimage/InfoQ-Trends-Report-small-1670863712433.jpeg)
/presentations/java-shared-memory-files/en/smallimage/peter-lawrey-s-1669107216422.jpg)
/articles/josh-long-spring-6/en/smallimage/logo-1669141674434.jpg){kind=logo}
/presentations/devops-java-devs/en/smallimage/Ix-chel Ruiz-s-1669107288266.jpg)
/presentations/log4shell-security/en/smallimage/Simon-maple-s-1665986617483.jpg)
/presentations/loom-java-concurrency/en/smallimage/Tomasz Nurkiewicz-s-1665739004716.jpg)
/articles/java-virtual-threads/en/smallimage/logo-1663737114685.jpg){kind=logo}
/minibooks/jhipster-mini-book-7/en/smallimage/logo-1677849630224.jpg){kind=logo}
/articles/series-apache-kafka-streams/en/smallimage/apache-kafka-article-series-logo-small-1673455781546.jpg){kind=logo}
/minibooks/2022-infoq-trends-reports/en/smallimage/LOGO-1672051527011.jpg){kind=logo}
/articles/secure-kafka-cluster-strimzi/en/smallimage/securing-a-kafka-cluster-in-kubernetes-using-strimzi-small-1671647644310.jpg)
/presentations/java-upgrade-path/en/smallimage/Andrzej Grzesik-s-1667476313077.jpg)
/presentations/jit-aot-tradeoffs/en/smallimage/qcon-plus-s-1665738630666.jpeg)
/articles/shift-left-api-standardization/en/smallimage/GettyImages-1059510610-1664896147152.jpg)
/articles/strimzi-the-gitops-way/en/smallimage/strimzi-gitops-small-logo-1664297048552.jpg){kind=logo}
/articles/framework-architectural-decisions/en/smallimage/logo-1679060242842.jpg){kind=logo}
Community comments
There is an answer
by Andreas Andreakis,
Java is not the problem
by Javier Paniza,
Re: Java is not the problem
by david m,
Re: Java is not the problem
by Bill Siggelkow,
Re: Java is not the problem
by Marc Stock,
Strongly typed vs Statically typed -- Whats the difference between the two
by karan malhi,
Re: Strongly typed vs Statically typed -- Whats the difference between the
by Chris McDermott,
Re: Java is not the problem
by Lex Luthor,
Re: Java is not the problem
by Bill Siggelkow,
Re: Java is not the problem
by Floyd Marinescu,
Re: Java is not the problem
by Javier Paniza,
Re: Java is not the problem
by Paul Beckford,
There is an answer
by Andreas Andreakis,
Your message is awaiting moderation. Thank you for participating in the discussion.
You dont need Rails to be productive with Java. I use (plain) Java with RIFE and it works perfectly well for me.
Java is not the problem
by Javier Paniza,
Your message is awaiting moderation. Thank you for participating in the discussion.
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,
Your message is awaiting moderation. Thank you for participating in the discussion.
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,
Your message is awaiting moderation. Thank you for participating in the discussion.
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,
Your message is awaiting moderation. Thank you for participating in the discussion.
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,
Your message is awaiting moderation. Thank you for participating in the discussion.
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,
Your message is awaiting moderation. Thank you for participating in the discussion.
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,
Your message is awaiting moderation. Thank you for participating in the discussion.
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,
Your message is awaiting moderation. Thank you for participating in the discussion.
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?
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?
Well, reading his post a little more closely (emphasis mine):
...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,
Your message is awaiting moderation. Thank you for participating in the discussion.
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,
Your message is awaiting moderation. Thank you for participating in the discussion.
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,
Your message is awaiting moderation. Thank you for participating in the discussion.
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.