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. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 24 reacties
Bron: Sun, submitter: Domokun

Sun heeft voor zowel de development kit als voor de runtime environment alweer de dertiende update uitgebracht voor Java Standard Edition 6.0. De versieaanduiding is vastgesteld op 6.0 update 13 en het exacte versienummer is op 1.6.0_13-b03 komen te liggen. De ontwikkelaars hebben de beveiliging van verschillende onderdelen verbeterd, ondersteuning voor meer root certificaten toegevoegd en een lijstje met bugs verholpen. De lijst met veranderingen voor deze dertiende update ziet er als volgt uit:

Changes in 1.6.0_13

The full internal version number for this update release is 1.6.0_13-b03 (where "b" means "build"). The external version number is 6u13.

OlsonData 2009a
This release contains Olson time zone data version 2009a. For more information, refer to Timezone Data Versions in the JRE Software.

Security Baseline
This update release specifies the following security baselines for use with the original Java Plug-in technology:
JRE Family Version 5.0 - Security Baseline 1.5.0_18
JRE Family Version 1.4.2 - Security Baseline1.4.2_20
For more information about the security baseline, see Deploying Java Applets With Family JRE Versions in Java Plug-in for Internet Explorer.

Java Naming and Directory Interface (JNDI) API Change
The behavior of the JNDI feature to store and retrieve Java objects in an LDAP directory has been slightly modified. When storing a Java object in an LDAP directory, the location of the object's class file (its codebase) may be specified. Later, when restoring the original object, its codebase along with additional object data is retrieved from the directory and used by the class loader. An object's codebase is no longer implicitly trusted. Instead, a new system property called com.sun.jndi.ldap.object.trustURLCodebase must explicitly be set to the string value true in order for a codebase to be used. Otherwise, the codebase will be ignored by the class loader when restoring a Java object, and only those class files that appear on the classpath will be recognized.

Java Management Extensions(JMX) Change
In a JMX access property file, the readwrite access no longer allows the remote createMBean and unregisterMBean operations. These must now be provided explicitly via new clauses. The default jmxremote.access file of the JRE ($JRE_HOME/lib/management/jmxremote.access) shows what this looks like.

Root Certificates Included
Root Certificates are included in this release. The following root certificates have been added:
  • Two additional T-systems root CA certs (Refer to 6803022.)
  • Two Unizeto root certs (Refer to 6803036.)
Bug Fixes
This release contains fixes for one or more security vulnerabilities. For more information, please see Sun Alerts 254569, 254570, 254571, 254608, 254609, 254610, and 254611.

Bug fixes are listed in the following table:
  • hotspot - runtime_system - Runtime.availableProcessors / os::active_processor_count wrong if unused processor sets exist
  • java - classes_net - URLConnection for HTTPS connection through Proxy w/ Digest Authentication gives 400 Bad Request
  • java - classes_security - Add T-systems root CA certs to the JRE
  • java - classes_security - Add Unizeto root certs to the JRE
  • java - classes_util_i18n - (tz) Support tzdata2009a
  • java_plugin - plugin2 - Issues with parsing of JNLP file under some scenarios while launching applets from desktop shortcut
  • jax-ws - wsimport - W3CEndpointReference constructor skips the extension elements or attributes
Versienummer:6.0 update 13
Releasestatus:Final
Besturingssystemen:Windows 9x, Windows NT, Windows 2000, Linux, Windows XP, Linux x86, Solaris, Windows Server 2003, Windows XP x64, Windows Server 2003 x64, Linux AMD64, Windows Vista, Windows Vista x64
Website:Sun
Download:http://java.sun.com/javase/downloads
Licentietype:Voorwaarden (GNU/BSD/etc.)
Moderatie-faq Wijzig weergave

Reacties (24)

Weet iemand toevallig het verschil tussen de versies:
jre-6u13-windows-i586-p.exe
jre-6u13-windows-i586-p-s.exe

Via de Java site wordt de jre-6u13-windows-i586-p-s.exe versie aangeboden, zie http://www.java.com/nl/download/manual.jsp voor het volledige installatiepakket (ik geef hier de voorkeur aangezien je dan niet online hoeft te zijn bij installatie). Via de site van Sun wordt de versie zonder '-s' aangeboden.
De met -s is de offline installer en de ander is de online installer. Op de Sun site staat volgens mij enkel de offline installer.
Dat klopt niet, want beiden zijn zo'n 15,5-15,6 MB groot. Dus beiden zijn offline-installers. Het verschil heb ik ergens nergens kunnen terugvinden, dus vandaar mijn vraag.
Waar haal je die grotes vandaan ? Ik zie hele andere dingen op java.com en sun.com

Als je hier http://java.com/en/download/manual.jsp kijkt zie je:

jre-6u13-windows-i586-p.exe -> Download van 593 KB
jre-6u13-windows-i586-p-s.exe -> Download van 15MB
Nope, via http://java.com/en/download/manual.jsp krijg je als je de Online versie klikt de file jre-6u13-windows-i586-p-iftw.exe van 593 kB. Maar daar had ik het niet over. Ik heb het over de Offline versies. Als je vanaf de Sun site download (http://java.sun.com/javase/downloads) dan krijg je de jre-6u13-windows-i586-p.exe van 15,5 MB. Zoals gezegd, daar mist dus de '-s' in de naam zoals je die krijgt als je via de java.com site download.
Ik zie het inderdaad, raar. Ze wijken ook iets af in grote :

16283032 2009-03-29 19:05 jre-6u13-windows-i586-p.exe
16438680 2009-03-29 19:05 jre-6u13-windows-i586-p-s.exe

Ik dacht heel even dat de een misschien gesigned was, maar beide zijn signed.
Ik hoop dat binnenkort ook eens multi-core goed ondersteund gaat worden. Dat zou de waarde van het gebruik van Java echt enorm verhogen. Zeker nu sinds kort ook x64 ondersteund wordt.
Ik hoop dat binnenkort ook eens multi-core goed ondersteund gaat worden. Dat zou de waarde van het gebruik van Java echt enorm verhogen.
In welke zin wordt multi-core dan niet goed ondersteund nu?

Mijn Java draait perfect concurrent op de 8 cores in mijn Mac Pro die ik op het werk heb tegelijk. Ten opzichte van andere platformen/talen heeft Java vrij degelijke concurrency support (met name vanwege de concurrent package). In Java 7 (~H2 2010) komt daar een behoorlijk update van, met oa een implementatie van het veel geroemde fork/join + workstealing principe.

Als je wilt kun je die libs trouwens NU ook al gebruiken. De implementatie is er namelijk al.
Java zou multiplatform zijn, maar OS X is zeker niet de moeite van een update waard?
Apple moest en zou zelf Java op OS X regelen. Als je betere support voor Java op de Apple wilt moet je daarover dus bij Apple klagen.

Als alternatief waren er ook mensen bezig de OpenJDK te poorten naar OS X dacht ik ?

[Reactie gewijzigd door JUDGExKTF op 27 maart 2009 22:20]

Als alternatief waren er ook mensen bezig de OpenJDK te poorten naar OS X dacht ik ?
Vanaf JDK7 (die helemaal via de OpenJDK ontwikkeld wordt) zal er als het goed is ook een Mac OS X build bijkomen. Naar verwachting zal deze hooguit een half jaar tot max een jaar achterlopen op de Linux/Windows builds. Ik verwacht dat het eerder hooguit een half jaar zal worden en in de praktijk wellicht minder.
En hij verwijdert nu de voorgaande versie. In mijn geval was dat build12.
Dat zou ook wel eens tijd worden...
Is Sun eindelijk wakker geworden, of is JavaRa ze eindelijk opgevallen?
Sun eindelijk wakker geworden ? Het is niet alsof we praten over Java Bug ID 4957990 ( http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4957990 ). We praten hier naar mijn idee over een minor inconvenience; Kwestie van handmatig deinstallen, big deal. Zoals je zelf al aangeeft is er zelfs een programmatje voor dat het voor je doet....
Dit is geen "minor inconvenience". Gewone gebruikers die de JRE installeren omdat hun software zegt dat ze het nodig hebben, zullen niet eens weten dat oude versies achter blijven. Ik zie soms computers met een hele geschiedenis java updates.
Gewone gebruikers die de JRE installeren omdat hun software zegt dat ze het nodig hebben, zullen niet eens weten dat oude versies achter blijven.
We hebben het hier over de gewone, doorsnee, Windows Vista gebruiker neem ik aan ? Die dus een besturingssysteem gebruikt wat al 10 GB is ? Waar standaard system restore aan staat dat 5% van je vrije space gebruikt ? Die doorsnee gebruiker ?

We leven in Terabyte tijden. Ik denk niet dat die 70 MB per JRE echt een major issue is. Ik zeg niet dat het geen issue is maar jullie blazen het wel enigsinds op.

Daarnaast win je theoretisch gezien weer wat aan space aangezien Java applicaties niet AOT gecompiled worden maar JIT dus zijn ze kleiner.
Gelijk maar even mee genomen in onze nieuwe Coldfusion 8.01 test omgeving. Het draaid prima op de 64-bit server hotspot.
Hij doet het in elk geval prima met WebICE :)
De 13de update alweer. Het gaat snel. Java 6 is nu wel echt helemaal volwassen.

Zijn er eigenlijk nog mensen hier die nog steeds 'bang' zijn voor dat enge Java 5 voor hun development en angstvallig aan Java2 1.4 vasthouden?
Ik zie nog regelmatig berichten langskomen in de fora over mensen die willen upgraden naar 1.2 of 1.3 en "of dat problemen gaat geven". Dus ja, ik neem aan dat java 1.4 nog veel gebruikt wordt, maar dan meer omdat grote systemen ontwikkeld zijn voor die versie en aanpassingen nodig hebben om op java 5 te kunnen werken (wat natuurlijk veel tijd en geld kost, niet alleen in de ontwikkeling maar ook voornamelijk in het testen).
Zoals gimbal al aangeeft, in veel gevallen is het niet 'angstvallig' vasthouden aan een oudere versie, maar gewoon enorme projecten. Veel van de grotere (bedrijfs)websites (denk Bol e.d.) draaien op Java, en bestaan vaak uit duizenden, zo niet tienduizenden classes. Om die 'even' over te zetten naar Java 1.5 (of hoger) kost veel tijd / geld.

Zelf vindt ik 1.5 het wel waard hoor, vooral generics is een uitkomst. Sterker nog, ik heb nooit met 1.4 gewerkt, en ik huiver bij de gedachte om Lists te maken zonder generics.
het was wat lastiger met alle nodige typecasts, maar ik heb nooit echt hinder ondervonden zonder generics. Ook al maken ze de code wat minder foutgevoelig dankzij de compiletime type checks, persoonlijk vind ik de code er niet schoner op worden. Zonder de generic declaraties was de code simpel en leesbaar, met name voor mensen die de taal net aan het leren zijn kan het verwarrende overkomen.

Wat ik zelf een enorm handige toevoeging vind zijn de annotations, met name in de enterprise hoek scheelt dat een enorme berg tik en configureerwerk (met als tegenargument dat de code er alweer niet schoner op wordt).
een woord: eens!
Zoals je zelf ook al zegt vang je door generics meer fouten bij compile time af. Ik ben zelf altijd voorstander geweest van het fail early princiepe.

Of de code schoner word kan je over twisten (dus dat doen ik dan bij deze ook ;) ) Los van dat het code toevoegd wat door sommige misschien als 'voodoo magic' gezien word scheelt het een hele hoop casts en if ( foo instanceof bar) statements. Dus dat ruimt ook weer aardig op. Persoonlijk kan ik me niet voorstellen hoe ik ooit zonder generics geleefd heb :)

Annotations vind ik zelf ook op bepaalde punten handig. Vooral in de view, in het model vind ik het wat minder. Je model beans worden dan vaak opeens implementatie afhankelijk en maakt het lastiger ze in het domein rond te sturen. Configureer werk daarvoor houd ik vaak liever in XML.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True