Talk:Java (programming language)/Archive 2
 | This is an archive of past discussions. 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 | Archive 4 | Archive 5 |
Audience and Context.
Hello,
I am new to this site and have a strong professional interest in the Java Programming Language.
I have two concerns that would fall within the area of strong criticisms regarding the text to date.
Firstly there is nothing wrong with the text per se, however, I have difficulty in determining who the audience this is being written to. Is it the technical Java programming developer community? or the world at large. Either of these audiences would find difficulty in reading this article. This is a particularly difficult question due to the fact that I could identify several distinct and disparate audiences, each requiring many different perspectives.
Secondly, I find that large chunks of the value of Java is missing. I am seing most of the individual trees, but no description of the forest. The conceptual paradigms that Java introduces are significant and a large part of why the language has travelled as far so fast. These are also the reasons that it introduces the opinions and conflicts in the marketplace.
I see the base of what has been written as real value in dealing with the complexity of Java and communicating that to those who want or need to know. As Java continues to expand and become more and more of a day to day "thing" in all peoples lives, this opportunity to translate much of this complexity is of vital interest.
thanks
—Preceding unsigned comment added by Pdc&gsc (talk • contribs) 00:10, 3 October 2004
Split this up, JRE & JDK seperated
I think the Java Runtime Environment section should have its own article, same as the developer's Kit. What we could do is have a blurb on it in this article and have a See also: Java runtime environment there.
The reason why I suggest we split it up is because the java programming language, the java runtime environment, and the java developer's kit are three different things/ideas. That may make things clearer. --ShaunMacPherson 05:11, 5 Nov 2004 (UTC)
- I have made a start on this. [[User:Smyth|– Smyth]] 13:12, 13 Nov 2004 (UTC)
JVM and JRE
What is the differences between them ??. :-? —Preceding unsigned comment added by 84.121.3.242 (talk • contribs) 12:41, 8 November 2004
- JVM is a generic term, see Java virtual machine. JRE specifically refers to Sun's product, comprising their own JVM implementation and their own Java API implementation. [[User:Smyth|– Smyth]] 13:13, 13 Nov 2004 (UTC)
- JDK includes JRE. JRE includes JVM. JDK is available for download by developers. JRE is available for download by clients. Anwar saadat 03:00, 25 March 2006 (UTC)
- Close, Anwar saadat, but not quite correct. JDK ("Java 2 System Development Kit") is indeed a Sun Microsystems product targeted at programmers. It contains all sorts of tools for creating and building Java programs. JRE ("Java Runtime Environment"), while sounding like a more generic term, is also a Sun product, this time targeted at consumers of Java programs. It contains just the components necessary to run a normal Java program, and comes bundled in with the JDK ('cause developers need it too). But JVM ("Java Virtual Machine") is a very generic term. Sun's current JVM product, is called "Java HotSpot Virtual Machine", and is one such JVM and is embedded within the JRE (and therefore within the JDK). In fact, it's Sun's second attempt at a JVM - their first attempt was responsible for much of the "Java runs slowly" folklore in the early days. But there are other JVMs, some of which are better at running Java programs than Sun's HotSpot JVM (for example, IBM's JVM). And even Sun currently provides two differently-tuned JVMs, accessible from the "java" command via the "-server" and "-client" options. RossPatterson 03:42, 25 March 2006 (UTC)
Responses to the Java Language is outdated
The complaints about collections and casting etc in this section are out of date with the generics & auto-unboxing in v1.5 (which are discussed in following section) and I can't see any other point in that section but have a feeling that if I removed it, it would be replaced. Anyone care to fix it? —Preceding unsigned comment added by Jaybee (talk • contribs) 18:30, 12 November 2004
- Not neccesarily everyone uses Java 1.5 and thus the prblems still remain. Of couse, adding some mention that they were fixed with the release of 1.5 would be nice. -- Taku 18:57, Nov 12, 2004 (UTC)
- I've added the 5.0 versions. Although the Java IO section needs some similar treatment. Why focus on IO over the whole of Java is strange to me --Calvin 21:33, 16 Nov 2004 (UTC)
- Because IO is kinda vital to any serious server application? In particular before nio it was impossible to code a single threaded event driven server app (which is by far the best method for certain types of server) in java. Plugwash 17:51, 22 April 2006 (UTC)
Gosling??
I think the first paragraph should either omit the mention of Gosling, or explain who he is. The way it is written now, the reader has no idea who Gosling is until he or she continues farther down the article, which is confusing.
Here's the paragraph I'm referring to:
Java is an object-oriented programming language developed primarily by Sun Microsystems. Gosling and friends initially designed Java, which was called Oak at first (in honour of the trees outside Gosling's office), to replace C++, although the feature set better resembles that of Objective C.
—Preceding unsigned comment added by 129.97.152.114 (talk • contribs) 03:47, 23 November 2004
Pronunciation, Round 2
It's been "suggested" once again that the opening sentence of the history section should bear a pronunciation note indicating that Java is "usually pronounced with a short 'a' as in 'hat.'" As a professional Java programmer, I find this very hard to swallow; although many Canadians may pronounce it this way, it's only notable if this differs from the usual pronunciation (as in coffee). Anyone? ADH (t&m) 07:15, Jan 14, 2005 (UTC)
- I always say jah-vah. It's best we don't mention an "official" pronunciation at all. Dysprosia 07:19, 14 Jan 2005 (UTC)
- While probably not common amongst English speakers, I've heard Java pronounced as /java/ (in the Netherlands and Poland) (ie. English spelling 'yava'), matching local pronounciation of the coffee-bean. How consistant is this with the Javanese pronounciation? And how common is this pronounciation in europe? (ie, in German) —Preceding unsigned comment added by 80.178.219.176 (talk • contribs) 03:03, 1 February 2005
- It's probably needless to say, but in japan "java" becomes jyaba. -- Taku 17:54, Apr 2, 2005 (UTC)
A few more topics to add
Any volunteer for : - the Java Security Model ? - the Java Community Process ?
—Preceding unsigned comment added by 70.114.249.148 (talk • contribs) 05:12, 27 February 2005
I have just landed on the orphaned Strictfp article via a random link. I've wikified it and added it to category:Java programming language, but it could do with a link from somewhere. The trouble is I don't know where would be apropriate - or even if it is apropriate to keep it as an article of its own, or should be merged somewhere (but I don't know where would be apropriate). I thought about VfDing it, but I don't know enough about the subject to know if it is really worth keeping or not. I am putting this here becuase as a featured article this talk page is probably going to be on the watchlists of people who know what they are talking about! Thryduulf 15:14, 2 Apr 2005 (UTC)
- I've added a link to strictfp, which is mentioned in Java programming language#Version history. --MarkSweep 18:20, 2 Apr 2005 (UTC)
Edits by 67.118.123.235
Yet another mass delete, please discuss large changes here first and get the version correct please :*) --Calvin 22:17, 19 Apr 2005 (UTC)
Request for references
Hi, I am working to encourage implementation of the goals of the Wikipedia:Verifiability policy. Part of that is to make sure articles cite their sources. This is particularly important for featured articles, since they are a prominent part of Wikipedia. The Fact and Reference Check Project has more information. Thank you, and please leave me a message when a few references have been added to the article. - Taxman 19:35, Apr 22, 2005 (UTC)
"Sun Control" comments in API
The comments that have been added to the article concerning Sun control are POV and reflect a shallow understanding of the JCP and of the historic situation. While Sun is the spec lead on many JSRs in the area of J2SE platform features, that's not the case with J2ME platform features and is not a necessary feature of the JCP - expert group leadership is now diverse. Additionally, ownership of specs is always shared by the expert group lead for practical reasons, so implications that that's bad in Sun's case are demonstrably POV. If it's essential that this topic is covered, a full explanation will be needed, and I suggest the appropriate place for it is in the JCP topic. As to controversy - well, it's controversial among those who don't understand it! --Webmink 01:49, 25 Apr 2005 (UTC)
"Object Oriented
The article on Java generally makes a very good run at explaining complicated issues clearly and succinctly.
One exception is the section entitled Object Oriented. Here the author has mistakenly adopted a too high level of abstraction, so that anyone reading the text and lacking familiarity with Object Orientation would be confused and put off.
The remedy is to begin by relying on concrete example(s), application(s) and familiar anologie(s); only later hinting at higher levels of abstraction.
I am making corrections along these lines.
Philopedia 00:22, 17 Jun 2005 (UTC)
Non-free IDEs under: 'Related free software' is ambiguous!
This was under 'Related free software', as a quick fix i moved it here. I hope somebody who is more erudite in this area than i am will reuse it!
- Non-free IDEs
—Preceding unsigned comment added by 212.114.231.48 (talk • contribs) 14:48, 13 July 2005
- What is the point of the "Related free software" section, anyway? ISTM it is just bloat that does not add much to the article; at best, it should be moved to a separate article. Objections to me just removing it? Neilc 05:18, 14 July 2005 (UTC)
Advanced Placement Program exam
- The College Board currently administers an Advanced Placement exam in Computer Science, which tests knowledge in Java and object oriented programming. The exam also tests knowledge on the Marine Biology Simulation Case Study a program written in Java. The exam switched from C++ to Java as its featured programming language in the 2003-2004 school year.
This seems to have been added and removed a few times over the history of this article. I personally don't think it's relevant (many institutions run Java exams, this one isn't particularly notable), but if it does have to be in the article it certainly doesn't belong in the 'Java meets the Internet' section. I noticed that it did originally have its own heading, but that seems to have been lost along the way. I've removed it for now, if someone feels strongly that it belongs in the article please can we try to decide on an appropriate section for it? --Batneil 16:39, 24 July 2005 (UTC)
Naming
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 [1]. violet/riga (t) 12:36, 28 July 2005 (UTC)
- Most articles on programming languages follow the format "X programming language". Dysprosia 12:40, 28 July 2005 (UTC)
- You're right, many do. I think it would be better for them all to have it as "X (programming language)" but that's probably too much work. Best to leave it here then, I guess, as it needs to be consistent. violet/riga (t) 12:43, 28 July 2005 (UTC)
public, abstract, static, and final
I've pulled the following paragraph from the section on interfaces and classes (sorry I forgot to sign in before making the change):
Methods defined by an interface are implicitly public and abstract. Fields defined by an interface are implicitly public, static, and final.
Without explanations of the meanings of public, abstract, static, and final, this paragraph adds little value. But, adding the explanations would be adding detail, and this paragraph seems to already be too much detail. Mark Harrison 06:28, 11 August 2005 (UTC)
Code examples, specically the new for loop
It is unlikely that a user will relate to widgets and boxes. This should be changed to for(Element e: list)...
The name Fred for a class that implements Deletable is also bad. This should be changed to something like Section, Something that one would actually delete. You would not delete a Fred.
Other bad examples include the deleteAll method. It should use a List instead of an array and should use a for each loop.
—Preceding unsigned comment added by 207.58.192.123 (talk • contribs) 20:36, 22 August 2005
TOCleft
This article is a perfect candidate for {{TOCleft}}. I find massive amounts of whitespace very wasteful.
Compare, if you will:
Without TOCleft: Java-without_TOCleft.png
With TOCleft: Java-with_TOCleft.png
What does everyone think? ¦ Reisio 00:29, 2005 August 24 (UTC)
- Go ahead --Rogerd 03:12, August 24, 2005 (UTC)
Java has public properties
I'd like to discuss someone's contention that Java doesn't have public properties and that it requires accessors. In Java, it is possible to declare all your properties public and never require a get/set to manipulate them if you don't want. Accessors are just a convention, not a language requirement. This convention is completely optional and can be observed in any language. If I've misunderstood the objection, please correct me, but these basic facts need to be clear. The Hokkaido Crow 20:31, 26 August 2005 (UTC)
- I don't think that is what the previous poster was refering to. In java, you cannot define a 'property' in the usual sence without using an instance method, whereas languages like C# have build in support for properties. Your answer only works if you want a read/write property, but fails for anything else.
- For contrast, in C# we can write:
//...
public string ReadOnlyProperty
{
get
{
return "a string";
}
}
public string WriteOnlyProperty
{
set
{
someString = value;
}
}
public string ReadWriteProperty
{
get
{
return someString;
}
set
{
someString = value;
}
}
//....
- which provides us with syntax like:
string s = o.ReadOnly; // o.ReadOnly = "something" will fail o.WriteOnly = "some string"; // string s = o.WriteOnly will fail string s = o.ReadWrite; // Reading ok o.ReadWrite = "a new string"; // Writing ok
- I'm not sure if Java 1.5 adds anything like this to the Java language. It doesn't seem strictly needed, but is very useful, though I occasionally wish I could have a public getter and a private/protected setter. :( OracleofTroy 01:34, 3 September 2005 (UTC)
- Come again? First, the example you've shown above appears to be particular to C#, and maybe even unique to C#. I don't think the C# definition of "properties" could really be called "the usual sense". Second, one can easily have a public getter and a private/protected setter in Java. Here's how it works (trivial untested code follows):
public class Demo
{
// Private variables can only be accessed by methods
private static String readOnlyStuff = "Please protect me";
// Using this method, anyone can read it
public String readStuff() {
return readOnlyStuff;
}
// But only this class can write to it.
private void writeStuff(String s) {
readOnlyStuff = s;
}
}
- yielding a syntax like:
Demo d = new Demo();
String stuff = d.readStuff(); // no problem
d.writeStuff("Ha ha, I overwrote you"); // this won't even compile due to security violation
- The C# approach is interesting and appears to let you have security constraints without forcing clients to call accessors. But don't be fooled, the accessors are still there, and powered by naming convention voodoo. For the minor convenience of letting clients avoid calling accessors, you gain the inconvenience of having double the accessors and introducing wonky naming conventions. Ewwww.
- I don't think it's appropriate to take a unique feature of C# and call it a criticism of Java, especially when Java can accomplish the same intention using its own feature set. Now if a majority other languages had this specific feature, or the language lacked any facility for accomplishing this intent, then its absence could be legitimate cause for criticism. The Hokkaido Crow 21:43, 6 September 2005 (UTC)
- Delphi and freepascal also have properties which look like fields but actually cause method calls. C++ doesn't have them natively but i've heared there are ways to make use of operator overloading to add them. Once your used to using properties moving to a language where you have to manuall call getters and setters all the time gets to be a real pita. Plugwash 23:00, 22 April 2006 (UTC)
verbosity and typing
A recent edit to this article claimed that "Any strongly typed language will have more type declarations" (presumably, when compared to a weakly-typed language). This is wrong:
- strongly-typed languages don't need explicit type annotations at all, according to most definitions of strong typing. Perhaps the author meant statically-typed.
- statically-typed languages do not necessarily require explicit type annotations, either: the compiler just needs to be able to infer type information at compile-time. ML and Haskell are two examples of statically-typed languages in which type declarations are uncommon (most types are automatically inferred by the compiler).
IMHO there is more to the "Java is needlessly verbose" claim that just the cruft that results from type declarations, anyway.
Neilc 20:35, 30 August 2005 (UTC)
- I think we're in agreement about what I see as the main issue... that type declarations aren't a major contributor to Java verbosity. I have no problem if someone wants to talk about Java's verbosity or any other perceived flaw, I just feel like we should accurately reflect what is unique to Java as opposed to what is a paradigm that someone would find problematic in any language. For example, see the previous objection to getters and setters, and the objection that Java isn't a procedural programming language. The Hokkaido Crow 21:26, 30 August 2005 (UTC)
Properties
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)