Hieruit komt ook vaak de frustratie:
Hardware die bepaalde versies Java vereisen zoals Cisco PIX (niet asa), HP KVM consoles of Brocade fiber switches. Allemaal tevens niet vooruit te branden. Als ze al niet vastslaan. Soms moet eerst de default JRE veranderd worden als je een apparaat benaderd. Je merkt het snel genoeg want je browser zal waarschijnlijk vastslaan.
Dit kan je moeilijk Java aanrekenen, Java kan zelfs vlot draaien op een mobiele telefoon. Het feit dat de GUI van een Cisco PIX enkel werkt met een bepaalde versie van de JRE zegt meer over Cisco dan de JRE. Alle Java applicaties
zijn in basis foreward compatible met nieuwe JRE's. Tenzij je restricted API's gebruikt (Wat ook een fatal error is voor de compiler die je met een speciale flag moet overriden), dan breekt de boel inderdaad.
Waarom is niet eens goed centraal te managen (GPO?). Het is toch een zakelijk framework?
Hier kan ik niet over oordelen. Zelf distribueer ik de JRE enkel naar Linux clients via SpaceWalk en daar heb ik nog nooit problemen mee gehad.
Waarom is uTorrent trouwens zo populair tov azureus? omdat als men keuze heeft tussen een native app en een java app iedereen voor een native app gaat.
Wat je kennelijk niet weet is dat Azureus (bijv voor Windows) als AOT compiled applicatie gestribueerd word. Azureus is dus native, er draait geen JRE
als je Azureus start, kijk maar in je procesmanager. Er is ook geen Java Swing interface, enkel native widgets dmv SWT.
En waar baseer je op dat de populariteit van uTorrent aan Java ligt (Los van het feit dat dat dus moeilijk gaat omdat het AOT gecompiled is) ? "Correlation does not imply causation" ik denk dat hier je eigen mening iets te
makkelijk projecteerd op de gehele internet gemeentschap.
Java vreet veel geheugen
Dat onderbouw je niet echt heel sterk. Daarnaast is het zo dat JIT gecompilde applicaties over het algemeen MEER CPU zullen gebruiken en MINDER geheugen ten opzichte van AOT gecompilde applicaties. Aangezien
ze alles on the fly compilen in tegenstelling tot AOT gecompilde applicaties waarbij alles al gecompiled is maar wel weer in het geheugen geladen moet worden.
Ik krijg meer het idee dat je dit artikel even snel gegoogled hebt. Dit artikel komt uit 2005. Verder schrijft de auteur stukken als:
What Java needs is, at least, a way to import a class and define an alias. Something like:
import com.acme.something.Rectangle as RectangleShape;
Aliases voor imports ? Dat zou code practisch onleesbaar maken.
Of een ander quote:
5. No multiple inheritance
Ook Microsoft toen ze de keuze hadden toen ze C# maakte implementeerde geen multiple inheritance in de taal. Ik denk niet dat ik verder in hoef te gaan op multiple inheritance...
Het zeker een interessant stuk om te lezen, maar meer ook niet. Ik zou niet te klakkeloos aannemen wat deze auteur allemaal zegt.
maar als het merendeel van de applicaties slecht draait is dat naar mijn mening ook de schuld van het framework.
Wat stel je voor ? Eerst een bekwaamheids test voordat je de JDK mag downloaden ? Of een Apple model, totale controle over de appstore en verder niemand ?
Een taal kan niet afdwingen dat je een goede applicatie schrijft. Iedere API kan je misbruiken/per ongeluk slopen, hoe goed hij ook in elkaar zit.
En als je geen verstand hebt van de API die je gebruikt dan is de kans groot dat je applicatie ook slecht word. Dat is zo in Java, C#, C++, C, ASP, PHP, Perl, Python, Bash of noem maar op.
Ik krijg sterk het idee dat je gefrustreerd bent over de Java applicaties die je hebt moeten gebruiken van bijvoorbeeld Cisco en dat je dit projecteert op de taal in plaats van een degene die de applicatie gemaakt heeft.
[Reactie gewijzigd door JUDGExKTF op woensdag 27 januari 2010 01:17]
![[RSS]](http://tweakimg.net/g/if/v2/icons/rss_small.png){kind=icon}
![[quick]](http://tweakimg.net/g/if/icons/world_link_cropped.png){kind=icon}
09:37
09:36
Door 
