Differences between version 20 and predecessor to the previous major change of Java.
Other diffs: Previous 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 15 | Last edited on Wednesday, November 19, 2003 6:46:16 pm | by AristotlePagaltzis | Revert |
@@ -1,42 +1,47 @@
-[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-independant 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.
-[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.
+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].
[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.
+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.
-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 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?)
-
-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].
+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++]
-
-''Lots to be refactored here. AddToMe.''
----
CategoryProgrammingLanguages, CategoryImperativeProgrammingLanguages, CategoryObjectOrientedProgrammingLanguages, CategoryMachineOrientedProgrammingLanguages
