Talk:Java programming language/Archive 1

From Wikipedia, the free encyclopedia
Jump to: navigation, search


Poorly Written/Misleading section

The following sentence begins the Performance Impacts section (under Criticisms)...

Java has obtained a reputation for slow performance, primarily because most users have targeted the Java virtual machine rather than compiling the language directly to native machine code.

This sentence is wrong for a few reasons. The implication of this sentence, by comparing it to native execution, is that JVMs interpret Java bytecode. While this might of been the case in early Java versions, it's almost never the case today. Practically all modern JVMs compile Java bytecode to native machine code before running it. Also, while there are a few java compilers out there that can create a native executable from a Java project, the majority of Java applications are delivered as Java bytecode and rely on the JVM to execute them. Compiling the language directly to a standalone (machine code) executable implies that not only is a JVM not used but also that the Java libraries, which the application most certainly uses, are compiled and delivered as native code as well. This is just not the case today. Spookfish 05:26, 17 December 2005 (UTC)

Compiling Java to the native machine will always produce more reliability and not necessarily performance. What must be realised also is that Java is already on the backfoot with execution speed against the likes of .NET which of course doesn't have the JVM/Native type of issues anyway. Speaking Dr Adrian Joniano (Professor in Computer Science, RMIT Doncaster) this whole issue of JVM alone renders Java almost certainly obsolete within 5 years if not resolved and it is expected that Microsoft will pounce with an evolved .Net by then. If any consolation come to Java and it's compilation issues it will be that at least when SUN delivered the product it extended its native drivers asynchronously to reconcile any threading issues. Portability all a farce in the end.


I don't know who wrote that last paragraph, but it shows a different view of reality to mine. First, we have applications which run as JVM or C++ (with a preprocessor to convert), and they are of comparable speed - for some code the Java applets even run faster for some reason. Modern JITs are very good - and they run native code. As for portability: we ship Java applets which run on Windows, Macs and Linux boxes, as well as Java players for mobile phones. I don't think .NET does this. Stephen B Streater 21:57, 8 March 2006 (UTC)

Performance Impacts

In the Criticisms:Performance Impacts section, it is mentioned that Garbage Collection 'unaviodalbly harms performance and memory usage' which is not neccesarily the case. Often, for large data sets with many small elements GC can dominate conventional malloc/free implementations, and in other cases can be comparable. See for details on a popular C implementation of a garbage collection. On the other hand the Language characteristics:Automatic Garbage collection section is very accuarte and independent. - Chris Marcellino

In fact, the simple experiment of doing free(malloc(10)); in a tight loop in C or C++ and the equivalent Java loop show GC to outperform usual implementations of free/malloc by a factor of ten. In Sun JDK allocation is about 10 machine instructions and deallocation is (almost) zero instructions since GC does not touch garbage. The life time of objects may affect this rather simplistic measurement, though, due to generational GC. I suspect it could be hard to comment on this in the article without getting in trouble with some people. This is somewhat speculative, but the assertion that 'GC is unavoidably slow' is even more speculative (dare I say provably false, as per the experiment I mention). Weregerbil 01:27, 16 January 2006 (UTC)

Incorrect information

There's a paragraph regarding networking facilities that bridges the "platorm independent" goal and "networking libraries" goal. It's not a correct paragraph, but I don't know the best way to split it. Help, please... -Alan D

I don't see the problem, if any. The only places those are mentioned together is where they are specifically mentioned as being the goals of the language, where "goals of the language" is the topic. --LDC

If you don't see a problem with it, then I'm happy. -Alan D

A few more topics to add

Any volunteer for : - the Java Security Model ? - the Java Community Process ?

Java history

Some notes about the Java version history would be nice. An especially which version is included in which browser. Kwaku

Maybe you're confusing Java with JavaScript?
Java 1.1 was included with IE at some point. It's since been taken out (?). But it plugs into the current browser, but you have to DL & install it. —Frecklefoot 16:19, Apr 16, 2004 (UTC)
I just added a sentence near the beginning in an effort to disambiguate Java and JavaScript. Which is more common in web pages, and how does their function differ in web pages? I would guess javascript is used more often, but I really don't know. It would be nice if someone with more knowledge in this area than me could help amplify the distinction, since I'm willing to guess they are quite often confused by us non-computer jocks. Spalding 14:49, Feb 19, 2005 (UTC)

See, which claims that the Java platform (not the language) was developed by Tom Stambaugh and his company Bridge Systems.


Lee, have a look at [1]. Good reviews so far!  :-) --LMS

This is a "How To" article

This should be moved to a howto somewhere, as it doesn't describe the language at all.

One of the most confusing concept for those just starting to learn the Java language is the notion of a ClassPath that needs to be set before anything can be either compiled or executed.
With recent versions, Java features a -classpath parameter which makes it unnecessary to set a CLASSPATH environment variable. In fact, I haven't used the latter since then. --Maik 17:46, 2004 Oct 13 (UTC)

Java a platform too

Hmm, I think this article would be helped with a look-thru of the old Java whitepaper. For one thing, Java is a platform as well as a language. The article as it stands is confusing on this issue. Also a major design goal is a relatively safe language for average programmers, so fingers aren't cut on the difficult parts of programming.

Still, this article is well-written, and I'd change it right now except that it would take a little time to not chop up the text terribly. Maybe I would get rid of the part that says there are "four" design decisions behind Java, and just turn it into a list.

The article is titled "Java programming language", and is about the language, not the platform. If the article doesn't make this clear, then perhaps it could be reworded a bit and linked to another article about the platform. And frankly, the whitepaper is a pretty awful source of information--it's mainly a publicity piece for Sun, that contains all of their goals and ideas, but none of the day-to-day realities of the majority of working Java programmers. This is an encyclopedia, not an advertising medium. --LDC
Nonetheless, this article is currently the redirect for 'Java platform' and now we have Groovy it would be very useful to point to a summary article like the Java section in the Sun Microsystems page. I'll make the same comment on the Java platform page. User:webmink
I have made a start on this. [[User:Smyth|– Smyth]] 13:11, 13 Nov 2004 (UTC)
There is also a section on Java as a platform on the Platform (computing) page.--Jondel 18:49, 25 Sep 2004 (UTC)

Java: a platform and a middleware too

I'd like a description as platform too. Java is not only a 1)platform and 2) a language it is also a middleware. Some how thid categories or definitions must be inserted or made. Jondel

Java is platform independent

is a myth, misleading and misnomer.

Rather, the JVM is ubiquitous on all types of devices and chips. When they say platform-independent it is really because the Java interpreter or JVM can be found almost everywhere(on all devices/chips/sw packages). The installation of an interpreter or JVM has become an industry standard. Java is not the platform independent, Java is the platform( or the ubiquitous JVM or Java interpreter is the platform). Jondel 04:09, 13 May 2004 (UTC)~~

I think of a programming language as its syntax, its semantics and its standard libraries. For Java, these three things are in large part platform-independent. In real life most Java applications will execute the same way on all platforms.
The standard libraries are the issue here. The syntax and semantics of high-level languages tend to be platform independent, but sometimes standard libraries are not. So the two relevant things to say about platform independence are 1) the intepreter is ubiquitous (that does matter--compare SmallTalk). 2) the standard libraries are platform-independent. Anybody see how to say this without screwing up a nice article? -BK 14:16, 9 September 2005 (UTC)
It's true that Java requires a platform-dependent interpreter, but I wouldn't characterise the interpreter as part of the "language". Just as I wouldn't regard the compiler as part of the language for a compiled language.
It's also true that there are platform-specific APIs in Java, but these tend to be discouraged or deprecated in the documentation. It is quite possible to avoid these APIs for almost all applications, and in practice they are avoided most of the time. The Java programming language isn't perfectly platform-independent but it does a very good job of it.
Ben Arnold 04:50, 13 May 2004 (UTC)
Different category ?
Agreed on the language and it does a pretty good job of being platform independent. You seem to be a programmer.
I am targetting beginners and newbies. Also I wanted to focus on the platform aspect.
The term 'platform independence' may lead to confusion. If Java is to be described, it is important to explain or examine its aspect as a platform and the Java interpreter. What if a new OS does not have a JVM? The programmer would need to know that all bytecode actually needs an interpreter. People tend to think that the platform is where program was compiled?
Maybe this should be under a different category (Java software?Java platform? Java API?) as the interpreter really is not part of the Java programming language. Jondel 05:49, 13 May 2004 (UTC)~~
I'm of the (extreme) opinon that the intrepreter or compiler is absolutely nothing to do with the language, and that languages should be thought of as abstractly as the colour red, rather than a pot of red paint. CGS 19:20, 13 May 2004 (UTC).
I feel quite different about it. While I appreciate the difference between a language and how it's used, understanding how the language is typically used (in the sense of whether it's typically compiled or interpreted, etc.) is crucial to understanding what it is. In the case of this article, I think it might be a mistake not to mention in a discussion of platform-independence that java is usually compiled to platform-independent bytecode and that the bytecode is executed on JVM (with the option of using JIT). --BK 14:24, 9 September 2005 (UTC)

Removed instruction

This appeared in one of the articles, and I don't really think it is encyclopedia content. It's really more of an instruction for us writers, so I'll just leave it here in Talk for now:

Java is a trademark of Sun Microsystems. Like all trademarks, "Java" is an adjective; when referring to Java technology, use a generic term after the word "Java". Correct: "program written in the Java language runs on the Java platform." Wrong: "*program written in Java runs on Java." For more information, visit Sun trademark policies.

JDK versions

How do the JDK version below relate to the so called "Java 2 platform"?

  • JDK 1.0, 1995
  • JDK 1.1
  • JDK 1.2
  • JDK 1.3
  • JDK 1.4, 2002
  • JDK 2.0, 2003

My understanding is that everything 1.2 and beyond is the "Java 2 Platform", but I can't find proof. Here's the Java 2 page: [2]

What is this JDK 2.0???? The latest version is 1.5 Enochlau

--JDK is SDK is API and a complete set is a platform--

Hi! Please correct me if I am wrong.

For most software developers, JDK (Java Development Kit) are nothing more than SDKs but in Java. SDKs are ussually provided commercially by a company. They are also ussually called APIs. A complete set to allow you to program are ussually called platforms. It would be good to refer to For the meantime, I believe that JDK 2 is Java 2 and is the same as Java 1.2 . Jondel

  • Java 2 is java 1.2 up, the change was made since there where significant changes to the java API's. dns

JDK 1.5 is called Java 5.0 and J2SE 5.0 - confusing I know, but thats what the latest version is called. J2SE/J2ME/J2EE 5.0 actually.. The reason they changed their mind and called it J2SE 5.0 instead of J2SE 1.5 was that it was such a large improvement over the previous versions. So same idea as when they increased the platform from Java to Java 2 at 1.2..

JDK Java Platform
1.0 1.0 1
1.1 1.1 1
1.2 1.2 2
1.3 1.3 2
1.4 1.4 2
1.5 5.0 2

Speaking of versions, I believe that Java Web Start was released in 2000 sometime, Ie at around 1.3.1 release, if that matters. Article: Announcing Java Web Start Technology

If you want even more confusion: there will be no "J2SE 6.0" or "J2SE 7.0". Instead they will be "Java SE 6" and "Java SE 7". And abbreviating it "JSE 6" is considered naughty, got to spell out "Java". See Sun's article on naming. Weregerbil 15:25, 17 January 2006 (UTC)

Objectionable phrasing

I object to the phrase "actually the entities containing data" in the section on Object Orientation. It's meaningless and unhelpful. However, I have already deleted it once, and the author re-inserted it. I don't hate it enough to delete it again, so I'll leave it to the wise Wikipedia editors.

Language facilities

"It contains language facilities and libraries for networking (more or less)." - What "language facilities" are being referred to, here?

Perhaps dynamic class loading? --Doradus 21:51, 13 Aug 2003 (UTC)
Which isn't really a part of the language, as defined in Reflection is provided entirely by the class libraries. If we open it up to that, then C can do the same.
No, dynamic class loading is not reflection. Two different things. Dynamic class loading is very much a part of the Java language. See It is far more pervasive and integral to Java than to C; in fact, all classes in Java are loaded dynamically.
Thats the way the Java virtual machine works, not the Java programming language. Sure they're muddled beyond belief, but I feel as though I can safely draw a line and say that the dynamic loading you're talking about isn't part of the language. (I certainly hope that native implementations of the Java programming language won't do the same thing!)
Ok, what about when I say "2+3" and the VM adds two numbers together? I guess that's also how the VM works, not the language? Honestly, we can argue about this all day, but if you really don't think dynamic class loading is a fundamental part of the Java language, then perhaps we must simply agree to disagree. As you say below, it's not like it really matters anyway. --Doradus 13:08, 19 Aug 2003 (UTC)
Besides, the fact that a language feature is implemented in a library is just good design, and doesn't mean that feature isn't part of the language. For instance, would you say that variadic functions are not part of C just because you need to #include <stdarg.h> to use them? --Doradus 15:52, 18 Aug 2003 (UTC)
I'd say they're part of C because they affect the syntax. IMO, something isn't part of the language until there are syntactic elements related to it. Up until that point, I can get rid of it and replace it. This is getting a long ways away from being something that has anything to do with language facilities for networking. How does the dynamic class loading of the Java programming language (if there are any which pertain to the language, rather than its implementation) distinguish its networking facilities from another language enough that it is worth mentioning them?
Because IIRC the entire motivation to add dynamic class loading was to allow programs to be loaded and run incrementally over a network. --Doradus 13:08, 19 Aug 2003 (UTC)

Java was not designed with the goal to "more or less" have facilities for networking, etc. If you are not satisfied with Java's attainment of those goals, an unbiased discussion of how and why these goals are incompletely attained should follow their detailed description.

Link bezerker

Someone has gone completely bezerk with links: [3]. Seriously, do we need links for "reputation", "speed", and "thing"?

This change needs to be backed out. Unfortunately there have been revisions in the mean time.

Maybe we need to get this page protected until the revert is done and subsequent revisions incorporated. But its a pity someone's labour will go a waste. Jay 14:00, 9 Dec 2003 (UTC)

Reverting and merging of later revisions has been done. (See Wikipedia:Make only links relevant to the context for reference). Jay 14:30, 9 Dec 2003 (UTC)

Should we be displaying the Java logo here without permission. Sun's logo website says the terms are very strict for the use of its logos. Jay 14:10, 18 Mar 2004 (UTC)

I would say no — the logo should be removed. RedWolf 01:15, Mar 19, 2004 (UTC)

After reading the usage agreement for the Java logos, I don't believe Wikipedia can use the Java logo on its site unless approved by Sun MicroSystems. I am therefore going to remove the logo from the article.

Also see:

RedWolf 02:36, Mar 19, 2004 (UTC)

Wikipedia:Logos states: "It is not necessary to seek formal permission from a corporation in advance of using their logo, so long as the usage is fair use, does not create any impression that the logo is associated with or endorses Wikipedia or the article it appears in, and does not create any reasonable grounds for complaint by the trademark owner. The purpose of the specific guidelines above is to meet these conditions." Fredrik 14:19, 19 Mar 2004 (UTC)

If the Java logo can be used on Wikipedia, then why wasn't it properly handled as per Wikipedia:Logos? For example boilerplate text on the image description page and image caption? RedWolf 17:52, Mar 19, 2004 (UTC)

Don't ask me, I didn't upload and insert it in the first place... I merely replaced the low quality image with a better one. If deleting it seems like the right thing to do, I'm not going to defend the case further. Fredrik 19:46, 19 Mar 2004 (UTC)

Confusing terminology

From the article: This should not be confused with the

break label;


continue label;

statements in C and C++, which function identically to goto.

As a C++ user, I am very confused since these statements do not exist in standard C/C++. I removed this part. Perhaps the author was thinking of some nonstandard extension?

I agree. "break;" and "continue;" statements are part of standard C and C++, but they do not have any sort of label after them in standard C or C++. Only in Java do they have that label. --DavidCary 17:45, 19 Oct 2004 (UTC)

To describe the language constructs or not?

I feel strongly that articles on programming languages should focus on their development and history, and on what sets the language apart from all others. This article does a great job of setting those things forth. However, as a programmer with eir hands in several other disciplines, I think that an article like this is not the place to go into any detail on the language constructs. I personally skim over such descriptions, and the non-l33t reader will certainly do likewise. The intricacies of, say, exception handling or string manipulation simply cannot be conveyed in one or even ten paragraphs of text in a Wikipedia article. Besides, "real" reference materials abound to cover the mechanics of the language, on the Web and in print.

In summary, programmers don't need syntactic information (they already have it), and non-programmers don't need it. I do think the "hello world!" program should have a space, since it can offer a quick glimpse into that language's world that both programmers and non-programmers would find useful.

That said, perhaps articles on programming languages should link to articles that cover their particular syntactic or semantic nuances in more depth, or link to Wikibooks.

Jeeves 14:35, 25 Mar 2004 (UTC)

I am completely agree with you. I am very surprised that the article does not mention important issues like open-sourcing of Java and tools like gcj and classpath projects while going into mere syntaical explanations of loops. Never hesitate to make a change. Most of the time, it looks bad to you because it is bad. -- Taku 05:16, Mar 28, 2004 (UTC)

TakuyaMurata edits

This is regarding the 2 edits by User:TakuyaMurata.

  • The one with comment "(oh boy; the article is terrible)": Has he just deleted the contents or moved them over to a new/existing article ? If it has been moved pls provide the new article name, if it has been deleted based on the above discussion, then I disagree. Language syntax is as important to the article as anything else.
  • The one with comment "(=Versions= -> =History)": What is the basis of removing a bulleted section that was rich in information ?

Jay 07:05, 28 Mar 2004 (UTC)

  • I disagree with the changes. This article became a featured article with all that information. I think we should at least put in the stuff about versions back in. Sasha Slutsker 12:51, Mar 28, 2004 (UTC)

Ok both of you why? As discussed above there is no reason to go detail about the syntax. Wikipedia is not a language manual. Besides the language syntax section is awfully incomplete. I have settup the new article so that I can put it in VfD. Give us comments. Also there is no reason to provide detailed information about which version supports which platforms. I know it was featured but I have just improved the article by eliminating redundancy. -- Taku 15:09, Mar 28, 2004 (UTC)

What does this mean : "I have settup the new article so that I can put it in VfD"
Why do you think "there is no reason to provide detailed information about which version supports which platforms"
Redundancy is not an issue as long as the same information is presented in different ways. A bulleted list is useful when the reader wants to casually browse through a long article. Jay 15:35, 28 Mar 2004 (UTC)
I moved some syntax information to brief overview of the syntax of Java. Sorry I have forgotten to mention it. The issues is: is the table of versions against years really useful? The history section still mention when each version was released and it doesn't take much to skim the section. -- Taku 15:49, Mar 28, 2004 (UTC)
There is no reason to delete the bulleted information, it was very useful. I am putting it back in, please don't take it out again. Sasha Slutsker 23:29, Mar 28, 2004 (UTC)


I propose reverting this article to the form it was in before Taku's edits of 28 March and later, on the basis that the content which has been removed or modified has made the article significantly less useful. If there's something Taku wants to remove, Taku can then try seeking consensus for the changes first. Please indicate your support or opposition. Jamesday 15:26, 6 Apr 2004 (UTC)

"which has been removed or modified has made the article significantly less useful."
Can you specify how so? You mean the syntax of Java? -- Taku 16:05, Apr 6, 2004 (UTC)
The sections:
  • Control structures
  • Unstructured control (the early exits from loops and methods portions)
  • Primitive data types table
  • Input/output
That is, what Jay and Sasha appear to be objecting to the removal of just above this poll. The removals removed the core of the ability to compare the control and data handling capabilities of this language to those of others. Jamesday 20:06, 6 Apr 2004 (UTC)


  1. Jamesday 15:26, 6 Apr 2004 (UTC)


  1. Kevin Saff 16:10, 6 Apr 2004 (UTC). I don't see what has been "removed". If anything, I think the history should now be broken out into a separate article, History of the Java programming language.
I think he is referring to this one [4] though I am still not sure what he means by modified or significantly less useful. -- Taku 16:18, Apr 6, 2004 (UTC)
I see. I didn't look at edits before March 28, since he only mentioned 28 March and later. I think that info could go into a Syntax of the Java programming language if that doesn't already exist. How do other long programming language articles deal with specific syntax? Kevin Saff 16:27, 6 Apr 2004 (UTC)
It varies. C has it in C syntax, with very little about the language itself in the main C article. This one (Java) was much more informative. The main C article looks pretty weak, describing the history and such but not the language itself. At some point I'll take a look and see how to put the description of the C language in the main article and the history in a subsidiary article. Jamesday 20:37, 6 Apr 2004 (UTC)
I see; it looks like a philosophical battle over whether the syntax or the history of a language is more fundamental. What's wrong with putting an overview in the main article, and creating separate articles for each? Languages like C and Java certainly seem important enough to justify multiple articles. Putting all the syntax in the main article seems to limit the things one can say about it (such as the history and parseability of the syntax, which is quite interesting for C!) Kevin Saff 22:55, 6 Apr 2004 (UTC)
Completely in favor. Let's do it. Jeeves 08:28, 7 Apr 2004 (UTC)


  1. Taku 16:05, Apr 6, 2004 (UTC)


  • The poll is meaningless because whenever we revert to whatever version, someone including me will make a further edit that might contradicts the reverted version.
  • The poll is meaningless because this is wiki, not democracy.
  • Refer Talk:Java syntax. User:fredrik suggested the incorporation of syntax related info into the curly brace family. Though I can't visualise how it can be done, I'd be happy if he or someone else does it. Jay 19:46, 7 Apr 2004 (UTC)


Does Sun specify how the word "Java" should be pronounced? Merriam-Webster [5] says that both "Java" (a's pronounced as the 'a' in "hat") and "Java" (a's pronounced as the 'o' in "body") are correct. I've always heard and used the second form, but a coworker of mine uses the first version and it drives me nuts! Does Sun actually dictate hwo they expect it to be phonated? —Frecklefoot 16:19, Apr 16, 2004 (UTC)

Americans tend to pronounce it Jova ('o' sort of as in body) while most(?) Canadians tend to say it with a hard 'a'. James Gosling, the inventor of Java, is a Canadian living in the US who pronounces it Jova.

Steve-o 03:27, 17 Apr 2004 (UTC)

As in "hat" and "body"? Neither of these sound right to me. In New Zealand we use the "a" sound in park, but without any r (we don't pronounce the r in park anyway). Thinking about Canadian pronunciation, maybe this is what you mean by the "o" in "body". We use a very sound in body and park, so it can be confusing.

To put it simply I pronounce Java to rhyme with lava, and that makes sense to me. Presumably an Indonesian would be able to give the most accurate pronunciation, or am I making incorrect assumptions about the etymology of the name.

To use "a" as in "hat" just sounds crazy to me, even when I assume a thick US drawl.

Ben Arnold

It's because Americans say body like baaahhdeee... Dysprosia 11:21, 25 Apr 2004 (UTC)
Well, I pronounce java with an a as in hat. If you think about it, I don't say novigator, I say navigator. I don't say hove, I say have, (though I am a Jay-Z fan:)). So it's pronounced java, not jova. That's just what I say and what I've heard here in Southwestern Ontario (2 cents from a wikimember in training).

-- 00:42, 7 May 2004 (UTC)

A tiny section on this in the article might be interesting, I live in NZ as Ben does and we pronounce it Jahva. The only other way to pronounce it I can think of is Javva. (Assuming Dysprosia is correct in saying how US citizens pronounce Java as body.) porge 23:19, 23 Aug 2004 (UTC)

The initial paragraph in "Platform independence" conflates 'binary' and 'source' portability. Java programs are portable in terms of their specification because the language (with some exceptions like jni) does not depend on the form of the underlying architecture. Compiling programs into JVM gives you a portable binary transport layer, but this is fundamentally irrelevant to Java itself, and to Java program portability.

I live in Germany and I (even though I´ve quite limited abilities in english ;) ) would pronounce it like *yarwa* with an "a" like park...

Quote about Java

"Java: The blinding speed of Smalltalk combined with the simple elegance of C++." —Kenneth C. Dyke, Apple Computer

Audience and Context.


I am new to this site and have a strong professional interest in the Java Programming Language.

I have two concerns that would fall within the area of strong criticisms regarding the text to date.

Firstly there is nothing wrong with the text per se, however, I have difficulty in determining who the audience this is being written to. Is it the technical Java programming developer community? or the world at large. Either of these audiences would find difficulty in reading this article. This is a particularly difficult question due to the fact that I could identify several distinct and disparate audiences, each requiring many different perspectives.

Secondly, I find that large chunks of the value of Java is missing. I am seing most of the individual trees, but no description of the forest. The conceptual paradigms that Java introduces are significant and a large part of why the language has travelled as far so fast. These are also the reasons that it introduces the opinions and conflicts in the marketplace.

I see the base of what has been written as real value in dealing with the complexity of Java and communicating that to those who want or need to know. As Java continues to expand and become more and more of a day to day "thing" in all peoples lives, this opportunity to translate much of this complexity is of vital interest.


Split this up, JRE & JDK seperated

I think the Java Runtime Environment section should have its own article, same as the developer's Kit. What we could do is have a blurb on it in this article and have a See also: Java runtime environment there.

The reason why I suggest we split it up is because the java programming language, the java runtime environment, and the java developer's kit are three different things/ideas. That may make things clearer. --ShaunMacPherson 05:11, 5 Nov 2004 (UTC)

I have made a start on this. [[User:Smyth|– Smyth]] 13:12, 13 Nov 2004 (UTC)


What is the differences between them ??. :-?

JVM is a generic term, see Java virtual machine. JRE specifically refers to Sun's product, comprising their own JVM implementation and their own Java API implementation. [[User:Smyth|– Smyth]] 13:13, 13 Nov 2004 (UTC)
JDK includes JRE. JRE includes JVM. JDK is available for download by developers. JRE is available for download by clients. Anwar saadat 03:00, 25 March 2006 (UTC)
Close, Anwar saadat, but not quite correct. JDK ("Java 2 System Development Kit") is indeed a Sun Microsystems product targeted at programmers. It contains all sorts of tools for creating and building Java programs. JRE ("Java Runtime Environment"), while sounding like a more generic term, is also a Sun product, this time targeted at consumers of Java programs. It contains just the components necessary to run a normal Java program, and comes bundled in with the JDK ('cause developers need it too). But JVM ("Java Virtual Machine") is a very generic term. Sun's current JVM product, is called "Java HotSpot Virtual Machine", and is one such JVM and is embedded within the JRE (and therefore within the JDK). In fact, it's Sun's second attempt at a JVM - their first attempt was responsible for much of the "Java runs slowly" folklore in the early days. But there are other JVMs, some of which are better at running Java programs than Sun's HotSpot JVM (for example, IBM's JVM). And even Sun currently provides two differently-tuned JVMs, accessible from the "java" command via the "-server" and "-client" options. RossPatterson 03:42, 25 March 2006 (UTC)

Responses to the Java Language is outdated

The complaints about collections and casting etc in this section are out of date with the generics & auto-unboxing in v1.5 (which are discussed in following section) and I can't see any other point in that section but have a feeling that if I removed it, it would be replaced. Anyone care to fix it?

Not neccesarily everyone uses Java 1.5 and thus the prblems still remain. Of couse, adding some mention that they were fixed with the release of 1.5 would be nice. -- Taku 18:57, Nov 12, 2004 (UTC)
I've added the 5.0 versions. Although the Java IO section needs some similar treatment. Why focus on IO over the whole of Java is strange to me --Calvin 21:33, 16 Nov 2004 (UTC)
Because IO is kinda vital to any serious server application? In particular before nio it was impossible to code a single threaded event driven server app (which is by far the best method for certain types of server) in java. Plugwash 17:51, 22 April 2006 (UTC)


I think the first paragraph should either omit the mention of Gosling, or explain who he is. The way it is written now, the reader has no idea who Gosling is until he or she continues farther down the article, which is confusing.

Here's the paragraph I'm referring to: "Java is an object-oriented programming language developed primarily by Sun Microsystems. Gosling and friends initially designed Java, which was called Oak at first (in honour of the trees outside Gosling's office), to replace C++, although the feature set better resembles that of Objective C."

Pronunciation, Round 2

It's been "suggested" once again that the opening sentence of the history section should bear a pronunciation note indicating that Java is "usually pronounced with a short 'a' as in 'hat.'" As a professional Java programmer, I find this very hard to swallow; although many Canadians may pronounce it this way, it's only notable if this differs from the usual pronunciation (as in coffee). Anyone? ADH (t&m) 07:15, Jan 14, 2005 (UTC)

I always say jah-vah. It's best we don't mention an "official" pronunciation at all. Dysprosia 07:19, 14 Jan 2005 (UTC)
Same here, I would pronounce it /ˈdʒɑvə/, not /ˈdʒævə/. Peter O. (Talk) 07:51, Jan 14, 2005 (UTC)

My bad, I thought the majority was for "short" "a"

While probably not common amongst English speakers, I've heard Java pronounced as /java/ (in the Netherlands and Poland) (ie. English spelling 'yava'), matching local pronounciation of the coffee-bean. How consistant is this with the Javanese pronounciation? And how common is this pronounciation in europe? (ie, in German)

It's probably needless to say, but in japan "java" becomes jyaba. -- Taku 17:54, Apr 2, 2005 (UTC)


I have just landed on the orphaned Strictfp article via a random link. I've wikified it and added it to category:Java programming language, but it could do with a link from somewhere. The trouble is I don't know where would be apropriate - or even if it is apropriate to keep it as an article of its own, or should be merged somewhere (but I don't know where would be apropriate). I thought about VfDing it, but I don't know enough about the subject to know if it is really worth keeping or not. I am putting this here becuase as a featured article this talk page is probably going to be on the watchlists of people who know what they are talking about! Thryduulf 15:14, 2 Apr 2005 (UTC)

I've added a link to strictfp, which is mentioned in Java programming language#Version history. --MarkSweep 18:20, 2 Apr 2005 (UTC)

Edits by

Yet another mass delete, please discuss large changes here first and get the version correct please :*)

--Calvin 22:17, 19 Apr 2005 (UTC)

Request for references

Hi, I am working to encourage implementation of the goals of the Wikipedia:Verifiability policy. Part of that is to make sure articles cite their sources. This is particularly important for featured articles, since they are a prominent part of Wikipedia. The Fact and Reference Check Project has more information. Thank you, and please leave me a message when a few references have been added to the article. - Taxman 19:35, Apr 22, 2005 (UTC)

"Sun Control" comments in API

The comments that have been added to the article concerning Sun control are POV and reflect a shallow understanding of the JCP and of the historic situation. While Sun is the spec lead on many JSRs in the area of J2SE platform features, that's not the case with J2ME platform features and is not a necessary feature of the JCP - expert group leadership is now diverse. Additionally, ownership of specs is always shared by the expert group lead for practical reasons, so implications that that's bad in Sun's case are demonstrably POV. If it's essential that this topic is covered, a full explanation will be needed, and I suggest the appropriate place for it is in the JCP topic. As to controversy - well, it's controversial among those who don't understand it! --Webmink 01:49, 25 Apr 2005 (UTC)

Non-free IDEs under: 'Related free software' is ambiguous!

This was under 'Related free software', as a quick fix i moved it here. I hope somebody who is more erudite in this area than i am will reuse it!

What is the point of the "Related free software" section, anyway? ISTM it is just bloat that does not add much to the article; at best, it should be moved to a separate article. Objections to me just removing it? Neilc 05:18, 14 July 2005 (UTC)

Advanced Placement Program exam

The College Board currently administers an Advanced Placement exam in Computer Science, which tests knowledge in Java and object oriented programming. The exam also tests knowledge on the Marine Biology Simulation Case Study a program written in Java. The exam switched from C++ to Java as its featured programming language in the 2003-2004 school year.

This seems to have been added and removed a few times over the history of this article. I personally don't think it's relevant (many institutions run Java exams, this one isn't particularly notable), but if it does have to be in the article it certainly doesn't belong in the 'Java meets the Internet' section. I noticed that it did originally have its own heading, but that seems to have been lost along the way. I've removed it for now, if someone feels strongly that it belongs in the article please can we try to decide on an appropriate section for it? --Batneil 16:39, 24 July 2005 (UTC)


I don't think that Java programming language is the best name for this article. That's not what it's actually called. I suggest Java (programming language) (currently a redirect) or Java Technology (which is used by [6]. violet/riga (t) 12:36, 28 July 2005 (UTC)

Most articles on programming languages follow the format "X programming language". Dysprosia 12:40, 28 July 2005 (UTC)
You're right, many do. I think it would be better for them all to have it as "X (programming language)" but that's probably too much work. Best to leave it here then, I guess, as it needs to be consistent. violet/riga (t) 12:43, 28 July 2005 (UTC)

public, abstract, static, and final

I've pulled the following paragraph from the section on interfaces and classes (sorry I forgot to sign in before making the change):

Methods defined by an interface are implicitly public and abstract. Fields defined by an interface are implicitly public, static, and final.

Without explanations of the meanings of public, abstract, static, and final, this paragraph adds little value. But, adding the explanations would be adding detail, and this paragraph seems to already be too much detail. Mark Harrison 06:28, 11 August 2005 (UTC)

Code examples, specically the new for loop

It is unlikely that a user will relate to widgets and boxes. This should be changed to for(Element e: list)...

The name Fred for a class that implements Deletable is also bad. This should be changed to something like Section, Something that one would actually delete. You would not delete a Fred.

Other bad examples include the deleteAll method. It should use a List instead of an array and should use a for each loop.


This article is a perfect candidate for {{TOCleft}}. I find massive amounts of whitespace very wasteful.

Compare, if you will:
Without TOCleft: Java-without_TOCleft.png
With TOCleft: Java-with_TOCleft.png

What does everyone think? ¦ Reisio 00:29, 2005 August 24 (UTC)

Go ahead --Rogerd 03:12, August 24, 2005 (UTC)

verbosity and typing

A recent edit to this article claimed that "Any strongly typed language will have more type declarations" (presumably, when compared to a weakly-typed language). This is wrong:

  • strongly-typed languages don't need explicit type annotations at all, according to most definitions of strong typing. Perhaps the author meant statically-typed.
  • statically-typed languages do not necessarily require explicit type annotations, either: the compiler just needs to be able to infer type information at compile-time. ML and Haskell are two examples of statically-typed languages in which type declarations are uncommon (most types are automatically inferred by the compiler).

IMHO there is more to the "Java is needlessly verbose" claim that just the cruft that results from type declarations, anyway. Neilc 20:35, 30 August 2005 (UTC)

I think we're in agreement about what I see as the main issue... that type declarations aren't a major contributor to Java verbosity. I have no problem if someone wants to talk about Java's verbosity or any other perceived flaw, I just feel like we should accurately reflect what is unique to Java as opposed to what is a paradigm that someone would find problematic in any language. For example, see the previous objection to getters and setters, and the objection that Java isn't a procedural programming language. The Hokkaido Crow 21:26, 30 August 2005 (UTC)


Hi. In an attempt to clarify what I thought was one of the other editors' objections to Java I wrote this:

Properties — public fields that are tied to code rather than directly to data — are not supported in Java. A more verbose convention involving get and set methods is popular and has substantial tool support.

The Hokkaido Crow reverted my edit this with the comment it appears to have factuality problems, but s/he didn't elaborate. What are the factually problems?

Ben Arnold 22:14, 30 August 2005 (UTC)

Java has public properties

I'd like to discuss someone's contention that Java doesn't have public properties and that it requires accessors. In Java, it is possible to declare all your properties public and never require a get/set to manipulate them if you don't want. Accessors are just a convention, not a language requirement. This convention is completely optional and can be observed in any language. If I've misunderstood the objection, please correct me, but these basic facts need to be clear. The Hokkaido Crow 20:31, 26 August 2005 (UTC)

I don't think that is what the previous poster was refering to. In java, you cannot define a 'property' in the usual sence without using an instance method, whereas languages like C# have build in support for properties. Your answer only works if you want a read/write property, but fails for anything else.

For contrast, in C# we can write:

public string ReadOnlyProperty
     return "a string";

public string WriteOnlyProperty
     someString = value;

public string ReadWriteProperty
     return someString;
     someString = value;

which provides us with syntax like: string s = o.ReadOnly; // o.ReadOnly = "something" will fail o.WriteOnly = "some string"; // string s = o.WriteOnly will fail

string s = o.ReadWrite; // Reading ok o.ReadWrite = "a new string"; // Writing ok

I'm not sure if Java 1.5 adds anything like this to the Java language. It doesn't seem strictly needed, but is very useful, though I occasionally wish I could have a public getter and a private/protected setter.  :(

- OracleofTroy 01:34, 3 September 2005 (UTC)

Come again? First, the example you've shown above appears to be particular to C#, and maybe even unique to C#. I don't think the C# definition of "properties" could really be called "the usual sense". Second, one can easily have a public getter and a private/protected setter in Java. Here's how it works (trivial untested code follows):

public class Demo
  // Private variables can only be accessed by methods
  private static String readOnlyStuff = "Please protect me";
  // Using this method, anyone can read it
  public String readStuff() {
      return readOnlyStuff;
  // But only this class can write to it.
  private void writeStuff(String s) {
      readOnlyStuff = s;  

yielding a syntax like:

Demo d = new Demo();
String stuff = d.readStuff();  // no problem
d.writeStuff("Ha ha, I overwrote you"); // this won't even compile due to security violation

The C# approach is interesting and appears to let you have security constraints without forcing clients to call accessors. But don't be fooled, the accessors are still there, and powered by naming convention voodoo. For the minor convenience of letting clients avoid calling accessors, you gain the inconvenience of having double the accessors and introducing wonky naming conventions. Ewwww.

I don't think it's appropriate to take a unique feature of C# and call it a criticism of Java, especially when Java can accomplish the same intention using its own feature set. Now if a majority other languages had this specific feature, or the language lacked any facility for accomplishing this intent, then its absence could be legitimate cause for criticism. The Hokkaido Crow 21:43, 6 September 2005 (UTC)

Delphi and freepascal also have properties which look like fields but actually cause method calls. C++ doesn't have them natively but i've heared there are ways to make use of operator overloading to add them. Once your used to using properties moving to a language where you have to manuall call getters and setters all the time gets to be a real pita. Plugwash 23:00, 22 April 2006 (UTC)

Code examples

I think the article needs some code examples which go beyond hello world (which often doesn't tell much about a language in most cases). Especially for Java as an object oriented language it seems to pay off to have an example which somehow shows how classes are implemented.

For this reason I reinserted the example deleted by Neilc. Of course we may discuss what kind of a more longish example to include so this is just to be considered as a placeholder for a more longish example. Hirzel 07:37, 24 October 2005 (UTC)

But it really is a terrible example, full of errors in terminology and demonstrating nothing useful about the language or OO in general. Where to begin? I'm a bit tied up at the moment. --Nigelj 19:00, 24 October 2005 (UTC)
If you insist on keeping it, can you please make it suck less? Because the current version is pretty bad. Neilc 04:15, 25 October 2005 (UTC)
Per this discussion, I've removed the examples again. If someone really does want to keep them, please improve them before just blindly re-adding them to the page (but I tend to agree with User:MarkSweep that an example isn't really needed, on the main article page at least). Neilc 13:14, 26 October 2005 (UTC)
I agree with Nigelj and Neilc. The code examples that were recently inserted, removed, and reinserted are rather amateurish ("a void is a function") and are not really representative of the language. I wouldn't object to a "Hello, world" program (though the proper place for that is Hello world program#Java, and we already got that covered). But the present examples are better suited (after some necessary cleanup) for a "gentle introduction to Java"-type writeup, perhaps on Wikibooks. I'd much prefer to keep code examples to a minimum, unless they serve to illustrate specific language constructs (e.g. the generalized for loop), as opposed to general lessons about object orientation. --MarkSweep 04:49, 25 October 2005 (UTC)


I find that all comparisons with C++ give a flawed explanation of the latters workings.

Automatic garbage collection

One possible argument against languages such as C++ is the burden of having to perform manual memory management. In C++, memory is allocated by the programmer to create an object, then deallocated to delete the object. If a programmer forgets or is unsure when to deallocate, this can lead to a memory leak, where a program consumes more and more memory without cleaning up after itself. Even worse, if a region of memory is deallocated twice, the program can become unstable and will likely crash.

In C++ there are two different kinds of memory. Memory for automatic objects, which is handled by the language and dynamic memory, which is handled by the programmer. All this requires is a correctly written constructor and destructor method for each class which uses "new".

  • Conversely, C++ programmers can become confused with Java because in Java primitives are always automatic variables and objects always reside on the heap, whereas C++ programmers are explicitly given the choice in both cases by means of pointers.

Another common Java mistake. The type of memory and the way to reference it are separate. In Java objects are really pointers which are automatically referenced and primitive types are references. In C++ all types are handled in exactly the same way. You can have pointers point to automatic or dynamic memory and the same for references. Consequently the "by means of pointers" makes non sense. --MarSch 14:21, 27 October 2005 (UTC)

Introduction is not very good

The summary need more info about what Java is, rather than all this about history and who makes it. Something about what makes Java speical, it's popularity, commons uses, --Apoc2400 07:09, 9 December 2005 (UTC)

I agree. The introduction is terrible. I've removed some of the really obscure trivia ("Oak" was named after a tree outside someone's office) but just about everything else that's in the introduction (i.e. everything after "Java is an object-oriented programming language ..." down to "shares a similar C-like syntax." should be moved out of the intro and replaced by a brief explanation of what Java actually is, where it's used and why it's significant. --Lee Hunter 01:08, 18 December 2005 (UTC)


Patrick Naughton claimed, in a Forbes magazine article he wrote, to have started the Java project (linked from his Wiki bio). Should that be mentioned in this article?


 I started the Java project at Sun Microsystems on December 5, 1990.

-- Brianhe 07:46, 17 December 2005 (UTC)

Java license

Is Java open source? Under what license is Java distributed? C for example is an international standard, therefore everybody is allowed to develop an own C compiler/linker/IDE. What about Java in this context? --Abdull 13:50, 17 December 2005 (UTC)

If memory serves, the Java standard is open; Sun's Java virtual machine implimentation is not. Raul654 16:28, 17 December 2005 (UTC)


Added TOCleft (article is hard to read otherwise on <= 1024x768).

I am the anon above. Why was the {{TOCleft}} reverted? Not everyone runs at 1280x1024. --DCrazy talk/contrib 17:11, 18 December 2005 (UTC)

"more robust runtime environment"?

The introduction states that Java is a variant of C++ with a "more robust runtime environment." As far as I know, C++ has no runtime environment except the operating system itself, which the JVM also runs on top of. Can we fix this little erratum?

--Duke 21:26, 20 December 2005 (UTC)

Should platforms be listed in Infobox?

Should Microsoft .NET, a software platform, be listed under Influenced in the info box? I added C#, which is the real influence of the Java language. .NET should be listed as a software platform influenced by the Java platform, not the language. I left .NET in the info box for now, but unless there are objections, I intend to remove it. -- Doug Bell 18:40, 10 January 2006 (UTC)

.NET is more comparable to (and competes with) J2EE. I agree with your removal. Ohnoitsjamie 18:42, 10 January 2006 (UTC)
My impression of what influenced what is: Java => C#, J2EE => .NET, JVM => CLR, Java byte code => IL code; I was considering removing it also. --Flash 02:29, 11 January 2006 (UTC)

Removed .NET from Influenced, added Objective C to Influenced by.-- Doug Bell talk/contrib 19:21, 11 January 2006 (UTC)

Self-enforcing complexity management?

The first bullet under criticisms is:

  • Not all projects or environments require enterprise-level complexity, such as stand-alone websites or sole-proprietorship programmers. Such individuals find Java's self-enforcing complexity management to be overkill.

What exactly does self-enforcing complexity management mean? If this is referring to Java EE, it belongs in a different article. I think this statement needs to be clarified or removed. – Doug Bell (talk/contrib) 21:20, 17 January 2006 (UTC)

Organizing content

I created a subpage, User:Flash200/Programming-language outline, for describing and discussing the content reorganizing I've been doing in the past couple weeks for a number of programming-language articles. I recently tried moving the Java history much farther down in the article, but quickly reverted the change because of feedback from a couple users.

Recently, someone changed the Python article, putting the philosophy at the beginning of the article with the commentary, "Put philosophy before history (what it IS is more important than how it got there)." So far no one has objected to that particular change, and it made sense to me. Would anyone object to placing history immediately after philosophy for the Java article, or for other programming articles in general? Please feel free to comment either here, on the subpage, or on my talk page (one user has already commented on my talk page). --Flash 23:38, 18 January 2006 (UTC)

Also see User:Dysprosia#location_of_the_history_section. —Ruud 23:44, 18 January 2006 (UTC)
In almost all cases, history should be before anything else. It is important for framing the article properly. Dysprosia 04:08, 19 January 2006 (UTC)
I started out writing a response here in favor of putting philosophy first based on the argument that the history is rarely succinct, whereas philosophy should be. However, examining the article on Java convinced me that my argument didn't hold. The philosophy is definitely a more in-depth discussion of Java and less likely to be accessible to a lay reader. So now I've gone 180° before even presenting my case. – Doug Bell talkcontrib 05:24, 19 January 2006 (UTC)

Moving sections on Syntax and Resources out to child articles

With the current reorganization of the article, the sections on syntax and resources stand out now as:

  • technical details unlikely to be of interest to non-programmers; and
  • stylistically different than the rest of the article being primarily recapitulations of information widely available elsewhere.

I think these sections have worthwhile content, but I think including a high-level summary and a link to a child article for each of these sections would tighten up the article. – Doug Bell talkcontrib 05:24, 19 January 2006 (UTC)

I'm working on splitting off the syntax section, but I'm a little unsure about exactly where to draw the line and what to leave behind. Should everything except a brief summary of the syntax be moved into the "Java syntax" article, or should some parts of it be left behind? For the C and C syntax articles, the main article still covers a lot of ground about the syntax, and the syntax article does a lot more than just listing correct syntactical expressions.
At the very least, would a brief summary (moving everything else to the syntax article) be an adequate solution? Not necessarily an ideal solution but an adequate one. I'd favor moving as much of the syntax info as possible (aside from a brief summary) into the sister article, so that if someone wants to learn about the syntax, they simply go to the syntax article, period; they don't have to keep going back and forth between the two articles. --Flash 18:22, 22 January 2006 (UTC)
I added a brief summary to the beginning of the syntax section. In theory, this is all that would be left behind when the syntax article gets created. --Flash 19:59, 22 January 2006 (UTC)
My preference would be to move as much as possible to the child article. However, I could also see some logic in including the annotated Hello World example in the Java programming article to give a reader of the Java article the flavor of the syntax. While I could see expanding the summary somewhat from what you have included, I would not expand it to the same extent as the C programming article. – Doug Bell talkcontrib 21:33, 22 January 2006 (UTC)
Done. I moved all of the syntax except for the summary and the Hello World example into the Java syntax article. I don't have any plans to split off the Resources section, but I'd have no objection to someone else doing so. --Flash 00:48, 23 January 2006 (UTC)

Merge from Java 2 Platform, Standard Edition

I realize this article is already too long, and we should be discussing splitting parts off (see #Moving sections on Syntax and Resources out to child articles), but nevertheless I think that the Java 2 Platform, Standard Edition article should be merged here. The difference between the Java language and the Java platform is hopelessly blurred. You can't discuss the language in abscence of the libraries in any meaningful way.
Consider that java.lang contains classes that are central to the language. The article on the language already has significant discussion of the libraries. The sections in the Java SE article that list and summarize the packages are better served by the Javadoc API documentation. (Compare Java SE 8 API Javadocs to the list of packages in the article—the article is nearly a complete subset.) The only really relevant thing that needs to be discussed regarding the platform is to describe the distinction between the platform and the language and explain what constitutes the platform. I suspect that can be accomplished in a paragraph.Doug Bell talkcontrib 11:19, 20 January 2006 (UTC)

Actually, what makes sense is to merge to Java 2 Platform, Standard Edition to Java platform so I've moved the discussion there. – Doug Bell talkcontrib 18:34, 20 January 2006 (UTC)

Operators and basic syntax

Is is really useful to clutter the article with basic syntax as this? We're not here to instruct the user on how to write basic Java. Dysprosia 09:16, 22 January 2006 (UTC)

  • Cluttering the article -> See the discussion above about splitting syntax (and possibly resources) into separate sister articles.
  • Basic syntax details -> Added up, those little differences in syntax of one language to another have as much to do with identifying what the language is, and how it's different from other languages, as do the high-level discussions about philosophy and history.
  • Teaching how to write basic Java -> The syntax details are not attempting to teach someone to use the language, and they're not attempting to teach the basic concepts of programming (the "References" and "External links" sections serve that purpose), they're simply showing in detail what the language actually is. HTH --Flash 17:06, 22 January 2006 (UTC)
The basic syntax is almost identical to that of languages such as C or C++. A paragraph noting this similarity I think would be much more fruitful than a reexplanation. What would be exciting and interesting would be a page possibly describing the grammar of Java in formal forms (EBNF or somesuch). Dysprosia 05:18, 23 January 2006 (UTC)
The formal grammar can be found in the syntax chapter of the Java Language Specification. We could link to that, but I don't see the point of also having the formal grammar here. --MarkSweep (call me collect) 06:00, 23 January 2006 (UTC)
The more similar some languages are, the more difficult it can be to get a clear idea of how they differ, and the more helpful I find it is to list the syntax for each of them. As an example, I learned PHP, Perl, and Bash scripts at roughly at the same time, all of which share a common ancestry and a very similar but inconsistent syntax. I found it to be invaluable to have cheat sheets (brief listings of the syntax) to avoid confusing one language with another. The same applies with C++ and Java; they're very similar syntactically, but there are inconsistencies throughout the syntax.
Syntax details are of great benefit to some of the people, they're encyclopedic in nature (as is formal grammar), and they require very little effort to create and maintain (much of it can be copied and pasted from other languages, and the syntax for a language tends to change very little over time). Plus, most of the details can be isolated in sister pages, without weighing down the main articles. In other words, there's a need, it's appropriate, and it doesn't get in the way of anything else. So I don't really see a downside.
On the same note, I'd have no objection to including the formal grammar, as long as there's even a single person that finds it useful, and as long as it doesn't weigh down the main article. I don't think the easy availability of info from other sources, or the size of the target audience, is enough of an argument to avoid adding something to Wikipedia. One of the key qualities of Wikipedia is that the content is and will remain freely available. There is no such guarantee with most other sources of information, regardless of how easily and readily available they are at present. Adding encyclopedic info to Wikipedia essentially ensures that the knowledge won't be lost, that it will remain permanently in the hands of the community. --Flash 20:09, 23 January 2006 (UTC)

Reg Ex

"Java's support of text matching and manipulation is not as strong as languages such as Perl or PHP, although regular expressions were introduced in J2SE 1.4."

This point no longer seems to be very valid. Although the mention of regex in J2SE 1.4 is nice, the truth is that Java now has reg ex support every bit as good as perl or php. The above sentence is seems to say that Java's regex is lacking, having early, minor support at best. That has not been my experience.

- Mark

Garbage collection performance

Before someone yells at my edit...

It is pointed out again and again in the article that automatic garbage collection can improve performance if used properly, but I think that's a little misleading. The very nature of automatic garbage collection requires extra operations to check whether or not a given object is safe to delete, and can never be as efficient as well planned manual garbage collection. The argument to make is that manual garbage collection is too error-prone and difficult to program, but pretending that you don't take a performance hit for that convenience is misinformation.

Meekohi 18:30, 8 March 2006 (UTC)

You might want to familiarize yourself with the Garbage collection (computer science) article or with the discussion on this topic on this talk page. The fact of the matter is that when using generational garbage collection, many objects end up being deallocated as a group without any operations required for the specific object. This is in contrast to manual deallocation which requires memory mangement operations specific to the individual object. What you are missing is that the reduction in time spent performing the deallocation is greater than the time spent determining if the object can be deallocated. – Doug Bell talkcontrib 19:01, 8 March 2006 (UTC)

FWIW, each JVM behaves differently, but if you want your real time Java applet to work on all widely available JVMs, you should bear in mind that the time it takes to garbage collect depends on the number of objects (rather than their size). We generally have small arrays of big objects rather than big arrays of small objects, and this does the trick. Stephen B Streater 10:16, 9 March 2006 (UTC)

Re: "gc can never be as efficient as well planned manual garbage collection". I'm not familiar with the term "manual garbage collection", do you mean malloc()/free() or C++'s new/delete? If so, try this experiment: in a tight loop allocate and free objects, i.e. free(malloc(16)). Then write the equivalent Java program that uses GC, i.e. "new Integer(1)". Compare speed. I get the Java version being 10x faster than malloc/free. So I'm not convinced the word "never" applies. What speeds do you get? Weregerbil 11:28, 9 March 2006 (UTC)

Alright, I'm obviously not going to win this battle, but I'd like to point out that the above test is unfair. You are comparing the Java GC, which collects at its leisure, with the worst case forced allocation/deallocation setup in C. I'd be curious to see that java program what happens if you compared a tight loop of mallocs, with deallocation saved until the end of the program, or at least something more sensible. Obviously Java will beat an idiot programer at memory management, but I still believe it is fundamentally slower if both are working at their best for the reasons described above. Meekohi 02:28, 13 March 2006 (UTC)
There have been a number of real-world tests with real-world applications. Not all perform better with a generational garbage collector vs. manual deallocation, but a (perhaps) surprising number do. It really depends on how many short-lived objects are created—many short-lived objects favor a generational garbage collector since all objects are allocated in the "nursery" and are never moved from the nusery—all the orphaned babies get thrown out with the bath water in one fell swoop. It is definitely not just contrived applications that benefit. Both the allocation and deallocation of these short-lived objects—averaging just a handfull of machine instructions each—are cheaper in a generational garbage collector than the corresponding operations in traditional dynamic memory management that has to deal with fragmented memory. – Doug Bell talkcontrib 05:27, 13 March 2006 (UTC)

Recent history

I suggest some improvements could be made to the first paragraph of this section.

It doesn't mention here yet, or in the previous internet section, that web browsers can run Java as Java applets.

Also, the Microsoft Java story is more interesting than portrayed here. Microsoft called their software "Java", but the trademark case ruled that it was not (quite) Java and Microsoft was breaching Sun's trademark by calling it Java. The first Windows version without "Java" was Windows XP shipped in 2001 - an age ago in computing. The effect of this decision on the modern installed base has long since largely faded. In reality, manufacturers stepped in and for several years have shipped Java with their Windows, Mac OS X and Linux boxes like they ship, for example, hard discs - for some time, shipping Java has had nothing to do with Microsoft.

Flash is doing well, but this doesn't seem to be at the expense of Java. At least in the UK, people were using Flash for websites back in 2000, and showed no inclination to switch to Java for this purpose. I doubt that Java is itself diminishing though. 90% of people who go here can watch the Java video. This figure has been pretty constant for years. Most of the rest are prevented by corporate firewalls and security settings (which could likewise prevent Flash, even if it is installed). The flexibility of Java allows the software to be updated even if the underlying Java is unchanged. However, the sophistication of Java is more suited to complex applets like Clesh than for flashy graphics on a web page.

So in conclusion, manufacturers have decided to ship their computers with Java, most web browsers can run Java applets without requiring the latest update, and Java is not diminishing. Stephen B Streater 21:49, 8 March 2006 (UTC)

I've updated this section.

Video applications are the most demanding web-run Java applications I have come across because of the hugh CPU requirements, combined with real time requirements. I haven't linked to any of these in the article, as I'm a bit to close to the companies involved, but here are a few for verification:

There are lots more, including Java MPEG players. Stephen B Streater 11:03, 12 March 2006 (UTC)