IWETHEY v. 0.3.0 | TODO
1,095 registered users | 1 active user | 1 LpH | Statistics
Login | Create New User
IWETHEY Banner

Welcome to IWETHEY!

New Oh look more crap from sunsoft
Must we have thousands of new classes? The current Java io library is fat enough to choke a beaver.

Howabout we just leave shit alone for a little while and call it good?

None of this crap is new or innovative and it was possible to do all this crap before so where is the value add?

OK, I feel a little better now.
New Carl Sagan meet Sunsoft: Billions and billions of classes..
"Beware of bugs in the above code; I have only proved it correct, not tried it."
-- Donald Knuth
New Yes and no
These classes do provide important functionality that was not there. The problem is that it doesn't tie well into the existing Java classes. The following quote illustrates this: [link|http://www.javaworld.com/javaworld/jw-09-2001/jw-0907-merlin.html|Master Merlin's new I/O classes]

"On the other hand, the new I/O doesn't integrate well with the old I/O. (And when exactly will it stop being new? Will Sun rename the packages when the next, newer I/O capability comes along?) In particular, the Buffers don't connect well with existing java.io classes. Just try explaining that BufferedReader can't read into Buffers and you can't pass a Buffer to BufferedWriter! The JCP operates by chartering an expert group (a committee) to address each specification request. These expert groups work independently, each with a relatively narrow charter. It is hardly surprising that there is little interaction between feature sets, or that new features do not reach broadly into the existing APIs. "

Unfortunatley this is what happens when you design a language by committees.
New Designing language
Actually, having more (enlightened) people in on the language design would have been good I think.

But the library designs have been short on vision and forethought. The "old" IO library remains a mess since the addition of Readers in place of InputStreams. Why every input class doesn't have both a Reader and InputStream ctor is beyond me - but it certainly takes some digging to come up with just the right set of nestings when you're given a InputStream and you need a type of Reader or vice versa.

Javasoft sucks at design.
     Java 1.4 non blocking I/O apis - (bluke) - (7)
         Back to the future: cooperative multi-tasking - (ben_tilly) - (2)
             Expensive thread startups... - (admin) - (1)
                 That just underscores my point - (ben_tilly)
         Oh look more crap from sunsoft - (tuberculosis) - (3)
             Carl Sagan meet Sunsoft: Billions and billions of classes.. -NT - (wharris2)
             Yes and no - (bluke) - (1)
                 Designing language - (tuberculosis)

If for no other reason that historical (hysterical?) context.
72 ms