You have to get a JVM (which usually isn't free and takes up space) versus .NET CF which is either free to download or included in ROM with the device. Then there's the whole confusing JAVA world of Personal Java, Micro Java, CLDC, MIDP, MIDLETs, yadda yadda yadda. There's a pretty big learning curve just to get the development environment figured out.
I disagree. I've been programming in Java since its inception (started early 1996) and had no problem in absorbing new versions. Sure, J2ME is pretty different from J2SE, but it's not very hard to learn either if you already know J2SE.
I won't argue that it is hard to keep up with, I'm looking more from the point of jumping in now (or in the last couple of years). Trying to determine from the Sun website what technology to use is incredibly hard. Until recently there was as much information on their site on PersonalJava (now defunct, I think) as there was on J2ME. There was also very little help in figuring out which of the two was the newer technology. The discussion of the CDC/CLDC "profiles" didn't help much either. ;-)
I know that the article is mainly about why JAVA developers don't code for PPCs, but I was approaching it from the position of why PPC developers don't use JAVA. Sorry if I didn't make that clear from the beginning.
I don't debate client-side Java is pretty dead (except for some well-known, multiplatform stuff like the Oracle GUI). So are 'toy' applets. Exceptions are midlets - and being able to run midlets on the PPC (even when they are dog-slow) is a big plus.
Java as a platform, on the other hand, is very popular in middle-layer programming. I mostly coordinate middle-layer business (not "plain" Web) development and the majority of middle-layer technologies are Java-based. For example, we've just started working with ** (a well-known American firm - electricity and stuff), and most of their middle-layer stuff are Java.
Furthermore, because of the lack of native apps on the PPC, Java support (would be) welcome to run, for example, advanced HTTP proxies (the only native PPC HTTP proxy only knows the GET method...) or thousands of other tools.
I don't debate running them in a bloated/slow JVM is not a good idea. But, at least, they work, until someone rewrites/recompiles the same stuff into native .NET.
I'm looking more from the point of jumping in now (or in the last couple of years). Trying to determine from the Sun website what technology to use is incredibly hard. Until recently there was as much information on their site on PersonalJava (now defunct, I think) as there was on J2ME. There was also very little help in figuring out which of the two was the newer technology. The discussion of the CDC/CLDC "profiles" didn't help much either. ;-)
Sun's website has always been pretty convoluted and their own tutorial useless for teaching/learning. I've been tutoring Java on several Java courses at separate firms / my ex-University since 1998 and have never used/recommended Sun's own teaching stuff (except for their own course books - SL-111 and SL-276, for example, in courses organized by them). Third-party tutorials, books (Core Java, Just Java, Thinking in Java, Beginning Java etc.) are orders of magnitude clearer.
I've been hearing for years about how amazing Java is and how it will take over the world and solve all our cross-platform issues.
If that was going to happen it would have happened a long time ago. Java has its good points, but it's certainly not the all encompassing solution that was originally envisioned.
Quote:
Originally Posted by SteveHoward999
I think I can count on the fingers of one had the number of Java applats I encounter each YEAR on the web (maybe I lead a sheltered life) and no-one has ever approached me requiring me to create a Java solution.
I work for a company that writes quite a lot of Java solutions, but we very, very seldom have to write applets. The company have generally found that Java solutions are best run on the web server as a servlet - that way you can predict the hardware and software platform and resources that Java has available to it.
1- The core audience of the PocketPC (and PalmOS) platforms is looking for an information appliance. They want apps that plug in and run. Java on either system is anything *but* plug-n-go.
2- Native plug-n-go apps are abundant and high quality, usually at good prices.
3- Native development tools are at least as good as anything Java has to offer and often much better. Hence there is no incentive for developers to use Java. If the developers don't use it, there is no incentive for hardware vendors to include it, which brings you back to item 1.
I've noticed that client-side Java is most successful in environments that are generally starved for applications. Usually proprietary or niche systems where if you couldn't run Java you couldn't run anything. Or, that are dominated by techies that aren't afraid of write once debug everywhere. >;-)
None of which applies to the mainstream PocketPC market.
The bottom line is PocketPC customers have no need of anything Java has to offer. And that's how MS likes it. ;-)
Given the need for the person installing the application to have purchased a JVM, the question regarding Java on Pocket PC is always going to be not so much "Why not?" as "Why?", and this is only going to become more true as Microsoft fills in gaps in the Compact Framework this year and improves performance.
There's probably a much stronger case for Java on Smartphone (the base of Java games for mobile phones, which makes a difference to some people), which is why some vendors provide it as standard.
Didn't Microsoft have to be sued before they would even release a Java module for Windows? Even then, it had to be downloaded and was not included in the default install...
That seems pretty clear that Microsoft's not interested in encouraging developers to use Java. MS could easily include support for it native in the OS if they wanted to...
As a Java developer with a good bit of desktop experience, I'd have to say that there are a FEW very good Java desktop applications. In fact, I'd say that Java IDEs are themselves some of the best examples of Java Desktop software in existence.
I'd even say that taken together, Eclipse, NetBeans and IntelliJ (and there are others) are some of the most incredible development tools ever written. Easily better than Visual Studio at this point (from someone who uses both).
Unfortunately, it's harder for me to find other examples outside of developer tools.
Java GUIs *CAN* be both beautiful AND highly responsive -- as the mentioned tools demonstrate. It isn't easy to acheive though, and I think that's the real problem.
The real hurdle for both Java and .NET apps is the relatively slow start-up time of larger GUI applications and the sometimes painful garbage collection that all VMs incur.
Both are getting better though, and the important thing to keep your eyes on though is that dynamic optimizers and dynamic profiling of code WILL someday be faster than the best pre-compiled code. Read this for a neat look into what the future may hold: http://arstechnica.com/reviews/1q00/.../dynamo-1.html
BTW, there're tons of cool and useful Java midlets released all the time (not just games), especially in Symbian-centric countries (e.g. Finland). For example, Tero Lehto's PDA BLOG ( http://lehto.net/blogi/ ) has just linked a new, very cool midlet, BusWatch, ( http://koti.mbnet.fi/~kakoskin/buswatch/ ) that contains some 6000 station data of the Helsinki area + Tampere. If you have (had) a PPC that is able to run midlets, it is of great help because there're no native PPC solutions for this (except for being connected and browsing the web).
As a Java Developer...
Linear Mode
LinkBacks (?)
