>From Les Schaffer:
`any insights into why Sun was so uhhh slow to fully support Java under linux????' (Les)
`Yes, but I'm a little too paranoid...to talk about it on an open forum ....'
------------
Well here is a completely uninformed guess, based on near zero knowledge or understanding of what I am talking about.
It has to do with the idea that threads are native to java (designed in it) and Linux handles threads, both in user-space and kernel-space.
Bill Joy, one of (or the) architect of java is fascinated with the concept of self-replication. Self-replication and threads (parent-child process chains) are two slightly different but intimately relate concepts (homeomorphic lattices?).
For some reason it must have been that Sun's version of unix (can't remember the name at the moment) didn't do threads well or there was some problem over dealing with threads that fork multiple siblings from the same parent process who carry different inheritance lines of their own. This forking is something that I think java does, so if a java app is running as a thread, then some master OS has to deal with this forking problem, spawned by java. It could have been that Linux was on to a better approach and Sun simply wanted to stall until they sorted out their own approach to the problem.
So what? To answer this, you have to imagine what's potentially just down the road. My guess is a complete multi-channelled, multi-media center all on the same desktop: live tv coverage of sports, a cd music window, 3-D gaming, and a giant database (live mounted, and accessed on-line) so you can pretend to be doing some real work on a spread sheet--all these running in xterm windows some of which can spawn themsevles so you can change the tv channel to another one and have both running, or set up a new query for a different view of the same database or a different db..
Well, wild guesses,
Chuck Grimes