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 …
@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.
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.
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.
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. :-(
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
