Talk:Criticism of Java

From Wikipedia, the free encyclopedia

Contents

[edit] Sun vs Microsoft Windows

This also belongs in the Criticism of Java article, but it should be noted that the lawsuit Sun brought against Microsoft hurt the consumer. Since the Microsoft VM no longer ships with Windows XP (or can be downloaded), any page that contains a Java applet will be frozen for up to 3min on slow systems while the JRE loads, This has not changed with , and is a significant detriment. There are some advantages to having a VM built into the OS's structure. LaVieEntiere 16:52, 30 April 2007 (UTC)

I don't think that it is a valid critic: 1) it is easy to load a JRE (even if it is Sun's JRE) and it loads only once; 2) many PCs are pre-loaded with the latest JRE inside (see here); 3) if you want to load the latest Java 6, it is 13 MB, less than Acrobat Reader, which is almost 18 MB !!! Reader is always pre-bundled with PC boxes, but you eventually have to upgrade it (and for other examples, IE is 14 MB, QuickTime 19 MB, MediaPlayer almost 13 MB...) Hervegirod 17:24, 30 April 2007 (UTC)

[edit] Creation

The whole content of this article is taken from the Java criticism article, which had become very long and confusing for readers (I thought). Hervegirod 09:54, 11 June 2006 (UTC)

I think it came from the Java programming language article, Criticism section. I've included this in case the section is ever renamed or edited out. Stephen B Streater 17:23, 11 June 2006 (UTC)
you're right, thanks for correcting my typing error Hervegirod 17:37, 11 June 2006 (UTC)
Sorry, that was my fault. A lot of the criticisms before were merely listing facts about Java rather than making criticisms against it and that was confusing readers. I have seen, for instance, newbies at Javaranch raise "the problem" they have heard about Java since it doesn't have multiple inheritance without knowing why that was a good or bad thing. And, on the other hand, I've seen a lot of actual criticisms of Java that weren't mentioned (e.g., any time Java is mentioned on Slashdot). I collected a few other criticisms that I didn't add as the section got way too large:
  • The performance of a Java program is only as good as whatever JVM the client is using
  • The JRE is too large such that "Hello World" requires 9 megabytes of memory on Solaris
  • Java 1.5 is no longer easy to teach
  • There is an over reliance on APIs rather than frameworks
  • Many Java programmers say that they have become more productive when they use a duck typing language.
The last three criticisms come from the book Beyond Java which has prominent Java people say what they didn't like about Java anymore. There are a lot of interesting citable criticisms in that book.
If anyone has an idea how to make this article relevant and helpful, I'd like to hear it. Chiok 17:44, 11 June 2006 (UTC)

[edit] Expanation of two criticism

I'm not confident enough in my understanding of Java or Wikipedia protocol to just change this myself, but can someone please explain the following two criticims, taken from near the bottom of the article in its current format:

  1. ResultSet.getInt() will return null even though the specified return value is an int and thus will error if assigned to the primitive type int.
  2. A ResultSet object is automatically closed when the Statement object that generated it is closed, re-executed, or used to retrieve the next result from a sequence of multiple results, however...

I assume that whoever wrote these is refering to the contents of the java.sql library (it would be helpful if this was explicitly stated). However, these aren't classes with standard implementations in the API; they're interfaces. Presumably there is no standard implementation, and the Java language can hardly be blamed if somebody happens to have written their own faulty implementations. That said, I'm also at a loss as to how any implementation of an interface specifying a method with a return type of int, can feature null as a return value for that method and still get past the compiler. As I'm more or less clueless myself, I'm not brave enough to delete the criciticms outright and potentially incur the wrath of whoever wrote them; perhaps someone can explain what I'm missing.Magicalsushi 13:52, 4 July 2006 (UTC)

At least the first sentence can be deleted safely, because it is false at it is stated : ResultSet.getInt() can never return null, because the output is not an object, but a primitive int. At most it can throw an Exception, but it is very different from what is written. So I delete it. As for the second sentence, it really make sense to me, as the ResultSet is a view of the result of the query. So if the Statement is closed, it is perfectly valid to close the corresponding ResultSet. And the "normal" way to iterate through a sequence of results, is to define this sequence of result in the Database query, rather than doing a lot of separate queries (I think it should be much quicker). So in my view, we should delete this sentence too (but for this one, I will wait for the approval of more than only myself...) Hervegirod 19:33, 4 July 2006 (UTC)

[edit] Database connections

Database connections and statements are not automatically closed when they fall out of scope as would be expected by a scope definition of any object oriented language => Again, this is perfectly normal. One should only look at what is done on a File stream. A Database is a resource, as is a File stream, and not only an object. It make sense to need to close explicitely a resource, this has nothing to do with the "Object oriented" notion (same in C#, for example) Hervegirod 19:43, 4 July 2006 (UTC)

same in Object-oriented Perl too, there is a function called "DESTROY" (like the Java "finalize") who can be used to free resources previously used by the GC-ed data structure Hervegirod 20:15, 22 July 2006 (UTC)

[edit] Language design and Sun's marketing

Perhaps something should be said about some of the language design decisions and Sun's marketing of the language. IIRC it had within Sun been agreed upon that pointers were a common source of issues, therefore Java should not have pointers, and instead has "references". However, references has the very same syntax as pointers (initialised by new and can be null) and are even called pointers under the hood (f.i. "NullPointerException"). Another marketing strategy was to claim that not including multiple inheritance was because that facility was a common source of subtle errors, a claim (a FUD strategy, according to some) that though has never been substantiated in any tests still became a taken-for-granted truism. Mikademus 21:52, 25 July 2006 (UTC)

pointers : Having coded in C and Java for examples, I think the references in Java are a lot easier to deal with than C pointers. It is very easy to make errors with pointers, because (for me) it is very easy to use the adress instead of what it points to (especially as you often need more than one level of indirection with pointers). There is no such problem in Java. The only thing you have is the "NullPointer" Exception, and it is not the same type of problem (and easy to deal with). For the multiple inheritance, I can't remember one time where I could have regretted that it was not there in Java. Of course, may be I adapted my needs to what the language can offer... Hervegirod 23:16, 25 July 2006 (UTC)
Thank you for the feedback, but you misunderstand - please do not take this into Holy War land. We have enough of those inside and outside of Wikipedia. The point is that (1) Java "references" are pointers but marketed as something different, and (2) exclusion of MI is marketed as something intentionally good because of unsubstantiated claims of MI --> bad code. Mikademus 07:26, 26 July 2006 (UTC)
It is not just marketing. Although they behave the same, the difference with references is that that there are stricter restrictions on what can be referenced, while pointers can point at any location in memory. For example, the following is impossible in Java:
int *a;
int b;

a = &b;
 
b = 1;
*a = 5;

printf("%i\n", b);
I would argue that pointers are different from references because of the limitations and stricter controls of references compared to pointers, and because of the syntactic differences (lack of the pointer operator simplifies the system). Fragglet 08:53, 26 July 2006 (UTC)
Where is the difference, really? There are only what is called references in Java -everything but atoms are references- so there's no need for C's * pointer-marker. And using dot instead of -> only simplifies the syntax, it doesn't change the underlying mechanics, a pointer dereference still takes place under the hood. You new what the reference points to, and the allocated object is automatically deleted when no longer referenced. It is called reference counting when writing smart pointer classes in other languages too. The only real differences between Java's references and C/C++'s pointers is that pointer arithmatics is not allowed in Java and once initialised you can't reassign references in C++ (which allows you to use the assignment operator transparently on references).
Integer a = new Integer();
Integer b = new Integer();

a = b; // under the hood a points the b's memory location
 
b.set_to( 1 );
a.set_to( 5 );

Mikademus 09:47, 26 July 2006 (UTC)

I know that it is not the point, but I think there is no set_to(int) method for Integer in Java. More importantly I think, is the fact that Java (but also C#) references are safe, which is not the case with C/C++ pointers. Here is an excerpt of the Reference article : "A number of popular mainstream languages today such as Java, C#, and Visual Basic have adopted a much more opaque type of reference, usually referred to as simply a reference. These references have types like C pointers indicating how to interpret the data they reference, but they are typesafe in that they cannot be interpreted as a raw address and unsafe conversions are not permitted. In those managed languages, the references are actually pointers of pointers of the referred data. In C/C++, the reference concept of managed languages means two-step pointing.". Hervegirod 09:58, 28 July 2006 (UTC)
As for the Integer syntax, you're right, the syntax is my_integer.parseInt("5");. Anyway, since the wikiarticles define references and pointers as virtually the same things but under different restrictions then the above discussion is moot, or perhaps tautological. However, doesn't this simply goes to emphasise the handwaving involved in the marketing of Java? Sun's contention that Java conains no pointers but instead the safer references, while arguably strictly true, is manipulative since pointers and references are the same thing ("Pointers are the most primitive and error-prone but also one of the most powerful and efficient types of references, storing only the address of an object in memory" according to the Reference (computer science) article) and seems to try to be purposely confusing. Again, I'm not criticizing the language here, especially since I'm using it myself, but I am testing the ground with you to see how a few, er... pointers about Sun's marketing would fit in the article. Mikademus 11:29, 31 July 2006 (UTC)
Found a link to a Stroustrup article from the main Java article, where a similar argument is made, though obliquly aimed at Sun's marketing:
“ The most widely circulated comparisons tend to be those written by proponents of some language, Z, to prove that Z is better that other languages. Given its wide use, C++ is often top of the list of languages that the proponents of Z wants to prove inferior. Often, such papers are "published" or distributed by a company that sells Z as part of a marketing campaign. Surprisingly, many seem to take an unreviewed paper written by people working for a company selling Z "proving" that Z is best seriously. One problem is that there are always grains of truth in such comparisons. After all, no language is better than every other in all possible ways. C++ certainly isn't perfect, but selective truth can be most seductive and occasionally completely misleading.

When looking at a language comparison consider who wrote it, consider carefully if the descriptions are factual and fair, and also if the comparison criteria are themselves fair for all languages considered. This is not easy.

 ”
(From here). This suggested addition hasn't evoked much response but not much opposition either. If I can find some neutral sources I'll write something together. Mikademus 12:54, 2 August 2006 (UTC)

[edit] Sources and external links

I realise that it might be difficult to find good, neutral sources about justified criticism of Java. I found this one, linking to a page unfortunately called "Java Sucks", but written by a self-proclamed proponent of Java and listing several items of interest. I wish it had been baptized otherwise because it's flammable by its name, but it might serve nontheless. Mikademus 09:40, 8 August 2006 (UTC)

[edit] Language Irregularities

The JSP one really has nothing to do with Java, which is why I removed it. I think it needs to be written better if it stays in (I'm assuming there isn't a Criticism of J2EE or anything). As for the iterator one, I don't see how an iterator not allowing itself to be reset is really that irregular. That being said, it's not exactly true, because ListIterator allows for back/forth movement, effectively enabling a reset. The whole section is kindof a mess to me, but FWIW, that's why I removed those two. If someonen can expand on them both, maybe we can reword them to make more sense. -- Davetron5000 21:45, 16 August 2006 (UTC)

The above comment was about the removal of these two bullet points from the "language irregularities" section:
  • The JSP get and set parameters insist on the arbitrary style of capitalizing the first letter of the corresponding bean function name: I.e.<jsp:setProperty name="moe" property="myfunc"/> expects a corresponding setMyfunc(), and even though the following work: setMYFUNC(),setMyFunc(); this one case won't work: setmyfunc().
  • Iterators can not be reset.
I agree that the article should not criticise non-core aspects, unless part of the standard library. As for iterators, I just don't know. Are iterators usually resetable in other languages? Mikademus 07:15, 17 August 2006 (UTC)
In languages with "real" iterators like Ruby/Python they are definitely not resetable. In C++ it is up to implementation, but in STL they are not resetable. So I have no idea why is it in the language criticism section. Taw 14:25, 6 September 2006 (UTC)
I'll take it out then, because I can't come up with examples where the programmer would expect it to be resettable. Whoever added it initially can find a reference for it. The whole section kinda sucks IMO, so anything to whittle it down is good with me -- Davetron5000 20:35, 6 September 2006 (UTC)
OK, I just axed the entire section. After removing the bit about iterators, two of the statements (regarding braces and closures) fit well in the "Language Choices" section, and the bit about resource management was dealt with in the Memory Management section. I see no reason to include this section any more -- Davetron5000 20:41, 6 September 2006 (UTC)
I agree !! Hervegirod 20:56, 6 September 2006 (UTC)

[edit] Constructors

The bullet regarding constructors is that a subclass inherits all methods of the superclass but none of the constructors, save for the no-arg constructor (which is only inherited and called if no constructor is specified I believe). Take Hashtable for example: You subclass it, and you must reimplement all of it's constructors to call the super-classes constructor. That is the point of that item in the article and that has nothing to do with the requirement that calls to the super-class constructor or another constructor in the same class must be the first line of the constructor. -- Davetron5000 14:17, 31 August 2006 (UTC)

Sounds interesting. Can we also get a link or something to an example of a language with inherited constructors? Mucus 14:37, 31 August 2006 (UTC)
Hmmm, a cursory search of google did not yield anything about other languages that support this (specifically, C++ also doesn't support constructor inheritance). I'll remove the bullet, though this kinda puts light on my disdain for the entire section, as it is a bit of a gripe list. -- Davetron5000 16:04, 31 August 2006 (UTC)
Trying to quickly take a look, admittedly not the best source, but this thread http://discuss.joelonsoftware.com/default.asp?design.4.50459.27 seems to indicate that constructors are inherited in Delphi and Smalltalk. However, it does seem that (at least in C# and I'd assume Java), the decision to require at explicit call (or initializer-thing in C++) to the superclass may be more of a intentional decision than an ommision. Mucus 16:31, 31 August 2006 (UTC)

[edit] Generics

The article currently contains the following statement, with 'citation needed' appended:

“ When generics were added, requirements on backwards compatibility limited the features that could be provided by this addition, as compared to other languages ”

I think this article on my own site may be useful as a citation, but I won't add it myself (as per WP:EL#Links normally to be avoided #3, 'If your page is relevant and informative, mention it on the talk page and let unbiased Wikipedia editors decide whether to add the link.'). --Safalra 13:42, 28 October 2006 (UTC)

I just added it, but expanded the bullet a bit, as I don't feel it's honest to just say it's limited. It is limited because of a very good reason, and I think the only alternative would have been to leave out generics. (Which would keep the language easier to learn, but leaves you with more runtime errors and implicit types.) Chip Zero 09:53, 29 October 2006 (UTC)

[edit] JIT Compilation Background

I wonder if it would help to give a bit more background on JIT compilation. The first time I came across JIT was in the Borland world where they used it in Delphi (and I'm sure it was around before then, but it was with the power of the 486(!!) that it became feasible concept for general programming). The assumption was that PCs had time to spare and due to I/O, graphics drawing and whatever, there were enough spare CPU cycles that there was time to compile the code as well as executing it.

The fundamental problem with Java and JIT is not in the single user world in general, most PCs have plenty of spare CPU and such extravagance can be tolerated, but in failing to recognise that in a multi-user/multi-tasking world, those CPU cycles were not spare, they were someone else's, hence JIT is less suitable for servers.

Regarding servers: my experience is rather the opposite. Code in servers runs a long time between restarts. In the last project I did the web server cluster gets restarted every night (if the web server could rotate its log files on the fly the servers could run forever without restart). As a side effect, initialization (initial database access, config file reading, etc) compiles a lot of the low level code (java.lang.*, java.util.*), and the rest gets compiled during the next few minutes as servlets are accessed. Then everything runs compiled for the rest of the day. So my gut feeling is that JIT really shines on servers! If we write something about this in the article we'd need some sources who have really studied the issue. Weregerbil 10:03, 14 November 2006 (UTC)
That is my gut feeling too and in the past have performed performance analysis of specific application components that has proved this, howevever I can't cite any sources unfortunately.--FifthColumnist 04:55, 12 January 2007 (UTC)

[edit] Inconsistent JVM Implementations

I propose to delete this part, as Java has now become GPL, this seems not to be a problem anymore. As I understand, the problem was that opensource alternatives were lagging behind Sun's. Hervegirod 15:26, 19 November 2006 (UTC)

[edit] Memory Management

I agree that the JVM's memory management strategies is a point that may be criticized. However, the article criticizes the plain fact that Java has a garbage collector, on the grounds that it may lead programmers to mess up when they move to C++. This is a bit far-fetched, as automatic garbage collection is common in a lot of languages. I personally think this part should be removed. --129.240.106.170 23:37, 23 October 2006 (UTC)

The first part of this section details an example of legal Java code that if written in the same way in C++ would result in a memory leak. Since Java handles it correctly how is this a criticism of Java? Surely it is a C++ problem? Criticising a language for not being valid in another language sounds absurd to me, unless I'm misunderstanding the article. Canderra 03:31, 13 December 2006 (UTC)

I think that paragraph is attempting to point out that Java can lead to incorrect coding in other languages in which one must explicitly allocate and deallocate memory. It does seem a bit of a stretch to criticize Java for poor coding in other languages. – Mipadi 09:02, 13 December 2006 (UTC)

Automatic garbage collection certainly isn't an inherent bug, or something specific to Java, but Java is often used for teaching purposes, and it is valid to say that Java and all other managed languages are incomplete as a teaching language, so long as memory management is liable to be an important skill for a programmer. This is one of many common complaints against Java as a teaching language that circulate in academia, and it's a factually valid one. Simply put, if we assert that a well trained programmer should have the basic thought process skill and "muscle memory" to be able to write C/C++/Pascal/assembler in a pinch, without any huge learning curve, then a managed-only skill set will fall short. 70.69.42.228 20:35, 13 January 2007 (UTC)

(Note that I merged the two 'memory management' talk sections for readability.) I don't believe this criticism is relevant here. Learning Java teaches you Java, and general programming concepts, and when thought well this includes many aspects of resource management. Java doesn't require manual garbage collection, but it doesn't teach you how to do functional programming either, to name something. So if anywhere, this comment should be on a page on academia criticism, but I don't think it deserves text and code samples of about a screen long there either. - Chip Zero 22:52, 13 January 2007 (UTC)
There's nothing about functional programming that Java can't cover, albeit with less grace and simplicity. I agree that reducing the mention may be in order, but I think that it does make sense to have some mention of the fact that a Java-only or managed-only programming education is effectively incomplete. Java's limitations as a teaching language are a valid area of criticism, given that it's often promoted as a "good" teaching language. 70.69.42.228 23:35, 13 January 2007 (UTC)
"some mention of the fact that a Java-only or managed-only programming education is effectively incomplete" - for the purpose of programming in an environment which requires manual memory management I agree, just as C++ itself would provide an incomplete education on how to program in assembly or machine code, but I still fail to see why this is a valid criticism of Java's memory management system. Java also fails to adequately teach students all the html tags, should this also be a criticism of Java?
I agree with Chip Zero that the point would be totally valid on some sort of "criticism of Java as an academic teaching language" page, but as it is not a Java problem and as Java wasn't designed for teaching students how to program in C++ or Assembly, it does not belong on this page. Canderra 01:11, 14 January 2007 (UTC)
"for the purpose of programming in an environment which requires manual memory management I agree" - So does a programmer have a complete education if they would have to go take more courses to learn some fundamental computer science concepts--rather than just new syntax--that are required to write or edit something in any number of commonly used unmanaged languages like C, C++, or Pascal? 70.69.42.228 03:00, 14 January 2007 (UTC)
"just as C++ itself would provide an incomplete education on how to program in assembly or machine code" - While not every combination of assembly language statements can be expressed in C++, a well versed C++ programmer should be comfortable with all of the concepts and thought processes that are required to work with assembly. 70.69.42.228 03:00, 14 January 2007 (UTC)
"but I still fail to see why this is a valid criticism of Java's memory management system" - It's not a criticism in the sense of suggesting that Java would be a "better" language if it lacked a GC, or that having a GC is a bug. The criticism is that Java is of limited use for the purpose of teaching, just as it's of limited use for various performance-critical floating-point projects for other reasons. 70.69.42.228 03:00, 14 January 2007 (UTC)
"as Java wasn't designed for teaching students how to program in C++ or Assembly, it does not belong on this page" - Java wasn't designed for a lot of different things that it resultingly handles poorly, (or in some cases handles well) but whether or not a given language was designed with a given task in mind has no bearing on whether it's weak and subject to criticism in that area. 70.69.42.228 03:00, 14 January 2007 (UTC)
Either way, it sounds like I'm outvoted, so if someone wants to remove the mention again, I won't re-add it. 70.69.42.228 03:00, 14 January 2007 (UTC)

[edit] Interfacing with native code

I have deleted the paragraph

It must be noted, however, that it is a common case for other Virtual machine languages, as for example the .NET Framework Common Language Runtime (see Platform Invocation Services).

because 1) it is incorrect: .NET P/Invoke does not require you to maintain two codebases the way JNI does, it also provides much safer (through annotations) memory and resource management, and 2) it is irrelevant. 212.242.89.162 (talk) 10:29, 27 May 2008 (UTC)

[edit] License

Sun Java is not currently open source or free software, as defined by the open source initiative and free software foundation. Referring to Java's proprietary nature in a past tense is deceptive because it's still proprietary, so I'm removing the "before xx java was proprietary" layout, but if/when the GPL release occurs, maybe it should be restored. I removed a few sentences that are factually inaccurate as well. For instance, Java is not more available or open source or free software friendly than .NET as Mono is more compatible with .NET than GNU classpath is with Java, and Mono is now in wider production use than GNU classpath. —The preceding unsigned comment was added by 70.69.42.228 (talk) 18:30, 4 January 2007 (UTC).

[edit] Classpath

The statement "Running a Java program requires all supporting libraries to be on the classpath." is not entirely accurate, it is possible to have a Java application manually manage the class loading of its libraries, in some areas it is quite common for applications to function in this way, utilities that use provider pattern APIs such as generic JDBC tools often manage the loading of the vendor specific JDBC driver themselves to prevent classpath problems for users. Applications which allow users to add plugins of one sort or another using the application UI will almost always work in this way, the netbeans IDE is a good example of this.

As I understand it, the mechanism by which an application's classpath (whether on the command line used to start the virtual machine and application, or as part of the system classpath) is specific to the java VM implementation, most implementations copy Sun's command syntax almost exactly (with slight variations appropriate for their platform).

It is definately true to say that the commands used to start a localy installed application from a system console or gui environment are platform specific (and often site/machine specific) and usually a barrier to the write once run anywhere paradigm.

Java applications that are executed as Applets embeded in HTML pages or applications started using the JNLP (webstart) framework avoid the pitfalls of CLASSPATH and are both examples of the write once run anywhere paradigm in action, I am sure there are other examples of WORA working properly, EJB applications possibly? Comments please.--FifthColumnist 04:55, 12 January 2007 (UTC)


[edit] Classpath defined in .jar Manifest

A java application executable (a jar with a Main-Class entry in its manifest), can also specify a Class-path entry. This entry can define each of the applications supporting libraries, or .jars, separated by a space, and uses forward slashes across platforms, including Windows, to delimit directories. By defining a classpath this way (rather than manipulating the system class path, it is easily possible to create a cross platform application, negating the problems in the main article. Main article should be updated with this information. Please see here: http://java.sun.com/developer/Books/javaprogramming/JAR/basics/manifest.html#download —The preceding unsigned comment was added by 217.205.198.24 (talk) 11:14, 26 April 2007 (UTC).

[edit] Encyclopedic language needed

There are some instances in this article that use informal or inappropriate language. An example is even in the lead paragraph: "However, Java is not without flaws, and it does not universally accommodate all programming styles, environments, or requirements." —The preceding unsigned comment was added by 128.12.108.147 (talk) 21:30, 10 May 2007 (UTC).

[edit] Performance subsection

I'm moving this text from the article here:

It is impossible to make any generalization about the performance of Java programs, because runtime performance is affected much more by the quality of the compiler or JVM than by any intrinsic properties of the language itself.

This text or anything of the kind does not appear in the main article, Java performance. It does not have citations and is either false or at least misleading. The choice of language features does affect the amenability of a language to present-day compilation techniques (let's forget the mythical Sufficiently Smart Compiler), and Java can be effectively compiled. This is not true of e.g. Python, Ruby or Perl at present, whose very dynamic nature makes things difficult for compilers. Nobody uses compilers/JVMs today which make Java as slow as Perl, so quality of the compiler is not in practice as important as properties of the language, and one can make the generalization that in practice Java is faster than Perl (unless your code spends all its time in libraries implemented in other languages, which is how Perl is usually used, but I digress). What matters is the performance of JVMs people actually have to deal with today (because customers use them) or the best JVM one can choose (when you can choose), and these do not vary so wildly as to make generalizations about them wholly impossible. -- Coffee2theorems 14:56, 30 August 2007 (UTC)