in black and white
Main menu
Share a book About us Home
Biology Business Chemistry Computers Culture Economics Fiction Games Guide History Management Mathematical Medicine Mental Fitnes Physics Psychology Scince Sport Technics

More Java Pitfalls Share Reactor - Daconta M,C.

Daconta M,C. More Java Pitfalls Share Reactor - Wiley publishing, 2003. - 476 p.
ISBN: 0-471-23751-5
Download (direct link): morejavapitfallssharereactor2003.pdf
Previous << 1 .. 12 13 14 15 16 17 < 18 > 19 20 21 22 23 24 .. 166 >> Next

int readyKeyCnt = 0;
// loop forever (even if select() returns 0 ready keys)
while (true)
readyKeyCnt =;
// ...
With the above change made, is ready to continually accept files from clients. This pitfall has introduced you to some of the major features of the NIO package. The package has some clear benefits at the cost of some additional complexity. Readers should be ready for more changes to Java's IO packages. The most
34 Item 3
glaring pitfall with this package is its separation from the IO package and the addition of brand-new metaphors. Having said that, most programmers will overlook that incongruity for the benefits of the new features. Overall, the performance improvements offered by NIO make up for the minor pitfalls mentioned here. All programmers should be encouraged to learn and use the NIO package.
Item 3: I Prefer Not to Use Properties
I have worked in a number of places where all development was done on an isolated network and a set of machines was used for office automation tasks like email, Web browsing, word processing, and time charging.
In this case, I really have two sets of properties that I need to handle. First, I have the set of properties that handle configuring the system in general. Examples of this would be the mail server that needs to be referenced, the network file server to point toward, and the timecard server. These are things that are clearly independent of any user and have more to do with the system than the individual user accessing the system.
Second, a multitude of user properties are required. It starts by being arranged by functional application, and then it is further organized by functional areas within the application.
Consider this properties file:
This obviously wouldn't work, but it illustrates a simple problem in a properties file. You cannot give a common name to a particular property. Notice that naming a property "server" is remarkably appropriate in each of these cases. Furthermore, if you wanted to use a common piece of code to make a TCP/IP connection for all three apps listed, you couldn't do it without either writing custom code to parse out of three different files (a maintenance nightmare) or parsing the server subproperty.
This properties file shows a more typical example to avoid namespace collision:
Notice that these property names imply a sense of hierarchy. In fact, there is no hierarchy. There are only further qualified property names to make them more unique. However, our earlier example gave us the idea of being able to take the server subnode off of all of the primary nodes. There are no nodes since the properties file is not stored as a tree. This is where the Preferences API comes in handy. Listing 3.1 is an example of a preferences file.
I Prefer Not to Use Properties 35
01: <?xml version="1.0" encoding="UTF-8"?>
02: < !DOCTYPE preferences SYSTEM 2
'http ://'>
04: <preferences EXTERNAL_XML_VERSION="1.0">
06: <root type="user">
07: <map />
08: <node name="com">
09: <map>
10: <entry key="addr" value="8200 Greensboro Dr." />
11: <entry key="pi" value="3.1416" />
12: <entry key="number" value="23" />
13: </map>
14: <node name="mcbrad">
15: <map />
16: <node name="prefs">
17: <map>
18: <entry key="mail" value="mail" />
19: <entry key="ftp" value="shortbus" />
20: <entry key="timecard" value="spectator" />
21: </map>
22: </node>
23: </node>
24: </node>
26: </root>
27: </preferences>
Listing 3.1 A preferences file
This preferences file shows the hierarchical organization of its XML format. It is very helpful when organizing multiple preferences under a particular user's settings.
Hang on, though. This just jumped from a discussion of system properties to user properties. Being able to do that in a single file is probably the best example of how we benefit from a hierarchical format. Now that we have a tree structure, not only can we separate nodes between different parts of the system, but we can also make a separation between the system and the user. Once that separation can be defined, we can make a distinction between users. This makes it easier to maintain a large number of users, all separated on the tree.
Using properties, you must store user properties within the context of the user's home directory, and then you almost always need to store those values in a file that is hard-coded into the system. This adds an additional problem with trying to ensure consistent access to these hard-coded locations. Listing 3.2 is an example of how a developer might use properties.
36 Item 3
01 package org.pitfalls.prefs;
03 import java.util.Properties;
04 import*;
06 public class PropertiesTest {
Previous << 1 .. 12 13 14 15 16 17 < 18 > 19 20 21 22 23 24 .. 166 >> Next