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...
No, IIRC Jini is the "glue" between Java-enabled devices on some communication network, where a device announces to the others what services it provides: For instance, a printer could tell a network that it provides printing, so that e.g. a scanner could send directly to it.
Math.random() too hard for you to understand?
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.
A deep unwavering belief is a sure sign you're missing something...
But now they have handwriting recognition, and it just "happens" to understand graffitti, and all is well.
WWJD? JWRTFM!!!
You posted on the wrong thread. The original complaint here was that a java-based OS would be too complicated for a secratary to use. Not many secrataries are going to do things like define function call interfaces, worry about memory allocation, etc... :)
Hey, I remember when 8k was enough for an OS and a Basic interpreter ;-)
Anyone fancy writing something really small?
Andy Armstrong
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.
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.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
The only fact is that I don't have a Java Jini powered toilet despite Sun's claims.
It could save many a marriage. Imagine Bob gets to the office, and suddely realises he's forgotten to put the lid down! He swiftly logs in across the net and sends the "lower lid" command, just in time before his wife goes in for a pee. "Phew, that Jini Powered Toilet was the best investment I ever made!".
Has anybody tried using VisualAge Micro Edition? It's a Java app. for building embedded Java applications, and the IDE runs on Linux. Could VAME be used to develop applications for Teapot?
--- One world, one chance Doc.
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
The secret to enjoying Slashdot is to realize that it should not be taken too seriously.
First develop it for ages putting it in the public eye, and then all of a sudden reveal its patent encumbered. Nice...
Thats not what I wanted to talk about though, Linux the trademark is under control of Linus. So if the community was to shun Linus, they'd have to rename their fork... and anyone who thinks the name is unimportant they are terribly naive.
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.
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.
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.
...Unless, that is, all the "object churn" has been inlined by the VM - at runtime. For this exact reason, not much work is being done on the compiler optimization (I mean the compiler that produces byte-code from the source). All the optimization efforts are being concentrated on JITs/VM optimization. And, of course, at this level syntax is totally irrelevant - we're dealing with byte codes.
Meant to say "than most CISC" processors, of course.
Find me ten average Java programmers who can point out the synchronized objects and the non-synchronized objects they are instantiating
Synchronization applies to methods, and more generally, blocks of code, not objects. It would appear that your Java experience is somewhat limited.
Same reason people with VMS or COBOL make good money. Legacy support is sometimes cheaper than rewriting (probably most of the time). Just because some summer student wrote a smalltalk app which now has to be supported by contractors doesn't mean anything. There are Clipper programs doing the same tasks.
I took 3 years of smalltalk in school and while I'll agree it was a cool concept for its time, it didn't teach people OO concepts any better than the alternatives.
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.
No, that's not hard. Try implementing it in the real world.
no sig
It would be nice to find out something about what they are talking about, but half the navigation of the site requires Javascript. No web page is important enough to make me turn that FPOS on.
--
A "freaking free-loading Canadian" stealing jobs from good honest hard working Americans since 1997.
The next Cmdr Taco duplicate will be ready soon, but subscribers can beat the rush and see it early!
Well, here's another fact: ordinary users are not SUPPOSED to program! They are supposed to pay $$$ to the guys/gals like me that can and do know how to program and how to program well ;-) Besides, it costs much more to maintain code which is badly written, badly documented and mostly badly understood by the author. ;-)
;-)
Btw, there are _loads_ of people that do not qualify as 'wizards and hackers' and still manage to write fairly nice code.
If you really *must* program for some reason, use one of the many BASIC variants out there, but you'll probably start complaining about the complexity of BASIC too, in which case you'll have to be shot
I plan to plan / Dutch course in The Hague
It's radical change, however, is slowing and it might be time for it to settle down a bit and mature. The kind of maturity attained through passing ownership over to a standards committee.
-- Good judgement comes with experience. -- Experience comes with bad judgement.
What does the language the OS is written in have to do with anything?
Actually, quiet a lot, when it comes to things like defining function call interfaces, memory allocation methods, and other memory managment systems.
Thats not to say that you can't use other programing languages with an OS written in C (As an example), just that you sometimes needs to bend the language to suit the Operating System conventions.
Syllable : It's an Operating System
This has already happened. If the language were 100% open and standardized it would be adopted developers and could never be restricted by a single company. Companies like Microsoft can beat Sun but they cannot beat the developer community.
Instead control remains with Sun. Sun is protecting its own interest in a proprietary language. By doing so, it will not take an external giant to ruin Java; Sun will bring its own downfall.
| Ceci n'est pas une pipe.
You miss the point, an os written in a more structured language is likely to have less bugs. It's not about ease of use, it's about stability and compatibility
And no, I didn't do any tutorial, I just looked at the source of a co-worker and began writing my own.
Maybe you're at the wrong job?
Depends on what you think is cool... I've worked on a bunch of applications I think are cool. Billing apps that use XML/XSL for page generation (Using Cocoon from Apache) and EJB servers for transaction control... they work very well, and were quick to develop. If the only thing you classify as cool is games, then you are correct. If you like good, fast object-oriented applications, then you're wrong.
Virtually, Edward Wolpert
With the release of either the Blackdown or Sun JDK, client applications on Linux are here. I have been doing alot of development on my Linux workstation and testing with no problem on Windoze. And there are some great tool. Examples include: Borland's JBuilder, TogetherJ, several XML / XSL / CSS editors, jCVS (a Java CVS client), and others. These tools are fast and responsive to use. The only drawback is that some of them tend to grow quite large. However, I think that this is more an artifact of the underlying design than of the programming language and underlying runtime engine. Couple this with the productivity and pleasure of the language and you have a winning combination.
What do you mean by a "randomization"?
//One line of code...
:-)
double r = Math.rand();
Or, you could use two lines of code to create an object of type java.util.Random, then call various methods to get randome sequences.
I'd like to see those 20 lines of code. Are you brave enough to post them?
RISC code is larger than CISC. Then there's all sorts of things like power management, rudimentary GUI, hand writing recognition (grafiti or the like). The GUI's probably the killer though. You don't need much overhead to manage a commandline. you do need it when drawing objects on screen and following the movments of a stylus. More developed API's to make coding apps easier also create "bloat"
An actual developer could probably give you a more thorough list of what a modern handheld OS provides over COMMAND.COM.
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.
By this reasoning, Windows must be the greatest operating system ever.
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.
Ok, and a secretary would be programming WHY?!?!? You're obviously not a programmer, so why the hell are you looking at a programming language? And you're right, 99% of computer users are not developers (drop the elite bullshit, being elite has nothing to do with being able to code...) but what the hell does that have to do with being able to use applications written in Java? It's like saying 'I don't understand C/C++ so I can't use MS Windows'
BTW as a developer who's done C, C++, Objective-C, Pascal, Cobol, Perl, and PHP I can say that Java is one of the most straight-forward languages around...
.technomancer
.technomancer
Jini is dead folks. If you think otherwise, point me at one real world device that uses it.
Its sales of Sparc boxes that are paying the bills over there folks.
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
- jon
Ganymede, a GPL'ed metadirectory for UNIX
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
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 ;-)
Andy Armstrong
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.
- jon
Ganymede, a GPL'ed metadirectory for UNIX
Isn't this something like Jini? I mean, They are going to put Java on a handheld which basically has a microprocessor/microcontroller, why not just use Jini.
I agree with this.
Personally I think Java is a lovely language. It's a bliss to program it compared to other languages due to all the included components and the strong typing. (Which I happen to like.)
Unfortunately SUN are making it harder for Java to reach it's full potential. People complain about how Java is slow. Hey, if it was included in X or Windows and loaded from the start it wouldn't be very slow. Integrate AWT/Swing into the GUI and you have fast, portable, stable.
Unfortunately SUN dosn't seem very keen on this. It's just really sad IMHO.
You know what this means... Quake, Doom, etc. running on these things.
I have no idea why people bash sun so much.. Maybe it's because the quality of their programming has died in the last few years. I am going insane at work using NIS+. When I called their tech support about it he could reproduce the error and couldn't get around it. My "little problem" was having a user change his password...
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..
Because their corporate investors want graduates with Java skills, not Pascal.
So you're saying, before Java came out, these same, mysterious "corporate investors" wanted graduates with *PASCAL SKILLS*?! Why wouldn't these investors have pressured the universities to ditch Pascal for C/C++ then?
Pascal was created as a *teaching* language. It was pretty easy to learn, and the focus could be on programming techniques instead of syntax.
Then Java came along with a very clean OO-style of programming. It is easy to teach, makes it much easier to learn C++ than going from Pascal to C++, and Java is a popular language in the real world.
-thomas
"And like that
Perhaps I'm missing something, but AromaSoft never said that Teapot was written in Java. In fact, it seems to be quite the opposite. The ASL and all the device drivers are definitely written in C and ASM, and as for the rest (SoftCPU, Kernel, TeaVM, etc.), AromaSoft doesn't say either way.
Every mention of Java on the site and in the white paper only refers to TeaPot's ability to natively run Java programs, and not that TeaPot is written in Java.
Hint: If you are trying to get open source developers to write stuff for your product, don't give out anything in Microsoft Word format! (Use html. Use pdf. Anything)
And could you tell us something about the licence, please?
--
When all you have is a hammer, every problem starts to look like a thumb.
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.
-DrPsycho - Coping with reality since 1975
But the Windows toilet has a EULA on the toilet seat, and the seat itself has to be upgraded every 6 months. The thing clogs constantly, and I need a plunger handy at all times. I cant keep it clean, and the roto-rooter man cant always fix it, he (most of the time) tells me it needs to be reinstalled.
No matter how much I clean it, you can get virusus from it also. They will contaminate all the MS things in your house too.
Fear the government that fears your guns. Fear the government that fears your computers. Remove them from my email.
It's good to see yet another cool piece of Java kick off. Now, let's see if we will get something usefull and working for a change.
Let's recount: First we were supposed to write Java once and it would run on every client. Then we were supposed to write java once on the server. (For some reason we saw very little exciting stuff actually work on the client) And now: We are going to write some Java on the PDA. (I haven't seen any really really cool apps on the server though...).
Java: money oriented programming
In Java you can have interfaces which can only contain method declarations, not implementations; abstract classes, whcih may implement some methods but not others; and full-blown classes that can implement resp. extend the former types.
For a better explanation I suggest you download Thinking in Java 2nd ed. at Bruce Eckels' website and read Chapters 6-8.
Java is a good way to blow millions of dollars on something that has to be thrown out in the end because it can't handle the throughput. I know - I make my living going into companies and rewriting their systems in C++. I prefer to work with technology that works today instead of the promise that it might work faster tomorrow when and if better code optimizers come along. Also - what do you do when your production JVMs crash repeatedly in the same location in the code through no fault of your own? Debug the virtual machine?
I think you are a bit misinformed on Java. Java does allow you to seperate your class interface declaration from your class definition. You simply declare your interface declaration to be an interface rather than the actual class. Then your actual implementation of that class declares that it implements the interface.
Example:
On the topic of Java for big applications, you're also misinformed. There are several large, feature-rich applications written in Java. Take a look at NetBeans, JBoss, or Tomcat. The list goes on and on.
The syntax is intentionally modelled after the C/C++ syntax. I don't see what issue you have with the syntax.
It appears that either I'm just really gullible and jumped at your nice troll. Or you need to do a little more Java research. Let's just hope I'm gullible; my ego can take it :).
Do you think these people sacrifice a snappy product name just to make the hot-beverage link?
You know, if they didn't do this, then we might not understand the relationship with Java.
For the record, the name stinks.
Don't get me wrong, Java is a very nice language, but I don't see why it is good for handhelds unless you have a special need to run something already in Java.
I would just as soon have a complied language.
"It's because they're stupid. That's why everybody does everything."- Homer Jay Simpson
The point of java is that it allows applications to be written once and run on different platforms, right? Who is going to run a word processor on a hand held? A spreadsheet? The small displays and lack of keyboards limit these PDAs to certain uses, and you don't NEED java on these devices. Hell you don't NEED java on the average PC desktop! Let's all just jump on the java bandwagon, whatever is popular just like a lot of companies (IBM, DELL) are latching onto Linux. It is sad and stupid.
I can understand why. I was in Carleton the first year they started teaching SmallTalk instead of Pascal. It was a really neat language but just not practical. Having had several years of programming experince before I started and seeing the newbies in class as well beginning their first programs they could of used any language.
I think they picked it because of the graphical interpreter. Remeber this was 1987/88 and except for LOGO there weren't too many languages that let you make pretty pictures easily. I really wished they taught basic C in first year and moved up from there.
Graduating with SmallTalk experience certainly isn't what an employer was looking for when I graduated in 1992 and never changed since.
It's called C Sharp!
*runs*
--
Peace,
Lord Omlette
ICQ# 77863057
[o]_O
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.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
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!
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.
- jon
Ganymede, a GPL'ed metadirectory for UNIX
How does this impact my "computing experience" again?
Well, that's a good question. If I were to make a slow and well thought out response to your question I might slowly come to the conclusion that there might be a few things which are native to java which might standout with regards to other languages. Of course one must be slow to respond to this question because it is of a technical nature and there are many aspects of a programming language which must be slowly looked upon when doing analysis. In fact, I'm going to slowly ponder this and perhaps repond with a more insightfull post at a later time.
As a Java Developer myself, some of the selling points on this aren't far from a miracle:
... With a 1.3MB memory footprint..."
"...with the capacity to run applications written in C
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!"
arcane for life
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.
Has anyone else noticed that the TeaFS page
has a circle for a "Lego Component Interface"?
I wonder what that does?
:-)
No I'm writing an irc-client. A bit more work :-)
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.
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.
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.
Java has replaced Pascal as the "teaching language" in many (most?) colleges now.
Go troll elsewhere.
"And like that
Consider a program you write. You have got all these classes and things. You compile and release. All the information about your program is now embedded implicitly in your program. There's no way for me to take any of those classes and reuse them. That's a dead end.
C++ is very binary-oriented: If I write a web server and servlet framework in C++, then the only viable way for servlets to communicate with the server is through some sort of well-defined binary interface, say DLLs/shared objects or RPC or CORBA or DCOM. Or on a source-code level. I would have to recompile the server each time I added a servlet. Does C++ need an ABI? I don't know. It would have to cover a lot more than just classes.
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.
C++ could have had this, but I tend to believe that it has too much crust -- from the preprocessor and reliance on include files and defines, to templates, to its object model (one of my major hassles with C++ is that two classes cannot contain automatic [ie., non-pointer] members of each others' types, because for one of the classes, the other class will be "unfinished" at the point of declaration) -- that does not make the language as suitable for opening up.
I don't buy your argument about system/platform language vs. application language. Plenty of people have successfully implemented forms/servlets in C++ and RDBMS or similar things in Java. What's your point? That Java is too heavyweight or bloated for that sort of thing? Requires a large runtime, what? What makes a language an "application language" versus a "system/platform language"?
As for Ruby, I remember looking briefly at it once and being befuddled by its syntax, but thanks for the reminder -- will check it out again. Are libraries plentiful? Does it connect well with other languages?
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
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.
> same, mysterious "corporate investors" wanted
> graduates with *PASCAL SKILLS*?!
There was no high tech boom when Pascal was popular. No one (important) wanted their skills.
> Then Java came along with a very clean OO-style
> of programming.
I can't believe you said that. Java replaced Smalltalk at Carleton. Java does not nor will it ever have a cleaner OO implementation than Smalltalk. In fact, Java's OO implementation is terrible. Far worse than C++.
Have you actually used Oracle's tools much? There are SEVERAL problems with them and IMHO they demonstrate exactly how NOT to use Java.
1. The administration tool is SLOOOOOW. 2. The installation tool is slow and you have to have the proper version of the install tool in order to install specific versions of their (freely avaliable) drivers. The install tool is not (last time I checked) freely downloadable.
Of course the install tool issues (besides speed) are really examples of poor design/distribution on Oracle's part but the speed issue still exists. I sincerely question the wisdom of Oracle wasting time re-inventing the wheel by writing their own install tool.
I have seen a few Java applications that functioned correctly but I have yet to see a Java application that approached anything I would call acceptable speed (and I'm talking about P3-450 and P3-600 systems). This is both with MS's JVM and Sun's.
Interpreted languages will ALWAYS be slower than natively compiled languages (Given the same quality of code)
It is the responsiblity of the developers/architects to make wise decisions as to when the loss of performance is worth the time saved (if in fact any time would be saved). Most of the Java projects I've seen have all come about due to the buzz factor of Java, not because it was the best solution for the problem at hand.
On a side note, I resent the implication that just because Oracle and IBM make two of the most popular products in the market that they are inherently writing 'cool' or better applications. I believe MS is #1 is several markets but there are at least one or two /. members that would agree that they don't have the best or coolest products.
-Zane
This sig is worse than my last.
Yeah, Java is slower than C on the Linux box, but Java applications (not applets) consistently out-perform Visual Basic and Visual C++ apps on Win32 benchmarks. It seems ignorant that the people who associate Java with slowness are often the same people who are coding in VB, hehe. Even if Java got IDENTICAL performance to VB, even if it WASN'T faster, it would still be a far more stable and intuitive development platform. In Java, a program will not COMPILE if an error can reach the top of the stack without being handled in some way. Name another development platform that does a better job of promoting that level of stability...
BRAVO! Java is a development platform. Some developers who write in other platforms may find Java too structured and limiting in some ways. Or they may be uncomfortable in the thought that their code will be used on third party JVMs on which it wasn't tested. On the other hand, C and C++ has always made me uncomfortable with the way it handles pointers. It seems like every large project I've ever worked on took forever to debug because of some pointer arithmetic or misassignment that was nearly impossible to track down. Java nearly eliminates those problems. Anyway, we are not so limited that we don't have our platforms of choice. Make any choice and you will find something to work on. All this arguing over which is the fastest or the best reminds me of that line in Pirates of Silicon Valley "When did this stop being a business and start being a religion?" I halfway doubt that the people who are so ardently defending or attacking one platform or another have ever written so much as a line of code in the platform they hate so much.
There was no high tech boom when Pascal was popular. No one (important) wanted their skills.
Hmmm, let's see, Pascal was popular in colleges... ohhh.... 3 years ago. I'd say there's been a "high tech boom" for the past 10 years.
I can't believe you said that. Java replaced Smalltalk at Carleton. Java does not nor will it ever have a cleaner OO implementation than Smalltalk. In fact, Java's OO implementation is terrible. Far worse than C++.
What I meant is that Java has come the closest, IMO, to a draw between good OO implementation and programming simplicity. I did not say Java has the best OO implementation, did I?
I am sorry you feel slighted with Java replacing Smalltalk at your school, but it is more practical and useful than Smalltalk in our internet world.
-thomas
"And like that
Thanks. Your post made my day. :)
-Stu
not to mention does cool java-based cash registers at compusa
Standardized (albeit by Sun), extensible APIs, especially on the server end, and extensible products, is part of what makes Java thrive today. Transaction API, J2EE, JNDI, Java2D/imaging, Java3D, servlets, JDBC, CORBA. Plus a host of pre-packaged libraries for things like sockets and RMI. Products: object databases (Ozone, the Castor O/R mapping framework), transaction managers (Tyrex), web servers (Resin, Jetty, Orion, Enhydra), XML etc.
Above all, Java connect to anything, provides a lot of freebies (garbage collection, a simple object model), is high-level and easy to learn, and lets you be more productive right out of the box as opposed to languages such as C++. 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. Unless you wired it up with magical strings and CORBA and reinventing all sorts of technologies, it just sits there.
This is much the same reason Python is thriving, really. Unfortunately, Java currently does not have anything that comes close to Zope. Turbine and Cocoon sound like two different projects aimed at this area, but they're not even close.
Who cares about Amex or set-top boxes? Unless I can write TiVo-like apps on my desktop computer that controls the box in interesting and hitherto-unrealized ways, it's useless, just another closed implementation. And Amex, well, how do I connect to my card, then?
Now:
I wish you hadn't mentioned that. Oracle's bloated, clunky Java GUI stuff is their big black sheep. I wish they never screwed this part up -- Oracle's native NT tools used to be at least adequate. Compare Oracle's present, slow, unstable, overdesigned, Microsoft Bob-like Java GUIs with Microsoft SQL Server 7.0's flashy, fast, and hugely functional tools and you just want to crawl into your mama's arms and cry like a baby.
Servlets is hardly Java's finest moment, same goes for JSP. True, servlets replace CGI in a nice way, and anything is better than ASP and assorted horrors, but that's about it.
Servlets make up a very low-level layer, and servlets themselves are quite isolated entities, compared to the riches of Zope's DTML documents.
Please, developers, do yourselves a favour and read up on how to properly divide content, logic, and presentation. Hint: Putting Java inside HTML gives you no cigar. Look instead at things like Freemarker and Webmacro, or even that bastard son of template processing, XSLT. Even so, these are quite weak tools, and you need to buy a $35,000-per-CPU app server to get any sense of an integrated package.
End of rant.
This development concerns me greatly. Why? Well, I'm a Palm OS fanatic. And in marketing, like in politics, it is a bad idea to split your constituency. Right now, I think it's safe to say that Palm OS's dominance is uncontestable in the "techno-geek" category who fear, loathe, and despite Microsoft. Now, with things like linux and java pda's threatening that...
XOXO -Les ailes de l'amitié
I'm merely stating the facts, not trolling. Noone can give me an answer about how to do a randomization in less than 20 lines in Java. I'm not denying that wizards and hackers might like Java and C-like languages, but for ordinary users - like the rest of us, simpler languages would be quite handy.
no sig
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
I won't tell you _that_ Java is archaic, but rather I'll tell you _why_. Ever used C++? Of course C++ is not compile-once-run-everywhere, but at least there's the possibility to separate the class interface declaration from class definition. Correct me if I'm wrong but AFAIK in Java every member function has to be fully defined within the class declaration, which makes the source definitely less readable than anything else.
I don't think Java fits for big applications, at least not without any of those big IDEs like JBuilder helping you to navigate the source. Java syntax, not Java in a whole, is a step back in IT, not a step forward!
Another platform for my best-selling games.
- J. J. J. Julius, author of a considerable number of best-selling games
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
Don't follow the link!
- J. J. J. Julius, author of a considerable number of best-selling games