Ontwikkelaar bouwt 'Flash player' in Java

Een Duitse ontwikkelaar is bezig met het bouwen van een Flash-speler in Java. Als de software klaar is, kan het programma Flash-content afspelen op alle OS'en waarop Java geïnstalleerd kan worden, of dat nu is op desktops of smartphones.

Er moet nog wel veel werk gebeuren voordat het programma, dat JITB is gedoopt, klaar is voor dagelijks gebruik, blogt Joa Ebert, de ontwikkelaar van de software. Zo moet de Flash API nog in de software worden geïntegreerd en de Display List-rendering moet worden overgezet naar OpenGL. Ebert hoopt hulp te krijgen om dat voor elkaar te krijgen.

JITB zet ActionScript-code om in Java-bytecode, waardoor bijvoorbeeld een swf-bestand door de software kan worden afgespeeld. De ActionScript-code loopt bijna even snel als gewone Java-code, iets dat voorheen niet mogelijk was. Op een later moment moet het ook mogelijk zijn Java-classes aan te roepen in ActionScript, maar vooralsnog behoort dat niet tot de mogelijkheden.

Volgens Ebert is zijn software in de toekomst voor veel toepassingen geschikt. Zo kan JITB geïnstalleerd worden op desktops, laptops, servers en Android-smartphones: elk platform zou geschikt zijn, zolang er maar Java op draait. Overigens heeft Adobe een versie van Flash uitgebracht voor smartphones met Android 2.2 en zal Flash in een later stadium ook naar vrijwel alle andere smartphoneplatformen komen: alleen iOS, dat draait op iPhone, iPod touch en iPad wordt niet ondersteund, omdat Apple dat niet toestaat.

Het is onduidelijk wanneer JITB af is en onder welke licentie de ontwikkelaar zijn software uit gaat brengen. Ebert vermeldt niets over zijn toekomstplannen met de alternatieve Flash-speler.

Reacties (130)

[ikweethetbeter]

Leuk te zien dat Apple bij een topic over Flash in Java er door veel forumleden weer negatief bij betrokken wordt. Vandaar dat ik ook even wat olie op her vuur doe...

Juist omdat Apple zoveel gekopieerd wordt (Windows lijkt op OS X, alle nieuwe telefoons lijken op de iPhone (3)), staat het zo in de schijnwerpers, en krijgt het kritiek op elke bit in de software die verkeerd zit. Of op het puriteinse Amerikaanse beleid als het gaat om "adult content". De meest perverse porno komt uit Amerika, alleen mag er geen App komen die daar speciaal voor gemaakt is. Elke krant heeft zijn eigen reader (geheel overbodig overigens, daar hadden we ooit eens universele browsers voor uitgevonden), een blootbladeraar mag niet.

En dan heb je nog Flash. Apple wil het niet op zijn iOS. Apple heeft daar goede redenen voor (matige performance, maar vooral veel minder accuduur), alleen vind ik dat dat een keuze is van de gebruiker. Zet het in de App Store, met een negatief installatieadvies, laat gebruikers tekenen dat ze niet bij Apple aankloppen bij vermeende accuproblemen (te snel moeten opladen) als ze het alleen al willen installeren.

Ben je het daar niet mee eens, ga dan jailbreaken, of koop een Android telefoon, als gebruiker heb je vrije keus. Maar een iPhone kopen (want het is toch wel hip) en erover zeuren doet men liever.

Op de meeste platforms is de HTML5 / H.264 combinatie veel minder processor-intensief dan Flash. Voor mobiele apparaten betekent dat dat ze minder warm worden en dat ze minder snel weer aan de lader moeten. Dat lijken me zeer grote voordelen!

Adobe heeft met PDF een mooie standaard neergezet, maar het gros van de uitbreidingen na versie 5 zit niemand op te wachten, en levert alleen grotere, loggere & tragere readers op. Vandaar dat de alternatieve PDF readers het zo goed doen! En dat terwijl de reader van Adobe, die de standaard gemaakt heeft, gratis is! Dat zou ze toch aan het denken moeten zetten, daar bij Adobe!

Adobe heeft ook Flash gemaakt. Stel dat de Java player van Flash sneller is dan de standaard player van Flash, dan mag Adobe zich helemaal gaan schamen!

De tijd zal het leren of Apple bijdraait en toch Flash toelaat, of dat Adobe bijdraait en een slankere & sneller Flash player maakt, of dat de markt uiteindelijk met een nieuw alternatief komt. Zelf gok ik op dat laatste, en HTML5 is daar het begin van.

[IStealYourGun]

De ActionScript-code loopt bijna even snel traag als gewone Java-code, iets dat voorheen niet mogelijk was

There, I Fixed It
Zover ik weet is java nu niet een van de meest snelle framworks dat er bestaat en ik ken veel professionele apps die super traag reageren onder java.

[hellfighter87]

hardstikke fijn dat jij progamma's gezien hebt die traag zijn in java. die heb ik in zoon beetje elke taal wel gezien dus dat is niet echt een verrassing.

[IStealYourGun]

Astu!
http://en.wikipedia.org/wiki/Java_performance

Let vooral op de JIT performances.

Om je één professionele app te noemen: NetBackup Administration Console
Daar bestaat zowel een java als een windows versie van. De java versie heeft zijn naam niet gestolen want je krijgt echt wel de tijd om koffie te drinken.

[Verwijderd]

Astu!
http://en.wikipedia.org/wiki/Java_performance

Let vooral op de JIT performances.

Iemand vraagt om onderbouwing voor jouw claim waarom Java traag zou zijn en je response is om te verwijzen naar een zeer generiek Wikipedia artikel ? Het artikel heet 'Java performance' en gaat over de theorie achter de performance van Java (niet specifiek goed of slecht). Als je op het artikel klikt word je begroet met de melding 'The neutrality of this article is disputed.'.

Dit staat er in dat specifieke stuk waarnaar je verwijst:

Early Java Virtual Machines always interpreted. bytecodes. This had a huge performance penalty (between a factor 10 and 20 for Java versus C in average applications)

Dit 'early' en 'had' gaat over 10 jaar geleden toen de Sun JVM nog geen JIT compiler had.

Vervolgens sluit het stuk af met:

However, due to time constraints, the compiler cannot fully optimize the program, and therefore the resulting program is slower than native code alternatives.

De bron van dit stuk tekst is deze site: http://www.jelovic.com/articles/why_java_is_slow.htm . Waar staat "Java, with the current language features, will never be as fast as C++". Een klein probleempje, deze text is uit 2005.

Ook zegt de auteur onderaan dat C++ applicaties sneller dan Java kunnen zijn als ze een JIT compiler gebruiken ? Niet heel consistent ?

> Java can be faster than C++ because JITs can inline over virtual function boundaries.
C++ can also be compiled using JITs. Check out the C++ compiler in .NET.

Daarnaast word de claim in hetzelfde Wikipedia artikel ook weer tegengesproken:

In some real-life programs, Java out-performs C, and often (ref required for often) there is no performance difference at all. One example is the benchmark of Jake2 (a clone of Quake 2 written in Java by translating the original GPL C code). The Java 5.0 version performs better in some hardware configurations than its C counterpart[34].

Concreet; Het is een complex onderwerp met duizend-en-een faceten waar geen duidelijk antwoord is.

Op basis van onderbuik gevoelens ventileer jij een mening die je niet kan staven met kennis, maar enkel met een dubieuze Wikipedia link. Je maakt er nu een omgekeerde wereld van; Je hebt onderbuik gevoelens bij Java en gaat bewijs erbij zoeken om dit te staven in plaats van is te kijken hoe het nu echt in elkaar steekt.

[edit]
Overigens wil ik er nog even aan toevoegen dat als JIT je probleem is je Java ook AOT kan compilen met bijvoorbeel Excelsior Jet of GCJ. Komt er een applicatie uitrollen met exact dezelfde performance eigenschappen als bij een C++ applicatie. Tevens dus ook geen runtime voor nodig. Gebeurt bijvoorbeeld met Azeurus.

[Reactie gewijzigd door Verwijderd op 27 juli 2024 13:11]

[Verwijderd]

Probleem dat ik met de JVM en impliciet ook java heb, is dat het op snelheid en resource gebruik gewoon onbetrouwbaar is. Dit komt niet door het JIT proces, dat zit wel aardig snor, maar door de garbage collector (GC). Hoe meer geheugen je nodig hebt, dus hoe meer Heap de JVM heeft, des te langer duurt een GC cycle. Dit kan soms wel tot bijna een minuut oplopen voor server software waarbij de heap 8 GB is. Gedurende die tijd is je platform effectief gezien niet in staat te reageren op requests van buitenaf!

Daarnaast heeft de GC, die nooit perfect voor iedere applicatie is (kom ik zo op terug), problemen met het opruimen van bepaalde datastructuren. Dit zorgt voor memory leaks, jawel, memory leaks bij gebruik van een GC en dit krijgt men al decennia niet eruit (mislukt concept?).

Daarnaast is het tunen van de GC van een JVM machine gekkenwerk, iedere applicatie gebruikt geheugen anders en zou voordeel hebben met eigen instellingen. Maar ondertussen draaien ze wel allemaal met dezelfde setting. Ga jij dan maar eens een systeem tunen....veel geluk met het vinden van een echt bevredigend resultaat voor al die programma's tezamen.

Het feit dat na meer dan 20 jaar deze "kinderziekten", want onder die naam zouden ze nog geaccepteerd kunnen worden, er nog steeds niet uit zijn is voor mij de reden tegenstander te blijven van Java, ook al moet ik er indirect op mijn werk mee leven en werken. Ook tegen andere omgevingen die met een GC werken ben ik zeer wantrouwend, zoals bijvoorbeeld .NET.

Ik heb het gebruik van Garbage collectors nooit vertrouwd (C/C++ achtergrond). men beweerde een probleem op te lossen dat er vaak gewoon niet was, en de oplossing is tot nu toe i.i.g. nooit bewaarheid geworden. Ondertussen zijn er wel een paar generaties programmeurs uit voortgekomen, die als ze terug zouden moeten met een taal waar ze zelf enige verantwoordelijkheid en inzicht moeten hebben m.b.t. geheugen management, niets goed werkend zouden maken en nu ook al achterstand hebben w.b.t. het managen van andere resources dan geheugen!

Het hele GC gebeuren is wat betreft performance en memory management een kapitaal vernietigende operatie gebleken, leuk voor academici om papers over te schrijven, zonder maar iets bij te dragen aan echt betere software. het heeft wel wat nieuwe taal constructies mogelijk gemaakt, maar of je daar nu per se blij mee moet zijn, we hebben er ook voor moeten inleveren, dus ik denk het niet!

Over 20 jaar kijken we terug, over wat een waanzin die jaren 90 en het decenia daarna wel niet waren! Dit is al op meer gronden gebleken

[Reactie gewijzigd door Verwijderd op 27 juli 2024 13:11]

[Verwijderd]

Memory leaks bij bepaalde datastructuren? In ieder geval niet bij cirkel-referenties, daar kan een moderne GC prima mee om gaan. Ik heb er nog NOOIT over gehoord, over die memory-leaks in Java of .NET. Ja, het is mogelijk om memory leaks te krijgen, maar alleen door toedoen van de programmeur, doordat hij een referentie naar een object behoudt en dat daardoor de GC het niet op mag ruimen.

En een collectie die een minuut duurt? Sowieso werkt de GC van Java en .NET in generaties, waarbij iedere generatie een aparte heap heeft, waardoor nooit alle 8 GB opgeruimd hoeft te worden in een enkele collectie. En de grootte is niet echt van belang, het is het aantal objecten, en dikke kans dat als je 8 GB in gebruik hebt, dat je een paar gigantische arrays hebt, het lijkt me sterk dat je voor 8 GB aan kleine kortlevende objecten hebt, want die komen in generatie 0 terecht die klein en dus zeer snel is en vaak wordt gecollect. En het is niet alsof allocatie en deallocatie gratis is zonder GC, hoe lang denk je dat het in C++ duurt om 8 GB te alloceren en dealloceren, laat staan als het 8 GB aan kleine objecten is (en wat het effect daarvan is op heap fragmentatie, wat geen probleem is bij een GC)?

Wel GC of geen GC is gewoon een afweging tussen snelle allocatie (heap allocatie in Java of .NET is bijna net zo snel als op de stack), langzamere deallocatie, onvoorspelbaarheid en gebruiksgemak versus langzamere allocatie, snelle deallocatie, voorspelbaarheid en ontwikkeltijd. Daarnaast is gebruik van een GC beter voor performance dan naïef gebruik van malloc/new, pas als je je eigen allocator gaat schrijven voor je programma ga je daar performance winst behalen t.o.v. een GC.

En het is inderdaad niet goed als je helemaal niks van geheugen weet, maar nog enger zijn de C programmeurs van de oude garde die niks vertrouwen wat de compiler of run-time voor je doet, omdat ze voortbouwen op ervaring of best-practices van 20 jaar geleden, ook al is dat inmiddels achterhaald, en dat ze vervolgens die dingen ook gaan toepassen in moderne omgevingen waar het effect alleen maar negatief is.

[Reactie gewijzigd door Verwijderd op 27 juli 2024 13:11]

[Verwijderd]

Fragmentatie is het onderliggende probleem bij een GC, om dit tegen te gaan wordt er soms een "compact" proces uitgevoerd en dat kan heel lang duren. Lees dit eens bijvoorbeeld waar blijkt dat het nog erger kan dan ik zelf heb meegemaakt.

http://www.theserverside....-the-Java-Virtual-Machine

En wie doet er nog aan naïef gebruik van malloc/new in code waar dit intensief wordt gedaan? Je gebruikt je placement new operator en vooraf door classen gealloceerd geheugen. Je kan zo werken zonder run-time overhead en zonder fragmentatie.

Ik ken overigens geen C++ ontwikkelaar die een compiler niet vertrouwt. De code die men schrijft leunt namelijk zwaar op de betrouwbaarheid van de compiler, aangezien die heel veel detail code automatisch voor je genereert. Daarmee is je redenatie dat die groep van ontwikkelaars negatief staat tegenover vormen van automatische processen zwaar overdreven. Er is een verschil tussen controle hebben zonder de details expliciet te programmeren en dezelfde problematiek door een "magisch" proces buiten je controle om volledig laten afhandelen.

Dat van die memory leaks kan ik niet zo snel terugvinden op het web, ik heb er op kantoor vast nog wel wat links van. Momenteel hebben we er nu geen last van, maar in de vorige versie van de java gebaseerde omgeving waar we mee werken was het wel degelijk een issue. Zo heb ik destijds ook de links gevonden over problemen met de GC zelf.

[Reactie gewijzigd door Verwijderd op 27 juli 2024 13:11]

[Verwijderd]

Met GC heb je juist minder last van fragmentatie. Dat je een compact operatie hebt, is juist een voordeel. Probeer maar eens een oplossing te vinden als je in je applicatie last heb van memory fragmentatie als deze in C is geschreven. (Het is allemaal wel te doen, hoor, maar tegen de tijd dat je klaar bent, kun je beter je eigen compiler schrijven. )

Overigens is in de jaren 60 al bedacht hoe je een real-time GC kunt schrijven, maar ik geloof dat dat op een single 'core' machine was, maar het idee kun je ook implementeren op een multi-core. Ik begrijp zelf eigenlijk niet zo goed waarom er zoveel geld gaat naar dat onderzoek terwijl de oplossing al lang bekend is. Misschien dat het wat geld kost om het te optimaliseren voor 'moderne' architecturen, maar verder?

[Verwijderd]

Ieder voordeel heeft zijn nadeel, en met name voor server omgevingen die veel geheugen gebruiken, is het nadeel onacceptabel groot.

[DarkJack]

Java 7.0 gaat een totaal ander concept van Garbage Collection gebruiken. Binnen de wereld van de managed omgevingen wordt er ook bakken onderzoek gedaan naar betere Garbage Collectors juist omdat automatisch geheugenmanagement iets zeer complex is, zeker in multithreaded of distributed systemen.

[Verwijderd]

Ik heb het even opgezocht en dat ziet er inderdaad al wat beter uit, i.i.g. wat betereft de lagere overhead en semi-gegarandeerde responsivnes. Is inderdaad beter geschikt voor server gebruik dan wat er nu rondspookt in java land en ik zie ook ruimte voor verdere verbetering.

Mij is overigens niet geheel duidelijk of met de nieuwe aanpak eerdere problemen met het niet kunnen opruimen van resources (dus memory leaks) in deze GC aanpak minder snel kunnen voorkomen.

Maar het is vooruitgang, en dat is zeer zeker welkom, misschien dat het mij t.z.t. kan overtuigen.

[Verwijderd]

Laat me raden, niet backwards compatible waardoor adoptie door de community en ontwikkelbedrijven minstens 10 jaar duurt?

[humbug]

Java 7 is net zo backwards compatible als Java 6, Java 5 enz. Er zullen wat verouderde functies verdwijnen, maar de meeste apps zullen gewoon direct werken.

[hellfighter87]

http://en.wikipedia.org/wiki/NetBeans

netbeans is bijv ook volledig geschreven in java en als de JVM eenmaal geladen is, wat ook maar 1 keer hoefd te gebeuren is het toch een vrij snel programma . teminste naar mijn mening dan

dacht geef ff een countervoorbeelt. meestal is het maar net afhankelijk van wat voor architecturen je toepast in je programmeer werk of iets snel is of niet. Daarom word op HBO ook ze gehamerd o pdat je de juiste architectuur kiest.

[ZpAz]

Tsja, Netbeans of Eclipse, beiden imho 3x niets als je het vergelijkt met Visual Studio of xCode. Het voelt gewoon op geen OS 'native' aan (op Windows nog het meest) onder OSX is het gewoon een vreemde eend in de bijt.

En daar zit meteen 'de fout' van het cross-platform moeten willen hebben. Het is voor geen enkel OS 'perfect' uitgewerkt, er wordt altijd rekening gehouden met de mogelijkheden van het minste systeem.

Nee geef mij maar een applicatie wat geoptimaliseerd is voor je platform.

[Reactie gewijzigd door ZpAz op 27 juli 2024 13:11]

[Verwijderd]

dat mag dan misschien wel zo zijn maar het ging over de snelheid
waarom is 'os-native' (wat dat dan ook moge betekenen) een pluspunt?

[ZpAz]

Simpel voorbeeld voor mobiele devices.

Apple's telefoon heeft sinds kort naast de accelerometer ook een gyroscoop, wil je een platfrom-cross spel maken dan kan je geen gebruik maken van de gyroscroop, omdat andere platformen die niet hebben. In dat geval moet de applicatie rekening houden met het minste platform wat je wilt ondersteunen.

Als die ook bijvoorbeeld geen accelerometer heeft, dan kan je dus enkel 'met de pijltjes' besturen, terwijl het spel misschien veel beter tot zijn recht komt dmv de besturing van een accelerometer + gyroscoop.

Een developer die denkt, ja ik ga dit spel maken, en niet persee rekening wil houden met het al dan niet cross-platform zijn van het spel heeft wel de mogelijkheid om de accelerometer en gyroscoop te gebruiken als hij dat wil.

Nu is het in dit geval een stuk hardware wat misschien niet op andere platformen aanwezig is, maar het kan ook een software-feature zijn wat een bepaald OS wel heeft wat een andere niet heeft. Of zels de GUI, Java onder OSX gebruikt niet de Cocoa GUI elementen, of althans lang niet allemaal die er zijn, terwijl sommige GUI elementen toch wel erg fijn werken, die dan niet in je Cross-platform app aanwezig zijn, omdat een ander OS dat niet ondersteund, en als cross-platform maker wil je toch zoveel mogelijk ondersteunen dus laat je die 'feature' er maar uit terwijl het een goede toevoeging had kunnen zijn.

[Twazerty]

@ZpAz, Je bedoeld dit?:

http://tools.twanwintjes.nl/uploads/images/AVCHDCalculator/AVCHDCalculator%201.2%20Mac%20OS%20X.jpg

Een Java app met gui elementen. Voor zover ik weet zien de GUI elementen van een native app er toch echt exact hetzelfde uit.

[ZpAz]

Als dat je definitie is van een 'native gui' dan heb je nog niet onder OSX gewerkt. Als alle applicaties er zo uit zagen was ik al lang van het OS afgestapt.

Bijvoorbeeld Things, Pixelmator of On the Job dat zijn applicaties die het goed hebben gedaan.

Die Java GUI is de GUI (half) van OSX 10.0 ofzo.

[Reactie gewijzigd door ZpAz op 27 juli 2024 13:11]

[Twazerty]

Die screenshot is genomen op een Apple. De graphics komen van OS X zelf af als het goed is (zo goed ken ik Java niet). Ik haal namelijk de native native look and feel van Mac OS X op. Als het goed is heb ik deze screenshot genomen op 10.5.x

Op windows kan ik die graphics namelijk niet tevoorschijn halen. Daar kan ik in Java de native look and feel van windows xp/Vista/7 ophalen afhankelijk van op welk platform de applicatie word gerunt.

[ZpAz]

Onder windows 7 kan je ook gare Windows XP controls tonen en controls die er constant een stukje naast zitten.

Zie mijn andere applicaties, dat ziet er toch een stuk beter uit.

Bijvoorbeeld in jou applicatie is iets 'fundamenteels' anders dan elke andere applicatie, namelijk die toolbar bovenin. Die staat in een native OSX applicatie NOOIT in de applicatie venster zelf maar helemaal bovenin het scherm.

[Twazerty]

idd, was mij nog niet opgevallen. Maarja ik heb dan ook geen Mac

[hellfighter87]

Ik zie daar het voordeel niet van in. het mooie van java is dat alles werkt overal. en als je dan toch zo nodig OS specifieke dingen gaat toevoegen dan detecteer je welk os je mee te maken hebt en dan voeg je die alsnog toe?.

Zo neem ik maar ff aan dat je vanuit java ook wel de Cocoa elementen kan aanspreken.

[RielN]

Daarom kun je bij android met veel games KIEZEN hoe je bestuurd. Een voorbeeld van niks.

[ZpAz]

Keuze, het heilige woord onder Tweakers, ja met keuze heb je dus dat het spel is geoptimaliseerd of voor knoppen of de andere, een van de twee werkt gewoon minder fijn. Het werkt wel, maar niet zo goed. Dan doe je weer concessies, of je probeert beiden te ondersteunen en dan is het beide keren 'net niet'.

Of zouden jullie ook kunnen leven met een spel wat bestuurd moet worden met 'Kinect aka Natal' en dat je dat ook met een controller kan besutren? Waarschijnlijk werkt het dan in beide gevallen gewoon niet fijn.

[Reactie gewijzigd door ZpAz op 27 juli 2024 13:11]

[Twazerty]

Het is maar net hoe je het bekijkt. Ik vind juist Visual Studio niks en juist Netbeans goed. (Eclipse vind ik ook niks)

[Verwijderd]

@Hellfighter87:

Pardon? Netbeans snel? Op mijn Atom 330 bakje gaat Visual Studio 2010 als een trein, inclusief code completion en weet ik wat nog meer voor fancy fratsen.

Bij Netbeans is het zo dramatisch dat als ik ga typen ik gewoon de letters vertraagd zie verschijnen. Code completion is zo traag dat ik ondertussen al 4x de verkeerde functie volledig uit had kunnen typen voordat ik de juiste uit het rijtje kon selecteren.

Vaak komen Java aanhangers dan terug met benchmarks waarin ze laten zien dat qua computational power Java best wel goed is. Dit is sinds Java 5 dan ook zo (daarvoor echt niet), maar daar hebben veel apps weinig profijt van. De UI's blijven zo traag als iets waardoor het gewoon meer tijd kost om zaken te doen en de hele boel traag aanvoelt. Wanneer de app eenmaal z'n ding moet doen gaat het prima qua performance.

Als we kijken naar de gigantische performance van de moderne CPU's (zelfs de Atom) dan lopen Java apps (als ze goed geschreven zijn) meestal redelijk soepel. Maar zoveel power zou er simpelweg niet nodig moeten zijn voor vaak redelijk simpele applicaties.

[peke]

Idd, zo is bvb PL/SQL developer (native app) een stuk sneller dan bvb Oracle SQL developer (Java). Bij SQL developer zie ik ook vaak mij handelingen met een seconde vertraagt, zoiets hoort gewoon niet in een simpele gui app.
C en C++ zijn bij mijn inziens nog steeds beter op het gebied van performance en dat zal altijd zo blijven.
Waarom worden games, embedded apps, OS, ... dan niet in Java gemaakt?

Java is een prachtige taal dat zeker, vaak beter dan .NET in mijn ogen (bvb threading is een gemak in Java) maar niets kan native apps verslaan qua performance.

[Verwijderd]

Behalve dat Visual Studio gewoon in .NET geschreven is en dus niet native is.

Waarom kan .NET het wel waar Java het niet kan?

[jecede]

Ik weet niet hoe het zit in andere branches, maar voor (high-end) games is java niet geschikt omdat je geen (of weinig, ik ben niet zo into java) controle hebt op de garbage collector. Op het moment dat die weer zijn periodieke opruimwerk verricht, leid dit tot performance drops. (Ik heb dit nooit zelf uitgetest, maar dat is wel altijd de eerste reden (buitenom de pointers etc.) die ik hoor als men vraagt waarom men c++ gebruikt.)

edit:ik zie nu pas dat in de reactie hieronder de garbage collector vriendelijk word afgeserveerd. spuit 11 dus.

[Reactie gewijzigd door jecede op 27 juli 2024 13:11]

[Verwijderd]

Kritische lezen is ook een kunst: The neutrality of this article is disputed. Please see the discussion on the talk page. Please do not remove this message until the dispute is resolved. (March 2010)

[Verwijderd]

komkom, het is algemeen geweten dat java programma's niet uitblinken in snelheid

[naikon]

Ja dat is een algemeen vooroordeel dat gewoon nergens op slaat. Sinds Java 5 is Java net zo snel als C in computationeel zware taken. Dit komt omdat de JIT compiler zwaar is verbeterd sinds java 4.

[demonite]

Daar geloof ik helemaal, maar dan ook helemaal niets van. Heb je een link voor me?

[Fuzzillogic]

Geen link, maar ik onderschrijf de stelling van Naikon. Java is erg snel, vaak on-par met compiled C++. Bovendien heeft het als voordeel dat het "automatisch" geoptimaliseerd wordt voor het onderliggende platform. Zo draaien Java-apps automatisch in 64-bit mode op een 64-bit systeem, zonder aanpassingen.

[Verwijderd]

@Demonite, de JVM technologie is erg volwassen en alle (stok)oude argumenten over Java Is Traag verhinderen alleen maar een normale discussie. Ik vind eerder dat JIJ een link moet geven om het nadeel te bewijzen.

[Verwijderd]

die link staat hieronder al hoor: http://en.wikipedia.org/wiki/Java_performance

[Xthemes.us]

Google maar eens een beetje in het rond, java zelf is niet van huis uit traag.
Dat de meeste bekende applicatie die er gebruik van maakt (Vuze/Azureus) nou niet bepaald bekend staat omdat deze zo zuinig met resources omgaat is een ander verhaal. Een hoop andere programma's draaien echter wel weer prima (Power Architect draait prima bij mij in ieder geval).

Vraag me echter af in hoe verre al deze alternatieven voor flash nou ook daadwerkelijk nuttig zijn, laatste keer dat ik gnash geinstalleerd had kreeg ik naast een aantal ads niet veel te zien. De videos on youtube, vimeo, dailymotion en tweakers.net werkten allen niet

[Reactie gewijzigd door Xthemes.us op 27 juli 2024 13:11]

[Verwijderd]

ik hoor vaak van java fanboys dat het niet aan java zelf ligt maar aan de programmeurs die er slecht mee omspringen. (Begrijp me niet verkeerd ik ben zelf een java voorstander maar het heeft zijn beperkingen)
Dit vind ik een onzinnig argument: het zou betekenen dat java programmeurs over het algemeen slechtere programmeurs zijn dan die die andere talen programmeren.
Ik vermoed dat dit niet het geval is
Het is toch op zijn minst vreemd te noemen dat er geen enkele (3D) java game wordt uitgebracht. Het zou een erg groot pluspunt zijn om java games te ontwikkelen want cross platform.

[Reactie gewijzigd door Verwijderd op 27 juli 2024 13:11]

[killingdjef]

Geen enkele is fout.

Il-2 Sturmovik en Vampire: The Masquerade. The Redemption zijn beide in Java geschreven. Waren ook echt prima spellen. Java is helemaal niet een slechte taal om games in te schrijven (www.jmonkeyengine.com) het enige probleem is dat de concurrentie erg ver voor ligt.

Kijk bijvoorbeeld naar de Crysis engine in combinatie met alle tools die het maken van een game eenvoudiger maken... Als zulke support er ook zou zijn voor een Java Engine dan zou het zeker niet slecht lopen.

[Verwijderd]

Heeft wel degelijk met de performance te maken.
Je blijft een virtuele machine houden als tussenlaag.
Die laag is een tweesnijdend zwaard: het heeft enorme voordelen t.o.v. compatibaliteit voor meerdere plafromen maar heeft per definitie niet de meest optimale code voor elk willekeurig platform: er is altijd een vertaalslag. Die kan enorm efficient zijn, maar nooit zo efficient als GEEN vertaalslag. (native code)
Bij het aanspreken van hardware API´s zal die vertaalslag niet de bottleneck zijn omdat de `load` bijvoorbeeld op een GPU zal liggen en de code vooral moet aansturen, dat die aansturing door een virtuele machine moet is in dat geval een minder groot probleem dan als de zwaarte van de `load´ in software zal liggen. Bijvoorbeeld zware berekening in games als AI of softwarematige geluids synthese. Dan is de virtuele machine wel degelijk een extra last.


Er zijn veel applicaties waar ik gewoon java voor zou gebruiken.
3D games horen daar niet bij.

[humbug]

Misschien eens op Google zoeken naar JIT compiler of native gecompileerde Java code. De problemen die jij beschrijft zijn onvermijdelijk voor een interpreter, maar JAVA wordt meestal niet geïnterpreteerd maar gecompileerd. Java applicaties kunnen (en zijn) vaak zelfs sneller zijn dan native applicaties.

Waarom? Omdat een JIT compiler de applicatie kan optimaliseren voor die ene computer waar het op dat moment op draait. Natuurlijk, een perfecte assembler applicatie zal sneller zijn. Helaas bestaan de meeste applicaties grotendeels uit bibliotheken en is optimalisatie iets wat enkel gedaan wordt om de grootste bottlenecks te verhelpen. Perfecte applicaties bestaan dus niet. En Java applicaties presteren in praktijk gewoon vergelijkbaar aan native applicaties.

Anderen hebben dit ondertussen ingezien met als resultaat dat we nu vergelijkbare oplossingen hebben van Microsoft (.net) en Google (android). Aangezien Oracle en IBM stevig in het Java kamp zitten durf ik wel te stellen dat een flink deel van de IT industrie ondertussen inziet dat "native" code niet heilig is en dat een oplossing mbv bytecode grote voordelen met zich meebrengt.

Blijft de vraag over of 3D games in Java een goed idee zijn. Native gecompileerde Java applicaties zouden ook daarvoor geschikt moeten zijn maar JIT compilers moeten leren. In veel gevallen is het lerender karakter van JIT compilers een voordeel, voor games kan het een nadeel zijn aangezien het leren de applicatie initieel trager maakt Gelukkig zijn er veel meer programma's wat geen 3D games zijn dan wel.

[Verwijderd]

Java applicaties kunnen (en zijn) vaak zelfs sneller zijn dan native applicaties.

bron?

[Verwijderd]

Nooit gehoord van Runescape? Draait toch echt op Java. Sinds de "HD"-versie is verschenen is het toch een behoorlijk indrukwekkende grafische kwaliteit gaan hebben, en dat zal alleen maar beter worden met de komende updates (er staan meer grafische verbeteringen op stapel). Bovendien kan Runescape gebruik maken van zowel DirectX, als OpenGL, als een software renderer.... ik zie het probleem niet.

En inderdaad, Runescape is (min of meer...) cross-platform. Al moet ik eerlijk zeggen dat de HD-versie ronduit slecht draait onder Linux (of in ieder geval OpenSuSE) maar dat heeft misschien meer met de grafische drivers te maken dan met Runescape zelf.

[breezie]

Java is denk ik niet meer dan een tussenlaag om berekeningen uit te voeren

Het weergeven van de dingen gebeurt dan via openGL (voor zover ik er iets van ken )

dus ik denk dat het al bij al nog zal meevallen

[wootah]

Het weergeven van de dingen gebeurt dan via openGL

Kijk, dat denk ik ook!

Het gebruik maken van dingen zoals openGL en directX zullen dit soort dingen zeker versnellen. Volgens mij gebruikt flash geen openGL/DirectX api en moet daarom alles mijn de cpu doen.

Aan de andere kant: volgens mij gebruikt deze ontwikkelaar niet de nieuwe beta van flash, met hardware versnelling

Voor de mensen die java afkraken qua snelheid: ik ben ook geen fan van java, maar het lijkt me dat java nog steeds dingen beter kan optimaliseren dan flash.

Voor echte snelheids monsters heb je C of C++ nodig... C++ heeft soms minder overhead dan C en kan dus sneller zijn dan C, hoewel ik persoonlijk liever in C werk.

[naikon]

Leg eens uit, wanneer heeft C++ minder overhead dan C. Volgens mij weet je niet waar je over praat of je verwart de twee talen.

Java heeft inderdaad een uitstekende JIT compiler welke zeker beter is dan die van flash (mocht ie er al een hebben).

[Salmon]

Mooie ontwikkeling, ik wil wel flash op me android

[Verwijderd]

Dat is al beschikbaar voor een select aantal toestellen. Dit is meer voor de mensen met een Apple apparaat...
http://www.androidplanet....oor-android-nu-officieel/

[Verwijderd]

Dit is meer voor de mensen met een Apple apparaat...

Dan bedoel je de iMac, MacBook, etc.? iPod Touch, iPhone en iPad ondersteunen immers ook geen JAVA.

[jeffhuys]

Wel met jailbreak.

[Verwijderd]

En dan kan je - zoals CptChaos al laat zien - er ook gewoon een Flash interpreter op zetten die -wel- vrijwel alle Flash commando's aan kan.

[CH4OS]

Wel met jailbreak.

En met jailbreak is er ook Flash (Frash heet het dan) ondersteuning:
nieuws: Hacker krijgt Flash werkend op iPhone en iPod touch
en
nieuws: Hacker krijgt Flash aan de praat op de iPad

[Reactie gewijzigd door CH4OS op 27 juli 2024 13:11]

[wvdburgt]

Wie zegt dat ik Flash WIL op mijn iphone/ ipad? Als ik zo dit review lees: http://blog.laptopmag.com...-player-proves-jobs-right
is flash echt niet zalig makend op een telefoon.

[Amanoo]

Wie zegt überhaupt dat die android speler niet zo brak en ongeoptimaliseerd is als het kan zijn?

Er zijn ook veel computerspellen die van console geport zijn naar de pc, en vervolgens zelfs op 's werelds sterkste pc niet fijn werken, maar of dat is omdat die console zo übergoed is, of de port zo überbrak, dat zijn twee verschillende dingen.

[BlakHawk]

Alsjeblieft, het missen van flash is een zwaar minpunt van de iPhone. Het hoeft niet snel te zien, niet mooi. Maar tegenwoordig als we ergens heen gaan moet ik weer van te voren op de laptop een adres zoeken. De iPhone is hier niet meer in te vertrouwen omdat je nooit weet of het toevallig een flash site is. Een gemis is altijd een minpunt zolang anderen er gebruik van maken. Het belemmert het doel van de iPhone. Internet, informatie altijd bij je hebben. Die informatie moet ik nu nog thuis opzoeken!

[ikweethetbeter]

Verkoop je iPhone! Als het een 3GS is, heb ik misschien wel interesse!

[de_jarno]

http://vimeo.com/10553088

of deze:

http://www.mikechambers.com/blog/2010/05/10/top-flash-misperceptions-flash-is-a-cpu-hog/

Het is al heel vaak gezegd: HTML5 kan bij lange na niet wat flash kan, zodra dat wel het geval is en er wordt iets (slecht) geprogrammeerd voor desktops, dan zal het net zo slecht op een telefoon draaien als sommige flash apps nu doen.

[Verwijderd]

Die review hakkelt aan teveel kanten om serieus over te komen.

[Neko Koneko]

Ok, jij wil het niet, maar wie zegt dat anderen het niet willen?

[PPie]

Die 100 miljoen mensen die een iOS apparaat (iPhone/iPod touch/iPad) hebben gekocht terwijl overal door tweakertjes geroepen wordt dat je niet kunt leven zonder Flash op je telefoon/mp3/tablet speler?
(En dit terwijl er al die jaren geen volledige Flash was op de telefoon... Hoogstens Flash lite...)

[Verwijderd]

De meeste van die mensen weten niet eens goed wat flash is. En komen niet op tweakers.net... Ze merken het pas als ze het een keer wel nodig hebben. En zo slecht werkt m.kongregate nou ook weer niet.

[cmegens]

Steve...

[FireDrunk]

Uh, dat is er al?

[Menesis]

Alleen voor Android 2.2. En sommige HTC toestellen met een oudere versie van Android hebben flash lite voorgeinstalleerd.

[Jack Flushell]

Flash is er inderdaad al lang op Android, het is ook HET grote voordel ten opzichte van iPhoneOS.

[Carbon]

Voordeel? Ik weet het nog niet zo zeker....

Mobile Flash Fail: Weak Android Player Proves Jobs Right

[mphilipp]

Ach...weer zo'n zinloos verhaal van een Apple fanboy. Flash is er nog niet heel erg lang op Android (bij mijn HTC is het nog preview) dus ik ga ervan uit dat het nog wel wat tweaks zal krijgen.

Het grote voordeel is gewoon dat je de keuze hebt. Apple timmert alles dicht en laat het vooral dicht om te zorgen voor max.revenue richting Jobs. Op zich niets mis met geld verdienen (doe het zelf ook graag), maar niet als het resultaat castraten zijn waar je alleen maar kunt slikken wat je opgedient wordt.

Maar goed, het is ieders persoonlijke keuze. Ik zeg nooit dat iPhone of Apple slecht of niet goed zou zijn. Dat bepaalt iedereen voor zichzelf. De rant van Jobs richting Adobe echter is bijzonder doorzichtig en kinderachtig. Hij zal binnen enkele maanden wel op zijn plaats worden gezet. Android wint voorlopig elke dag weer terrein. Misschien Apple moeheid? Apple heeft momenteel geen enkel voordeel tov de Android apparaten, dus men moet snel iets verzinnen. Android is iig een open platform en dat spreekt mij persoonlijk veel meer aan.

[kasperkb]

Ik heb niets met Apple (ik heb alleen een aaiPet ), maar ik ben toch geen fan van flash. Ik heb Ubuntu 10.04 32 bit en deze crasht af en toe helemaal bij Flash-content. Soms crasht alleen Firefox, maar al mijn crashes zijn Flash gerelateerd.

Misschien doe ik wel iets totaal fout, maar vooralsnog denk ik dat Flash het probleem is.
Ook gebruikt Flash veel CPU. Ik weet niet of er hier ook anderen zijn met dezelfde issues.

Ik heb overigens geen idee of Java-Flash nuttig zou zijn voor de desktop.

[mphilipp]

Klopt, flash is niet het beste dat tot ons gekomen is. Maar ik zou graag zelf die beslissing nemen. Bij Apple is een bepaalde keuze gemaakt om een klein, plat en licht apparaat te maken. Dat heeft gevolgen voor de architectuur van het ding, en met name de temperatuurhuishouding en de accu. Die heeft dus zijn grenzen. En aangezien ze ook nog een ontwerpbeslissing hebben genomen om die accu niet verwisselbaar te maken, zit je op een gegeven moment met een probleem: je moet de cpu zoveel mogelijk ontzien, want anders vreet ie teveel stroon en wordt dus te heet. Zie daar de reden achter het niet willen multitasken (alleen Apple iPhone gebruikers zeggen dat dat toch helemaal niet belangrijk is...) en geen Flash (want teveel cpu belasting).
In plaats van dat gewoon toe te geven, verzinnen ze ingewikkelde verhalen waarom men dat niet wil en waarom de gebruikers dat vooral maar niet moeten willen.

Prima, ik wil misschien helemaal geen Flash. Ik zie het op de PC ook regelmatig fout gaan. Maar ik kan tenminste kiezen. We zijn gvd zover gekomen met de ontwikkeling van de technologie, dan wil ik niet meer terug naar 1960 waar IBM bepaalde wat wij wanneer met onze vreselijk dure computers mochten doen.
Had Apple zelf niet die mooie commercial van 1984 over vrijheid enzo? Waar is die vrijheid dan als er aan alle kanten keuzes voor jou worden gemaakt? Naar mijn idee wordt je dus aan alle kanten ingeperkt, en dat vind ik niet fijn. Ik wil een computer waarop ik bepaal wat ermee gebeurt.

Voordat ik weer een bak stront over me heen krijg: dit is geen anti Apple bash, maar gewoon mijn mening en hoe ik persoonlijk tegen computerspul aan kijk en hoe ik ermee omga. Ik ben geen fan van enig platform. Ik heb thuis windows, ubuntu én android draaien en ik bouw mijn pc's zelf (vandaar dus geen Apple pc). En ik heb ook een iPod. Die iPod is een krijgertje, maar het is een leuk ding en goede speler. Alleen eeuwig zonde dat ze proberen je vast te klinken aan dat verrotte iTunes. Blij dat het een oude iPod is, zodat ik ook nog andere programma's kan gebruiken.

[jeffhuys]

Flash crasht regelmatig op eigenlijk alle pc's die ik gebruik (oude, mainstream en high-end)

[Ayporos]

Ik gebruik flash al sinds ik een kleine jongen was en heb er serieus NOOIT een probleem mee gehad.

Dat gezegd hebbende gebruik ik het alleen op mijn computers en niet op handhelds.

newgrounds.com, albinoblacksheep.com.. ik heb in mijn jaren als enthousiast computer gebruiker veel flash creaties voorbij zien komen.
Spelletjes, filmpjes, noem het maar op. Ik heb het allemaal gezien en gespeeld.

Vandaag de dag heb ik misschien wel in totaal meer dan duizenden flash bestanden afgespeeld... java? noemenswaardige java applicaties/filmpjes die ik gezien/gespeeld heb? Ik denk dat ik die op een hand kan tellen.

Het boeit mij echt helemaal niks of jij of wie dan ook vind dat java/flash beter is dan flash/java maar IKZELF weet wel dat er in flash veel meer gemaakt is waar IK plezier van heb.

En daarbuiten komt nog eens dat ik een enorme fan ben van open-source en de mogelijkheid om zelf te kunnen kiezen wat jij denkt dat goed/beter is voor jou in jou geval.
Dit alleen al is genoeg rede voor mij om NOOIT een apple product te kopen.

Java plaatst irritante pictogrammen in mijn systeemvak, Java blijft zeuren om updates die god weet ik veel wat doen, java runt irritante processen in mijn processenlijst.. flash doet dit niet. Ik kreeg laatst een melding van firefox dat er een update beschikbaar was voor mijn flash plugin/speler, en deze was in een seconde of twee geinstalleerd. Toen dat gebeurde dacht ik bij mezelf "wow, ik kan me niet herinneren de laatste keer dat ik flash heb hoeven/moeten updaten".

Ongeacht of het hierboven gezegde waar is of niet, DAT is mijn ervaring met flash en java.

Flash gebruikt veel CPU? puh. Wanneer ik een flash bestand aan het afspelen/bekijken ben doe ik op dat moment niks anders dus het interesseert mij echt niks al zou flash 90% van mijn beide CPU cores opvreten.

Dit is ongetwijfeld allemaal irrelevant aangezien desktop-applicaties iets van het verleden is en iedereen het alleen nog maar heeft over smarphones, pad dingen, e-readers, netbooks/tops en al dat soort ongein maar dat is hoe ik er over denk.

[Svardskampe]

Helemaal mee eens!

Al moet ik zeggen dat flash toch bijna even vaak update dan Java, en voor mij is dat irritanter. Bij elke update van flash moet ik NFSW32.dll gaan HEX-editten om te zorgen dat ik gewoon op mijn andere scherm kan werken als een flashapplicatie op het andere scherm op fullscreen staat

Maar bovendien, zelf heb ik nooit last gehad van instabiliteit van Flash. En dan heb ik het over de de Pentium 4 2.26 Ghz die in mijn studiekot staat, en mijn i7 860 thuis. Beiden draaien Windows 7, dus ik zou niet weten hoe het met flash eraan toe is op linuxdistro's en regenjassen.

[Verwijderd]

heb je misschien een linkje voor mij wat je aan dat bestand moet veranderen om dat 2e scherm terug te krijgen?
ik heb hier ook last van

alvast bedankt

[Svardskampe]

Google op "dual monitor flash full screen <versienummer>"

Voor degene die ik heb, wat ik denk dat toch de laatste is. (versienummer 10.1.82.76. Firefox doet automatisch updaten):

op regel 180AAF verander 74 39 naar 90 90.

Bij elke nieuwe update moet je dit opnieuw doen, en vanzelfsprekend werkt dezelfde aanpassing bij een nieuw versienummer niet meer.

[Verwijderd]

Ik heb niet de laatste versie geinstalleerd staan, waardoor de meeste sites niets meer automatisch afspelen. Zodoende kom je van die crashes af. Altijd maar die flash updates voor bijna niets aan meerwaarde voor de eindgebruiker. En de meeste flash dingen zijn toch voor ads, dus die mis ik dan ook mooi.

[ikweethetbeter]

Flash is CPU intensief, op elk platform, maar vooral op elk niet-Windows platform, daar hebben ze geen bit optimalisatie doorgevoerd.

[Verwijderd]

Zucht.. Weer zo'n Android fanboy die maar hinnekt over dichtimmeren en keuze vrijheid bij Apple. Deze groep Android verafgoders begint redelijk irritant te worden.
Het grote voordeel van Apple is de hele entourage rondom het toestel. Ze creeeren nieuwe markten en nieuwe hypes. voorlopig hobbelt Google nog achter Apple aan (Appstore, iPhone, iPad) dus laat dat negatieve over Apple een keer achterwege. Het komt zo onnadenkend en jaloers over.

Zoals je al zegt..ieder zijn ding, maar niet nog ff een sneer over de ander maken!!

[taeke18]

Ontopic:
DIt is een zeer goede ontwikkeling zo krijg je via een omweg toch nog flash op Apple os'en... verder dit vermakkelijkt flash buildin bij sommige linux distro's waarbij flash instaleren toch een hele klus is.
En natuurlijk is dit fijn voor o.a. symbian en wat dan ook je kunt het overal op zetten. En je hoeft ook niet te verwachten dat alles van flash werkt.. zolang sites als youtube maar werken want dat is iets waar veel mensen over zitten te zeuren. Ik geef ze ook groot gelijk youtube is een groot en ook overhyped medium, en eerlijk gezegt wel fijn om te gebruiken.


Offtopic.

idd apple is een geweldig product.. maar waarom laten ze mensen nou niet kiezen of ze flash willen of niet.... maak een keuze menu bij het opstarten... Do you want to use flash on your i(naam product)? met daarbij duidelijk gemeld, some flash may cause extencive presure on cpu witch may cause shorter battery life.

dan kunnen mensen kiezen! Ik vind het nu wat Jobs wil iets en kan alles maken dus doet hij iets geks....

En tuurlijk je hebt gelijk er zijn android fanboys maar die zijn er ook van apple.... die zijn er ook van windhoos en linux os'en. Helaas blijf je die houden als Android user kan ik me ook ergeren aan deze fanboys maar deze mensen kun je gewoon beter negeren.

[Cyw00d]

De reden waarom ze het bannen lijkt mij vrij simpel.
Flash vermindert de accuduur, zorgt voor veel cpu verbruik waardoor het mogelijk langzamer reageert. Als een consument nu een langzame telefoon heeft geeft deze apple de schuld.

Een mooie vergelijking is windows vista en hoe consumenten het de grond intrapte voor een driverprobleem wat niet helemaal hun schuld is.

Apple beschermd zn eigen producten tegen de over het algemeen domme mensen, bespaard tevens een hoop support kosten.

[Verwijderd]

google hobbel achter Apple aan? dat was mss 2 jaar geleden, maar tegenwoordig is er geen verschil meer hoor. Het enige voordeel aan een iPhone is het high res scherm (dat naar mijn inziens nutteloos is), terwijl android geleidelijk aan iOS4 voorbijstreeft qua functionaliteit.

[ikweethetbeter]

Iedereen hobbelt achter Apple aan. Maar geeft er dan wel zijn eigen draai aan. Op zich is daar niks mis mee, men doet dat al eeuwen (goede ideeën kopiëren), maar om dan meteen Apple af te kraken... dat is afgunst!

Als je wilt weten hoe de volgende Windows versie eruit ziet, dan moet je naar de huidige OS X versie kijken.

Als je wilt weten hoe de volgende Google / HTC / ... telefoon eruit ziet, dan moet je naar de huidige iPhone kijken. Want dat is echt verbluffend, neem een willekeurige Samsung / HTC / ... telefoon, en je moet 2 keer kijken om zeker te weten dat je geen iPhone (3) in je handen hebt. OK, in gebruik is er nog een (groot) verschil, maar de eerste stap is gezet: fysiek is de iPhone al gekopieerd.

Als je wilt weten hoe de music & app stores van Google / MS / ... eruit gaan zien, kijk dan ook naar Apple.

[Tijn89]

Functionaliteit?

Ik vind de iOs veel logischer dan Android in elkaar steken hoor. Ik ben best bekend in verschillende os'en maar voordat ik de weg wist in de HTC legend van mn vader, was ik wel ff bezig hoor. Eerlijk gezegd totaal niet logisch, maar goed. Ieder zijn ding dan maar he.

Maar om google en apple met elkaar te vergelijken ben je indd wel kort door de bocht: een hardware-gigant en een zoek-gigant. Maar wat betreft OS'en wel

De app-store is dan denk ik de beste vergelijking en dan gelijk weer niet. Apple wint het dan met het tienvoudige. Verandering komende? Denk het niet, zeker nu Google weer achter loopt met de iPad.

Google is wat dat betreft te afhankelijk van de hardware-makers als HP, Motorola enz. Zelf een eigen tablet of mobiel uitbrengen levert weinig op, zie de nexus-one. Nexus-two zal wel nooit komen...

[Jack Flushell]

Het grote voordeel van Apple is de hele entourage rondom het toestel. Ze creeeren nieuwe markten en nieuwe hypes.

En jij hobbelt daar vrolijk kwijlend achter. Ieder zijn ding, dus ga je gang, maar ik vind iets pas cool als het ook cool is, niet als een bedrijf dat dicteert door zo'n hype te creëren.

[blorf]

Mee eens, maar ik vind het eigenlijk nogal twijfelachtig dat een telefoon of elektronisch boek een bepaalde mate van coolheid met zich meebrengt. Dat is volgens mij de hele illusie waar veel mensen zich pas bewust van worden als ze een paar honderd euro lichter zijn. Vanaf hetzelfde moment begint de frustratie toe te slaan en krijg je discussies die ze op de kleuterschool ook voeren.
Het ding verbetert niks. Bellen of mp3's luisteren kon je ook voor een paar tientjes. Browsen kunnen de meesten thuis. Wat er overblijft is alleen het mobiel browsen, dus ergens op straat of in de trein oid. Nou wil ik niet namens iedereen spreken, maar ik zie er de lol of het nut niet van in, zeker niet na er 400 piek voor betaald te hebben. Geef mij maar een oud pc-tje of laptopje om mijn elektronicaverslaving op te botvieren.

[Reactie gewijzigd door blorf op 27 juli 2024 13:11]

[ikweethetbeter]

Ja, knap he, met zo'n laag marketingbudget zo'n hype genereren!

Apple doet een beetje marketing, maar doet het wel goed. Er wordt een tablet computer aan de wereld getoond met een verhaal of het wiel opnieuw uitgevonden is. Dat is slim.

Apple voedt de hype, maar de hype wordt gemaakt in de media, bij mogelijke kopers, op fora zoals deze waar je felle voor- en tegenstanders hebt. Apple dicteert niks, dus ook geen hype. Die zit tussen jouw oren! En wil je het niet? Dan koop je toch gewoon een HP Slate? Of wacht je totdat HP met de Palm WebOS variant komt. Niemand zal je dwingen een iPad te kopen!

[mphilipp]

En ik zeg nog: het is ieders persoonlijke keuze. Mijn overwegingen zijn de jouwe niet. Ik sneer niets. Ik zeg wat ik vind, en dat mag. Voorlopig doe jij waar je mij van beticht. Ben jij toevallig een Apple fanboy oid?

Mensen die mij kennen weten dat ik nergens fan van ben. Hell, ik heb die hele kut-apple zelfs nog overwogen. Maar goed...toen ik keek hoe dat eraan toeging hoefde ik niet meer. Is that a crime? Ik maak mijn keuzes op mijn eisen en wensen.

Tip: probeer in het vervolg zaken te lezen zoals ze zijn. Een kritische noot mag best. Zelfs een kritische noot over Apple. Dat is niet meteen een aanval of een afkeuring. En zeker niet persoonlijk bedoeld richting de mensen die er heen hebben. Dus trek het je nou eens niet zo persoonlijk aan, dan wordt je leven wat draaglijker...

[ikweethetbeter]

...Mensen die mij kennen weten dat ik nergens fan van ben. Hell, ik heb die hele kut-apple zelfs nog overwogen....

Een hele kut-apple? Wow! Omdat-ie er goed uit ziet, of omdat je er heel gemakkelijk alles wat je maar wilt mee kunt doen? En wat voor kut-apple was het eigenlijk, een iMac? Een iPhone?

...Maar goed...toen ik keek hoe dat eraan toeging hoefde ik niet meer...

En, hoe gaat dat eraan toe? Probeerde Steve jobs de Apple gedachte bij je in te stralen? Was je bang dat de App Store voor de iPhone ook oping voor de iMac?

...Is that a crime?...

No.

...Ik maak mijn keuzes op mijn eisen en wensen...

Dat doet elk weldenkend mens. Maar heb je het wel op de juiste gronden gedaan? Of was je bang om met een kut-apple bij de Google- en Microsoftvriendjes aan te komen?

Maar goed, je zult vast een goede keuze gemaakt hebben (slechte dingen worden niet veel meer gemaakt, dus ook niet door MS, Google, HTC of Sony). Succes ermee!

[Verwijderd]

De conclusie van het artikel is dat FLASH verouderd is, en niet dat Android slecht werkt hoor!

Verder ben ik wel blij met deze ontwikkeling.
Dan zal Apple dit ook wel gaan gebruiken, en komt er meer concurrentie =D

[Verwijderd]

Jaaa, Flash op je smartphone lijkt me echt ontzettend chill. Het werd eens tijd!

[mOrPhie]

En dan nu even wat roet in het eten gooien.

Elke interpreter van swf's die tot nu toe gemaakt werden, waren incompleet of buggy. Gnash, swfdec of zelfs Smokescreen zijn leuke projecten, maar lopen achter op de flash API en zijn buggy. Scaleform kan nog aardig met flash 8 content om gaan, maar ook daar gebruik je flash vooral als tussenvariant, om zo snel mogelijk weer over te gaan op native UI's.

Begrijp me niet verkeerd, ik vind het prima dat deze ontwikkelaar deze stappen maakt, maar voordat iedereen denkt dat dit het ei van columbus is: mijn verwachting is dat dat het niet is. De ActionScript-naar-JBC JIT'er is op zichzelf wellicht wel van waarde, omdat je daarmee een scriptbinding zou kunnen creëren tussen ActionScript en Java. Verder zal het vooral een leuke techdemo blijven en ik verwacht niet dat dit echt gebruikt gaat worden.

Ik vind het jammer voor diegenen die hier hoge verwachtingen van hebben, maar ik ben bang dat je je verwachtingen een beetje zal moeten bijstellen.

[_JGC_]

Het is ook niet makkelijk een flash interpreter te bouwen voor Flash 10.1 als de API pas tot 8 openbaar is gemaakt. Adobe is wat dat betreft ook niet gek, die zorgen ervoor dat hun platform onmisbaar blijft om de nieuwste dingen te draaien.

[Verwijderd]

De headline kan beter 'hobbyist bouwt implementatie van een heel klein gedeelte van de Flash specificatie' zijn.

Ik wist overigens niet dat de Flash specificatie achterliep t.o.v. wat ze releasen. Nog een reden om er ver weg van te blijven dus.

[Frash]

Gnash, Frash, Lightspark en nu dit. De custom Flash players reizen de pan uit. Als ze nou de krachten zouden bundelen...

[DarkJack]

deze in Java is echter nuttiger. De JVM draait op bakken systemen, inclusief embedded systems. Da's ook de reden dat de JVM door meer programmeertalen dan alleen Java gebruikt worden.

[Ruud v A]

Het lijkt er zelfs op dat de java versie iets sneller is bij de tweede demo. Het zou wel mooi zijn als dit open source zou worden, dan kan Flash ook een meer open platform worden.

[MrR0b3rt]

Dat viel mij inderdaad ook op. Als het qua resources ook minder gebruikt dat java gebruikerlijk doet dan ben ik helemaal blij Dan is het wat mij betreft: weg flash, welkom Java!

[ErrieR]

Interessanter zijn nog de implementaties in JavaScript/HTML5, omdat je hiervoor geen enkele plugin hoeft te installeren: http://wiki.github.com/tobeytailor/gordon/ en http://smokescreen.us/

[jeronevw]

Jah, Smokescreen maakt het mogelijk om flash bestanden te lezen en weer te geven. Allemaal met HTML5 en JavaScript. Hierdoor kan flash worden weergegeven in elke browser (zelfs in Safari van Apple devices) zonder dat hiervoor een flash plugin nodig is.

[Verwijderd]

Erg snel zal het niet zijn... maar liefst 2 vertaalslagen:
executable Flash code of ActionScript -> Java bytecode -> native CPU code
een flash naar java emulator... en vervolgens nog eens een java virtuele machine.

[unglaublich]

Kijk eens naar de video man! De Java player heeft een veel hogere framerate dan de flashplayer. Daarnaast zijn de meeste flash toepassingen niet bepaald veeleisend voor je pc.

[biebelebons]

Jeeeemig!!

Mag ik wat kwijt?
Zo niet dan toch.
Stuk voor stuk allemaal meningen en opvattigen over wat slecht, goed beter of best is.
En geen van alleen gebruikt zijn opvatting als richtlijn om tot verbeteringen over te gaan.

De mening is als een schreeuw tijdens een popconcert.
Nutteloos gezien de functionaliteit van de schreeuw in het kader waarin deze plaats vindt.

Als je echt overtuigd bent van datgene wat onomstreden belangrijk is dan geef je er handen en voeten aan. Leg je het voor aan de juiste persoon om tot verdere ontwikkelingen te komen.

Op deze manier is het verspilde energie en juist ook dat is zonde in deze tijd waar we geacht worden om te denken in kaders van energie efficiëntie.


Elk begin start vanuit je reactie op je omgeving. Zo ook de efficiëntie van je stem en handelen.

Het is geen thee kransje, en is dat het wel dan zijn de reacties hier behoorlijk onnodig opgeklopt, verdedigend en onnodig aanmatigend zonder meerwaarde op de gezelligheid die het thee kransje behoort te geven.

ontopic.

Mooie gedachtengang , multiplatform flash via een multiplatform en wijd versprijd/ toegelaten framewerk. Doet me denken aan het paard van troje. Wie niet sterk is moet slim zijn.
Dit is slim, de AppStore van Apple zit pot dicht wat flash betreft dus alleen een sterke "jongen" die het open krijgt.

Of het voor de rest veel teweeg zal brengen, geen idee.
Aan mij zal het niet liggen. Persoonlijk mis ik flash niet daarentegen gebrek aan Java zou mij al gauw opvallen.

Succes allemaal!

[ikweethetbeter]

De Java Flash Player komt er niet voor iOS...

Multiplatform Flash vind ik prima, ik juich het toe, maar als het performt, dan mag Adobe zich wel achter zijn oren krabben.

Ik ga hier niet zeggen wat beter is, HTML5 heeft voordelen en Flash heeft voordelen. En wie er gelijk heeft, Apple of Adobe, dat boeit me niet.

Feit is dat ik Flash nauwelijks zal missen, Java wel. Feit is ook dat Flash onder OS X en op mobiele platforms niet echt efficiënt geschreven is. De laatste mobiele versie is wat beter, maar het houdt niet over. Als er een efficiënte variant op basis van Java komt, vind ik dat een goede ontwikkeling.

Maar of het de inspanningen waard is? Flash is oud, er komen straks vast opvolgers die de markt gaan overnemen. Of HTML6 maakt Flash helemaal overbodig, wie weet...

[Verwijderd]

Prachtig! Flash in java, dat moet je ook maar kunnen en willen maken. Als het af is een vrachtwagen pluimen voor die ontwikkelaar.

Ik ben blij te zien dat dergelijke zaken worden gedaan, het zou flash compleet platform-onafhankelijk maken en een leuke interactie flash/java vrijgeven (iets dat nu dus moeilijker is). Het lijkt me in ieder geval een grote vooruitgang en een upgrade voor zowel java als flash.

@hellfighter87: Netbeans is inderdaad een erg mooi voorbeeld van java-programmatie. Het laadt niet al te snel in het begin (maar goed het is een groot programma), maar daarna draait het echt handig en vlot bij mij.

Ik heb al gewerkt met combinatie flex/java (flex is ook een vorm van flash zeg maar). Ik moet zeggen dat dat niet zo heel makkelijk werkt vind ik. Een dergelijke combinatie als de Duitser aan werkt moet dus vele poorten openen. Echt leuk, hopelijk valt de licentie enzo wat mee.

[Reactie gewijzigd door Verwijderd op 27 juli 2024 13:11]