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.

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.

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.

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

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.

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

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

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

Quote

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

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.

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

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

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.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org