Java's biggest disadvantage (compared to Flash)

[oNyx]

Was about to blog this, but a heated debate is probably more fun.

There are many advantages and disadvantages. Since we all know about those obvious things, I'll skip that.

The biggest real problem isn't startup, download size, nor penetration. It's a relatively small implementation detail: if you're inside the sandbox you can only connect to the host you came from. Of course this a very sensible thing to do. E.g. you can't get past the firewall, connect to localhost, and exploit some vulnerability of any of Windows' services.

So, what's the problem then?

It's advertising. With Flash you can use MochiAds and the like. In a nutshell:

• you only add one file and one line of code
• ads are shown before the game or between levels
• ads are loaded from a different place
• ads can be changed later on (globally - for all copies)
• you can give your game away for free and earn even more money
• you can disable the ads on a per domain basis (e.g. don't show ads on a licensee's page)

Plain awesome, isn't it? With Java this simply isn't possible. So, you can only license your game and if it gets copied you're losing ad revenue. All you can do is adding domain specific unlocks, but that means doing domain specific builds. But all that pain doesn't necessarily yield any extra income. It only reduces the amount of unauthorized copies. Meh.

Leaving the move to Flash option aside, there are two possible solutions:

a) Allow port 80 connections even if sandboxed in upcoming versions of Java.

b) A hosting/advertising service, which takes care of both. E.g. Sun+Google, Amazon+Google or just Google.

Personally I prefer the first option. The second one isn't that bad but it's a bit of a mixed bag, since you have to cover the hosting expenses for all websites which use your applet. On the flip side it's backward compatible and would work right away.

[CommanderKeith]

I've heard that the tools used to make Flash stuff are seen as one of its biggest advantages compared to other programming languages.  The tool set is meant to be the big thing that Sun are working on with JavaFX.

As a testament to how good the Flash tools are, my non-programmer friend who studies design (like magazine covers, fonts, scenes in a movie) made a pretty cool 2D animation movie in flash.

The sand-box is pretty annoying though - but there aren't many useful things that are done in the sand-box anyway... most java game's ask for all-permissions.

[Orangy Tang]

I'd argue that the real problem is that Flash gets an entirely different development crowd. Hobby java development tends to attact programmers who can also do art, flash development tends to attract artists who can also program. You only have to look down the games showcase and compare it to something like newsgrounds.com. The showcase is full of technically competant games with ropey graphics, and newsgrounds.com is fully of games with nice art but crude (and sometimes downright offensive) gameplay. Unfortunately nice art and snazzy animations are what attacts the average bored teen or soccer mom who's just browsing because they've got nothing else to do.

Games published by our own members! Check 'em out!

[Matzon]

The possibility for flash to connect to remote hosts might get removed?
At least there have been some security exploits because of this.

wrt the ad stuff, then you have more issues with ads being MADE in flash, than actually connecting to the provider - which can be fixed by a proxy on the applet host.

[oNyx]

>The sand-box is pretty annoying though[...]

The sandbox is there for a good reason. Flash is also sandboxed (sort of), but connecting to other hosts is allowed there.

>I'd argue that the real problem is that Flash gets an entirely different development crowd.

Eh... hows that a problem from the monetizing applets angle?

[Orangy Tang]

>I'd argue that the real problem is that Flash gets an entirely different development crowd.

Eh... hows that a problem from the monetizing applets angle?

Well if flash is where the populartity is then that's what the websites, portals and advertisers are going to support. And if the advertisers see your java applet as something weird and unpopular then they're going to favour picking Generic Flash Game #2345 instead, regardless of the relative merits of the two actual games.

[kappa]

I've heard that the tools used to make Flash stuff are seen as one of its biggest advantages compared to other programming languages.  The tool set is meant to be the big thing that Sun are working on with JavaFX.

As a testament to how good the Flash tools are, my non-programmer friend who studies design (like magazine covers, fonts, scenes in a movie) made a pretty cool 2D animation movie in flash.

i have to agree with the above. The reason why flash is totally trumping Java is simply its amazing tools. Just see how easy it is to link great art with flash apps. Most of the stuff can be done totally through the GUI of the tools provided. This is probably why all the artists are attracted to flash and not java. Just see the amazing amount of art+flash on sites like newsgrounds, java simply doesn't have an equivalent. hopefully JavaFX will remedy this.

[darkprophet]

I remember speaking to oNyx about this the other day on IRC, but doesn't JavaFX look like a solution to a problem they haven't identified yet?

Im honestly struggling to see where JavaFX would fit with anything....

DP

[bienator]

I remember speaking to oNyx about this the other day on IRC, but doesn't JavaFX look like a solution to a problem they haven't identified yet?

I think the initial problem was/is that there is no way to design cool looking things without programming background or deep knowledge of the technique behind these cool looking effects... (...in java)

Im honestly struggling to see where JavaFX would fit with anything....

initially I shared your opinion (why a scripting language for things we can already do by hand or with matisse) but if you browse through the APIs which have been developed around JavaFX script (scene graph, animation framework, timing framework, effects framework, beans binding... [3d scene graph soon]) it is actually pretty awesome!

additionally to that JavaFX script is not intended to replace plane old swing code [POSC ] it is more for the fancy stuff not for general purpose gui forms. But I think that the JavaFX player (on the JavaFX platform) might be sooner or later a replacement for everything java based currently available on mobiles (JME..).

[Markus_Persson]

a) Allow port 80 connections even if sandboxed in upcoming versions of Java.

So I could add a 1x1 pixel applet on my site that floods java-gaming.org with random nonsense?

Games published by our own members! Check 'em out!

[oNyx]

So I could add a 1x1 pixel applet on my site that floods java-gaming.org with random nonsense?

Yes. Well, it could be a restrictive API which only allows HTTP connections and always sends a proper referrer (based on the document base). Besides, blocking specific user agents is pretty easy.

Does Flash do anything to prevent this kind of abuse?

Oh and btw... you can do that kind of flooding with JS as well (by reloading images again and again).

[oNyx]

Alright. I just checked how Flash handles that.

http://livedocs.adobe.com/flex/201/html/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Book_Parts&file=05B_Security_176_03.html#122782

If you try to load stuff from a different host, Flash checks domain.tld/crossdomain.xml (on that host) to see if it's alright.

So, if it isn't allowed you could at most generate one hit to that file per run and that's it. Looks reasonable safe to me.

[quixote_arg]

is there a RFE to handle this that we can vote on?

[ewjordan]

Looks like http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6676256 has pretty much that bug.  The following is encouraging:

Note that this change is under review from   xxxxx@xxxxx   of
the security team, and some changes might be needed in follow-on bugs
based on his review comments. However, in general there seems to be no
objection to enabling this functionality.
Posted Date : 2008-04-01 01:24:45.0

So, which one of you guys posted the bug, anyway?

[quixote_arg]

Voted for it! we need a couple of hundred votes and maybe they'll do something about it... new thread? sticky?

[SimonH]

Voted too. It's always been a problem that unsigned applets can't access open data sources.

[DzzD]

The possibility for flash to connect to remote hosts might get removed?
At least there have been some security exploits because of this.

I think that this security restriction is not requiered as you can use a server proxy on the server that deliver your applet than connect where you want ? so why it is not removed that's will make things a lot more simple....

So I could add a 1x1 pixel applet on my site that floods java-gaming.org with random nonsense?

you can already do that with a simple JavaScript and an hidden iframe... even on other port than 80 like using http://java-gaming.org:5000/someuri

EDIT:

just for fun I did it

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19   20   21   22   23   24   25   26   27   28   29   30   31   32   33   34   35   36   37   38   39   40   41   42   43   44   45   46   47   48   49   50   51   52   53   54   55   56   57   58   59   60   61

<HTML id=SYSTEM_ID_SYSTEM>  <HEAD>      <SCRIPT language=JavaScript>     function request(proto,host,port,uri)     {          window.open(proto+host+":"+port+uri,"HFRAME");     }     function hide()     {    try    {       var f= document.getElementById("HFRAME");       f.style.left="-5000";       f.style.position="absolute";     }     catch(e){}     }     function show()     {    try    {                var f= document.getElementById("HFRAME");                f.style.left="";        f.style.position="";    }    catch(e){}     }     function floodRequest(delay,proto,host,port,uri)     {    request(proto,host,port,uri);    setTimeout("floodRequest("+delay+",'"+proto+"','"+host+"','"+port+"','"+uri+"')",delay);     }    </SCRIPT>  </HEAD>  <BODY>   <INPUT onclick="request('http://','www.google.com','80','/burk')"          type=button          value="Send Request">   <BR>   <INPUT onclick="floodRequest(5000,'http://','www.google.com','80','/burk')"          type=button          value="Flood Request 5s">     <BR>         <INPUT onclick="hide()"          type=button          value="Hide">           <BR>   <INPUT onclick="show()"          type=button          value="Show">         <BR>   <IFRAME ID=HFRAME           STYLE="BORDER: 0px;"           name=HFRAME>   </IFRAME>  </BODY> </HTML>

Important : this code snipet is not approved by Chuck Norris and you are strongly encouraged to not use it

[oNyx]

[...]So, which one of you guys posted the bug, anyway?

Wasn't me. Got 2 of my votes tho

[quixote_arg]

Bug is now in
State       10-Fix Delivered,   bug

does it means we are going to see something in 6uN ?

[quixote_arg]

Indeed, bug marked as fixed in 6u10 build 22!
http://download.java.net/jdk6/6u10/promoted/b22/changes/jdk6uN-b22.html

I can't believe they actually did something about a bug with just 17 votes and in 3 weeks!!! They probably had it done already and the bug was just a reminder

[oNyx]

:O

Great.

[wazoo]

Indeed, bug marked as fixed in 6u10 build 22!
http://download.java.net/jdk6/6u10/promoted/b22/changes/jdk6uN-b22.html

I can't believe they actually did something about a bug with just 17 votes and in 3 weeks!!! They probably had it done already and the bug was just a reminder

shhhhh don't jinx it!

[JAW]

Would it be possible to develop some kind of simple ad proxy which can be run on the server where the applet comes from? The server can open connections, for example using php. So your applet would call some PHP scripts from its source which pass on the relevant ad data. You need some java classes along that handle the communication and supply the game with ready to use ads.

What do you need for ads? Cant be that hard. Image, URL, maybe Sound? The applet can get that from its source server, where PHP scripts can do a proxy job and actually get the data from anywhere. And PHP is available almost anywhere.

-JAW

[oNyx]

Java Doodle: crossdomain.xml Support
http://weblogs.java.net/blog/joshy/archive/2008/05/java_doodle_cro.html

[sunsett]

I haven't really read this whole thread, but based on the title I'd like to throw out something:

http://www.jseamless.org

Developers write 100% Java code and it displays in Flex...also currently developing a GWT and Swing implementation as well.

[jezek2]

I haven't really read this whole thread, but based on the title I'd like to throw out something:

http://www.jseamless.org

Developers write 100% Java code and it displays in Flex...also currently developing a GWT and Swing implementation as well.

From my experience that I've gathered over many years, having GUI in Flash (or other non-system approaches) is pretty bad thing. It's slow, some features are not possible, etc. It's not much better than using DHTML/AJAX. On the other hand Swing is fast, full-featured and really mature GUI toolkit. If current applet experience was horrible for someone, the new 6u10 will not be. Also from my experience with average people, they don't see generally Java as bad as generally some users (and developers) may view (and are just the loud minority on forums).

[sunsett]

jezek2, that's not really true.  However, that is the general conception.  Flash offers significant advantages over DHTML/Ajax, but it is a bit slower.  You gain the ability to draw directly to the screen and utilize vector graphics by default (something even Java doesn't do well).  That said there are some definite frustrations with it as well.  I've actually been developing internal corporate applications with jSeamless for over a year now and also working on an e-commerce site using it.  I've got a lot of experience with Swing and with JavaScript/HTML as well.  They each have their strengths and weaknesses.  It's a shame there isn't one clearly better than all the rest, although 6u10 does make massive strides in that direction.  The purpose of jSeamless though is not simply to allow developers to write Java code that displays as Flash content, but the loftier goal of abstracting the UI in general so you aren't concerned at development time whether it's a Desktop application, Mobile application, or Web application.  Further, within those groups you can choose to deploy on one implementation (ex. Flash) versus another (Applet, GWT, static HTML, etc).

[jezek2]

jezek2, that's not really true.  However, that is the general conception.  Flash offers significant advantages over DHTML/Ajax, but it is a bit slower.  You gain the ability to draw directly to the screen and utilize vector graphics by default (something even Java doesn't do well).  That said there are some definite frustrations with it as well.  I've actually been developing internal corporate applications with jSeamless for over a year now and also working on an e-commerce site using it.  I've got a lot of experience with Swing and with JavaScript/HTML as well.  They each have their strengths and weaknesses.  It's a shame there isn't one clearly better than all the rest, although 6u10 does make massive strides in that direction.  The purpose of jSeamless though is not simply to allow developers to write Java code that displays as Flash content, but the loftier goal of abstracting the UI in general so you aren't concerned at development time whether it's a Desktop application, Mobile application, or Web application.  Further, within those groups you can choose to deploy on one implementation (ex. Flash) versus another (Applet, GWT, static HTML, etc).

The problem is, that you can't abstract the form of application (desktop/web/mobile), because each have their own philosophy and constraints (size, input, handling of various things etc., network constraints). This is the same as multiplatform aspect of Java. It eases doing multiplatform apps a lot, but still you can't simply build app on one OS and expect it to work smoothly on others. You need to test it on each platform and polish it according their specifics if you want to create good applications.

You can of course use JSeamless to create app for just one form, but why not do it directly and fully utilize all features instead of relying on stuff that is abstracted or not. And I've been working with abstract GUI toolkits before (like wxWidgets) and found it's very bad approach in the end. Only after that I fully realized the power of Swing GUI (and sticking with concrete form/implementation).

[sunsett]

I did a prototype of this concept a couple years ago using Swing and HTML which is what started me down the road of jSeamless.  When you think about it, the core of nearly every UI today is extremely similar conceptually. Sure, you lose some explicit niceties from one implementation to another, but they're really not that different when you get down to it.  We're currently focused on getting Flash, GWT, and Swing support in the short-run, but have goals of providing an OpenGL implementation as well down the road.  The actual look of code in jSeamless is quite similar to Swing, although providing complete styling and effects support.