The Sharp Edgeds of JDK 9 - JavaOne 2016

Copyright©2016, Oracleand/oritsaffiliates.Allrightsreserved.|

ThesharpedgesofJDK9ChangesforJDK9thatcouldrequireyoutochangeyourcodeandprocesses

AurelioGarcia-RibeyroJavaSEProductManagementSeptember2016


SafeHarborStatementThefollowingisintendedtooutlineourgeneralproductdirection.Itisintendedforinformationpurposesonly,andmaynotbeincorporatedintoanycontract.Itisnotacommitmenttodeliveranymaterial,code,orfunctionality,andshouldnotberelieduponinmakingpurchasingdecisions.Thedevelopment,release,andtimingofanyfeaturesorfunctionalitydescribedforOracle’sproductsremainsatthesolediscretionofOracle.


Aboutme– SeniorGroupProductManagerfortheJavaPlatformGroupatOracle– InchargeofmanagingtheproductrequirementsforOracle’sJDKsincejoiningOraclethroughtheSunacquisitionin2010

– BeforejoiningOracle,workedatSunMicrosystemsfortheJavaProductManagementteam

–MBAfromMITSloanandBachelordegreeinSystemsEngineeringfromUniversidaddeLima


ProgramAgenda

Intro

Large– Manyprogramsaffected,rewriterequired

Medium– Gonein9butusedbylesssystems

Small– Easyworkaround

1

2

3

4


Javaremainscommittedtobackwardcompatibility


Buttherearestillmanywaysonwhichanychangetotheplatformcanhavealargeimpactonlegacyprograms

⚠Thispresentationisnotall-inclusiveandremainssubjecttochange


• Java2DfontmetricsbugfixedonJDK1.2• [Important customer] recognizedthebugasavalidbugandthefixasacorrectfixhowever…..• Versionsoftheirprograminthefieldreliedonthebug

• Aflagwasaddedtoallowturningthebugfixoff

Onedeveloper’sbugfixisanotherdeveloperbug…


From“Sun”to“Oracle”• In2010Oracleannounceditsintentiontochangeseveralpropertiesthatsaid“Sun”totheequivalent“Oracle”values• EclipsetoldusitwouldstopworkingsinceitusedthevendortodeterminewhatJVM(HotspotvsJ9)flagstoset• Eclipsecouldn’treadthepropertiessincethatrequiredstartingtheJVMandthatrequiredknowingwhichparameters…..

• Weaddedapropertytextfilefortheirconvenienceanddelayedthefixuntiltheywereready


It’sevenus….“CodetotheSpec,nottotheimplementation”FromJDK7SpecificationforHashMap:Thisclassmakesnoguaranteesastotheorderofthemap;inparticular,itdoesnotguaranteethattheorderwillremainconstantovertime.

• InJDK7uXabugfixalteredthereturnorderofthevaluesinaHashMap• OurownJDKcodereliedontheiterationorder

• Hadtodelaythefixareleasetoaddressthis


Wecouldproducehundredsofexamplesifwewanted


Javaremainscommittedtobackwardcompatibility

Butthatdoesn’tmeaneveryprogramwillalwaysworkunchangedonthenextrelease


• Bugfixes• Changesinsupportedalgorithms• Newsecurityrequirements• Changesinsupportedplatforms• Useofnativecode• Changesinproperties• Deprecationstriggeringnewwarnings• Changesindeployment(browser)

• Changeininternalworkings– E.g.Garbagecollectionalgorithmsor– UseofinternalAPIs

• Changeinpackaging– Filenames,internalstructureoffiles,registrykeysinWindows,installationfolders,etc.

• Additionaltoolsorfilesnolongerincluded

Commonincompatibilitiesaredueto


• Bugfixes• Changesinsupportedalgorithms• Newsecurityrequirements• Changesinsupportedplatforms• Useofnativecode• Changesinproperties• Deprecationstriggeringnewwarnings• Changesindeployment(browser)

• Changeininternalworkings– E.g.Garbagecollectionalgorithmsor– EncapsulationofinternalAPIs

• Changeinpackaging– Filenames,internalstructureoffiles,registrykeysinWindows,installationfolders,etc.

• Additionaltoolsorfilesnolongerincluded• Removalofdeprecatedmethods,classes,andfunctionality

IncompatibilitiesexpectedinJDK9dueto


#1IncompatibilityexpectedinJDK9

AthirdpartylibraryortoolthatyourcodereliesonisaffectedbythechangestoJDK9

• AspartoftheJDK9workwearecontactingdevelopersofmanycommonframeworksandcommonlibrariesthatwehaveidentifiedasaffected• ExpectmostvendorswithlargeinstalledbasetoprovideupdatesbeforeJDK9releasesbut…• Untilyourcodeadoptsthenewversions:itislikelyaffected


LargechangesExpectmanydeveloperstohavetochangecode


JEP260:EncapsulatemostinternalAPIs

• ThevastmajorityofinternalAPIswillbecomeinaccessiblebydefault• AhandfulofwidelyusedinternalAPIswithoutgoodalternativeswillremainpublicuntilalatermajorreleasewhenalternativesarecreated• jdeps, toolavailablewithJDK8,canhelpidentifyprogramsthatmightbeimpacted(bettertousejdeps fromJDK9EAasitismorecurrent)• Multi-ReleaseJARfiles(JEP238)isbeingintroducedtoallowmanyJava-release-specificversionsofaclasstocoexistinasingleJARfile• AcommandlineoptionwillallowrevertingthischangeforJDK9

InternalAPIsnolongeraccessibletodevelopers


JEP223:NewVersionStringScheme

• TheversionstringforJDK8andearlierisconvolutedandnon-standard• NewversionstringisclosertoSemantic-Versioninganddropssomelongkeptbaggage(e.g the“1.”infront,theuseof“u”forupdates)• Javapropertieswillchange;programsthatrelyonversionstringstocheckforcorrectJavaversionmightneedtobeupdated• AllfilenamesforJavabinaryfilenameswillalsochange– Buildandtestsystemsthatassumedoldformatwillneedtobeupdated

• Codewillhavetodealwith“old”and“new”formatsformanyyearsasthechangeisonlyforJDK9andlater

JDK1.9.0_25 turnsintoJDK9.1.9andallthebinaryfilenameschange


JEP220:ModularRun-TimeImages

• WiththenewmodulesystemtheinternalstructureoftheJDKchangessignificantly• DirectorystructuresandfilenamesinsidetheJDKfolderarechanging• AllprogramsthatinspecttheJDKfolderandinferanythingfromtheexistence,orlackof,anyfilearelikelytobeintrouble

Bye,byert.jar


Mediumchanges- Gonein9butlesslikelytobeusedbymanySpecificAPIs,Methods,Features,etc.nolongerincludedwiththeJDK


Removemostsun.misc.*andsun.reflect.*APIs

• InordertokeepcriticalAPIswithoutareplacementaccessiblebydefaultsun.misc andsun.reflect willnotbehiddenandafewAPIskept“public”– sun.misc.Unsafe– sun.misc.{Signal,SignalHandler}– sun.misc.Cleaner– sun.reflect.Reflection::getCallerClass– sun.reflect.ReflectionFactory

• AllotherAPIsinthesepackages(e.g.sun.misc.Base64)willberemoved

ExceptforafewcalledoutonJEP260


• JEP173deprecatedtheseGCcombinationswithJDK8• UnsupportedanduntestedsinceJDK8• Theseflagcombinationswillnowerror• DefNew +CMS:ParNew +SerialOld :-XX:+UseParNewGC

ParNew +iCMS :-Xincgc

ParNew +iCMS :-XX:+CMSIncrementalMode -XX:+UseConcMarkSweepGC

DefNew +iCMS :-XX:+CMSIncrementalMode -XX:+UseConcMarkSweepGC -XX:-UseParNewGC

CMSforeground:-XX:+UseCMSCompactAtFullCollection

CMSforeground:-XX:+CMSFullGCsBeforeCompaction

CMSforeground:-XX:+UseCMSCollectionPassing

• IncrementalCMS(iCMS)isremoved

JEP214:RemoveGCCombinationsDeprecatedinJDK8


Generalrule:LookoutforunrecognizedVMoptions• LaunchingJREwithunrecognizedVMoptionsfails• UsingdeprecatedoptionsinJDK8triggerswarningmessages

$java-XX:MaxPermSize=1G-versionJavaHotSpot(TM)64-BitServerVMwarning:ignoringoptionMaxPermSize;supportwasremovedin8.0

• Previouslydeprecatedoptions,removedinJDK9,willfailtostart– PermgenerationwasremovedinJDK8(JEP122)– Expectmanyprogramstorunintothisproblem


FollowuptotheworkstartedwithJDK8inJEP162:PrepareforModularization• RemoveaddPropertyChangeListener andremovePropertyChangeListener– Fromjava.util.logging.LogManager– Fromjava.util.jar.Pack200/Unpack200

• Removecom.sun.security.auth.callback.DialogCallbackHandle


JEP231:RemoveLaunch-TimeJREVersionSelection

• MultipleJRE(mJRE),introducedinJDK5,allowedspecifyingwhatJREversion,orrangeofversions,shouldbeusedtolaunchanapplication• Theversion(s)couldbespecifiedinamanifestentryintheapplicationjarorthroughacommandlineparameter• InreallifechoosingaJREversiontakesmoreworkandwehavebettermechanismsfordoingtheselection• InJDK9version(s)selectedthroughthemanifestwillbeignored(withawarning),version(s)selectedthroughthecommandlinewillerrandexit


JEP182:PolicyforRetiringjavac -sourceand-targetoptions

• Useof–sourceand–targetof1.5orearlierwasdeprecatedinJDK8• JDK9willallowonly–sourceand–targetofJDK1.6(6)orhigher• Newpolicywillbe"oneplusthreeback"forfutureJDKversions


EndorsedStd OverrideandExtensionmechanism,deprecatedin8u40,droppedin9

• Extensionmechanism(alsocalledOptionalPackages)madeAPIsavailabletoanyapplicationrunningontheplatform• EndorsedStandards wasusedforupdatingcertainclassesandinterfacesoftheruntimewithoutupdatingthewholeJRE• JDK9failsifanythingisplacedon${java.home}/lib/ext and${java.home}/lib/endorsedorifyouusejava.ext.dirs systemproperty• JDK8u40introduced-XX:+CheckEndorsedAndExtDirs toprintamessageifyouareusingtheextensionorstandardmechanisms• Useupgradablemodulesorputjarsontheclasspath instead

JDK-8060206


java.awt.peer andjava.awt.dnd.peer packageswillbehidden

• Allthefunctionalitytheseclassesprovideisavailableinother,supported,APIs• jdeps (availablesince8butusetheonefrom9)willflagtheseandgiveyoualternatives• AlreadyannouncedinOpenJDK,receivedpositivefeedback

Non-obvious,buttheseAPIswerefortoolkitimplementers


JEP240:RemovetheJVMToolInterfacehprof Agent

• SourcecodewillremainonOpenJDKbutthetoolwillnotshipitaspartoftheOracleJDK• WaswrittenasdemonstrationcodefortheJVMTI– Documentationhasmanyinstancesof: “ThisisdemonstrationcodefortheJVMTIinterfaceanduseofBCI,itisnotanofficialproductorformalpartoftheJDK.”

• Heapdumps(heap=dump)supersededbythesamefunctionalityintheJVM:GC.heap_dump (jcmd <pid>GC.heap_dump),alsoavailableviajmap -dump

• Allocationprofiler(heap=sites)availablethroughJavaVisualVM andmanythirdpartyprofilers

• CPUprofiler(cpu=samples,cpu=times)supersededbyJavaFlightRecorderandJavaVisualVM

libhprof.so


JEP241:Removethejhat Tool

• SourcecodewillremainonOpenJDKbutthetoolwillnotshipitaspartoftheOracleJDK• AddedinJDK6,baseduponthejava.net HAT(HeapAnalysisTool)project.• Experimental,unsupported,andout-of-datetool• Alreadymarkedwith:"NOTE:ThistoolisexperimentalandmaynotbeavailableinfutureversionsoftheJDK."• Superiorheapvisualizersandanalyzershavenowbeenavailableformanyyears.


TheentireHTTPproxying mechanismofRMIwasdeprecatedinJavaSE8

• RemoveRMIHTTPproxyimplementationJDK-8066750• RemoveRMI/JRMPHTTPtunnelingimplementation• Neverworkedproperly

AndwillberemovedinJDK9


Thread.stop(Throwable),longtimedeprecated,willthrowexception

• Thread.stop methodsareinherentlyunsafe,causethreadstoleaveobjectsinaninconsistentstate,andhavebeendeprecatedsince1998(JavaSE1.2)• RatherthantrydodosomethingunsafeitwillnowthrowUnsupportedOperationException• Theno-arg Thread.stop()remains.– Althoughthismethodisalsoinherentlyunsafe,itappearstohavesignificantlymoreusagethanThread.stop(Throwable)

http://ccc.us.oracle.com/7059085


RemoveSerializedAppletsfunctionality

• Thisistheabilitytodeployappletsasserializedobjects• ModerncompressionandJVMperformancenegateallbenefitstothistechnology• Appletsasadeploymentmechanismisbeingdeprecated

JDK-8074161


Non-strictJNLPParsingnolongerallowed

• JNLPparsingcurrentlyallowserrorsthatmakecodemaintenancedifficultandincreaseexploitattackarea• Strictparsingwillremoveinconsistencies• ExpectthechangestobeminorandeasytofixbutmightimpactalargenumberofJNLPimplementations

http://ccc.us.oracle.com/8075605


RemoveUnsupportedAppleAPIs

• JEP272:Platform-SpecificDesktopFeaturesreplaces– com.apple.eawt– com.apple.eioWithplatform-independentalternativesinjava.awt

• removecom.apple.concurrent JDK-8148187• Remove AppleScriptscriptingengineJDK-8143404

LegacycodereceivedthroughApple’scontributionoftheirownport


Removecom.sun.image.codec.jpeg

• ReplacementAPIshippedsince2002(1.4)• NotavailableinOpenJDK• DeprecatedinJDK7

JDK-8038838


JEP271:UnifiedGCLogging

• Logsaredifferentformat– Parsersmightneedtobereworked

• Mostcommonflagsaretobedeprecatedandremapped-XX:+PrintGC willbemappedto-Xlog:gc-XX:+PrintGCDetails willbemappedto-Xlog:gc*-Xloggc:<filename>willbemappedto-Xlog:gc:<filename>

• 43lessusedGCloggingflagsareremoved.JVMwillnotstartiftheseflagsarespecifiedonthecommandline. http://ccc.us.oracle.com/8145092

Re-implementedGCloggingwiththenewJVMloggingframeworkfromJEP158


_nolongerallowedasaone-characteridentifier.

• PartofJEP213:MillingProjectCoin• InJDK8itwasbannedfromlambdaparameters• WarningissuedwhenusedsinceJDK8- JDK-8005852

JDK-8061549


Windows32ClientVMdropped

• Windows32defaultVMwasclientuptoJDK8• OptionsforemulatingclientVMbehavior– setTieredStopAtLevel to1bydefault(sothatonlyC1compilationsareperformedinthesystem)

– adjusttieredcompilationthresholdssothatintheemulatedclientbuildC1compilationhappensaroundthesametimeasinclientVM

– setthesizeofthecodecachetoavalueusedinclient– useParallelGC insteadofG1

OnlyserverVMwillbeoffered


DeploymentTechnologiessupportedonlyonclient/developmentoperatingsystems

• SupportedonWindows10,8,and7,UbuntuLinux,andOSX• ThismeansnotsupportedinOracleLinux,RedHatLinux,Solaris,WindowsServer,etc


AnnoyanceSectionEasytogetaroundbutminorworkneeded


G1isthenewdefaultgarbagecollector

• ParallelGCwasthedefaultuptoJDK8onmostplatforms– Stilltherebutnolongerthedefault– CanturnbacktoParallelGCviacommandflags– SerialGCis,andremainsinJDK9,thedefaultGCon32bitWindows

• OnplatformswhereG1isnotavailable(e.g.ARM)wekeepthecurrentdefault

JEP248:MakeG1theDefaultGarbageCollector


JEP252:UseCLDRLocaleDatabyDefault

• UnicodeConsortium'sCommonLocaleDataRepositoryisthede-factostandardforlocaledataonmanyplatforms• CLDRlocaledataisbundledwiththeJREasofJDK8butnotenabledbydefault• Defaultlookuporderwillbe:CLDR,JRE,SPI• Localizedpatternsfortheformattingandtranslationofdisplaystrings,suchasthelocalename,maybedifferentinsomelocales• Cansettojava.locale.providers toavaluewithJREaheadofCLDRtoreverttoJDK8behavior


NolongershipJavaDB

• JavaDB isarepackagingofApacheDerby• IsbundledwithJDK7and8• ApacheDerbyremainsavailablefromApache

JDK-8004716


DeprecatedinJDK9(butstillthereatleastuntilJDK10)• Appletasadeploymentmechanism– Appletviewer– CommonDOMAPIs:JDK-8074162– classid support:JDK-8134712

• VP6videocodecandFLV/FXMfileformatforJavaFXMediaJDK-8134330

• jarjar:JDK-8133595

• CMSGarbageCollector

• com.sun.jarsigner packageJDK-8076535

• JavaPolicyTool

• SeveralsecurityAPIsthatarenolongercurrentJDK-8050955

• Doclet API,replacedwithsimplifieddoclet JEP221

The Sharp Edgeds of JDK 9 - JavaOne 2016

Documents

Transcript of The Sharp Edgeds of JDK 9 - JavaOne 2016