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.

Comments

Re:Why on a handheld?

[be-fan]

JAVA CAN BE COMPILED. Repeat this to yourself 5 times every day.

Re:Troll? Facts!

[be-fan]

Actually, it seems that bash shell scripts are probably a good place to start. For those who are a little more advanced, a form of BASIC is a good idea. There is a thing on BeBeOS called BeBasic that lets you make BeOS GUI apps in BASIC. Though I'm not quite sure you could consider basic that much easier than C, it is a pretty good way to let users who have good ideas, but not much programming practice contribute to the BeOS community.

Re:All these PDAs.. i'll stick with my Palm

[Ranger Rick]

I think the difference that makes my PocketPC actually useful is WinCE 3.0's support for handwriting recognition. The thing that kept me going back to my Palm III when I had a WinCE 2.11 machine (took it back and got an iPAQ) is that text entry was *so* much faster with graffitti than the lame on-screen keyboard in WinCE.

But now they have handwriting recognition, and it just "happens" to understand graffitti, and all is well. :)

:wq!

Re:All these PDAs.. i'll stick with my Palm

[um... Lucas]

Sorry, but the desktop metaphor doesn't translate well to the palm of your hand. And what's a start menu doing eating up such valuable real estate? And 8 hours per charge? Please! I'll take my 5-8 weeks from a pair of AAA's any day over that.

The point of Personal Java is...

[SuperKendall]

However, the point of Personal Java is that you can write Java applications and GUI's that run on any small device. Is it not as desireable to write something once and have it run on as many small devices as possible?

Also, having Java on small devices makes Jini really possible - for example, you could have each stereo device Jini enabled and when a handheld was connected, each device could present a customized control panel on the handheld.

That's just one possibilty - there are other good reasons for wanted to be able to transmit classes between devices.

Re:Big operating systems...

[Kiwi]

Is it just me, or is 1.3 megs a little large for a handheld operating system?

I don't think so, considering that PalmOS 3.5 is 1.5 megs.

In that 1.5 megs, you get a really nice API that blows away anything a 360k DOS had.

- Sam

Re:Java still miles behind for production code

[Ars-Fartsica]

"Verbose syntax" doesn't cause performance problems,

Bullshit!!!

The compiler has to do something with all of those language elements. When you enter

Foo.bar.crap(crud), there isn't a genie in a bottle that comes out and figures out what you were trying to say - your statements get parsed with the presumption that you want all this object churn to happen.

Syntax matters. Yes, you can find "hotspots" in the code, but a JIT is not a magic wand. Try writing a compiler sometime and you'll appreciate the impact of syntax on compiled code.

Re:Java still miles behind for production code

[Ars-Fartsica]

What you seem to be saying is that you're angry with Java from abstracting the low-level too much.

No, I'm sick of a language making me buy and pay for synchronization when I may neither want nor need it. If a programmer doesn't know the difference, you have to wonder what their paycheck is for. I repeat - there is no such thing as threading for dummies. You cannot get around using your head on threads, and when you do, C++ will be a much more satisfactory choice.

How wouldn't you know what you're incurring? You're writing the app, aren't you? There are such things as profiling tools.

Find me ten average Java programmers who can point out the synchronized objects and the non-synchronized objects they are instantiating. Threading will get you poor performance when poorly applied. I would rather have the default be that it not be applied, as I don't want to pay for what I don't use.

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.)

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. Added to which, generic programming is entirely more useful than OO, and C++ is the only language the implements it usefully.

All these PDAs.. i'll stick with my Palm

[NinjaPaul]

It seems new Linux/Java/whatever PDAs are popping up all over the place, but I wouldn't even consider purchasing one until there's some serious 3rd party support for them.

I don't know about most of you, but I actually put my PDA to good use. PocketQuicken makes it incredibly easy to keep track of my check card usage/credit card usage and sync it all up to Quicken 2000 (yeah yeah I know it runs on windows, but hey when you've got 4 computers you can spare one.) I do a lot of travel on the job and get some pretty hefty expense reports, Quicken ExpensAble is the greatest app/prc combo out there for doing expense reports.

Windows CE is bloated as hell and I wouldn't ever consider running it, PalmOS is just perfect. It gives me a TON of functionality with a very speedy interface that doesn't have to clunk along when I switch from app to app.

So until one of these Java and/or Linux based PDAs actually give me the same features that I can get with my little itty-bitty Palm I think I know what my choice in handhelds is.

Re:All these PDAs.. i'll stick with my Palm

[jonnythan]

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.

Re:All these PDAs.. i'll stick with my Palm

[GregWebb]

Ever tried a Psion?

Ex-Palm user here. I moved because I realised I needed a keyboard (I was having to work on large documents too often for graffiti to be practical) but I have to say I wouldn't move back now. The system's just better. More powerful, more flexible. Also makes me realise how small the screen is on a Palm :)

I can't comment too directly on the apps as my machine's fairly old (original S5) but they're still pretty good. Yes, there are some things I miss, but not many.

If you get a chance, try one. Yes, they're a little larger. But I have to say the extra size is worth it. You get a better machine which made me realise just how compromised - and, in some ways, downright _cheap_ - the Palms are.

cool Java Projects

[Stu Charlton]

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.

Because Sun charges LOTS of $ for JINI...

[kbonin]

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.

A note about IBM and Oracle "support"

[Ars-Fartsica]

Firstly, I woiuld like to let you know that IBM and Oracle have succesfully jumped on and off every programming bandwagon of the last ten years.

Trust me - Java can vanish from Oracle as fast as it came...and this coming from someone who has the audacity to call others clueless - give me a break - you obviously have little experience with Oracle "support" of these passing-fancy technologies.

As for Servelets and JSP - Java has got to be the clunkiest page pushing platform I have ever seen. Compare the simplicity and power of PHP to the ridiculously verbose embedded Java solutions, and you really have to wonder who is making these decisions.

And what is with the ridiculous "tm" following each mention of Java??

Java continues to be what it always has been - a "for-idiots-by-idiots" language that will never perform and will always be ridiculously verbose to the point of pain.

Who cares, Jini is DEAD.

[Ars-Fartsica]

I can't wait to hear the response from Sun advocates - but let me tell you as a preemptive counter-response, that Jini adoption is going nowhere. Industry is still aching from draconian dealings with MS - they aren't about to enter into the same types of relationship with Sun.

Jini is dead folks. If you think otherwise, point me at one real world device that uses it.

Re:Who cares, Jini is DEAD.

[lgraba]

"I hope you can do better than that. Is this the same army that still uses Ada?"

Excuse me, the original poster asked him to name one product that uses Jini. He did so and now you say thats not good enough? For your information, the army has some pretty stringent requirements in the area they are applying Jini. They are targeting TOC's (Tactical Operations Centers) that are the brains of any size army unit. TOC's have to be very maneuverable; they must be ready to move within 20 minutes of being told to do so, and must be able to set up within 30 minutes of arriving at a new locations. With dozens of networked computers, the ability to plug them in and have them just work (provided by Jini) is a big plus, and not available via any other connection system.

Its easy to say something is dead. Giving a detailed analysis backing up this claim is more difficult. I doubt the poster could do it. Saying 'name one commercial application that uses it' is not enough (By the way, Mimio uses it on one of their new internet whiteboard products). How many applications can you name that use [fill in low level middleware product, such as CORBA]?

Java is not responsible for SUNW's rise

[Ars-Fartsica]

As an owner of a vast chunk of Sun stock, I am obviously happy that it has appreciated, but I'm not naive enough to think that Java has anything to do with it.

Its sales of Sparc boxes that are paying the bills over there folks.

Java: performance vs. safety

[jonabbey]

Ars (may I call you Ars?) is right.. using the Java APIs makes for a lot of object churn. Anything you do with Strings causes you to create temporary objects, anything you do with Vector or Hashtable can give you thread synchronization penalties on those JVM's that don't have efficient object monitors.

And that's the price you pay for a thread-safe system, absolutely. Strings are immutable to avoid security race conditions. Vectors and Hashtables are synchronized to try and guarantee safety in any possible threading context.

These are all class library issues, but it's fair to call them Java issues, nonetheless. All I can suggest is that safety is one of the most important factors in modern programming, and given that computers are still doubling in speed every eighteen months while they are not getting twice as safe at the same speed, I'd say that Java's tradeoffs for safety (and portability) are worth paying in many cases.

With Ganymede, I can have my server run indefinitely without crashing, despite the fact that the server has over 100,000 lines of code in it that we wrote, and at least twice that much again that Sun wrote. If errors come up, then that thread throws an Exception and everything else keeps going without so much as a hiccup.

For me, that's reliability worth paying for. Sure, C++ doesn't make you pay for features you don't use, but it makes you pay if even one line of code out of your program and its libraries has the slightest blemish.. one null pointer anywhere or one loop that goes one byte too far and the whole house of cards can come tumbling down.

Yes, with modern C++ you can use safer language features that encourages less risky coding and less pointer games, but you still run the risk that any piece of code is capable of corrupting any memory in your program's memory space, at any time. If you need the speed in execution more than the speed of development and debugging, then more power to you, but I'm certainly willing to let the computer pamper me a bit, particularly when my app can have all that safety and still run as very fast as it does.

--jon

Re:Why on a handheld?

[tagish]

Setting aside for the moment the fact that Java is a compiled language, the benefits of its much touted portability extend far beyond portability for whole applications. Code reuse across multiple platforms and multiple environments on those platforms is in many ways a far more significant advantage.

As a trivial example we have a simple HTML parser that, to date, we've used in an Applet, a stand alone application which runs on a number of platforms, a number of servlet based systems and in a Lotus Domino agent. We can do this because the same standard classes are available at runtime in all these environments.

Now you might observe that C++ also has a standard library, but for various reasons it is much less pervasive. I recently wrote some C++ to get Visio talking to Lotus Notes. At one point within the scope of a single function I was dealing with three different string types, none of which came from the STL. C++ is great for pure C++ applications, but increasingly developers spend at least some of their time writing glueware and if you do that in C++ you're quite likely to find out that more than 50% of your code is concerned with

• bashing strings from one string type to another
• duplicating functionality that exists in the STL but is not available here, now
• munging errors into exceptions and vice versa
• etc, etc

I've been trying to achieve meaningful amounts of code reuse for years, but it's only since we've started using Java that this has become a reality.

Usual disclaimer: YMMV. I'm not a language bigot; I've used Perl, Java and C++ today ;-)

Re:Java still miles behind for production code

[jonabbey]

Find me ten average Java programmers who can point out the synchronized objects and the non-synchronized objects they are instantiating. Threading will get you poor performance when poorly applied. I would rather have the default be that it not be applied, as I don't want to pay for what I don't use.

Well, sure, threading will get you poor performance when poorly applied. But the fact that many classes in the Java library are synchronized won't necessarily give you bad performance. Sun's Java 1.3 VM's can call unconstested synchronized methods with almost no penalty.

The most common thread-synchronized classes that Java programmers most commonly use are the Vector and Hashtable classes, both of which now have non-synchronized variants in the 1.2 Collections API, for those times when you have higher-level thread synchronization being performed.

Surely, if your 10 average Java programmers are not savvy enough to know the difference between synchronized and non-synchronized, though, then it is probably for the best that the most classes they'll reach for most commonly will be synchronized. That'll keep 'em out of trouble long enough for them to learn the difference.

Sun-bashing

[mckinlay]

I don't know.. I mean, credit where credit is due, Sun created Java, but they want it to be an open standard *and* have control at the same time. Call me a cynic, but I don't buy that.

I think that far too much Sun-bashing goes on, granted, but if they didn't act like they are then there probably wouldn't be nearly so much..

Re:Sun-bashing

[sjames]

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.

Re:Sun-bashing

[stu_coates]

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.

Personally I like Java as a language, and having experience of many languages can see that it suits application development very well. Whilst C/C++ is still superior for low-level (OS) speed critical stuff.

BTW, not a Linux basher - I use it on almost all of my machines, and have been for many years.

Re:Sun-bashing

[ekmo]

Sun walked away from the ISO several months ago because the ISO would not let them retain complete control, including imposing a licensing scheme, on the proposed ISO Java Standard. Sun merely did not want Java established as a standard, but they wanted to supercede the ISO when it came to formulating, monitoring, and enforcing the standard. This would have included huge licensing fees for anyone who used the ``standard''. It was little more than an attempt to get the ISO to become the licensing enforcement arm of Sun. When the ISO said no, Sun walked away. So they tried to make an end run around the ISO through the ECMA (until Sun realized that Microsoft was and ECMA member), and now they are apparently forming an Executive Committee, (comprised primarily of corporations, as opposed to developers). If this is supposed to be the Java community-based Process program, where are the real members of the community, the developers! Mr. McNealy, you cannot have your cake, and eat it too! Either Java is a copyrighted product, which you are free to license to third parties, or it is a standard. NOT BOTH! This is nothing more than another uncommitted publicity stunt by Sun that will accomplish nothing. Java will remain without standardization.

Re:Sun-bashing

[Kerg]

If this is supposed to be the Java community-based Process program, where are the real members of the community, the developers!


You mean developers like the Apache Group?

The Java Community Process Program -- Executive Committee Information

Get a clue.

Handheld Java-based OS

[DrPsycho]

I know the new AmigaOS is touted as being scalable anywhere from servers to cellphones... and there are definitely plans in the works for notebooks and PDAs. It will be based on the Elate/Intent engine by Tao Group, which itself includes a Java VM which works faster than anything Sun has managed to create.

Seems to fall into the same genre ( only with all the "yeah right... Amiga's making more promises" flames that get kicked up whenever this topic surfaces ) down to the "our Java code kicks Sun's Java code" machismo. Amiga aside, those of you who are interested should check out what Tao and their partners are doing on DeviceTop.com. Looks like Java for PDA might be here to stay.

I'll stop rambling now. :^)

--- [DrPsycho] Coping with reality since 1975.

Re:Handheld Java-based OS

[DrPsycho]

Okay. I lied. I won't stop rambling just yet...

Point of clarification. The Intent/Amiga thing runs PersonalJava 1.1 compliant Javacode, while Teapot is PersonalJava 3.0 compliant. As with most wide-sweeping generalizations (including this one), the details eventually get in the way. Things may not be as similar as they seem on the surface.

The Amiga SDK is reviewed, with a lot of detail shed on the Java side of things, at devicetop.com: "As you can se AmigaSDK performes about 2.5 times faster than kaffe, 3.2 times faster then Sun 1.2.2 and a little faster than IBM jit 1.1.8." I think you have to puff out your chest when you say that to get the full ego effect. :^)

http://www.devicetop.com/dt/editorial?showcase

No really. I'm going now.

--- [DrPsycho] Coping with reality since 1975.

Microsoft has a really cool Java product!

[Lord Omlette]

It's called C Sharp!

*runs*
--
Peace,
Lord Omlette
ICQ# 77863057

IPM/2

[Greyfox]

IBM's infoprint manager's GUI front end apparently runs in Java. I'm told it's about 10 million lines of code (!) and takes half an hour to start on a fast machine.

Big operating systems...

[Anonymous Coward]

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!

Ganymede (was Re:No Cool java Apps?)

[jonabbey]

Well, I dare say we've got a cool Java app, at least if you have a large, heterogeneous network.. we manage our lab on Ganymede, which is about 200 thousand lines of Java, GPL'ed.

Ganymede features a centralized database server written entirely in Java which contains object data for Users, Groups, Email, Netgroups/NFS, Automounter configuration, IP Networks, Systems/DNS, and more. Administrators in our lab can use the Ganymede GUI client in their web browser (on Windows, Macintosh, OS/2, Solaris, HP-UX, Linux..) to login to the server. The Ganymede server only lets them edit things that belong to them, and many different administrators can be logged into Ganymede simultaneously, each browsing the database and committing changes at the same time. A back end Makefile and Perl code takes the text data files written out by custom plug-in Java code on the server and does an NIS build, a DNS rebuild, an RSH over to our NT PDC to update users and groups on our NT server, a rebuild of the lab's Sendmail aliases, an update of our VPN and Dialup router authentication files, and more.

All Java, distributed, and multi-threaded as heck, with a client that worked the first time we tried it on both Macintosh and OS/2.

I don't know about y'all, but I'm impressed and pleased with Java quite well. If Sun didn't have such tight control over the specification, I'm sure more Java technology would be supported by Microsoft, at least, but I am also sure that you would get less reliability and consistency in running a given piece of code, as everyone would package the class libraries that they like or that is strategic to them, or would provide extensions/distortions to the VM so that floating point math would be done more quickly on their particular processor, or the like. None of which would be helpful for code portability, which is essential for Java to be a credible platform in the first place.

Wow this is amazing..

[_marshall]

As a Java Developer myself, some of the selling points on this aren't far from a miracle:

"...with the capacity to run applications written in C ... With a 1.3MB memory footprint..."

I'd be interested in seeing the source to something like this. Can you imagine an entire Operating System written in Java that has a memory footprint of 1.3 MB?? That's simply amazing.

~Marshall


--
Homer: "No beer, No TV make Homer something something";
Marge: "Go crazy?";
Homer: "Don't mind if I do!"

Java still miles behind for production code

[Ars-Fartsica]

- JDK 1.3 is a massive improvement in client side performance,

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.

Plus, server side Java code has been shown to be, at times, faster than optimized C code:

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).

Java is a very pleasant language to work in.

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.

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.

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.

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.

Re:Java still miles behind for production code

[Ars-Fartsica]

..Unless, that is, all the "object churn" has been inlined by the VM - at runtime.

I don't think any VM - or JIT - has ever claimed to eliminate object churn completely. I'm getting the impression that you think you can throw whatever you want at the VM and JIT and it will magically divine what you were really trying to do and somehow create the optimal solution for you. Unfortunately, this appears to be a pervasive myth among Java programmers.

Re:Java still miles behind for production code

[Stu Charlton]

No, I'm sick of a language making me buy and pay for synchronization when I may neither want nor need it.

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??") ... 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.

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.

Re:Java still miles behind for production code

[Stu Charlton]

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.

Re:Java still miles behind for production code

[Ars-Fartsica]

C++ has no inherent support for multiple threads. Pretty much everything is done through an OS api.

My contention is and always will be that it is easier simply to avoid threading entirely than to even bother with the details of where and when to use it. The pain of doing it right through native threads will be worth it when those few problems that demand threading arise. This statement is obviously opinion and highly subjective.

>>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?

By using the STL to create your datastructures. This safety is included.

Lego Component Interface

[jpick]

Has anyone else noticed that the TeaFS page
has a circle for a "Lego Component Interface"?

I wonder what that does?

:-)

Teapot vs. PocketLinux

[jpick]

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.

Re:And a fine example RT-Linux is...

[sjames]

Linux the trademark is under control of Linus.

Linus had little choice there. Some guy who had no connection with Linux development tried to trademark the name (in the same category) for unknown reasons just as the world outside of geekdom was starting to hear about this 'other operating system'.

Re:Wrong cool apps, for the wrong reasons

[Ars-Fartsica]

No wonder new stuff is sprouting up like mushrooms -- a phenomenon that I suppose Bjarne Stroustrup is mildly annoyed about and doesn't quite understand. Once you've written a C++ app, it's a dead end. It not reusable.

I can assure you that there is nothing about programming languages that you (or I) understand that Bjarne doesn't. C++ is a system/platform language. Java is an application langauge. Bjarne and Gosling have pointed this out repeatedly. This is why you'd be silly to write a forms/servelet app in C++ (unless its being served on a site like yahoo or AOL), and you'd be equally silly to write an RDBMs, web browser, or document processor in java.

The notion that C++ code is a "dead end" is also ludicrous. C++ has standard libs. Java has standard libs. You either use them or your own object hierarchy. If your C++ hierarchy is unuseable, why would its java version be any better? As it stands, reuse through generic programming is far more powerful than OO in any case.

I agree with the rest of your post, so I won't quote it. As it stands, if you like Python, check out Ruby - its probably closer to the OO nirvana you are looking for, although it is mostly popular in Japan where it orginated.

Better options?

[Ars-Fartsica]

For "safety" without the performance cost of threading, I suggest any of Perl, Python, Ruby, etc. Its my opinion that there are still very few applications that really demand threading, and the chance of misusing it is greater than the supposed benefits.

You can run Java on your Palm too.

[ikekrull]

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.

Re:Why java?

[be-fan]

It's cool. It's the same reason that GNOME uses CORBA for embedding. It's the same reason GNOME has it's own VFS layer. It's the same reason GNOME becomes a cross platform API on top of a cross platform API on top of a cross platform API. (GNOME on top of GTK on top of POSIX) It's the same reason Windows is riddled with feature bloat. It is simply not cool to have a simple product.

already being done...

[kootch]

what's the difference between this and SavaJe Technology's http://www.savaje.com/products.phtml">JScream product for information appliances?

As an unrelated question, why is slashdot posting PR for a company that doesn't have a product out yet? So they're working on a JavaOS, they haven't built it yet. All you can download on the site is a stupid white paper.

Re:Wrong cool apps, for the wrong reasons

[Ars-Fartsica]

One of Java's best assets is its notion of dynamic class loading, which could just as easily be done in a native-binary model, although the use of bytecode makes Java's approach more flexible, more adaptive, and of course logistically simpler for porting purposes.

Sorry Earlybird, but if you don't know by now that C++ has late binding and RTTI (which is directly implied by the ext preceeding that part I quoted), there really isn't much point continuing this thread.

Plenty of people have successfully implemented forms/servlets in C++ and RDBMS or similar things in Java.

No, no one has implemented a Java RDBMS, at least in the sense that they ever expected anyone else to use it.

No Cool java Apps?

[Carnage4Life]

Why is it that everytime Java is mentioned on slashdot some clueless person has to post some tripe about how they haven't seen any cool Java apps.
Now this is off the top of my head...

1. The new American Express credit cards use Java Card(TM) technology. That's right, American Express credit cards now run Java. Here's an
2. interview with the CIO of Amex.

1. Both
2. Oracle 8i and IBM's DB2 use Java extensively both for their DB administration GUIs as well as for middleware code. If you didn't know, these are the number 1 and number 2 Enterprise database systems in the world

1. Java servlets and JSP are used extensively on the web from sites like
2. mail.com to Firstunion.com. Hundreds of sites use Java(TM) to deliver dynamic content these two are simply the most prominent that come to mind.

1. Personal Java(TM) runs on
2. 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

Troll Alert

[Carnage4Life]

Obviously you are a troll. What does the language the OS is written in have to do with anything?

Windows 9x contains complex MFC/COM/DCOM C++ code that even seasoned developers have difficulty using. Does this somehow detract from the ease of use of the OS to the average Wintel using AOLer? No

Go troll elsewhere.
The Queue Principle