Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

Write Once, Run Anywhere?

By Blarney in Op-Ed
Thu Oct 10, 2002 at 10:25:31 PM EST
Tags: Software (all tags)

The programming language Java gains much of its popularity from its platform-independant nature - "Write once, run anywhere", as Sun Microsystems, the creator of Java, claims. Your Java program should run, without any code changes, on any computer with a Java Virtual Machine available - and JVMs are available for Linux, Windows, Macintosh, Solaris, IRIX, and many other operating systems. However, in practice things are not so simple, even for quite trivial applications.

I had an idea for a simple online toy - nothing serious - just something fun that multiple users could play with. I was planning to use PHP, Apache, and MySQL for the server side of this project. This combination of a web server, a server-side programming language, and a database is easy to use and popular enough that I shouldn't have too much trouble finding a webhost with this software installed. However, I needed a way to make a more graphically sophisticated interface than HTML is able to handle - so naturally I thought of using Java.

A popular way of creating sophisticated interfaces for websites involves use of Java applications known as Applets, which can be embedded in a webpage as easily as an image. The browser runs the Java program inside a "virtual machine", a simulated computer which works the same way whether the browser itself runs on Windows, Mac OS, or any other supported Java platform. Anybody with a web browser can use your program without you worrying about compatibility issues - truly a dream for a Web software developer. So I began my hobby project by coding up a simple applet and testing it on various browsers - Microsoft Internet Explorer and Netscape on Windows, Mozilla and Netscape on Red Hat Linux 7.2, and Sun's own Appletviewer on both Windows and Linux. I was shocked to find out that my applet did not, in fact, work on all platforms!

The applet functioned perfectly in Appletviewer and IE, but on Mozilla I was plagued by a bug where buttons did not work - the JVM did not even report the events associated with these GUI components to my application for them to be processed. Further investigation showed that this only happened when I had a TextField on my applet. Fortunately, installation of the plugin for the most recent JVM, version 1.4.1 for Linux, cured my problems. I was happy for a few minutes, despite the annoyance of finding out that Sun had released a completely broken JVM which they could not have possibly approved had they ever bothered to actually use it. However, I had a color picking dialog which crashed on Netscape when the scrollbars corresponding to RGB color values were moved in page-size increments, but not when they were dragged manually or moved in small increments. The helpful folks on IRC informed me that Netscape crashes all the time, so I decided that this was, in fact, normal Netscape behavior and considered the issue resolved. Again I was happy....

Until a very kind and helpful gentleman, to whom I do not wish to cause trouble by naming him in this rant, was kind enough to test my applet on his Apple Macintosh computer, running the gorgeous Mac OS X operating system. The control buttons were so large that the row of them extended past the boundaries of the applet window itself, rendering many vital controls invisible! Furthermore, my color picking dialog did not display the current color properly. I had been hoping that the FlowLayout object I had instantiated and attached my buttons to would automatically resize and move them to fit on the applet interface automatically - but I was sadly disappointed. I redesigned my GUI to use compact, space-saving Choice controls rather than the bulky buttons. Still the nagging color-picker dialog issue remained...

Today, I managed to find a Macintosh computer running IE for OS9 at a library to test my applet on. The new compact layout worked fine, but the color-picker still didn't update when I changed colors. Forcing a refresh by dragging the dialog offscreen and back caused the update to occur. Apparently, the setBackground API call on a Label object does not force the component to be redrawn on the Mac OS platform, and repainting must be ordered. As this would have no forseeable harmful effects on any platform, I of course added this API call after the setBackground. However, a more serious problem was readily apparent.... setBackground had no effect whatsoever on a Button control. Buttons are always gray with a black background, and I could no longer have a Color button which served the dual purpose of bringing up the color dialog and displaying the current color. The color dialog had a list of most recently used colors stored as a row of colored buttons - which became blank, featureless, mystifying objects on OS9 rather than a space-saving, easy, and aesthetically pleasing way to pick from a few common colors.

Further experimentation on the OS9 Macintosh revealed that my applet was not notified when the Escape key was pressed, that mouse events did not properly report the SHIFT key being pressed during a click or drag, and that there was no way to enter a right-click event. The Macintosh of course had only one mouse button, but the common combination of holding down the Apple key while clicking did not produce a right click alone - rather, it produced a left click followed by a right click. This requires some recoding to ignore the superfluous left-click - but discarding a left-click immediately preceding a right-click is likely to injure functionality on other platforms.

So it seems that I cannot, in fact, run the same applet on Windows, Linux, Macintosh OS9 and OSX, and other platforms that users might wish to access my future webpage with. I may use the System.getProperties() API call to determine what system my applet is running on, and run different code tested and optimized for each platform. The entire user interface may have to be designed in several platform-dependant ways to provide proper functionality. At his point, I will no longer be enjoying the Write Once, Run Anywhere functionality that Java is so famous for, and I will unavoidably neglect some perfectly Java-capable platforms as I do not have the resources to test on every platform. Perhaps this problem of mine is due to the fact that I am merely a hobbyist and not a Java professional, maybe there is a way to make everything magically work out - but probably the goal of true platform independance for applications is still an impossible dream. I look forward to the day it truly comes to reality.


Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure


What should I do?
o Get the applet to run on MS Windows and be satisfied. 6%
o Use System.Getproperties() to run multiple code paths for different platforms. 11%
o Forget Java! Write an ActiveX control in MS Visual Basic instead. 5%
o Write multiple applets, completely disregarding Write Once, Run Anywhere. 10%
o RTFM, you incompetant wannabe! 36%
o Write angry letters to Bill Joy. 30%

Votes: 96
Results | Other Polls

Related Links
o Java
o Apache
o Applets
o version 1.4.1
o FlowLayout
o setBackgro und
o System.get Properties()
o Write Once, Run Anywhere
o Also by Blarney

Display: Sort:
Write Once, Run Anywhere? | 102 comments (74 topical, 28 editorial, 0 hidden)
So what? (4.00 / 1) (#2)
by l3nz on Wed Oct 09, 2002 at 04:03:12 AM EST

It's well known that applets raise such issues - that's why nobody actually uses them for web page interaction.

Popk ToDo lists - yet another web-based ToDo list manager. 100% AJAX free :-)

Well known.... (3.66 / 3) (#5)
by Blarney on Wed Oct 09, 2002 at 04:15:58 AM EST

I have books about Java, I have read Sun's API Documentation, and I have Googled for Java applet programming sites written by various hobbyists. None of them mentioned this sort of platform-dependant idiocy! Certainly there must be rumors among people who have used Java that, in fact, applets are a horrible idea, but it's not exactly what I'd call a mainstream piece of knowledge yet. Perhaps this article can be a good start towards informing the general public.

[ Parent ]
Write once debug everywhere. (4.75 / 4) (#13)
by Anonymous Hiro on Wed Oct 09, 2002 at 05:05:19 AM EST

Write once, run anywhere is hype.

A number of mobile phone vendors fell for it. Then they found out that since phones have different sized/shaped/colour screens, you can't just write one game and run it on all phones, even their own phones!

Doh. Should have been obvious, right? Somehow the hype must have clouded their judgement.

It's the same thing for larger platforms - there are other differences to stumble on.

Java on smartcards could work tho, but that's niche, and why not Forth or Lisp on smart cards for that matter?

The level of write once, run anywhere that Java has is the same that Perl, Python, Lisp, Tcl, etc have. If you limit yourself to certain stuff only, then yes it works. I've run a perl webmail program on both IIS on NT and Apache on Linux - same code, no modifications. Worked just fine.

But once your program starts getting interesting and goes beyond "take inputs in text, calculate stuff and print results in text", the hype falls apart.

So they've started moving the goal posts - Java on the server side. But then who needs write once run anywhere when you're picking the platform? Server apps run just one place - on the server.

Your users don't really care if your server apps are in Fortran or Cobol, just as long as they work.

Unless they've got pointy hair I suppose ;).

[ Parent ]

Another browser-embeddable GUI... (none / 0) (#60)
by unDees on Wed Oct 09, 2002 at 06:40:26 PM EST

I've created non-trivial GUIs in LabVIEW that have behaved consistently across a few platforms. LabVIEW interfaces can be embedded in a Web page with the processing done on the server, or can be run entirely on the client side with the free LabVIEW Player (sort of like downloading a .jar file and running it in appletviewer).

Granted, LabVIEW is pricy and controlled by one vendor, and the software doesn't exist on as many platforms as Java, but it goes to show that not every cross-platform project is as fraught with difficulty as the one in this article.

Your account balance is $0.02; to continue receiving our quality opinions, please remit payment as soon as possible.
[ Parent ]

Webstart (4.50 / 4) (#4)
by gromgull on Wed Oct 09, 2002 at 04:14:46 AM EST

is the solution for all yours problems... No time to explain no, try google, bus basically it removes the hassle of dependencies and library nonsense from running Java applications, and it is bundled with the newest jdk.
If I had my way I'd have all of you shot

webstart (none / 0) (#9)
by starsky on Wed Oct 09, 2002 at 04:35:55 AM EST

having just read about that, surely that makes Java non-platform-independant!

In fact, it IS platform-dependant, it just depends on all platforms supporting the Java platform!

So the issue here is surely that the JVM's are not being written well enough for each platform, no?

[ Parent ]

Why are they doing this? (5.00 / 2) (#10)
by QuickFox on Wed Oct 09, 2002 at 04:36:23 AM EST

Long ago I had similar experiences. After about two months of more than full-time work I just had to give up and throw it all away. That's quite some investment thrown away to get nothing at all in return.

That was years ago. I was hoping they had resolved the issues by now. Too bad they haven't. I wonder why.

Give a man a fish and he eats for one day. Teach him how to fish, and though he'll eat for a lifetime, he'll call you a miser for not giving him your fi

Interesting definition of popular & sophistica (5.00 / 4) (#11)
by gnovos on Wed Oct 09, 2002 at 04:38:41 AM EST

A popular way of creating sophisticated interfaces for websites involves use of Java applications known as Applets

As a Java developer with nearly seven years of expierence, I can tell you, unequivicobly, that "applets" are not my first choice when developing anything.

A Haiku: "fuck you fuck you fuck/you fuck you fuck you fuck you/fuck you fuck you snow" - JChen

Shame (2.50 / 2) (#16)
by Herring on Wed Oct 09, 2002 at 05:45:35 AM EST

It's a shame that they are so crap. You could do some pretty good stuff with applets talking to servlets (via XML?) if it worked properly. Plus it would look great on your CV/resume.

Also, applets may be crap, but they are nowhere near as fuckwitted as downloading native executable code to run on your machine with your user privileges. Whoever thought that was a good idea?

Say lol what again motherfucker, say lol what again, I dare you, no I double dare you
[ Parent ]
Agreed (4.33 / 3) (#18)
by Cloaked User on Wed Oct 09, 2002 at 06:01:10 AM EST

Applets are, in fact, a damn good idea. Network-aware applications running in a safe, sand-boxed environment, that you can write once and then run on any client machine with the necessary software installed (i.e. a browser with Java support).

I was looking at writing one for a project at work once - it would have been perfect for some of the requirements that the client had (real-time updating of a list of incoming orders, secure access to order details, etc - all doable in plain HTML, but nicer with an applet/application).

A short discussion with our most senior Java programmer, who had worked on our only applet, convinced me that it was not the way to proceed. He'd had a nightmare of a time on the applet that he'd worked on, had worked on several in the past, and did not recommend it.

Like many things, it's a great idea, that unfortunately has been rendered all-but unusable in practice.
"What the fuck do you mean 'Are you inspired to come to work'? Of course I'm not 'inspired'. It's a job for God's sake! The money's enough and the work's not so crap that I leave."
[ Parent ]

Actually ... (5.00 / 1) (#33)
by Simon Kinahan on Wed Oct 09, 2002 at 07:59:37 AM EST

This is done quite a bit for proprietary applications that require "push" features in a web browser. However, the usual way of doing it, at least in my experience, is to use a GUI-less applet to communicate with the server, some kind of nasty DHTML technology to create a GUI, and lots of gungey Javascript to tie the two together.

This tends to result in a solution that is far from platform independent, and which depends on a obsolete technology called LiveConnect, invented by Netscape, that lets Java and Javascript talk to one another.


If you disagree, post, don't moderate
[ Parent ]

/Agree (none / 0) (#87)
by Gailin on Fri Oct 11, 2002 at 06:34:12 PM EST

I would definitely have to agree with you.  As Java developer myself, I look upon applets as being the worst thing that happened to Java.  It has caused so many misconceptions due not only to incompatibilities, but also when it does run, the speed at which it does so.  

On the other hand, as a developer writing J2EE apps for a large bank, I can say that it performs remarkably well on the server.


[ Parent ]

i doubt that (5.00 / 1) (#25)
by nex on Wed Oct 09, 2002 at 07:00:34 AM EST

> ... installation of the plugin for the most recent JVM, version 1.4.1 for Linux,
> cured my problems. I was happy for a few minutes, despite the annoyance of finding out
> that Sun had released a completely broken JVM ...
from sun, you downloaded a JVM that works pretty well. i doubt that the completely broken JVM that came with mozilla also was from sun. can anyone confirm/falsify this?

The browser... (4.50 / 2) (#27)
by vitriol on Wed Oct 09, 2002 at 07:13:57 AM EST

Is responsible for dispatching events to the JVM. Your bug was likely a mozilla/oji bug rather than a JVM bug (though there are plenty of those too). This is why Java in the browser sucks and nobody uses applets anymore - native integration is a bitch. If you want rich UI in a browser, use Flash, Java is for enterprise/distributed applications and server side programming. This is all really old news. By the way, the letter should probably be addressed to James Gosling rather than Bill Joy.

[ Parent ]
not really (5.00 / 1) (#32)
by nex on Wed Oct 09, 2002 at 07:46:58 AM EST

> The browser Is responsible for dispatching events to the JVM
yes, of course -- the browser has to provide an applet viewer. if a mouse-click-event goes directly to the applet or to the browser first is implementation dependent, but the dispatching you mention is a rather trivial issue and not a big source for errors. it is definitely not the reason why "Java in the browser sucks".

a much bigger issue -- the one i was actually aiming at in my comment -- is that many browsers (this is particularly true for older ones) don't use the system's default JVM, but their very own, built-in JVM. and most of these are really crappy. for example, the internet explorer's built-in JVM never supportet any java version above 1.1, so developers had to use the AWT instead of Swing. many popular applets like sodaplay are still 1.1.

[ Parent ]

Microsoft JVM (5.00 / 1) (#70)
by traphicone on Thu Oct 10, 2002 at 04:57:46 AM EST

Actually, the Microsoft Java virtual machine formerly distributed with Internet Explorer is about the best thing that ever happened to client-side Java. There isn't a VM out there which is more compliant with the Java 1.1 specification, and the efficiency of the bytecode interpreter is leaps and bounds past the alternatives.

Of course, they never implemented anything past the 1.1 specification, which is a damned shame, but you can thank Sun for that. Still, however, it is not too difficult to write your own windowing toolkit under 1.1, and many companies have their own custom libraries to use instead of Swing.

"Generally it's a bad idea to try to correct someone's worldview if you want to remain on good terms with them, no matter how skewed it may be." --Delirium
[ Parent ]

question: (1.00 / 1) (#72)
by nex on Thu Oct 10, 2002 at 07:00:11 AM EST

it's sun's fault that MS never implemented a VM past 1.1? i always thought they didn't do it because in the first place, they wanted to jump on the java train and assimilate the whole thing, so they wrote a VM, but then they were pissed of by sun because sun wouldn't let MS gain much control; consequently, MS gave up java support (and started thinking about their own java clone, which amounted to C#). as far as i see the issue (but i don't really know much about it), sun pissed MS off, but rightly so.

[ Parent ]
Native Integration (none / 0) (#98)
by vitriol on Tue Oct 15, 2002 at 04:31:05 AM EST

but the dispatching you mention is a rather trivial issue and not a big source for errors. it is definitely not the reason why "Java in the browser sucks".

Native integration certainly isn't trivial. Your insistence that it is speaks volumes about your lack of experience. The reason why "Java in the browser sucks" boils down to many hairy integration issues regardless of which browser and JVM we're discussing. This event dispatch bug is merely another example of the same fundamental problem: Integration is hard.

People doing active Java applet development use the Java plug-in to embed Java2 in IE and NS. Browser VM non-compliance is not an issue.

[ Parent ]

Applet vs. Application (4.40 / 5) (#28)
by snakey on Wed Oct 09, 2002 at 07:21:25 AM EST

For what it's worth, I write Java applications, and they work really well on Windows and Linux implementations of the Java VM. I have never really got into applets, and I suspect that the poor implementations of the Java standard are what is at fault here, not the language itself. A VM implementation is not a trivial task, however, as anyone who has tried it will know..

I wish more people were aware of the differences between applets and applications before bashing Java! :-)

Applets made Java successful (4.00 / 2) (#31)
by orangecutter on Wed Oct 09, 2002 at 07:43:55 AM EST

Sure, they're not great to write an in-browser wordprocessor, but they are what allowed the early adopters to try Java out initially with minimal effort and maximum results. And so they kick-started its popularity.

Sort out your work problems by talking to others
The shame of early applets. (none / 0) (#71)
by traphicone on Thu Oct 10, 2002 at 05:16:41 AM EST

Early applets were, more often than not, horrible beasts consisting of scrolling text banners, slide-show photo albums, calculators that didn't quite work, and eventually the nefarious Java Lakes.

I remember a few years back, Sun couldn't seem to shake the popular conception that Java was simply a tool for creating inane spangles used by fourteen-year-old girls and middle-aged science teachers on their home pages to add a little sparkle. Frustrated, they ran, in huge lettering on their website, something to the effect of, "Java is more than just a flashy way to liven up your site!"

"Generally it's a bad idea to try to correct someone's worldview if you want to remain on good terms with them, no matter how skewed it may be." --Delirium
[ Parent ]

The pattern is... (4.50 / 4) (#34)
by mirleid on Wed Oct 09, 2002 at 08:21:13 AM EST

...that all the stuff that you mention relates to the graphical capabilities of Java. As you probably know, the windowing toolkit's implementation is native. This means that you are faced with the old problem where you need to use a unique programming interface to handle several platforms, but the windowing is done quite differently across all of them.

This is not Java's fault, it is rather the fault of the little quirks and ideosyncrasies that different windowing platforms exhibit. Now, if you can come forward with complaints on the functioning of java as a language rather than on the functioning of underlying layers (which are fundamentally different and can't be abstracted), then I'm willing to listen to your case. Otherwise, I recall having seen old newsgroups on stuff like the RogueWave windowing toolkit (dead and gone), which also failed spectacularly because of the same factors...

Chickens don't give milk
don't use AWT. (4.00 / 1) (#36)
by delmoi on Wed Oct 09, 2002 at 08:59:08 AM EST

Swing works better, or you could write your own interface stuff.  I don't think AWT provides much by the way of guiness that DHTML dosn't these days.  Are you just using java for input?
"'argumentation' is not a word, idiot." -- thelizman
In my limited applet experience... (5.00 / 1) (#37)
by jw32767 on Wed Oct 09, 2002 at 09:23:18 AM EST

...from a couple years ago, a lot of the problem is the different versions of the jvm that ship with browsers.  For example, back in the day Netscape shipped with 1.1.6, IE with 1.1.8, neither of which used Swing.  I always though that there needed to be an easier way of reving the browser's jvm, but I'm not sure if they have come up with one.

Krups, not only can they shell Paris from the Alsace, they make good coffee. - georgeha

These views are my own and may or may not reflect the views of my employer.
Applets suck (4.00 / 1) (#39)
by jabber on Wed Oct 09, 2002 at 09:28:02 AM EST

They're crippled, and for anything useful, I'm afraid they're just plain broken.

Java can be a beautiful thing. I take advantage of the WORA of it daily, but I've avoided using applets for anything professional.

Anywhere I've seen applets used in a professional capacity, they've been more picky than an application to do the same thing would have been.

Initially, they were a cool and promissing thing, way back when. Now, I think they've become a liability. Consider writing an application to do the same thing. Then you'll only have to worry about having a properly configured runtime (of the correct version of the VM) on each target machine. :)

[TINK5C] |"Is K5 my kapusta intellectual teddy bear?"| "Yes"

Alternatives (5.00 / 1) (#41)
by j1mmy on Wed Oct 09, 2002 at 10:06:36 AM EST

If you want to embed something applet-like but more consistent across platforms, consider Flash or Shockwave. Shockwave does have a robust scripting language and is quite flexible. You might also consider Javascript, depending on the complexity of your application. Installing Java may not be an option for all visitors, too.

Flash/Shockwave EULA? (none / 0) (#50)
by Anonymous Hiro on Wed Oct 09, 2002 at 02:16:04 PM EST

I don't use either but I heard there were terms like:

2. License Grants
(c) You agree that Macromedia may audit your use of the Software for compliance with these terms at any time, upon reasonable notice

Wonder what's reasonable notice ;).

[ Parent ]

Flash/Shockwave (none / 0) (#52)
by Ludwig on Wed Oct 09, 2002 at 02:25:59 PM EST

"Installing Java may not be an option for all visitors..."

Installing Flash may be an option for even fewer visitors. Disregarding the issue of the user's permissions to install software in the first place, Macromedia has been pretty halfassed about providing a decent selection of binaries. Try finding a player for non-x86 Linux, for example. Good thing they bothered to do versions for Compuserve and HP-UX, though!

[ Parent ]

Installing Flash (none / 0) (#63)
by j1mmy on Wed Oct 09, 2002 at 11:23:52 PM EST

I've found Flash installed by default far more often than Java. Java doesn't exactly have wide platform support, either, though I haven't checked on the blackdown project lately. I don't know how many os/arch combos they support.

[ Parent ]
Old news. (4.00 / 1) (#42)
by porkchop_d_clown on Wed Oct 09, 2002 at 10:47:41 AM EST

Developing Java apps was my job for a couple of years and it was insanely frustrating. Eventually we just started using Java on the server to render HTML forms.

But - for your Mac rendering problems - the problem there isn't the Mac but the way you designed your GUI. I'm betting you hard coded positions and sizes rather than letting the layout manager size and position everything for you.

I'm not dissing you - using the layouts can be really frustrating. Another possibility is to tell java to use a specific look-and-feel instead of taking the default. That's how I get PCGEN to work.

Once one sock is sucked, the other sock will remain forever unsucked.

WORA (5.00 / 2) (#43)
by FortKnox on Wed Oct 09, 2002 at 10:53:14 AM EST

The write once run anywhere is what gave java a 'jump' in the industry, but, today, the reason java is popular is the J2EE packages.

The advantages J2EE gives developers over other web languages (PHP, ColdFusion, Perl, etc...) is why most large companies want Java on their websites. Granted, the main competitor of Java on the web is .NET, and Java gained its advantage (at least, for now, while Mono is still incomplete) by being available on more than one platform; but features like EJBs and taglibs really puts Java above the rest of the web languages (at least for larger applications that will truely take advantage of the technologies).
Yes, shrubberies are my trade. I am a shrubber. My name is Roger the Shrubber. I arrange, design, and sell shrubberies.
As a Mac OS developer... (5.00 / 1) (#44)
by DLWormwood on Wed Oct 09, 2002 at 11:06:13 AM EST

...I say you should not focus too much effort on getting your UI to work under OS 9 unless you know that a significant chunk of your audience will use it.

Despite Sun's and Apple's efforts, I'm told that the Mac OS only properly supported (read: caught up to) the full Java API with the introduction of OS X. After upgrading to a OS X system, many websites that were broken under OS 9 just started working for me without any of them changing. Apple is only recently taking Java seriously as a development language, even though Steve Jobs still holds on to some vestigal Not-Invented-Here-like attitude with Objective-C.
Those who complain about affect & effect on k5 should be disemvoweled

Applets Suck (5.00 / 2) (#45)
by daviddisco on Wed Oct 09, 2002 at 11:09:55 AM EST

Trying to post a Java applet on a public website is, as the article makes clear, a headache inducing experience. I don't recommend even trying. Maybe applets are an effective solution on a private network where you can control the browser verion used but HTML is the only real Write Once, Run Anywhere UI language. On the other hand, Java works quite well as a server side solution. I regularly develop Java server components on my Windows workstation and then deploy them onto Unix machines without trouble. If you can code Java, you might consider writing your server side components in Java.
##I run a geography related site at globalcoordinate.com##
Most people use an out-dates JVM (none / 0) (#46)
by DodgyGeezer on Wed Oct 09, 2002 at 11:48:40 AM EST

Until more people are running something more modern than Java 1.1 with their browser, applets are always going to suck.  MSFT is fully aware of this, which is why they must have been happy when the Sun lawsuit stopped them producing more Java products.  It's also unfortunate that many web pages also use applets for unnecessary purposes.

[ Parent ]
Java is ugly. (5.00 / 1) (#55)
by Noam Chompsky on Wed Oct 09, 2002 at 04:22:48 PM EST

It's the 21st century's COBOL in terms of elegance, expressiveness, orthogonality, etc. Anyone who thinks otherwise cannot possibly have very much experience with other languages. However, Java has a matchlessly rich and uniform API:

  • threads
  • blocking and non-blocking i/o
  • networking
  • rpc (corba, rmi)
  • security api
  • relation db api
  • sound
  • gui api
  • xml
  • xslt
  • components (java beans)
  • printing, imaging
  • preferences
  • naming
  • regexp
  • text formatting
  • logging
  • zip
  • etc

    And yet, despite its turnkey api, Java is a language definition very few people can become passionate about.

    "They are in love. Fuck the war."
    [ Parent ]

  • That's an insulting comparison (none / 0) (#85)
    by Cro Magnon on Fri Oct 11, 2002 at 02:17:15 PM EST

    I liked COBOL! :)
    Information wants to be beer.
    [ Parent ]
    Windowing systems (3.33 / 3) (#47)
    by riceowlguy on Wed Oct 09, 2002 at 11:53:21 AM EST

    Alas, the vagaries of graphical windowing systems make the task of writing a simple, conceptually clean and elegant GUI API for any language that wants to run on multiple platforms a sysiphyian task.  A lot of this has to do with the *NIX world, which decided to adopt X, an extremely underspecified windowing system designed for a research environment, not commercial workstations, as its "standard" GUI.  And thus we have the fun of choosing toolkits and window managers for our Linux and other X boxen.  Fun for us geeks, to be sure: who wouldn't want another issue to get all religious about?  But it makes writing cross-platform code for them crazy.  No wonder most people cop out, get it working on MS Windows, and then quit.

    "That meant spending the night in the living room with Frank watching over me like some kind of Lovecraftian soul-stealing nightmare creature-Azag-Frank the Blind God of Feet, laughing and drooling from his black throne of madness." -TRASG0

    What? (5.00 / 1) (#62)
    by JAM on Wed Oct 09, 2002 at 08:54:15 PM EST

    At least in Linux I don't see having a choice between toolkits as a problem; show me a (mainstream and current) Linux distribution that don't install by default Gtk/Qt + GnomeLibs/Kdelibs. Moreover, Gtk/Qt are a lot more portable that the Windows API, write an app in Gtk or Qt and if you think 'portable' from the beggining it will run with little modifications on various flavors of Unix, Mac and Windows, you just have to compile statically on the platforms that don't have those libs by default, or made the installer to install the libs before the app , take a look at Gaim, Gimp for Gtk examples or KVIrc for a Qt one.

    Code an app using only the Windows API and try to run that on other platform (without emulators).

    Sorry for my engRish.
    -- Sorry for my engRish (TM)
    [ Parent ]

    except for the fact that... (none / 0) (#93)
    by joto on Sun Oct 13, 2002 at 08:08:28 AM EST

    AWT doesn't target X11. It targets Motif. Motif is hardly underspecified. It works just as well as any other commercial GUI (e.g. windows or mac).

    Now, Motif runs on top of X11, but so what, anything has to run on top of something. Even if you don't name the layers, they are going to be there (or the code is likely a mess).

    Having said that. I don't particulary like Motif. It's huge, non-free, weird to program for, and so on. But these characteristics it also shares with any other platforms native widget-libraries.

    Personally, I think the reason applets doesn't work properly is more of a political issue. Sun doesn't want to do much work on awt because their developers seem to think swing is more fun. Microsoft doesn't want to have a good JVM because they want to cripple java. Free software developers on linux don't want to touch Sun's jvm too much because of it's proprietory nature. And writing a new one (with included class-libraries) is just a lot of work. And initial failures have made people just go away from the concept, which makes it a low priority for anyone (including sun) to fix. Besides, the money is really in consulting, and applets are too simple for you to need expensive consultants.

    [ Parent ]

    Use SWING, and dont write crappy code! (4.80 / 5) (#48)
    by Warpedcow on Wed Oct 09, 2002 at 12:05:49 PM EST

    Jeezus people, it really is NOT hard to write a Java applet/application that works well cross-platform.  Just use swing, and follow the well-written, concise javadocs on sun's website.  I've been developing a web interface for a product that my company will hopefully release in a few months and we use java applets and we've tested them on many platforms/browsers and everything works fine.  Just make sure you dont write shitty code.  It really isn't that hard, people.  And make sure your clients are using a SUN JVM and not MS's JVM.  And even IBM's OS/2 JVM works well.

    Just my two cents of experience.

    Crappy code. (none / 0) (#54)
    by Anonymous Hiro on Wed Oct 09, 2002 at 02:40:32 PM EST

    Came across a crappy situation just a few years back - one of our customer's contractor was making an app for the customer's customers to use.

    Even if the users were using Sun's JVM, they often needed to make sure they were using the same version JVM as the one the developers were coding. JVM bugs, variations etc.

    Having the customer's customers download multimegabyte JVMs down dialup lines, followed by applets of few hundred KB for each web page ain't funny. Not sure why some of those applets were so big.

    What are the typical sizes of your applets?

    Why we got kinda involved - it had to work through a firewall we sold to our customer. The applets didn't use HTTP for communications, they used RMI. Doh.

    Good chance the contractors were clueless and writing crap code. But hey I'm no Java coder - if I had to do it, I'd whip up a pure webapp instead.

    BTW how do you send data from an applet back to the server?

    Coz I'd like to know if a java applet can get info from a filled HTML form, manipulate it and use the browser (and whatever proxy settings) to HTTP post/get the results to a webserver.

    That could be useful.

    [ Parent ]

    Yup (none / 0) (#97)
    by epepke on Mon Oct 14, 2002 at 10:15:07 PM EST

    And make sure your clients are using a SUN JVM and not MS's JVM.

    Sure enough. If you have this kind of control, then Java works fine. But just what part of the word "anywhere" do you fail to understand?

    The truth may be out there, but lies are inside your head.--Terry Pratchett

    [ Parent ]
    The title should be changed to... (4.50 / 2) (#49)
    by bayankaran on Wed Oct 09, 2002 at 12:34:25 PM EST

    ...Write Once and Run Away.

    Me coding a graph application using Swing displayed through applet.

    Me feels this thing sucks.

    Thinking of changing career to Apple farming.

    Write once, debug everywhere. [EOM] (none / 0) (#68)
    by NFW on Thu Oct 10, 2002 at 01:59:43 AM EST

    Got birds?

    [ Parent ]

    Works OK for us.... (4.50 / 4) (#51)
    by johnnyfever on Wed Oct 09, 2002 at 02:18:48 PM EST

    Where I work, we have an 24/7 enterprise app that is used by up to 500 concurrent users every day, all year. The interface is a Java Applet (actually, there are 1/2 dozen of them depending on which service you use).

    We've had this in production for almost 4 years now, with no Java incompatibility problems. Granted we only support the various flavours of Windoze, however those of us who prefer to do remote support on our Linux machines at home have all run the app many many times on Linux.

    Not sure about OS/X though :)

    On a slightly unrelated note, we initially ran our RMI server middleware component on NT because at the time that was the best performance we could get. Remote support on NT is so useless (can you say bsod!) and performance evened out over time, so we move it all to Solaris. All we had to do was copy the code over and start everything up. Worked flawlessly!

    Same here... (none / 0) (#58)
    by spiralx on Wed Oct 09, 2002 at 06:28:56 PM EST

    ... just about ;)

    I work for a website which uses Java applets to display live information to thousands of simultaneous users at any one time. The trouble is not in the base applet itself, it's when you come to writing signed applets that can manipulate things outside of the Java sandbox that's the trouble. Then you run into the fact that there are innumerable different ways of doing this depending on which version of Java you're running, which virtual machine, which browser, whether it's "tame" or "wild" and so on. Christ it's a fucking pain.

    "I actually think spiralx is more likely of the crime... As for motive, well, spiralx has lots of reason to hate australians from his own love life. Perha
    [ Parent ]

    DHTML and graphics.. (4.50 / 2) (#53)
    by StephenThompson on Wed Oct 09, 2002 at 02:33:57 PM EST

    I have had success with sprite graphics using DHTML. With no little frustration, I was able to get sprites that work on ie,mozilla,opera and konqueror on all platforms. Sprite graphics, combined with layers and tables can be used to do just about everything I've seen done in a java applet so far.

    What's the advantage (1.00 / 4) (#57)
    by medham on Wed Oct 09, 2002 at 06:13:59 PM EST

    Of using large binary formats such as MSQL files when you could just store information in easily parsable flat text files? That's probably your problem.

    The real 'medham' has userid 6831.

    Too bad MS dropped Java (none / 0) (#59)
    by spacejack on Wed Oct 09, 2002 at 06:35:44 PM EST

    Theirs was the only VM that actually worked and performed half decently. Hell, even the latest offerings that ship with the latest Netscape or Mozilla (and then go and replace your IE VM and won't turn off when you tell them to) have annoying cursor flicker bugs. Whatever, Macromedia picked up the ball and ran with it.

    import gernsback.image.*; (4.20 / 5) (#61)
    by Scrymarch on Wed Oct 09, 2002 at 06:58:47 PM EST

    I read your article and it made me hear the great propellers in the sky again tonight.  I was walking home and faintly heard their strong deliberate thuds above the traffic noise.  I think I saw a corner of it; I think I saw a corner of the giant polished wooden flying wing between the skyline and the clouds.

    Oh, Java applets are dead, they are another glorious cul-de-sac of tech, they are a half-dream of the Internet's birth.  And so they live on only in a cultural alleyway; in a psychic hiccup of our shared unconsciousness.  And when those beautiful Aryans on the flying wing have shaved and dressed for breakfast if they read a nouveau New York Times it is on screens of glass, mahogany and gleaming brass.  And splashing pixels on that screen are Java newslet virtual machines, ported with greatest ease onto the Tesla-energy-powered thinking vacuum tubed contraptions.

    It is an addictive, melancholic world, and you have strayed deep into it already.  The visions may soon increase their frequency and irony will not defend against their hauntingness.  

    If you have problems with it look to Gibson, who gives the cure with the diagnosis.  Hard-core and violent Nazi porn can empty you of it, and leave you torn, weak and convalescing on a modern shore.

    humpf. (2.33 / 3) (#69)
    by rev ine on Thu Oct 10, 2002 at 03:33:01 AM EST

    -1 for being whiny as well as a bad coder.

    Please elaborate: (none / 0) (#74)
    by Blarney on Thu Oct 10, 2002 at 11:30:44 AM EST

    So, it seems to be a conclusion that I am a bad coder. Can you tell me what I have done that is wrong here? Probably not, as you haven't seen any source code - but if I did post some, would you be so kind as to tell me where I have gone astray?

    Now, it is a hypothesis of mine that I am a bad coder, and that a good coder would instinctively know what features of the Java API could not be relied upon; however, I have no evidence for this hypothesis either for or against. Perhaps I am actually a good coder and Java just sucks ass.

    Simply reiterating the "bad coder" hypothesis doesn't provide anything useful to the discussion. If you could provide some evidence to support this hypothesis, it would be actually useful.

    [ Parent ]

    If you were a good coder ... (none / 0) (#83)
    by vrai on Fri Oct 11, 2002 at 03:49:21 AM EST

    ... you wouldn't be using Java ;)

    \me dons asbestos suit ...

    [ Parent ]

    BEA WebLogic vs. Tomcat (none / 0) (#75)
    by tuxedo-steve on Thu Oct 10, 2002 at 10:32:31 PM EST

    For my final project at Uni, I had to write a Java servlet that basically transformed XML input into HTML or WML. I was, at that point, well-indoctrinated into the "write once, run everywhere" ideal of Java. I believed the hype.

    So: I coded the entire project at home using the Apache Tomcat servlet environment. When the time came to present my project, I knew it worked perfectly in conjunction with Tomcat.

    But... for the presentation, it had to be deployed under a BEA WebLogic server. No problem, thinks I, it's Java: "write once, run everywhere." Differing servlet environments are irrelevant.

    So, foolishly, I did the presentation with WebLogic, without thoroughly testing it first. While the system did work to some extent, it did failed to correctly execute certain crucial functionality. Which came as a complete suprise to me when I was in the midst of my presentation, and it started throwing exceptions left, right and centre.

    Fortunately, I was allowed to re-present my project a couple of days later (under Tomcat.) The moral of the story is that "write once, run anywhere" is not necessarily true in all cases: don't merely trust that any one JVM implementation will run your code like any other!

    - SMJ - (It's not just a name - it's a bad aftertaste.)
    Java: Write once, hype everywhere ;) (none / 0) (#90)
    by Anonymous Hiro on Sat Oct 12, 2002 at 06:04:16 AM EST

    I'm not surprised about portability problems with applets, but servlets... Wow. Then again look at the config files for various servlet engines :).

    Once your program does more and more interesting things it's likely to become less and less portable.

    If it doesn't do very "interesting" things, it's just as portable using C, C++, Perl, LISP, TCL, Forth, Python etc.

    For example: I've run perl cgi webapps on IIS/NT and Apache/Linux no changes needed to app. I've run perl fastcgi apps on both Apache/Linux and Zeus/Linux - no problems as well. So trivial stuff like that is just as portable as Java, or seeing your example - even more portable.

    Java: Write once, hype everywhere.

    [ Parent ]

    A WORA success-story (4.50 / 2) (#76)
    by carlfish on Thu Oct 10, 2002 at 11:43:11 PM EST

    Applets are a really terrible place to test cross-platform compatibility, because Internet Explorer's applet viewer is stuck back in about 1995, which means you're writing user-interfaces in AWT. AWT was rushed out in order to get Java started, and then replaced by the Swing toolkit. The whole reason AWT was abandoned in favour of Swing was because AWT uses native widgets, and is therefore very hard to get consistent across platforms.

    It's certainly not Java's fault that neither major browser updated its Java implementation for five years. Sun's fault, maybe, but not Java's.

    On the non-applet side of WORA, it's a lot more encouraging. I was recently doing some consulting work for a large software-development team. As part of the job, we decided to set up an issue-tracking system using JIRA, which is 100% Java. (And which kicks every other issue-tracker's ass, but that's another story)

    JIRA comes as a "stand-alone install" with a stripped-down copy of the JBoss Application Server. At first, it was installed on an NT box that happened to be lying around, but because that box was already running $expensive_proprietary_software, it was a bit too overloaded to host another web application.

    At that point, a co-worker said, "Why don't we stick it on the AS/400?" So we did. We took exactly the same zip file that we'd installed on the NT box, unpacked it onto the AS/400, ran the startup script, and it was all working perfectly in a few minutes. It took longer to set Apache up to forward requests to the AS/400 than it had to set up JIRA on it.

    Later, JIRA's author informed me that nobody had ever tried this before (not surprising really, AS/400's aren't exactly commonplace). But because of the portability of the virtual machine, it all just worked.

    So now, whenever anyone scoffs about the value of Write Once, Run Anywhere, I hit them with my clue-stick.

    Charles Miller

    The more I learn about the Internet, the more amazed I am that it works at all.
    You smacked a bug and it got really GUI (none / 0) (#77)
    by hardburn on Thu Oct 10, 2002 at 11:45:35 PM EST

    The GUI APIs in Java suck. Let me back up. All GUI APIs suck. Java's GUI APIs suck more. For a language that is generally clean and nice to program in, their GUI APIs are a process of frustration. AWT is too primitive, and Swing is too buggy.

    GUI design is just a naturally tedious process. Unless someone really, really smart comes along and magically makes it possible to write any non-trival GUI in just a few lines of code, GUI APIs will always stay sucky. To be honest, the only GUI design I ever liked is Visual Basic. The reason being that you don't actually program the GUI--you just lay out your widgets on the screen, then add your events and any additional code. Too bad the underlieing programming language makes Python's interpreted whitespace look inviting.

    There, now I've insulted two programming languages in one sentance. If this doesn't spark a flame war, I don't know what will.

    while($story = K5::Story->new()) { $story->vote(-1) if($story->section() == $POLITICS); }

    Windowing kits (5.00 / 1) (#79)
    by MostlyHarmless on Fri Oct 11, 2002 at 12:37:53 AM EST

    Visual Basic does make it very easy to design a limited subset of GUIs. However, it positions all widgets absolutely rather than relatively: by coordinates, rather than in a table. Contrast this with Tk (as seen in Tcl and Python) and GTK, where the nested grid layouts make dynamic window resizing trivial.

    I worked with VB for two summers in projects with a significant amount of user interface code. I switched to Python the following summer and was overjoyed at not having to write extra lines of junk codes to handle the users trying to resize the window. The graphical painting of UIs a la VB is not significantly easier than creating them by hand (if you use a decent toolkit; I've never tried Swing or AWT), and this advantage does not overcome the many other downsides to VB *shudder*. Using Python, I was able to create programs that ran flawlessly[*] using native widgets on both Windows and Linux. Being able to use the same binary on multiple platforms is overrated, since it is trivial to re-package code that is properly cross-platform. More important to me is that the code distributed on multiple platforms performs as advertised (cf. this entire article) and isn't generally grody (cf. VB, above).

    [*] That is to say, any bugs due to bad coding on my part exist equally on both platforms.

    "Nevertheless, that is the theorem." - Tom Stoppard
    [ Parent ]

    Pythoncard (none / 0) (#81)
    by ComradeFork on Fri Oct 11, 2002 at 01:03:55 AM EST


    A very promising toolkit for Python which may become better than VB is Pythoncard (pythoncard.sf.net).

    Binding events to widgets is done automatically, by calling your function [widgetname]_[event].

    [ Parent ]

    Cocoa (none / 0) (#82)
    by carlfish on Fri Oct 11, 2002 at 01:12:17 AM EST

    Building an OS X GUI using Interface Builder and Cocoa is only slightly less enjoyable than sex.

    Charles Miller
    The more I learn about the Internet, the more amazed I am that it works at all.
    [ Parent ]

    Delphi, (none / 0) (#86)
    by bored on Fri Oct 11, 2002 at 06:05:03 PM EST

    By Borland,Try it... you might like it.. Its basically a nicer Visual Basic, instead of basic it uses Object Pascal. If you don't like the absolute beauty of object pascal there is a C++ version called Borland C++ Builder, not as pretty but still quite functional. :> There is even a Linux port now called Kylix. I don't know how well the crossplatform stuff works though.

    [ Parent ]
    Why do people think this is hard? (1.00 / 1) (#80)
    by Duncan3 on Fri Oct 11, 2002 at 12:40:37 AM EST

    Write your software for whatever platform, in whatever fully portable language like C or FORTRAN you wish, have the _NATIVE_ GUI code call your subroutines. Use OpenGL for any serious graphics.

    Then port the GUI, which for a medium size application will take anyone even remotely similar with the target platform at least 1 day, (mostly in converting the .bmp files to .tiff or whatever it needs)

    Do this for Win32, Cocoa(OSX), and Xwindows and you're done because that's all there is.

    Doing it this way is:
    1. Fast
    2. Easy
    3. Users get the interface they expect and know how to use!
    4. And best of all, it doesnt look like crap.

    Oh, but you wrote all your code in with the GUI code in one big file, well go read a book on software engineering or something else "Java for Fry Cooks" didnt cover.

    Once you do one cross-platform application this way, you'll realize that all the Java hype about cross-platform was a load of crap and is profoundly limiting to begin with. Besides, Java is only portable within VM's written by the same people, you have to pick Microsoft Java or Sun Java right up front.

    OK, I'll bite. (none / 0) (#89)
    by carlfish on Sat Oct 12, 2002 at 02:39:41 AM EST

    Could you please provide a link to the most complex product that you have developed in this manner?

    Charles Miller
    The more I learn about the Internet, the more amazed I am that it works at all.
    [ Parent ]

    Something similar to what he's talking about (none / 0) (#91)
    by Anonymous Hiro on Sat Oct 12, 2002 at 06:12:22 AM EST


    Uses OpenGL.
    Fairly portable if I recall correctly.
    Customizable - allows people to add extensions too - see Teamfortress etc.

    And last but not least - it's amongst the best software in its class.

    Then again, if you start with a very good programmer...

    [ Parent ]

    And the survey says, no. (none / 0) (#94)
    by carlfish on Sun Oct 13, 2002 at 09:45:12 AM EST

    Quake has minimal GUI, and what it has it draws itself. Sorry, no match.

    The reason I asked is because it's really nowhere near as simple as the original poster states that it is. The idea that, even with sufficient isolation, you can code the GUI for any significant application in a day on any platform is pure fantasy. I strongly suspect that the parent poster in this thread has never been involved in a project of the kind he describes, and probably wouldn't recognise such a project if it sat on his face.
    The more I learn about the Internet, the more amazed I am that it works at all.
    [ Parent ]

    But that's one way to do it (none / 0) (#96)
    by epepke on Mon Oct 14, 2002 at 09:59:00 PM EST

    Quake has minimal GUI, and what it has it draws itself.

    That is, however, one way of getting around the problem: keeping the UI in the application itself. I wouldn't say that Quake has minimal GUI, though. It's just not traditional WIMP GUI. Any successful game has to have a well crafted appropriate GUI.

    The self-contained approach seems to be, essentially, the approach that Netscape 6 takes. Of course, Netscape 6 is a great example of why it is not always a good approach. It violates the principle of least astonishment. Every user has an expectation that a new application will seem familiar. This involves a lot more than widget shapes. Even for trivial applications, layout conventions and the logic of menus and control placement play a big role. Many users will not notice violations of convention precisely enough to put their fingers on them, but they'll get a gestalt feeling that an application is not terribly well designed.

    The idea that, even with sufficient isolation, you can code the GUI for any significant application in a day on any platform is pure fantasy.

    I agree. As much as I approve of the idea of isolating the GUI from the rest of the code (in an intelligent way), there are limitations, and there are far too many ways to do this wrong. The philosophy maps most easily onto trivial applications that consist basically of forms and buttons. The problem is that the philosophy may drive the GUI in an inappropriate direction. Most of the time, when it is possible to solve a problem by throwing widgets at it, there is a far better way that requires more thought and flexibility. Consider something as simple as changing the name of an icon. It is, of course, possible to bring up a dialog box with the name. This is the most easily isolatable approach, but it's pretty bad. Selecting and editing in place requires much more thought and work, but it's better (unless you don't complete the job, and expected editing features don't get implemented).

    Another problem, though, is that these constraints apply to WORA systems as well. It's very hard to do a nontrivial interface in AWT or Swing without doing a lot of custom work, and it's generally impossible to get the precision that you need to reduce the astonishment enough. Also, much as it pains me to admit it, AWT and Swing both really suck. Designing UI API's requires a special kind of person, someone who can be free and artistic but also incredibly anal-retentive, and it seems clear to me that Sun didn't have people like this on the project.

    There's an intermediate approach: have one part of the application describe the user interface in semantic terms and have another part of the application interpret those semantics and map them onto the user interface. This is somewhat analogous to font display systems that use "hints." This can work very well and has surprising benefits, but the drawback is that it is 100% programmatic and doesn't fit well onto existing layout editors. If you wanted to keep that visual approach, you'd need some new kind of semantic editor combined with previews, and I haven't seen anything like that. I doubt it will ever be produced, either, because such an approach would require a somewhat expert designer, and market forces don't seem to go in this direction.

    The truth may be out there, but lies are inside your head.--Terry Pratchett

    [ Parent ]
    Try XWT (none / 0) (#84)
    by tzanger on Fri Oct 11, 2002 at 02:13:26 PM EST

    was planning to use PHP, Apache, and MySQL for the server side of this project. This combination of a web server, a server-side programming language, and a database is easy to use and popular enough that I shouldn't have too much trouble finding a webhost with this software installed. However, I needed a way to make a more graphically sophisticated interface than HTML is able to handle - so naturally I thought of using Java.

    Try XWT -- Write your interfaces using XML and 100% (although non-OO) ECMAscript. Platform independent, fast and free. Native clients for Win32 and Linux, and Java for the rest.

    All your business logic is on the server and you access it via XML-RPC or SOAP. Very cool. Under active development and actually quite fun to use. Be sure to check out the online demos -- you can go from the utterly simple to the very complex (there's a mostly-complete outlook-lookalike IMAP client in the demo section!

    I gave up on doing this via HTML/CSS/DHTML/whatever. I gave up on trying to maintain compatibility with every browser and rev of said browser. And I've always been sick of the *clicketyclick*[sumbit]*clickclickeyclick*[submit]*clickawfuck*[back]*ohshititdi dn'tlikethat* bullshit. With XWT you make apps that run locally but are hosted *over there* and all the business logic is *over there*. Very cool.

    Just tried it (none / 0) (#95)
    by epepke on Mon Oct 14, 2002 at 08:57:56 PM EST

    Clicked on the demo and got a page that said "java.lang.nullPointerException." I must admit that I'm using an unusual system (Netscape 6.0 on OS X 1.2), but isn't that the whole point of WORA?

    As they say on USENET, plonk.

    The truth may be out there, but lies are inside your head.--Terry Pratchett

    [ Parent ]
    <sigh> (none / 0) (#99)
    by tzanger on Thu Oct 17, 2002 at 05:59:41 PM EST

    Adam keeps tinkering with the launcher. It should work now. *should* :-)

    It really is quite a cool technology but it's a little new, as you can see. :-)

    [ Parent ]
    Same results (n/t) (none / 0) (#100)
    by epepke on Fri Oct 18, 2002 at 12:27:50 AM EST

    The truth may be out there, but lies are inside your head.--Terry Pratchett

    [ Parent ]
    <sigh>^2 (none / 0) (#101)
    by tzanger on Fri Oct 18, 2002 at 02:49:57 PM EST

    It seems that Adam's having some trouble with the MacOs launcher. You could always grab the jar file and use it but I expect that I've already lost my audience. :-)

    [ Parent ]
    Nah (none / 0) (#102)
    by epepke on Fri Oct 18, 2002 at 08:06:37 PM EST

    I'll look at it, but then again, I'm a geek, and I'd work hard to get a Java applet working, too. The devil is in the details, though. A practical solution has to be something with a high degree of automatic behavior (Flash fits this pretty well). And, of course I sympathize with the trials and tribulations of getting something to work cross-platform. But still, it has to be done before we can seriously consider it a solution.

    The truth may be out there, but lies are inside your head.--Terry Pratchett

    [ Parent ]
    Conversation... (4.00 / 1) (#88)
    by Bill Godfrey on Fri Oct 11, 2002 at 08:32:44 PM EST

    A: What you reading?
    B: Some K5 article. This guy is having problems running his Java code cross platform.
    A: Why didn't he use C?
    B: I dunno.

    Bill, dunno.

    Applets not a big deal (none / 0) (#92)
    by tmullett on Sat Oct 12, 2002 at 06:52:24 PM EST

    The real promise of applets turned out to be more about deployment more than WORA. If you're charged with... what did I do this month... writing the data input and reporting applications for a sales force, just for instance. Like most companies of any size, users have a (supposedly) standard OS installation maintained by IT, so WORA has limited value when it comes to the desktop. Keeping all the salespeople up on the current version of the code without buying responisiblity for whether Suzie can print today, now that's priceless! That's not to say that Java's WORA never shines. I spend about 80% of my time at work on servlet-based systems. I develop on Win2000 with Tomcat, or if I get to work from home it's Linux and Tomcat. I deploy to Solaris running Weblogic and NT4 with IPlanet. A couple of my buddies use basically the same development platform that I do, but deploy to AS400 and OS390. There's no recompiling for different platforms, no #ifdefs to keep track of, just drop in the binary and go. It's not a problem, once you know what you're doing.

    Write Once, Run Anywhere? | 102 comments (74 topical, 28 editorial, 0 hidden)
    Display: Sort:


    All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
    See our legalese page for copyright policies. Please also read our Privacy Policy.
    Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
    Need some help? Email help@kuro5hin.org.
    My heart's the long stairs.

    Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!