Feeds

back to article Coder cooks up Java-built Flash Player

A version of Flash is being built using Java, two years after Adobe Systems opened the player's closed formats to external inspection. Programmer Joa Ebert has demonstrated a Java build of Flash executing SWF. The player is apparently called JITB, and it was recently unveiled at an event in San Francisco. While there's still …

COMMENTS

This topic is closed for new posts.
Silver badge
Alert

Java + Flash

Will it reach a critical bloat mass and suck in everything else you've got installed on the computer?

4
0
Grenade

Way to go!

Then FarmVille can run on your mobile... even more slowly than it does on the desktop.

How to combine two nasty, ugly, sluggish technologies in an even less useful way.

2
1
FAIL

RE: Way to go!

You play Farmville?

0
0
Thumb Up

Wonderfully silly

Lets hope it has less security holes than the real thing.

Of course it is less mind-bogglingly silly as emulating the entire PC in java

http://jpc.sourceforge.net/home_home.html

But almost nothing is.

1
0
Silver badge

New flash player in Java?

class FlashPlayer{

float [] pixels;

public FlashPlayer(){

while(browserNotLockedSolid){

pixels[pixels.length+1]=new float();

}

}

}

1
0

float vs Float

Tom,

Float is a class, float is a primitive type. pixels[pixels.length+1] will throw an ArrayindexOutOfBoundsException, thus breaking out of the loop.

1
0
FAIL

Stick to scripting, kiddie

@Tom 7

An excoriating attack on Java - pity you don't seem to know anything about Java, or, it seems, programming in general.

- The pixels array is never initialised, so a NullPointerException will be thrown when you try to use it.

- The length field of an array is one more than the maximum index, so "pixels.length+1" is out of range (this looks like JavaScript syntax, but even there, "length+1" gives you an array half empty).

- "new float()" won't even compile, as "float" is a primitive, not a class.

- The (presumably boolean) variable "browserNotLockedSolid" is undeclared, so the loop won't compile.

- If the class is package-private, why does it have a public constructor?

- At least the lines that simply contain braces are error-free.

0
0

The cycle is complete

Interpreters running inside interpreters. What is next... a ZX-Spectrum emulator running in flash in Java?

0
0

almost

'What is next... a ZX-Spectrum emulator running in flash in Java?'

.... on a ZX Specturm.

0
0
FAIL

Mmmmm, Flash and Java

Like having square wheels AND no engine.

1
0

Cool!

Now I can run 64bit Linux with a 32bit Linux VM in VirtualBox where I can use DOSBox to run Windows 98se and open Internet Explorer with Java so that I can run Flash in side it!

As Mr Booth pointed out above -- why not just emulate an entire machine in Java?

While I can see that this may make some things "more convenient" running a VM inside another VM is just plain wasteful.

1
0
Silver badge

It's not that bad

Picking your post at random to reply to, the article states that ActionScript is translated into Java bytecode. So, in principle, most of the time, the Flash code is executing as though it were Java. The Java runtime then has a whole bunch of similar stuff for translating Java to native code so the whole thing is better framed as a caching problem rather than an ongoing translation problem.

I'd have been all for this a week or two ago, but since Oracle started throwing their weight around I've gone back to liking Adobe more. And probably the best way forward is still whoever it is that's working on the translation of Flash to Javascript+<canvas> — then you're translating something essentially closed (and hopefully soon legacy) into something completely open that's supported by a variety of vendors, each competing for the best implementation. You can even sell it as 'Flash on iOS devices' if you want to grab some venture capital, it'll still benefit the vast number who don't buy Apple.

0
0
Jobs Horns

Apple Made This (tm)

...sticker on it?

0
0
Go

More secure

The Java language does bound checking on all array accesses. It also checks all use of reference (pointer) values. So, this should result in a more reliable Flash engine with significantly fewer exploitable flaws. If the use of compilation to native code for the Java bytecode can get the speed up the result could be a Flash engine that is reasonably fast (there will be some cost of course) and a lot less exploitable. I would be all for that.

As for the bloat, well, yeah, you're going to get that. :-(

1
0
Silver badge
Happy

Next stop...

...a Flash interpreter written in BBC BASIC.

0
0
Thumb Up

I wonder...

Will it be more secure?

Will it be less bloated?

Will it use less CPU cycles?

Since everything Adobe has released in the last 15 years has been "bobbins", I'm guessing "yes" to all three!

0
0
Thumb Up

I hope it exceeds the performance of the native Flash runtime

...because this show up Adobe as the bunch of brainless tossers that they are when it comes to writing software, where performance is an afterthought.

0
0
This topic is closed for new posts.