Java's biggest disadvantage (compared to Flash)

Networking & Multiplayer
#1

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.

#2

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.

#3

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.

#4

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.

#5

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? :slight_smile:

#6

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.

#7

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.

#8

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 :slight_smile:

#9

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)

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…).

#10

[quote=“oNyx,post:1,topic:31350”]
So I could add a 1x1 pixel applet on my site that floods java-gaming.org with random nonsense?

#11

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).

#12

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.

#13

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

#14

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

[quote]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
[/quote]
So, which one of you guys posted the bug, anyway? :slight_smile:

#15

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

#16

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

#17

[quote]The possibility for flash to connect to remote hosts might get removed?
At least there have been some security exploits because of this.
[/quote]
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…

[quote]So I could add a 1x1 pixel applet on my site that floods java-gaming.org with random nonsense?
[/quote]
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

<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">
  

  <INPUT onclick="floodRequest(5000,'http://','www.google.com','80','/burk')"
         type=button
         value="Flood Request 5s">	
  
		 
  <INPUT onclick="hide()"
         type=button
         value="Hide">
		 
  

  <INPUT onclick="show()"
         type=button
         value="Show">		 
  

  <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

#18

Wasn’t me. Got 2 of my votes tho :slight_smile:

#19

Bug is now in
State 10-Fix Delivered, bug

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

#20

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 :slight_smile: