|
|
|
1000 Java Tips ebook
|
|
 
Free "1000 Java Tips" eBook is here! It is huge collection of big and small Java
programming articles and tips. Please take your copy here.
Take your copy of free "Java Technology Screensaver"!. |
|
Easy Learn Java: Programming Articles, Examples and Tips - Page 368
Previous
1060 Stories (530 Pages, 2 Per Page)
Next
The Java Look-and-Feel Debate
|
Java Swing comes with "pluggable look-and-feel
technology", which essentially boils down to the fact that interfaces can be
"skinned" (although this is simplifying a tad) and is therefore, extremely
flexible. By default, Java ships with a cross-platform look-and-feel (LAF),
which means your apps can look consistent across all platforms, or LAFs that
mimic the look of a specific platform, say Windows, for example. However, one of
the chief complaints of Java desktop applications is its "look". It basically
stems from two issues:
- The default cross-platform LAF is "ugly".
- The platform specific LAFs lack fidelity,
i.e., they're not convincingly native.
To be honest, they have a point! That's not to
say that there aren't many devs (and users) out there who are happy with the
LAFs Java ships, but there is work to be done. However, this isn't the end of
the story. Java GUIs can be made to look great. Also, is the issue of platform
fidelity really as big an issue as many developers think?
Native look and feels
There are many Java developers who program with
only the Windows platform in mind. They often feel disappointed that the Windows
LAF bundled with Java doesn't do an adequate job of looking like a Windows
application. However, does this really matter? Let's look at Microsoft software
for example. Take Microsoft Office, Microsoft Media Player and Microsoft
Messenger. Three extremely popular pieces of software for Windows, written by
Microsoft. Yet, the irony here is that MS themselves have taken great effort to
deviate away from the normal Windows look (and from a intra-MS perspective,
their own products also deviate from each other, where Office looks different to
Media Player, which looks different to Messenger, and so on). And they aren't
the only ones.
The full story at OSNews
here...
comments? |   | Score: 0
|
Posted by jalex on Thursday, June 02, 2005 (00:00:00) (2468 reads)
|
Fail Early, Fail Often
|
You will write bugs
In programming you will write a lot of bugs. Just accept it. I've known a lot of
fantatically capable programmers, but only one who wrote essentially flawless
code in the first draft, Ira Rubin.
Mistakes are educational
If you aren't writing bugs, at least while you're still learning the art of
programming, you probably aren't pushing yourself to try new things. You can
rationalize a lot of errors by repeating "I learn more from my mistakes than my
successes", and it's probably true.
Compile-time errors are the best
Ideally, you want someone else to find your errors. Compiler error checking is
your friend because it finds errors you've made immediately and tells you about
them. Some development systems even have continuous compilation, so you are
informed about errors during compilation. I haven't tried these systems, but
imagine it might work something like spelling checkers that put a read line
under words that might be errorneous as you type -- not intrusive, but letting
you know where there may be a problem.
The quality of compile-time error diagnosis is both a function of language
design and the compiler design. The Java language is so-so in this area, however
its strong typing (variable types must be declared) and required casting
are very good features. Some of the rumored featuers of JDK 1.5 will further
improve compile time checks, eg, templates, type-safe enums, and a "foreach"
statement. The goal of not allowing illegal programs to compile is impossible,
but its always interesting to think of how the language design could be improved
to help detect errors at compile time.
Catch runtime errors early if possible
The worst kind of runtime error causes the program to slowly fall apart. Perhaps
the greated leap that Java made over C++ is in providing runtime checks that
various common errors. Perhaps the most important features are garbage
collection and array indexes out of range.
Yet, there are still many possible run-time errors. Java provides another
great tool in the assert statement which checks that things
that must be true really are (See Assertions). Learn about assertions and
use them.
Rigorous testing
While it is true that testing can only show the presence of bugs, not their
absence, it essential. Methodologies such as Extreme Programming require
that test data be written before the code. The JUnit testing
facility makes writing and running tests much easier. With fast machines it is
possible to run regression tests frequently. See Testing.
Fail early, fail often
You will write bugs and you want them caught as early as possible. Use types to
help catch errors at compile time if possible; use assertions to stop execution
if something is wrong; use rigorous testing to find errors.
7 comments | | Score: 0
|
Posted by jalex on Wednesday, June 01, 2005 (00:00:00) (2600 reads)
|
|
|
RSS feed Java Forums
