The internet, where everyone's an expert. And a conspiracy theorist.
Well, listen up, I was there, and I've been pushing for select() since
1.1, so let me fill you in:
You're full of it. Stop assuming things without checking facts.
There's only been one (1) person working on java.net since James Gosling
wrote the initial version. First Pavani, then Brown then BR... I've
lost track some time ago, I don't know the present person's name. They
usually did double duty in some other area, as well. Not because Sun
has any grand strategy on starving The Feature You Simply Can't Live
Without, but because java.net is (rightly) considered mostly done, and
other things get priority.
select was pretty much impossible to implement in green threads. Hell,
blocking IO was a bear under green threads. Remember green threads?
Sort of shoots your "it's an afternoon's work" argument in the head,
doesn't it? Thank God that that's no longer supported, but quite
frankly with the way Linux threads work (or fail to), green threads
could be mighty useful even still. But then you'd never get your
feature.
More inline:
Peter Donald wrote:
> Let me see - which step did I stuff up.
Everything after step 3.
> 1. Sun coined or at least advocates the term "The network is the computer"
Um, ok.
> 2. For a while Java has been billed as great for serverside stuff
It is.
> 3. The longest bug/feature request relating to serverside stuff is lack of
> select()
OK, I'll take that at face value, but I'd be suprised if it was true.
> 4. Implementing select() is not difficult considering it is part of POSIX
> and implemented on all platforms that I am aware of (except small ones
> which use a different platform - J2ME).
This is not entirely true. If it was trivial, someone would have
cranked it out over a weekend. Heck, you've got the source code (in
SCSL) - why don't YOU do it.
> 5. select() was implemented by other vendors hence the R&D costs should be
> minimal
Citation, please - I'm not aware of anyone else having implemented a
version of select() which was integrated into a Java VM.
> 6. Without select it is impossible to write scalable server apps that deal
> with sparsly transmitted upon connections except in hardware that have fine
> grain locking + many CPUs
Not true. With clever use of threads, it's been possible to write at
least one webserver which exceeded the performance of Apache using
standard benchmarks on SMP machines (both NT and Solaris, Linux threads
were crap back then, and the implementation wasn't up to it), as well as
a proxy server which was speed-competitive with Squid.
All of which sounds pretty competitive to me. Where are you getting
*your* data?
> 7. One of suns greatest revenue streams is selling hardware that has fine
> grain locking and many CPUs
True, but the connection to the rest of the argument is not established.
> 8. Given the above - Sun obviously believes networking is important, server
> products are a forte of java and have little cost or risk implementing
> select().
Demonstrated false - you're assuming little cost here, which has not
been established.
> 9. By virtue of 6 and 7 it would be an unwise buisness decision to
> implement select() as it would reduce demand for their hardware.
Not demonstrated by facts.
> Conclusion ?? (it should be obvious).
My conclusion is that it's more convenient for you to engage in
conspiracy theory than actually ask the engineers involved, or look at
the codebase, or think.
> Now which step in reasoning is invalid?
See above.
BTW - I've been out of it for awhile, I'll check and see if Merlin
finally has some of what you're looking for. (I hear there's a new IO
package in the works). But really, as I said, if you can write even a
halfway decent threadpool, it's not so necessary to have select.
It'd be far more yeild for high performance servers to have a bug-free
VM, better performance in multithreaded envirnments, security that
actually works, DNS lookups that do smart caching and all the other
things that those engineers actually worked on every time I asked if we
could have select now.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
