Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Java Programming

A Java-Based Handheld OS 124

Posted by emmett from the one-lump-or-two dept.
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.
This discussion has been archived. No new comments can be posted.

A Java-Based Handheld OS More

A Java-Based Handheld OS

Comments Filter:

  • Re:Why on a handheld? (Score:3)

    by be-fan ( 61476 ) on Sunday August 20, 2000 @06:47AM (#841587)
    JAVA CAN BE COMPILED. Repeat this to yourself 5 times every day.
  • 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.
  • 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!

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

  • 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 [oti.com]? 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?
  • 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

  • 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.
  • "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.

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

  • 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.
  • the PowerPC has more complex instructions than most RISC processors

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

  • No, that's not hard. Try implementing it in the real world.

  • 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.
  • 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 ;-)
  • Personally, I am glad that SUN's owned java the past few years. It's unlikely that it could have evolved as quickly had it been owned by some committee such as ANSI.

    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.

  • What do you mean by that?

    There's the standard Random class, and Math.random. There are also numerous other random number generator classes outthere with much greater cycles.

    I don't know what you mean by "try implementing it in the real world". Many people do.

    I'm no fan of sun...but I just don't know what you're getting out of this...
  • 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.
  • > If the langage was 100% open, companies like MS would have ruined it.

    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.
  • 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
  • It took me about 2 days to 'learn' Java. It's just C++ done better (GC, interfaces, hierarchy).
    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.

  • Java Clients on Linux has arrived. (Score:1)

    by Anonymous Coward
    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"?

    double r = Math.rand(); //One line of code...

    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.

  • cool Java Projects (Score:5)

    by Stu Charlton ( 1311 ) on Sunday August 20, 2000 @08:12AM (#841620) Homepage
    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 [aceshardware.com]..(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... (Score:3)

    by kbonin ( 58917 ) on Sunday August 20, 2000 @07:20AM (#841621)
    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.
  • 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.

  • Not that I support SCSL ... but this is quite misleading. Sun charges a "Logo Fee", which is a choice of ten cents $0.10 per unit sold or an annual $250,000 fee. You'd only be paying a 5 digit (not 5+) licensing fee if you expected to sell more than 2.5M units annually.

    See: Appendix B of the SCSL agreement for Jini [sun.com]. License fees may be waived at Sun's discretion (B2.3) if the product is distributed for cost. This is only for commercial use. All other use is gratis.

    No. I didn't read the whole thing and IANAT.

  • The latest issue of linux journal has a great piece about Java on linux - currently even compiled solutions like gcj perform worse than the windows runtimes, and this is coming from a linux publication.

  • 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

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

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

  • 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

  • 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 ;-)

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

  • 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...
  • To whom is the name so terribly important?
    Sawmill to Sawfish, Linux to Looneyix, big whoop.
    ---
    Where can the word be found, where can the word resound? Not here, there is not enough silence.
  • 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..

  • How about the US army?

    http://www.sun.com/dot-com/studies/jiniinthearmy .html

  • I think it depends on whether you make the distinction between 'microprocessor' and 'microcontroller'. Sun obviously do, and I agree with them for the most part.

    After all, your Palm V has a hell of a lot more overall resources to it than your average microcontrolled coffee machine.

  • 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

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

  • The army is the end user. The use of Jini or UPnP has nothing to do with the saleability of the product anyway.

    The product doing what it is meant to do makes it sellable.

    Why do you people talk about standards like they're football teams or something?
  • 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?
    --
  • I know the new AmigaOS [amiga.com] 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 [tao-group.com], 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 [devicetop.com]. Looks like Java for PDA might be here to stay.

    I'll stop rambling now. :^)

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

  • 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 [devicetop.com]

    No really. I'm going now.

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

  • >> Sun created Java, but they want it to be an open standard *and* have control at the same time.

    Yea imagine that! They should be more like Linus, he would never, what? oh yea, nevermind.

    or, um, RMS! he would never, huh? oh yea. hmmm...
  • 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.

  • 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

  • You're wrong.

    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 [bruceeckel.com] and read Chapters 6-8.

  • Yes, you're right. (Score:1)

    by Anonymous Coward
    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:

    Foo.java:

    public interface Foo
    {
    public int getBar();
    public void setBar(int Bar);
    }

    FooImpl.java:
    public class FooImpl implements Foo
    {
    int Bar;
    public int getBar(){return this.Bar;}
    public void setBar(int Bar)
    { this.Bar=Bar;}
    }

    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.

  • Why java? (Score:1)

    by Anonymous Coward
    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.
  • // die rolling program
    // assume imported java.util.Random;

    Random r = new Random();
    System.out.println(r.nextInt(5) + 1);

    // it doesn't get any easier than this,
    // even in Basic

  • 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
  • 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.
  • Java is a very nice language, which is exactly why it should be used on handhelds. If the language features of Java can cut development time significantly (which I have found to be the case where I work), than it only makes sense to use it. Of course there are some applications for which Java is ill suited, but I don't see this being the case for typical PDA applications. The cross platform nature of Java can also cut development time.

    BTW, the latest Java implementations (Sun/IBM v 1.3.0) deliver performance comparable to compiled languages. This is because they used mixed-mode interpreters that essentially perform runtime profiling to find the hotspots and compile those sections of Java bytecode.

  • Big operating systems... (Score:4)

    by Anonymous Coward on Sunday August 20, 2000 @07:46AM (#841659)
    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 [utexas.edu], 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.

  • Re:All these PDAs.. i'll stick with my Palm (Score:3)

    by jonnythan ( 79727 ) on Sunday August 20, 2000 @07:47AM (#841661)
    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.
  • 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.
  • Despite the fact that there are 2 major contenders for handheld devices (PalmOS and Windows CE), there are at least 4 or 5 different CPU architechtures. Motorola dragonball (68k) on Palms and Visors, and NEC Vxxxx, MIPS, SH3, and ARM chips on WinCE. If you could have the base "OS" handle java, handheld applications will work on all of them without recompiling. That's a definite plus.

    :wq!

  • 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!"

  • Re:Sun-bashing (Score:4)

    by sjames ( 1099 ) on Sunday August 20, 2000 @07:55AM (#841665) Homepage Journal

    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.

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

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

    I wonder what that does?

    :-)

  • Teapot vs. PocketLinux (Score:4)

    by jpick ( 3522 ) on Sunday August 20, 2000 @09:10AM (#841669) Homepage
    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.

  • 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'.

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

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

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

  • You can run Java on your Palm too. (Score:3)

    by ikekrull ( 59661 ) on Sunday August 20, 2000 @01:56PM (#841679) Homepage
    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 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]?

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

  • 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.
  • 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.
  • 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 [sun.com]

    Get a clue.
  • what's the difference between this and <a href="http://www.savaje.com">SavaJe Technology's</a> http://www.savaje.com/products.phtml">JScream</a> product for information appliances?<P>

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

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

  • No Cool java Apps? (Score:3)

    by Carnage4Life ( 106069 ) on Sunday August 20, 2000 @04:30AM (#841705) Homepage Journal
    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 [sun.com].
    1. Both
    2. Oracle 8i [oracle.com] and IBM's DB2 [ibm.com] 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 [mail.com] to Firstunion.com [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 [sun.com].
    The Queue Principle
  • 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

Slashdot Top Deals

Somebody ought to cross ball point pens with coat hangers so that the pens will multiply instead of disappear.

Close