Talk:Java (programming language)/Archive 4

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: 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 talk•contrib 19:01, 8 March 2006 (UTC)

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

text: 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)
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: There is a section along the lines of "Java is the new COBOL or maybe ALGOL". Could the section be worded in a clearer way?
To me COBOL is (for its time) a very popular business programming language, and I mostly remember ALGOL for not having a concrete syntax. The section also talks about entrenchment which according to Webster's means "take something unfairly or unlawfully" (ignoring concrete hole digging meanings). There is also talk of resistance to change and over-inflation. So in whole to me the section reads:
Java is occasionally compared to other languages. Java will become very popular in the business sector which is unfair and/or illegal. It will change too little while simultaneously over-inflating. Some day it might not have a concrete syntax. This is a hyperbolic and/or legitimate concern.
Probably not what the critic meant. Can it be stated more directly and less ambiguously, without depending on the reader having knowledge of and a suitable negative image about COBOL et al? Weregerbil 19:31, 11 March 2006 (UTC)
replies: text: Thanks for the good laugh!  :-)  I love your translation...  —Doug Bell talk•contrib 07:00, 20 March 2006 (UTC)
thread_title:  COBOL 

message: IMO we need a top level article with a title of say Java (computing) or Java (sun) to which incoming references to java can be directed. This would then discuss java as a whole (and take most of the incoming links from other topics) and deffer to the more specialist articles for more detail. Right now this page is an uncomfortable mismash of a java programming language article and a top level java article. What do others think? Plugwash 22:52, 10 April 2006 (UTC)
replies: text: I agree with this. WP is supposed to be accessible to the layman. A top level article could be short and describe what Java is for and how the user experiences it without going into technical details. I think something more like Java applet, but less specific and covering all of Java, with wikilinks to illustrate in detail each aspect of Java. Stephen B Streater 06:37, 11 April 2006 (UTC)
replies: text:  Well i've made a start on an article at Java (Sun) i'll hold off changing the links to point there until its a reasonable article though. Plugwash 11:07, 12 April 2006 (UTC)
replies: text:  I've started to contribute to this too. Stephen B Streater 22:26, 12 April 2006 (UTC)

text: I think in the right side box, various implemetations of Java must be listed, the list is right now empty. eg. The implementations mentioned in external links section can be put over there. -- Mritunjai 06:23, 19 June 2006 (UTC)
thread_title:  top level Java article 

message: I removed: A more appropriate comparison might be ALGOL 60, the Java of its day back in the mainframe era, which lost its way after it over-inflated into ALGOL 68.  
Basically the problem with Algol68 centers around an "unpublished" minority report by a member of the IFIP Working Group 2.1
C. A. R. Hoare: 'The best we could do was to send with it a minority report, stating our considered view that, "... as a tool for the creation of sophisticated programs, the language was a failure."'
Algol68 is not much like Java as Algol68 only has  a standardised math & io library and very elementary classes.  Whereas Java has many standardised libraries and is fully object oriented.
One could say Algol68 is more like "distilled" C99, but Algol68 has OP-erator overloaded, stronger typing and the PAR-arallel clause. 
NevilleDNZ 10:13, 22 April 2006 (UTC)
thread_title:  revert: the Algol60=>Algol68 comparison  

message: (First comment copied and second (which was inserted out of order) comment moved from section above:)
What i mean is for example C++ you can implement reference counting in your own code to deal with memory and non-memory rescources. Javas garbage collection takes away the resposibility for managing memory rescources but javas language design takes away the tools needed to manage non-memory rescources any way other than manually. Plugwash 17:07, 29 April 2006 (UTC)
replies: text: The constructor/copy constructor/destructor system. Sure you could implement reference counting if you consider manually incrementing and decrementing the reference counts acceptable but if your going to force your users to do that you may as well not bother with the reference counting in the first place. Plugwash 23:15, 29 April 2006 (UTC)
replies: text:  Actually, you can use a  to do what you are suggesting.  The constructors for the class would create and maintain a  for each constructed object.  This will allow the program to track when the garbage collector changes the reachability of an object to phantom reachable, which happens before it is garbage collected. —Doug Bell talk•contrib 23:43, 29 April 2006 (UTC)

text: Now that I understand the point you were trying to make, I think the entire bullet point should just be deleted.  It's simply a misunderstanding—what you are talking about can be done in Java.  J2SE 1.2 added the ReferenceQueue and PhantomReference to provide a better alternative to finalizers.  You can still have explict dispose() methods in a class to facilitate having the resources released explicitly, to overcome the uncertainty with finalizers.  The combination of an explicit dispose with PhantomReferences actually provides a better solution to the problem than destructors in C++ because the possibility of the object becoming dereferenced without the desctructor being called, and thus the resource never being reclaimed, is removed. —Doug Bell talk•contrib 00:13, 30 April 2006 (UTC)
replies: text:  OK, I'm taking the silence to mean agreement, so I deleted the bullet point about reference counting from the "Criticisms:General" section in article. —Doug Bell talk•contrib 02:41, 2 May 2006 (UTC)
thread_title:  Reference counting 

message: Java's support of text matching and manipulation is not as strong as languages such as Perl, Ruby, or PHP, although regular expressions were introduced in J2SE 1.4
I don't think this is true. There's almost no differences from perl regular expressions (see regex  documentation), 4 Perl constructs are not supported, but 2 additional Java constructs are not supported by Perl, I don't think that minus two constructs can make for "not as strong". Also there are some limitations in PHP regex support, see for example  Hervegirod 09:35, 20 May 2006 (UTC)
thread_title:  Text matching support 

message: I think that the Look and Feel and Performance sub-chapters should  be separated from the Criticism chapter, because their scope is wider than just Criticisms about the language - Hervegirod 10:19, 20 May 2006 (UTC)
replies: text: I thik that it is important to mention that non-opensource nature of Java is only partially true. SUN makes just one of the implementations and other competing implementations exist from IBM and BEA Systems. However, none of them are truly open source (SUN's is partially, IBM and BEA's not at all!). So saying that Java, the language, is not open source will not be factually correct. Implementations like Blackdown and GCJ are freely available, though not mature and feature complete yet. So, as a matter of fact, non-inclusion of Java on open source platforms is because open source implementations are not complete yet. Mritunjai 06:06, 19 June 2006 (UTC)
thread_title:  Criticism 

message: HI , I added a very useful link , but a guy or other is removing them . Can they provide us with the reason for that ? a tutorial better than SUN itself ! Alhoori 00:09, 21 May 2006 (UTC)
replies: text: This has already been discussed in your talk page. Your contribution history suggests an attempt to use Wikipedia to promote your personal site. OhNoitsJamieTalk 03:13, 21 May 2006 (UTC)
replies: text:  Sorry , but this tutorial was there for weeks , and your removed it with no useful reason ! Can you provide a useful easy tutorials for members like this ? WE ARE WAITING .Alhoori 09:13, 21 May 2006 (UTC)
thread_title:  Removing links 

message: The article states that libgcj is being merged with classpath, but the webpage of libgcj states that "libgcj has been merged with GNU Classpath". Jorge Peixoto 01:30, 27 May 2006 (UTC)
thread_title:  Update the article