Talk:Java (programming language)/Archive 3

Archive 1

Archive 2

Archive 3

Archive 4

Archive 5

→

Archive 7

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)

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)

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)

C++?

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

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)

Java platform developed by Bridge Systems?

See http://c2.com/cgi/wiki?JavaHistory, which claims that the Java platform (not the language) was developed by Tom Stambaugh and his company Bridge Systems. —Preceding unsigned comment added by [[User:{{{2}}}|{{{2}}}]] ([[User talk:{{{2}}}|talk]] • [[Special:Contributions/{{{2}}}|contribs]]) 13:04, 16 December 2005 213.134.124.81

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

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. —Preceding unsigned comment added by 210.0.99.105 (talk • contribs) 01:55, 22 December 2005

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)

Inventors

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.

— Patrick Naughton

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

Vandalism

Reverted to deal with vandalism. DCrazy 22:01, 17 December 2005 (UTC)

TOCleft

Added TOCleft (article is hard to read otherwise on <= 1024x768). —Preceding unsigned comment added by 144.126.130.139 (talk • contribs) 08:41, 18 December 2005

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 71.198.170.40 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 ^{talk•contrib} 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 ^{talk•contrib} 05:24, 19 January 2006 (UTC)

I'll try to split off the syntax section before it gets too ridiculously long :-) --Flash 23:51, 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 ^{talk•contrib} 21:33, 22 January 2006 (UTC)

I'm pretty comfortable with leaving only the summary and the Hello World example behind. --Flash 00:03, 23 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 19 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 ^{talk•contrib} 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 ^{talk•contrib} 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 misleading...it seems to say that Java's regex is lacking, having early, minor support at best. That has not been my experience.

- Mark —Preceding unsigned comment added by 204.126.80.110 (talk • contribs) 20:31, 27 February 2006