Talk:Java (programming language)/Archive 4

This is an archive of past discussions about Java (programming language). Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 1

Archive 2

Archive 3

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 ^{talk•contrib} 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 ^{talk•contrib} 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:

Vividas very high quality video
Clipstream quite well known
Forbidden live streaming
Forbidden video editing and publishing

There are lots more, including Java MPEG players.

Stephen B Streater 11:03, 12 March 2006 (UTC)

COBOL

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)

Thanks for the good laugh! :-) I love your translation... —Doug Bell ^{talk•contrib} 07:00, 20 March 2006 (UTC)

Good easy tutorial

I have added thid easy tutorial , but it was removed why ? —Preceding unsigned comment added by Alhoori (talk • contribs) 06:09, 20 March 2006

Java wiki

Why there is no Java wiki tutorial where all users in the world update it ? —Preceding unsigned comment added by Alhoori (talk • contribs) 23:42, 30 March 2006

There is in Wikibooks.. wikibooks:Java Programming —Pengo 08:11, 3 April 2006 (UTC)

thanks , but it is still in the beginning . —Preceding unsigned comment added by Alhoori (talk • contribs) 06:54, 4 April 2006

revert: the Algol60=>Algol68 comparison

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)

`Runtime.getRuntime().gc();`

I see that Doug Bell reverted my edit of 21:36, 28 April 2006. I wasn't suggesting System.runFinalization(), but as above. Whenever I've run this, on GUI desktop apps, it has done the job immediately. (Was it Eclipse or Netbeans that used to have a toolbar button to do the same job, complete with progress bar to show it working wrt memory at least?). Maybe it's not so definite for busy server-side apps, is that it? I know that the JavaDoc says "Calling this method suggests that the Java virtual machine expend effort toward running the finalize methods..."[1] (My emphasis), but e counting in Java for managing non-memory resources? What is the language feature you think always took that just to mean that it runs in a lower-priority thread, not that it may not do anything at all. I do think that the paragraph is too strongly negatively worded as it is, for NPOV. --Nigelj 10:50, 29 April 2006 (UTC)

As to how finalization works, it isn't a matter of desktop vs. server, but rather the semantics required of the JVM. You can't make a statement that is based on something you've observed in some circumstances when referring to the general case. As to the current wording, the only issue I have is with "Java lacks the language features needed to implement automatic reference counting". Reference counting is neither restricted (you could implement a JVM using reference counting, but it is so much more inefficient that nobody does) nor a language feature, so this needs to be removed, or if you were trying to make a different point, then reworded. —Doug Bell ^{talk•contrib} 17:00, 29 April 2006 (UTC)

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)

With all respect, Doug, I'm basing my question to you on the principle that it "Walks like a duck, sounds like a duck, it's named 'duck', it's described as a duck in the spec...": There is a method called gc(), that always invokes the GC, and Sun's JavaDoc says "When control returns from the method call, the virtual machine has made its best effort to recycle all discarded objects." Yet you tell me "You can't make a statement that is based on something you've observed in some circumstances when referring to the general case." What general case is that, then? I'm sorry, but the phrase "but rather the semantics required of the JVM" doesn't really explain your point to me. We are all very clear about circular and cyclic dependencies, weak, soft and phantom references etc, but all that is not relevant - we can assume here that if a designer is intending to invoke GC to help clear resource-holding objects, he will first have made sure that they are unreachable. I agree that if it were essential that these resources were freed in total and immediately, this would not be the best way to do it. I'm taking issue with the way you wanted the paragraph in the article worded, your dismissive revert of my edit and your dismissive tone above, as if I'm making a schoolboy error by extrapolating some dubious personal experience without reading the spec. I assure you I have read widely, but I'm always ready to learn something new and I wonder if you know something I don't, and if so what it is. It may be that the article would benefit from it being included explicitly. --Nigelj 18:00, 29 April 2006 (UTC)

I have limited experience, being involved only in Java applets on various JVMs. My experience is that the garbage collect routines behave inconsistently between JVMs. Some are quick, some are slow. Most seem to take a time depending on the number of objects. But none of them seem to work properly when you ask them to. Quite a few don't release all the available memory for many seconds, or even after the web page has been closed, which is a bit annoying. If there is a specific issue here which needs another opinion, I'll ask the guys at work next week who understand the detail. Stephen B Streater 21:42, 29 April 2006 (UTC)

First, please don't read anything into my reply as being dismissive or disrespectful, ok? Let's not even start in that direction—I'm not intending any of that. My last comment above was made quickly as I was headed out the door, so it was rather more abbreviated than I would normally make, and I apologize if it gave the wrong impression.

By saying that "you can't make a statement that is based on something you've observed in some circumstances when referring to the general case," what I mean is that there are many JVM implementations. Observing how some specific JVMs choose to implement the specification may lead to incorrect assumptions about how how all JVMs behave. (This was particulary true in regards to threading, which is why JSR 133 was needed, and even now getting acceptable behaviour for multi-threaded apps across JVMs is challenging.) The fact is that the selection and implementation of garbage collection algorithms varies considerably from JVM to JVM and many do not behave the way you might expect when System.gc() (or equivelantly, Runtime.getRuntime().gc()) is called. And calling System.runFinalizers() (or equivelantly, Runtime.getRuntime().runFinalizers()) is even less likely to accomplish what the "programmer intended" because, perhaps unintuitively, the entire process of gc and finalization is often performed in stages by a number of different threads. The statement in the JavaDoc for gc() "When control returns from the method call, the virtual machine has made its best effort to recycle all discarded objects" is almost misleading as some JVMs (especially JVMs that implement the Real-time specification for Java) don't do ANYTHING when this is called, because the garbage collection routines are incremental and NEVER do stop-the-world gc. By referring to "the semantics required of the JVM", I am referring to the latitude intentionally allowed the JVM by the JVM spec and the JLS, which is intended to allow a wide range of JVM implementations.

One final issue, not related to the statement in the article but related to using finalizers, is that instances of classes that have implemented (overridden) finalize() are often handled much differently by the garbage collector. The cost of reclaiming objects with finalizers can be an order or two of magnitude more expensive than reclaiming objects without finalizers, so there are other good reasons not to rely on finalizers. —Doug Bell ^{talk•contrib} 23:00, 29 April 2006 (UTC)

Reference counting

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

I guess I don't follow. Why can you not implement reference counting in Java for managing non-memory resources? What is the language feature you think is available in C++ that is missing? —Doug Bell ^{talk•contrib} 23:00, 29 April 2006 (UTC)

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)

Actually, you can use a ReferenceQueue to do what you are suggesting. The constructors for the class would create and maintain a PhantomReference 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)

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)

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)

Text matching support

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 Pattern 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 [2] Hervegirod 09:35, 20 May 2006 (UTC)

Criticism

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)

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)

Removing links

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)

the useful site was there since month http://wiki.riteme.site/w/index.php?title=Java_programming_language&oldid=50732240#Tutorials Alhoori 01:19, 21 May 2006 (UTC)

This has already been discussed in your talk page. Your contribution history suggests an attempt to use Wikipedia to promote your personal site. OhNo itsJamie ^Talk 03:13, 21 May 2006 (UTC)

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)

Update the article

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)

Are the criticisms outdated?

Java failed to deliver industry standard arithmetic capabilities. The IEEE 754 Standard for Binary Floating-Point Arithmetic had appeared in 1985 and has remained an industry standard since then. While Java's floating point arithmetic is largely based on the standard, certain features are not supported. Details about this kind of criticism can be found below in the external links section.

Doesn't the strictfp keyword (there since Java 1.2) support strict IEEE754? If not, please explain how. Or please, at least, cite which external link explains this criticism.

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.

Can someone list what text matching and manipulation support is lacking in Java since the addition of regex?

Java code is often more verbose

Is this still true? The criticism cites manual casts and then says that isn't an issue.

Java is predominantly a single-paradigm language. Historically, it has not been very accommodating of paradigms other than object-oriented programming. As of J2SE 5.0, the procedural paradigm is somewhat better supported in Java with the addition of the ability to import static methods and fields so that they can be referenced without prepending the class name.

So is Java still a single-paradigm language? It sounds like the answer is "somewhat". Can't we be a little more precise to what the problem is?

Java's semi-proprietary nature, supposed inflexibility to change, and growing entrenchment in the corporate sector, have caused some to refer to Java as "the new COBOL". Many consider this to be a somewhat hyperbolic assertion, although it does allude to some legitimate concerns with Java's prospects for the future. However, Sun announced in JavaOne 2006 that Java will become Open Source. The statement was issued by Sun Software Executive Vice President Rich Green : "It's not a question of whether, it's a question of how, and so we'll go do this."

Huh? Yes, there are some issues people have with Java licensing, but this ("inflexibility to change", "growing entrenchment", "the new COBOL") is unhelpful. The criticism even says that it is somewhat hyperbolic. Well, this is an encyclopedia if it is somewhat hyperbolic it should be changed. Please cite some concerns with the licensing (e.g., not in Debian main and not quick to add new features) instead of the unhelpful comments that are there right now. There are people who think that GPLing Java would be a bad thing (e.g., multiple incompatible versions of Java).

This section reads as if one person wrote a criticism and then someone else wrote a "however" afterwards to say the opposite of the criticism. I don't know what criticisms are still valid and what ones are addressed.Chiok 19:34, 27 May 2006 (UTC)

Java references across WP were quite hostile before I came along. I have worked with a few other editors to update a lot of articles to reflect more recent innovations from an applet end-user point of view, but my expertise is limited to what I can get my applets to do. I'm not an expert on comparisons with other languages, but it wouldn't surprise me if the more detailed programming sections need updating too given the progress is other areas. Stephen B Streater 22:37, 27 May 2006 (UTC)

I've been editing the criticisms and while they are better, I'm still not happy with them. The main problem is that most of them aren't criticisms, but rather they are statements of fact. Java isn't a strictly pure object-oriented programming language, does not support user-definable operator overloading, and doesn't have true multiple inheritance. Okay, well, so what? _Why_ are these bad things (esp. since they were all intentional)? I'm tempt to just delete these as they are not criticisms. They might belong somewhere in the article as clarifications, but not here as they stand.

The IEEE criticism is similar. This one is much more technical, but I'm not completely clear on what the problem is. I don't exactly know why not being IEEE compliant is a problem. Is the floating point arithmetic less accurate? Is it slower? Can it give you wildly wrong answers. Sun surely knows about this and they made the intentional decision to part with IEEE in certain ways and I'm not sure what their reasoning was. (I'm also not quite positive why strictfp and Math.IEEEremainder don't make it IEEE compliant. The cited workshop slideshow presentation is 8 years old, so I'm not sure if the floating-point handling has improved since then.)

There are some valid criticisms of Java that aren't mentioned. I'm sure the way Java handle Generics (esp. erasure) can bring up a few criticisms. I seem to remember Bruce Eckel making several "What were they thinking?" comments in Thinking In Java. I'd much rather see criticisms from the likes of Eckel, Bloch, Sierra & Bates, and other published Java authors here.Chiok 05:14, 29 May 2006 (UTC)

In the criticism section there are currently three items under "memory management":

Programmer skills for dealing with leaks. Is there a source for this statement? Memory leaks are so very different beasts in C and Java. I don't find my C experience helpful for memory leak hunting in Java (though I recall doing that only once in my life...) With the biggest C programs I worked on I was lucky to have Purify; there is nothing remotely like that needed in Java.
Stack vs heap, giving the programmer the choice. Escape analysis^{please expand this article if you know about the subject} and register allocation make the statement about stack/heap storage incorrect. A JIT that does register allocation stores primitives on stack or in registers, and escape analysis allows objects to be kept on the heap, stack, or in registers. I'd say this is an advantage rather than criticim, much like a C/C++ compiler that does automatic register allocation is an advantage.
GC is inefficient. The good old myth... With escape analysis (if/when you have that), register allocation, and new+GC being up to ten times faster than the typical malloc()+free() this statement would need some verifiable sources. Or wording that mentions the criticism might be more superstition than fact. Weregerbil 18:31, 29 May 2006 (UTC)

From our escape anlysis article "Notably Java Standard Edition 7 ("Dolphin") is expected to implement escape analysis". Two versions into the future != current situation. Plugwash 18:38, 29 May 2006 (UTC)

Yeah, the Sun JDK doesn't have EA. (Or: it does! Mustang, currently in Beta 1, has it. AFAIK it just doesn't have any optimizations based on it :-) I recall seeing conference slides that discussed the implementation of EA in another vendor's Java runtime. Can't recall the vendor and quick googling doesn't find it either. And the EA article: it has ever had only one contributor (and he is not an expert on the subject) so take it with a grain of salt; it hasn't gone through any peer review.

The wording in the stack vs heap criticism could use tuning: the language does not mandate objects on heap. The currently shipping version of the currently most popular implementation happens to work that way. Weregerbil 18:52, 29 May 2006 (UTC)

Maybe memory leaks was a bad example. I just hear a lot of complaints from people about what people who only study Java don't know. See Joel on Software's The Perils of JavaSchools Chiok 19:06, 29 May 2006 (UTC)

The language requires that all objects allocated have the semantics of a garbage collected heap allocation. The jit compiler may in some cases be able to determine that this isn't really required but at this time its anyones guess as to how effectively this determination can be made.

Sun has done a sterling job of improving the performance of a language that was never designed for good performance but it has come at the cost of complexity and predictability (the performance of java code can be significantly effected by what other code is loaded). Plugwash 19:11, 29 May 2006 (UTC)