I'm more at the novice end of the software developer spectrum, but nevertheless I've had exposure to quite a few programming languages and frameworks. From all the technologies I've used, I haven't found any with an API as well-structured and user-friendly as Java's. Why is this? Why is it that robust languages such as C++, Perl and Python do not have APIs that come even close to Java's?
-
Which language did you start with?– Billy ONealCommented Jun 29, 2011 at 21:29
-
Do you have some examples, so we have a good idea of what kinda stuff you referring to?– tshepangCommented Aug 12, 2011 at 7:58
-
Java is all about APIs. It is a language for glueing readily available components together, so it is vital that components it is supposed to be used with are usable. Most of the other languages are used for different styles of programming, not that much API-centric.– SK-logicCommented Aug 12, 2011 at 14:23
-
I have a rather strong feeling that this question might have been about the API documentation rather than the actual API. If that's the case, I would certainly agree that Javadocs are by far easier to navigate than others I have worked with incl. Python– posdefCommented Feb 8, 2016 at 10:24
Add a comment
|
6 Answers
Your opinion might change as you get more experience with other languages. I have found the Java APIs to be rather poor:
Date and Calendar and related classes are a mess.
The collection classes are unwieldy, and don't play well with arrays. This is a problem because some methods return collections while other methods demand arrays. Very common Collection operations are missing. I found the C++ standard template collections to be more powerful, and more easily extensible.
The standard Java libraries support String split, but still do not support String join, which is available in almost every other language.
- Java I/O is inconvenient when compared to languages that allow streams to be processed as collections.
- The Java Reflection API is also quite unwieldy, but that may be more a function of the Java language design.
- There are far too many classes that have separate methods for passing objects of various types, e.g. setDate, setInt, setString, instead of set(Object).
- Other languages (Perl, Python, Ruby) have a common module repository. Java does not.
answered Jun 29, 2011 at 18:24
-
3To be fair, Date, Calendar, and related code is a mess everywhere. I don't think I've ever seen a Date/Time system that's not horribly messy, because the problem it's solving is inherently a horribly messy one. Commented Aug 12, 2011 at 0:34
-
@Mason: .NET's seems to work fine, especially if you use
DateTimeOffsetwhich encodes the actual offset instead of the time zone. Kind of hard to say "everywhere" unless you've used every library. Even JavaScript's date handling isn't all that horrible, for my money anyway. Commented Aug 12, 2011 at 1:32 -
@Mason: C had struct tm and time_t and at least it was clear how the worked. Java went wrong when they tried to do it all with a single Date class, and it's never been right since. Time zones are magically applied all over the place. Date and Calendar are mutable and hard to clone, exactly the opposite of what would be most useful. Then JDBC really confused things by mapping java.util.Date to a SQL DATE, when the representations are completely different. Try to find documentation for that conversion. Commented Aug 12, 2011 at 3:03
I'm curious to what you think of C# / .NET's api, btw, as far as I know it's on-par if not better than Java's. (Unbiased, I'm a Java guy myself)
As to your question, I have a few theories. The C++ libraries are built out of the old C library and the STL on top of that. Back when, it was one of the earliest standard libraries, and one of the first object-oriented programming languages (preceded by Smalltalk and probably a few others - I'm not too familiar with OO language history). This means not too much experiences yet, amongst other things.
What makes Java's (and .NET's) APIs / libraries / documentation better are two things:
- Experience
- Corporate support
Experience in that they were able to start with a clean slate at the time - no backwards compatibility with existing libraries required, so they could built a standard library that was based on the best ideas of the past, and then some. Of course, the actual quality of the API's / standard libraries has deteriorated some, mainly due to having to maintain backwards compatibility (example is the old Collection classes like Vector and Hashtable, which have been superseded by List and Map but are still in the API for the sake of backwards compatibility).
Corporate support is very important here, as this meant there was a team of people that could spend their whole working day writing the library and documentation. This is contrary to the languages / libraries without corporate support, which rely on volunteers and a community.
I'm pretty sure it's a matter of culture, too. Java (and .NET, too) are both very 'corporate'- high security, backwards compatibility, etc. Python and Lisp and such on the other hand are more aimed at the 'hacker' community (to generalize, I can't think of a better word). You don't see much Java in the *Nix world (and no .NET worth mentioning, for that matter), but a huge amount of Python, Lisp, and what-have-you.
-
Modified a bit the section explaining C and C++ providing a background for why Java has the advantage of being a cleaner version of the C++ language.– NeilCommented Jun 29, 2011 at 9:56
-
1.NET's API is structured fairly well, but documented pretty badly. In my experience most of the code samples are pretty useless, and e.g. a lot of documentation of properties doesn't tell you anything you couldn't already tell from the name except from whether it's read-only. OTOH Java has some APIs like this too - when I looked at Java3D its API doc was completely opaque and didn't seem to have any entry points. Commented Jun 29, 2011 at 10:03
-
1@Peter Taylor - I feel the opposite. I love .NET's documentation (for the most part) and feel that the Java docs are lacking.– JettiCommented Jun 29, 2011 at 20:58
-
Reverted back to the original answer -- there's no reason to turn this into a C++ bashing fest. Commented Jun 29, 2011 at 21:35
-
I haven't done much .net development yet, but when I did, I found the .net documentation in MSDN pretty helpful for my causes. YMMV Commented Jun 29, 2011 at 22:32
Java was written as a blue-collar programming language for professional programmers. (Which is why teaching Java to students is inappropriate)
Go look at the original Java stuff by James Gosling.
So it's got ugly bits in the libraries ( you get used to them and eventually they get fixed)
But it's also got a long history of conservative software engineering that doesn't break my million lines of code just to add gee-whiz language or library features. I don't want to assign resources to fixing version migration. There is no competitive advantage for me there.
Contrast with C#'s approach to generics, where you get a new collection library.
This conservative approach makes it hard to change library objects that are badly designed, but some progress is being made on that.
So a bit more time gets spent on polishing the documentation. And we get where we are today.
answered Jun 30, 2011 at 0:15
-
I don't want to assign resources to work around bad design. Besides, Java is also on the second version of collections; Vector and Enumeration are gone. Well, almost, but there are still popular libraries returning Enumerations. Commented Jun 30, 2011 at 4:52
-
@kevin, I'm not defending the design of bits of the Java API's. Java is a like a pickup truck. I have my John Deere cap. But the improvements are generally carefully thought out. I appreciate that. I'm looking forward to Java 8 and auto-paralleizing, vectorizing, offloading to the GPU inner iterators that take lambda functions on all the collection classes. Meanwhile, the pickup works. Large programs can be maintained by small teams and not break. Commented Jun 30, 2011 at 5:04
-
in another language, those large programs would be small programs that could be maintained by even smaller teams. Commented Jul 2, 2011 at 7:08
Have you checked Cocoa and Cocoa Touch frameworks? These two frameworks are as beautiful and well designed as Apple hardware machines.
As Kevin says:
Your opinion might change as you get more experience with other languages.
Absolutely true.
The commitment the Java team has made to avoid introducing non-backwards compatible changes means that they probably think long and hard when they're extending their API, instead of just throwing something out there. Compare this to (say) PHP, which completely changed the handling of XML in PHP5 - no deprecation, just gone.
The reasons are historical and philosophical, with the history deeply affecting the philosophy.
C++, Perl, and even Python are all older then Java, and because of Moore's law they were developed in an environment where disk and memory were one or two orders of magnitude more expensive. Developers very much wanted to pick and choose which APIs they had on a system because memory and disk were expensive, and networks were slow. Why not let developers exercise their judgment and chose whatever library they thought best?
Java was originally developed for proprietary, embedded software so it HAD to provide all the libraries used at run time. When Java migrated to general purpose computing this turned out to work pretty well for folks doing line-of-business software, but it was also one of the reasons why Java initially got smacked as being slow and bloated.
If you go to a nice restaurant you'll often be given a choice between "prix fixe" and "ala carte". Each course of the prix fixe meal, and maybe even the wine is chosen by the chef in advance. This is great if you don't know much about the food and trust the chef. If you have very particular tastes or think the chef is a moron, you'll want to order ala carte, where you pick each course to exactly suite your taste.
answered Aug 12, 2011 at 6:45
