Talk:Java programming language/Archive 1

message: 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)
thread_title: Poorly Written/Misleading section

message: 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 http://www.hpl.hp.com/personal/Hans_Boehm/gc/#details 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)
thread_title:  Performance Impacts 

message: 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. – Smyth 13:11, 13 Nov 2004 (UTC)
replies: text: There is also a section on Java as a platform on the Platform (computing) page.--Jondel 18:49, 25 Sep 2004 (UTC)
thread_title: Java a platform too

message: 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: 
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 java.sun.com. 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..
 Versions
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)
thread_title:  JDK versions 

message: Someone has gone completely bezerk with links:
.  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)
thread_title:  Link bezerker 

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

message: From the article: This should not be confused with the
 break label;
and
 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)
thread_title: Confusing terminology

message: Does Sun specify how the word "Java" should be pronounced? Merriam-Webster  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)
replies: text: It's because Americans say body like baaahhdeee... Dysprosia 11:21, 25 Apr 2004 (UTC)

text: 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).
--204.101.190.5 00:42, 7 May 2004 (UTC)
replies: text:  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)
thread_title: Pronunciation

message: 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)
replies: text: I have made a start on this. – Smyth 13:12, 13 Nov 2004 (UTC)
thread_title:  Split this up, JRE & JDK seperated 

message: 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. – Smyth 13:13, 13 Nov 2004 (UTC)
replies: text: 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)
replies: text: 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)
thread_title:  JVM and JRE 

message: 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)
replies: text: 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)
thread_title:  Responses to the Java Language is outdated 

message: 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)
replies: text: I've added a link to strictfp, which is mentioned in Java programming language#Version history. --MarkSweep 18:20, 2 Apr 2005 (UTC)
thread_title: [[Strictfp]]

message: Yet another mass delete, please discuss large changes here first and get the version correct please :*)
--Calvin 22:17, 19 Apr 2005 (UTC)
thread_title:  Edits by 67.118.123.235 

message: 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)
thread_title:  "Sun Control" comments in API 

message: 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!
* Non-free IDEs
**CodeGuide
**IntelliJ IDEA
**JBuilder
**JCreator
**JCreator LE (freeware)
**IBM Websphere Studio Application Developer
**BEA Weblogic
** Oracle JDeveloper
: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)
thread_title:  Non-free IDEs under: 'Related free software' is ambiguous! 

message: :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)
thread_title:  Advanced Placement Program exam 

message: 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 . violet/riga (t) 12:36, 28 July 2005 (UTC)
replies: text: Most articles on programming languages follow the format "X programming language". Dysprosia 12:40, 28 July 2005 (UTC)
replies: text: 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)
thread_title:  Naming 

message: 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)
thread_title:  public, abstract, static, and final 

message: 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)
replies: text: 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)
thread_title:  verbosity and typing 

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

message: 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)
replies: text: 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)
thread_title: Java has public properties

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

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

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

message: 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)
thread_title:  C++? 

message: 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.
</blockquote>
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)
thread_title: Automatic garbage collection

message: 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)
replies: text: 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)
thread_title:  Introduction is not very good 

message: 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?
Quote:
  I started the Java project at Sun Microsystems on December 5, 1990.
-- Brianhe 07:46, 17 December 2005 (UTC)
thread_title:  Inventors 

message: 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)
replies: text: If memory serves, the Java standard is open; Sun's Java virtual machine implimentation is not. Raul654 16:28, 17 December 2005 (UTC)
thread_title:  Java license 

message: Added TOCleft (article is hard to read otherwise on <= 1024x768).
: I am the anon above.  Why was the  reverted?  Not everyone runs at 1280x1024. --DCrazy talk/contrib 17:11, 18 December 2005 (UTC)
thread_title:  TOCleft 

message: 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 71.198.170.40 21:26, 20 December 2005 (UTC)
thread_title:  "more robust runtime environment"? 

message: 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)
replies: text: .NET is more comparable to (and competes with) J2EE.  I agree with your removal. Ohnoitsjamie 18:42, 10 January 2006 (UTC)

text: 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)
thread_title:  Should platforms be listed in Infobox? 

message: 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)
thread_title:  Self-enforcing complexity management? 

message: :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  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 talk•contrib 11:19, 20 January 2006 (UTC)
thread_title:  Merge from [[Java 2 Platform, Standard Edition]] 

message: 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)
replies: text: 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)
replies: text: 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 talk•contrib 05:27, 13 March 2006 (UTC)
thread_title:  Garbage collection performance 

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