Slashdot Mirror
The JFC Swing Tutorial
I was just finishing up my first year of university when Java burst onto the scene. As those of us who were around then can remember, the hype was intense. Actually, that would be an understatement. You would have thought Java was going to save the world and make your morning coffee all at once. Fortunately, things settled down almost as fast as they began, and Java started on its long road to maturity. In many ways, this book is the culmination of three years of Java maturation. The AWT, Java's original GUI library, has been replaced by a completely new one, Swing, with the release of Java 1.2/2.0. It promises to have more features, be more stable, and generally live up to the platform-specific libraries against which it competes. In many ways, Swing is the hope for Java on the desktop. Of course, you have to figure out all those APIs first....
What's the book about?The JFC Swing Tutorial is the Sun-imprinted official word on how to code for the Swing API (note that this book is also available for free from Sun's web site [see the link in the title above]). Of it's 950 pages, literally the last 300 are source code to all of the examples in the text, while the first 600 delve into every aspect of Swing. As with most tutorials, things start off slow, with a "hello, world!" equivalent, but the difficulty ramps up quickly. There is a (relatively) short section giving an introduction to layouts, painting, and other GUI basics before the real meat of the book begins.
Chapters 12-17 are the heart of the tutorial, and take the reader through every part of the Swing API. This is broken up into top-level containers (frames, dialogs, applets), intermediate-level containers (panels, panes, tool bars), and atomic components (all the buttons, choosers, and menus). There are tables at the end of each section summarizing the various methods, along with their purposes. There are also example summaries, listing where to find the examples that demonstrate the various concepts presented. The section is quite thorough, with plenty of code interspersed through the text.
The final part delves into the other parts of Swing, including layouts, actions, borders, icons, look and feel, and chapters on event listeners, graphics, and converting from the AWT. These chapters continue the structure begun in the middle sections, with many code examples and handy summary tables.
What's Good?Simply put, if you want to know how to do something in Swing, it's probably covered in this book to one extent or another. In fact, you're likely to find that your code has already been written for you to some extent, given the copious examples provided. Even if you cannot find exactly what you want, you can likely piece it together from what is provided. It's also nice being the official tutorial, as you can trust that the authors had decent references whenever they had a question or two. This is the official way to do Swing.
What's Bad?Well, in short, more than I would like. Personally, I'm not well-grounded in doing GUIs. Not to say that I've never done them before, but I've had my struggles in the past. That's one reason I wanted to review this book, as I was hoping to strengthen my skills along the way. Unfortunately, I don't feel like that has happened. Don't misread the title. This isn't a GUI tutorial in any sense of the word; it's a Swing tutorial. The complexity of the text ramps up quite quickly after "hello, world," and if you aren't ready, you'll be lost in the dust. To be honest, I found this to be more of a reference book than a tutorial, at least to the extent that I wouldn't read this book cover-to-cover, but would pull it off the shelf any time I had a Swing question. The examples are thorough and there are plenty of them, but the style and layout do not make for an easy read-through.
So What's In It For Me?Firstly, you have an amazing advantage of being able to try this book out for free. If you're interested, check out the URL and read through a few sections. Make your own review. You can buy it or ditch it at your leisure. Second, don't use this book as a general GUI tutorial. That's not what it is, and trying to use it as such will only frustrate you. If, however, you know GUIs, and you want to learn about all that Swing has to offer, this is an excellent book. You get an entire CD-ROM full of Java code for your use, plus the official Swing reference. Depending on your needs, this book will either be very helpful, or a very heavy paperweight.
Purchase this book at fatbrain.
- Table of Contents
- Preface
- Before You Start
- Getting Started with Swing
- About the JFC and Swing
- Compiling and Running Swing Programs
- Running Swing Applets
- A Quick Tour of a Swing Application's Code
- Features and Concepts
- Components and Containment Hierarchies
- Layout Management
- Event Handling
- Painting
- Threads and Swing
- More Swing Features and Concepts
- The Anatomy of a Swing-Based Program
- Using Swing Components
- A Visual Index to Swing Components
- The JComponent Class
- Using Top-Level Containers
- Using Intermediate Swing Containers
- Using Atomic Components
- Solving Common Component Problems
- Laying Out Components
- Using Layout Managers
- Creating a Custom Layout Manager
- Doing Without a Layout Manager
- Solving Common Layout Problems
- Using Other Swing Features
- Writing Event Listeners
- Some Simple Event-Handling Examples
- General Rules for Writing Event Listeners
- Listeners Supported by Swing Components
- Implementing Listeners for Commonly Handled Events
- Summary of Listener API
- Solving Common Event-Handling Problems
- Working with Graphics
- Overview of Custom Painting
- Using Graphics Primitives
- Using Images
- Performing Animation
- Solving Common Graphics Problems
- Converting to Swing
- Why to Convert
- How to Convert
- Conversion Resources
- Solving Common Conversion Problems
- Appendices
- Code Examples
- Reference
- Index
Because I like to read on the toilet, and my wife won't let me put a machine in there!
Sure about that?
Wow, I'm sorry too. Sorry that your post is mostly just rambling incoherent babble and even sorrier that I read it. But most of all I'm sorry that I wasted a brief portion of my life replying to it.
Tried Swing under 1.3. No help.
Ehhe I see I'm not the only one then :). The toilet is THE knowledge room for me. I must admit I sometimes bring my laptop with me but I prefer paper. And If the book is not good, guess what I feel like doing with it ;)
The problem is that the excess object creation is caused in Swing's classes themselves - well beyond the reach of my program. Perhaps the Sun dudes should read the Javaworld excess object creation article.
Java's been out for 5 years now. Do we have to wait another 5 years for decent performance? I don't think the customers of my Java applications care about these excuses - they are only concerned with speed - and don't give a damn about the language it is implemented in (all of them run Windows anyway).
How great would it be to write applets which take advantage of the gui tools that swing provides without the need/headache of the browser-plugin? With jdk1.2 Sun has promised us less changes in java's core APIs so let's see Netscape catch up and give us a browser that support at least 1.1 already. Imagine developing web apps with powerful frontends including JTrees and JTables. It could change the way apps are written for the web.
I think you're a fool! What do you call Solaris?
I suppose you're some sort of pansy that would
rather use Windows NT 4.0 than a real operating
system like Solaris.
Maybe it's decaf
No one makes you use Java garbage collection. Just imagine that, with Java, that you have a language without garbage collection and strict typing, keep your own pool of freed objects, and do your own garbage collection.
Isnt that just the demo of the JIT for Linux??
I've been looking for the "Pure Java" Jbuilder beta, but cannot find it...
Oh I'm sorry. You must be on the wrong website. You're looking for WrestleZone.com, where they post things like Wrestlers dying in a car crash when they're perfectly HEALTHY. In other words, this ISN'T the place for that shit.
Have you tried 1.3 beta? Much, much faster.
Swing is all but unusable at this time due to its poor performance - I've reverted back to AWT for my java applications and applets.
I've been developing Java in VI on an AIX platform using IBM's Common Desktop Environment, which is itself done in Java. If anyone is familiar with this, it is very slick and solid. My apps seem to fall short of this, and Swing seems like the only answer. The AWT doesn't run as fast as I would like, if I weight these down with Swing what will happen. Maybe I need to use JNI and a bunch of C++ code??? Will the next version of Swing leave 50% of our methods "depricated"??? Anyone who wants to flame me, comment directly or let me know where I can take part in a Java community, my email: dare@netrox.net. I've also noticed that every Java magazine or Tech rep I get on the phone is affraid of command line programming and their knowledge of Java is limited to Windows! Let us all bow our heads for a moment of pitty for those poor un-enlightened bastards...
Slow and bloated. Sun should stick to hardware. I haven't seen a good piece of software from Sun since, well... hmm... dang, can't think of anything.
Programmers who use the Swing libraries are limited only by their imagination. Of course if your idea of GUI design is aligning a bunch of text fields, then that limitation is too severe and you should stick to VB.
Don't forget to check out the book's website for all their "errata" -- we used it in a course (a Data Structures & Algorithms course, oddly, though the assignments didn't have to be done in Java) and the prof would almost always start off the class with a little section "These are the errors in the textbook we're going to encounter today". Some of them were kinda nasty too, if you weren't aware of them; stuff like coding errors in their pseudocode for algorithms wasn't uncommon. Other than that, it's not bad...I'd get into a more detailed discussion about it, but this is the wrong book review :)
Yeah, some do and I will tell you ... I will not do it again. There are definately better ways to do this.
Can you hear that deep, sucking sound of the next crap Sun has thrown up over the world?
It's called rabbit-dung,jinibean-enabled bullshit builder. And believe me, they will do everything to shove it down your throat!
It is a Sun book, and there are numerous instances throughout its two massive volumes that make quite critical mention of java and/or some certain component thereof. I should point out that "Core Java" is considered the "definitive reference and tutorial" for the Java language.
So get your head out of your anti-capitalist, GPL'ed ass and think.
Thank you.
Sun wanted to provide a well-designed, componentized GUI toolkit and that is exactly what Swing is. Every Swing component is a JavaBean as well, the event handling is more elegant than any GUI toolkit I have ever seen (yes, it typically involves a deep call stack, though I've never seen it go beyond 8 or 9 levels), and the available functionality is astounding.
I was able to throw together a fairly largescale app with ease, customize portions of it, perform cute (and occasionally useful) buffering tricks, etc. It is just barely possible that Qt could be as complete and easy to use as Swing, but I doubt it. Nothing else even comes close.
Now if I could just write a GTK theme to Swing Pluggable Look and Feel converter...
Actually, JDK 1.3's version of the JFC is codenamed Kestrel and is supposed to have some significant changes. See this for more information.
>anti-capitalist, GPL'ed ass
I guess you didn't notice the huge IPOs on GPL software companies, then?
The biggest problems with Swing are:
Some appearant inconsistencies:
Any user interface which ignores those differences cannot called "cross platform" without redefining the word (which you would more expect from Microsoft).
About the speed: NeXTstep and MacOS X Server provide an at least as powerful framework as Swing, but is much faster and doesn't have those inconsistencies.
The explanation for this is quite simple: the apple implementation of Java sucks.
SWING for Mac is created by Sun, it has *nothing* to do with MrJ. SWING guidelines especially state that the menubar on mac systems should use the inferior implementation (menu bar attached to window, *belch*).
I'm a bit confused about this statement. I hope you don't mean that its impossible to recreate the same GUI on different platforms because that is exactly what swing does.
This is just the problem: Mac applications have to behave to the Apple UI guidelines; Windows applications have to behave to MS UI guidelines (even though Office and IE give a bad example) and Motif apps have to behave to the CUA guidelines.
Later on you mention that it is impossible to entirely incorporate the look and feel of one platform without violating the look and feel on other platforms. You're right, so what? The goal of pluggable look and feel is not to copy into every detail the look and feel of a specific platform but to be able to customize the applications look and feel without touching the application. A nice application of this is to immitate the look and feel of different platforms to provide users with a familiar looking GUI. A more interesting advantage is that it enables application developers to give a unique look to their applications.
Isn't this just a *disadvantage*? I want my applications to look consistent with the rest of my system, just like many others. Otherwise, you can call Windows 3.1 also cross-platform, as you can use WINE/WABI to run them under UNIX based systems and VirtualPC/SoftWindows to run them under Mac. They also are horribly out of sync with the rest of the system.
It's silly to claim that and nobody is doing that.
NeXTstep, and their implementations on Mac and Windows (WebObjects) exactly does that.
"NeXTstep and MacOS X Server provide an at least as powerful framework as Swing, but is much faster and doesn't have those inconsistencies."
Irrelevant because you need apple hardware to run it. Nice design but not crossplatform (in both our interpretations of this term).
I assume you don't know that in fact there exists an implementation that runs above Windows (called WebObjects). Apps then have exactly the look and feel of Windows applications, cause there the interface is clearly separated from the code, as opposed to SWING or the bunch of X based toolkits. And BTW, NeXTstep runs on Intel boxes.
Sorry that the link was filtered out. Here's what I meant: JFC Tutorial
About four months ago, I was looking for a good introduction to Swing. The Campione/Wollrath book is OK, but it seems like they just typeset the web tutorials which are already available on the java.sun.com website. Not all of the Sun Java books look like that: I have about five or six of the Sun Java series that are well-written and invaluable.
...
Since the content is mostly available online, I opted for the book "Pure JFC Swing" by Pantham. This book also has its faults: lots of coding examples, but not much instructional material. Kind of like buying a book of recipes when you really want to know the basics of cooking. Sure, you can try different recipes, but there is little explanation of the fundamentals.
So, what looks like the best book so far is the O'Reilly book "Java Swing" by Eckstein, Loy, and Wood. Maybe I go over to Stacey's in San Francisco and pick it up today
I don't have the Swing Book, but I have 2 editions of the main Java Tutorial book. I have used the on-line tutorial extensively, but sometimes like to be able to study material off-line. Book type is also a lot easier to read in long stretches.
In the end, it's a matter of taste.
I agree that Swing is sometimes overdesigned (and under-implemented). But it is also the first viable cross-platform GUI framework that I have seen.
For an example of what can be done with Swing, see JeraWorks, a cross platform outliner I developed using Java and Swing. Peformance should be fine on any 150 MHz machine, especially with IBM's Java VM.
It used to be the "Java" coffee cup, but CmdrTaco and friends recieved threatening e-mail from Sun, so they replaced it with a not particularly well drawn coffee cup of their own months ago.
I can't believe this troll has been moderated up, to "Interesting" no less!
His argument is:
1) The world changes, so Java will become obsolete,
and
2) Java changes, so your code will become obsolete.
These two statements don't just apply to Java, but to all programming languages! Show me a programming language that does not have these qualities...
And the last two paragraphs are pure arrogance. "...you should check the content of your skull for contamination by animal defecation"? What an "Interesting" statement.
I purchased this book last week. Why? I find I can learn off of a website and get the jist, but when it comes to knowing something I have to read it from a book. I have an excellent computer setup, but I already spend hours a day sitting here coding and reading. When I want to learn something I jump to the couch behind my desk and start reading in 50 page chunks broken up by cups of tea.
I have a few ideas why I learn better this way too. For one, it is a lot easier to flip back 50 pages to look at a previous example than with a web page. Also, with my 15inch monitor and 40megs of ram, not having to jump around a website and wait for my swap to catch up is a bonus to my sanity.
And for the 'dead tree comment,' I would end up printing out and losing important sections repeatedly.
I would have to say that the Java API reference on the web is excellent, especially for finding which methods are inherented.
-- DrZaius - Minister of Sciences and Protector of the Faith
Well, as far as I can see, FLTK is C++ and not available for Java.
So it's not really an alternative if you want to program in Java, which IMHO is a nicer programming language.
As someone else has already said: creating a cross platform GUI framework is hard.
Sun's decision to go with a pure Java GUI in Swing is not based on "arrogance", but on their failure to find a way to extend the AWT (which used native components) and keep it cross platform. As to what approach is best: well, noone knows. Attempts have been made to extend the native widget approach or mix the two, but none has been very successful. A remote GUI, running in another app, or on another machine, is also an option, but increases the amount of code that must be maintained.
And yes, Swing looks nothing like a Mac, even when running on one. Deal with it. It looks nothing like Windows or Motif either.
http://java.sun.com/docs/books/tutorial/informatio n/download.html
There's lots of other tutorials there too...
Pardon me, but what does the icon for this topic mean?
Looks like a flowerpot to me... ?!
Didn't it use to be a cup of steaming hot coffe?
>Stick a break point in a callback and check out >the call stack - 20 deep, WTF were they >thinking. I have to protest this assumption of deep call stack -> bad implementation. By that logic, any code that uses recursive function calls is "bad", which is obviously untrue--recursion is an excellent way to define complex behavior via simple code.
I don't care if it's 90,000 hectares. That lake was not my doing.
When Java first popped up, I was one of the schmoe's who bought a few of the first round of books. I picked up a few things, but never felt like I had a good grasp of Java.
I took a few weeks to get to know the Swing tutorial (and the rest of the online tutorial) back in April. I've since downloaded the entire thing to my laptop, and couldn't be happier.
Of course, it isn't going to teach you Java. The only way to do that is to start writing code now. It doesn't matter which book you read -- if you don't apply the lessons, you won't remember anything. But, the tutorial is the perfect reference.
--Mid
I whole heartedly agree...maybe some of the yahoo's on /. who don't want to make Linux easy to use for everyday people should read this book. Then have a new look at all the flames when someone says installing Linux is hard, setting up PPP is hard etc, they may actually be believed in stead of ridiculed
Never by hatred has hatred been appeased, only by kindness - the Buddha
Most of the stuff that I see developed in for the
web, where swing is not used.
does anyone develop swing-based apps?
every customer we go to says web based HTML, no applets.
Maybe you'd like to test the preview of Borland's Linux version of JBuilder 3, it's available here.
BTW, the Blackdown folks also seem to make progress with their Linux 1.2.2 JDK, see the updated status page.
I just want to say that I'm pleased to see we're now linking to fatbrain and not Amazon.
Got HTML? Want LaTeX? Try html2latex
Female Prison Rape in NY
For learning Swing, I preferred "Core Java Foundation Classes" by Kim Topley, from Prentice Hall. It explains well the underlying design shared by all GUI elements. The Swing thread and synchronization finally make sense. It has the best single explanation of GridBagLayout that I've seen. No space is wasted merely listing javadoc information. Instead you learn how to make it all work together, in good style.
(Reality reasserts itself sooner or later.)
Java has no business running outside of a web browser. The only reason to put up with Java is the portability (which it doesn't deliver) and the reliability (which it doesn't deliver), and the garbage collection (which it delivers, but has a nasty habit of hanging your app up for a few seconds while it does a mark and sweep.)
If you want a serious OO development environment, use Python, Smalltalk, Objective-C, or Perl 5. If you want serious speed, use *any* language other than Java. If you want protability, stick to Perl and Python.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
I for one *hate* online books and manuals. I'll use them in a pinch, but I find it so much easier with a book on my desk that I can thumb through while coding. I curse everything I open a software package and there are no paper manuals.
:)
On the other hand, maybe what I need is a second computer with all of my documentation on it beside my main box
Dana
Ummm.... "run anywhere" means run on any hardware, not on any software.
-jacob
Yeah? So where are those tools then? Anything I've come across s*cks like a cheap whore.
> These two statements don't just apply to Java,
> but to all programming languages!
True, but the other programming languages did not promise "write once, run anywhere".
Nonsense! It's easy to write programs that use the appropriate look and feel for the system.
From the Java Tutorial:
"UIManager.getSystemLookAndFeelClassName()
Specifies the look and feel for the current platform. On Win32 platforms, this specifies the Windows Look & Feel. On Mac OS platforms, this specifies the Mac OS Look & Feel. On Sun platforms, it specifies the CDE/Motif Look & Feel."
jmp
here's a shortcut to javasoft's tutorial webpages: http://www.TheJavaTutorial.com
Um, you could embedd gui components into other gui components since vb3 and probably before.
Read 'Data Structures and Algorithms in Java' by Goodrich and Tamassia (http://www.cs.brown.edu/courses/cs016/book/), it gives a good explanation of basic OO principles and their implementation in Java (which is what Java is supposedly for). It's about the only useful coding textbook I've encountered.
Swing takes out the native components and replaces them with components with a look and feel that is standardized across platforms.
I don't think this is necessarily a good thing: Windows users want applications with a Windows look and feel, Mac users want applications with a Mac look and feel, etc. Using Swing makes the application look odd and out of place -- something users are very sensitive to.
But what I as a coder realy needs when it comes to making GUI-frontends: something like VisualBasic or Glade. Coding a GUI-frontend is pretty much typing in things and testing it if it is what U want.
On the other side, it's good to have a book to look at examples on spesific matters of coding.
Java's plenty fast if you're careful. I mean, no one's going to be writing Quake4 in it, but it does the job pretty well. Swing is a big exception, but I believe Swing's slowness results from one or two critical graphics bugs. Please correct me if I'm wrong.
... while we're on the topic of garbage collection, tho, if there's one thing I REALLY wish for every damn day it's the ability to turn the GC off and manage my own damn memory. The gc is the one huge area Java falls down on - at least when you're trying to write a large app.
Here's what tends to speed up java most:
1) Create less objects. Object creation is surprisingly expensive.
2) Don't use the String + operator anywhere you care about. Yikes, is that slow.
3) Examine what kind of algorithms the built-in Sun objects (Polygon, Vector, that sorta stuff) use - a lot of them are nice and clean, but less-than-optimal. If necessary, roll your own.
I find that most people who complian that Java is too slow haven't really worked at it too long. yes, you have to be more concious of performance than you would in C, but that's the price you pay for all the good java stuff like bounds checking and garbage collection
I have to say I have my misgivings about Swing and about Sun's approach to the GUI aspects of Java altogether.
Swing is *big*, and *complicated*. Looking into its guts give one a strong feeling of "hack upon hack". AWT was bad, complex where complexity wasn't needed in many cases, but Swing is an order of magnitude worse in that arena.
I often get the feeling, when I look through the Swing JavaDocs, that the architects at Sun are trying to solve every possible problem in one framework. I think they would be much better off to focus on getting what they do *right*, as they do it. If you try to solve every possible problem at once, you will inevitably end up doing everything at a lower quality level than if you just focused on the most important problems at hand, and once they are nailed down, go on to bigger things.
One could say that that's what they did with AWT - they got the low level done and then the moved on to a more complicated, complete GUI framework. I would argue that they never got AWT right; instead they threw up their hands and said, "oh well", and then proceeded to build a huge monsterous framework on top of the weak foundation that they had built with AWT.
Consider this: setting a breakpoint in just about any GUI method of your Java Swing program will show a call stack at least a dozen calls, often two dozen calls, deep. To me, that's a very pointed indication of a framework that is too complex for its own good.
The last thing that Java needs is more bloat, because Java is already very sensitive when it comes to getting performance - you can get good performance in Java (nearly comparable to traditional compiled languages) but ONLY if you optimize the hell out of your Java code and keep those call stacks small. It seems that Sun would rather try to solve every single possible GUI problem in one framework than concentrate on making Java small, tight, solid, and fast, which I believe is what they should be doing, because as every Java developer knows, you have to fight tooth and nail to get Java in the same ballpark performance-wise as other languages (but it can be done - Sun is just making it harder and harder by throwing stuff like Swing at us).
I never said that a deep call stack is necessarily a sign of poor implementation. It just USUALLY is. Recursion is an obvious exception (although with a bit more experience you'll realize that recursion does not deserve nearly as much emphasis as it receives in college). Swing isn't using recursion here anyway, it's purely indicative of bloat. Also, the deep call stack wasn't the only reason why I think Swing implementation is bad - I've read a fair amount of the source code and it seems to have been implemented without any consideration for efficiency.
http://rareformnewmedia.com/
I've read this online, and I would have to say you would be out of your mind to buy this book on Swing.
Why - well, it's written by Sun. They aren't allowed to say things like "this method is all fucked up, it fails mysteriously sometimes and when it does work, it's perversely slow, here is the workaround..."
Buy any other book, at least they are allowed to tell you the truth. There are a couple of good ones out there - "The complete guide to swing" (I think - it's at work)
But better yet, forget about Swing altogether.
The design is good, implementation is terrible.
Stick a break point in a callback and check out the call stack - 20 deep, WTF were they thinking.
Save yourselves endless grief and use the only decent LGPL cross-platform toolkit available:
FLTK, it even comes with its own powerful GUI design tool (fluid). You will end up with 1/4 of
the code required by a Swing based implementation and it will be 10x faster.
http://fltk.easysw.com
http://rareformnewmedia.com/
Before you pick up any book on how to build GUIs, you really ought to have a look at Alan Cooper's The Inmates are Running the Asylum. In fact, it ought to be compulsory reading for anybody building any kind of software. It explores concepts such as -- gasp! -- thinking about what the user is likely to need before design and coding, sticking to the original design, and treating prototypes as prototypes and not version 0.5.
Its theories on why all software is crap are refreshing and while it's simplistic in places, it's a book that both PHB's and those who actually do the work can comprehend.
I have all of these Linux programs that are not compatable with Linux. What a crappy operating system. I'm supposed to have a more stable system and I can't even run my new programs on an old version. (sarcasm off)
Write once, run anywhere means that I can write it once and run it on any compatable JVM on any hardware that happens to have a compatable JVM.
Interpretting the sentence as anything else is just ludicrous. It's flamebait of the highest order.
Edu. sig-line: Choose rhymes with lose. Chose rhymes with goes. Loose rhymes with goose.
Comparing? THEN use THAN.
The swing tutorial is part of the Java tutorial and has been available from www.javasoft.com/tutorial for years now. During this period the tutorial was expanded to cover new API's. It's an excellent resource for Java programmers. Together with the API documentation it is all the documentation you will ever need. The only thing that puzzles me is why somebody would want to use a printed version of these documents. The online version is so much more convenient.
As the reviewer noted, you typically don't read the tutorial from cover to cover. What you do is find some topic you're interested in, read it. Then you click links to related topics, examples or the API documentation. The latter is very hard to do in a paper version.
Jilles
AWT versus Swing and the compatibility and deprecation problem points to the root of the problem: the fact that Java can mathematically not deliver on its promises.
"Write once, run anywhere" not only makes abstraction of the fact that there is already a large installed base of different things, with no realistic cross-upgrade path, it even doesn't work when the whole world would be Java-only already.
Imagine Java does not change, and that there would only be one single release, then it would quickly fail to address new problems, take advantage of new research and development and in time be abandoned for newer technologies.
Imagine Java does change and gets upgraded. That means that it will get new features. If your code takes advantage of these new features, it will not be compatible with the old Java run-time. Therefore, your code does not "run anywhere". It doesn't even run on the previous Java platforms.
Everybody could have seen the AWT to Swing problem coming from day one.
Any technology that makes abstraction of the fact that there is already an installed base, is bound to fail. What's more, any technology that pretends that it will fill all holes, is a scam.
Everyone with half a brain could have seen this problem arriving, from day one, hour one, and minute one. If some idiot comes and tells you that your software will run out of the box on every single platform in the universe, and you believe him, you should check the content of your skull for contamination by animal defecation.
The less someone has a brain, the more that person is bound to be incompetent, and the more he is likely to hype along with the rest. The people who I saw jumping on the Java bandwagon, were already failing in their existing projects, didn't master their old technology and were hoping desperately for something new like Java to make up for their incompetence. I am sorry, but if you can't do the job, not one single technology is going to help.