Nieuwe Java-release ondersteunt meertaligheid
Sun Microsystems heeft gisteren de langverwachte nieuwe versie van Java Platform Standard Edition (Java SE) vrijgegeven: versie 6 met de codenaam Mustang. Nieuwe features omvatten onder meer een betere performance en ondersteuning van scriptingtalen.
Door de aanwezigheid van deze feature kunnen ontwikkelaars vanaf heden Java-code mixen met die uit andere talen, zoals PHP, Python, Ruby en JavaScript. In het verleden was het altijd zo dat Sun wilde dat Java de oplossing was voor alle ontwikkelproblemen, aldus chief Java SE-engineer Mark Reinhold, maar developers wilden juist graag gebruikmaken van de hun bekende talen om hybride applicaties te ontwikkelen. Op Suns website is een verzameling scriptengines te vinden die gebruikt kunnen worden in combinatie met Java SE 6. Verder is door Sun gewerkt aan de performance van de Java HotSpot-virtual machine en de garbage collection. Volgens Bill Curci, manager productmarketing bij Sun, zou de nieuwe Java-technologie minstens 10 tot 15 procent sneller moeten zijn geworden.
Java SE 6 is voorzien van ondersteuning voor Windows Vista, dat enkele weken geleden aan bedrijven is beschikbaar gesteld. Tijdens de ontwikkeling van dat nieuwe besturingssysteem hebben Java-engineers zich meerdere malen in moeilijke bochten moeten wringen om api's goed geïmplementeerd te krijgen, maar in de definitieve versie van Windows Vista werkt alles op de juiste wijze. Microsoft en Sun hebben onder de noemer 'Project Tango' samengewerkt aan het beter interoperabel maken van Java- met Microsoft-technologie. Dit is onder meer zichtbaar in de nieuwe Java API for XML Web Services 2.0. Daarnaast heeft Sun nieuwe tools gebouwd die gebruikt kunnen worden voor het diagnosticeren, beheren en monitoren van Java-applicaties.
Java SE 6 is de eerste versie van de de Java-software die op een open wijze is ontwikkeld: wekenlang werden er 'weekly builds' op het web geplaatst en hebben ruim 160 bedrijven en 330 externe ontwikkelaars meegewerkt aan het verbeteren van de Java-code. In totaal heeft de community 750 bugs gemeld en zijn er meer dan 300 patches geleverd. Ontwikkelaars die direct aan de slag willen gaan met de nieuwe Java-technologie kunnen zestig dagen gratis gebruikmaken van het Sun Developer Expert Assistance-programma. Verder heeft Sun een nieuwe versie ontwikkeld van de NetBeans-ontwikkelomgeving, die onder meer voorzien is van de nieuwe GUI Builder, codenaam Matisse, en support aan boord heeft voor de nieuwe features van Java SE 6.
Reacties (41)
Sweet.
Jammer dat we bij mijn bedrijf net gemigreerd zijn naar 1.4, duurt nog wel ff voordat ik met deze technieken aan de gang mag das...
Jammer dat we bij mijn bedrijf net gemigreerd zijn naar 1.4, duurt nog wel ff voordat ik met deze technieken aan de gang mag das...
waarom nu migreren naar 1.4?
kan je niet gewoon wat versies overslaan en direct naar 5 gaan?
da stable build van Java 5 is toch ool al een lange tijd uit dacht ik?
kan je niet gewoon wat versies overslaan en direct naar 5 gaan?
da stable build van Java 5 is toch ool al een lange tijd uit dacht ik?
hier kan je alvast de JDK of JRE vinden
Ik vind het een beetje vreemd om hybride applicaties te gaan ontwikkelen, lijkt me de onderhoudbaarheid van software niet echt ten goede komen.
Het is natuurlijk wel een manier om de drempel voor het gebruik van java te verlagen.
Het is natuurlijk wel een manier om de drempel voor het gebruik van java te verlagen.
Nou, toch zijn er wel gevallen waarvoor dat heel handig is. Denk bijvoorbeeld aan een webapplicatie waar validaties nodig zijn op ingevoerde gegevens. Die controles wil je het liefst eerst op de client doen om de server niet onnodig te belasten en om een snelle response te behouden. Maar die controles moeten uiteindelijk ook op de server worden gedaan omdat het altijd mogelijk is dat iemand op een client de code heeft gemanipuleerd.
Tot nu toe moest die code dus twee keer worden geschreven, nu kun je in zo'n geval volstaan met één javascript versie.
Tot nu toe moest die code dus twee keer worden geschreven, nu kun je in zo'n geval volstaan met één javascript versie.
als je die validaties clientside houdt, zijnze niet echt herbruikbaar laat staan dat het onderhouden soepel verloopt.. maarja dat is voornamelijk een verschil tussen JAVA developers (server side) en Oracle developers (client side)
Client side validatie is enkel voor gebruikersgemak. Er is altijd server side validatie nodig als je het vanuit een security standpunt bekijkt. De client side validatie kan namelijk door die client ontweken worden.
Die is al niet meer echt onderhoudbaar... wat dacht je van een mix van: HTML, CSS, JavaScript, Ajax, JSP, Struts, Maven, Spring, Hibernate. Dat is toch de grootste wens van ongeveer 99% van de bedrijven (iig als je de vacatures bekijkt). Owh en natuurlijk UML....Ik vind het een beetje vreemd om hybride applicaties te gaan ontwikkelen, lijkt me de onderhoudbaarheid van software niet echt ten goede komen.
@krpros
Dat hoort niet in het rijtje thuis van gemixte talen, maar in het rijtje wensen van bedrijven.
Leuk, maar werkt het ook goed onder Linux?maar in de definitieve versie van Windows Vista werkt alles op de juiste wijze
UML? Dat is slechts voor het ontwerp, en dat blijft nogal uniform over wat voor een applicatie je ook gaat maken. Waarom zet je dat er bij?
Mwah, het lijstje wat je daar noemt lijkt me nu niet het voorbeeld van ononderhoudbaarheid. Html en Jsp zijn eigenlijk hetzelfde: puur je view data gestructureerd weergeven. Css is duidelijk voor de vormgeving van je applicatie. Ajax is iets dat je eventueel in je tags kunt integreren waardoor je de javascript helemaal niet meer terug ziet. Struts icm Spring is inderdaad ietsje lastiger als je het samen gaat gebruiken. Je zult ietsje dubbel moeten configureren, maar het is nog goed te doen. Hibernate daarintegen is heel simpel te integreren met Spring. Maven vervolgens als buildtool gebruiken heeft alleen maar voordelen en maakt het project eerder overzichtelijker.
En UML? Ja, UML gebruik je in de ontwerp fase. Laat UML nu eens via tools heel makelijk al naar code om te zetten te zijn.
Conclusie: Je verhaal raakt kant nog wal. Het is hetzelfde als zeggen dat apache + php + mysql + cvs wel heel erg ingewikkeld wordt omdat je vier dingen gebruikt (om er even een bij tweakers iets bekendere combo bij te halen)
En UML? Ja, UML gebruik je in de ontwerp fase. Laat UML nu eens via tools heel makelijk al naar code om te zetten te zijn.
Conclusie: Je verhaal raakt kant nog wal. Het is hetzelfde als zeggen dat apache + php + mysql + cvs wel heel erg ingewikkeld wordt omdat je vier dingen gebruikt (om er even een bij tweakers iets bekendere combo bij te halen)
Dus moet ik concluderen dat als je HTML kent (en geen Java) je dus ook JSP kent. Voledige flauwekul wat mij betreft. Mijn punt is dat alle door mij opgenoemde Talen/dialecten onderling verschillend zijn (hetzij licht, hetzij zwaar) en door deze allen te mixen het geheel niet overzichtelijker wordt.Html en Jsp zijn eigenlijk hetzelfde
Apache is geen programmeertal/script .. eventueel zou je de /etc/httpd.conf als script kunnen beschouwen.
MySQL is ook geen programmeertal/script... SQL heb ik al uit het lijstje gelaten ivm Hibernate.
CVS is ook geen programmeertal/script.
Weliswaar hebben Maven, Hibernate, Struts allen als basis XML, maar zo heeft de rest als basis ASCII. Sterker nog ik kan nu dus stellen dat ASM, Java en C++ eingelijk hetzelfde zijn.
Nee, andersom. Als je jsp kent dan ken je ook html. Html is helemaal niet moeilijk. Er zijn maar een paar tags die je moet kennen om te zorgen dat je je gebeuren semantisch op orde hebt. Css daarintegen is vaak wat ingewikkelder vanwege de slechte implementatie in sommige browsers.
Daarnaast vraag ik me af of je Hibernate, Maven en Struts kent. Ik begrijp namelijk niet waarom je dit talen of dialecten wilt noemen. Ik kan dan eigenlijk ook geen enkele andere conclusie trekken dan dat je de termen enkel van de vacature sites kent.
Hibernate is geen taal maar een tool. Het is een (in java geschreven) OR mapper die de koppeling met een database juist simpeler maakt vergeleken met (standaard) jdbc.
Struts is een MVC platform waarbij je een stuk standaard implementatie (weer in java) hebt die je enkel uit hoeft te breiden.
Maven is vervolgens een build tool. Als je Ant had gezegd had je heel misschien een punt gehad aangezien je daar nog veel zelf moet implementeren. Maven is juist de uitbreiding die standaard al weer een berg geimplementeerd heeft waardoor je zelf enkel nog je project specifieke uitbreidingen hoeft te doen.
Maar goed, als deze standaard combo van frameworks die simpel samen te configureren zijn (een applicatie config voor de spring, eventueel enkele hbm.xml bestanden voor je pojo's, en helaas nog wel een apparte spring config waarin je enkele beans uit je application config moet herdefinieren) voor jou blijkbaar de boel al onoverzichtelijk maken.......
Daarnaast vraag ik me af of je Hibernate, Maven en Struts kent. Ik begrijp namelijk niet waarom je dit talen of dialecten wilt noemen. Ik kan dan eigenlijk ook geen enkele andere conclusie trekken dan dat je de termen enkel van de vacature sites kent.
Hibernate is geen taal maar een tool. Het is een (in java geschreven) OR mapper die de koppeling met een database juist simpeler maakt vergeleken met (standaard) jdbc.
Struts is een MVC platform waarbij je een stuk standaard implementatie (weer in java) hebt die je enkel uit hoeft te breiden.
Maven is vervolgens een build tool. Als je Ant had gezegd had je heel misschien een punt gehad aangezien je daar nog veel zelf moet implementeren. Maven is juist de uitbreiding die standaard al weer een berg geimplementeerd heeft waardoor je zelf enkel nog je project specifieke uitbreidingen hoeft te doen.
Maar goed, als deze standaard combo van frameworks die simpel samen te configureren zijn (een applicatie config voor de spring, eventueel enkele hbm.xml bestanden voor je pojo's, en helaas nog wel een apparte spring config waarin je enkele beans uit je application config moet herdefinieren) voor jou blijkbaar de boel al onoverzichtelijk maken.......
Uitgezonderd van Struts ken ik alle door mij opgenoemde technieken (ja ook ASM en C++).
Ik probeer het nog een keer :: Jij beweert dat Hibernate geen taal/script is. Dan zou je ook kunnen zeggen dat HTML geen taal/script is. De browser is namenlijk een tool (geschreven meestal in C++) die HTML gebruikt om een pagina weer te geven. Ik kan jou argumentatie ook omdraaien: zonder een pom.xml te schrijven doet hibernate niets. En ja er zijn vast grafische tools voor om deze pom.xml, maar deze zijn er ook voor HTML en ook vaar Java.
pom.xml moet hbm.xml zijn
.. pom is naturrlijk voor Maven
Over Maven kan ik ook weer een dergelijk verhaal opratelen maar dat laat ik maar.
Kritiek geven in de wereld van J2EE, Hibernate, Struts, Maven, HTML, Ajax is op dit moment niet geliefd dat weet ik. Ik werk dagelijks met de deze technieken en moet telkens weer vaststellen dat er teveel schapen-gedrag vertoond wordt. Het probleem met de technieken is wat mij betreft niet de complexiteit om deze technieken technieken te gebruiken. Ik kan bijna elke VMBO-er JSP,JavaScript, HTML, Maven bijbrengen. Het wordt echter een probleem als dingen om de 1 of andere reden niet functioneren zoals verwacht. Dan moet er opeens een process in je hoofd gaan lopen die een samenhang tussen de technieken begrijpt. Vervolgens moet je gaan achterhalen hoe dingen in elkaar grijpen en hoe deze vertaald worden. In het kort: een computer in de auto zorgt ervoor dat de auto efficienter rijd en meer kan, en misschien eenvoudiger te bouwen is, maar als er een probleem optreed kan de automonteur weinig meer doen.
Ik probeer het nog een keer :: Jij beweert dat Hibernate geen taal/script is. Dan zou je ook kunnen zeggen dat HTML geen taal/script is. De browser is namenlijk een tool (geschreven meestal in C++) die HTML gebruikt om een pagina weer te geven. Ik kan jou argumentatie ook omdraaien: zonder een pom.xml te schrijven doet hibernate niets. En ja er zijn vast grafische tools voor om deze pom.xml, maar deze zijn er ook voor HTML en ook vaar Java.
pom.xml moet hbm.xml zijn
.. pom is naturrlijk voor MavenOver Maven kan ik ook weer een dergelijk verhaal opratelen maar dat laat ik maar.
Kritiek geven in de wereld van J2EE, Hibernate, Struts, Maven, HTML, Ajax is op dit moment niet geliefd dat weet ik. Ik werk dagelijks met de deze technieken en moet telkens weer vaststellen dat er teveel schapen-gedrag vertoond wordt. Het probleem met de technieken is wat mij betreft niet de complexiteit om deze technieken technieken te gebruiken. Ik kan bijna elke VMBO-er JSP,JavaScript, HTML, Maven bijbrengen. Het wordt echter een probleem als dingen om de 1 of andere reden niet functioneren zoals verwacht. Dan moet er opeens een process in je hoofd gaan lopen die een samenhang tussen de technieken begrijpt. Vervolgens moet je gaan achterhalen hoe dingen in elkaar grijpen en hoe deze vertaald worden. In het kort: een computer in de auto zorgt ervoor dat de auto efficienter rijd en meer kan, en misschien eenvoudiger te bouwen is, maar als er een probleem optreed kan de automonteur weinig meer doen.
hbm hoeft totaal niet complex te zijn als je hibernate annotations gebruikt. Hibernate is een library geen tool of taal.
Ik beweer dat het gebruik van deze frameworks en tools je applicatie eerder makkelijker en overzichtelijker maken dan onoverzichtelijk. Natuurlijk kun je je *.hbm.xml weglaten, maar dan zul je wel een bak jdbc code moeten maken. Je kunt ook je pom weglaten, maar dan zul je je hele bouw en deploy stap met de hand moeten doen, zelf de jusite libs moeten downloaden en zorgen dat je IDE config gelijk blijft met je build gebeuren.
Je mag gerust kritiek geven op die termen, maar kom dan ook met steekhoudende argumenten. Dat het gebruik van deze, duidelijk gescheide en op specifieke onderdelen van je applicatie gerichte technieken je applicatie slecht onderhoudbaar maken is dat in ieder geval niet.
En over je verhaal over de VMBO-er? Tja, in mijn hoofd loopt dat process inderdaad. Het lijkt me ook niet meer dan logisch dat een software ontwikkelaar dit process in zijn hoofd heeft lopen. Ikzelf ben trouwens van mening dat een software ontwikkelaar het ook zonder de tools zou moeten kunnen, maar meer ook niet. Ik zal mezelf vast neit populair maken met de volgende opmerking, maar software ontwikkeling op dit niveau is nu eenmaal niet voor die VMBO-er weggelegd. Mocht het process niet lopen dan kan hij daarvoor aankloppen bij de HIO-er of Academicus die het voor hem op kan lossen, precies zoals die automonteur ook zal moeten doen.
Je mag gerust kritiek geven op die termen, maar kom dan ook met steekhoudende argumenten. Dat het gebruik van deze, duidelijk gescheide en op specifieke onderdelen van je applicatie gerichte technieken je applicatie slecht onderhoudbaar maken is dat in ieder geval niet.
En over je verhaal over de VMBO-er? Tja, in mijn hoofd loopt dat process inderdaad. Het lijkt me ook niet meer dan logisch dat een software ontwikkelaar dit process in zijn hoofd heeft lopen. Ikzelf ben trouwens van mening dat een software ontwikkelaar het ook zonder de tools zou moeten kunnen, maar meer ook niet. Ik zal mezelf vast neit populair maken met de volgende opmerking, maar software ontwikkeling op dit niveau is nu eenmaal niet voor die VMBO-er weggelegd. Mocht het process niet lopen dan kan hij daarvoor aankloppen bij de HIO-er of Academicus die het voor hem op kan lossen, precies zoals die automonteur ook zal moeten doen.
nou dan echt de laatste . Mijn eerste kommentaar gaat ook niet over of iets beter of slechter is om te gebruiken bij het ontwikkelprocess. Er werd alleen door RedBeard beweerd dat het de onderhoudbaarheid van software niet ten goede komt er verschillende talen aan toe te voegen. En ik heb daarna vermeldt dat er al genoeg talen om java heen gebouwd zijn en dat die paar extra script taaltjes er ook niet meer toe doen. Persoonlijk zou ik zelf het liefst alle onnodige rommel uit de Java SDK smijten en deze als APIs/modulen beschikbaar maken. Zou het bijvoorbeeld mooi vinden als Sun ging besluiten Swing weer terug te doen in een externe lib (zoals het vroeger was). Dan heb ik in ieder geval de mogelijkheid voor SWT te kiezen zonder dat ik de Swing rommel meedraag. Hetzelfde geldt voor de ingebakken XML parser. Deze nieuwe script-talen zouden ook gewoon Plugable moeten zijn. Sun is wat dat betreft net Microsoft... we leveren alles mee zodat de mensen het automatisch gaan gebruiken en er aan gewend raken. Positief daaraan is dat iedereen dan iig dezelfde collection-klassen/ (N)IO klassen benut (ware het niet dat Apache dat gedeeeltelijk nog een keer opnieuw geimplementeerd heeft)
. Mijn eerste kommentaar gaat ook niet over of iets beter of slechter is om te gebruiken bij het ontwikkelprocess. Er werd alleen door RedBeard beweerd dat het de onderhoudbaarheid van software niet ten goede komt er verschillende talen aan toe te voegen. En ik heb daarna vermeldt dat er al genoeg talen om java heen gebouwd zijn en dat die paar extra script taaltjes er ook niet meer toe doen. Persoonlijk zou ik zelf het liefst alle onnodige rommel uit de Java SDK smijten en deze als APIs/modulen beschikbaar maken. Zou het bijvoorbeeld mooi vinden als Sun ging besluiten Swing weer terug te doen in een externe lib (zoals het vroeger was). Dan heb ik in ieder geval de mogelijkheid voor SWT te kiezen zonder dat ik de Swing rommel meedraag. Hetzelfde geldt voor de ingebakken XML parser. Deze nieuwe script-talen zouden ook gewoon Plugable moeten zijn. Sun is wat dat betreft net Microsoft... we leveren alles mee zodat de mensen het automatisch gaan gebruiken en er aan gewend raken. Positief daaraan is dat iedereen dan iig dezelfde collection-klassen/ (N)IO klassen benut (ware het niet dat Apache dat gedeeeltelijk nog een keer opnieuw geimplementeerd heeft)"Html en Jsp zijn eigenlijk hetzelfde Dus moet ik concluderen dat als je HTML kent (en geen Java) je dus ook JSP kent. Voledige flauwekul wat mij betreft."
mag je mij uitleggen dan, hoe dat Voledige flauwekul is. Als je dynamische websites kan maken kan je met jsp omgaan ongeacht of je java kent. Bij normale bedrijven zit er geen java code in jsp's.
HTML CSS en Javascript komt in elke webapplicatie terug, alhoewel alle nieuw bouw die ik zie is allemaal xhtml, wat een subset van xml is. (dat het bij de client vanwege ongerelateerde zaken anders aankomt..)
(Ajax)Asynchronous JavaScript and XML, die twee hadden we al.
- Struts is java..
- Maven is java dat geconfigureerd word in/dmv xml...
- Spring is java dat geconfigureerd word in/dmv xml...
- Hibernate is java(ja het maakt gebruik van HQL om objecten te querien) en een stukje xml om het te configureren.
xml (en xhtml?)
css
javascript
java
HQL
als je spring bebruikt heb je als het goed is een mooi gelaagd model en als je het per laag bekijkt valt het nog meer mee.
het grootste gedeelte niet java is configuratie welke volgens mij niet zo veel maintanace issues heeft.
Als je kijkt naar de talen hebben die allemaal een specifieke taken.
Waar Redbeard op doelt is volgens mij verschillende talen met de zelfde taak/doel. En ik denk dat dat klopt omdat het dan de zelfde persoon meerdere talen in de diepte moet kennen. Volgens mij hoeven programmeurs niet op de hoogte te zijn van bv alle CSS hacks omdat het echte werk waarschijnlijk door een design engineer word gedaan anders om zal de design engineer weer weinig op hebben met Java etc etc.
mag je mij uitleggen dan, hoe dat Voledige flauwekul is. Als je dynamische websites kan maken kan je met jsp omgaan ongeacht of je java kent. Bij normale bedrijven zit er geen java code in jsp's.
HTML CSS en Javascript komt in elke webapplicatie terug, alhoewel alle nieuw bouw die ik zie is allemaal xhtml, wat een subset van xml is. (dat het bij de client vanwege ongerelateerde zaken anders aankomt..)
(Ajax)Asynchronous JavaScript and XML, die twee hadden we al.
- Struts is java..
- Maven is java dat geconfigureerd word in/dmv xml...
- Spring is java dat geconfigureerd word in/dmv xml...
- Hibernate is java(ja het maakt gebruik van HQL om objecten te querien) en een stukje xml om het te configureren.
xml (en xhtml?)
css
javascript
java
HQL
als je spring bebruikt heb je als het goed is een mooi gelaagd model en als je het per laag bekijkt valt het nog meer mee.
het grootste gedeelte niet java is configuratie welke volgens mij niet zo veel maintanace issues heeft.
Als je kijkt naar de talen hebben die allemaal een specifieke taken.
Waar Redbeard op doelt is volgens mij verschillende talen met de zelfde taak/doel. En ik denk dat dat klopt omdat het dan de zelfde persoon meerdere talen in de diepte moet kennen. Volgens mij hoeven programmeurs niet op de hoogte te zijn van bv alle CSS hacks omdat het echte werk waarschijnlijk door een design engineer word gedaan anders om zal de design engineer weer weinig op hebben met Java etc etc.
@Mr_light
Je geeft een compleet nieuwe visie op de definitie voor het woordje 'is'
Struts is Java... iemand die Struts kan die kan ook Java .. en iemand die Java kan die kan ook Struts. Dat is dus wel makkelijk dan hoef ik als ik een boek aanschaf slechts 1 boek aan te schaffen hetzij een boek over Java hetzij een boek over Struts. Aangezien de twee identiek aan elkaar zijn beschrijven boeken over Java en boeken over Struts dus precies hetzelfde.
Om het geheel nog verder te ontkrachten... volgens mij zou je bijvoorbeeld Maven prima met C++ kunnen bouwen. Er is niemand die dat doet, maar theoretisch kan het.
Wat ik nu al de hele tijd probeer duidelijk te maken is dat niet al deze technieken hetzelfde zijn. Het is gewoon niet zo dat als je weet wat XML is dat je dan automatisch alle andere technieken die er gebruik van maken ook kent. Als je HTML kent weet je niet automatisch wat CSS en/of Javascript is.
Je geeft een compleet nieuwe visie op de definitie voor het woordje 'is'
Struts is Java... iemand die Struts kan die kan ook Java .. en iemand die Java kan die kan ook Struts. Dat is dus wel makkelijk dan hoef ik als ik een boek aanschaf slechts 1 boek aan te schaffen hetzij een boek over Java hetzij een boek over Struts. Aangezien de twee identiek aan elkaar zijn beschrijven boeken over Java en boeken over Struts dus precies hetzelfde.
Om het geheel nog verder te ontkrachten... volgens mij zou je bijvoorbeeld Maven prima met C++ kunnen bouwen. Er is niemand die dat doet, maar theoretisch kan het.
Wat ik nu al de hele tijd probeer duidelijk te maken is dat niet al deze technieken hetzelfde zijn. Het is gewoon niet zo dat als je weet wat XML is dat je dan automatisch alle andere technieken die er gebruik van maken ook kent. Als je HTML kent weet je niet automatisch wat CSS en/of Javascript is.
Als het geen Java is dan is het iets anders (tis maar net hoe je het beestje wil noemen). Laten we zeggen het heet JSP-code ... iig als er niet iets afwijkends van HTML in zou zitten dan zou ik het dus ook onder IIS moeten kunnen laten lopen. Bovendien is je opmerking over "omgaan met JSP" ook weer compleet er naast geschoten. Wat mij betreft zijn er miljoenen Nederlanders die met hun auto om kunnen gaan, maar hoeveel Nederlanders kennen hun auto ? Er zijn ook mensen die kunnen omgaan met een Java-compiler. Zodra ze een Java bestand krijgen kunnen ze het compileren. Ze kunnen dus omgaan met Java, maar kennen doen ze het wat mij betreft niet.Bij normale bedrijven zit er geen java code in jsp's.
Dat kan nog eens interessant wordenJava-code mixen met die uit andere talen, zoals PHP, Python, Ruby en JavaScript
Over de codenaam Mustang: Al een paar maanden geleden heeft Sun officieel de codenamen laten vervallen. De naam Mustang voor JDK 6 wordt dus niet meer gebruikt, en de naam Dolphin voor de volgende versie (JDK 7) wordt ook niet meer gebruikt.
Waar het verhaaltje hierboven op doelt is de nieuwe scripting API die in Java zit ingebakken (package: javax.script). Deze API maakt het heel gemakkelijk om scripts geschreven in talen zoals Python, JavaScript, Ruby enz. vanuit een Java programma aan te roepen. Dit is overigens niet iets heel nieuws, er bestond al lang een library (Rhino) om JavaScript en andere scripttalen te kunnen gebruiken vanuit Java; de implementatie in JDK 6 is gewoon een versie van Rhino.
En natuurlijk betekent dit niet dat we ineens allemaal hybride applicaties gaan maken waarin allerlei talen door elkaar gebruikt worden.
Meer over wat er allemaal nieuw en verbeterd is kun je hier vinden: Java SE 6 Key Features
Waar het verhaaltje hierboven op doelt is de nieuwe scripting API die in Java zit ingebakken (package: javax.script). Deze API maakt het heel gemakkelijk om scripts geschreven in talen zoals Python, JavaScript, Ruby enz. vanuit een Java programma aan te roepen. Dit is overigens niet iets heel nieuws, er bestond al lang een library (Rhino) om JavaScript en andere scripttalen te kunnen gebruiken vanuit Java; de implementatie in JDK 6 is gewoon een versie van Rhino.
En natuurlijk betekent dit niet dat we ineens allemaal hybride applicaties gaan maken waarin allerlei talen door elkaar gebruikt worden.
Meer over wat er allemaal nieuw en verbeterd is kun je hier vinden: Java SE 6 Key Features
En zie hier een overzicht van beschikbare scripting engines:
https://scripting.dev.java.net/#engines
Echt vet, Scheme staat er ook tussen.
https://scripting.dev.java.net/#engines
Echt vet, Scheme staat er ook tussen.
Je zou ook zoiets kunnen bedenken als scripting in bv Office. Met VBA kan een gebruiker zelf tools binnen applicaties schrijven, nu zou die gebruiker dat op dezelfde manier ook in java applicaties kunnen doen.
Dat mixen van code valt wel mee eigenlijk. Je kunt niet letterlijk in een bestand twee dingen heel eenvoudig door elkaar gebruiken.
Wel kan het handig zijn om bepaalde dingen te kunnen scripten. Zo kun je sommige dingen makkelijk aanpasbaar maken zonder de hele applicatie om te hoeven schrijven.
Dit soort dingen konden overigens "vroeger" ook al, alleen is het nu gestandaardiseerd.
Wel kan het handig zijn om bepaalde dingen te kunnen scripten. Zo kun je sommige dingen makkelijk aanpasbaar maken zonder de hele applicatie om te hoeven schrijven.
Dit soort dingen konden overigens "vroeger" ook al, alleen is het nu gestandaardiseerd.
Meer support voor scripting vind ik lang niet de meest in het oog springende. Er is ook een hoop verbeterd voor client software, dat werd hoog tijd ook. Presentatie en performance van Swing schijnt enorm verbeterd te zijn, en er zijn features toegevoegd als system tray support en splash screens bij jvm startup. De meeste artikelen over jdk 6 spreken dan ook over een "desktop revolution" maar dit vind ik wel heel erg voorbarig en optimistisch.
Verder is er weer een hele hoop verbeterd te zijn in de core, en de performance schijnt weer beter te zijn geworden. Hoe ze dat elke keer doen daar verbaas ik me nog steeds over. Java is al bloedsnel als je in aanmerking neemt dat het in een vm draait.
In tegenstelling tot versie 5 is er dit keer nauwelijks iets gewijzigd aan de syntax van de taal.
Verder is er weer een hele hoop verbeterd te zijn in de core, en de performance schijnt weer beter te zijn geworden. Hoe ze dat elke keer doen daar verbaas ik me nog steeds over. Java is al bloedsnel als je in aanmerking neemt dat het in een vm draait.
In tegenstelling tot versie 5 is er dit keer nauwelijks iets gewijzigd aan de syntax van de taal.
Volgens mij is dit de enige manier waarop Sun kan zorgen dat Java relevant blijft.
Er zijn een aantal beperkingen in Java die productiviteit van de ontwikkelaar erg in de weg zitten. Ruby on Rails is een voorbeeld van een alternatief voor Java om web-applicaties te maken, waarbij het ontwikkelen vele malen efficienter gaat. (Voor haast alle web-applicaties.)
Op het ogenblik lijkt het erop dat een groot aantal visionairies aan het zoeken zijn naar een alternatief voor Java. Door Java te veranderen, zodat het een algemeen platform word voor allerlei talen, blijft het relevant.
Voor meer informatie kan ik het boek Beyond Java aanraden.
Aan de andere kant is het eigenlijk helemaal niet zo spannend wat Sun doet. Als je naar de scripting-engines kijkt dan is het duidelijk te zien dat al die engines al lang bestaande projecten zijn. Dus het was allang mogenlijk om dit soort dingen te doen, maar het is nu beter geintergreerd.
Er zijn een aantal beperkingen in Java die productiviteit van de ontwikkelaar erg in de weg zitten. Ruby on Rails is een voorbeeld van een alternatief voor Java om web-applicaties te maken, waarbij het ontwikkelen vele malen efficienter gaat. (Voor haast alle web-applicaties.)
Op het ogenblik lijkt het erop dat een groot aantal visionairies aan het zoeken zijn naar een alternatief voor Java. Door Java te veranderen, zodat het een algemeen platform word voor allerlei talen, blijft het relevant.
Voor meer informatie kan ik het boek Beyond Java aanraden.
Aan de andere kant is het eigenlijk helemaal niet zo spannend wat Sun doet. Als je naar de scripting-engines kijkt dan is het duidelijk te zien dat al die engines al lang bestaande projecten zijn. Dus het was allang mogenlijk om dit soort dingen te doen, maar het is nu beter geintergreerd.
Beetje spijtig dat de installer niet in MSI formaat is uitgebracht... Vonnet ideaal om Java via GPO's automatisch aan PC's toe te kennen, dat lukt zo niet meer...
Wat ik vooral spijtig vind, is dat er nog geen Mac OS X versie is ....
Wel al de nieuwe netbeans.
Wel al de nieuwe netbeans.
Toch is het niet helemaal correct om Ruby on Rails te vergelijken met Java. Dan zou je Ruby moeten vergelijken met Java. Meer in het algemeen kun je dan dynamische talen vergelijken met statisch getypeerde talen.
Maar als je kijkt naar een aantal demo's van de nieuwste Netbeans IDE dan zie je dat er voor Java ook tools ontwikkeld worden om snel 'scaffolds' op te zetten, zoals Ruby on Rails dat ook doet.
Edit: Was bedoeld als reactie op de post van Cappen...
Maar als je kijkt naar een aantal demo's van de nieuwste Netbeans IDE dan zie je dat er voor Java ook tools ontwikkeld worden om snel 'scaffolds' op te zetten, zoals Ruby on Rails dat ook doet.
Edit: Was bedoeld als reactie op de post van Cappen...
Ik heb Ruby on Rails ook als voorbeeld gegeven. 
Ruby on Rails is een voorbeeld van een framework, zoals dat niet direct mogenlijk is in Java.
Het handige van Ruby is dat het (beperkt) meta-programming mogenlijk maakt. Waardoor je dus later in het ontwikkel proces de structuur van het programma kunt aanpassen.
Een voorbeeld: Bij Java is het niet mogenlijk om methodes aan classes toe te voegen na afloop van het compileren, die bijvoorbeeld afhankelijk zijn van je database structuur, die je pas weet tijdens het opstarten van je programma.
Ruby on Rails gebruik die functionaliteit van Ruby om bij het opstarten nuttige methodes toe te voegen aan objecten afhankelijk van de database-structuur.
Natuurlijk zijn die handige methoden niet nodig, maar ze maken het wel makkelijker en dus efficienter om mee te werken.
Ook is het zo dat er veel aspect-georienteerde extensies zijn die dit soort functionaliteit wil toevoegen aan Java. Maar dan hebben we het niet meer over de Java-taal.
Om ook even te reageren op 'scaffolds':
Het verschijnsel van een programma dat alvast een beginopzetje maakt van een applicatie, zoals met 'scaffolds' bestaat natuurlijk al heel lang. Ik denk ook niet dat een goed voorbeeld is van wat Ruby on Rails beter maakt. Wel moet ik zeggen dat het goed uitgewerkt is in dit geval.
Ruby on Rails is een voorbeeld van een framework, zoals dat niet direct mogenlijk is in Java.
Het handige van Ruby is dat het (beperkt) meta-programming mogenlijk maakt. Waardoor je dus later in het ontwikkel proces de structuur van het programma kunt aanpassen.
Een voorbeeld: Bij Java is het niet mogenlijk om methodes aan classes toe te voegen na afloop van het compileren, die bijvoorbeeld afhankelijk zijn van je database structuur, die je pas weet tijdens het opstarten van je programma.
Ruby on Rails gebruik die functionaliteit van Ruby om bij het opstarten nuttige methodes toe te voegen aan objecten afhankelijk van de database-structuur.
Natuurlijk zijn die handige methoden niet nodig, maar ze maken het wel makkelijker en dus efficienter om mee te werken.
Ook is het zo dat er veel aspect-georienteerde extensies zijn die dit soort functionaliteit wil toevoegen aan Java. Maar dan hebben we het niet meer over de Java-taal.
Om ook even te reageren op 'scaffolds':
Het verschijnsel van een programma dat alvast een beginopzetje maakt van een applicatie, zoals met 'scaffolds' bestaat natuurlijk al heel lang. Ik denk ook niet dat een goed voorbeeld is van wat Ruby on Rails beter maakt. Wel moet ik zeggen dat het goed uitgewerkt is in dit geval.
Die is er al wel voor OSX. zij het dat het de developer preview 1 build 88 is.
Kijk maar op: http://developer.apple.com/java/
Het klopt dat het nog geen stabel release is, maar die zal ongetwijfeld snel komen.
Kijk maar op: http://developer.apple.com/java/
Het klopt dat het nog geen stabel release is, maar die zal ongetwijfeld snel komen.
Op dit item kan niet meer gereageerd worden.
Onderwerpen
Populair: Samsung Websites en communities Mobiele telefoons Laptops Sony Games Microsoft Politiek en recht Consoles Microsoft Xbox One
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
