Talk:Criticism of Java

message: 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)
replies: text: 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)

text: 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)
thread_title: Sun vs Microsoft Windows

message: 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:
# 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.
# 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)
replies: text: 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)
thread_title:  Expanation of two criticism 

message: 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)
replies: text: 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)
thread_title: Database connections

message: 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)
thread_title: Sources and external links

message: 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)
replies: text: 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)
replies: text:  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)

text:  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)
thread_title:  Constructors 

message: The article currently contains the following statement, with 'citation needed' appended:
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)
replies: text: 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)
thread_title: Generics

message: 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)
replies: text:  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)

text: 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)
thread_title:  JIT Compilation Background 

message: 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)
thread_title: Inconsistent JVM Implementations

message: 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)
thread_title:  Interfacing with native code 

message: 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)
thread_title: License

message: 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)
thread_title: Classpath

message: 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)
thread_title: Classpath defined in .jar Manifest

message: 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)
thread_title:  Encyclopedic language needed 

message: 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)
replies: text: 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)
replies: text:  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)
thread_title:  Performance subsection 

message: 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)
replies: text: No remarks in one month, so I removed it ;-) Hervegirod (talk) 09:04, 30 August 2008 (UTC)
replies: text:  actually, it does affect performance, so the removal was good Bestsss (talk) 11:51, 13 June 2011 (UTC)
thread_title:  Primitive types are not objects 

message: 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)
replies: text: 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)
replies: text:  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)
thread_title:  Lack of references 

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

message: 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)
replies: text: 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)
replies: text:  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)

text: 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)
thread_title:  Java Library 

message: 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)
replies: text: Done, still needs sourcing Hervegirod (talk) 11:56, 10 August 2009 (UTC)
thread_title:  No primitive types in generics 

message: 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)
replies: text: 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)
thread_title:  Security critics 

message: 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)
replies: text: (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)

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

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

text: 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)
thread_title:  Non-atomic assignment of 64-bit primitives section 

message: 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)
replies: text: 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)

text: 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)
thread_title:  unreferenced or improperly referenced sections 

message: 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)
replies: text: Alright, I'm taking that as consensus.  dmyersturnbull   ⇒ talk 01:04, 21 April 2010 (UTC)
replies: text: 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... --AlainR345Techno-Wiki-Geek 02:29, 28 April 2010 (UTC)

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

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

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

text: 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)
thread_title:  Proposed merge 

message: 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)
thread_title:  173.160.86.121 edits 

message: 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)
replies: text: 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)
thread_title:  analysis of languages with real code (not artificial benchmarks)

message: 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)
thread_title:  References to Microsoft 

message: 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)
thread_title:  Unsigned integer types 

message: 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)
replies: text: 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)
replies: text:  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)
replies: text:  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)
replies: text:  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 . 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 . What valid source criticize is the fact that Byte is signed in Java, which is not logic at all .  Hervegirod (talk) 00:25, 18 February 2011 (UTC)
thread_title:  Semantics of external processes 

message: 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)
replies: text: 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)

text: 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)
replies: text: 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)
thread_title:  This article should be deleted and merged back into the main Java article. 

message: 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)
replies: text: 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)
thread_title:  Adobe products in Security Section 

message: 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)
thread_title:  Robustness 

message: 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)
replies: text: 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)

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

text: 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)
thread_title:  Noun-orientedness 

message: 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)
replies: text: 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)
replies: text: No, it's not a controversial topic, but don't trust me. Ask IBM, Facebook, Twitter and Google why they chose Java. . 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 . 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)
thread_title:  Is unreflected criticism a good idea for a wikipedia article? 

message: 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.
Cheers.—InternetArchiveBot (Report bug) 16:52, 14 August 2017 (UTC)
thread_title:  External links modified