Talk:Criticism of Java

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)

The only cases I have seen of Java loading taking multiple minutes have been tracked down to antivirus software trying to analyse the entire content of the Java class libraries. Anything can fall victim to badly written AV software. —Preceding unsigned comment added by 217.206.42.18 (talk) 15:55, 19 November 2008 (UTC)

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)

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)

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)

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)

The garbage collection strategies used created significant application stability issues. These were noted in CMS and G1 algorithms. --Jscorrales (talk) 17:44, 14 April 2023 (UTC)

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)

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)

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)

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)

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)

Java is very well suited for servers, usually there is abundances of free cores. Especially during start most of the time taken is the disks, not JIT, not GC or actual work. The server restarts may happen once in 6 months for a well-written progr. JIT usually starts in interpret mode and after certain amount of executions it decides to compile the code doing on stack replacement, it can use 2 different compilers: one stupid but fast and one smart and slow. So compilation time is not an issue unless the required start-up time is in sub-millis region. Bestsss (talk) 11:47, 13 June 2011 (UTC)

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)

I didn't read the section, but this is still a problem - on phones. 155.198.65.29 (talk) 11:22, 7 April 2009 (UTC)

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)

To say that Java should be criticized because it fails to teach things like memory management and other concepts in other languages is unfounded because, like those above have said, you can say the same thing about languages such as C and C++. Also, the market isn't huge for C/C++ programming, especially in industry. The only major fields they have use in is in embedded systems and operating system development due to their ability to perform operations that would be considered low level (i.e. assigning/creating ISR, making inline assembly and directives, accessing and manipulating specific memory locations, etc.). A large portion of the industry deals with web based applications and client applications which would benefit from GC. This is why languages like C#/VB/Java are used to create these applications because they don't require the need to perform low level operations, such as manual memory management. And considering that one of the key points of academia is to prepare you for industry, why not use what a large portion of the industry is using, i.e. languages that support automatic GC. --Jake 198.102.153.2 (talk) 17:48, 18 August 2011 (UTC)

...which would benefit from GC...

Horrors! Now, if GC is that good, why is it 1. that Android Phones freeze for minutes, and 2. why is it that Mozilla eats all your memory and everything becomes teeeeedious? I was of your opinion some years ago, but now I've changed my mind: GC is a bad idea. It's better to take the hard effort of manual memory management.

For the rest: your apology goes to garbage collection (computer science), not specifically to Criticism of Java. Rursus dixit. (^mbork³!) 16:12, 1 September 2011 (UTC)

What is this? " This means that a Java EE server cannot limit the amount of memory that a deployed application can allocate, nor it can limit how many time a servlet can use to answer a user request."

First, the reference used to support this is not a reference to anything about Java at all, it's a reference to another language and says nothing about Java.

Secondly , the whole section does not read like an encyclopedia entry. THe English is simply broken and ungrammatical here- "nor it can limit how many time a servlet can use to answer a user request", a sentence fragment that actually makes no sense.

Third, the statement is simply false; J2EE server and the application it hosts can indeed monitor and limit the amount of memory used and it can also limit servlets in any way it sees fit.

Sorry, this is not true, not grammatical and not referenced. I am taking it out. — Preceding unsigned comment added by 71.194.197.246 (talk) 12:55, 25 August 2012 (UTC)

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)

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

Now that Java is release under GPL, should this be removed in its entirety? Les (talk) 12:23, 9 October 2008 (UTC)

As I haven't seen any kind of edit wars nor I couldn't find anuthing in wiki rules (except IAR) I deleted the section. I hope I didn;t do anything wrong. Uzytkownik (talk) —Preceding undated comment was added at 23:14, 20 October 2008 (UTC).

There are still issues if you need to use Java for emedded use. See Google's decision to write a VM for their Anroid platform in order to avoid some of the problems.66.11.179.30 (talk) 23:51, 27 October 2008 (UTC)

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)

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

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

There is a subject-verb agreement issue in Performance section: "Sun Microsystems have taken considerable trouble to address these problems, and regularly produce white papers on this topic" should read: "Sun Microsystems has taken considerable trouble to address these problems, and regularly produce white papers on this topic." —Preceding unsigned comment added by 67.186.12.163 (talk) 02:17, 31 May 2009 (UTC)

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)

Heh. It wasn't that long ago when perl blew the doors off of java in terms of performance... it seems that java performance improved a lot in recent years, but I'm sorry to see that perl performance has also degraded in the last decade. linas (talk) 21:59, 13 July 2008 (UTC)

Perl start to approach Java performance only for Java interpreted mode. I think you refer to the time (not so long ago, I agree), when Java was not JITted ? Hervegirod (talk) 20:30, 30 July 2008 (UTC)

Primitive types are not objects

The following sentence: However, as demonstrated in C# it is possible to allow for value types/primitive types to exhibit OO characteristics such as encapsulation, instance methods and interface implementation without compromising performance at all seems really dubious to me. I was not able to find any reference backing this. So if nobody finds a ref about that in say 2-3 days, I propose to remove it. Hervegirod (talk) 20:07, 30 July 2008 (UTC)

No remarks in one month, so I removed it ;-) Hervegirod (talk) 09:04, 30 August 2008 (UTC)

actually, it does affect performance, so the removal was good Bestsss (talk) 11:51, 13 June 2011 (UTC)

Lack of references

I have a general problem with the content of this article. A lot of sections are not sourced, or sources are not critics at all. Not that I want to remove all unsourced sentences, but it seems to me that for now, a lot of critics are mainly WP:POV. As it is, the article seems to me more a collection of editors personal thoughts than anything else:

• Class path: it is not even written as a critic, and the only source is not a critic, it is coming from Sun technical stuff about Java !!! Should be removed (it rather belong to the Classpath (Java) article, as a technical explanation).
• Resource management,: unsourced.
• Primitives vs. objects: unsourced, and it looks to me more of a technical explanation of one of Java's language choices than a critic. Should be removed.
• Generics: the first paragraph is clear and sourced. But all the rest is completely unsourced and seems to me more like the point of view of who wrote this part, it seems completely WP:POV (I'm not talking about the merit or the accuracy of the text below, this is not the point here).
• Non-Virtual methods: unsourced. Should be removed. It is more a language feature.
• Single paradigm: same.
• Exception handling: same.
• Closure: same.
• Floating point arithmetic: I have a problem with the only source that is a criticism (the other is Sun's technical article). It is a very very old (1998, Java's beginning) flaming critic that was openly written to rebute James Gosling, so it seems a little unreliable to me.
• Look and feel: There ARE critics on that, but we should find sourced here !! Plus the content of this section is not very clear (too much stuff, making it difficult to understand).
• Performance: I think only the header part (which is sourced) should be retained here. All the sub-sections should be deleted (unsourced, technical rather than critics, and already are or should be in the Java performance article).
• Hardware interfacing : Unsourced, the only example (unsourced) is specific of 1.0 version !!! Should be removed.
• Interfacing with native code: unsourced. And I think that it is not what critics say about JNI. the only critic seems to be that it is complex. The rest is WP:POV and should be removed.
• Inconsistent JVM implementations: Unsourced. Should be removed (seems WP:POV to me.

Hervegirod (talk) 09:37, 30 August 2008 (UTC)

After more than one month without any reply, I'm a bit more bold and rm some of the unreferenced parts that seemed to be WP:OR. Hervegirod (talk) 00:24, 9 October 2008 (UTC)

It has been more than 6 months since the unsource tags, I have now deleted sections that remained unsourced since that time. I'm not against critics, but still having no sources at all for such a long time despite the tags means that they were WP:POV and should be removed. That said, 'm not against people re-adding them, but please do it only with reliable sources. Hervegirod (talk) 11:29, 10 January 2009 (UTC)

Look and feel

It isn't much of a criticism when there is no comparison to alternatives ··gracefool☺ 10:58, 2 April 2009 (UTC)

Java Library

Does no-one have a problem with the badly designed library? Comparing String to C++'s std::string or QString shows just how hard it is to work with. Then there's the whole lack of a decent vector class (oh for std::vector<int>!) There are other stupidities too, like the fact that Thread objects can only run once, there's no readLine() equivalent, you can't seek in files, etc. This is all J2ME I'm talking about but I doubt it is much better in J2SE. 155.198.65.29 (talk) 11:29, 7 April 2009 (UTC)

hmm, I have no problem with adding this kind of criticism, if you find reliable sources for it. However, C++, std included, may be hard to work with, and I always found Java collections much much easier to use, to the point that it maybe was one of the reasons of Java's appeal to developers at its beginnings. As for Java's String, OK its immutable but it's not the only language that use immutable Strings, why do you find it hard ?. And there's a readLine equivalent (with exactly the same name) in Java J2SE. There are areas of Java that are touted as badly designed, (html manipulation packages for example), but certainly not the core of the language, nor the collections ;) Hervegirod (talk) 23:45, 7 April 2009 (UTC)

Four years later - I'm also surprised there isn't a huge section about the problems and inadaquacies in the Java framework. For example java.util.Date and java.util.Calendar - no professional programmers use them, they all use Joda-Time. My understanding is that Google was so unimpressed with the Java framework that they simply rewrote large portions of it, see Guava: http://code.google.com/p/guava-libraries/ RenniePet (talk) 06:47, 21 September 2013 (UTC)

The criticism I have about Java's standard library is its handling of time. It has the built-in assumption of time being stored as local time and makes handling time as a single number counting ticks since some time (say seconds from Jan 1, 1970) quite difficult. Having handled some code dealing with time it has been well demonstrated storing times as local time is nearly always a major mistake. Deltas from an epoch nearly always work better. 207.172.210.101 (talk) 02:09, 30 September 2017 (UTC)

No primitive types in generics

The section about java not providing primitive types in generics should be merged into the section about generics themselves, as it is a result of type erasure. —Preceding unsigned comment added by 129.132.45.64 (talk) 11:50, 10 August 2009 (UTC)

Done, still needs sourcing Hervegirod (talk) 11:56, 10 August 2009 (UTC)

Security critics

A new Security section has been added recently. However, the only sources are just FAQs which do not criticize the java security model and a personal blog which quotes an IBM paper. This paper concludes by these words "So is Java still secure? The short answer is yes". This section should be removed. After some days I will do it myself it I have no further valid sources about this. Hervegirod (talk) 20:49, 3 September 2009 (UTC)

Hang on with this. Java does have some negative security issues. I will be writing more papers that will expand on these. Basically the security risks come from using a Java enabled internet browser. I know of some problems, and there are papers scattered around the internet that back up some of these issues. The article section just needs expansion and cross references made to the various articles. Here are some:

http://www.cs.princeton.edu/sip/faq/java-faq.php3 http://www.cigital.com/javasecurity/reviews.html (I haven't yet read this) http://www.nwnetworks.com/sands.htm (This links other articles, again I haven't followed this through yet)

92.232.150.252 (talk) 08:14, 5 September 2009 (UTC)

Sorry, it was more than 10 days ago, and there was still no valid sources for this part:

• the first link was not a critic (see my first comment)
• the 2 next links were empty
• the last link was about a security hole (patched) in Java 1.3

Hervegirod (talk) 21:34, 15 September 2009 (UTC)

Non-atomic assignment of 64-bit primitives section

This section only reference Sun's Java Language Specification and Sun's memory model specification, which can not be considered as criticisms on Java. The whole section is a interpretation on parts of the Java specification, but don't link to any source criticizing Non-atomic assignment of 64-bit primitives. For these reasons it should be deleted. Hervegirod (talk) 00:10, 3 December 2009 (UTC)

(Christopher Schultz)Sigh: <sarcasm>I forgot that WikiPedia isn't allowed to contain any actual information... just links to it</sarcasm>. I will attempt to find some references to someone actually complaining about these issues rather than simply complaining about them myself. —Preceding unsigned comment added by 69.143.128.194 (talk) 01:34, 3 December 2009 (UTC)

(Christopher Schultz): I have added a reference to a blog entry by Bruce Eckel (author of Thinking in Java among other things) which mentions briefly this issue. His complaint is really about the Java memory model in general, specifically the vague "rules" about the volatile keyword. Perhaps I should change the level of specificity of this section to be about the Java Memory Model in general, which has lots of articles such as "The JMM is Broken" and "Fix the JMM", etc. Many of those changes have been made in recent versions, however, and so may perhaps be outdated. The section on "security" issues" mostly refers to non-recent versions, so I'm not sure what's appropriate, here. —Preceding unsigned comment added by 69.143.128.194 (talk) 01:58, 3 December 2009 (UTC)

I don't think the section as it is now is making a particularly good argument. It's basically saying "things are well-documented in the JLS but they still suprise some people." (I don't even think the referenced principle of least surprise applies to concurrent programming in general, but that's a different issue.) Concurrency is a tough issue, and unless there are good sources about a lack of documentation this section should be removed. As it is now, it even ends with an open question, which is a definite smell. Someone doing original research didn't do their homework? – Chip Zero 09:04, 3 December 2009 (UTC)

The Bruce Eckel source does not criticize Non-atomic assignment of 64-bit primitives, it mainly criticize a book. So I don't see it as a valid source. However, if you find a valid source about "The JMM is Broken" (for the current JMM, of course, because the current version of the JMM really fixed Java memory model), no problem. Hervegirod (talk) 01:01, 4 December 2009 (UTC)

unreferenced or improperly referenced sections

A lot of unreferenced or improperly referenced sections appeared in this article recently. Please note that on wikipedia stuff must be properly sourced. I have put a tag, and I'm allowing people to add valid sources, but if these sections are still not properly sourced in a few days, I will remove them. To be more clear:

• "Articles should be based upon reliable, third-party published sources with a reputation for fact-checking and accuracy": thus a source which is a blog from someone nobody knows is not valid.
• sourcing something which does mention a feature without criticizing it, and stating it as a critic is not valid either.

Hervegirod (talk) 12:46, 6 December 2009 (UTC)

---

How should the "Autoboxing" section be footnoted? For something so terse, surprising, and easily verifiable by any compiler, is a footnote actually necessary? I've added footnotes to some of the other new entries, and will be adding more in the near future.

JonDePlume (talk) 03:48, 7 December 2009 (UTC)

Wikipedia rule is that articls must be properly sourced (verifiability). Furthermore:

• sourcing an article merely stating a fact in a neutral tone, and using it to source a critic is not proper sourcing here;
• an unreferenced page without date, author, etc is not a proper source.

You may have critics about Java, and you may be right, but it's not the point here. Adding footnotes is not enough if these footnotes are only improper sources. I have no problem at all with criticisms sections, but they must be properly sourced. For example, it is improper sourcing to quote Sun's documentation about something and using this as source for a critic. There were a lot of cases like that in your sourcing. Also quoting an unknown blogger or just an unreferenced page on the web is not proper sourcing.

I have to repeat what I wrote just before. You are welcome to edit and add critics, but you must properly source them. That you consider Java's lacking in certain aspects is not a valid reason by itself to add a critic on the language in this article, except if you find a reliable source which says the same ting as you think. Hervegirod (talk) 22:50, 10 December 2009 (UTC)

Hervegirod (talk) 22:39, 10 December 2009 (UTC)

---

Hervegirod,

Because you're not disputing that the criticisms of java I've listed in this article are commonly made, deleting the material I gathered does not seem appropriate... particularly when the page itself is rather skimpy. If you accept the basic premise that Wikipedia is here to help the community refine and transmit information, then a more constructive approach would be to assist in adding new references rather than wholesale removal of topical and relevant content.\

Perhaps Mark Reinhold is an unknown blogger to you, but he is the principal engineer responsible for managing Java within Sun. As such, he seems like a perfectly good person to cite, even if he makes certain announcements within the context of his blog; that's how he communicates to the world sometimes -- it *is* the primary document. Memory bloat is a fairly common concern/criticism of Java. Sometimes it's the programmer's fault, sometimes it's the way that the GC is being used, sometimes Java is the wrong choice for a particular job -- that's not what's at issue here. This article is about what the criticisms are, not whether or not they are true, who is to blame, or whether you agree. Is research conducted by the GWT team at Google not a reliable enough guide for estimating how large objects typically are in Java? If not, what is? To what standard are references in this article being held? Do you consider the opinions of the person who wrote iBATIS irrelevant? That seems implausible, given the popularity of iBATIS; his opinion matters to a great many people. You don't have to agree with it, but that doesn't take away from that fact that the criticisms have been made.

I am not out to bash java; there are many things to like about it. However the world has indeed criticized it, and those criticisms ought to be documented. A page entitled "Criticisms of Java" seems like the right place, no? For these reasons, I'm going to revert the undo operations you've performed and hope that we can have a constructive dialogue about this if you disagree (rather than going back & forth with delete/undo). I think we both want the same thing in the end: a well-sourced, useful, content-rich Wikipedia.

JonDePlume (talk) 02:51, 11 December 2009 (UTC)

There's a misunderstanding; I never intended to say that I was not disputing the criticisms of java you listed in this article. I have absolutely nothing to say about if they are valid or not, the point is that they must be properly sourced. I'm sorry to say that you did not properly sourced your paragraphs. I looked at each of them, and if I removed all of these improper sources, no source would remain.

Perhaps we should begin by the first paragraph: Overall Verbosity:

• your first source, Dan Dyer, is a blogger and *not* a well-known one. There are no reference of him anywhere on the web except in his own blog, a few of his own posts being copied in dzone, which mainly regroup various blogs in the community.
• the second source only list the future changes in Java7 (second part of the paragraph), so it is not relevant to the criticism you make about verbosity. There is nothing in the article that there are efforts in JD7 to "improve the situation".
• same for the next source, which is not making any critic on Java "verbosity" at all, but list small changes which would be included in Java 7 (and it's a Sun reference)
• And the last by Mark Reinhold, which explains Java 7 schedule and the closures proposal (and I very well know who he is).

Furthermore, none of these sources use the word "verbosity" or "verbose" once, so "Overall Verbosity", and "Java is widely considered to be an overly verbose programming language" (compared to what other languages?) come from nowhere here. maybe there are valid sources about this "verbosity", but as you are the one who added this paragraph, the burden of finding a valid source is yours.

AFAIK all the paragraphs you recently proposed have the same kinds of problems. Therefore they should all be deleted. Please be assured that it's not to "defend" Java from critics. Hervegirod (talk) 00:30, 12 December 2009 (UTC)

---

Hervegirod,

I cited both well known and lesser known sources, but this seems entirely appropriate in the context of a wiki page that enumerates widespread criticisms (again, this isn't a page describing what's wrong with java, but rather one that describes frequent criticisms of it). If you follow the link to Mark Reinhold's blog you'll see that the reason he finally caved in was that "Working with parallel arrays in Java, unfortunately, requires lots of boilerplate code to solve even simple problems".

While Mark doesn't use the literal phrase "overly verbose", I think it's fair to say that his comments amount to an admission of just that. What's the problem with this reference then? That he didn't use the exact words "overly verbose" or "overall verbosity"? If that's it, then I don't believe that's a reasonable standard. After all, this reference isn't attached to a quotation, it's serving the role of substantiation of the summary itself. Fair?

If you'd like to spend some time helping, perhaps you might be able to find references to complaints about how much typing is required to accomplish simple things. For example, I've come across plenty of griping about System.out.println("..."). This was a problem that static imports were intended to address. Finding "authoritative" quotes on stuff like this is awfully difficult because Sun rarely comes out and says "oops". What you're left with is citing a larger number of lesser-known sources in order to document the scuttlebutt within the diverse java community itself. Maybe once in a blue moon you could get lucky and stumble upon a broad academic statistical survey of opinions. If you can find such a thing, then fantastic -- hat's off! I could not. I tried. Still, I thought the reference to Clinton Begin (the author of iBATIS) was pretty good. As for memory usage, that's still a work in progress. Clearly, it's a frequent criticism, but so far I've just gotten as far as the GWT team's quantitative listing, and haven't had time to select nice references about people in the community griping about it. Jump in there to if you'd like.  :)

Aside: an interesting but difficult to calibrate tool for getting a sense of "zeitgeist" is Google's auto-completion feature. Try typing the phrase "Java is too" and pause for a moment to allow the search completion to kick in. The first completion is "Java is too verbose". The next completion is "Java is too complicated". This kind of thing is impossible to cite in a wikipedia article, but I mention it here both to substantiate the claim that this is a frequent criticism, and in the hope that you might find it an interesting and fun tool (if you don't already play with it). —Preceding unsigned comment added by 24.62.25.194 (talk) 03:38, 12 December 2009 (UTC)

In any case, I believe the article is better and richer for the material I've added then it was before. It could be improved further by additions, clarifications, and better references, but not by removing items that are uncontroversial.

Cheers, JonDePlume (talk) 03:13, 12 December 2009 (UTC)

Proposed merge

A note on the proposed merge...

It strikes me that information here belongs under Java_programming_language#Criticism and other pages, not in a separate article. Wikipedia has enough "criticism of" pages without this short article on points better addressed elsewhere. The page on C++ does it correctly.

Some of the content is poorly referenced and non-neutral. For example:

Java lacks certain features that are considered by some to improve readability and/or programmer productivity.

Who considers? What certain features? What arguments do they cite? What are opposing viewpoints?

Some of the content is good; let's add that to Java_programming_language#Criticism and Generics_in_Java. Opposing viewpoints?  dmyersturnbull  ⇒ talk 00:52, 14 March 2010 (UTC)

Alright, I'm taking that as consensus.  dmyersturnbull  ⇒ talk 01:04, 21 April 2010 (UTC)

I know I'm late to that game, and since I do not remember what was really in there as for content I won't argue, but still, what strikes me here is that someone says: The page on C++ does it correctly and let's add that to Java_programming_language#Criticism and that's precisely not what is done in the end. Strange a bit... --AlainR345^{Techno-Wiki-Geek} 02:29, 28 April 2010 (UTC)

merge Yes, I support the proposed merger. Sae1962 (talk) 08:13, 27 April 2011 (UTC)

No, I don't agree to the proposedmerger. The original page it too lng as it is; the amount of information in this page should be put into a separate page anyway, regardless if it was 'criticism' or 'history'. peterl (talk) 07:44, 28 April 2011 (UTC)

Yes, I support the propsed merge. I'm little late too, and I actually added a section to the bottom of the page before I realized this had already been discussed. I agree this article should be merged back into the main Java article. It almost seems like Java is being unfairly singled out. There are a lot of criticisms that can be leveled against other programming language (Flash or COBOL anyone?) but Java is the only one that actually has an entire article dedicated to criticism of the language. Pleo2012 (talk) 20:38, 14 June 2011 (UTC)

No, Although some I agree with some aspects of this discussion, the danger is that the Java page will end up huge, and having this as a separate article helps keep the main article's size down. peterl (talk) 08:39, 15 June 2011 (UTC)

173.160.86.121 edits

If you think I have been overly harsh to revert, we can combine our ideas here perhaps. Stephen B Streater (talk) 23:13, 23 March 2010 (UTC)

analysis of languages with real code (not artificial benchmarks)

beside some technical effectivness, which has undebatable increased in the last years for java (defining the potential best implementation), there is an typical achieved performance by real existing programmers (mean or median effectivness of language) ... http://page.mi.fu-berlin.de/prechelt/Biblio/jccpprt_computer2000.pdf http://portal.acm.org/citation.cfm?id=317683 maybe this analysis should be included, the metholodgy makes them still valid. 141.52.232.84 (talk) —Preceding undated comment added 19:23, 29 November 2010 (UTC).

Maybe but this study shows no statistically significant differences in speed between C, Java and C++ (all error bars overlap). Only in memory consumption C and C++ use less (this is known). They estimation of productivity in prototyping seems dubious for me as it is openly (clear text) based on assumption that developer spends the same time on a single line of code regardless of the language. One can write all program in a single line, using other separators between sentences - this adds nothing to productivity Audriusa (talk) 14:34, 6 December 2010 (UTC)

References to Microsoft

Microsoft owns .NET platform that is a major competitor of Java platform, and they are openly aiming to replace the competing technology with theirs. Hence there is a conflict of interest in they Java related talks and I suggest to avoid using references to Microsoft people talks in the article on Java criticism. If Microsoft is the only available source, maybe better not to include this kind of criticism at all. Audriusa (talk) 12:23, 30 November 2010 (UTC)

Unsigned integer types

The section “Unsigned integer types” states that Java lacks native unsigned integer types. This it not true since 'char' is an unsigned native 16 bit integer, 'char' is however the only unsigned native integer so native 32 bit and 64 bit integers does not exist, neither this 8 bit. —Preceding unsigned comment added by 193.150.222.25 (talk) 00:26, 29 December 2010 (UTC)

Semantics of external processes

I removed the paragraph, because as it is, it's more a POV sentence thhat anything else. The fact that this bug has been voted top of the list is not significant in itself. There is only 364 votes for it, and the last comment date from April (saying that there are other means to achieve this on Unix boxes). Besides it can be significant only if a valid source explains that it is a significant bug. Which the Bug list on Oracle's database can't say. Or else any of the other top voted bugs can be in this article, which would be ridiculous. And to be complete, the low amount of comments on the bug (else than just "google" without anything else, tend to show that the number of votes is not significant. Find a valid source saying that it is a serious bug, and there's no problem. Hervegirod (talk) 23:45, 18 January 2011 (UTC)

Whether you or I personally would like Java to have unsigned integers and unsigned longs is clearly not the issue. What matters for the sake of this article is whether or not java's lack of unsigned types has met with a meaningful level of criticism by its user community. Do you seriously question that many people level this criticism at java? If so, please google "java unsigned" and take the time to read what comes back. Assuming you're a software engineer, please also read and think about the stuff that people talked about in the Sun/Oracle bug report as well. This is a genuine issue with real consequences for certain classes of applications, so it doesn't makes much sense to pretend that they don't exist. Java has met with a tremendous number of well-deserved accolades but has also met with criticism as well. If you want to add more references, please do. However, I think it's not even slightly plausible to assert that this criticism isn't significant or long-standing. JonDePlume (talk) 21:06, 19 January 2011 (UTC)

I don't have any problems with critics, of course, but please put them if they are coming from valid sources. Bug lists are not valid sources in themselves, else EVERY bug or RFE should be chosen and put in the article. If a valid source explains that it feels that it is a major / critical / etc... problem in the Java platform, no problem. This article is sadly a place where everybody (I'm not talking specifically about you) think he has the right to put his own ideas. But this article is exactly like any other. BTW, the critics about unsigned integer types are not properly sourced too. Please note that I'm not against putting every one of them, what I think of the the real significance of these problems is not the point here. Please also note that I'm not against adding valid sources myself for any of these critics, if can find them and have the time to do it (I don't edit only on Java articles, and my time is not infinitely extensible). But I don't think it is my duty to find valid sources in all cases. Duty is on people who put the critics, who must find the sources themselves. Hervegirod (talk) 23:48, 19 January 2011 (UTC)

Thanks for restoring the section on unsigned, though I don't see the rationale behind omitting the useful reference I gave to Oracle's bug datebase -- it's a fairly handy in this context. As for including every single bug as a "criticism", of course that's absurd. I understand the fear, but I hope you don't think what I've done is even remotely like that. However, imagine what would happen if every person that believed "the citations were insufficient" just started doing wholesale deletions of material rather than improving or augmenting them. Wikipedia would quickly find itself in a world of hurt. All material is endangered by the continuum fallacy because sharp distinctions are often impossible to make; hence, we really do need to rely on a collegial and liberal principle of "being reasonable", lest every article spirals in to add/delete wars. That's an unpleasant waste of time for everybody, and ill-serves readers. Strong statements obviously require strong documentation, but the idea that "many people are critical of java's lack of good process control & integer types" simply isn't like claiming they're right. JonDePlume (talk) 16:41, 22 January 2011 (UTC)

Sorry for not answering before, I was not aware that there was a new comment on the article. Of course I'm sure you added the source in good faith! However, I persist to think that a bug database "in itself" is not a valid source. If you look for valid sources about java unsigned arithmetic, you will find that people don't really criticize unsigned arithmetic in itself (again, a bug database is not a valid source, it's the equivalent of comments on a blog post or an article), it is a feature of the language, some people explaining on the contrary that signed arithmetic is difficult to understand well without doing mistakes [1]. There are a LOT of valid references on the Web explaining how it is easy to make huge mistakes with C code because of the unsigned int types [2]. What valid source criticize is the fact that Byte is signed in Java, which is not logic at all [3]. Hervegirod (talk) 00:25, 18 February 2011 (UTC)

This article should be deleted and merged back into the main Java article.

It seems to me that Java is being unfairly singled out here. Sure, many other programming languages on Wikipedia have criticism sections, but Java seems to be the only one that was actually given a stand-alone article for "Criticism of Java". There are many criticisms that can be leveled against Flash, COBOL, .NET, C++, etc. But none of them actually have their own article titled "Criticism of [Insert Language X here]". — Preceding unsigned comment added by Pleo2012 (talk • contribs) 19:32, 14 June 2011 (UTC)

I agree entirely. We should either make criticism pages for all other languages or merge this into the main Java article. I'm in the process of merging them right now.JavaAndCSharp (talk) 14:25, 7 July 2011 (UTC)

Get consensus first; see #Proposed_merge. My opinion is that the resulting merged document will be too big. peterl (talk) 22:47, 7 July 2011 (UTC)

While I do agree that having a criticism article only for Java treats Java unfairly (I doubt that criticism of Java is any more notable than criticism of C++ or many other languages), to me the far greater issue (and the reason I proposed the merge) is that criticism articles almost always, almost unavoidably devolve into mass collections of particular editors' complaints.

Moreover, this is a terrible way to categorize: a natural categorization for a programming language would be "syntax", "history", and "performance" (for example), and these can be placed into distinct articles. To a reader, seeing a criticism article is a bit like opening an encyclopaedia, flipping to the entry for "dog", and seeing two sections: "good" and "bad". It doesn't make any sense, and it's not conductive to reading and the point of an encyclopaedia.

I think there are far bigger problems contributing to the size of the Java article, such as overuse of code samples and unnecessarily in-depth discussion of syntax (which could easily be moved into the Java syntax. (Also: do we really need a "more comprehensive example" to the already long example section?)

Much of this article is already original research mixed with users' complaints, and I think it's likely to devolve from there.  dmyersturnbull  ⇒ talk 01:16, 3 August 2011 (UTC)

I suggest examples and textbook like segments are removed and the core of this article is merged into the Java article. The Java article is already too long and should be shortened to leave room for the content in this article. The examples in the Java article are too long and the explanations too technical. 217.209.140.211 (talk) 20:49, 27 January 2012 (UTC)

I am the one which created this article a long time ago, because the same problem that we have here occurred in the java article. People added more and more OR and users complaints, to the point that a large part of the article itself was devoted only to criticisms. I am not against removing this article, but I am against creating a specific criticism section in the Java article, and furthermore I don't think that removing parts of the Java article to make room for a Criticism section would do any good. I very much prefer a bad article as this one is sadly than a destroyed java article because anyone want to add it's share of personal opinion, which was the case before this article was created. Hervegirod (talk) 15:25, 28 January 2012 (UTC)

I'm also against a criticism section in the main article (in general, I hate criticism sections and articles, so perhaps I'm a bit biased). You raise a very interesting point. Do you think removing this article would inevitably lead to a ruined Java main article? Would it be worth trying? I have noticed that the Java main article is also pretty bad in its current state: it's practically a list of disconnected examples.  dmyersturnbull  ⇒ talk 20:36, 15 June 2013 (UTC)

Adobe products in Security Section

What do Adobe Acrobat and Adobe Flash have to do with Java security weaknesses? 204.210.242.157 (talk) 22:53, 11 January 2012 (UTC)

Nothing at all. I can think of no logical reason to include it, particularly as the first line in the section. I've removed it. —ShadowRanger ^(talk|stalk) 03:12, 12 January 2012 (UTC)

Two-Dimensional Arrays

I cannot agree with the point in section "Large Arrays" about two dimensional arrays. I use Java(tm) for scientific/matrix applications as well and i made some rudimentary comparisons on my own machine and I found out that matrices backed by a two-dimensional array offer better performance than using one dimensional arrays. Following reasons:

 * When it comes to a row majored array the row-major access was only slightly slower whith a double[][] array when its was whith a double[] array ( tested on a 4x4 and 100x100 matrices ) when it came to colum-major acces the double[] array turned out to be way slower ( on 100x100 matrices )
 * double[][] (4 small arrays) arrays can be created/allocated way way faster than one contigious double[] array.
 * double[][] arrays allow mindblowingly fast row xor colum permutations (used for LU decompositions for example)

I am not a professional programmer and my tests were done on only one machine and might be scientific nonsense. But still my point stands: please give REASON why a java two dimensional arrays in java are bad (e.g. interfacing with native libraries but that would be another point wouldn't it). I assume that this article is trying to sum up REASONABLE criticism. --89.15.46.209 (talk) 07:09, 26 May 2012 (UTC)

I also thought that sentence was lacking when I read it. I would think the reason has to do with cache misses, but the cite (page 3-4) doesn't even mention that.

I haven't thought of a Wikipedia article or section of an article that goes into detail, though, so I can't really add anything to the article. --68.161.144.254 (talk) 12:48, 1 June 2012 (UTC)

Robustness

I removed the Robustness area, which was tagged as "OR" since June 2012. There was still no valid sources added since that time. I have of course no problem if someone re-add this part, of course providing that it is properly sourced. Hervegirod (talk) 15:08, 19 January 2013 (UTC)

Noun-orientedness

I suggest to either completely rewrite the section on "Noun-orientedness" or remove it. The current version simply does not make sense. It calls classes "nouns" and then explains that "verbs" (methods) can be performed on or by nouns. It's not wrong, but I would say that the majority of methods in a program are non-static and, hence, performed on or by objects, not classes. It continues with "Many argue that..." and only gives a reference to a blog entry. Later, it claims that "a function is bound to a class and can never operate on multiple types", ignoring that of course a method can operate on its parameters, which can be of any type (see the example of the sort method below). Finally, it gives a "likely" example of a Quicksorter class which "has a constructor taking an Object as an argument, and a single method called run()", which is rather funny because this is exactly how the sort method of the java.util.Collections class is NOT used.

I have some vague idea what the paragraph wants to critize (lack of top-level functions, the tendency to over-design Java frameworks, etc.), but I am not a native speaker. --130.89.103.73 (talk) 09:07, 28 August 2014 (UTC)

Completely agree with that. This argument only pops up in that single blog entry. Having the datastructures (objects) responsible for defining their algorithms (methods) is the core principle of object orientation. Thus this argument is against object orientation, not the Java language. --212.243.177.218 (talk) 12:07, 21 October 2014 (UTC)

OOP is the defining concept for Java. Even stronger, Java is the prime example of OOP and defined to a good degree what is currently understood under OOP. So Java included OOP needs to be defended by Java (and this article) (also, the main source for the Noun-orientedness section clearly targets Java). Shaddim (talk) 00:52, 16 March 2015 (UTC)

I also agree with the statement that the "Quicksorter class example" is a rather bad example. "A Quicksorter class that has a constructor taking an Object as an argument, and a single method called run()"; I think this example intends to say that even for a simple operation like sorting, a new class has to be created having a single method doing that operation on a single variable. Although this is one way to do it but I don't think Java enforces this kind of thinking in any way. There's no need for a separate class if you're implementing a single operation, you can do it in other ways and since there's no proof that Java enforces such ideas, the whole example stands incorrect. I'm thinking of rewriting the whole paragraph. But I'll need some concise and correct examples; if somebody has an idea about it then they can add it. --Furquanahmad (talk) 08:28, 10 December 2015 (UTC)

Is unreflected criticism a good idea for a wikipedia article?

Is it a good idea to have a sole article about unreflected criticism of <insert thing here> in wikipedia? While it is absolutely legitimate to criticise aspects of the Java language and the JVM (this article is about both), the critics in this article are sometimes biased by, for example, choosing a not fitting example (Noun-orientedness). This article would not read so much as a rant against Java and the JVM if there would also be some counterarguments in it, but I don't think an article with the title Criticism of Java has a place in wikipedia. It should be boiled down and made a section in the main Java article. 84.187.47.2 (talk) 17:30, 17 January 2015 (UTC)

Java was and still is a controversial topic in the software engineering domain. Just google for heated discussion about Java performance vs <something>. Java clearly deserves a even big(ger) controversy/criticism article on its own. Shaddim (talk) 00:48, 16 March 2015 (UTC)

No, it's not a controversial topic, but don't trust me. Ask IBM, Facebook, Twitter and Google why they chose Java. [4]. Some criticism is well deserved, I have seen the changes in sorting algorithms, and traversal of Red-Black Trees, etc... so yeah, as any language it's not perfect, but this specific instance seems like a personal crusade. More on performance [5]. Some parts of the article are too old and others probably talk about features/deficiencies that have already been changed/removed. — Preceding unsigned comment added by 201.151.56.174 (talk) 22:18, 2 February 2016 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified 3 external links on Criticism of Java. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20070102132948/http://www.ociweb.com/jnb/jnbJul2003.html to http://www.ociweb.com/jnb/jnbJul2003.html
• Added archive https://web.archive.org/web/20090325195557/http://research.sun.com/techrep/2002/smli_tr-2002-114.pdf to http://research.sun.com/techrep/2002/smli_tr-2002-114.pdf
• Added archive https://web.archive.org/web/20151124005023/http://armadilloaerospace.com/n.x/johnc/recent%20updates/archive?news_id=295 to http://armadilloaerospace.com/n.x/johnc/recent%20updates/archive?news_id=295

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 16:52, 14 August 2017 (UTC)

Removed outdated code

A fragment claimed:

"However, the following is, and will throw a ClassCastException on run-time, which means the type system was unable to detect any problems (however this is detected by modern IDEs like Eclipse and IntelliJ IDEA)."

class Nullless<T, U> {
  class Constrain<B extends U> {}
  final Constrain<? super T> constrain;
  final U u;
  Nullless(T t) {
    u = coerce(t);
    constrain = getConstrain();
  }
  <B extends U>
  U upcast(Constrain<B> constrain, B b) {
    return b;
  }
  U coerce(T t) {
    return upcast(constrain, t);
  }
  Constrain<? super T> getConstrain() {
    return constrain;
  }
  public static void main(String[] args) {
    String zero = new Nullless<Integer,String>(0).u;
  }
}

Since at least Java 8, this no longer compiles (haven't tested it under Java 6 or 7 to see when it stopped compiling).

error: method upcast in class Nullless<T,U> cannot be applied to given types;
    return upcast(constrain, t);
           ^
  required: Nullless<T,U>.Constrain<B>,B
  found: Nullless<T,U>.Constrain<CAP#1>,T
  reason: inference variable B has incompatible bounds
    lower bounds: U
    lower bounds: T
  where B,T,U are type-variables:
    B extends U declared in method <B>upcast(Nullless<T,U>.Constrain<B>,B)
    T extends Object declared in class Nullless
    U extends Object declared in class Nullless
  where CAP#1 is a fresh type-variable:
    CAP#1 extends U super: T from capture of ? super T

References