[Java] 10 reasons why we need Java3

[TaXaN]

Om het niveau wat op te krikken

http://www.onjava.com/pub/a/onjava/2002/07/31/java3.html

Zelf kan ik mij wel vinden in een aantal van zijn punten (verwijderen van deprecated methodes, correcte naamgeving, AWT) maar van andere punten kan ik mij geen idee vormen wegens gebrek aan ervaring.

Kunnen de Java-goeroes hier wat commentaar bij geven?

[Verwijderd]

Nou, dit levert geen 'hoger' niveau op hoor, want die tekst is echt belabberd. Wel vermakelijk is een aantal reacties op slashdot op dit artikel

http://developers.slashdo...49227&mode=thread&tid=108

Een van de leukste imho (en uiteraard naar -1 troll gemod):
'we already have java3, it's called C# and .NET'

[Verwijderd]

Ook een lange draad als reactie hierop op Javalobby

[windancer]

Ik heb nog wel een wens : Complexe getallen "primitive" toevoegen zodat je de gewone rekenoperaties hierop kunt toepassen.

[Soultaker]

windancer schreef op 09 augustus 2002 @ 22:04:
Ik heb nog wel een wens : Complexe getallen "primitive" toevoegen zodat je de gewone rekenoperaties hierop kunt toepassen.

Dan zou ik liever operator overloading toevoegen, zodat je tenminste op een nette manier elk gewenst soort getal (of ander 'ding') kunt maken. Het is natuurlijk een beetje jammer dat door Sun ontworpen objecten/klassen (zoals de string klasse) 'geprivilegeerd' zijn ten opzichte van door 'gebruikers' ontworpen klassen.

[Glimi]

windancer schreef op 09 augustus 2002 @ 22:04:
Ik heb nog wel een wens : Complexe getallen "primitive" toevoegen zodat je de gewone rekenoperaties hierop kunt toepassen.

Een van de voorstellen van deze site is JUIST om dit onderscheid te laten vervallen en primitieven (a la smalltalk) als volwaardig object te gaan bekijken en ook zo te behandelen.

Het lijkt me dan ook dat de gewone rekenkundige bewerkingen dan ook omgebogen worden naar een bewerking op java.lang.Number met misschien een overloading op + - / * ed. voor 'de gewenning'

Ik heb eigenlijk geen idee of dat erg veel performance gaat kosten. Dat hangt natuurlijk samen met hoe groot het object voor een getal gaat worden maar natuurlijk telt ook de initiele "overhead" van een object mee. Verder zou de compiler intern natuurlijk kunnen 'vertalen' naar primitieven om zo de boel dmv een hack toch 100% met Objecten te kunnen werken

Kan iemand hier iets zinnigs over zeggen?

Soultaker schreef op 09 augustus 2002 @ 22:09:
Dan zou ik liever operator overloading toevoegen, zodat je tenminste op een nette manier elk gewenst soort getal (of ander 'ding') kunt maken. Het is natuurlijk een beetje jammer dat door Sun ontworpen objecten/klassen (zoals de string klasse) 'geprivilegeerd' zijn ten opzichte van door 'gebruikers' ontworpen klassen.

Iehw, liever niet. Natuurlijk is het niet 100% correct dat sun bijv de string class 'belangrijker' vindt dan een standaard class van u, maar om dan gelijk overal operator overloading toe te staan. Dit is denk ik gedaan om mensen niet in een keer helemaal in een schok te laten belanden, als opeens + niet meer werkt op een string.

Ik vind het altijd maar raar als ik opeens een rekenkundige functie overloaded is met ( ) waarmee je kunt evaluaten.
Ik ben dan eigenlijk altijd gelijk kwijt wat er gaat gebeuren. WTF is ( ) ?Wordt het object geconstureerd (C++ context) of wordt er een functie aan geroepen? Duidelijker vind ik altijd f.compute( 6 ) ipv f( 6 );

[Soultaker]

Het artikel gelezend hebbende, moet ik zeggen dat ik het een erg geslaagde analyse vind. Het enige punt waar ik zo mijn twijfels over heb, is of Swing beter is dan AWT (en of er niet nog een beter alternatief, gebaseerd op native widgets, zou zijn), maar ik ben het er in ieder geval mee eens dat twee GUI API's er een teveel is.

[Expander]

Soultaker schreef op 09 augustus 2002 @ 22:15:
Het artikel gelezend hebbende, moet ik zeggen dat ik het een erg geslaagde analyse vind. Het enige punt waar ik zo mijn twijfels over heb, is of Swing beter is dan AWT (en of er niet nog een beter alternatief, gebaseerd op native widgets, zou zijn), maar ik ben het er in ieder geval mee eens dat twee GUI API's er een teveel is.

Naar mijn weten was AWT er alleen nog voor comptabiliteit. Het viel dus te verwachten dat deze gedropped zou worden.

Ik vind het verder goed dat de depreciated stuff wordt gedropped. Dit bevordert goede structuur in programmatuur. Het maakt echter wel de 'overstap' groter voor mensen die nog (eigenwijs) 'ouderwets Java' progten.

[ Voor 0% gewijzigd door Expander op 09-08-2002 22:29 . Reden: toevoeging alinea ]

[Glimi]

Expander schreef op 09 augustus 2002 @ 22:26:
Naar mijn weten was AWT er alleen nog voor comptabiliteit. Het viel dus te verwachten dat deze gedropped zou worden.

Dit zijn niet de officele specs voor Java 3 hoor Dan gaat SUN zich echt te buiten en jagen ze ook een hoop mensen (qua compatabiliteit) flink in het harnas!

[Expander]

Glimi schreef op 09 augustus 2002 @ 22:29:
[...]
Dit zijn niet de officele specs voor Java 3 hoor Dan gaat SUN zich echt te buiten en jagen ze ook een hoop mensen (qua compatabiliteit) flink in het harnas!

Ik moest je post zelfs nog een paar keer overlezen. Had het niet helemaal begrepen.

Maar dan nog is inderdaad twee widget sets niet bevorderend, een Swing component in een AWT component stoppen kan zelfs problemen geven.
Het consistent benoemen van methodes is ook iets dat hier en daar beter kan, al vind ik dat Java al best begrijpbare constructies heeft qua benaming..

[ Voor 0% gewijzigd door Expander op 09-08-2002 22:37 . Reden: toevoeging ]

[Alarmnummer]

Ik begin me ook steeds meer te ergeren aan het geklungel in java en het feit dat ze dus steeds voortborduren op oude code en je daardoor een lading ondoorzichtige code krijgt (zie swing bv en die idiote hierarchie). Ik denk dat java ook echt toe is aan een grote refactor beurt, want tenslotte schrijven mensen hun code niet in 1 keer goed. Sommige dingen die vormen zich nu eenmal naar verloop van tijd.

Ik vond java in het begin een erg mooie taal omdat ze helemaal nieuw begonnen zijn en geleerd hebben van voornamelijk c++. Maar nu begint java zelf dit soort trekken te vertonen, en het zou jammer zijn als java gaat worden wat het ooit juist niet was.

Ik ben verder ook voor nieuwe features, zoals multi dispath en multi methods, c# style properties, natuurlijk geparametriseerde types (trouwens dat is vanaf java 1.5 standaard), etc etc. Verder ben ik voor een de uitermate handige null optie van nice. vb:

?String s1;//kan null zijn
String s2;//kan niet null zijn.

Dit zijn allemaal dingen die nu al bestaan in sommige talen en zouden zonder problemen ingebouwd kunnen worden omdat al deze dingen goed beschreven zijn en verder geen onderzoek meer vragen.

Maar in de toekomst zul je weer nieuwe features krijgen, en zal je in de tussen tijd weer backward compatible api`s moeten maken waarin concessies gemaakt moeten worden omdat java gewoon door veel mensen gebruikt worden en waardoor het een traag iets gaat worden waarin nog weinig verandering valt te brengen.

Misschien zijn dan kleine talen zoals bv Nice een uitkomst. Nice is een taal die 99% java is, alleen heeft hele mooie nieuwe features. Nice die compileerd gewoon weg naar bytecode (class files) en kan op iedere normale vm draaien.

Bepaalde taalfeatures zoals de multidispatch (dus dus geen onderdeel zijn van de standaard vm) worden daarin gesimuleerd met een toegevoegd algoritme waar de programmeur verder niets mee te maken heeft.

Misschien zit de toekomst voor taalfeatures wel in dit soort kleine projecten. Ze kunnen gebruik maken van goed geteste systemen en de daarop ontwikkelde api`s en toch kunnen ze op deze manier allerlei superhandige features toevoegen, waaronder een aantal uit het lijstje van die 10 redenen.

Maarja, hier is het probleem van rotte api`s nog niet opgelost

[Soultaker]

Alarmnummer schreef op 10 augustus 2002 @ 00:36:
Misschien zijn dan kleine talen zoals bv Nice een uitkomst. Nice is een taal die 99% java is, alleen heeft hele mooie nieuwe features. Nice die compileerd gewoon weg naar bytecode (class files) en kan op iedere normale vm draaien.

Omg; een programmeertaal zonder casts! Geweldig! Tot dusver was je daarvoor aangewezen op functionele programmeertalen of C++, voor zover ik weet. (Zelfs C++ mist echter nog een aantal van de features die op de Nice website worden beschreven).

Het lijkt me helaas sterk dat Java de features die je beschrijft ooit allemaal gaat ondersteunen. Het lijkt mij in ieder geval niet logisch om met het ontwikkelen van een programmeertaal alle geavanceerde features van bestaande talen achterwege te laten om ze vervolgens met wat hackwerk weer toe te voegen. Sun heeft voor de Java koers een duidelijk gekeuze gemaakt en die gaf voorrang aan portabiliteit en eenvoud boven geavanceerde eigenschappen en compile-time safety.

Toch leuk dat er dan projecten als Nice blijven te zijn, die een betere taal proberen te definieren op een bestaand executieplatform; zo krijg je eigenlijk het beste van de twee aspecten.

[Alarmnummer]

Soultaker schreef op 10 augustus 2002 @ 01:42:
Toch leuk dat er dan projecten als Nice blijven te zijn, die een betere taal proberen te definieren op een bestaand executieplatform; zo krijg je eigenlijk het beste van de twee aspecten.

Precies. Java blijft een stabiel platform waar veel research op plaatst vind en die ook steeds verbeterd wordt. Tevens voorzien ze je van 90% van de benodigde api`s en voor de rest kan je werken met een taal die alle features heeft die je maar hebben wilt. Zo gauw Nice echt gebruikt kan worden, dan zal ik met uitzonderlijk veel plezier overstappen. (Overstappen is een groot woord, omdat het dus 99% java is).

ps: heb je al gezien hoe supergeil die null problemen zijn opgelost?
http://nice.sourceforge.net/safety.html (3.2)

[Verwijderd]

Iedere taal met generics en operator overloading kan zonder casts, of mis ik iets?

[Alarmnummer]

Nice heeft inderdaad generics gebruikt om de casts op te lossen.

Maar lees dat safety stuk maar eens door, daar staan echt hele leuke dingen in die je meteen in je eigen taal zou willen hebben, vooral die '?' oplossing voor de null problematiek.

[Gerco]

Betekent die ? oplossing in nice ook dat je deze code niet kan schrijven?

code:

?String somestring;

if(somestring != null) {
  somestring.doewat();
  somestring.doewatanders();
}

Ik kan me voorstellen dat de compiler dit nog wel slikt, maar dit?

code:

?String somestring;
method(somestring);

boolean method(String s) {
  if(s == null) return false;

  s.iets();
  s.ietsanders();
}

[Alarmnummer]

Gerco schreef op 10 augustus 2002 @ 14:08:
Betekent die ? oplossing in nice ook dat je deze code niet kan schrijven?

code:

?String somestring;

if(somestring != null) {
  somestring.doewat();
  somestring.doewatanders();
}

Dit kan je in Nice niet schrijven. Je moet bij nice een nullbaar (nieuw woord) type op een speciale manier aanspreken. voorbeeld.

int lengte = (somestring == null) ? -1: somestring.length();

Je kan het volgende bijvoorbeeld compile technisch niet voor elkaar krijgen:

int lengte = somestring.length();

De methode functie die is niet gedefinieerd voor een nullbare string, maar alleen voor een string. Daarom moet je dus die speciale constructie aanmaken waardoor je het als volgt kan zien:

int lengte = (somestring == null) ? {-1}: [somestring.length()];


In {..} is somestring van het type null, en in [..] is somestring van het type String. En pas in [..] kan je die methode length uitvoeren op somestring.

Die [] {} zijn hier alleen gebruikt om aan te geven dat je verschillende gebieden hebt, en hebben verder geen betekenis zoals je die bent gewent uit programmeer talen, maar ik kon gvd geen goeie spaties in mijn code tags krijgen!!!!!

Ik kan me voorstellen dat de compiler dit nog wel slikt, maar dit?

code:

?String somestring;
method(somestring);

boolean method(String s) {
  if(s == null) return false;

  s.iets();
  s.ietsanders();
}

Dit gaat wederom niet lukken. Het type van s in die method is een String (die onmogelijk null kan zijn in tegenstelling tot bv Java). Het type van somestring is een nullbaar string type (dit heet ook wel een variant type, omdat het of een null type is, of een String type). Het type van somestring is dus wijder dan het type van de methode, dus wordt bij het compilen al afgekeurd.

Nice heeft die null op een uitzonderlijk fraaie manier opgelost en je hoeft dus geen null checks meer te doen, omdat je een veel krachtiger typesysteem tot je beschikking hebt.

[Gerco]

OK, je zult dus als je een aantal operaties achter elkaar wilt doen op een ?String, bij iedere operatie moeten contoleren of die ?String geen NULL is? In het kort, zo:

code:

?String s;
?String s2;

s2 = (s == null) : null ? s.substr((s==null) : 0 ? s.length() - 3, (s == null) : 0 ? s.length());
if (s2 != null) s2.toLowerCase();

Ook al weet je 100% zeker dat de 2e en derde check overbodig zijn omdat de eerste check die situatie al uitsluit? De andere 2 checks zijn compleet zinloos.

Nu is dit wel een geweldig incentive om dan maar geen ?Strings te gebruiken

[Alarmnummer]

Nee, je hoeft het maar 1 malig te doen denk ik (ik ben er verder nog niet in thuis, maar theoretisch zou het zo moeten werken). Op het moment dat je die keuze hebt gemaakt (null of echt object) dan ben je ook klaar.

dus in jouw geval:
s2 = (s == null) : null ? s.substr(s.length() - 3, s.length());

[Gerco]

Op zich maakt het mij niet veel uit eigenlijk, ik gebruik zelden tot nooit 'null' waardes in dingen die ik zelf schrijf. De enige nulls die ik zie zijn diegenen die ik uit de api teruggesmeten krijg.

[Alarmnummer]

aarrghh... reply weg!! fuck internet explorer

ok, ontopic.

Het gaat er niet zozeer om of jij ze wel of niet gebruikt, maar het gaat erom dat je kan garanderen dat er nu niets meer misgaat ipv zelf te moeten checken. Je krijgt nu vantuit de taal ondersteuning met een veel krachtiger typesysteem. Op dit moment moet ik dus nog alles controleren (vooral publieke methodes zijn irritant omdat je dus alle argumenten moet controleren op null waardes) en daar ben je in 99% van de gevallen niet in geinteresseerd. Ik vind de nice aanpak dus zeer nice en zal met veel plezier hiermee gaan werken.

Daarnaast bezit nice dus ook nog hele handige dingen zoals multdispatch. Dit kan supereenvoudig in java ingebouwd worden (er zijn een aantal onderzoeken geweest om het in te bouwen en het stelt echt niet zo veel voor). En verder oa ook generics. Ik ben op dit moment ook met generics bezig met java en kan niets anders zeggen dan dat het fantastisch werkt. Als je het eenmaal hebt gebruikt dan wil je niet zonder meer

Maar java is nu eenmaal een log en groot beest, waar weinig taaltechnische veranderingen in aan te brengen zijn (kijk maar hoe lang het duurt voordat generics pas in java standaard te krijgen zijn). Met nice krijg je dus het beste van 2 werelden. Veel api`s en veel handige taalfeatures.

[Gerco]

Daar kan ik het mee eens zijn. Nice is heel nice...

Generics zien er best wel roelerend uit en het idee om nooit meer te hoeven casten spreekt mij zeer aan _{understatement of the year}.

Ook het hele null-values idee vind ik mooi opgelost, ik maak me alleen zorgen wanneer je weleens WEL null-values wilt gebruiken, ik geloof dat je dan in een behoorlijke syntactische bagger terecht komt.

Multidispatch heb ik iets over gelezen op de nice website en het klinkt prachtig, al weet ik nog niet helemaal hoe ik het zou moeten gebruiken, maar ik ga het zeker wel eens proberen.

[CyberSnooP]

De conclusie van het artikel:

We can argue about exactly which changes are necessary, and which ones may cause more harm than good. But one thing's for sure: if Java fails to change, if it refuses to correct its well-known problems, there are other languages waiting in the wings written by some very sharp programmers who have learned from Java's mistakes and are eager for the opportunity to replace Java in the same way Java replaced earlier flawed languages. Java must not be forever handicapped by mistakes made seven years ago in Java 1.0. There comes a point where we need to throw off the chains of backwards compatibility and move boldly into the future.

Er valt (zoals op Slashdot te zien is) wel het e.e.a. aan te merken op zijn voorgestelde wijzigingen, maar ik deel zijn mening dat (met behoud en gedeeltelijke ondersteuning van huidige versies) het voor de toekomst van Java belangrijk is dit soort grote stappen te nemen.

Ik betwijfel namelijk zeer of het gewenst is dat er weer verschillende nieuwe programmeertalen gaan opduiken die allemaal beweren cross-platform te zijn en de modernste taal-constructies toestaan. Vooral als die talen ook hun eigen VM en daarmee hun eigen (security-)bugs meebrengen.

Kortom: De ict-wereld is gebaat bij een moderne en up-to-date taal als Java zou kunnen blijven mits er af en toe wat grote stappen genomen kunnen worden.