JD on EP

Java and Flash make different trade offs regarding features, security, and download size. It is true that Java Applets can do things Flash cannot. On the Network/Internet side of things there are two core protocols TCP and UDP that applications commonly use. Flash only supports TCP while Java supports TCP and UDP. UDP is the lower-level protocol that multicast protocols are based on. On the local machine itself the Java api is much more extensive allowing you to do things Flash does not. Java has a different security model than Flash so that applets can ask the user for permission to do things which might be dangerous.

I think the richer UI claim for Java is a more difficult claim. I wonder why he said that.

Gosling does balance his statement this way:
"Our issue hasn't really been, can you build interesting rich Internet applications? But that it's difficult. And most of our efforts really are around making a lot of it easier."

From the interview it sounds like they will ship something in the spring that will make RIA development easier.

I'm sure the Flash Player team has received requests to allow UDP and other APIs. I think its probably fair to say they have decided not to provide those features so far because of Flash's different approach to security and player size.

Flash seems to be moving in a different direction. It looks like some extensions to what Flash is capable of - especially on the networking side - will come with player add ons that have to be installed separately by the user and only work with Adobe's hosted services or things like Connect.

In the longer term I think the trade offs developers are forced to make on each platform will be more important than the base capabilities of the "extended" runtimes.

I've heard Gosling say this before, and it was common hype at JavaOne last year when JavaFX launched.

Much of it based on common misconceptions developers have about what the Flash Player can do, but Gosling nails networking protocols as a shortcoming. I don't it has anything to do with informing the Player team per se because the security sandbox would limit most networking options. Rather I would pin this on Flash Player not having the ability to sign code, and let developers do away with the sandbox if they've been properly authenticated.

This could also be applied to other common security-related requests like removing the "About" and "Settings" from the context menus.

The other side of this is that while Java and Flash have been around roughly the same amount of time, Flash has only recently provided a decent networking API. By contrast, Java was created with networking in mind. While there are countless libraries for various networking protocols in Java, there's really almost nothing in Flash. Even the common protocols such as IRC, NNTP, SMTP/POP, etc. There really needs to be a way in Flash to protect your intellectual property should you decide to commit the time to build and monetize on these opportunities. This would also afford developers the ability to monetize with component libraries, image processing libraries, etc.

Two cents,
Kevin

Like I said, if you need a particular network protocol, make the case to the team.

UDP was in Shockwave Multiuser Server, but I didn't see that many people use it -- not even many firewall support requests -- so it's hard to read into his phrase and see that as "really falling short".

Might as well say desktop clientside Java "falls short" because Photoshop has features it lacks. There are always deltas in functionality, but you look for best fit instead.

Still, make a case, if your work needs it. (Gosling's work lies elsewhere.... ;-)

(I've never felt comfortable with code-signing myself, or at least not since Microsoft had their Verisign certificates stolen. It's just another flawed layer of complexity -- you've got to nail it initially, or else it raises more problems later on.)

Hi John,
It's funny that you mention the old Shockwave Multiuser server which I don't remember ever supported audio or video...? That was a LONG time ago. It was replaced by the Flash Communications Server which became Flash Media Server. FCS/FMS have always used TCP in part because the Flash player never supported UDP. For many years FCS/FMS developers HAVE been asking Macromedia (now Adobe) for UDP.
That's because real-time streaming of video/audio simply works better with UDP. And for efficient streaming of synchronously viewed streams, multicast, which requires UDP, is much more cost effective. Lots of people in Adobe know this. They know that real-time communications benefits from the lower latency you can get from UDP. In fact Adobe's RTMP protocol is designed in some respects to simulate UDP by dropping messages when it detects network congestion.

And who knows, aside from add ins to Flash maybe Flash will get UDP in some form or other in the future. I don't know.

I do know that Gosling's claim on the networking side at this point in time is entirely reasonable. And for a developer looking for a platform with a rich networking API or other APIs to do things like display HTML or capture the screen, Java has more to offer than Flash.

Again there are trade offs. Flash does a lot of things for the developer that takes a lot more work in Java. The wider context here is a discussion of what developers are looking for in a RIA platform.

Competition is good and there are going to be a lot more of these sorts of comparisons made. I just don't understand the richer UI claim? Did that have something to do with text and graphics handling? Anyone know?

"That's because real-time streaming of video/audio simply works better with UDP."

no dispute, there Brian, but half the grief I get using Java solutions for video conferencing (something that Flash-based Connect doesn't have) is blocked UDP.

I rate reliability and dependability (esp with having ad-hoc users) far higher than quality of the "signal". The quality will eventually come.

Hi Barry,
Sure enough. But a well designed Java client will fail over from UDP to TCP and even tunnel over tcp/http when necessary. Of course a Java developer has to do more work than just assume UDP will always work. But the platform provides the APIs you need to make it work.
Cheers,
-Brian

We spent (wasted) a few months of effort modifying our server application because the new Flash client did not support UDP whereas the older Shockwave client did. And not supporting Flash wasn't an option, obviously. It makes absolutely no sense to even begin to compare Flash to other platforms or to ask everyone to make a feature request for something as....basic as UDP. So let's not even try. Please. Just. Don't.

[jd sez: I'm not sure why comments here went so off-topic. If Gosling has anything to say about the Player's clientside success, then complaining about UDP ain't it.]