I am learning Java. I have learned and used Ruby. The Ruby books always tell the advantages of Ruby over Java. But there must be some advantages, that's why lots of people (especially companies) use Java and not Ruby. Please tell the absolute(not philosophical!) advantages of Java over Ruby.
+14
A:
- Many more developers experienced with Java than with Ruby.
- Many existing libraries in Java (That helps JRuby too).
- Static typechecking (can be seen as advantage and as disadvantage).
- Existing codebase that has to be maintained.
- Good tool-support.
- More and deeper documentations and tutorials.
- More experiences with good practices and pitfalls.
- More commercial support. That's interesting for companies.
Many of these advantages are the result, that the Java-ecosystem is more matured, than that around Ruby. Many of these points are subjective, like static vs. dynamic typing.
Mnementh
2009-08-20 09:33:05
You might more accurately say that while the languages are about the same age, the Java ecosystem is more mature than the Ruby ecosystem. And I wouldn't assert unilaterally that that's an advantage, either; maturity often brings tedium (see: Java Community Process).
Sarah Mei
2009-08-20 22:16:33
@Sarah Mei: You are right, Ruby was released 1995, so it isn't much younger than Java. I didn't know that. I change that, as you said. And yes, maturity can't only seen as advantage. But that's like static typic, also here some people would say it's actually a disatvantage. It's subjective.
Mnementh
2009-08-21 07:38:08
"More and deeper documentations and tutorials". Really? Just one example off the top of my head, I found the documentation for doing xpath much better on the ruby side. The java side is a giant mess.
jshen
2009-11-16 19:35:51
+6
A:
Please tell the absolute … advantages of Java over Ruby
Programmers should rarely deal in absolutes.
I'll dare it, and say that as a rule, static typing (Java) is an advantage over dynamic typing (Ruby) because it helps recognize errors much quicker, and without the need to potentially difficult unit tests1).
Harnessed intelligently, a strong type system with static type checking can be a real time-saver.
1) I do not oppose unit testing! But good unit testing is hard and the compiler can be a great help at reducing the sheer number of necessary test cases.
Konrad Rudolph
2009-08-20 09:34:10
Ruby *has* a strong type system, so I assume you mean that Java's time savings arise from the static type checking. It does catch some errors. I wonder, though, if the time saved by that is outweighed by the time you spend writing a much higher volume of code. It would be interesting to see some numbers on that.
Sarah Mei
2009-08-20 22:10:08
@Sarah: yes, I know – but I was talking about *static* type checking, something Ruby does *not* offer. I agree on the numbers, but my (very subjective) experience tells me that yes, static type checking (combined with an extensible type system) helps a lot. I encourage you to read my answers at http://bit.ly/iwiUs and http://bit.ly/rx3ap where I expand on the argument.
Konrad Rudolph
2009-08-21 08:25:48
Interesting - thanks for the pointers. I disagree, though, that writing good unit tests is hard, or that it delays feedback of errors. To address the former: I find that writing the unit tests first, before writing the code, forces me to visualize how I'll use the code. Once I have that, it's usually obvious what kinds of errors I'll encounter if I use it differently, and I can add tests for those.
Sarah Mei
2009-08-21 17:43:02
To address the latter: you can set up a background process while you're programming that constantly runs the tests and informs you of failures. It can be subtle, so it doesn't interfere with what you're doing - a stoplight in the task bar that turns from green to red when there's a failure, and back again once you fix it. If you're on OS X you can use growl, but I find that a little too distracting. Tests shouldn't be something you only run on check-in; if they are, perhaps because they take too long, you need to find ways to run subsets and/or run them continuously so you're not waiting.
Sarah Mei
2009-08-21 17:47:12
Unfortunately, the comment space isn't a great place for a discussion. I've been yearning to write a longer text about static typing, perhaps I'll find time someday soon. That said, great hint about the background process. I've never seen unit tests done like that and it sounds really useful.
Konrad Rudolph
2009-08-21 18:54:26
+5
A:
Reason #1. There's a lot of legacy Java code out there. Ruby is new, there's not so many programmers who know it and even fewer who are good at it. Similarly, there is a lot more library code available for Java than Ruby.
So there may be Technical reasons Ruby is better than Java, but if you're asking for Business reasons, Java still beats it.
gbjbaanb
2009-08-20 09:34:16
Actually, Ruby is almost exactly as old as Java. But until Rails, it was just an obscure language that hardly anyone (especially outside of Japan) had ever heard of.
Michael Borgwardt
2009-08-20 10:18:31
+1
A:
If you have to build a big software, you'll need to collaborate. By having a lot of programmers out there, you are sure that there will be someone that can be asked to maintain your software even if the original developers have left the company.
Static type checking and good Java IDE offer no magic and this is good for a lot of maintainer instead of Ruby.
nanda
2009-08-20 09:41:26
+9
A:
I don't known very well Ruby, however I can guessing these points:
- Java has more documentation (books, blogs, tutorial, etc); overall documentation quality is very good
- Java has more tools (IDEs, build tools, compilers, etc)
- Java has better refactoring capabilities (due to the static type system I guess)
- Java has a widespread adoption than Ruby
- Java has a well specified memory model
- as far I know Java has better support for threading and unicode (JRuby may helps here)
- Java overall performances are quite good nowdays (due to hotspot, G1 new garbage collector, etc)
- nowdays Java has a very attractive and cheap server hosting: appengine
dfa
2009-08-20 09:44:57
Hey @dfa, now that i have learnt some Java, i would like to know more about refactoring capabilities of Java. DO you have any good pointers for that?
Webbisshh
2010-03-28 07:30:32
+1
A:
It is not sufficient to indicate that java is statically typed and ruby is dynamically typed.
Correct me if I'm wrong, but does this cover the fact that in ruby you can add to and even change the program (class definitions, method definitions etc) at runtime? AFAIK you can have dynamically typed languages that are not "dynamic" (can be changed at runtime).
Because in Ruby you can change the program at runtime you don't know until you've actually run the program how it is going to behave, and even then you don't know if it will behave the same next time because your code may have been changed by some other code that called the code you're writing and testing.
This predictability is, depending on the context, the advantage of Java - one of the contexts where this is an advantage is when you have a lot of developers of varying skill levels working on a fairly large enterprise application.
Michael Wiles
2009-08-20 09:58:40
How on earth does Java geta C on new developer learning curve? It is **way** simpler as a language than Ruby. I'm not dissing Ruby as it's more expressive than Java - but this is because the language contains many more constructs and ways of doing things. Typically in Java there is one way of achieving a goal: much simpler
oxbow_lakes
2009-08-20 10:37:49
there are some points that are completely subjective like software licensing, rapid feedback, etc
dfa
2009-08-20 10:48:01
hey! java has a huge APIs and all but its a bit difficult to learn for sure... take an example of input! lot of efforts are required for taking input only. thats the most basic thing.... and that's more difficult.
Webbisshh
2009-08-20 11:46:32
It's still comparing a language with a framework, which makes little sense. Multi-threading in Ruby, for example, is about the same as Java - if you use JRuby, which runs on the JVM. It's also out of date - Ruby 1.9 has much stronger Unicode support. I'm not saying it's all bad, just that the basic premise is flawed.
Mike Woodhouse
2009-08-20 12:07:03
@oxbow_lakes - I checked your profile before I wrote this comment and I was expecting to find a first-year CS student. Ten years of Java experience and you seriously assert that Java has only one way of doing anything? Perhaps you meant there is one idiomatic way of doing things. If so, you should know that the same is true in Ruby.
Sarah Mei
2009-08-20 22:31:17
+3
A:
The Java Virtual Machine, which has had over a decade of improvements including:
- just in time compilation in the HotSpot compiler (JIT - compiling byte code to native code)
- a plethora of garbage collection algorithms and tuning parameters
- runtime console support for profiling, management etc. of your application (JConsole, JVisualVM etc)
oxbow_lakes
2009-08-20 10:15:09
A:
IMHO, what one person considers an advantage might be a disadvantage for someone else. Some people prefer static typing while others like dynamic. It is quite subjective and depends largely upon the job and the person doing it.
I would say just learn Java and decide for yourself what its strong points are. Knowing both languages yourself beats any comparisons/advice some other person can give. And its usually a good thing to know another language, so you're not wasting your time.
MAK
2009-08-20 11:09:29
+1
A:
The language.
My opinion is that the particular properties of the Java language itself lead us to the powerful capabilities of the IDEs and tools. These capabilities are especially valuable when you have to deal with very large code-base.
If I try to enumerate these properties it would be:
- of course strong static typing
- the grammar of language is a LALR(1) grammar - so it is easy to build a parser
- fully qualified names (packages)
What we've got in the IDE so far, for example Eclipse:
- great capabilities of exploring very large code bases. You can unambiguously find all references, call hierarhy, usages of classes or public and protected members - it is very valuable when you studying the code of the project or going to change something.
- very helpful code editor. I noticed that when I writing code in the Eclipse's java editor I'm actually typing by hand only names of calsses or methods and then I press Ctrl+1 and editor generates a lot of things for me. And especially good that eclipse encourage you to write the usage of piece of code first and even before the code is aclually writen. So you do the method call before you create the method and then editor generates the method stub for you. Or you add extra arguments to the method or constructor in the place when you're invoking it - and editor change the signature for you. And enev more complicated things - you pass some object to the method that accept some interface - and if the object's class do not implement this interface - editor can do it for you... and so on. There's a lot of intresting things.
There is a LOT of tools for Java. As an example of a one great tool I want to mention Maven. Actually, my opinion is that the code reuse is really possible only when we have such a tool like Maven. The infrastructure built around it and integration with IDE make feasible very intresting thinsg. Example: I have m2eclipse plugin installed. I have new empty project in the Eclipse. I know that there is a class that I need to use (reuse actually) somewhere in the repositories, let say StringUtils for example. I write in my code 'StringUtils', Eclipse's editor tell me that there is no such class in the project and underlines it with red. I press Ctrl+1 and see that there is an ability to search this class in the public repository (actually in the index, not the repository itself). Some libs were found, I choose one of them at particular version and the tool downloads the jar, configures my project's calsspath and I alredy got all that I need.
So it's all about programmer's productivity.
The JVM.
My opinion is that the JVM (Sun's HotSpot particularly) is a one of the most intresting pieces of software nowadays. Of course the key point here is a performance. But current implementation of HotSpot JVM explores very cutting edge ways to achieve such really great performance. It explores all possible advantages of just-in-time compiling over static, collects statistics of the usage of code before JIT-compile it, optimise when it possible virtual calls, can inline a lot more things that static compiler can, and so on. And the great thing here that all this stuff is in the JVM, but not in the language itself (as contrary with C# as example). Actually, if you're just learning the Java language, I strongly encourage you to learn the details of modern implementations of JVM, so you know what is really hurt performance and what isn't, and do not put unnecessary optimizations in the Java code, and do not afraid to use all possibilities of the language.
So... it's all about IDEs and tools actually, but by some reason we have them for Java not for any other language or platform (.NET of course is a great competitor in the Windows world).
alsor.net
2009-08-20 13:53:35
So the only advantage Java has over Ruby is that its tool support is more mature? That's a pretty low bar.
Sarah Mei
2009-08-20 22:24:42
@Sarah - the value of this advantage very depends on the size of the project (or several projects within one big system) and the size of the team. It is some kind of trade-off - you choose between language flexibility, expressiveness on the one hand and the order on the other hand. BTW, don't forget that we can mix up things - we have JRuby and another scripting languages on the JVM - this is great.
alsor.net
2009-08-21 07:39:17
I agree that the JVM is a great platform to develop and deploy on. My point is that the tools aren't light-years apart now, so it's pretty easy to imagine a world in which there's tool parity. If there were, would anyone use Java outside of existing projects?
Sarah Mei
2009-08-21 17:31:21
I don't agree that full tool parity is possible. As I said, and is my opinion, that some powerful capabilities of tools for Java is a direct consequence of certain language properties.
alsor.net
2009-08-23 17:33:14
A:
There are more choices:
- Developers - lots to hire
- Libraries - lots of wheels already invented.
- IDE's - lots of development environments to choose from. Not only just vi/emacs + a shell.
- Runtimes - if you for some reason do not like the JVM you use on the system, you can either download or buy another implementation and it will most likely Just Work. How many Ruby implementations are there?
Please note that this has nothing to do with the LANGUAGES as such :)
Thorbjørn Ravn Andersen
2009-08-21 07:57:01
A:
Reading up on this : http://stackoverflow.com/questions/1310107/is-ruby-as-cross-platform-as-java made me realize at least one factual advantage of java over ruby:
The J2ME-compatible subest of java is more portable than ruby
as long as JRuby won't run on J2ME which may be forever
Jean
2009-08-21 08:02:59
I second that .. but i think Jruby should be able to overcome this drawback.
Webbisshh
2010-03-28 07:34:00
A:
Negatives for Java:
- There is a lot of duplication in libraries and frameworks available for Java.
- Java developers/communities tend to create over complicated solutions to simple problems.
- There is a lot more legacy in Java to maintain.
- Too much pandering to business users has introduced cruft that makes middle managers feel better. In other words, some philosophies in Java are more concerned with BS instead of getting the job done. This is why companies like to use Java.
- You'll generally need to write more code in Java than Ruby.
- It takes a lot more configuring/installing/setup to get a fully working Java development environment over Ruby.
Positives for Java:
- Speed.
- Documentation.
- Lower level language than Ruby, which could be a good thing or a bad thing, depending on your needs.
None of my points are very scientific, but I think the differences in philosophy and personalities behind Java and Ruby is what makes them very different to each other.
Dan Harper - Leopard CRM
2009-08-23 13:15:21