Slashdot Mirror

MiTEG writes "The Washington Post has an article on a cheaper alternative to Microsoft's Office Suite, ThinkFree Office. Currently selling for $50, their product also includes a one year subscription to Cyberdrive, a 20 MB web file-storage service. While it's no StarOffice, this glowing review may help people realize that Microsoft is not the only option." 'Glowing review' probably isn't the right term to use, since the reviewer found quite a few faults.

rbeattie writes: "This morning at JavaOne it was announced during the keynote that Sun and Apache have come to an agreement securing the basic right to implement Java specifications in open source. Apache actually went as far as issuing a Press Release about it with information about the agreement. One of the cool things is that Sun actually agreed not only to change various licenses and contracts, release the testing code, but also to let qualifying non-profit open source groups use their 1800 support number while testing." (This is a followup to this earlier story indicating that such an agreement had been reached.)

Over on NewsForge, Roblimo has taken a look at Sun's new StarOffice 6.0 (due out in April for retail purchase), and comparing it to OpenOffice build 641C. I installed StarOffice on a new Toshiba laptop, and since my Mandrake 8.2 ISOs are still trickling in, have StarOffice 6.0 running instead under Windows XP. (I have just a few additional notes on this, below.)

The installation was dead simple, and therefore better than most software: I popped in the CD, and with about 10 minutes of point-click-whirrring, the software was installed. The only notable aspect of this process is that the CD included (and popped onto my hard drive, with prompting) a new Java runtime environment (Sun's standard JRE, version 1.3.1). The helpful timer that accompanies the install is conservative, which is nice -- it started out estimating 14 minutes for the "transferring files" portion, but quickly dropped down to less than five.

Having not touched StarOffice for a while, it's nice to see the features in OpenOffice trickle in -- most importantly, getting rid of the monolithic desktop makes it actually usable to those of us who hate screen-hijacking software. And at least on this 1 GHz, 256MB laptop, even "bloatware" features like auto-correction are snappy enough not to be bothersome.

Two small notes on Roblimo's review for anyone curious about using SO under Windows: The Windows version does claim to open "WordPerfect (Win) 6.0-7.0" documents, which is at least a start toward WordPerfect compatibility. And under Windows, the nice X-Window style one-click text transfer isn't an option. One more note for 6.0 Beta testers: you can download a patch from Sun to extend the life of the beta from March 31 to June 3 2002.

klocwerk writes "At the game developers conference, Sun is releasing a white paper on their new "Java Games Profile." Their ultimate goal? To have one CD you could pop into an Xbox, a PS2, a Windows machine, or a Linux machine, and play the same game on them all. If they get full support for it I can finally get rid of that windows gaming partition!" Sun's got an article on their site describing what they hope to accomplish.

phalse phace writes "Yahoo! News is carrying a ZDNet News article which reveals that Mandrake has decided to change its policy regarding its Mandrake Club. Previously, Mandrake stated that all membership levels would enjoy the same benefits. But since Mandrake Linux 8.2 will include StarOffice 6.0 and Sun is charging for it, they decided to only allow the download of SO 6.0 to Silver members and higher."

phalse phace writes "Yahoo! News is carrying a ZDNet News article which reveals that Mandrake has decided to change its policy regarding its Mandrake Club. Previously, Mandrake stated that all membership levels would enjoy the same benefits. But since Mandrake Linux 8.2 will include StarOffice 6.0 and Sun is charging for it, they decided to only allow the download of SO 6.0 to Silver members and higher."

webjam writes: "JXTA for JXME shows a practical use of Sun's JavaTM 2 Platform Micro Edition. "Project JXTA is short for Juxtapose. It is in recognition that peer to peer is juxtapose to client server or Web based computing." The purpose of project JXTA for J2ME is to provide JXTA functionality to java enabled cell-phones and handhelds. We will soon see applications released based on these projects and technologies. Those who understand and can efficiently develop applications using these tools will no doubt have a prosperous future. Even with a limited knowledge of programming, working applications can be created using the APIs provided. Check out the Software requirements and build instructions. Once running it will provide application developers with the emulation environment; documentation and examples needed to develop Java technology applications targeted at CLDC/MIDP compliant mobile phones and entry level PDAs. Also, check out some of the main JXTA projects and applications developed so far..... Oh, I almost forgot, for sending instant messaging from your mobile toys, I would suggest you go ahead and spring for that teeny external keyboard :-) Alphanumeric just doesn't cut it."

An anonymous reader "Sun Microsystems has released the Sun Blade 2000 workstation, along with a new graphics accelerator, the XVR-1000. This could very well give SGI's lineup a run for its money in the CAD and Visualization fields, although its fillrate and 38-bit colour may make it less desirable for animation. Make sure to check out Ace's article. " (page down a couple times to read it)

An anonymous reader "Sun Microsystems has released the Sun Blade 2000 workstation, along with a new graphics accelerator, the XVR-1000. This could very well give SGI's lineup a run for its money in the CAD and Visualization fields, although its fillrate and 38-bit colour may make it less desirable for animation. Make sure to check out Ace's article. " (page down a couple times to read it)

An anonymous reader "Sun Microsystems has released the Sun Blade 2000 workstation, along with a new graphics accelerator, the XVR-1000. This could very well give SGI's lineup a run for its money in the CAD and Visualization fields, although its fillrate and 38-bit colour may make it less desirable for animation. Make sure to check out Ace's article. " (page down a couple times to read it)

Herve writes "Sun Microsystems announced it has filed a private antitrust lawsuit against Microsoft Corporation. The suit, filed March 8, 2002 in the United States District Court in San Jose, CA., seeks remedies for the harm inflicted by Microsoft's anticompetitive behavior with respect to the Java[tm] platform and for damages resulting from Microsoft's illegal efforts to maintain and expand its monopoly power. In June 2001, the Federal Court of Appeals found Microsoft guilty of illegally abusing its monopoly power with respect to Sun and the Java platform. Sun's suit seeks to redress the competitive and economic harm caused by Microsoft's illegal acts."

Herve writes "Sun Microsystems announced it has filed a private antitrust lawsuit against Microsoft Corporation. The suit, filed March 8, 2002 in the United States District Court in San Jose, CA., seeks remedies for the harm inflicted by Microsoft's anticompetitive behavior with respect to the Java[tm] platform and for damages resulting from Microsoft's illegal efforts to maintain and expand its monopoly power. In June 2001, the Federal Court of Appeals found Microsoft guilty of illegally abusing its monopoly power with respect to Sun and the Java platform. Sun's suit seeks to redress the competitive and economic harm caused by Microsoft's illegal acts."

Reader amoon writes: "With the rise of XML-based RPC (e.g. SOAP, XML-RPC, APEX), the distributed computing world is starting to really unsettle from the CORBA-RMI-DCOM oligopoly of the 1980s and 1990s. Yet, XML-based RPC is not a panacea (though it is quite cool), especially for those of us involved in the legacy and client-server worlds. Now, what is fascinating: the publishing world is revving up the engines on not only the XML-based RPC stuff, but also the RMI and CORBA stuff -- while rarely applied to the tech industry, the old adage, "what was old is new again," seems to fit well here. This review describes this über-cool trend from the RMI perspective, with a focus on Java RMI (O'Reilly) by William Grosso." Read on for the rest of the review. Java RMI author William Grosso pages 545 publisher O'Reilly rating 8 reviewer amoon ISBN 1-56592-452-5 summary Solid practical insight into the nitty-gritty details of RMI.

The Scoop

Remote Method Invocation (RMI) is the object-oriented remote procedure call (ORPC) facility for distributed programming in Java, since the 1.1 days. RMI also served as motivation and a proof-of-concept for jini, javaspaces, and numerous other solid distributed networking technologies. Of course, anyone from the academic distributed programming world knows Wollrath, Waldo, and Riggs.

Yet, despite a myriad of books over the past five years on network programming, RMI always seemed to be the stepchild: relegated to a single chapter (buried on page 496, of course) that always said that RMI was "better" than sockets and "worse" than CORBA. Now, granted that RMI is operationally rather trivial compared with CORBA and was (prior to RMI/IIOP) a unilanguage distributed ORPC technology -- but still. For those of us who have to interoperate with RMI (whether welcome from the Java world or not), the lack of in-depth technical analysis (beyond the spec) has been a hindrance.

Fortunately, this trend is finally starting to buckle with the release of several in-depth RMI books including: Java RMI, Java.rmi, and Mastering RMI: Developing Enterprise Applications in Java and EJB. As evidence of this problem, Grosso states the same in his introduction – and actually pulls it off without sounding self-serving.

I chose Grosso's text because of the cute squirrel (aka the O'Reilly brand), Grosso's recent series of articles on the hashbelt algorithm, and his unadulterated academic knowledge management and mathematics bent. Fortunately, I was rewarded: this animal returns to O'Reilly's pre-bubble quality. Koodoos to both Grosso and his editors (Knudsen, Loukides, and Eckstein) for getting the train back on the track.

What's to Like

Bottom line is that Grosso simply covers the topics and does so with solid conceptual and code coherence – even by O'Reilly standards (over 40 animals grace my shelves). His prose and explanatory patterns make it clear that he has actually gotten into the real-world of RMI, and doesn't hesitate to highlight both good and bad parts. You cannot be dozing off when you read this (at least not if you expect to understand it) -- this is written by someone with solid analytic thinking skills and it shows. After too many years of "there are no caveats" journalism and publishing, this is a nice reversion. Further, I can only imagine that his current employment is a testament to his real-world knowledge of RMI.

Grosso hits on a vein which is not well-appreciated: when not smoothed over by marketing people, RMI is actually a mostly-capable ORPC technology. Certainly activation and RMI/IIOP really began to make things interesting, from Java2 and EJB respectively. Discussion of reference-counted distributed garbage collection, a feature missing from CORBA and other popular ORPC standards, also contributes a nice bonus (although Grosso's ardent attempt to debunk the "RMI doesn't scale" argument is rather weak, even going so far as to rehash the definition of Threads and threadpools – this complexity mismatch is an ugly giveaway that a well-intentioned editor went astray).

What sets this text apart is the tight focus on nitty-gritty implementation details of RMI itself. After all, these RMI texts are way too late to the game to reteach how to write "baby RMI" code: 5 years after the original spec, you either know how to write RMI or you don't. Grosso simply gives you a solid in-depth analysis of all the obscurities of the RMI runtime, custom sockets, dynamic classloading, activation, MarshalledObjects, and HTTP tunneling. In other words, all the interesting real-world topics whose official documentation is poor and which the various RMI tutorials (written many years ago) ignored.

While canonical, the single banking example followed through the text was well-executed, although authors continue to underestimate the prevalence of readers who consume textbooks non-linearly.

What's Not to Like

RMI/IIOP is shaping up to be a fascinating contributor to the "cleanup the EJB mess" discussion. Dedicating a measly 13 pages (beginning on page 503, no less) to this critical topic seems a bit of an oversight – but maybe that is just my CORBA sentiments speaking. Either way, the mechanics of CORBA are sufficiently intricate in real-world deployments that saying "if you can build an RMI system, you can build a CORBA system" (p. 511) is a bit brazen (or naïve) for my tastebuds. I can only chalk up this oversight to deadline pressure, which is probably a Good Thing, since the book was supposedly in production over almost 2 years.

A minor point: the top-level organization of the book (Part I, II, III) is arbitrary, ignore it -- use the chapter organization instead.

The Summary

Quality: solid practical insight into the nitty-gritty operational implementation details of RMI in the real-world. You simply are not going to find solid O'Reilly-quality coverage of the topics elsewhere.

Relevance: If you are responsible for making RMI actually work in production systems, this might well be the next animal on your shelf – either now or later. If you want a breezy afternoon saunter around RMI, skip this. Instead, google one (of the many) free tutorials online."

You can purchase Java RMI from Fatbrain. Want to see your own review here? Just read the book review guidelines, then use Slashdot's handy submission form.

Reader amoon writes: "With the rise of XML-based RPC (e.g. SOAP, XML-RPC, APEX), the distributed computing world is starting to really unsettle from the CORBA-RMI-DCOM oligopoly of the 1980s and 1990s. Yet, XML-based RPC is not a panacea (though it is quite cool), especially for those of us involved in the legacy and client-server worlds. Now, what is fascinating: the publishing world is revving up the engines on not only the XML-based RPC stuff, but also the RMI and CORBA stuff -- while rarely applied to the tech industry, the old adage, "what was old is new again," seems to fit well here. This review describes this über-cool trend from the RMI perspective, with a focus on Java RMI (O'Reilly) by William Grosso." Read on for the rest of the review. Java RMI author William Grosso pages 545 publisher O'Reilly rating 8 reviewer amoon ISBN 1-56592-452-5 summary Solid practical insight into the nitty-gritty details of RMI.

The Scoop

Remote Method Invocation (RMI) is the object-oriented remote procedure call (ORPC) facility for distributed programming in Java, since the 1.1 days. RMI also served as motivation and a proof-of-concept for jini, javaspaces, and numerous other solid distributed networking technologies. Of course, anyone from the academic distributed programming world knows Wollrath, Waldo, and Riggs.

Yet, despite a myriad of books over the past five years on network programming, RMI always seemed to be the stepchild: relegated to a single chapter (buried on page 496, of course) that always said that RMI was "better" than sockets and "worse" than CORBA. Now, granted that RMI is operationally rather trivial compared with CORBA and was (prior to RMI/IIOP) a unilanguage distributed ORPC technology -- but still. For those of us who have to interoperate with RMI (whether welcome from the Java world or not), the lack of in-depth technical analysis (beyond the spec) has been a hindrance.

Fortunately, this trend is finally starting to buckle with the release of several in-depth RMI books including: Java RMI, Java.rmi, and Mastering RMI: Developing Enterprise Applications in Java and EJB. As evidence of this problem, Grosso states the same in his introduction – and actually pulls it off without sounding self-serving.

I chose Grosso's text because of the cute squirrel (aka the O'Reilly brand), Grosso's recent series of articles on the hashbelt algorithm, and his unadulterated academic knowledge management and mathematics bent. Fortunately, I was rewarded: this animal returns to O'Reilly's pre-bubble quality. Koodoos to both Grosso and his editors (Knudsen, Loukides, and Eckstein) for getting the train back on the track.

What's to Like

Bottom line is that Grosso simply covers the topics and does so with solid conceptual and code coherence – even by O'Reilly standards (over 40 animals grace my shelves). His prose and explanatory patterns make it clear that he has actually gotten into the real-world of RMI, and doesn't hesitate to highlight both good and bad parts. You cannot be dozing off when you read this (at least not if you expect to understand it) -- this is written by someone with solid analytic thinking skills and it shows. After too many years of "there are no caveats" journalism and publishing, this is a nice reversion. Further, I can only imagine that his current employment is a testament to his real-world knowledge of RMI.

Grosso hits on a vein which is not well-appreciated: when not smoothed over by marketing people, RMI is actually a mostly-capable ORPC technology. Certainly activation and RMI/IIOP really began to make things interesting, from Java2 and EJB respectively. Discussion of reference-counted distributed garbage collection, a feature missing from CORBA and other popular ORPC standards, also contributes a nice bonus (although Grosso's ardent attempt to debunk the "RMI doesn't scale" argument is rather weak, even going so far as to rehash the definition of Threads and threadpools – this complexity mismatch is an ugly giveaway that a well-intentioned editor went astray).

What sets this text apart is the tight focus on nitty-gritty implementation details of RMI itself. After all, these RMI texts are way too late to the game to reteach how to write "baby RMI" code: 5 years after the original spec, you either know how to write RMI or you don't. Grosso simply gives you a solid in-depth analysis of all the obscurities of the RMI runtime, custom sockets, dynamic classloading, activation, MarshalledObjects, and HTTP tunneling. In other words, all the interesting real-world topics whose official documentation is poor and which the various RMI tutorials (written many years ago) ignored.

While canonical, the single banking example followed through the text was well-executed, although authors continue to underestimate the prevalence of readers who consume textbooks non-linearly.

What's Not to Like

RMI/IIOP is shaping up to be a fascinating contributor to the "cleanup the EJB mess" discussion. Dedicating a measly 13 pages (beginning on page 503, no less) to this critical topic seems a bit of an oversight – but maybe that is just my CORBA sentiments speaking. Either way, the mechanics of CORBA are sufficiently intricate in real-world deployments that saying "if you can build an RMI system, you can build a CORBA system" (p. 511) is a bit brazen (or naïve) for my tastebuds. I can only chalk up this oversight to deadline pressure, which is probably a Good Thing, since the book was supposedly in production over almost 2 years.

A minor point: the top-level organization of the book (Part I, II, III) is arbitrary, ignore it -- use the chapter organization instead.

The Summary

Quality: solid practical insight into the nitty-gritty operational implementation details of RMI in the real-world. You simply are not going to find solid O'Reilly-quality coverage of the topics elsewhere.

Relevance: If you are responsible for making RMI actually work in production systems, this might well be the next animal on your shelf – either now or later. If you want a breezy afternoon saunter around RMI, skip this. Instead, google one (of the many) free tutorials online."

You can purchase Java RMI from Fatbrain. Want to see your own review here? Just read the book review guidelines, then use Slashdot's handy submission form.

Reader amoon writes: "With the rise of XML-based RPC (e.g. SOAP, XML-RPC, APEX), the distributed computing world is starting to really unsettle from the CORBA-RMI-DCOM oligopoly of the 1980s and 1990s. Yet, XML-based RPC is not a panacea (though it is quite cool), especially for those of us involved in the legacy and client-server worlds. Now, what is fascinating: the publishing world is revving up the engines on not only the XML-based RPC stuff, but also the RMI and CORBA stuff -- while rarely applied to the tech industry, the old adage, "what was old is new again," seems to fit well here. This review describes this über-cool trend from the RMI perspective, with a focus on Java RMI (O'Reilly) by William Grosso." Read on for the rest of the review. Java RMI author William Grosso pages 545 publisher O'Reilly rating 8 reviewer amoon ISBN 1-56592-452-5 summary Solid practical insight into the nitty-gritty details of RMI.

The Scoop

Remote Method Invocation (RMI) is the object-oriented remote procedure call (ORPC) facility for distributed programming in Java, since the 1.1 days. RMI also served as motivation and a proof-of-concept for jini, javaspaces, and numerous other solid distributed networking technologies. Of course, anyone from the academic distributed programming world knows Wollrath, Waldo, and Riggs.

Yet, despite a myriad of books over the past five years on network programming, RMI always seemed to be the stepchild: relegated to a single chapter (buried on page 496, of course) that always said that RMI was "better" than sockets and "worse" than CORBA. Now, granted that RMI is operationally rather trivial compared with CORBA and was (prior to RMI/IIOP) a unilanguage distributed ORPC technology -- but still. For those of us who have to interoperate with RMI (whether welcome from the Java world or not), the lack of in-depth technical analysis (beyond the spec) has been a hindrance.

Fortunately, this trend is finally starting to buckle with the release of several in-depth RMI books including: Java RMI, Java.rmi, and Mastering RMI: Developing Enterprise Applications in Java and EJB. As evidence of this problem, Grosso states the same in his introduction – and actually pulls it off without sounding self-serving.

I chose Grosso's text because of the cute squirrel (aka the O'Reilly brand), Grosso's recent series of articles on the hashbelt algorithm, and his unadulterated academic knowledge management and mathematics bent. Fortunately, I was rewarded: this animal returns to O'Reilly's pre-bubble quality. Koodoos to both Grosso and his editors (Knudsen, Loukides, and Eckstein) for getting the train back on the track.

What's to Like

Bottom line is that Grosso simply covers the topics and does so with solid conceptual and code coherence – even by O'Reilly standards (over 40 animals grace my shelves). His prose and explanatory patterns make it clear that he has actually gotten into the real-world of RMI, and doesn't hesitate to highlight both good and bad parts. You cannot be dozing off when you read this (at least not if you expect to understand it) -- this is written by someone with solid analytic thinking skills and it shows. After too many years of "there are no caveats" journalism and publishing, this is a nice reversion. Further, I can only imagine that his current employment is a testament to his real-world knowledge of RMI.

Grosso hits on a vein which is not well-appreciated: when not smoothed over by marketing people, RMI is actually a mostly-capable ORPC technology. Certainly activation and RMI/IIOP really began to make things interesting, from Java2 and EJB respectively. Discussion of reference-counted distributed garbage collection, a feature missing from CORBA and other popular ORPC standards, also contributes a nice bonus (although Grosso's ardent attempt to debunk the "RMI doesn't scale" argument is rather weak, even going so far as to rehash the definition of Threads and threadpools – this complexity mismatch is an ugly giveaway that a well-intentioned editor went astray).

What sets this text apart is the tight focus on nitty-gritty implementation details of RMI itself. After all, these RMI texts are way too late to the game to reteach how to write "baby RMI" code: 5 years after the original spec, you either know how to write RMI or you don't. Grosso simply gives you a solid in-depth analysis of all the obscurities of the RMI runtime, custom sockets, dynamic classloading, activation, MarshalledObjects, and HTTP tunneling. In other words, all the interesting real-world topics whose official documentation is poor and which the various RMI tutorials (written many years ago) ignored.

While canonical, the single banking example followed through the text was well-executed, although authors continue to underestimate the prevalence of readers who consume textbooks non-linearly.

What's Not to Like

RMI/IIOP is shaping up to be a fascinating contributor to the "cleanup the EJB mess" discussion. Dedicating a measly 13 pages (beginning on page 503, no less) to this critical topic seems a bit of an oversight – but maybe that is just my CORBA sentiments speaking. Either way, the mechanics of CORBA are sufficiently intricate in real-world deployments that saying "if you can build an RMI system, you can build a CORBA system" (p. 511) is a bit brazen (or naïve) for my tastebuds. I can only chalk up this oversight to deadline pressure, which is probably a Good Thing, since the book was supposedly in production over almost 2 years.

A minor point: the top-level organization of the book (Part I, II, III) is arbitrary, ignore it -- use the chapter organization instead.

The Summary

Quality: solid practical insight into the nitty-gritty operational implementation details of RMI in the real-world. You simply are not going to find solid O'Reilly-quality coverage of the topics elsewhere.

Relevance: If you are responsible for making RMI actually work in production systems, this might well be the next animal on your shelf – either now or later. If you want a breezy afternoon saunter around RMI, skip this. Instead, google one (of the many) free tutorials online."

You can purchase Java RMI from Fatbrain. Want to see your own review here? Just read the book review guidelines, then use Slashdot's handy submission form.

Reader amoon writes: "With the rise of XML-based RPC (e.g. SOAP, XML-RPC, APEX), the distributed computing world is starting to really unsettle from the CORBA-RMI-DCOM oligopoly of the 1980s and 1990s. Yet, XML-based RPC is not a panacea (though it is quite cool), especially for those of us involved in the legacy and client-server worlds. Now, what is fascinating: the publishing world is revving up the engines on not only the XML-based RPC stuff, but also the RMI and CORBA stuff -- while rarely applied to the tech industry, the old adage, "what was old is new again," seems to fit well here. This review describes this über-cool trend from the RMI perspective, with a focus on Java RMI (O'Reilly) by William Grosso." Read on for the rest of the review. Java RMI author William Grosso pages 545 publisher O'Reilly rating 8 reviewer amoon ISBN 1-56592-452-5 summary Solid practical insight into the nitty-gritty details of RMI.

The Scoop

Remote Method Invocation (RMI) is the object-oriented remote procedure call (ORPC) facility for distributed programming in Java, since the 1.1 days. RMI also served as motivation and a proof-of-concept for jini, javaspaces, and numerous other solid distributed networking technologies. Of course, anyone from the academic distributed programming world knows Wollrath, Waldo, and Riggs.

Yet, despite a myriad of books over the past five years on network programming, RMI always seemed to be the stepchild: relegated to a single chapter (buried on page 496, of course) that always said that RMI was "better" than sockets and "worse" than CORBA. Now, granted that RMI is operationally rather trivial compared with CORBA and was (prior to RMI/IIOP) a unilanguage distributed ORPC technology -- but still. For those of us who have to interoperate with RMI (whether welcome from the Java world or not), the lack of in-depth technical analysis (beyond the spec) has been a hindrance.

Fortunately, this trend is finally starting to buckle with the release of several in-depth RMI books including: Java RMI, Java.rmi, and Mastering RMI: Developing Enterprise Applications in Java and EJB. As evidence of this problem, Grosso states the same in his introduction – and actually pulls it off without sounding self-serving.

I chose Grosso's text because of the cute squirrel (aka the O'Reilly brand), Grosso's recent series of articles on the hashbelt algorithm, and his unadulterated academic knowledge management and mathematics bent. Fortunately, I was rewarded: this animal returns to O'Reilly's pre-bubble quality. Koodoos to both Grosso and his editors (Knudsen, Loukides, and Eckstein) for getting the train back on the track.

What's to Like

Bottom line is that Grosso simply covers the topics and does so with solid conceptual and code coherence – even by O'Reilly standards (over 40 animals grace my shelves). His prose and explanatory patterns make it clear that he has actually gotten into the real-world of RMI, and doesn't hesitate to highlight both good and bad parts. You cannot be dozing off when you read this (at least not if you expect to understand it) -- this is written by someone with solid analytic thinking skills and it shows. After too many years of "there are no caveats" journalism and publishing, this is a nice reversion. Further, I can only imagine that his current employment is a testament to his real-world knowledge of RMI.

Grosso hits on a vein which is not well-appreciated: when not smoothed over by marketing people, RMI is actually a mostly-capable ORPC technology. Certainly activation and RMI/IIOP really began to make things interesting, from Java2 and EJB respectively. Discussion of reference-counted distributed garbage collection, a feature missing from CORBA and other popular ORPC standards, also contributes a nice bonus (although Grosso's ardent attempt to debunk the "RMI doesn't scale" argument is rather weak, even going so far as to rehash the definition of Threads and threadpools – this complexity mismatch is an ugly giveaway that a well-intentioned editor went astray).

What sets this text apart is the tight focus on nitty-gritty implementation details of RMI itself. After all, these RMI texts are way too late to the game to reteach how to write "baby RMI" code: 5 years after the original spec, you either know how to write RMI or you don't. Grosso simply gives you a solid in-depth analysis of all the obscurities of the RMI runtime, custom sockets, dynamic classloading, activation, MarshalledObjects, and HTTP tunneling. In other words, all the interesting real-world topics whose official documentation is poor and which the various RMI tutorials (written many years ago) ignored.

While canonical, the single banking example followed through the text was well-executed, although authors continue to underestimate the prevalence of readers who consume textbooks non-linearly.

What's Not to Like

RMI/IIOP is shaping up to be a fascinating contributor to the "cleanup the EJB mess" discussion. Dedicating a measly 13 pages (beginning on page 503, no less) to this critical topic seems a bit of an oversight – but maybe that is just my CORBA sentiments speaking. Either way, the mechanics of CORBA are sufficiently intricate in real-world deployments that saying "if you can build an RMI system, you can build a CORBA system" (p. 511) is a bit brazen (or naïve) for my tastebuds. I can only chalk up this oversight to deadline pressure, which is probably a Good Thing, since the book was supposedly in production over almost 2 years.

A minor point: the top-level organization of the book (Part I, II, III) is arbitrary, ignore it -- use the chapter organization instead.

The Summary

Quality: solid practical insight into the nitty-gritty operational implementation details of RMI in the real-world. You simply are not going to find solid O'Reilly-quality coverage of the topics elsewhere.

Relevance: If you are responsible for making RMI actually work in production systems, this might well be the next animal on your shelf – either now or later. If you want a breezy afternoon saunter around RMI, skip this. Instead, google one (of the many) free tutorials online."

You can purchase Java RMI from Fatbrain. Want to see your own review here? Just read the book review guidelines, then use Slashdot's handy submission form.

Reader amoon writes: "With the rise of XML-based RPC (e.g. SOAP, XML-RPC, APEX), the distributed computing world is starting to really unsettle from the CORBA-RMI-DCOM oligopoly of the 1980s and 1990s. Yet, XML-based RPC is not a panacea (though it is quite cool), especially for those of us involved in the legacy and client-server worlds. Now, what is fascinating: the publishing world is revving up the engines on not only the XML-based RPC stuff, but also the RMI and CORBA stuff -- while rarely applied to the tech industry, the old adage, "what was old is new again," seems to fit well here. This review describes this über-cool trend from the RMI perspective, with a focus on Java RMI (O'Reilly) by William Grosso." Read on for the rest of the review. Java RMI author William Grosso pages 545 publisher O'Reilly rating 8 reviewer amoon ISBN 1-56592-452-5 summary Solid practical insight into the nitty-gritty details of RMI.

The Scoop

Remote Method Invocation (RMI) is the object-oriented remote procedure call (ORPC) facility for distributed programming in Java, since the 1.1 days. RMI also served as motivation and a proof-of-concept for jini, javaspaces, and numerous other solid distributed networking technologies. Of course, anyone from the academic distributed programming world knows Wollrath, Waldo, and Riggs.

Yet, despite a myriad of books over the past five years on network programming, RMI always seemed to be the stepchild: relegated to a single chapter (buried on page 496, of course) that always said that RMI was "better" than sockets and "worse" than CORBA. Now, granted that RMI is operationally rather trivial compared with CORBA and was (prior to RMI/IIOP) a unilanguage distributed ORPC technology -- but still. For those of us who have to interoperate with RMI (whether welcome from the Java world or not), the lack of in-depth technical analysis (beyond the spec) has been a hindrance.

Fortunately, this trend is finally starting to buckle with the release of several in-depth RMI books including: Java RMI, Java.rmi, and Mastering RMI: Developing Enterprise Applications in Java and EJB. As evidence of this problem, Grosso states the same in his introduction – and actually pulls it off without sounding self-serving.

I chose Grosso's text because of the cute squirrel (aka the O'Reilly brand), Grosso's recent series of articles on the hashbelt algorithm, and his unadulterated academic knowledge management and mathematics bent. Fortunately, I was rewarded: this animal returns to O'Reilly's pre-bubble quality. Koodoos to both Grosso and his editors (Knudsen, Loukides, and Eckstein) for getting the train back on the track.

What's to Like

Bottom line is that Grosso simply covers the topics and does so with solid conceptual and code coherence – even by O'Reilly standards (over 40 animals grace my shelves). His prose and explanatory patterns make it clear that he has actually gotten into the real-world of RMI, and doesn't hesitate to highlight both good and bad parts. You cannot be dozing off when you read this (at least not if you expect to understand it) -- this is written by someone with solid analytic thinking skills and it shows. After too many years of "there are no caveats" journalism and publishing, this is a nice reversion. Further, I can only imagine that his current employment is a testament to his real-world knowledge of RMI.

Grosso hits on a vein which is not well-appreciated: when not smoothed over by marketing people, RMI is actually a mostly-capable ORPC technology. Certainly activation and RMI/IIOP really began to make things interesting, from Java2 and EJB respectively. Discussion of reference-counted distributed garbage collection, a feature missing from CORBA and other popular ORPC standards, also contributes a nice bonus (although Grosso's ardent attempt to debunk the "RMI doesn't scale" argument is rather weak, even going so far as to rehash the definition of Threads and threadpools – this complexity mismatch is an ugly giveaway that a well-intentioned editor went astray).

What sets this text apart is the tight focus on nitty-gritty implementation details of RMI itself. After all, these RMI texts are way too late to the game to reteach how to write "baby RMI" code: 5 years after the original spec, you either know how to write RMI or you don't. Grosso simply gives you a solid in-depth analysis of all the obscurities of the RMI runtime, custom sockets, dynamic classloading, activation, MarshalledObjects, and HTTP tunneling. In other words, all the interesting real-world topics whose official documentation is poor and which the various RMI tutorials (written many years ago) ignored.

While canonical, the single banking example followed through the text was well-executed, although authors continue to underestimate the prevalence of readers who consume textbooks non-linearly.

What's Not to Like

RMI/IIOP is shaping up to be a fascinating contributor to the "cleanup the EJB mess" discussion. Dedicating a measly 13 pages (beginning on page 503, no less) to this critical topic seems a bit of an oversight – but maybe that is just my CORBA sentiments speaking. Either way, the mechanics of CORBA are sufficiently intricate in real-world deployments that saying "if you can build an RMI system, you can build a CORBA system" (p. 511) is a bit brazen (or naïve) for my tastebuds. I can only chalk up this oversight to deadline pressure, which is probably a Good Thing, since the book was supposedly in production over almost 2 years.

A minor point: the top-level organization of the book (Part I, II, III) is arbitrary, ignore it -- use the chapter organization instead.

The Summary

Quality: solid practical insight into the nitty-gritty operational implementation details of RMI in the real-world. You simply are not going to find solid O'Reilly-quality coverage of the topics elsewhere.

Relevance: If you are responsible for making RMI actually work in production systems, this might well be the next animal on your shelf – either now or later. If you want a breezy afternoon saunter around RMI, skip this. Instead, google one (of the many) free tutorials online."

You can purchase Java RMI from Fatbrain. Want to see your own review here? Just read the book review guidelines, then use Slashdot's handy submission form.

Reader amoon writes: "With the rise of XML-based RPC (e.g. SOAP, XML-RPC, APEX), the distributed computing world is starting to really unsettle from the CORBA-RMI-DCOM oligopoly of the 1980s and 1990s. Yet, XML-based RPC is not a panacea (though it is quite cool), especially for those of us involved in the legacy and client-server worlds. Now, what is fascinating: the publishing world is revving up the engines on not only the XML-based RPC stuff, but also the RMI and CORBA stuff -- while rarely applied to the tech industry, the old adage, "what was old is new again," seems to fit well here. This review describes this über-cool trend from the RMI perspective, with a focus on Java RMI (O'Reilly) by William Grosso." Read on for the rest of the review. Java RMI author William Grosso pages 545 publisher O'Reilly rating 8 reviewer amoon ISBN 1-56592-452-5 summary Solid practical insight into the nitty-gritty details of RMI.

The Scoop

Remote Method Invocation (RMI) is the object-oriented remote procedure call (ORPC) facility for distributed programming in Java, since the 1.1 days. RMI also served as motivation and a proof-of-concept for jini, javaspaces, and numerous other solid distributed networking technologies. Of course, anyone from the academic distributed programming world knows Wollrath, Waldo, and Riggs.

Yet, despite a myriad of books over the past five years on network programming, RMI always seemed to be the stepchild: relegated to a single chapter (buried on page 496, of course) that always said that RMI was "better" than sockets and "worse" than CORBA. Now, granted that RMI is operationally rather trivial compared with CORBA and was (prior to RMI/IIOP) a unilanguage distributed ORPC technology -- but still. For those of us who have to interoperate with RMI (whether welcome from the Java world or not), the lack of in-depth technical analysis (beyond the spec) has been a hindrance.

Fortunately, this trend is finally starting to buckle with the release of several in-depth RMI books including: Java RMI, Java.rmi, and Mastering RMI: Developing Enterprise Applications in Java and EJB. As evidence of this problem, Grosso states the same in his introduction – and actually pulls it off without sounding self-serving.

I chose Grosso's text because of the cute squirrel (aka the O'Reilly brand), Grosso's recent series of articles on the hashbelt algorithm, and his unadulterated academic knowledge management and mathematics bent. Fortunately, I was rewarded: this animal returns to O'Reilly's pre-bubble quality. Koodoos to both Grosso and his editors (Knudsen, Loukides, and Eckstein) for getting the train back on the track.

What's to Like

Bottom line is that Grosso simply covers the topics and does so with solid conceptual and code coherence – even by O'Reilly standards (over 40 animals grace my shelves). His prose and explanatory patterns make it clear that he has actually gotten into the real-world of RMI, and doesn't hesitate to highlight both good and bad parts. You cannot be dozing off when you read this (at least not if you expect to understand it) -- this is written by someone with solid analytic thinking skills and it shows. After too many years of "there are no caveats" journalism and publishing, this is a nice reversion. Further, I can only imagine that his current employment is a testament to his real-world knowledge of RMI.

Grosso hits on a vein which is not well-appreciated: when not smoothed over by marketing people, RMI is actually a mostly-capable ORPC technology. Certainly activation and RMI/IIOP really began to make things interesting, from Java2 and EJB respectively. Discussion of reference-counted distributed garbage collection, a feature missing from CORBA and other popular ORPC standards, also contributes a nice bonus (although Grosso's ardent attempt to debunk the "RMI doesn't scale" argument is rather weak, even going so far as to rehash the definition of Threads and threadpools – this complexity mismatch is an ugly giveaway that a well-intentioned editor went astray).

What sets this text apart is the tight focus on nitty-gritty implementation details of RMI itself. After all, these RMI texts are way too late to the game to reteach how to write "baby RMI" code: 5 years after the original spec, you either know how to write RMI or you don't. Grosso simply gives you a solid in-depth analysis of all the obscurities of the RMI runtime, custom sockets, dynamic classloading, activation, MarshalledObjects, and HTTP tunneling. In other words, all the interesting real-world topics whose official documentation is poor and which the various RMI tutorials (written many years ago) ignored.

While canonical, the single banking example followed through the text was well-executed, although authors continue to underestimate the prevalence of readers who consume textbooks non-linearly.

What's Not to Like

RMI/IIOP is shaping up to be a fascinating contributor to the "cleanup the EJB mess" discussion. Dedicating a measly 13 pages (beginning on page 503, no less) to this critical topic seems a bit of an oversight – but maybe that is just my CORBA sentiments speaking. Either way, the mechanics of CORBA are sufficiently intricate in real-world deployments that saying "if you can build an RMI system, you can build a CORBA system" (p. 511) is a bit brazen (or naïve) for my tastebuds. I can only chalk up this oversight to deadline pressure, which is probably a Good Thing, since the book was supposedly in production over almost 2 years.

A minor point: the top-level organization of the book (Part I, II, III) is arbitrary, ignore it -- use the chapter organization instead.

The Summary

Quality: solid practical insight into the nitty-gritty operational implementation details of RMI in the real-world. You simply are not going to find solid O'Reilly-quality coverage of the topics elsewhere.

Relevance: If you are responsible for making RMI actually work in production systems, this might well be the next animal on your shelf – either now or later. If you want a breezy afternoon saunter around RMI, skip this. Instead, google one (of the many) free tutorials online."

You can purchase Java RMI from Fatbrain. Want to see your own review here? Just read the book review guidelines, then use Slashdot's handy submission form.

Reader amoon writes: "With the rise of XML-based RPC (e.g. SOAP, XML-RPC, APEX), the distributed computing world is starting to really unsettle from the CORBA-RMI-DCOM oligopoly of the 1980s and 1990s. Yet, XML-based RPC is not a panacea (though it is quite cool), especially for those of us involved in the legacy and client-server worlds. Now, what is fascinating: the publishing world is revving up the engines on not only the XML-based RPC stuff, but also the RMI and CORBA stuff -- while rarely applied to the tech industry, the old adage, "what was old is new again," seems to fit well here. This review describes this über-cool trend from the RMI perspective, with a focus on Java RMI (O'Reilly) by William Grosso." Read on for the rest of the review. Java RMI author William Grosso pages 545 publisher O'Reilly rating 8 reviewer amoon ISBN 1-56592-452-5 summary Solid practical insight into the nitty-gritty details of RMI.

The Scoop

Remote Method Invocation (RMI) is the object-oriented remote procedure call (ORPC) facility for distributed programming in Java, since the 1.1 days. RMI also served as motivation and a proof-of-concept for jini, javaspaces, and numerous other solid distributed networking technologies. Of course, anyone from the academic distributed programming world knows Wollrath, Waldo, and Riggs.

Yet, despite a myriad of books over the past five years on network programming, RMI always seemed to be the stepchild: relegated to a single chapter (buried on page 496, of course) that always said that RMI was "better" than sockets and "worse" than CORBA. Now, granted that RMI is operationally rather trivial compared with CORBA and was (prior to RMI/IIOP) a unilanguage distributed ORPC technology -- but still. For those of us who have to interoperate with RMI (whether welcome from the Java world or not), the lack of in-depth technical analysis (beyond the spec) has been a hindrance.

Fortunately, this trend is finally starting to buckle with the release of several in-depth RMI books including: Java RMI, Java.rmi, and Mastering RMI: Developing Enterprise Applications in Java and EJB. As evidence of this problem, Grosso states the same in his introduction – and actually pulls it off without sounding self-serving.

I chose Grosso's text because of the cute squirrel (aka the O'Reilly brand), Grosso's recent series of articles on the hashbelt algorithm, and his unadulterated academic knowledge management and mathematics bent. Fortunately, I was rewarded: this animal returns to O'Reilly's pre-bubble quality. Koodoos to both Grosso and his editors (Knudsen, Loukides, and Eckstein) for getting the train back on the track.

What's to Like

Bottom line is that Grosso simply covers the topics and does so with solid conceptual and code coherence – even by O'Reilly standards (over 40 animals grace my shelves). His prose and explanatory patterns make it clear that he has actually gotten into the real-world of RMI, and doesn't hesitate to highlight both good and bad parts. You cannot be dozing off when you read this (at least not if you expect to understand it) -- this is written by someone with solid analytic thinking skills and it shows. After too many years of "there are no caveats" journalism and publishing, this is a nice reversion. Further, I can only imagine that his current employment is a testament to his real-world knowledge of RMI.

Grosso hits on a vein which is not well-appreciated: when not smoothed over by marketing people, RMI is actually a mostly-capable ORPC technology. Certainly activation and RMI/IIOP really began to make things interesting, from Java2 and EJB respectively. Discussion of reference-counted distributed garbage collection, a feature missing from CORBA and other popular ORPC standards, also contributes a nice bonus (although Grosso's ardent attempt to debunk the "RMI doesn't scale" argument is rather weak, even going so far as to rehash the definition of Threads and threadpools – this complexity mismatch is an ugly giveaway that a well-intentioned editor went astray).

What sets this text apart is the tight focus on nitty-gritty implementation details of RMI itself. After all, these RMI texts are way too late to the game to reteach how to write "baby RMI" code: 5 years after the original spec, you either know how to write RMI or you don't. Grosso simply gives you a solid in-depth analysis of all the obscurities of the RMI runtime, custom sockets, dynamic classloading, activation, MarshalledObjects, and HTTP tunneling. In other words, all the interesting real-world topics whose official documentation is poor and which the various RMI tutorials (written many years ago) ignored.

While canonical, the single banking example followed through the text was well-executed, although authors continue to underestimate the prevalence of readers who consume textbooks non-linearly.

What's Not to Like

RMI/IIOP is shaping up to be a fascinating contributor to the "cleanup the EJB mess" discussion. Dedicating a measly 13 pages (beginning on page 503, no less) to this critical topic seems a bit of an oversight – but maybe that is just my CORBA sentiments speaking. Either way, the mechanics of CORBA are sufficiently intricate in real-world deployments that saying "if you can build an RMI system, you can build a CORBA system" (p. 511) is a bit brazen (or naïve) for my tastebuds. I can only chalk up this oversight to deadline pressure, which is probably a Good Thing, since the book was supposedly in production over almost 2 years.

A minor point: the top-level organization of the book (Part I, II, III) is arbitrary, ignore it -- use the chapter organization instead.

The Summary

Quality: solid practical insight into the nitty-gritty operational implementation details of RMI in the real-world. You simply are not going to find solid O'Reilly-quality coverage of the topics elsewhere.

Relevance: If you are responsible for making RMI actually work in production systems, this might well be the next animal on your shelf – either now or later. If you want a breezy afternoon saunter around RMI, skip this. Instead, google one (of the many) free tutorials online."

You can purchase Java RMI from Fatbrain. Want to see your own review here? Just read the book review guidelines, then use Slashdot's handy submission form.

Reader amoon writes: "With the rise of XML-based RPC (e.g. SOAP, XML-RPC, APEX), the distributed computing world is starting to really unsettle from the CORBA-RMI-DCOM oligopoly of the 1980s and 1990s. Yet, XML-based RPC is not a panacea (though it is quite cool), especially for those of us involved in the legacy and client-server worlds. Now, what is fascinating: the publishing world is revving up the engines on not only the XML-based RPC stuff, but also the RMI and CORBA stuff -- while rarely applied to the tech industry, the old adage, "what was old is new again," seems to fit well here. This review describes this über-cool trend from the RMI perspective, with a focus on Java RMI (O'Reilly) by William Grosso." Read on for the rest of the review. Java RMI author William Grosso pages 545 publisher O'Reilly rating 8 reviewer amoon ISBN 1-56592-452-5 summary Solid practical insight into the nitty-gritty details of RMI.

The Scoop

Remote Method Invocation (RMI) is the object-oriented remote procedure call (ORPC) facility for distributed programming in Java, since the 1.1 days. RMI also served as motivation and a proof-of-concept for jini, javaspaces, and numerous other solid distributed networking technologies. Of course, anyone from the academic distributed programming world knows Wollrath, Waldo, and Riggs.

Yet, despite a myriad of books over the past five years on network programming, RMI always seemed to be the stepchild: relegated to a single chapter (buried on page 496, of course) that always said that RMI was "better" than sockets and "worse" than CORBA. Now, granted that RMI is operationally rather trivial compared with CORBA and was (prior to RMI/IIOP) a unilanguage distributed ORPC technology -- but still. For those of us who have to interoperate with RMI (whether welcome from the Java world or not), the lack of in-depth technical analysis (beyond the spec) has been a hindrance.

Fortunately, this trend is finally starting to buckle with the release of several in-depth RMI books including: Java RMI, Java.rmi, and Mastering RMI: Developing Enterprise Applications in Java and EJB. As evidence of this problem, Grosso states the same in his introduction – and actually pulls it off without sounding self-serving.

I chose Grosso's text because of the cute squirrel (aka the O'Reilly brand), Grosso's recent series of articles on the hashbelt algorithm, and his unadulterated academic knowledge management and mathematics bent. Fortunately, I was rewarded: this animal returns to O'Reilly's pre-bubble quality. Koodoos to both Grosso and his editors (Knudsen, Loukides, and Eckstein) for getting the train back on the track.

What's to Like

Bottom line is that Grosso simply covers the topics and does so with solid conceptual and code coherence – even by O'Reilly standards (over 40 animals grace my shelves). His prose and explanatory patterns make it clear that he has actually gotten into the real-world of RMI, and doesn't hesitate to highlight both good and bad parts. You cannot be dozing off when you read this (at least not if you expect to understand it) -- this is written by someone with solid analytic thinking skills and it shows. After too many years of "there are no caveats" journalism and publishing, this is a nice reversion. Further, I can only imagine that his current employment is a testament to his real-world knowledge of RMI.

Grosso hits on a vein which is not well-appreciated: when not smoothed over by marketing people, RMI is actually a mostly-capable ORPC technology. Certainly activation and RMI/IIOP really began to make things interesting, from Java2 and EJB respectively. Discussion of reference-counted distributed garbage collection, a feature missing from CORBA and other popular ORPC standards, also contributes a nice bonus (although Grosso's ardent attempt to debunk the "RMI doesn't scale" argument is rather weak, even going so far as to rehash the definition of Threads and threadpools – this complexity mismatch is an ugly giveaway that a well-intentioned editor went astray).

What sets this text apart is the tight focus on nitty-gritty implementation details of RMI itself. After all, these RMI texts are way too late to the game to reteach how to write "baby RMI" code: 5 years after the original spec, you either know how to write RMI or you don't. Grosso simply gives you a solid in-depth analysis of all the obscurities of the RMI runtime, custom sockets, dynamic classloading, activation, MarshalledObjects, and HTTP tunneling. In other words, all the interesting real-world topics whose official documentation is poor and which the various RMI tutorials (written many years ago) ignored.

While canonical, the single banking example followed through the text was well-executed, although authors continue to underestimate the prevalence of readers who consume textbooks non-linearly.

What's Not to Like

RMI/IIOP is shaping up to be a fascinating contributor to the "cleanup the EJB mess" discussion. Dedicating a measly 13 pages (beginning on page 503, no less) to this critical topic seems a bit of an oversight – but maybe that is just my CORBA sentiments speaking. Either way, the mechanics of CORBA are sufficiently intricate in real-world deployments that saying "if you can build an RMI system, you can build a CORBA system" (p. 511) is a bit brazen (or naïve) for my tastebuds. I can only chalk up this oversight to deadline pressure, which is probably a Good Thing, since the book was supposedly in production over almost 2 years.

A minor point: the top-level organization of the book (Part I, II, III) is arbitrary, ignore it -- use the chapter organization instead.

The Summary

Quality: solid practical insight into the nitty-gritty operational implementation details of RMI in the real-world. You simply are not going to find solid O'Reilly-quality coverage of the topics elsewhere.

Relevance: If you are responsible for making RMI actually work in production systems, this might well be the next animal on your shelf – either now or later. If you want a breezy afternoon saunter around RMI, skip this. Instead, google one (of the many) free tutorials online."

You can purchase Java RMI from Fatbrain. Want to see your own review here? Just read the book review guidelines, then use Slashdot's handy submission form.

Reader amoon writes: "With the rise of XML-based RPC (e.g. SOAP, XML-RPC, APEX), the distributed computing world is starting to really unsettle from the CORBA-RMI-DCOM oligopoly of the 1980s and 1990s. Yet, XML-based RPC is not a panacea (though it is quite cool), especially for those of us involved in the legacy and client-server worlds. Now, what is fascinating: the publishing world is revving up the engines on not only the XML-based RPC stuff, but also the RMI and CORBA stuff -- while rarely applied to the tech industry, the old adage, "what was old is new again," seems to fit well here. This review describes this über-cool trend from the RMI perspective, with a focus on Java RMI (O'Reilly) by William Grosso." Read on for the rest of the review. Java RMI author William Grosso pages 545 publisher O'Reilly rating 8 reviewer amoon ISBN 1-56592-452-5 summary Solid practical insight into the nitty-gritty details of RMI.

The Scoop

Remote Method Invocation (RMI) is the object-oriented remote procedure call (ORPC) facility for distributed programming in Java, since the 1.1 days. RMI also served as motivation and a proof-of-concept for jini, javaspaces, and numerous other solid distributed networking technologies. Of course, anyone from the academic distributed programming world knows Wollrath, Waldo, and Riggs.

Yet, despite a myriad of books over the past five years on network programming, RMI always seemed to be the stepchild: relegated to a single chapter (buried on page 496, of course) that always said that RMI was "better" than sockets and "worse" than CORBA. Now, granted that RMI is operationally rather trivial compared with CORBA and was (prior to RMI/IIOP) a unilanguage distributed ORPC technology -- but still. For those of us who have to interoperate with RMI (whether welcome from the Java world or not), the lack of in-depth technical analysis (beyond the spec) has been a hindrance.

Fortunately, this trend is finally starting to buckle with the release of several in-depth RMI books including: Java RMI, Java.rmi, and Mastering RMI: Developing Enterprise Applications in Java and EJB. As evidence of this problem, Grosso states the same in his introduction – and actually pulls it off without sounding self-serving.

I chose Grosso's text because of the cute squirrel (aka the O'Reilly brand), Grosso's recent series of articles on the hashbelt algorithm, and his unadulterated academic knowledge management and mathematics bent. Fortunately, I was rewarded: this animal returns to O'Reilly's pre-bubble quality. Koodoos to both Grosso and his editors (Knudsen, Loukides, and Eckstein) for getting the train back on the track.

What's to Like

Bottom line is that Grosso simply covers the topics and does so with solid conceptual and code coherence – even by O'Reilly standards (over 40 animals grace my shelves). His prose and explanatory patterns make it clear that he has actually gotten into the real-world of RMI, and doesn't hesitate to highlight both good and bad parts. You cannot be dozing off when you read this (at least not if you expect to understand it) -- this is written by someone with solid analytic thinking skills and it shows. After too many years of "there are no caveats" journalism and publishing, this is a nice reversion. Further, I can only imagine that his current employment is a testament to his real-world knowledge of RMI.

Grosso hits on a vein which is not well-appreciated: when not smoothed over by marketing people, RMI is actually a mostly-capable ORPC technology. Certainly activation and RMI/IIOP really began to make things interesting, from Java2 and EJB respectively. Discussion of reference-counted distributed garbage collection, a feature missing from CORBA and other popular ORPC standards, also contributes a nice bonus (although Grosso's ardent attempt to debunk the "RMI doesn't scale" argument is rather weak, even going so far as to rehash the definition of Threads and threadpools – this complexity mismatch is an ugly giveaway that a well-intentioned editor went astray).

What sets this text apart is the tight focus on nitty-gritty implementation details of RMI itself. After all, these RMI texts are way too late to the game to reteach how to write "baby RMI" code: 5 years after the original spec, you either know how to write RMI or you don't. Grosso simply gives you a solid in-depth analysis of all the obscurities of the RMI runtime, custom sockets, dynamic classloading, activation, MarshalledObjects, and HTTP tunneling. In other words, all the interesting real-world topics whose official documentation is poor and which the various RMI tutorials (written many years ago) ignored.

While canonical, the single banking example followed through the text was well-executed, although authors continue to underestimate the prevalence of readers who consume textbooks non-linearly.

What's Not to Like

RMI/IIOP is shaping up to be a fascinating contributor to the "cleanup the EJB mess" discussion. Dedicating a measly 13 pages (beginning on page 503, no less) to this critical topic seems a bit of an oversight – but maybe that is just my CORBA sentiments speaking. Either way, the mechanics of CORBA are sufficiently intricate in real-world deployments that saying "if you can build an RMI system, you can build a CORBA system" (p. 511) is a bit brazen (or naïve) for my tastebuds. I can only chalk up this oversight to deadline pressure, which is probably a Good Thing, since the book was supposedly in production over almost 2 years.

A minor point: the top-level organization of the book (Part I, II, III) is arbitrary, ignore it -- use the chapter organization instead.

The Summary

Quality: solid practical insight into the nitty-gritty operational implementation details of RMI in the real-world. You simply are not going to find solid O'Reilly-quality coverage of the topics elsewhere.

Relevance: If you are responsible for making RMI actually work in production systems, this might well be the next animal on your shelf – either now or later. If you want a breezy afternoon saunter around RMI, skip this. Instead, google one (of the many) free tutorials online."

You can purchase Java RMI from Fatbrain. Want to see your own review here? Just read the book review guidelines, then use Slashdot's handy submission form.

Reader amoon writes: "With the rise of XML-based RPC (e.g. SOAP, XML-RPC, APEX), the distributed computing world is starting to really unsettle from the CORBA-RMI-DCOM oligopoly of the 1980s and 1990s. Yet, XML-based RPC is not a panacea (though it is quite cool), especially for those of us involved in the legacy and client-server worlds. Now, what is fascinating: the publishing world is revving up the engines on not only the XML-based RPC stuff, but also the RMI and CORBA stuff -- while rarely applied to the tech industry, the old adage, "what was old is new again," seems to fit well here. This review describes this über-cool trend from the RMI perspective, with a focus on Java RMI (O'Reilly) by William Grosso." Read on for the rest of the review. Java RMI author William Grosso pages 545 publisher O'Reilly rating 8 reviewer amoon ISBN 1-56592-452-5 summary Solid practical insight into the nitty-gritty details of RMI.

The Scoop

Remote Method Invocation (RMI) is the object-oriented remote procedure call (ORPC) facility for distributed programming in Java, since the 1.1 days. RMI also served as motivation and a proof-of-concept for jini, javaspaces, and numerous other solid distributed networking technologies. Of course, anyone from the academic distributed programming world knows Wollrath, Waldo, and Riggs.

Yet, despite a myriad of books over the past five years on network programming, RMI always seemed to be the stepchild: relegated to a single chapter (buried on page 496, of course) that always said that RMI was "better" than sockets and "worse" than CORBA. Now, granted that RMI is operationally rather trivial compared with CORBA and was (prior to RMI/IIOP) a unilanguage distributed ORPC technology -- but still. For those of us who have to interoperate with RMI (whether welcome from the Java world or not), the lack of in-depth technical analysis (beyond the spec) has been a hindrance.

Fortunately, this trend is finally starting to buckle with the release of several in-depth RMI books including: Java RMI, Java.rmi, and Mastering RMI: Developing Enterprise Applications in Java and EJB. As evidence of this problem, Grosso states the same in his introduction – and actually pulls it off without sounding self-serving.

I chose Grosso's text because of the cute squirrel (aka the O'Reilly brand), Grosso's recent series of articles on the hashbelt algorithm, and his unadulterated academic knowledge management and mathematics bent. Fortunately, I was rewarded: this animal returns to O'Reilly's pre-bubble quality. Koodoos to both Grosso and his editors (Knudsen, Loukides, and Eckstein) for getting the train back on the track.

What's to Like

Bottom line is that Grosso simply covers the topics and does so with solid conceptual and code coherence – even by O'Reilly standards (over 40 animals grace my shelves). His prose and explanatory patterns make it clear that he has actually gotten into the real-world of RMI, and doesn't hesitate to highlight both good and bad parts. You cannot be dozing off when you read this (at least not if you expect to understand it) -- this is written by someone with solid analytic thinking skills and it shows. After too many years of "there are no caveats" journalism and publishing, this is a nice reversion. Further, I can only imagine that his current employment is a testament to his real-world knowledge of RMI.

Grosso hits on a vein which is not well-appreciated: when not smoothed over by marketing people, RMI is actually a mostly-capable ORPC technology. Certainly activation and RMI/IIOP really began to make things interesting, from Java2 and EJB respectively. Discussion of reference-counted distributed garbage collection, a feature missing from CORBA and other popular ORPC standards, also contributes a nice bonus (although Grosso's ardent attempt to debunk the "RMI doesn't scale" argument is rather weak, even going so far as to rehash the definition of Threads and threadpools – this complexity mismatch is an ugly giveaway that a well-intentioned editor went astray).

What sets this text apart is the tight focus on nitty-gritty implementation details of RMI itself. After all, these RMI texts are way too late to the game to reteach how to write "baby RMI" code: 5 years after the original spec, you either know how to write RMI or you don't. Grosso simply gives you a solid in-depth analysis of all the obscurities of the RMI runtime, custom sockets, dynamic classloading, activation, MarshalledObjects, and HTTP tunneling. In other words, all the interesting real-world topics whose official documentation is poor and which the various RMI tutorials (written many years ago) ignored.

While canonical, the single banking example followed through the text was well-executed, although authors continue to underestimate the prevalence of readers who consume textbooks non-linearly.

What's Not to Like

RMI/IIOP is shaping up to be a fascinating contributor to the "cleanup the EJB mess" discussion. Dedicating a measly 13 pages (beginning on page 503, no less) to this critical topic seems a bit of an oversight – but maybe that is just my CORBA sentiments speaking. Either way, the mechanics of CORBA are sufficiently intricate in real-world deployments that saying "if you can build an RMI system, you can build a CORBA system" (p. 511) is a bit brazen (or naïve) for my tastebuds. I can only chalk up this oversight to deadline pressure, which is probably a Good Thing, since the book was supposedly in production over almost 2 years.

A minor point: the top-level organization of the book (Part I, II, III) is arbitrary, ignore it -- use the chapter organization instead.

The Summary

Quality: solid practical insight into the nitty-gritty operational implementation details of RMI in the real-world. You simply are not going to find solid O'Reilly-quality coverage of the topics elsewhere.

Relevance: If you are responsible for making RMI actually work in production systems, this might well be the next animal on your shelf – either now or later. If you want a breezy afternoon saunter around RMI, skip this. Instead, google one (of the many) free tutorials online."

You can purchase Java RMI from Fatbrain. Want to see your own review here? Just read the book review guidelines, then use Slashdot's handy submission form.

Reader amoon writes: "With the rise of XML-based RPC (e.g. SOAP, XML-RPC, APEX), the distributed computing world is starting to really unsettle from the CORBA-RMI-DCOM oligopoly of the 1980s and 1990s. Yet, XML-based RPC is not a panacea (though it is quite cool), especially for those of us involved in the legacy and client-server worlds. Now, what is fascinating: the publishing world is revving up the engines on not only the XML-based RPC stuff, but also the RMI and CORBA stuff -- while rarely applied to the tech industry, the old adage, "what was old is new again," seems to fit well here. This review describes this über-cool trend from the RMI perspective, with a focus on Java RMI (O'Reilly) by William Grosso." Read on for the rest of the review. Java RMI author William Grosso pages 545 publisher O'Reilly rating 8 reviewer amoon ISBN 1-56592-452-5 summary Solid practical insight into the nitty-gritty details of RMI.

The Scoop

Remote Method Invocation (RMI) is the object-oriented remote procedure call (ORPC) facility for distributed programming in Java, since the 1.1 days. RMI also served as motivation and a proof-of-concept for jini, javaspaces, and numerous other solid distributed networking technologies. Of course, anyone from the academic distributed programming world knows Wollrath, Waldo, and Riggs.

Yet, despite a myriad of books over the past five years on network programming, RMI always seemed to be the stepchild: relegated to a single chapter (buried on page 496, of course) that always said that RMI was "better" than sockets and "worse" than CORBA. Now, granted that RMI is operationally rather trivial compared with CORBA and was (prior to RMI/IIOP) a unilanguage distributed ORPC technology -- but still. For those of us who have to interoperate with RMI (whether welcome from the Java world or not), the lack of in-depth technical analysis (beyond the spec) has been a hindrance.

Fortunately, this trend is finally starting to buckle with the release of several in-depth RMI books including: Java RMI, Java.rmi, and Mastering RMI: Developing Enterprise Applications in Java and EJB. As evidence of this problem, Grosso states the same in his introduction – and actually pulls it off without sounding self-serving.

I chose Grosso's text because of the cute squirrel (aka the O'Reilly brand), Grosso's recent series of articles on the hashbelt algorithm, and his unadulterated academic knowledge management and mathematics bent. Fortunately, I was rewarded: this animal returns to O'Reilly's pre-bubble quality. Koodoos to both Grosso and his editors (Knudsen, Loukides, and Eckstein) for getting the train back on the track.

What's to Like

Bottom line is that Grosso simply covers the topics and does so with solid conceptual and code coherence – even by O'Reilly standards (over 40 animals grace my shelves). His prose and explanatory patterns make it clear that he has actually gotten into the real-world of RMI, and doesn't hesitate to highlight both good and bad parts. You cannot be dozing off when you read this (at least not if you expect to understand it) -- this is written by someone with solid analytic thinking skills and it shows. After too many years of "there are no caveats" journalism and publishing, this is a nice reversion. Further, I can only imagine that his current employment is a testament to his real-world knowledge of RMI.

Grosso hits on a vein which is not well-appreciated: when not smoothed over by marketing people, RMI is actually a mostly-capable ORPC technology. Certainly activation and RMI/IIOP really began to make things interesting, from Java2 and EJB respectively. Discussion of reference-counted distributed garbage collection, a feature missing from CORBA and other popular ORPC standards, also contributes a nice bonus (although Grosso's ardent attempt to debunk the "RMI doesn't scale" argument is rather weak, even going so far as to rehash the definition of Threads and threadpools – this complexity mismatch is an ugly giveaway that a well-intentioned editor went astray).

What sets this text apart is the tight focus on nitty-gritty implementation details of RMI itself. After all, these RMI texts are way too late to the game to reteach how to write "baby RMI" code: 5 years after the original spec, you either know how to write RMI or you don't. Grosso simply gives you a solid in-depth analysis of all the obscurities of the RMI runtime, custom sockets, dynamic classloading, activation, MarshalledObjects, and HTTP tunneling. In other words, all the interesting real-world topics whose official documentation is poor and which the various RMI tutorials (written many years ago) ignored.

While canonical, the single banking example followed through the text was well-executed, although authors continue to underestimate the prevalence of readers who consume textbooks non-linearly.

What's Not to Like

RMI/IIOP is shaping up to be a fascinating contributor to the "cleanup the EJB mess" discussion. Dedicating a measly 13 pages (beginning on page 503, no less) to this critical topic seems a bit of an oversight – but maybe that is just my CORBA sentiments speaking. Either way, the mechanics of CORBA are sufficiently intricate in real-world deployments that saying "if you can build an RMI system, you can build a CORBA system" (p. 511) is a bit brazen (or naïve) for my tastebuds. I can only chalk up this oversight to deadline pressure, which is probably a Good Thing, since the book was supposedly in production over almost 2 years.

A minor point: the top-level organization of the book (Part I, II, III) is arbitrary, ignore it -- use the chapter organization instead.

The Summary

Quality: solid practical insight into the nitty-gritty operational implementation details of RMI in the real-world. You simply are not going to find solid O'Reilly-quality coverage of the topics elsewhere.

Relevance: If you are responsible for making RMI actually work in production systems, this might well be the next animal on your shelf – either now or later. If you want a breezy afternoon saunter around RMI, skip this. Instead, google one (of the many) free tutorials online."

You can purchase Java RMI from Fatbrain. Want to see your own review here? Just read the book review guidelines, then use Slashdot's handy submission form.

alapalaya queries: "If you had to implement a message dispatcher with soft real time requirements, which has to manage a lot of messages, and in general subject to a lot of problematic requirements (including object persistence); all implemented using a Java Message Service; what implementation would you use? In fewer words: in your opinion what is the best Java Message Service Implementation? Among the various JMS implementations I am currently using SonicMQ; but it doesn't seem to scale up in a proper way (to around several hundreds of clients generating from 10 to 200 messages/sec each). What do you know about other vendors/implementations?"

dagbrown writes: "An article linked from Sun's front page, entitled "Linux on the mainframe: Not a good idea" by Shahin Khan, Sun's chief competitive officer, has the interesting theory that Linux on mainframes makes no sense because, among other things, the VM/Linux combo isn't a very good match. What do the folks on Slashdot think?"

dagbrown writes: "An article linked from Sun's front page, entitled "Linux on the mainframe: Not a good idea" by Shahin Khan, Sun's chief competitive officer, has the interesting theory that Linux on mainframes makes no sense because, among other things, the VM/Linux combo isn't a very good match. What do the folks on Slashdot think?"

pangloss writes: "Yay: XML, built-in Perl-ish regex, jdbc 3.0, asserts, IPv6, lots of other goodies. Release notes and incompatibilities. And I think this means I can use my wheel-mouse in NetBeans without that extra module ;) Download it here." WilsonSD adds: "There are many cool new features including a New I/O package, an Assert Facility and enhanced performance." Some other random Java notes: O'Reilly has an essay about why you won't see any open source J2EE implementations, and Kodak has filed a patent-infringement claim against Sun regarding Java.

pangloss writes: "Yay: XML, built-in Perl-ish regex, jdbc 3.0, asserts, IPv6, lots of other goodies. Release notes and incompatibilities. And I think this means I can use my wheel-mouse in NetBeans without that extra module ;) Download it here." WilsonSD adds: "There are many cool new features including a New I/O package, an Assert Facility and enhanced performance." Some other random Java notes: O'Reilly has an essay about why you won't see any open source J2EE implementations, and Kodak has filed a patent-infringement claim against Sun regarding Java.

pangloss writes: "Yay: XML, built-in Perl-ish regex, jdbc 3.0, asserts, IPv6, lots of other goodies. Release notes and incompatibilities. And I think this means I can use my wheel-mouse in NetBeans without that extra module ;) Download it here." WilsonSD adds: "There are many cool new features including a New I/O package, an Assert Facility and enhanced performance." Some other random Java notes: O'Reilly has an essay about why you won't see any open source J2EE implementations, and Kodak has filed a patent-infringement claim against Sun regarding Java.

pangloss writes: "Yay: XML, built-in Perl-ish regex, jdbc 3.0, asserts, IPv6, lots of other goodies. Release notes and incompatibilities. And I think this means I can use my wheel-mouse in NetBeans without that extra module ;) Download it here." WilsonSD adds: "There are many cool new features including a New I/O package, an Assert Facility and enhanced performance." Some other random Java notes: O'Reilly has an essay about why you won't see any open source J2EE implementations, and Kodak has filed a patent-infringement claim against Sun regarding Java.

pangloss writes: "Yay: XML, built-in Perl-ish regex, jdbc 3.0, asserts, IPv6, lots of other goodies. Release notes and incompatibilities. And I think this means I can use my wheel-mouse in NetBeans without that extra module ;) Download it here." WilsonSD adds: "There are many cool new features including a New I/O package, an Assert Facility and enhanced performance." Some other random Java notes: O'Reilly has an essay about why you won't see any open source J2EE implementations, and Kodak has filed a patent-infringement claim against Sun regarding Java.

pangloss writes: "Yay: XML, built-in Perl-ish regex, jdbc 3.0, asserts, IPv6, lots of other goodies. Release notes and incompatibilities. And I think this means I can use my wheel-mouse in NetBeans without that extra module ;) Download it here." WilsonSD adds: "There are many cool new features including a New I/O package, an Assert Facility and enhanced performance." Some other random Java notes: O'Reilly has an essay about why you won't see any open source J2EE implementations, and Kodak has filed a patent-infringement claim against Sun regarding Java.

A number of people have submitted the press release from Sun Microsystems about their latest announcements in conjunction with Linux. Highlights from this one include the promised release of "New single- and multiprocessor systems, to be announced mid-year, will use the x86 architecture and be capable of running thousands of Linux applications natively." As well, they are expanding the Cobalt line of servers, but even more interestingly they are going to "freely offer" parts of Solaris - but no license specified that I saw. They are also releasing "ABICheck", which should check compatibility between Linux/Solaris. C|Net is carrying coverage now as well. And it looks like Lineo and SuSe are going to get competition in the embedded and telecom support area - I wonder if that's tied to the OSDL announcement. It's good to see that they are getting on the right track - now let's hope they stay the course.

iamriley writes: "According to this, Sun is making Gnome 1.4 available for customers 'to test drive, explore, and evaluate an early version of the GNOME desktop for the Solaris[tm] Operating Environment, SPARC[tm] and Intel Architecture Editions.'"

eyefish asks: "Is Microsoft's Common Language Runtime CLR (document in PDF form) really a way for Microsoft to slowly stop depending on hardware vendors like Intel to drive the Windows platform, and in the long run as a way to build a hardware-independent Windows platform to fight Java? I'd like to ask the Slashdot community what their thoughts are on this matter. Is there something preventing the CLR from being truly platform independent, now or in the future? How does it compare to the Java Virtual Machine?"

"It seems to me that once the CLR has matured enough, there won't be a need for Microsoft to wait for others to innovate on the hardware front and start offering its own hardware (and charge whatever it wants for it) to go with future versions of Windows.Net. Worst still, 99.99% of the population will not be able to say no to this strategy since they'll have no choice but continue using the Windows monopoly in order to run their favorite apps."

Jamie comments: I don't think it's about hardware innovation, or beating Java. It's about absolute control.

The big money over the next decade will be in transforming the computer into an entertainment device. AOL Time-Warner sees a computer as a revenue producer, with the unfortunate ability to copy digital works. They and the other five media giants want to put a stop to it; Microsoft and Intel will find it very profitable to help them.

One good step along the way is to give the computer a common interpreted language to run everything. We're there already. And when developers have to code to a virtual machine, not the actual bare iron, then whoever writes the virtual machine holds all the cards. And since the authors of the virtual machine will make a lot of money by enforcing intellectual property rights, the arms races are all over: copy protection is absolute, DeCSS won't compile, unauthorized MP3s won't play.

Of course developers rarely write on the bare metal anyway: we write to APIs, we write scripts, we write code that doesn't (need to) run in the CPU's supervisor mode. We're used to surrendering the ultimate control over the machine to the operating system, or to be more precise, to the BIOS that decides how and which operating system to run.

If we surrender this control, though, we'll find ourselves with a monopoly operating system that makes it impossible freely to write code for. (And it's not hard to cut off Linux and every other rogue free OS at the knees. The day that every motherboard's BIOS uses strong crypto to demand the master boot record be signed with a secret key known only to Microsoft is the day that Linux becomes a thing of the past.)

Naturally, to prevent you from firing up GCC and doing a rogue compilation of DeCSS or Lame or other unauthorized code, the operating system will have to stop you from running anything that isn't written in its language for its virtual machine. Requiring code to be signed by a central authority will make its first appearance as virus-prevention but its real purpose too will be control. Universities will be able to buy special licensed exemptions, at least until corporations decide universities are hotbeds of piracy and theft. At which point your alma mater begins teaching Computer Science 101 (and 201, and 301, and 401) in C#.

My prediction is that, unless antitrust legislation in the U.S. gets some teeth between now and then, the PC will become a Gameboy within fifteen years. Enjoy computers while they last.

eyefish asks: "Is Microsoft's Common Language Runtime CLR (document in PDF form) really a way for Microsoft to slowly stop depending on hardware vendors like Intel to drive the Windows platform, and in the long run as a way to build a hardware-independent Windows platform to fight Java? I'd like to ask the Slashdot community what their thoughts are on this matter. Is there something preventing the CLR from being truly platform independent, now or in the future? How does it compare to the Java Virtual Machine?"

"It seems to me that once the CLR has matured enough, there won't be a need for Microsoft to wait for others to innovate on the hardware front and start offering its own hardware (and charge whatever it wants for it) to go with future versions of Windows.Net. Worst still, 99.99% of the population will not be able to say no to this strategy since they'll have no choice but continue using the Windows monopoly in order to run their favorite apps."

Jamie comments: I don't think it's about hardware innovation, or beating Java. It's about absolute control.

The big money over the next decade will be in transforming the computer into an entertainment device. AOL Time-Warner sees a computer as a revenue producer, with the unfortunate ability to copy digital works. They and the other five media giants want to put a stop to it; Microsoft and Intel will find it very profitable to help them.

One good step along the way is to give the computer a common interpreted language to run everything. We're there already. And when developers have to code to a virtual machine, not the actual bare iron, then whoever writes the virtual machine holds all the cards. And since the authors of the virtual machine will make a lot of money by enforcing intellectual property rights, the arms races are all over: copy protection is absolute, DeCSS won't compile, unauthorized MP3s won't play.

Of course developers rarely write on the bare metal anyway: we write to APIs, we write scripts, we write code that doesn't (need to) run in the CPU's supervisor mode. We're used to surrendering the ultimate control over the machine to the operating system, or to be more precise, to the BIOS that decides how and which operating system to run.

If we surrender this control, though, we'll find ourselves with a monopoly operating system that makes it impossible freely to write code for. (And it's not hard to cut off Linux and every other rogue free OS at the knees. The day that every motherboard's BIOS uses strong crypto to demand the master boot record be signed with a secret key known only to Microsoft is the day that Linux becomes a thing of the past.)

Naturally, to prevent you from firing up GCC and doing a rogue compilation of DeCSS or Lame or other unauthorized code, the operating system will have to stop you from running anything that isn't written in its language for its virtual machine. Requiring code to be signed by a central authority will make its first appearance as virus-prevention but its real purpose too will be control. Universities will be able to buy special licensed exemptions, at least until corporations decide universities are hotbeds of piracy and theft. At which point your alma mater begins teaching Computer Science 101 (and 201, and 301, and 401) in C#.

My prediction is that, unless antitrust legislation in the U.S. gets some teeth between now and then, the PC will become a Gameboy within fifteen years. Enjoy computers while they last.

As promised chrisd back with his report from the expo floor at MacWorld and a brief note about what Linux can learn from the Macintosh. Walking the show floor at MacWorld, I'm beginning to feel a little sorry for people who are Windows boosters. Where do they go for their community? The Mac folks have MacWorld and WWDC, we have LinuxWorld, O'Reilly and Usenix, but they have what? Comdex? There is no MicrosoftWorld. Whether this is a result of their size or what, I couldn't tell you. But there is a similar feel that the "Linux Faithful" and "Apple Faithful" share and that is that we are clearly part of a user and developer community.

Yesterday, I reported on the Jobs keynote and his ability to expand his reality field to encompass and entire ballroom. Today, do people still feel energized by his talk? Some were still pumped just to a part of the show, gasping and oo'ing and enjoying the melodrama of it all, but the next day there was a collective vibe of "well, was that it?". This is not to say that they were disappointed by it, but they perhaps wanted something more. The rumors had been flying for months about a flat screen iMac, and since that was what Apple brought forward, it was going to been seen as an evolutional, and thus anti-climactic, step, even if it was daringly packaged.

Many noted that they were expecting a speed bump for the G4 towers, but with Seybold coming up in February, many expect Apple to announce their tower update then to a more professional audience.

At the Tuesday keynote "The Power of X", Phil Shiller and Avie Tevanian talked about OS X and what it means to apple and to the future of the Macintosh platform. Apple is stressing how stable and crash proof OS X is and what this can means to the "Apple Faithful". They discussed the kernel, the media layers, security and the user interface and how it all works together. What they've done with their BSD derived core is really impressive. As part of the keynote, Tweak Films showed off an OS X based deep ocean wave visualization app that they assert they ported from Unix in weeks, with significant functionality gains.

The show floor itself was bouncy fun. For me it was a nice change from the austerity of a Linux exposition and it's focus on sheer functionality, capability and commerce. Large exhibitors included Alias|WaveFront, Adobe (not having anyone at this conference arrested, I noted), FileMaker pro, Microsoft and a number of other software development houses. As I walked the floor, I made a mental note of applications that were available for both Windows and the Macintosh. The reality is that there isn't much that is specifically for the Mac intosh, with the obvious exception of the hardware from apple, with all the vendors one ends up asking, what is unique here?

What Apple has that is unique, and sadly Windows and Linux both lack, is cohesion. Everyone with devices and software for the Mac seem to work so well with each other and the OS. We should strive to emulate that cohesion whenever practical for open source software. Before, the apple story was cohesion without stability or power. Now, with BSD at it's core, you can bet that Apple will be able to attack Windows, SUN and Linux on the power front. A year from now it will be interesting to see how many people are running apache to serve pages from their Apple machines, and I will be unsurprised if someone is giving an apache serving presentation at the next Apple WWDC.

Please note that I have posted some pictures of my trip to MacWorld, with some pictures of the new iMac and of the keynote.

Slashback this evening brings you news and updates on several previous stories, including (not limited to) @home service, Linuxgruven, and some followups to Slashdot book reviews.

More news you can use on the @home front. Anubis333 writes: "After a while talking with customer support, I have learned that Comcast@Home (Soon to be ATT Broadband) has instituted a network-wide cap on user upload to 15KB! (Thats not much more than dialup) Also, they have now capped Usenet news access. What am I paying 50 dollars a month for again? More info on usenet here.

Upon even longer hold times, I found out that when Comcast switches over to ATT the cap will be set to 128KB and the usenet caps will be lifted, also they will support more groups. The full change over will be complete by the end of Feb. Any users in the Savannah Ga. Area, they will start here Jan. 15 and end in early feb. Call support for exact local dates if interested."

Yessir, about oh, yea big by a few more inches ... Dave contributed a link showing a side-by-side comparison of the current Apple laptop line, including the new bigger iBook. Shame about the resolution, though ...

By their fruits ye shall know them. zsazsa writes: "According to the St. Louis Post-Dispatch, Missouri Attorney General Jay Nixon has sued James Hibbits and Michael Webbs, the two founders of Linuxgruven for deceptive business practices. He alleges that interviewers were actually salespeople paid to enroll job applicants in training programs costing up to $3,150."

Would the FSF call Sun "GNU-minded"? maitas writes: "It seems that Sun has removed Solaris for Intel from its free download list. It's really sad to see a company that promotes its 'GNU minded' culture to go back on the few good things it had made. They even removed the Solaris source code from their site! Sad, sad, sad."

That them thar' book larnin' Stardance points to an interview at Salon with Steve Grand, in which the "designer of the artificial life program 'Creatures', talks about the stupidity of computers, the role of desire in intelligence and the coming revolution in what it means to be 'alive.'" You may remember Grand's book Creation: Life & How to Make It, reviewed on these pages. Speaking of reviews, several readers have contributed links to the New York Times' review of Lawrence Lessig's new book.

Gerard J. Pinzone queries: "My company is looking to implement C/C++ and Java coding standards. However, I can't seem to find a definitive list. I'm more familiar with Java and have suggested that we use 'Elements of Java Style' and Sun's documentation. BTW, beware of 'Netscape's Software Coding Standards Guide for Java.' It's woefully out-of-date! Any suggestions?"

Reader samjam sent in an interesting piece about his dream handheld PC, sort of a cross between a subnotebook and a wireless web pad, with the kitchen sink thrown in. Mmmmm, light-emitting polymers. I can't decide if this kind of thing is right around the corner or just a fantasy - after all, normal notebook computers sell, and at a nice high premium - and web pads are less than successful - why would anyone spend the money to develop a device like this? samjam writes: "My dream handheld is not available though some things come close. The technology is becoming available.

Though it may take a few months, here is what I would put together if I had the chance. Including Bluetooth, IButtons, solar panels and light emitting polymer screens...

For links to other linux handhelds, try linuxdevices.com.

My ideal handheld is the size of an A4 pad of paper, so I have to hold it on my left forearm with the fingers of my left hand curled over the end. A4 gives me plenty of screen space for watching real TV, reading real books, writing real emails, browsing real web pages and doing some real showing off.

The front cover is a solar panel, but I can't decide if the cells should be on the inside or the outside to help charge it while I use it or while I'm not using it. Hard one that.

The screen is not heavy-breakable LCD but LEP (brief technical primer, more on Google) or perhaps Xerox Electronic Paper seemingly available under the name Gyricon, pictures here and slight details here.

The choice of processor doesn't bother me much; I'd like to think there are many versions available of my handheld by many manufacturers (to drive the price down) and so many processors will be available but let's pretend the first release will run on a Transmeta just to keep excitement running high.

60 GB or so should be plenty of disk space, 2.5" IDE to keep weight down.

Input via stylus or sticky finger of course, with support for Graffiti, as used on the Palm and many others, also Quickwriting as featured on Slashdot as well as regular handwriting recognition (take your pick) and other pluggable input modules with popup keyboard for those times when you just can't manage to input a tilde (~) or backtick (`) properly.

Connectivity will be provided via a multitide of USB ports (where real keyboards can be plugged), Bluetooth (useless link) in action (good link), wireless ethernet as well as perhaps as many as 4 PCMCIA slots for things that change a lot like GPRS adaptors &c, or radio and TV tuner cards. Yeah! Why not add some Compact Flash while I'm at it? And boring 100 base T ethernet.

In fact I'm going to use the mobile phone card, along with my sound system to make the whole thing into a mobile phone for voice, not just data access. Talking of phones, the built in web cam can be used for video conferencing with (for example) Gnophone.

Better stick some firewire ports on there, too, for good measure, along with a few IRDA ports pointing in a few different directions for those more subversive inter-classroom networks as well as controlling my grannies telly to show off. And talking to my old non-bluetooth mobile which I can't afford to upgrade cos I spent it all on my handheld.

It will have integrated Ibutton support for security and authentification, maybe even built into the BIOS.

What more do I need? Oh yes, an Operating System. Pick your own.

I shall be running Linux with Ximian Gnome because it looks cool (and Bill Gates was nearly right, eye candy counts for a lot if only not to distract you by means of ugliness). I will be running redhat because I find up2date (or redhat channels of RedCarpet) invaluable effort-free way to remove those exploits, and I will finally get round to playing with Rebol.

The first thing I will need to develop is some network scavenging software to grab internet connectivity where it can for syncing imap folders and news, updating "offline web pages" [yikes! MS concept there]. Code to hi-jack available SMTP relays (*cough*). Does this smell a bit like Jini or something like it? I'll need to register my changing location for Gnophone so callers can find me. Perhaps the first thing for company visitors in the future will be to checkin their Ideal Handheld to the company network.

I will load all my favourite books into it as well as the entire classical Mormon works, copies of conference talks Doctrines of Salvation, Journal of Discourses etc, along with the Bible, Book of Mormon, and all of Project Gutenberg.

What will you do with yours? Have I missed any gizmos out? Or gadgets even?"

no parity writes "Last year on October 13, much of the source to Sun's StarOffice was released as the OpenOffice project. They have set up a birthday page to celebrate what they have achieved in that one year - yes, it prints, spellchecks and has online help. Keep up the good work, guys!" Yep - and my installation still spits up, too. *grin*

kevin@ank.com was there last night when "Max Lanfranconi of the OpenOffice project spoke to the Silicon Valley Linux User Group on Wednesday morning's release 6.0 of the LGPL'd office suite. When the project was opened two years ago, it was missing online help, spell-checking, and printing which had been based on proprietary commercial libraries. With release 6 the open source community has replaced these missing features." Read on for some more information on the new release, courtesy of Kevin.Update: 10/04 22:11 GMT by T : Several readers have pointed out that the 6.0 release is actually the beta of StarOffice 6.0. Though StarOffice is based on OpenOffice code, there's not actually a new build of OpenOffice yet. OpenOffice's is currently at build 638.

"Release 6 also gets rid of the old Star Office desktop of version 5 which was generally disliked for its annoying tendency to cover up all of the other windows you were working with and make it difficult to interact with your X Window Manager.

The application suite has programable APIs for each of the applications, exposed through a custom object request broker named UNO. In an impressive demonstration, Max showed live update of a spreadsheet with real-time stock data, all under the control of a small Java application. Changed data were reflected throughout the spreadsheet table with each update as the sheet recalculated each cell based on the new input.

Max freely admits that there are still weaknesses in the code. He pointed to the ten year lifespan of the mostly C++ code base, and hopes to see the code improved with the use of more modern C++ features. In browsing through the source tree I don't find that the code is in nearly as bad shape as Max portrayed it. Admittedly I've only seen a tiny fraction of the code (at 3.7 million lines, OpenOffice is by far the largest open source project in the world), but my random sampling showed very good coding practises, like preprocessor guards around each header include to reduce compile time due to reopening headers that have already been processed. Even with these measures in place however, the full system takes upwards of 15 hours and 1.5GB of disk to build on currently available hardware.

System load time for the office suite has been significantly reduced (about 20s on Max's 500MHz laptop with 128MB memory) by removing several libraries from the link process and instead loading them on demand. Over the next year or more Max hopes to see more modularization of the code base with the eventual goal of seperating the monolithic program into seperate applications linked together through an object request broker.

Q&A went on until we got kicked out of our room, so there is a lot more that is new about OpenOffice than I've described here. If you are interested you can pick up a copy at OpenOffice.org, or at one of its mirrors around the world."

Lumpish Scholar and 753 other people wrote in to let us know that Sun has released its beta of Star Office 6. CNET has a blurb about the release as well. I was hoping that Sun's site might be unclogged enough to try it out myself, but that doesn't seem to be in the cards today.

SilentChris writes: "Sun has released the Starcat server, a beast with up to 106 processors running Unix. Anyone have an extra couple [million] bucks lying around?" They're not cheap.

SilentChris writes: "Sun has released the Starcat server, a beast with up to 106 processors running Unix. Anyone have an extra couple [million] bucks lying around?" They're not cheap.

SilentChris writes: "Sun has released the Starcat server, a beast with up to 106 processors running Unix. Anyone have an extra couple [million] bucks lying around?" They're not cheap.

andyfsu99 inputs: "Recently I've noticed the increasing confusion between Java the language and Java the platform. Recruiters and project managers routinely ask for a numeric "rating" of a developer's Java skills. Do they mean Java the language (OO concepts, syntax, libraries, etc)? Or Java the platform (EJB, JCA, JSP, etc)? How do you answer this question? Clearly, Sun is pushing the platform definition. How will this effect the evolution of emerging techologies like C# and .NET? Will major new languages be forever coupled with platforms moving forward?"

Ur@eus writes: "Ever since Sun joined the GNOME Foundation people have been wondering exactly what they have been working on. To solve this we have done an interview with some of the people Sun have working on GNOME. The topics discussed include the background for Sun choosing GNOME, Accessibility, Useability and more. You find the interview at Linuxpower.org."

tnorbye writes: "On Sun's Intel site today there's a link to a new XFree86 porting kit. Essentially, you can download binary XFree86 drivers which run with the Solaris X server! So any graphics card you can use with Linux you can now use with Solaris. Sure makes Solaris x86 more widely available!"