Slashdot Mirror
A Java-Based Handheld OS
William Tanksley writes "For all those not yet tired of Java: Aromasoft has announced a Java-based OS for handheld devices, Teapot. It's allegedly Personal Java 3.0 compliant, and cleanroom engineered (which probably means no Sun code, although I'm not certain)." Is it just me, or is everyone working on a really cool Java project, and dismissing Sun at the same time.
There are tons of cool Java projects, but no, I don't see people dismissing Sun, except a few armchair critics on Javalobby and Slashdot.
Sun has done a lot for the community, and continues to do so. They've made PR mistakes, but so does every company. Instead of mulling over political agendas, let's look at the results:
- JDK 1.3 is a massive improvement in client side performance, since most of Swing was optimized and Hotspot 2.0 client VM came out. This is a tremendous success.
- The J2EE is really catching on and addressing some of the original concerns of doing cross-platform enterprise applications. EJB 2.0 actually does a lot to improve upon the way it integrates objects with databases. The COM bridge will allow us to talk to EJB apps through Visual Basic (which is crucial in the business world). All in all, job well done
- The community has never been bigger or better. JavaOne continues to be the largest technical conference in the world, with over 25,000 attendees -- almost quadruple the Microsoft PDC attendence figures. The community process continues to get new specifications added to it, while Sun focuses on bug fixing and "depth" issues as oppsoed to "breadth" issues. JDK 1.4 will be another "fixes + optimization" release, once again showing that Sun wants this thing to be SOLID.
I really don't give a crap if Java is an ISO or ECMA standard. It took C++ until 1998 (freaking 1998!!) to become an ISO standard. And there STILL are major compiler and library discrepancies 2 years later.
The fact of the matter is that I can write a large Java distributed system much faster than I can write it in C++, and it will be overall less buggy due to a lack of memory leaks, pointer smashes, and better exception handling -- plus the fact that I can buy one of several solid application servers for Java. In C++ I can't do that, I can only really use Windows 2000/COM+ or BEA Tuxedo, or roll my own. If I need access to the VM source code, I have it available to me, though there will rarely be the case where it's the VM at fault, and not my code.
Plus, server side Java code has been shown to be, at times, faster than optimized C code:
Click here for graphs plus source code..(Note to take the benchmark with a huge grain of salt. run it for yourself.. be sure to change his baseline numbers in the source code to match your own baseline.)
Java is a very pleasant language to work in. It's not the best -- I'd prefer Smalltalk -- but given the market climate, and the vast selection of tools and server products, it's quite livable if you love object oriented design.
-Stu
Is it just me, or is 1.3 megs a little large for a handheld operating system? I have never owned one of these little devices, but it seems to me that they are already suffering from Operating System feature bloat.
Think about it. You could easily run an older version of DOS that fit on a 360k floppy, Im sure Linux can be scaled down that low too. Where is all this extra stuff coming from?
Since there is the same type of hardware going into each of these, why don't they just get rid of the crap we don't need. That 1 meg of memory is important!
Am I the only one who sees some parallels here with the control that Linus has over the direction of the Linux kernel... he wants it to be open but still keep control of the direction that it takes.
Linus has control because the community as a whole wants him to be in control. Unlike Sun, he put nothing in the license that grants him that control. You are perfectly free to take the latest 2.4.0testx kernel and fork the code. You will control that fork as Linus controls his. It's just that nearly everyone will use his version unless you come up with something REALLY extraordinary.
There IS RT-Linux. It is a fork and not under Linus' control. It is only used by people who need the specialized features it has.
Just in case anybody is equating PocketLinux with Teapot, just because they sound very similar on the surface, I'd like to point out some differences.
1) PocketLinux is GPL'd. Teapot is not. It looks quite proprietary to me.
2) PocketLinux is available for download now. Teapot is not.
3) PocketLinux runs on currently available hardware, and any hardware that runs Linux into the future. Teapot doesn't seem be available for any shipping PDAs.
4) PocketLinux has screenshots on the website. Teapot doesn't.
5) PocketLinux was released last week. Teapot seems to have been announced in 1999, but there doesn't seem to have been much action since.
We've put a lot of work into PocketLinux -- it ain't vapourware (we just didn't get much documentation up yet). Check it out.
No, I'm sick of a language making me buy and pay for synchronization when I may neither want nor need it.
... but that's hubris. Do we stop a good thing just because some people abuse it? That's burning the house to roast the pig.
You don't pay for it unless you use the "synchronized" keyword. period. One should never used that keyword unless they have good experience with concurrency.
You cannot get around using your head on threads, and when you do, C++ will be a much more satisfactory choice.
C++ has no inherent support for multiple threads. Pretty much everything is done through an OS api. Note that many people feel that API-based multithreading constructs are MUCH more unsafe and error prone than something that is inherent in the language. [On a tangental note, I believe there's actually academic research that suggests this as well.]
I look at WinNT's threading model and I cringe at the lack of consistency. Sure, it gives me a lot more choice in IPC constructs, but they're all quite painful to use. System V's IPC is a bit better, but still not as consistent & simple as monitors.
Find me ten average Java programmers who can point out the synchronized objects and the non-synchronized objects they are instantiating.
I'm a half consultant/half trainer in C++, Java, etc. and I get to deal with a lot of variation in levels of comprehension and competence. One thing I'm pretty certain of is after they make it through my class, they understand that A) all of the Java 2 collections aren't thread safe, and B) we shouldn't use the Java 1.1 collections because they ARE thread-safe and are, hence, slower for no good reason. They may not understand *WHY* synchronization slows stuff down, but they do understand that it does.
I can fully understand your complaints about the Java 1.1 Vector & Hashtable being synchronized with no choice in the matter, but that changed quite a while ago with the release of List, Set, and Map. Furthermore, String, which you alluded to in a prior message, is *not* synchronized because it is immutable. StringBuffer *is* mutable, so it is logically synchronized. One tends not to use StringBuffer all that often for this reason. This is pretty much identical to the way NSMutableString and NSImmutableString were designed in NeXTStep.
To this my response is that yes, straight C makes stack smashes a reality. C++, when used with the standard libraries, can correct this issue.
C++ corrects this? How? I can still take the address of a stack allocated object and it still will smash. A good C++ programmer would never make this mistake (they'd use new, and they'd actually read the compiler warnings that scream at me for taking the address of a local variable), but a newbie might make this mistake (because they don't understand compiler warnings that well).
I would also say that this sort of bug is much more debilitating than newbies making mistakes about synchronized keywords. One makes your code slower, one makes your code crash with a seg fault.
Added to which, generic programming is entirely more useful than OO, and C++ is the only language the implements it usefully.
Look, I've read your prior messages and your rants against OO, but let me make something perfectly clear: just because you have a hard time making a paradigm-shift in thinking, that does not make that paradigm mumbo-jumbo.
There are many people that like OO but also detest "UML myopia" and "top heavy" methodologies that just generate lots of paper. These people tend to flock to more pragmatic approaches such as extreme programming. I like OO because I can create simple abstractions when I need to, and complex ones when I need to. The patterns movement is also a great body of literature to learn techniques from. Again, it's a tradeoff in that it allows newbies to think they're design gods just because they can cram 15 patterns into their systems ("look ma! I can use a visitor here, and a chain of responsibility here! it's 15-class, 150 line hello world with 6 levels of indirection! aren't ya proud??")
Choosing a multi-paradigm approach has its trade-offs, just like choosing a single paradigm. With the multi-paradigm approach, you have to be extra good at providing readable constructs and abstractions because you've effectively thrown consistency out the window. You'll need a patient programmer versed in several paradigms to be able to maintain your code. If you pick ONE paradigm for a system, though, you at least have consistency and readability on your side.
One should not choose a multi-paradigm approach for just performance reasons, as this reeks of premature optimization. I feel profilers are a must in *ANY* paradigm.
Now, on to generics. Generic programming is quite useful, and actually I would say LISP and Modula-3 do it better than C++, but I digress.
Generics is a different paradigm from OO -- and I wouldn't say it's more or less useful in general over OO. Alexander Stepanov may think so, but Stroustroup certainly doesn't, reading his arguments in favor of OO in his books on C++.
In some cases, generic programming is definitely needed, such as when you want to implement generic mathematical functions for matrix arithmetic in a large numerical computation system or simulation. Those situations warrant generics.
Beyond the above though, compile-time type checking of containers is not what I call "entirely more useful" -- it's more of a "nice thing to add". Java takes an 80/20 approach where it gives you strong typing most of the time, but basically takes the Smalltalk approach to collections/containers. This line of argument tends to degenerate to the classic strong vs. weakly typed polymorphism & language debate, so I'll leave it at that.
-Stu