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.
JAVA CAN BE COMPILED. Repeat this to yourself 5 times every day.
A deep unwavering belief is a sure sign you're missing something...
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
JINI is not part of the Java SDK given away for free - its part of their enterprise suite, and they charge a 5+ digit licensing fee to redistribute it in a commercial product.
Furthermore, unlike other API's in the enterprise suite, JINI is not provided as an interface that anyone may implement. Sun has patented some critical aspects of it, and has stated they will defend that patent.
There exists at least one open source JINI clone that is being held by the authors until the patent issue is resolved.
Until something changes, JINI is for corporate use only.
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!
What Windows CE did you use to say that it's "bloated as hell"? As far as I can tell from using it, it's rather lean for the incredible range of functionality it has. I doubt if there's any more code in WinCE than there is with the linux + X distribution I saw on the iPaq. It does all sorts of stuff and is far more versatile than PalmOS.
Just because you like the PalmOS for its simplicity doesn't mean everything that's larger and more functional is "bloated as hell." I seriously doubt you've ever used WinCE...if you have, I doubt if you would claim that it's bloated. I love WinCE for what it is, and I think PalmOS is magnificent for what it is.
WinCE is not crap.
Not everything from Microsoft is bloated by default. Get over it.
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
The KVM and Waba Virtual Machine (as well as others i'm sure) let you run java programs on PalmPilots. Both of these products also have CE versions, meaning that you can develop the same app for your CE and Palm devices.
IMHO it's by far the fastest way to prototype any app on the PalmPilot, and while speed of execution doesn't compare to C, you get a good looking application in minimal time.
I used Waba to display a quick n dirty java GUI on a 1MB Pilot Pro - went from knowing nothing about Palm development to done in a couple of hours, and that caused the jaw of the guy who does CE development here to hit the ground real fast.
the Waba VM weighs in at under 80k, and a typical Waba app would take between 5 and 50k.
Thats noticeable on a 1MB Palm unit, barely noticeable on a 2MB Palm unit, insignificant on an 8MB Palm and miniscule for a 32MB CE device.
My current development work is on a GUI-oriented Java project with a servlet backend, intended for desktop computers, but i know that i can easily port it to a Palmtop whenever i like with minimal hassle.
Our customers will flip when i show them the app running over a wireless link from a CE handheld and a PalmPilot using a GSM modem.
Java, despite Suns mishandling, really does have the potential to shake up the entire industry, and make programmers lives a lot easier, especially in the handheld space.
I gots ta ding a ding dang my dang a long ling long
Java is dead on the client - deal with it - Sun has. Compare Java client code to even the crap that runs in Macromedia plug-ins, and there is no comparison.
Flash is a much better web-GUI technology than an applet for vector based animations. So yes, applets-for-animation are pretty much toast.
However, Sun has most definitely not given up on this, though certain factions within Sun probably have.
A document metaphor, and the DOM itself, only goes so far. Not every interface is a web interface, though it may be internet-enabled (See Napster). Java Swing potentially has a future here, mainly because of "Java Web Start", which will allow full-featured Java applications to be web-distributed, similar to the Add/Remove Programs control panel in Windows. This is a great idea, especially for intranet applications that need centralized version management.
I'd really suggest you look at the JDK 1.3 and the speed of the GUI. Take the IBM virtual machine out for a spin too. There have been some great strides.
Oh be real - these benchmarks are all using in-memory operations on scaled data sets. Show me some real-world tests - graphics, user input, networking - and watch Java come to a crawl. These are the same types of useless benchmarks that HotSport advocates have been tossing around. They're cute, but no one is going to bet their job on matrix transformation benchmarks (if they want to keep their job).
Real world apps? Check out www.instinet.net. It's a worldwide fixed income trading system. It's positively huge. And it's completely Java.
Nike replaced an HR system with Gemstone in 1998.
Charles Schwab is writing all of their systems in Java, and currently has over 100 new projects on the go (according to their VP of technology, at JavaOne. Check the slides, they're online).
I wrote a backoffice system in Java (Gemstone) running 200 tps on a rather low-end Sun machine (Ultra 10).
The fact of the matter is that Java is doing just fine on the server. Performance complaints really aren't warranted here for business systems concerned with mainly I/O performance.
Java on the client continues to need more work, but again, there have been great strides here.
Are these hard scientific numbers? Probably not. I think you'd be pressed to see hard scientific numbers on any in-house app whether C++ or Java, just because they are "in house".
Uggh! I strongly disagree. How verbose can one language be? I can crank out useable solutions in perl in a quarter of the code, and they'll likely cream the Java performance as well (Hotspot included), and I'm not talking about matrix transforms or Fibonacci sequences.
Perl's raison d'etre is to be able to write applications fast, but to care less about their maintainability (i.e. readability). Java, on the other hand, is meant to be read over again because most software is in perpetual maintainance, with NEW people coming in to maintain your old code.
Some people's careers are made up of fixing other people's shitty, unreadable code. It doesn't have to be this way. Java encourages people to write somewhat readable code, though it's up to the person to go the distance.
I also really question your perl performance statement. Try it against the IBM virtual machine or Hotspot 2.0. Really. This is interesting given that Java has some impressive 3rd party regex packages now.
Also, Java is about as verbose as C considering most of the syntax is taken from C. C is widely considered to be a fairly terse language, so your desire for more terseness (perl) is somewhat unique. Many people need to maintain code over several years, so they want fairly verbose code that has a clarity to it. Reading regular expressions requires a lot more concentration and is more time consuming than reading basic C code.
Beyond this, C++ is much more verbose (see templates). Try COBOL too.
The only verboseness problem I've really had is when using "anonymous inner classes" which can be somewhat obtuse at first compared to a Smalltalk block. Again, a fairly minor annoyance, it's two extra curly braces...
My major problem with Java is it tries to make threading useable by people who have no idea what threads are or why or when they should be used. Like attaching a thread to each Socket, or synchronization of strings.There is no such thing as "threading for dummies" - try going this route and you actually get a massive performance degradation.
I never got this impression at all. The "book" on Java multithreading (Concurrent Programming in Java, 2nd ed, by Doug Lea) is *not* for beginners.
Java makes the simple things in threading fairly easy (mutexes), and the hard things possible (using monitors). I would have preferred if they actually used a FIFO/priority queue for their blocked threads as opposed to an unordered queue but that's a small annoyance.
Furthermore, the Java 2 collections and Swing are all naturally not thread safe precicely because they don't want to encourage multi-threaded programming. They only want experts to use it. Sure, you they provide convenience methods to fully-mutex a collection, but obviously if you're going to write an application that deals with millions of objects in a Set, you're not going to use a fully synchronized collection.
What you seem to be saying is that you're angry with Java from abstracting the low-level too much. But, what about the experts who are SICK of the low level stuff, SICK of twiddling bits, and just want to get their job (of coding business logic) done? That's what Java allows. This trade-off also allows newbies to think they're all smart & powerful, but that's something you just have to deal with if you want the increased productivity of a high level language. Just life.
I just don't see how you can blame Java's attempt at trying to make the lives of experts easier for causing newbies to think they are multithreading gods. I don't think any technology is responsible for building such hubris.. it's just a human thing.
As for Java performance - look at the language! All that threading, OO support, etc. that is built-in, and all that object churn you don't even know you're incurring - they're part of Java and result from the ridiculously verbose syntax. You're never going to get rid of this degradation.
How wouldn't you know what you're incurring? You're writing the app, aren't you? There are such things as profiling tools.
Threading is a purely optional, so you wouldn't normally incur its overhead unless you decide to synchronize everything.
OO support is inherent in the language, so you're going to incur runtime method dispatch overhead no matter what. If you don't want this, why are you using an OO language? Furthermore, dynamic dispatch is about as minimal an overhead as one can get, so it barely registers as a complaint beyond the realm of hard real time systems.
Memory allocation is definitely costly, on the other hand, but is much less prone to errors than stack-allocation of objects in C++. (Pointer smashes from passing around stack-objects that went out of scope a long time ago is a nasty, but common, occurence when you have free reign with memory addresses in the language.)
Again, profilers can find your bottlenecks so you can create some object-reuse factories to prevent the re-creation of too many objects.
I still heartily endorse the use of C++ for large scale code. Its open, it performs, and it doesn't make you pay for features you don't use. Its intelligently designed, and designed for intelligent people. Admittedly it has a learning curve, but anything worthwhile does.
Java's got a bit of a learning curve too -- it requires one to unlearn a lot of the debilitating habits we've picked up by being obsessed with memory locations and pass-by-copy semantics in C++.
C++ is a good language if you need a hybrid form of development - meaning you've got a system that needs low-level semantics and high level ones. But there's a trade off for this flexibility - it takes you longer to write stuff, it'll probably be more error-prone due to manual memory management, pointer errors, and a real lack of exception handling enforcement. It makes you focus more on the bits of the matter than the problem you're solving. In some situations, that's warranted. More often than not though, it's not warranted.
-Stu
Now this is off the top of my head...
- Personal Java(TM) runs on
- millions of settop cable boxes in the United States.
For more information on Cool Java Apps being deployed in the Real World (as opposed to some childish wannabe h4X0rs applet) check out Sun's industry news page.The Queue Principle