Differences between version 20 and previous revision of Java.
Other diffs: Previous Major Revision, Previous Author, or view the Annotated Edit History
Newer page: | version 20 | Last edited on Saturday, March 19, 2005 12:12:33 pm | by AristotlePagaltzis | Revert |
Older page: | version 19 | Last edited on Monday, July 5, 2004 8:29:36 pm | by CraigBox | Revert |
@@ -1,10 +1,18 @@
-[Java] is a cross-platform ProgrammingLanguage created and controlled by [Sun]
.
+''Welcome to the huge sprawling mess that is our [Java] page.''
+
+
[Java] is a cross-platform ProgrammingLanguage created and controlled by SunMicrosystems
.
[Java] shares simlar syntax to [C]/[C++], but differs in some fairly major ways:
-;
GarbageCollection : The programmer need not worry about memory leaks, at the expense of having a garbage collector
.
-;
Compiled to ByteCode : Binaries are machine-independent ByteCode, the intention being "write once, run anywhere". This usually works for non-windowing, non-audio applications. It means [Java] binaries need a special run time environment to run.
-;
Huge standard [API] : It is enormous and does ''lots'' of stuff, in a platform independent way.
+
+
GarbageCollection:
+
The programmer need not worry about memory leaks, at the expense (if it is one at all)
of requiring GarbageCollection
.
+Compiled to ByteCode:
+
Binaries are machine-independent ByteCode, the intention being "write once, run anywhere".
+
This usually works for non-windowing, non-audio applications.
+
It means [Java] binaries need a special run time environment to run.
+Huge standard [API]:
+
It is enormous and does ''lots'' of stuff, in a platform independent way.
[Java] really shines in a couple of areas, particularly documentation: the documentation of the [Java] [API] is excellent. It surpasses the masses of documentation found in Microsoft's [MSDN] in quality and beats documentation I have seen for any OpenSource project to date. It's comparable to [UNIX] man pages, but much more consistent and much better interlinked.
[Java] makes networking easy as pie. Networking between different platforms wasn't always too easy before [Java], but it is very simple with [Java].
@@ -12,32 +20,28 @@
[Java] even makes multi-threading easy. And platform independant (the programming is platform independant, but the running is platform dependant, unfortunately).
[Java] is an example of good object oriented design (generally). Almost all of [Java]'s internal classes are very well defined and all follow a nice naming convention.
-[Java] applets allow [Java] programs to be written and run in [WebBrowser]s. Unfortunately, after [Java] 1.1, Microsoft didn't quite agree with [Sun]
and stopped updating the version of [Java] that comes with InternetExplorer, the most common WebBrowser. Because of this, most applets you see on the internet today are limited to a very old version of [Java] and don't make use of all the new features in [Java] today (version 1.4.1 at the time of writing).
+[Java] applets allow [Java] programs to be written and run in [WebBrowser]s. Unfortunately, after [Java] 1.1, Microsoft didn't quite agree with SunMicrosystems
and stopped updating the version of [Java] that comes with InternetExplorer, the most common WebBrowser. Because of this, most applets you see on the internet today are limited to a very old version of [Java] and don't make use of all the new features in [Java] today (version 1.4.1 at the time of writing).
[Java]Beans allow dynamic introspection of software components and streaming of state-full objects across the network without full knowledge.
!! Issues
But Java, like any ProgrammingLanguage, has cons. First, Java's Run-time Environment (JRE) is a big download and is needed for any user wishing to run a Java program. This JRE also incurs quite a large memory penalty, even running a simple application can take quite a large amount of memory. Also, despite the promise of "write-once, run anywhere", changes to the language [API] and differences in JRE versions results in problems for developers and users. See http://developers.slashdot.org/comments.pl?sid=94959&cid=8142663.
-
Java has a GraphicalUserInterface library; in fact it has two. Swing, a high level and well-designed API which is built upon AWT (Abstract Window Toolkit). These work well enough, but don't take the native LookAndFeel of a system (though they can attempt to emulate it), and can look quite ugly. They can also be quite unresponsive.
-Java isn't fast. Now, I am not attempting to start a FlameWar. Java can actually perform very well, as fast as C code in many cases. However, especially for [GUI]'s, Java doesn't come out too well. Even on a 650MHz computer, many Java interfaces programmed with the standard Java windowing toolkits will be slow and unresponsive. Case in point: Sun's own Forte. This is now called [Sun][[tm]
One Studio 4, but is a good case of an unresponsive system written in Java that seems to otherwise be very well designed and implemented.
+Java isn't fast. Now, I am not attempting to start a FlameWar. Java can actually perform very well, as fast as C code in many cases. However, especially for [GUI]'s, Java doesn't come out too well. Even on a 650MHz computer, many Java interfaces programmed with the standard Java windowing toolkits will be slow and unresponsive. Case in point: Sun's own Forte. This is now called SunMicrosystems
One Studio 4, but is a good case of an unresponsive system written in Java that seems to otherwise be very well designed and implemented.
-[Java] also has limitations due to it's [
ClassFile]
format
+[Java] also has limitations due to its
ClassFile format.
-
-
The popular JREs start a new virtual machine for each java
program, rather than sharing one amongst all programs. This combined with the large memory overhead can make it impractical on machines more than a few years old. (AddToMe - is this still true these days?)
+The popular JREs start a new virtual machine for each [Java]
program, rather than sharing one amongst all programs. This combined with the large memory overhead can make it impractical on machines more than a few years old. (AddToMe - is this still true these days?)
Sun's JRE (run-time environment) is not [Free]-software (although it is [free] as in $$, and the source code is available). The "other" widely used JRE for [Linux] distributions, blackdown, is based on Sun's code, so therefore isn't Free either. Neither [Debian] or RedHat or many of the other distributions will officially distribute non-Free software.
The lack of a Free JRE (along with JRE size and speed issues) is probably one of the biggest obstacles to wide-spread adoption of Java on Linux. However, most of the issues mentioned above are implementation issues so could in theory be overcome. For example, the [GCC] project is part-way through a java compiler that would (of course) be licensed under the [GPL]. http://java.debian.net/index.php/MovingJavaToMain shows the progress on getting Free java programs (and runtimes) into Debian's main stable distribution.
See JavaNotes, [JavaAndC++]
-
-''InNeedOfRefactor''
----
CategoryProgrammingLanguages, CategoryImperativeProgrammingLanguages, CategoryObjectOrientedProgrammingLanguages, CategoryMachineOrientedProgrammingLanguages