Slashdot Mirror
U.S. Army Testing Jini
ion-flux writes "Sun Microsystems said several army bases in the U.S. are testing Jini to quickly create tactical operation centers which control, execute,
and monitor battlefield maneuvers." No matter how smart you are, when you're under fire (literally) you can't deal competently with complex interoperability procedures. Of course, back in my Army days, we didn't even dream about things like Jini. Sure would have made our lives easier (and safer).
Um, if Nobody cares, why are you posting about it? (Unless, of course, you are the "Nobody" referred to in your post.) Otherwise, why are you participating in this little shared piece of our culture? WTF?
Geeky modern art T-shirts
I met a Brazilian a few months ago who was worried about how safe any American city was due to all the gunplay. The next day I saw in a newspaper from his Brazilian town that 30 people had died of gunshots in one day (no mention of how many wounded), and it was in the back of the paper with minor news. 30 is much more than most American states, much less their cities.
This article has seen a large number of subjective posts. Let's stick to the facts.
/.'ers realized this.)
JINI does not depend on a specific hardware platform, it only depends on the existence of a stable Java implementation. Now, many of us know that Java's AWT and Swing libraries have significant flaws and really can't be called stable by slashdot standards. But JINI does not require the AWT. As others have said, why would you want to surf the Web on your toaster? Even if you did, Win CE would take care of that for you. Win CE still uses WinMain(), I believe, which requires you to create a "window" before your application can be considered "behaved". JINI != Win CE.
Now what does JINI do, then? Well, start with the fundamentals of Java: multithreading, garbage collection, dynamic code loading, platform independence, decent speed, and stability (as long as you don't use AWT). Null pointers and buffer overflows are hardly an issue when Java is implemented properly. Now add to that the benefit of JINI: automatic and reliable networking. It sounds just right for an environment where you don't have time to make sure your targeting computer has downloaded the coordinates from your high-security digital messenger device. It has to work perfectly every time.
Now, let's look at where Java and JINI may fail. How big can a JINI network be before the devices start running out of RAM? Since any device can connect to any other device, each device on a "subnet" must know that each other device exists. If we went past the limit, would the whole network shut down? Would single devices mysteriously disappear? The military must consider this VERY CAREFULLY, because if the devices communicate via RF then it might be trivial for an enemy to shut down the network on a nearby ship just by broadcasting a few signals.
Encryption is very important in this application. Every device would have to have its own public-key encryption implementation. But in reality, that's probably a plus for the military since any device of this kind, JINI or not, would have to support strong encryption, and there are already plenty of pretty good Java encryption implementations.
(BTW--slightly related--I got that free FireCracker kit from x10.com and it's neat for controlling one light but if I used it for the whole house, anyone else who happened to have their own "clicker" could shut down all the lights in my house from 100 feet away. I hope most
I have to believe Linux wouldn't quite fit the bill. By the time the kernel and the required supporting utilities were slimmed down to fit into 128K or so, it would no longer be Linux.
A presentation on this subject was made at JavaOne. The PDF file with the slides can be found at http://industry.java.sun.com/javaone/99/event/0,17 68,742,00.html
Your arguments are true... but irrelevant. By extension of that logic everything would be written in assembly or C. However, while I'm truly a C bigot ;), I do write many little administrative tasks as shell scripts. People actually use Perl (gasp!) in web server applications. Need I point out that Perl "will always be slow compared to native alternatives"?
;)
Different tasks lend themselves to optimization for machine performance, speed of development, simplicity, manageability, executable size, portability, etc.
So, yes, Java will always be slow[er], but I guess I'm prepared to deal with it.
Geeky modern art T-shirts