Sun gaat programmeren in Java makkelijker maken

Volgende maand zal in San Francisco de JavaOne conferentie plaatsvinden. Tijdens deze conferentie zal Sun informatie geven over hoe het bedrijf het programmeren in Java gemakkelijker wil gaan maken. De afgelopen jaren is de concurrentie op programmeertaalgebied erg veel groter geworden en Sun wil daar nu iets tegen gaan doen. Zo zal het bedrijf een speciaal ontwikkeltool presenteren dat qua uiterlijk veel lijkt op Visual Basic. Uit onderzoek is gebleken dat 43 procent van de Visual Basic-programmeurs erover denkt om met een andere taal te gaan werken. Sun wil hen met dit programma over de streep trekken om met Java bezig te gaan. Ook zal Sun tijdens deze conferentie een aantal veranderingen aan de Java-specificatie bekendmaken om het ontwikkelen eenvoudiger te maken. Aan het einde van dit jaar zullen opnieuw veranderingen in de specificatie volgen:

In tandem with tool enhancements, Sun's Green said that over the next six to 12 months, Sun and other Java companies will be adding improvements to the Java specifications that will speed up development.

The planned features for Java 2 Standard Edition (J2SE), for example, are focused on ease of development, better performance and Web services. This update to the Java specification, code-named Tiger, is set for release some time this year.

Reacties (36)

[BezurK]

Mijn insziens een verstandige zet. Het is al lang bewezen dat Java enorme mogelijkheden biedt, en de meeste programmeurs zijn er dan ook erg over te spreken. Probleem is de 'starters' die ze hiermee toch kunnen bereiken

In zekere zin is dit dus een directe concurrentie voor MS Visual C#

[Mick]

In zekere zin is dit dus een directe concurrentie voor MS Visual C#

Aan de andere kant: Microsoft heeft IMHO wat dat betreft een voordeel, want MS kan makkelijker regelen dat die doelgroep van VB-programmeurs bestaande VB code in C# kunnen gebruiken (door het te includen, of VB naar C# te vertalen), dan het voor Sun is om de opname van VB code in J2SE mogelijk te maken.

Dat zou wel eens doorslaggevend kunnen zijn bij bestaande/lopende projecten - die anders deels of compleet herschreven zouden moeten worden.

Ik ben benieuwd naar het toekomstige Tweakers berichtje waarin staat beschreven hoe Microsoft hier precies kwa VB/C# strategie op gaat reageren..

[Verwijderd]

Het grootste probleem van Java is denk ik niet het gemak, maar de snelheid.

Qua gemak is het voor de gemiddelde C++ programmeur (wat de doelgroep is) allemaal heel goed te doen, maar de snelheid van een Java-applicatie valt vrijwel altijd tegen.

Maar desalniettemin is zo'n VB-look-a-like wel grappig natuurlijk

[Aaargh!]

Het grootste probleem van Java is denk ik niet het gemak, maar de snelheid.

Voor heel veel toepassingen is de snelheid van Java prima.

Ik heb me bezig gehouden met zowel losse java programma's als servlets, portlets en agents (voor domino) in Java en ben nooit echt tegen performance problemen aangelopen. Op m'n stage gebruik ik dagelijks een aantal forse Java applicaties tegelijkertijd (WAS, WSAD en WPS) en dat draait (als 't eenmaal allemaal opgestart is, want het zijn grote apps) zonder veel performance problemen.

[MisterData]

Juist omdat het een VM is, is er nog een hoop te optimaliseren. Sinds JIT (Just In Time) compiling is er een wereld opengegaan voor java-apps, die ineens een stuk sneller werden. Het mooie van een VM is dat als er een nieuwe CPU komt (denk aan de Itanium, en de Opteron), met speciale instructiesets, die VM wel eens een hoop performance kan opleveren, zonder recompile (en bij C++ zul je dan minimaal moeten hercompileren en eventueel nog handmatig assembly moeten schrijven). Verder is de VM in staat om vooruit te kijken in het programma, te voorspellen wat er gaat gebeuren, waardoor instructies op elkaar kunnen worden afgestemd en dus sneller draaien. Bij C++ gebeurt dit compile-time, bij Java run-time en dat kan een hoop schelen.

Nu nog een snelle VM, maar dat is mijnsinziens slechts een kwestie van tijd

[Jit]

En met een JIT in de VM ben je na de opstart fase qua performance (bijna) op gelijk nivo met C++.

Bovendien moet je je niet altijd blindstaren op performance eisen. Voor veel toepassingen is de snelheid van geinterpreteerde talen als java, perl en python goed genoeg.
Wat veel meer van belang kan zijn is het onderhoud van de code en het gemak van ontwikkelen. Deze twee zijn nou niet bepaald gunstig voor c/c++ in vergelijking met Java of python.

Wat die GUI-betreft heb je gelijk. Die is op de meeste platformen net niet conform dat platform, maar boeit dat? Er is veel meer dan alleen GUI-apps. En anders gebruik je een gui-toolkit die beter aansluit bij je target plaform(en).
En ook in dit geval, voor de meeste doeleinden maakt die kleine afwijking niet veel uit.
Met c/c++ heb je dat probleem overigens ook, tenzij je voor elk platform waar je op wilt draaien de interface in de native toolkit implementeert. Maintenance-nightmare als dat meer dan 1 platform is.

[Verwijderd]

het is en blijft op een VM draaien.. en ik zie 't nut voor een multiplatform app in 99 van de 100 gevallen ECHT niet.. als je ansi C(++) code kun je 't ook op alle OS'en compilen.. maar dan is 't wel 3x zo snel als java..

laat ze de VB mensen met rust laten en de C# mensen proberen over te halen of zo

[edit:]sterker nog, het gebruik van Java maakt je app alleen nog maar lelijker vind ik, omdat de GUI componenten nooit aansluiten bij wat standaard is in je OS (in windows in ieder geval).. en das gewoon echt heel vies.. java apps herken je altijd aan de lelijke GUI's.. dat is niet voor nix.

[Verwijderd]

sterker nog, het gebruik van Java maakt je app alleen nog maar lelijker vind ik, omdat de GUI componenten nooit aansluiten bij wat standaard is in je OS (in windows in ieder geval).. en das gewoon echt heel vies.. java apps herken je altijd aan de lelijke GUI's.. dat is niet voor nix

Als je in Java een mooie GUI wilt hebben dan kan je natuurlijk altijd gebruik gaan maken van Swing. Maar de applicaties die ik tot nu toe heb gebouwd met Java vond ik er mooi uit zien. De kleuren en andere visuele instellingen van het OS werden gewoon meegenomen. Met OS X ziet het er helemaal geweldig uit.

Maar van Sun vind ik het een goeie stap dat ze iets gaan doen om gemakkelijker te kunnen proggen met Java. Dat scheelt een hoop werk voor je GUI. Alleen moeten ze dan wel opletten dat er geen baggercode wordt gegenereerd als je de tools gaat gebruiken voor het bouwen van een GUI. Want daar zit niemand op te wachten denk ik zo.

Wel ben ik het met de meeste eens dat het wel wat sneller mag allemaal. Maar ja, het punt zit bij de VM . Maar Java is en blijft een mooi taaltje!

[Confusion]

De vermeende traagheid van Java is een urban legend. Java is in 99% van de gevallen niet relevant trager dan C of C++.

[Verwijderd]

Het is toch een wereldje waar we naar toe gaan.
Zelfs microsoft heeft nu een VM in de vorm van hun CLI draaien. maw. alles wat je strakjes met de visual studio .NET gaat zitten hakken wordt netjes op basis van een VM geinterperteerd.

Natuurlijk heeft het voor een gemiddelde desktop omgeving absoluut geen nut om cross platform ontwikkelingen te doen. Maar voor bedrijven die steeds meer ontwikkelingen doen op basis van een ASP model heeft het steeds meer voordelen om de hardware te consolideren.
plat gezegd zodra fabrikant A het ijzer goedkoper aanbiedt wordt dat aangeschaft en een half jaar later gaan ze voor fabrikant B. In dat opzicht heeft Java een gouden troef in handen.

[gluip]

......................

mmmh ik ontwikkel en debug wel code op ms omgevingen. Terwijl de productie op unix systemen draait Dus cross platform is wel degelijk van belang

[PageFault]

Helemaal mee eens. De enige fatsoenlijke tool, die er nu is, is Forthe (Visual Cafe en JBuilder zijn niet echt snel en prettig in omgang). Er zit ook meteen CVS integratie in.

Die snelheid van Java geloof ik niet meer in. Allerlei Java aanhangers komen met papers met tests over dat bepaalde JIT compilers (bijna) even snel zijn als C++, maar dan zullen ze misschien het compileerproces bedoelen... Het blijft gewoon een ramp.

[TheOneLLama]

Suns eigen Sun One is ook wel redelijk, en de beste IDE is natuurlijk Eclipse. Ik denk niet dat er heel veel betere bestaan (voor elke taal), wat de allerbeste is, is natuurlijk een kwestie van smaak.

[johanvdw]

C# is niet sneller dan java, en dat is de concurrent waarop Sun doelt.

[intGod]

Dit is geen goede zet van Sun. Een interface 'die lijkt op' is zeer frustrerend als hij inderdaad enkel 'lijkt op'. Ik denk dan aan een speelgoed mobiel en een echte mobiel. De irritante belmelodietjes zijn het zelfde. Voor de rest doet het display andere zaken, zijn de functies verschillend en is de user-interface (druktoetsen) volledig verschillend.

Ik ben momenteel verplicht om te werken in Magic Software met een engine die er 'ongeveer' Windows achtig uitziet. Echter is ctrl-c gemapt aan een controle-venster, opent ctrl-z een dos window en opent ctrl-x een cross-reference dialoog. Het toevoegen van lijnen in een lijst gebeurt onder de cursor terwijl ik van excel bv gewoon ben dat invoegen OP de cursor gebeurt. Knoppen, focus en 'intuitieve' handelingen zijn volledig onderuit gehaald.

Als je dus een visual interface bouwt doe het dan goed en kijk hem niet af. Ik denk hierbij aan Macromedia die met success een interface in de markt hebben/heeft gezet die uniform is binnen hun produktlijn (flash, dreamweaver, ultradev, ...) en die na enige inwerking perfekt werkbaar is. Sun en zijn platformen kennende denk ik dat het voor die-hard VB programmeurs even slikken zal zijn om een x-windows interface aan te pakken.
Ik weet dat ik best lang met Ethereal en the Gimp heb lopen vechten omdat het een x-windows achtige interface heeft ipv een Windows interface. Uiteindelijk, moet ik toegeven, heb ik beide programma's gedumpt voor andere software.

Ik hoop dus dat Sun een echt gedegen interface bouwt, die ook laat testen door VB programmeurs (en niet door doorgewinterde Sparcstation fanatici) en dat ze misschien eindelijk eens zorgen dat Java in machines ingebakken wordt waardoor het een beetje sneller gaat draaien.

Edit: sorry voor het redundante 'snelheid' gedeelte Sommigen typen nog sneller dan ik. Maar dat bewijst wel dat er blijkbaar meer mensen last hebben van de snelheid en de complexiteit van een VM.

[Verwijderd]

Het is inderdaad zo dat Sun een beetje (erg) eigenwijs is als het gaat over user interfaces. Veel klachten over de snelheid en geheugengebruik van Java ontstaan door de Swing UI library van Sun. Voor server en embedded toepassingen is Java echter vrij succesvol.

De SWT library van IBM is echter een alternatieve user interface library, die wél gebruik maakt van elementen van het OS waarop het draait. Dat is een stuk sneller en efficiënter, en voelt veel beter aan dan de trage, niet door hardware versnelde en niet standaard componenten van Sun.

In dit artikel wordt ook gesuggereerd dat Tiger dit jaar al beschikbaar zou zijn. Bij mijn weten mogen we blij zijn als de eerste beta dit jaar uit is, maar de officiële Tiger zal nog even op zich laten wachten. Overigens worden sommige dingen in Tiger wel makkelijker, maar komen met die release ook veel nieuwe begrippen en constructies waardoor het er voor de VB programmeur, die niet eens Inheritance kent, echt niet makkelijker op wordt gemaakt...

Kortom: een leuk stukje propaganda van Sun, maar ik zie ze het nog niet waar maken...

[Little Penguin]

Ik hoop dus dat Sun een echt gedegen interface bouwt, die ook laat testen door VB programmeurs (en niet door doorgewinterde Sparcstation fanatici) en dat ze misschien eindelijk eens zorgen dat Java in machines ingebakken wordt waardoor het een beetje sneller gaat draaien.

Wat interface betreft heb je gelijk, maar waarom zou men het niet beter mogen doen. (Anders wordt al gauw gezien als slechter en dat is natuurlijk ook niet zo).

Over het inbouwen in machines, hoe had je dat willen zien? Tenslotte is het juist de kracht dat Java op alle machines draait, of zou je de mogelijkheid om bytecode uit te voeren in de processor willen bouwen?

Iets wat dan vergelijkbaar is met Jazelle van ARM http://www.arm.com/ die volgens mij al wel de mogelijkheid heeft om bytecode op hardware niveau te regelen.

[Ximinez]

Een IDE omgeving gaat niet uit de weg wat het grootste probleem is bij beginnende en al wat meer ervaren Java ontwikkelaars. Namelijk, gebrek aan kennis van object georienteerd ontwerpen en implementeren.
Object orientatie kent vele voordelen maar ook vele valkuilen. Gebrek aan OOD/OOP zijn kritische factoren in grotere Java projecten. Dan praat ik niet over Java in de context van JSP/Servlet.
Hoe goed de IDE de ontwikkelaar ook ondersteund het is geen mechanisme om zoals gezegd VB ontwikkelaars in de wereld die Java heet te laten opereren. VB is gewoonweg niet object georienteerd.
De grote voordelen van OO zie je helaas zelden terug door een verkeerd gekozen architectuur wegens gebrek aan grondige kennis. OO is ook niet eenvoudig en door een VB ontwikkelaar op deze manier op Java te zetten zie ik niet als een positieve ontwikkeling. Ik zeg daarmee niet dat VB ontwikkelaars daar niet toe in staat zouden zijn, ik zeg alleen er is veel meer voor nodig.
Het feit dat je Java kent wil nog lang niet zeggen dat je OO beheerst. Dus dat traject zou Sun zeker in de strategie moeten opnemen.

Java mist nog goede ondersteuning voor compositie, delegatie en component interfaces. Hoop dat daar verbetering in komt. Zoals bijvoorbeeld de taal E, gebaseerd op de JVM, welke delegatie op een zeer elegante wijze ondersteund.

[Verwijderd]

VB is gewoonweg niet object georienteerd.

Pardon? Wel eens gekeken naar Visual Basic.NET? Dat is volledig OO (en VB6 in beperktere mate ook).

Lees dit maar eens:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vs techart/html/vbtchooinvbnet.asp

[mxcreep]

t zou wel eens lekker zijn als er een goede IDE door sun gebouwd werd om in te ontwikkelen die niet in JAVA zelf gebouwd is...de huidige sun one studio gebruikt zo debiel veel geheugen als je em opstart.....Jbuilder doet dat trouwens ook....t zijn mooie tools maar ik vind ze persoonlijk wel erg veel geheugen gebruiken en de boel traag maken...
Ben geen MS fan, maar visual studio en nu dus ook de .NET variant zitten wat dat betreft toch beter in elkaar...

[Verwijderd]

De Sun One Studio is inderdaad een zeer langzame en logge ontwikkelomgeving, die nog niet eens lekker werkt ook. JBuilder is wel een fijne tool, maar is ook behoorlijk zwaar in de resources. IntelliJ van IDEA is een zeer goede ontwikkelomgeving voor "coders", maar het VB publiek zal dit misschien niet zo handig vinden.

Al deze IDE's zijn geschreven op de Swing user interface library, en dit is de voornaamste oorzaak van hun slechte response tijd en geheugengebruik. Ik heb hier echter de nieuwe Eclipse van IBM draaien, en die gebruikt ong. 30 mb kaal en +/- 10 mb meer als je een project open hebt. En dat is met een realtime incrementele compiler, realtime code checking/code completetion, uitgebreide refactoring mogelijkheden, hot code replace, en ga zo maar door. Eclipse kun je draaien op 233 mhz met 256 ram (heb ik echt Java op ontwikkelt!) en dat gaat prima. Maar Eclipse gebruikt dan ook niet de Swing library, maar een door IBM zelf ontwikkelde native GUI library genaamd SWT. En dat scheelt.

[SlasZ]

hetzelfde met Together: een java c++ c# vb ontwikkeltool geschreven in java, met zeer veel mogelijkheden (UML, Testing, ...) maar gebruikt enorm veel geheugen (200mb zonder dat er iets open is). Op een pc met 256mb ram moet je niet veel andere dingen doen terwijl Together openstaat.

Het wordt tijd dat Sun iets doet aan de snelheid van de GUI(s)

[gluip]

Over het algemeen vind men (ontwikkelaars/distributeurs) het mooi om een development omgeving uit te brengen die geprogrameerd is in dezelfde taal. Dit zou de kracht van de taal bewijzen. (ik ben er ook nog niet helemaal van overtuigd).
Deze trend is begonnen rond de eerste smalltalk-80 omgevingen. But correct me if I'm wrong

[mouse256]

Zo zal het bedrijf een speciaal ontwikkeltool presenteren dat qua uiterlijk veel lijkt op Visual Basic

ontwikkeltool is zo niet het probleem voor mij, wel de snelheid en de vereiste van eerst een virtual machine te installeren (daar schrik je de meeste mensen mee af)
Ook de goede decompile mogelijkheid zal commerciele projecten tegen houden.
Voor de rest vind ik java een goede taal, en het cross-platform zijn is heel handig

[Verwijderd]

VM draait op de meeste PC's al wel ... en anders doe je er een JRE bij.

Decompilen is geen goede reden: ten eerste kun je een obfuscator er over heen gooien .. en ten tweede schijnen er tools te zijn om een jar te encrypten (vraag mij niet hoe het werkt .. ik wil het namenlijk niet weten) ..

En dat cross-platform dat valt toch ook zwaar tegen sinds ze die nieuwe byte-code hebben geintroduceerd in 1.3 en dan komt IBM ook nog eens met allerlei eigen brouwsel.

[pjonk]

Voor beginnende ontwikkelaars is de IDE vaak het eerste wat ze te zien krijgen en een professionele IDE geeft natuurlijk wel een goede indruk.

Echter voor Java heb je bijvoorbeeld www.eclipse.org als gratis IDE beschikbaar wat al zeer veel mogelijkheden biedt.

Ook zal Sun tijdens deze conferentie een aantal veranderingen aan de Java-specificatie bekendmaken om het ontwikkelen eenvoudiger te maken. Aan het einde van dit jaar zullen opnieuw veranderingen in de specificatie volgen.

Hier ben ik wel benieuwd na. De taal is toe aan vernieuwing om de concurrentie met .NET van MS aan te kunnen.

[Jefrey Lijffijt]

Eclipse is inderdaad een gigantisch mooie IDE, met volledige ant en cvs integratie, heerlijk om te gebruiken, ik werk er op dit moment zelf in. Daarnaast is hij beschikbaar voor bijna alle OS'en zodat niet alleen de geschreven software, maar ook het bouwen ervan platform-onafhankelijk is.

Overigens is wat er gaat veranderen in SDK 1.5 al een tijdje bekend. Kan de officiële link ff niet vinden maar als je interesse hebt is op google zat te vinden.

[Aaargh!]

Zo'n RAD tool als VB die nogal zwaar leunt op z'n GUI builder lijkt me niet echt een goed plan.
Het probleem is dat mensen een GUI gaan 'tekenen' en er dan code omheen gaan prutsen. Dat kan natuurlijk nooit de bedoeling zijn.

[Verwijderd]

Zo zal het bedrijf een speciaal ontwikkeltool presenteren dat qua uiterlijk veel lijkt op Visual Basic

Lijkt me geen slecht idee. Ik heb laatste tijd veel met Java zitten werken (vooral GUI's maken) en zo'n ontwikkeltool kan een hoop werk besparen. Als je ziet hoe lang je bezig bent om wat knoppen, tekst etc. fatsoenlijk op het scherm te krijgen...

[gluip]

Java.........

wat ik hier nog mis is:
a) java programmas zijn absoluut niet platform onafhankelijk
b) je hoeft alleen maar java kennis te hebben om een goede applicatie te schrijven .


Ik heb jaren lang in die taal geprogrameerd en doe het af en toe nog steeds. Vaker wordt ik nu ingehuurd om problemen met java applicaties op te lossen. De java source code is platform onafhankelijk(dat geldt meestal ook voor ansi c, ect) maar de werking van die code in de specefieke paltform gerelateerde VM is echt anders. Een correcte app in linux/w32 kan een leak in unix systemen hebben. De crux zit in hoe de stack en heap per platform worden opgebouwd.
Daarnaast onstaan er ongelovelijk veel memory leaks omdat de programmeurs geen enkel idee hebben hoe de machine intern werkt. In C/C-++ werd je hier genadeloos voor afgestraft. In java kom je er niet super snel achter. Maar een leak van 1KB per uur kom je regelmatig tegen. En die leaks komen meestal wel door de stress testen heen. Ik heb nog nooit van een stress test van 4 weken gehoord. Meestal was het na 3 dagen wel genoeg.
Wil je goed java kunnen programeren dan zul je echt het principe van pointers en geheugen allokering moeten snappen en daarnaast de zwakke classes in java moeten weten (meeste java.util.*) En hoe de garbage collector per jdk werkt

Verder over performance. Java code is 17x trager dan platform optimize C. Native java is maar 2.3 trager. Dus alles naar native compileren ??? Kan, maar ik doe het niet. 17 keer klinkt veel maar als je er reeel naar kijkt is het niet zo gek veel. En we hebben hier dan naar een een puur platform ge-optimaliseerde taal. Door het naar native te compileren verlies je ook een hoop mogelijkheden om de appl te monitoren gedurende runtime. Kortom gewoon in de vm draaien.

Als Sun het programeren in java nog makelijker gaat maken (minder kennis van het systeem), betekend dat meer business voor mij. Dus goed nieuws

[Verwijderd]

Sun heeft intern toch wel een aantal problemen met het gebruik van Java:

http://www.internalmemo.com/memos/memodetails.php?memo_id=1321

4. It is not backward-compatible across minor releases.

Among the various incompatibilities across minor releases are:
a) In JDK 1.1 Class.fields() returns only public variables. In 1.2, protected and private variables are returned.
b) Swing table sizing calculation changed from Java 1.3 to 1.4.
c) Swing JFrame launch behavior changed significantly from Java 1.2.2 to Java 1.3.1.