Project Ace versnelt ontwikkeling Java-applicaties

drizze rapporteerde dat Sun werkt aan een project genaamd Ace. Hoewel object-oriënted methodes en intensief hergebruik van code ervoor zorgen dat applicaties sneller ontwikkeld kunnen worden, moet het allemaal nog veel sneller kunnen vinden de mensen van Sun. Ace is een nieuwe technologie die zich boven de code bevindt. Om het te gebruiken is geen kennis nodig van achterliggende technieken als Java, Corba, .NET, databases et cetera. Met Ace wordt een begrijpelijk diagram gemaakt van de functionaliteit, in een UML-achtige vorm. Tijdens het maken van het diagram wordt zo min mogelijk nagedacht over de implementatie. Als het diagram af is kan een gewenst platform gekozen worden en wordt de code automatisch gegenereerd. Dit kan het ontwikkelen van software volgens Sun tot tien keer zo snel maken, vooral omdat het in een laat stadium aanbrengen van drastische veranderingen of uitbreidingen in een groot programma - de nachtmerrie van menig programmeur - met Ace een kwestie is van het diagram aanpassen en regenereren.

Als demonstratie van J2EE technologie heeft een Sun programmeur ooit een dierenwinkel gebouwd. Dit kostte hem zes maanden van zijn leven en het project bevatte meer dan 14.000 regels met de hand ingeklopte code. Toen Microsoft wilde bewijzen dat met .NET sneller ontwikkeld kan worden hebben ze een project met dezelfde funcionaliteit gemaakt bestaande uit 3.484 regels handgeschreven code. Nu met Ace kon een Sun programmeur exact dezelfde dierenwinkel bouwen met slechts 243 regels handgeschreven code, en dat binnen een week tijd. Het is ook mogelijk om uit bestaande applicaties een Ace diagram te extraheren:

The code that Ace generates is automatically performance-optimized for a given architecture and technology choice. By dramatically improving application performance, Ace can also increase application scalability.

Equally important, Ace can improve the performance and scalability of existing applications as well as new applications. Thus, programmers can reverse-engineer existing applications into Ace, making it easy to adopt different architectures.

Reacties (46)

Mmhh ik heb wel eens gewerkt met micro$oft frontpage. Hoef je je ook niet druk te maken over de achterliggende code om een website te designen. Maar dan moet je niet kijken naar de enorme berg garbage die hij erachter dumpt. De vaarg is dus met dit of het onder de huid wel allemaal zo effeicient loopt en is als dat de programmeur het met de hand doet. Want dan wordt er ook gekeken naar hoe "mooi" de code is en hoe iets met zo weinig mogelijk middelen geprogrameerd kan worden. Dit zal nog lang duren voor een programma dit net zo snel en mooi kan.

Er zijn ook wysiwyg editors die een stuk betere code afleveren dan frontpage. Maar het is uiteraard een afweging. Langere ontwikkeltijd maar wel de meest optimale code (als in: "het beste" wat de programmeur uit z'n vingers kan krijgen) maar een lange ontwikkeltijd, of een korte ontwikkeltijd maar code die misschien niet helemaal 100% optimaal is. Als het uiteindelijk net zo goed werkt (alleen in het laatste geval msischien iets langzamer) denk ik dat de meeste managers zullen kiezen voor een kortere ontwikkeltijd. Maar ja ik neem aan dat Sun de tool niet uit zou brengen als het resultaat een baggertrage code opleverd. En het is ook erg afhankelijk van wat de app moet doen, voor een app die vooral staat te wachten tot de gebruiker uitgetiept is en alle velden heeft gevuld, is snelheid van minder belang dan 1 of andere realtime tracking app.

Maar op zich vind ik het een hele goed ontwikkeling, misschien jammer voor een aantal pure code kloppers, maar tools die het ontwikkelen makkelijker en vooral sneller maken, kun je als bedrijf een hoop mee besparen, en dus ook als klant zijnde (goedkopere licentiekosten bijvoorbeeld).

Zeer knap programma zonder twijfel dat code genereert zonder moeite.

Ik heb echter zware twijfels bij de snelheid. Ja, ACE zal niet x=x+1; maar x++; schrijven, maar echt effectief programmeren ?

Ik denk eerder aan globale vertragingen zoals een lijst steeds opnieuw vullen terwijl het niet noig is. Een levende programmeur ziet zeer snel dat zoiets overbodig is maar gaat een programma begrijpen wat het schrijft ?

KAN een programma begrijpen wat het schrijft ?

Een test om te kijken of een compiler goed is, is om zichzelf te compileren, kan ACE zichzelf 'maken' ?

Miischien dat dit nuttig is om een algemene structuur te genereren voor een programma, maar om het echt effectief en gebruiksvriendelijk te maken zal altijd intensief hand programmeerwerk gedaan moeten worden.

Over enekele decennia kan de situatie veranderd zijn, maar voor het ogenblik denk ik dat dit grote quatsch is

Een test om te kijken of een compiler goed is, is om zichzelf te compileren, kan ACE zichzelf 'maken' ?

Ik ken java niet zo goed maar zou je met java een compiler kunnen schrijven?

Tuurlijk kan dat, een compiler leest text en genereerd daaruit een binair bestand. Dat kan in princiepe in iedere taal...

Ja, dat kan. Je kan in elke programmeertaal een compiler schrijven. Een compiler voor zichzelf zelfs

Ik moet je dan toch teleurstellen! Hoezo zou het niet kunnen? Je analyseert de code, maakt er machinecode of bytecode van. Toch geen probleem dat in C of java te doen? Met elke programmeertaal die met bestanden om kan gaan kun je een compiler maken. Je zou zelfs met java een C compiler kunnen maken.

Er is namelijk een java compiler in java. Hoe denk je dat anders JSP werkt (Java Serrver Pages). Jps bestanden worden in java Classes omgezet en dan gecompileerd. Sinds dit platformonafhankenlijk gebreurt komt hier geen C aan te pas.

Goh, gcc is toch echt in c geschreven hoor...
sterker nog, het compileren van gcc gaat in 3 stappen.

1. compileer gcc met je oude compiler
2. compileer gcc nogmaals met het resultaat van 1 (dus gcc met gcc)
3. compileer gcc een derde maal, maar nu met het resultaat van 2. controleer of de output van 2 en 3 hetzelfde zijn.

in welke taal dacht je dat de gnu c compiler geschreven is?

Dat is toch echt c...

Het is wel zo dat de eerste compiler van een bepaalde taal niet in die taal geschreven kan worden, want op dat moment is natuurlijk nog geen compiler beschikbaar voor die taal.

[edit]
in twee minuten 3 reacties... helaas ben ik de laatste.

Sterker nog, ik meende dat de javacompiler ook als object in Java beschikbaar is.

Ik weet alleen niet of daar gekke trucjes gebruikt worden

Nou is het vanaf scratch schrijven van een compiler in zijn eigen taal natuurlijk iets ingewikkelder dan dat (iets waaraan ik ooit nog eens een begin hoop te maken als oefening), maar het kan. Volgens mij is de noodzakelijke en voldoende voorwaarde dat de taal Turing compleet is.

Het is ooit bewezen dat het onmogelijk is om een compiler te maken die een taal kan compileren waarin hij zelf geschreven is.

Dan moet ik je toch echt teleurstellen. Wat dat je van GCC? Die compileerd zich zelf

De site Daar staat een hoop meer informatie

Helaas, de java-compiler zelf is geheel geschreven in Java. Alhoewel de eerste versies ervan wel 'native' C++ waren is 'ie nu helemaal in Java, met als enige stukje C++ de .exe die de VM opstart voor de compiler Op http://www.javasoft.com is zelfs de sourcecode van de compiler te downloaden

zware onzin.. alsof GCC in asm geschreven is

Ligt eraan waar je je focus wilt hebben
Snel een product af
Een product dat zeer snel werkt

Dit verkort de ontwikkeltijd gewoon enorm, maar zal qua snelheid niet optimaal zijn denk ik...

Ik denk dat dat redelijk meevalt.

Het grootste deel van de optimalisatie doet de compiler alsnog.
Of je nou x = x+1; of x++ schrijft, de compiler maakt er in de meeste gevallen hetzelfde van.

Voor vele andere zaken geld hetzelfde.
Wat dus nu de grootste taak van Sun is, is het verder optimaliseren van hun compiler, als zij willen dat iedereen Ace gebruikt.

Maar ze hoeven daarvoor dan weer niet perse de programmeertaal toegangkelijker te maken

[quote]Over enekele decennia kan de situatie veranderd zijn, maar voor het ogenblik denk ik dat dit grote quatsch is[/quote[

En waarom denk jij dat? Er moet ooit mee begonnen worden en ik ben er van overtuigd dat het gaat werken. UML is namelijk zeer goed om te zetten in OO-code.

Er zullen altijd specifieke zaken zijn die je net ff anders wilt dan voorgebakken code, maar voor het gros denk ik dat het razendsnel is.

En het gaat er ook om om de snelheid van het ontwikkelen niet te verhogen. Niet om al het programmeerwerk uit handen van de programmeur te nemen.

Ik zou het iig erg fijn vinden als ik zelf niet meer die diagrammen hoef te vertalen naar code. Ik ga in Java ook niet zelf een textbox op een scherm zetten, daar heb je een designer voor. Allemaal om de zaak te vereenvoudigen, tijd en dus kosten te besparen

Ik geloof dat ACE geoptimaliseerd is voor het progammeren van dierenwinkels

Is dit niet hetzelfde als wat er al in menige ontwikkel-tool zit?

Ik weet nog goed dat dBase IV al een Report tool en een Forms tool had. Als je het resultaat daarvan door ging kijken, kon ja ongeveer 90% van de code weg gooien omdat die geen doel diende.
Ik ben erg bang dat ACE hetzelfde gaat worden. Dat betekend dus dat een applicatie door ACE 10 keer sneller gebouwd kan worden, maar ook 10 keer slechter performed.

Ik houd het liever bij component based development. Daarmee kan ook heel wat tijd worden gewonnen, maar je hebt in ieder geval wel componenten die aan je eigen standaarden voldoen.....

mmm ... kweetniet. Als ik een project heb afgerond (wat we meestal in team verband doen). Dan is het grote voordeel toch eigenlijk altijd dat je een dieptekennis van het bedrijf, het project en de code overhoud. Dit is met deze technologie natuurlijk veel minder zo. Dit zou uitbreidingen kunnen bemoeilijken ... ook omdat je bij uitbreidingen weer afhankelijk bent van dezelfde technologie ...

Ik denk trouwens ook dat een design (en zeker UML) niet altijd in detail veel zegt over de code die er daadwerkelijk voor nodig is. Loop je niet snel tegen iets heel klantspecifieks aan, wat een ontwikkelaar toch wel erg vaak tegenkomt, en waar je moeite mee hebt in je design.

Ik ben ietwat sceptisch, maar dit betekent echter niet dat ik er niet voor opensta. Kijk het even aan.

Het nadeel is echter vaak wel van deze tools dat de uiteindelijke source code die de code generator maakt alleen fatsoenlijk te hergebruiken is mbv dezelfde tool. Dus als je naderhand het programma wilt gaan uitbreiden, of bugs er uit wilt halen of wat dan ook, dan ben je altijd verplicht om hetzelfde pakket te gebruiken. Want met de hand later een aanpassing doen lukt gewoonweg niet. De vraag blijft dan, is deze tool over een paar jaar nog te gebruiken (dit ivm compatibiliteit tov versienummers van bibliotheken en andere zaken). Zo niet, dan is het een typische korte termijn oplossing. En daar heb ik al te veel van gezien binnen de ICT.

mmmzzz....ik zie mijn baan in gevaar komen als dit zo door gaat
Anderzijds is dit natuurlijk wel een geweldige 'uitvinding'

Dit zal toch alleen maar voor appilcaties werken. Ik denk niet dat je hier een besturingssyteem mee kan schrijven of een driver.

Nee, het gaat hier volgends mij inderdaad over grotere apllicaties die voor de gebruiker zijn, zoals boekhoud systemen ofzo. Drivers zijn vaak kleinere stukjes code (relatief dan ), en daar ligt de nadruk niet zo zeer op het model, maar op het algoritme wat gebruikt word. Wat je met Ace vooral kan is modelleren. (Denk ik)

ach, dan zou iedere 4GL je baan in gevaar brengen.. beetje onzinnig.. probeer met dit UML dingetje maar es een vette java game te maken

Uitvinding? Het bestaat al lang, Microsoft verkoopt het onder de naam BizTalk Server.

Zou deze taal voor een on-ervaren programmeur (zoals ik) makkelijk te leren zijn?

Ik denk van wel. Bijna elk programmeertaal is makkelijk. Alleen ziet het er de eerste keer moeilijk uit wat veel mensen afschrikt waardoor ze blijven zeggen dat het moeilijk is. Maar na een paar dagen dan begin je het toch al te begrijpen.

En dan heb je de IT'ers die het moeten leren op school maar er gewoon geen zin hebben, dus uiteindelijk moet je het wel leuk vinden om het te leren en dat is zo met alles. Dus uiteindelijk kun je niet concluderen dat het makkelijk is en dat iedereen het kan leren!

dus uiteindelijk moet je het wel leuk vinden om het te leren

Nou, ik kan ook iets makkelijk leren wanneer ik het niet leuk vind.

...een intensief hergebruik van code...

dit is m.i. de reden dat veel programma's de zelfde fouten of onvolkomendheden bevatten, veel hergebruikte code zorgt voor te grote en te lompe programma's en idd hergebruik van code is zeker niet geschikt voor OSen (iets waar met windows veelvuldig de fout is ingegaan,nfi) Je moet nou eenmaal blind kunnen vertrouwen op de code die je hergebruikt en vaak is die code alleen maar als lib aangeleverd, dus niet betrouwbaar omdat je de source niet kent (of je moet gaan zitten decompilen - wat vaak dan weer niet mag)

Wat stel jij dan voor? Dat we het hele Object Geörienteerd Programmeren overboord gooien?
Voor een groot programma als een OS, games en andere zware applicaties is dat juist erg belangrijk.

hoho! Neem bv. de linux kernel. Hier komt geen OO code aan te pas. De Linux kernel is namelijk in C en niet in C++ geschreven.

Hiermee wil ik niet zeggen dat ik OO slecht vind!

5e generatie programmeertalen....het zat er aan te komen...dus is dit niet echt iets nieuws...
En volgens mij lijkt het programma sprekend op Rational Rose....

Generaties? Dat is het eerste wat ik daar van hoor. Heb je ergens een linkje waar eens overzichtje staat van de generaties met hun talen? Zou ik wel interessant vinden.

whatis.com zegt het volgende:

programming language generations

In the computer industry, these abbreviations are widely used to represent major steps or "generations" in the evolution of programming languages.

1GL or first-generation language was (and still is) machine language or the level of instructions and data that the processor is actually given to work on (which in conventional computers is a string of 0s and 1s).

2GL or second-generation language is assembler (sometimes called "assembly") language. A typical 2GL instruction looks like this:

ADD 12,8


An assembler converts the assembler language statements into machine language.

3GL or third-generation language is a "high-level" programming language, such as PL/I, C, or Java. Java language statements look like this:

public boolean handleEvent (Event evt) {
switch (evt.id) {
case Event.ACTION_EVENT: {
if ("Try me" .equald(evt.arg)) {


A compiler converts the statements of a specific high-level programming language into machine language. (In the case of Java, the output is called bytecode, which is converted into appropriate machine language by a Java virtual machine that runs as part of an operating system platform.) A 3GL language requires a considerable amount of programming knowledge.

4GL or fourth-generation language is designed to be closer to natural language than a 3GL language. Languages for accessing databases are often described as 4GLs. A 4GL language statement might look like this:

EXTRACT ALL CUSTOMERS WHERE "PREVIOUS PURCHASES" TOTAL MORE THAN $1000


5GL or fifth-generation language is programming that uses a visual or graphical development interface to create source language that is usually compiled with a 3GL or 4GL language compiler. Microsoft, Borland, IBM, and other companies make 5GL visual programming products for developing applications in Java, for example. Visual programming allows you to easily envision object-oriented programming class hierarchies and drag icons to assemble program components.