Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 13 reacties, 5.201 views •
Bron: Sun, submitter: ESTANNY

Sun heeft voor zowel de developmentkit als de runtime-environment van Java Standard Edition 6.0 de achttiende update uitgebracht, waarbij het exacte versienummer op 1.6.0_18-b07 is komen te liggen. De ontwikkelaars hebben nieuwe versies van verschillende onderdelen meegeleverd en een lijst met bugs afgewerkt. De lijst met veranderingen voor deze achttiende update ziet er als volgt uit:

Changes in 1.6.0_18 (6u18)

The full internal version number for this update release is 1.6.0_18-b07 (where "b" means "build"). The external version number is 6u18.

OlsonData 2009s
6u18 contains Olson time zone data version 2009s. For more information, refer to Timezone Data Versions in the JRE Software.

Security Baseline
6u18 specifies the following security baselines for use with Java Plug-in technology:

JRE Family Version 5.0
Java SE Security Baseline 1.5.0_22
Java for Business Security Baseline 1.5.0_22

JRE Family Version 1.4.2
Java SE Security Baseline 1.4.2_19
Java for Business Security Baseline 1.4.2_24

On October 30, 2008, Java SE 1.4.2 reached its end of service life with the release of 1.4.2_19. Future revisions of Java SE 1.4.2 (1.4.2_20 and above) include the Access Only option and are available to Java for Business subscribers. For more information about the security baseline, see Deploying Java Applets With Family JRE Versions in Java Plug-in for Internet Explorer.

Additional Supported System Configurations
For 6u18, support has been added for the following system configurations:
  • Ubuntu 8.04 LTS Desktop Edition for both JFB and Java SE (x86) in 32-bit
  • SLES 11
  • Windows 7 support is now available
  • Red Hat Enterprise Linux 5.3
VisualVM 1.2
VisualVM 1.2 is included in 1.6.0_18. VisualVM 1.2 introduces the following features and enhancements:
  • Sampling CPU and Memory profiler plugin (VisualVM-Sampler available on Plugins Center)
  • Support for multiple jstatd connections on a single local/remote host
  • New charts with dynamic tooltips, public Charts API for plugins
  • Monitor and Threads tab are saved into Application Snapshot
  • Application Snapshots can be opened using the Load action or --openfile parameter
  • Properties UI for Applications, Hosts and Snapshots, public Properties API for plugins
  • Customizable proxy settings in Options dialog
  • UI for customizing SSL certificates in Options dialog (VisualVM-Security available on Plugins Center)
  • Enhanced JMX API to enable customizing JMX environment/connections by plugins
  • Display name defined by the monitored application: visualvm.display.name property
  • Improved performance for remote X sessions
  • Automatic detection of broken jvmstat on Windows (username capitalization vs. hsperfdata file)
  • Various UI improvements: main menu, toolbar and context menu; system (theme) colors; About dialog, profiler snapshots, HeapWalker
Java DB
Java DB 10.5.3.0 is included in 1.6.0_18. Java DB 10.5.3.0 introduces the following improvements:
  • SQL Roles
  • Generated Columns
  • LOB Improvements
  • Replication of encrypted databases
  • OFFSET/FETCH FIRST syntax
  • In-memory back end
  • Better updating of optimizer statistics
  • Service-tag aware installers
Note that Java DB is distributed with the JDK and not JRE. Java DB 10.2 and Java DB 10.3 have reached EOL.

Performance Improvements

6u18 introduces improvements in the following areas:
  • Faster jar File Creation
    The fix of a long standing bug related to jar file creation has greatly improved creation time. For example, for a given jar file, it is possible that you might see a creation time improvement in the range of 20 percent. (Refer to 6496274.)
  • Java Hotspot VM 16.0
    6u18 includes version 16.0 of the Java HotSpot Virtual Machine. Contributing to increased performance in this release are several enhancements in Java HotSpot VM 16.0.
  • Application Startup Improvements
    • Better startup of applications and applets on systems where D3D is used. Savings are up to 100-200ms depending on application and the system. (Refer to 6891435.)
    • Revised support for pre-verification of FX runtime. Improves warm start of typical FX applications by up to 15 percent. (Refer to 6894899.)
    • Concurrent download of jars for webstart applications and applets.
    • Number of other startup improvements for UI applications and applets. (Refer to 6753173, 6896857, 6892138, 6868503, 6874881, 6874336, 6891293 and 6895250.)
  • Runtime Performance Improvements for UI Applications
    • Improved performance of applications using translucent windows. (Refer to 6794764.)
    • Better performance and smaller memory consumption by text rasterizer. (Refer to 6891557 and 6891551.)
    • Faster processing of PNG images. (Refer to 6549882.)
  • Ability to Read Larger .zip Files
    As of this update release, it is possible to read .zip files of sizes up to 4 gigabytes. (Refer to 6860950.)
Deployment Updates
Java Web Start now implements JSR-056 version 6.0.18.

JSR-173 StAX 1.2 API Upgrade
6u18 includes an upgrade to minor revision 1.2 of JSR-173 Streaming API for XML (StAX) which was a result of Maintenance Reviews 2 and 3. You can find more details about these Maintenance Reviews in the JSR 173 Change Log. Also refer to 6861589. The StAX 1.2 upgrade maintains binary and source compatibility. Existing binaries compiled on StAX 1.0 will continue to run on StAX 1.2. Programs written to StAX 1.0 will continue to compile to StAX 1.2. There will be a minor behavioral difference if deprecated methods are used. In this case, there will be deprecation warnings at compilation. Other than these warning messages, the StAX 1.2 upgrade maintains behavioral compatibility.

Bug Fixes
This feature release does not contain any new fixes for security vulnerabilities to its previous release, Java SE 6 Update 17. Users who have Java SE 6 Update 17 have the latest security fixes and do not need to upgrade to this release to be current on security fixes.
Versienummer:6.0 update 18
Releasestatus:Final
Besturingssystemen:Linux AMD64, Linux x86, Linux, Solaris, Windows Server 2008, Windows Vista x64, Windows Vista, Windows Server 2003 x64, Windows XP x64, Windows Server 2003, Windows XP, Windows 2000, Windows 7 x64, Windows 7
Website:Sun
Download:http://java.sun.com/javase/downloads/index.jsp
Licentietype:Voorwaarden (GNU/BSD/etc.)

Reacties (13)

Jammer dat nog steeds veel devvers Java als basis gebruiken. Het is zeer traag en log (groot). Mijn java directory was na alle updates een dikke GB groot. Ik heb het uit principe al niet meer op men pc geïnstalleerd staan.

/Edit
Uiteraard wil ik het even onderbouwen. Allereerst wist ik niet dat de nieuwe versies de oudere automatisch opruimden. Ik kom zelf "in het veld" echter voornamelijk applicaties tegen die alleen met versie 1.6 (of andere oudere versies) werken. 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.

Internet Explorer en Java is ook een waar drama. Ik werk veel met terminal servers en als ik zie hoeveel crashes JRE wel niet heeft veroorzaakt.... Vaak in combinatie met Jinitiator. Dit heb ik geconstateerd vanwege verschillende traagheid problemen binnen een Citrix terminal server omgeving te hebben onderzocht. Het blijkt de grootste resource hog te zijn op de meeste terminal servers.

Updates: Java framework ziet het verschil niet tussen een persoon met admin rechten en iemand zonder. Resultaat: een netwerk met update meldingen terwijl de gebruiker niet eens recht heeft om een update te draaien. Resulteert weer in verwarde gebruikers.
Waarom is niet eens goed centraal te managen (GPO?). Het is toch een zakelijk framework?

Mijn pc heeft echt geen java geïnstalleerd. Het werkt prima zonder en mis het niet. Ik zie het als men iPhone. Die heeft geen flash maar ik mis het ook niet want het zorgt ook dat alle webpagina's lekker snel blijven.

Java vreet veel geheugen. Ik weet dat sommige mensen dat niet belangrijk vinden maar in het bedrijfsleven is dat wel belangrijk want we hebben niet allemaal monsters van pc's op de werkplek. 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.

Leuk artikel wat ik trouwens net tegen kwam:
http://www.jelovic.com/articles/why_java_is_slow.htm

Ik weet dat het uiteindelijk grotendeels de schuld is van de devvers die de applicatie schrijven maar als het merendeel van de applicaties slecht draait is dat naar mijn mening ook de schuld van het framework.

Mijn mening. No flame intended.

[Reactie gewijzigd door dycell op 26 januari 2010 23:43]

Als je gewoon netjes installeert, eventueel javara gebruiken om op te schonen (even op javara googlen). Ik zit namelijk op +/- 90 mb voor deze versie (jre).

Daarnaast kan java best aardig vlot zijn en ook niet memory slurpend. Maar goed een groot voordeel van java blijft gewoon dat een groot deel van de applicataties meteen op allerlei omgevingen werkt.
Jammer dat nog steeds veel devvers Java als basis gebruiken. Het is zeer traag en log (groot). Mijn java directory was na alle updates een dikke GB groot. Ik heb het uit principe al niet meer op men pc geïnstalleerd staan.
Heb je een recente telefoon of Blu-ray speler? Grote kans dat daar java op draait. Verder is de JVM tegenwoordig dusdanig goed in het optimaliseren dat er bijna niet meer tegenaan te assemblen valt. Het enige punt dat ik je moet geven is dat oude versies niet automatisch worden gedeinstalleerd bij een update. Ik kan me ook echt bijna niet voorstellen dat je geen java meer op je pc hebt staan.
Edit: in bovenstaand bericht zijn de "Known Issues" ( http://java.sun.com/javas...html#knownissues-1.6.0_18 ) blijkbaar weggelaten. Daar wordt aangeraden om op een 64-bit OS eerst de 64-bit versie & pas dan de 32 bit versie van Java te installeren.
Mijn java directory was na alle updates een dikke GB groot.
Sinds Java 6 u10 (iirc) worden vorige Java versies verwijderd & blijf je enkel de recentste behouden, dus: uninstall alles wat je hebt aan Java, installeer deze versie, & je hebt er nooit geen last meer van.

De installer is iets meer dan 15 MB &, zoals cossy nl al zegt, neemt de installatie tegenwoordig niet meer dan 90 mb in. Ik weet niet hoeveel een installatie van het .NET framework inneemt, maar de installer alleen is al ruim 230 MB (full installer van 3.5 SP1), i.e. 18x groter dan de Java installer.
Het is zeer traag en log (groot).
En daar heb je vast ook uitgebreid onderzoek naar gedaan? :X

[Reactie gewijzigd door terje7601 op 26 januari 2010 13:11]

java dir van JRE is slechts 75,8 MB zeker nu harddisks van 500GB en groter.

Java kan net zo snel zijn als andere programmeertalen (bijv. c++).

Overigens heb ik tegenwoordig liever dat een applicatie meer geheugen gebruikt en daardoor snel is. Dan dat een applicatie krampachtig met geheugen moeten omspringen. Wat kost 4GB aan ram (40 euro).

[Reactie gewijzigd door Cobalt op 26 januari 2010 15:36]

Jammer dat nog steeds veel devvers Java als basis gebruiken. Het is zeer traag en log (groot)
Als (voornamelijk) Java dev weet ik als geen ander dat Java sterke en zwakke punten heeft. Daarom ben ik ook oprecht benieuwd naar je onderbouwing voor deze stevige woorden.

Ik ben namelijk van mening dat als je je zo sterk uitlaat over iets je wel verplicht bent om dit te onderbouwen (het geen je nu niet gedaan hebt).
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.
Leuk artikel wat ik trouwens net tegen kwam:
http://www.jelovic.com/articles/why_java_is_slow.htm
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 27 januari 2010 01:17]

@dycell

Dit artikel dateert uit 2005 en als je ook maar wat java had gevolgd had je geweten dat:
However, in order to achieve overall results like that, the language must be designed to give the compiler room for optimization. Unfortunately, Java was not designed that way. So no matter how smart the compilers get, Java will never approach the speed of C++.
Euhm heb jij onlangs nog eens een programma gerunt in een moderne jre ipv in een oude? Ik zal je vertellen dat de performance winst overduidelijk is.
Lots of Casts
With the advent of templates, good C++ programmers have been able to avoid casts almost completely in high-level programs. Unfortunately, Java doesn't have templates, so Java code is typically full of casts.
Sinds de tijd van dit artikel heeft java "Generics" geïntroduceerd en is het casten zo goed als verdwenen enkel onhandige overblijfselen uit het verleden daar gelaten.
Increased Memory Use

Java programs use about double the memory of comparable C++ programs to store the data. There are three reasons for this:

1. Programs that utilize automatic garbage collection typically use about 50% more memory that programs that do manual memory management.
2. Many of the objects that would be allocated on stack in C++ will be allocated on the heap in Java.
3. Java objects will be larger, due to all objects having a virtual table plus support for synchronization primitives.

A larger memory footprint increases the probability that parts of the program will be swapped out to the disk. And swap file usage kills the speed like nothing else.
Als je weet wat je compiler doet met je code dan weet je heel goed waar je welke code wel en waar welke niet mag schrijven. en als je een beetje voorzichtig en oplettend bent is het zeer goed mogelijk om met java zeer performante programma's te schrijven, misschien niet zo performant als in assembler mogelijk is. Maar ik denk dat niemand naar die tijd terug wil. Wel ik alleszins niet en ik ben zeer blij dat ik voor bijna iedereen programma's kan schrijven in één taal en zonder allerlei fuss zoals oeps ik draai een x86 van amd of ik draai er één van intel van generatie x of y en het werkt niet...

(zie ook JUDGExKTF: generaliseer enkele slechte programmeurs niet naar een volledige taal)
Het artikel dat je aanhaalt staat vol met niet onderbouwde en soms zelfs lachwekkende claims:

1. Het alloceren op de stack een zero time operation en kost in een lus nog steeds zero time?? Ik moet ook maar aannemen dat alloceren op de heap uberhaupt meer tijd kost.
2. Casten zal ook best performance kosten maar om dit nou te baseren op pseudo-code van hoe je het zelf zou implementeren lijkt me nou niet bepaald maatgevend. Ook kan al sinds java 5 gebruik worden gemaakt van generics (wat veelvuldig casten onnodig maakt). In tegenstelling wat de auteur lijkt te willen suggereren gebeurt dit compile time en zal dit dus geen performance kosten.
3. Ik kan niet ontkennen dat veel Java programma's een hoop geheugen gebruiken. Maar mede van invloed hierop is het geheugen wat je zelf toekent aan de JVM bij het opstarten en welke garbage collection instellingen je toepast.

Toch zijn er een aantal zaken in Java (waar de programmeur niets aan kan doen) die potentieel erg vervelend zijn:

1. De opstarttijd van de huidige JVM komt in de verste niet in de buurt van hoeveel tijd het kost om een native programma te initialiseren. De grootste veroorzaker hiervan is de steeds groter wordende 'rt.jar' die een gedeelte van het Java framework herbergt. Let op, het gaat hier over opstarttijden in de orde van grootte 200 ms. Java 7 gaat hier door zijn modulaire opzet hopelijk een einde aan maken.
2. Het maken van CLI programma's is een crime met Java. De snelheid waarmee bijv. geschreven kan worden naar de console is vrij mager in vergelijking met native programma's.

Het gevaar van Java en andere talen die dingen makkelijker maken is wel dat je programma's kan maken zonder van de hoed en de rand te weten. Bij grote programmatuur gaat dit natuurlijk op den duur mis...
Het zal wel aan mij liggen, maar na download van jre-6u18-windows-i586.exe blijkt het 'not a vallid 32 bits application ' te zijn...
Geen problemen hier... (W7 32b) Ff snel googlen leverde mij dit op. Misschien helpt dat? Waarschijnlijk is je download corrupt.
Je ziet in de verbeteringen die Sun nu doorvoert dat de focus van Java ontwikkeling sterk veranderd is; het was ooit robuustheid, nu is het bijna volledig de snelheid.

Op zich is het keerpunt niet op het verkeerde moment gekomen; het was al een betrouwbaar platform en nu wordt het alleen maar efficienter. Het brengt alleen een probleem met zich mee; de compiler / virtual machine is tegenwoordig zoveel beter in optimalizatie dat ik er zelf een luie programmeur van ben geworden!
JavaFX heeft met deze update een enorme snelheidsboost gekregen, met name bij het starten van een JavaFX applicatie in een browser.

Op dit item kan niet meer gereageerd worden.



Apple iPhone 6Samsung Galaxy Note 4Apple iPad Air 2FIFA 15Motorola Nexus 6Call of Duty: Advanced WarfareApple WatchWorld of Warcraft: Warlords of Draenor, PC (Windows)Microsoft Xbox One 500GBWebsites en communities

© 1998 - 2014 Tweakers.net B.V. Tweakers is onderdeel van De Persgroep en partner van Computable, Autotrack en Carsom.nl Hosting door True