Develop Reference

Why does Java have a central API documentation, but not C++?

Question pretty much explains it all. I've been wondering why Java has nice, organized and centralized API documentation, but C++ library definitions seem to be scattered across the internet?
Is it because Sun put some effort behind making Java API documentation easy and accessible? Thanks in advance.

What you call "nice, organized/centralized, API" for Java is probably the documentation of Oracles's official implementation. C++ implementations also have their own documentation, for instance, GNU's implementation is well documented in http://www.gnu.org/s/libc/manual/ (the C part), and in http://gcc.gnu.org/onlinedocs/libstdc++/ (the C++ part; see section "API and Source Documentation"). You will also be able to find in MSDN Library the full documentation for Microsoft's C++ implementation.
You probably find Java API more concise and well documented because there is only one serious implementation of it (Oracle's original implementation), making its documentation the very resource for the language itself.
On the other hand, C++ is a standard, implemented by a wide variety of vendors, and many documentation resources are not even based on any specific implementation, but in the standard itself. In the end, different C++ resources on the Internet tend to outstand others in some areas. For instance, cplusplus.com concentrate good documentation about <iostream>, <string> and beginners topics, while the documentation of SGI's implementation of STL (http://www.sgi.com/tech/stl/) became the reference resource for STL, probably because of its completeness and very good organization.

C++ has a language specification, and a set of standard libraries.
Java also has a language specification, and also has set of standard libraries.
I don't really see any fundamental difference between the C++ standards and the Java standards, except that Java also comes with a standard implementation (from Oracle, formerly Sun).
PS:
Admittedly, Java has a standard API for GUI's (Swing), and C++ doesn't. But do you really want to force a "standard" like Windows MFC, to the exclusion of alteratives like Qt?

Part of the difference comes from the fact that the C++ standard library is not as well defined as the Java equivalent. The C++ standard leaves a lot of room for implementations to behave slightly differently in certain cases, a luxury Java does not provide. So for Java, once you have one good, quality set of docs, you're done... everything you need to know is right there. But with C++, STLPort's documentation won't necessarily match Dinkumware's, for instance, and you end up with lots of scattered documentation.

One reason is that C++ is not tied to single vendor, so it's not centralized by default.
Another reason is that Java provided documenting comments as part of the language and Javadoc was available from the beginning as one of the standard JDK tools. This had an impact on availability of API docs. Generating API doc was always a natural stage in Java build model.
C++ is a different story. I have met following comment by Nathan Myers in GCC's basic_string.h implementation.
Documentation? What's that?
Only recently Doxygen established a de facto standard. For a long time documenting comment was like black magic. Each project relied on its own tools and even though some projects had very nice docs, those tools were not available for a general use. I remember people begging Trolltech to release Qt documenting tool but this never happened.
Accidentally stepped into this answer and realized it needs an update. In a meantime Qt Company has actually released QDoc. Moral: never say never.

Good start for .Net and c++ to Java transition?

I know the .Net framework very well and know where to find things ie: StreamReader, StreamWriter, Graphics, etc, and I know Java has similar things. The syntax is different but quite similar to c++ which I have a lot of native c++ experience. Therefore, what would you recomend as a good starting point for tutorials and such. Thanks

In my new job, I quickly found myself working on a common library in C++, C# and Java. I had no Java knowledge and yet found it pretty intuitive to make simple mods to the Java code - the general C# principle that there is a framework class/namespace for most things you want to do, appear to hold in Java.
The thing that bothers me is that this MO would not teach me tricks and improvements in Java that are specific to that language. That's where I would like to see other answers to this question lead.
In the meantime: http://en.wikipedia.org/wiki/Comparison_of_C_Sharp_and_Java
btw while I found C# and Java pretty congruent, I would not say the same about C++ vs Java.

If you work in eclipse/netbeans/intelliJ it may actually be a no-brainer. Guess at a class name, start typing it and hit ctrl-space (for eclipse, others vary). Regardless of which package it is in, it will find all the classes that match and list them for you faster than you could look them up anywhere else.
The other really nice thing to have on hand is the javadocs for the SDK you are working with--you can code effectively with nothing else. They are online (just search for JDK 6.0 or whatever version) or they can be downloaded from the same place you get the JDK.

The javadocs are your friend - once you figure out some of the main packages in java.*, it's easier to know where to look for specific classes / functionality.
Once you're writing some code, buy Effective Java - it's full of tips for the language, and is just a good programming book.

Can a second implementation of a programming language be written in that language?

This question is just something that I have been thinking about lately. Can a programming language be written in that language as a second implementation? e.g. Java. Is it possible to rewrite the java programming language using the java programming language?
Apologies if this is a silly question but I need to know!
GF

Always. Any Turing-Complete language is -- well -- a Turing-Complete language. If you can write the compiler in one complete language, you can write it in any equivalent language.

Yes, it is possible. Check out BootStrapping.

Yes for any Turing Complete language. Lisp comes to mind as one of the easiest languages to write an interpreter/compiler for itself.

It can. A recent example is that python has pypy. A little more information is on the Wikipedia page and some good links.

Sure.
Many many years ago one of my first home computers, a Vic 20, came with a built-in BASIC interpreter but that was it. So I wrote the first version of an assembler for it in BASIC. Then I used my first primitive assembler to write a better assembler.

Yes. As long as the language is Turing Complete, you can implement the language in itself.

There are many practical examples of this, one example is the Oberon Language, which is of interest in this discussion because the compiler code is very readable it's in the book Project Oberon available for free:
http://www.oberon.ethz.ch/bibliography/publications
http://en.wikipedia.org/wiki/Bootstrapping_(compilers)

The GCC compilers are written in C.
It has been a long time since anyone built any C compilers from assembly.

Not just possible, but for native-code compilers, this is the most common implementation technique. A good how-to guide is Andrew Appel's paper Axiomatic Bootstrapping: A Guide for Compiler Hackers.

It not only can, it is. ecj (Eclipse's compiler) is one example, and I think the SDK itself comes with a pure Java compiler, though I could be wrong about that.

write a java compiler in java - no problem at all. actually I think Sun's javac is written in java.
however, 'java' usually means more things than just the javac, so your question isn't very clear.

Sure. I've even seen someone write a COBOL compiler written in COBOL! (OK, not a full compiler ... but at least a parser.)

Check out 3-LISP

Approaching Java from a Ruby perspective

There are plenty of resources available to a Java developer for getting a jump-start into Ruby/Rails development. The reverse doesn't appear to be true.
What resources would you suggest for getting up-to-date on the current state of java technologies? How about learning how to approach DRY (don't repeat yourself) without the use of metaprogramming? Or how to approach various scenarios where a ruby developer is used to passing in a function (proc/lambda/block) as an argument (callbacks, etc)?

You might start out by learning Groovy and Grails, which may seem a bit more familiar to you. Then you can start learning more of the Java side of Groovy to get familiar with what Java can do. Eventually (if you need to) you can move into 100% Java.
Groovy is in many ways similar to Ruby (at least from my Ruby-novice view), but you also have full access to Java libraries and coding.
I guess you might also look into JRuby first rather than Groovy since it is a Java-based implementation of Ruby.
The best thing to do is consider what you would want to do with Java and try to dig deeper into that area. Java as a whole has gotten pretty unwieldy over that last few years.
Good luck and I hope this helps a little.

I wouldn't start with the "current state" of Java. Like #chstehno said, Java is huge, and a bit of a mess. Focus on learning the basics, then delve in the the libraries as they become relevant to what you're working on.
I went from Java (and a bunch of other old school languages) to Ruby, so I can't speak to going the other way, except to say that Java is a lot more "by the book" and you can figure out a lot just by reading and searching through code, whereas that can be tough in Ruby with all of the mixins, lambdas, and convention-based magic in frameworks like Rails.

Advantages of Java over Ruby/JRuby

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.

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.

I don't know Ruby very well, but I can guess the following 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 more widespread adoption than Ruby
Java has a well-specified memory model
As far as I know, Java has better support for threading and unicode (JRuby may help here)
Java's overall performance is quite good as of late (due to hotspot, G1 new garbage collector, etc.)
Nowadays, Java has very attractive and cheap server hosting: appengine

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.

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.

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)

I like this Comparison(Found on link Given by Markus!Thanks!)... Thanks to all... i am also expecting some more discrete advantages
And its Great!!

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).

This has probably been beaten to death, but my personal opinion is that Ruby excels at quickly created web apps (and frameworks) that are easy to learn, beautiful to read, and are more than fast enough for web apps.
Where Java is better suited for raw muscle and speed.
For example, I wrote a Ruby program to convert a 192 MB text file to a MongoDB collection. Ruby took hours to run. And the Ruby code was as simple/optimized as you could get (1.9.2).
I re-wrote it in Java and it runs in 4 minutes. Yes. Hours to 4 minutes. So take that for what it's worth.

Network effect. Java has the advantage of more people using Java. Who themselves use Java because more people use Java.

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.

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.

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.

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.

Better performances

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 :)

Reading up on this : 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