Slashdot Mirror
The "Return" of Java Discussed
An anonymous reader writes "Following on from the marvelous recent James Gosling interview highlighted in Slashdot last week, it would seem that a renewed momentum is building up for his cross-platform creation, if this editorial is anything to go by. It's called 'Java is Back!' But did it ever go anywhere?"
wxWidgets (my favorite) and wx.NET /.) .NET
Mono
Cocoa# and Gtk# (recentely kn
Java is slow, obeist, and heavy.
It's strange how so many people say "Java is dying" or now that it patently isn't, they're saying "Java's back". If you go to any of the recruitment websites in the UK, the most popular requirement is Java Enterprise experience, hardly the mark of a development system that's been in decline ... The only explanations for this misrepresentation of Java that I encounter on sites like Slashdot and Linux Today is the following:
Discuss ...
Do a user driven (10 questions, you know) with James Gosling. Java/Sun takes a lot of flak these days, it would be genuinely interesting to get Gosling respond to some good questions.
Seriously, this was a 100% fluff article. The foundation for the article was based entirely on the assertion that a Google for "Java" brought back far fewer hits than "NET": well no shit Sherlock- perhaps if you'd tried ".NET" instead?
The major problem Java has is EJBs: everyone in Java-land seems to think that their problem requires solving using this pile of crap. A web application with persistence- ooh we'd better use EJBs then!
A secondary issue for Java is the barrier to entry is extremely high: sure you can learn the language quickly but it's Java's libraries that add the real value. And there are an awful lot of them. I've been using Java for 10 years (yeah I developed using the AWT and cursed it every day: if it hadn't been for the AWT being so awful I'd never have thought Swing was any good). Anyway, I've been using Java for 10 years and I would hate to have to learn it from scratch today.
Bad analogies are like waxing a monkey with a rainbow.
People thought it was going away because of all the stupid people saying 'Oh, c++ is much faster'
when in fact Java uses allot of native code that is actually compiled c code. Its often very fast.
One of the first things I was taught in college, was to be critic of the sources I based research on.
In the world of WWW, it seems that each and every article and blog entry can be used as reliable fact. "He wrote it, it must be true". If some nerd posts that language X is the best, and those who use it are really really smart (case in point Paul Graham/Pythong) - that really doesn't make it come true. Same goes for Java "dead or alive" etc. etc. (Naturally, we all know that BSD is in fact dying - this is the exception).
Unable to read configuration file '/bigassraid/htdig//conf/14229.conf'
Geocrawler error message.
Java is pretty popular on the server side, but client side it was always one monumental flop.
As applets go, for example, nowadays the whole program-inna-browser market is owned by Flash, followed by ActiveX. And for good reasons.
Starting with the fact that Java 1.0 was indeed a slow piece of crap for anything but the most trivial applets. Try displaying a complex table without a JIT, and you were talking about response times you could measure with a stopwatch, not with System.currentTimeMillis().
The initial lack of support for packing everything in a jar didn't help that cause either. Downloading 50 classes as separate files isn't particularly fast. And that's a very small project.
And for all the multi-platform hype, wasn't particularly portable either. If you tried running even a trivial AWT applet on different platforms, you wouldn't even get the same events. Or for something which required you to give a size in pixels on the web site, you wouldn't even get the same font sizes.
And by the time it caught up... meh. Flash is _still_ the better choice.
Not the least because of download size. Sun now includes all the crap they could think of as standard libraries. Do I need an XML parser to make a simple game applet? Not really, but Sun wants my users to download that crap anyway.
(No, it's not a made up problem. I've had modem users tell me literally "whoa, I'm on dialup. Is there some smaller version I can download?")
That's just a small slice of the many ways in which Sun started it on the wrong foot.
A polar bear is a cartesian bear after a coordinate transform.
It's just a marketing.
:(
Java language has stagnated in about 1999 with the release of J2SE 1.2 (dubbed Java 2); new J2SE 1.5 (Java 5) is just a cosmetic change of language (yes, I consider current implementation of generics/annotations to be 'cosmetic').
It's quite OK to be conservative, but you can't conquer the world of IT being conservative. Java's position on server-side is still pretty firm, but desktop apps in Java (apart from Java IDEs) are non-existant.
And Microsoft's position on server-side is strengthening. So Microsoft will prevail if nothing changes in the recent future
and thats not bad.
Consider, that java is not only the language itself, but also the whole environment!
And thats the real big difference to mono. Java may run on any Computer since 92' till 2050, without need to take care of what Microsoft will change in 2 years.
He bases part of his argument that Java is less popular than .NET by doing a Google fight between "java" and "net"???
Java can be a coffee or an island in the Indonesia. Net is a device to ensnare animals and is a verb as well.
And he cites a blog item from a Sun executive as proof that Java is back? Please. The article is nonsensical.
---Technology will liberate us if it doesn't enslave us first.
got bored watching
Microsoft is a master at switching enough labels to "keep things interesting". New bells and whistles to hold your attention. (I'm a sucker for a pretty interface) Kind of makes it seem like Java isn't moving at all. Java never left and it's not going to "die". It is a young language that has survived and grown on its own merits and not through billions in marketing hype and R&D and despite it's creaters over protectiveness. It's just getting started.
Either the tool you're using allows you to get the job done or it doesn't. Either the tool improves over time to make your job easier or it doesn't. If you want to see Java thrive, use it.
Michalangelo Progr
Well, you must be pretty hopeless not to be able to install the Java runtime. Last time I installed it on Windows, it took half a dozen mouse clicks and a couple of minutes tops.
Everything is easy when you approach it from the point of view that it doesn't actually have to work.
There are many versions of the Java environment, from different vendors, all with subtly different behaviors and ways of integrating into the environment. Not to mention that the user may be running other Java applications which depend on a particular version of the Java environment, which further complicates matters. This makes it a pain if you want to deliver an application to the user with minimal hassle.
Or, you can just mandate that the user run such-and-such version of the Java enviroment on such-and-such platform, but then you lose a large part of the write-once, run-everywhere appeal.
I run Java on very low spec embedded PC's, and it's no slouch there. Even if there is a couple of seconds wait at startup, the JIT compiler means a well written app will run without being appreciably slower than a "native" app once the JVM is bootstrapped.
Java's "slowness" has at least three components: startup time, garbage collection delays, and the huge footprint which triggers swap activity.
For server applications, none of these matter much. For interactive client applications, these factors conspire to make Java apps look very bad when compared to "native" competitors. The exception here are applications like Eclipse, which you start when you get in from work and don't quit until you're done. But for most other apps, e.g. utility apps which you just want to quickly use and close, or workflows where you switch between multiple apps frequently, Java is just not suited.
Very rarely do we have to resort to doing major grunt work on the server as opposed to doing it in the Java client.
You're missing the point royally. Java isn't slow at doing grunt work. Few people would contest that. But as a platform to write desktop applications, it is a pig. The Swing UI is slow and prone to memory leaks, data interchange facilities are poor (even the clipboard functionality integrates poorly with the surrounding environment), memory requirements are completely uncontrollable.
Yes, Java does requisition a lot of memeory when an untweaked JVM starts up, but the inmpact depends on the machine running the program.
Indeed, and that's why most Java shops pretty much only run one application on their servers.
This could be rephraed as "bad Java programmers leak memory".
The fundamental problem is that you cannot control how memory gets used. For example: the JVM allocates memory from the underlying OS in chunks which it then doles out to your app as necessary. Then at garbage collection time, the memory is reclaimed from your app and returned to the JVM. But then the JVM may or may not ever return this memory to the underlying OS. This means that even if you have a tiny application, when the user opens a mammoth 100MB document just once, the application will continue using 100MB even after the user has closed the document.
Yes, this is sort of tunable through commandline options and other properties, but then only for some versions of some implementations of the JVM. Which brings us back to the first point, that it's a hassle to deliver hassle-free Java applications. It's so troublesome in fact that some programmers choose to simply distribute a JVM along with their apps.
The bottomline is this: Java is a cool language, but it just doesn't play nice with others. It insists on reinventing everything, it insists on abstracting everything, and it insists on total control over the environment. That's fine for in-house apps or web apps, but it limits Java's adoption on the desktop.
And ultimately, I think it condemns Java to a perpetual "behind the scenes" existance, growing ever more baroque appendages in its invisible niche, until its burdensome legacy is swept away by something more open.
This is another one of those horrible things that happens every once in a while on slashdot. This argument is about as big as MS v. Linux or AMD v. Intel or ATI v. nVidia (for those who care).
The fact is you have some people who are super java fan boys and will stand by it until the day they die and most of them probably haven't programmed enough in other languages to say anything but the few bad experiences they did have.
Don't think I am letting the C/C++ programmers off either. I am one of them and I will be the first to admit I have hardly ever used java, but I have also had enough first-hand bad experience to not want to use it.
The fact is that people will stick with they know best and odds are whichever you learned first (java or c++) that will more than likely be the one you spend the majority of your time working with. So half the people can continue to rip on java now and the rest of you can praise it. I do digital design so I don't care enough about code to get into this argument.
--
"The same thing we do every night Pinky; Try to take over the world!"
"Some days you just can't get rid of a bomb."
I am almost at the point that I'll promise not to engage in this discussion again. Ok, one more time:
``Well, you must be pretty hopeless not to be able to install the Java runtime. Last time I installed it on Windows, it took half a dozen mouse clicks and a couple of minutes tops.''
And a 20 MB download that takes dog knows how many megabytes after installation. Also, the whole process will have to be repeated at the next release, as chances are software developed on a newer version won't run on an older one.
``Even if there is a couple of seconds wait at startup, the JIT compiler means a well written app will run without being appreciably slower than a "native" app once the JVM is bootstrapped.''
Most applications don't need a lot of speed once up and running, anyway. Startup time is a huge annoyance, to me anyway. Is it really that hard to save the compiled code, so next time the JIT doesn't have to work again?
``java applications have slow, unresponsive user interfaces--- on slower machines, using java-based user interfaces can be frustrating (resizing the application window can mean taking a coffee break).
That's strange, it must be their inability to code an interface and data models in an efficient manner.''
I don't know about your systems, but on any system I have used in the past years, user interfaces in Java apps are noticeably more sluggish than in native ones. Perhaps this is perceived performance, but arguably it's the perceived performance that matters for user interfaces.
``java applications leak memory
This could be rephraed as "bad Java programmers leak memory".''
Yes, but isn't it symptomatic of defects in the language if many programs written in it leak memory? Besides, isn't Java's garbage collection supposed to take care of things? Personally, I believe that there was an issue with old JVMs (at least on Linux) leaking memory, that has now been solved. At any rate, I think that kast's author is being more bitter than rational when he says things might be better without gc. Gc is a Good Thing, after all, memory allocation and deallocation is excactly the sort of task that machines are good at and humans are not. It can even speed up programs under some circumstances.
Please correct me if I got my facts wrong.
You know, I can't remember the last time I was asked to deliver a product that printed "Hello World" so whether or not the JVM is too heavyweight for such an app' is moot. And even if it was: throw more hardware at it. Hardware is cheap. Maintaining code is expensive and C++ has a much higher maintenance overhead than Java does (pointers, object ownership, misused multiple inheritance - the list goes on).
Bad analogies are like waxing a monkey with a rainbow.
Well, you must be pretty hopeless not to be able to install the Java runtime. Last time I installed it on Windows, it took half a dozen mouse clicks and a couple of minutes tops.
That is SO not the point. Why the hell should a, for example, 55 year old occasional computer user need to even know WHAT Java is, let alone UNDERSTAND why they need to install it?
Surely the uppermost aim for any software engineer / developer / designer is to hide complexity from the user?
I have two roles at my work: the first is as an IT Project Manager and the second is in a Procurement role for 3rd-party software development effort (i.e. a Client). If the technical-lead on a project or a supplier ever told me that "all the user needs to do" is to "just" download and install anything (including Java) to run their application I would throw them out the door / off the project!
This is as absurd as priming your fuel pump everytime you want to drive somewhere, or calibrating your derailleur gears before you can use your bicycle.
Not acceptable!!
quidquid latine dictum sit altum viditur
Three things have changed: broadband has meant that applets are not as slow to load as they used to be; machines have got faster; and JVMs have got better (including plugins).
In the project I'm working on (I'm a Java developer, mostly servlet/JSP/struts) we're deploying an applet to provide a richer user experience which HTML alone would not provide. I would not have dreamt of providing this solution even a year ago.
The applet is very usable, only takes a second to load the first time it's used (and thereafter is cached) and the user has a better experience of our product. We're telling our customers to use JRE 1.4.2.
The trick is to use applets when they are appropriate. This is, after all, true of all technologies.
I believe that eclipse http://www.eclipse.org/ and netbeans http://www.netbeans.org/ have both made a huge contribution to showing how Java applications can be used for serious development projects. There is now a huge amount of support for the Java development community, with lots of free libraries (Apache Foundation rocks http://www.apache.org/!) and some great stuff coming out of Sun (Java Server Faces).
Put it all together and you have a very rich environment for creating serious multi-tier applications using web or application front-ends.
For me, the icing on the cake would be the development of a forms standard which allows application-like front ends with a web architecture. Maybe XForms? XUL? This is what our customers want. Combine it with a strict and workable MVC architecture and it'd be my perfect development environment!
This makes it a pain if you want to deliver an application to the user with minimal hassle.
Not really. There is Java WebStart which solves this issue. Commericial products like InstallAnywhere solved this also. Old issue.
Java's "slowness" has at least three components: startup time, garbage collection delays, and the huge footprint which triggers swap activity.
Start up time is slow. It takes approx a couple seconds. Ofcourse this is a one time cost that interpreted languages go through. C# has the same problem.
Garbage collection delays? Ive never seen this as a big problem. With good coding practice (create fewer objects, reuse etc) this becomes invisible.
Memory swapping? You must have a mighty large java app or very little memory. As for java being a memory pig that is questionable since IE, mozilla, and about a dozen other apps I run on my computer consume more memory than my java apps like Azurues. Go figure.
It insists on reinventing everything, it insists on abstracting everything, and it insists on total control over the environment.
I just wrote a java app the other day that embeds an activeX control within it. Worked great. Ive written C++ apps that use Java (gcj) and it worked great. I think youll have a hard job trying to prove that strange view.
I think it condemns Java to a perpetual "behind the scenes" existance, growing ever more baroque appendages in its invisible niche, until its burdensome legacy is swept away by something more open
Java is already open. Go look at projects like GNU classpath or Kaffe. Javas invisible niche is kinda hard to miss since it covers most IT departments here in the United States and abroad. A bit hard to miss. You can go to SourceForge and see that it is currently almost exceeded the number of C and C++ apps.
Your example more fits C# at its ilk which has had very slow adoption.
I find it amusing that Java is dying because it hasn't totally supplanted Win32 as a desktop application environment. More and more I'm seeing companies replacing their aging in-house applications with Java web services. Where several years ago an internal application might be a VB5 front-end to an Access database today is likely a full fledged web service running on a central server. Such applications are available over a VPN, dial-in modems, or even bridged networks with little trouble. The data is also centralized meaning there's no synch issues within the office. When Mary updates a record Sam gets that information immediately. These applications are also client agnostic so they'll run on just about anything with a web browser.
Centralized web services are capturing the hearts and minds of a lot of companies anymore. Clients for such services can be thin or fat and can run whatever OS is practical. An office full of iMacs can access a web service just as well as an office full of HPs running Linux. If Java is ditched down the road for Perl or Python the database server isn't going to go tits up.
Java's death never really happened, it's just that its success came from an area no one really expected early on. Perl's met with similar success. What started off as a language to parse server logs and turn huge data files into meaningful information became the premiere CGI language on the web. While a successful word processor might never be written in Java, the language and environment are far from dead.
I'm a loner Dottie, a Rebel.
Maybe someone should work on fixing those things that encourages most people to write java improperly. If most people are using it incorrectly, then that points to issues with the language that need to be resolved.
"Yes, but isn't it symptomatic of defects in the language if many programs written in it leak memory? "
No, it's not symtomatic of a bad language, but that a lot of programmers don't know how to properly manage their objects. Whenever I'm called over to look at a java memory leak it's one of two things - people put hard references in static containers that never get cleared, or they initialize objects with circular reference that don't unwind properly. Blaming Java for bad programming is just wrong.
People often use garbage collection as an excuse to be lazy. "I don't have to worry about it, the garbage collector will take care of it". I'm sorry to say, garbage collectors are not not the silver bullet to bad programming.
Java's got a lot of problems in the standard class libraries and type model. When I started working on it I found the lack of dynamic types and the inconsistent classes are a big problem: I wanted to write wrapper classes around everything just so I could get the bookkeeping out of my hair. Apple's Objective C class libraries (Cocoa) have the same problem to a certain extent, even with dynamic types to help.
I'm not sure that MVC is the problem, though. It's been widely used in a variety of systems since the late '70s on processors that aren't even pocket-calculator quality today. The Smalltalk I played with in 1982 was running on a Dorado that must have managed all of a million instructions per second, and my NextStation (however that's supposed to be capitalised) has a very responsive GUI on a 68030... it actually feels faster than OS X on a G3/400. Java's implementation of MVC may be particularly bad, but the inherent overhead in the design can't be that great if machines as anemic as these can manage it well.
I would put the responsibility for Aqua's performance squarely on the shoulders of Quartz. Quartz is a high quality rendering engine, but to get decent performance out of it you need a good video subsystem and enormous amounts of memory to copy and composite the high resolution pre-rendered bitmaps... not to mention enough processor time to do print-quality rendering in the first place. I expect that Microsoft's next generation video subsystem will be equally aggressive.
>I find it utterly hilarious that people say that Swing proves Java is fast, because the really fast parts aren't written in Java.
Me too.
Java apologists are funny that way.
When you get right down to it, a tight-loop algorithm using only native keywords and operators CAN'T be as fast in Java; it's interpreted.
All the cognitive dissonance you can throw at that fact can't change it, but the apologists keep trying anyway.
To be fair, I *do* like Java; as a teaching tool so students can pick up programming basics.
But if I had my way, everyone would learn assembler FIRST, because to my mind, that is the only true way of understanding what is REALLY going on in the computer.
I think that that is also why C (and C++) are so succesful and will never go away; they're the languages that map closest to assembler and are therefore relevant.
Until we design a computer that DOESN'T operate on the same principle as current ones do, C and C++ are never going away, and Java will always need apologists.
I don't know the meaning of the word 'don't' - J
the real question isn't why does it take so much more code to do the same thing. It is this. If you wrote it in Perl, how well would it scale to handle large number of concurrent users and how easy would it be to write a database cache in Perl. On the otherhand, you can use any number of mature ORM solutions to do that, without having to re-invent the wheel. absolutely, it will take more time and people to code, but it would only take 5 guys if you're talking about junior developers. A single senior level developer would be able to build it by himself in the same amount of time as a Perl expert. In the end, the Java guy would have to write fewer components to reach the same level of scalability.
Urm why would you "copy" all the data from the model to the view when using MVC? Yes, that would be inefficient but that's not a requirement of MVC, infact I wouldn't recommend it at all. I would second this sentiment. What happens when the database table has 5 million rows. You're going to read the whole table? Lazy loading was invented for a really good reason? I'm guessing the original post never had to show more than a couple thousand rows of data.
I find it utterly hilarious that people say that Swing proves Java is fast, because the really fast parts aren't written in Java.
Swing is called a light-weight gui since it has no native peers. This means there are no native widgets in otherwords. Whoever said Swing is fast?
Azurues uses SWT. SWT is not Swing. SWT uses native widgets. SWT is generally faster than swing because of this.
BUT what people dont get is why Swing exists. SWT, although faster, operates differently on different platforms and looks different. Windows widgets look different than GTK or Qt based ones. SWT problems is the same as any other cross-platform gui like WxWindows. Swing though always looks the same no matter what the platform is. This means Swing apps look and operate the same no matter what the platform.
It handles them fine.
The problem is that if you've got a circular loop of, say, 15 objects, and a reference to a single object. The GC can't get rid of the fourteen other objects (or whatever part of them are actually redundant) because there exist references to them all. If that ciruclar reference were not present, then the GC can destruct all the objects without direct references.
Note that a manually managed memory model wouldn't nessecerily help in that situation - if you free() the objects you no longer need, not noticing that there is a cirular reference, you can end up with a particularly painful to sort out segmentation fault if you later acess that ciruclar reference (probably in a call to free() itself).
But that's not what Java is being used for. The most common usage of Java is for high volume dynamic web sites such as Amazon.com and most online banking systems. The combination of Java servlets, Java Server Pages and Java based web engines (WebSphere or Web Logic for example, or even Apache and Tomcat) are becoming the most common usage of Java.
I work at a major California bank and have worked on various web based applications for about 9 years. Java is the standard for writing those types of dynamic web apps. For example. When you want to see your financial summary you wouldn't expect that there is somebody writing a web page just for you every time to make an ATM transaction would you? Of course not. You log in and we identify you. Then we go to an Oracle database or a bank host system and get your transaction history. We load that into a data object and pass it to a JSP which dynamically creates the web page with your transaction history. Java excels at that kind of application. And by the way, I can develop my code in Windows 2000, move it to a Linux box to do some basic testing, and then move it (all without recompiling) to an IBM AIX Unix box and have everything work the same on all these different environments. That makes my job easier.
So we need to stop comparing apples to oranges and saying things that essentially sum up to "A badly written Java program is slower than a well written C program" or "Java was slow 6 years ago so it's still slow today" or "I don't agree with the language designer's choice of [properties, no operator overloading or whatever language peeve you have]". Look at how the language is actually being used and you'll see that Java is indeed alive and well.
Good grief, have the pills worn off already?
1. Strangely, despite developing in Java for years, I've never once met James Gosling or anyone else involved with developing Java. Clearly I'm doing something wrong. I don't actually believe that using Java in any way constitutes an approval of the lifestyle and behaviour of people I have never met.
2. Yes, you're right. Java stops you from drawing anything to the screen if its inbuilt filters detect anything 'pretty'. Or could it be that lazy programmers develop ugly apps? I'll admit that a good GUI takes some effort in Java, but I can choose to do something about it.
3. It might be slow, but at least it knows the value of the CAPS LOCK KEY
4. Imagine.. Microsoft submits c# to the ecma. Then they change it, breaking hundreds of APIs in the next version and submit that to the ecma. But it's OK, because it's a standard. Sun on the other hand have managed to release seven major versions of Java without too much problem, support deprecated APIs beyond all reasonable expectations and provide comprehensive validation tools to allow people developing JVMs to guarantee that they are compatible at many levels.
5. Not correct. For that matter, has Mono been ecma approved, and has it any assurance that Microsoft won't close it down for relying on patented Microsoft technology? Is Mono guaranteed to be compatible, and to still work when Microsoft upgrades to the next version? So far Mono is the only other implementation of Net. Compare that with the huge eco-system of languages and JVMs that have been developed around the Java platform.
But that is the two-edged sword. All Java apps look and function like Java apps - no matter the underlying OS. My Windows' users want apps that function like all other Windows apps they use - same for the MacOS crowd. Swing only ensures that we can put a pretty somewhat native-face on the code.
The Windows users should not care that its a Java app and thus people they don't know who run the app on a Mac will get the same experience. This is the flaw of Java Swing.
Chip
Java is a good language. Yes, there are issues, but they could be resolved by Sun fairly easily. But, in most cases, Java simply isn't needed. Statistics show that the vast majority of software applications being developed are not "mass market" type apps but rather stuff that is used in house. Most shops have standardized around one platform or another so cross platform isn't really an issue. And, when it is, it's usually trivial to edit C code and recompile for the new arch.
Lastly, let me tell you a little story: I am currently launching a new startup aimed at developing a kiosk for the entertainment industry. Originally, everyone said I simply *had* to write my software in Java because of an infinate number of reasons. Even as an experienced programmer, I was dumb enough to buy into it and try. Within a few weeks the software had become so slow and bloated that I knew I had to find something else. Where do you think I went?
Python with the WX extensions.
Python offers me everything Java can (WORA, Speed, Good GUI enviroment, etc) and is absolutley painless to learn. In fact, I am LEARNING the language AS I write the new software and it's not slowing me up at all. There are times I have to go back and fix things but usually it's pretty straightforward. Python is, to me at least, a Java killer.
I think that Java has some strong points. But, ultimately, it's no stronger that some other languages out ther (think C++, Python) and in some ways weaker. Sun needs to do something to get Java back on track. They can save the language but they need to drop the arrogance and get back down to basics.
Anthony Papillion
Advanced Data Concepts, Inc.
"Quality Custom Software and IT Services"
Some turtles are oddly enough, fast as heck.
Even box turtles can go really fast when they want to. (Oh crud, where did the little bugger go? Ahh!!!)
I think it'd be nice if Sun did some sort of multi-platform automatic binary distrobution system instead of that darn VM, Java itself is a nice language, the API is simple to use for many many things, the only issue is the darn VM!
If compiled binaries were more common, or even some sort of limited compiled binaries, compiled to the LOWEST level possible and still be run in a sandbox, I think Java would have a better chance.
I mean heck, how many plateforms are there REALLY browsing the Internet? Three: Windows, Macintosh, Linux.
For most applets, multibinary support would not add THAT much more size to the applet, since most of the size of an applet is likely to be in the graphics and sound department anyways.
Oh yah, talking about graphics and sound:
Sun: STOP IT WITH THE MINIMAL LEVEL OF SUPPORT CRUD!
2.4Ghz machine;
800x600 resolution;
Instanciating a new Color object to draw random lines: 100% of my CPU use.
Head --> Wall
*POUND* *POUND* *POUND* *POUND*
stupidstupidstupidstupid.
This is not even counting how slow doing other graphical operations is, ugh! Please, sun, optimize Swing on a per machine basis!! On Windows it should automatically take advantage of DirectX, on OSX, Quartz, on Linux, umm, whatever Linux uses (MESA? Err, no clue).
Annnnyways. Aside from the, umm, performance issues (which ARE a killer), and the graphical issues, oh, yes, wait, one more mini-rant on graphics and Java.
People complain that making a GUI in Java is a pain, indeed, it IS a pain, but you know, compared to other APIs, it is not ALL that bad. Just a bit odd at times, having to work with a lowest common denominator toolkit. Actually it is NOT truely crossplateform, as the dude with the Mac OSX Laptop in my class wrote GUIs that didn't "look right" on Windows and the rest of the class on Windows wrote GUIs that didn't look right on his box. ^_^ Oh well, they were USEABLE more or less, only a bit of overlap between elements, hehe.
Yah, umm, that was good for a couple of laughs.
Oh yah, the language.
Fun to program in, very interesting, makes me WANT to program, easy to use.
Just performance bites. Horribly.
Need help treating your acne? Come here!