Kotlin 1.8.0 版本已經(jīng)正式發(fā)布,以下是該版本更新中的一些主要內(nèi)容:
針對 JVM 的新實驗性功能:遞歸復制或刪除目錄內(nèi)容
Kotlin 1.8.0 為java.nio.file.Path引入了兩個新的擴展函數(shù):copyToRecursively()和deleteRecursively(),它們允許你以遞歸方式:-
將一個目錄及其內(nèi)容復制到另一個目的地
-
刪除一個目錄和它的內(nèi)容
用于java.nio.file.path的這些新函數(shù)是實驗性的。要使用它們,你需要選擇加入@OptIn(kotlin.io.path.ExperimentalPathApi::class)或@kotlin.io.path.ExperimentalPathApi。另外,你也可以使用編譯器選項-opt-in=kotlin.io.path.ExperimentalPathApi。
改進了 kotlin-reflect 的性能
利用kotlin-reflect現(xiàn)在是用 JVM target 1.8 編譯的這一事實,我們將內(nèi)部緩存機制遷移到 Java 的ClassValue。以前我們只緩存KClass,但現(xiàn)在我們也緩存了KType和KDeclarationContainer。這些變化使得調(diào)用typeOf()時的性能得到了明顯的改善。新增 -Xdebug 編譯器選項,以獲得更好的調(diào)試體驗
Kotlin 1.8.0 增加了一個新的-Xdebug編譯器選項,它可以禁用優(yōu)化以獲得更好的調(diào)試體驗。目前,該選項禁用了 coroutines 的 "已優(yōu)化" 功能。在未來,當我們添加了更多的優(yōu)化功能后,這個選項也將禁用它們。
kotlin-stdlib-jdk7和kotlin-stdlib-jdk8合并為kotlin-stdlib
在 Kotlin 1.8.0 中,標準庫(kotlin-stdlib、kotlin-reflect和kotlin-script-*)是用 JVM target 1.8 編譯的。此前,標準庫是以 JVM target 1.6 編譯的。Kotlin 1.8.0 不再支持 JVM targets 1.6 和 1.7。因此,你不再需要在構(gòu)建腳本中單獨聲明kotlin-stdlib-jdk7和kotlin-stdlib-jdk8,因為這些工件的內(nèi)容已經(jīng)并入kotlin-stdlib。改進了 Objective-C/Swift 的互操作性
為了使 Kotlin 與 Objective-C 和 Swift 更具有互操作性,1.8.0 增加了三個新的注解:-
@ObjCName允許你在 Swift 或 Objective-C 中指定一個更習慣的名字,而不是重新命名 Kotlin 聲明。 -
@HiddenFromObjC允許你從 Objective-C 中隱藏一個 Kotlin 聲明 -
@ShouldRefineInSwift對于用 Swift 編寫的包裝器替換 Kotlin 聲明很有用
與 Gradle 7.3 兼容
Kotlin 1.8.0 完全支持 Gradle 7.2 和 7.3 版本,這個版本帶來了很多變化:-
將 Kotlin 編譯器選項作為 Gradle 惰性屬性公開
-
提高了最小支持版本
-
能夠禁用 Kotlin 守護程序的回退策略
-
強制檢查相關的 Kotlin 和 Java 編譯任務的 JVM target 兼容性是否相等
聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學習之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問題,請聯(lián)系本站處理。
舉報投訴
-
SWIFT
+關注
關注
0文章
125瀏覽量
24840 -
kotlin
+關注
關注
0文章
60瀏覽量
4510
原文標題:Kotlin 1.8.0發(fā)布,改進性能和Swift的互操作性
文章出處:【微信號:OSC開源社區(qū),微信公眾號:OSC開源社區(qū)】歡迎添加關注!文章轉(zhuǎn)載請注明出處。
發(fā)布評論請先 登錄
相關推薦
熱點推薦
為什么選擇 Nordic 的低功耗藍牙解決方案?
,我們的協(xié)議??商峁┚哂行袠I(yè)領先互操作性的強大藍牙 LE 通信。
經(jīng)過驗證的質(zhì)量、可靠性和互操作性: 在數(shù)以千計的開發(fā)人員和數(shù)十億無線 So
發(fā)表于 04-16 10:40
吉事勵引領電動汽車充電互操作性與兼容性測試新風向
在電動汽車行業(yè)蓬勃發(fā)展的進程中,充電樁的互操作性與兼容性已成為決定行業(yè)能否持續(xù)穩(wěn)健前行的核心要素。這不僅關系到用戶充電體驗的優(yōu)劣,更影響著整個產(chǎn)業(yè)生態(tài)的健康發(fā)展。
是德科技攜手愛立信賦能Pre-6G互操作性驗證
是德科技(NYSE: KEYS )近日宣布,與愛立信攜手合作,使用是德科技的WaveJudge無線分析儀解決方案,對愛立信Pre-6G基站(gNB)與Pre-6G原型設備間的互操作性進行故障排查
通過恩智浦RW612三頻無線MCU提升多協(xié)議互操作性
無線連接是現(xiàn)代智能家居和工業(yè)系統(tǒng)的基石,推動著無數(shù)更智能、更自主設備的普及。恩智浦非常重視無線互操作性,確保生態(tài)合作體系中的每臺設備能夠無縫協(xié)同工作的關鍵能力。
愛立信攜手蘋果和聯(lián)發(fā)科技加速構(gòu)建6G生態(tài)系統(tǒng)
愛立信正通過與蘋果和聯(lián)發(fā)科技等領先設備及芯片制造商建立戰(zhàn)略合作伙伴關系,加速構(gòu)建6G生態(tài)系統(tǒng),驅(qū)動下一代連接技術的創(chuàng)新與互操作性,助力運營商及整個產(chǎn)業(yè)為移動網(wǎng)絡的未來做好準備。
IO序列化操作:提升系統(tǒng)互操作性的關鍵技術
在異構(gòu)系統(tǒng)并存的今天,IO序列化操作成為實現(xiàn)系統(tǒng)間互操作性的核心技術。通過標準化的數(shù)據(jù)格式(如JSON、Protobuf、Hessian等),不同語言、平臺的系統(tǒng)得以無縫交換信息。合理設計序列化策略
Matter 1.5 正式發(fā)布
景,包括對攝像頭、閉合設備、土壤傳感器的支持,同時還新增多項能源管理功能。此次更新延續(xù)了 Matter 的核心使命,即簡化智能家居開發(fā)流程、增強設備互操作性,為消費者與開發(fā)者打造更豐富、更可持續(xù)的互
是德科技與HEAD acoustics成功完成新一代eCall系統(tǒng)互操作性測試
是德科技(NYSE: KEYS )近日宣布,其基于UXM的新一代eCall(NG eCall)解決方案,已成功與全球汽車聲學測試領導者HEAD acoustics GmbH完成互操作性測試。
全新升級 | 匠芯創(chuàng)AiUIBuilder V2.0.0發(fā)布
近日,匠芯創(chuàng)自主研發(fā)的GUI開發(fā)工具AiUIBuilderV2.0.0發(fā)布。作為一款基于LVGL的UI設計工具,AiUIBuilder致力于通過拖拽式操作,加速基于匠芯創(chuàng)嵌入式平臺的圖形應用開發(fā)
Microchip與AVIVA Links實現(xiàn)ASA-ML互操作性驗證
汽車行業(yè)正加速從專有串行器/解串器(SerDes)解決方案向汽車串行器/解串器聯(lián)盟(Automotive SerDes Alliance)及其首個開放標準——ASA Motion Link(ASA-ML)構(gòu)建的可互操作系統(tǒng)生態(tài)過渡。
Kuikly鴻蒙版正式開源 —— 揭秘卓越性能適配之旅
和Kotlin Native可以直調(diào)、無額外跨VM/語言調(diào)用開銷。除了早期CAPI版本存在一些Bug和功能缺失等問題,CAPI方案也在開發(fā)難度、復雜性上也更高,但為了追求極致性能表現(xiàn),我們最終決定采用
發(fā)表于 06-04 16:46
Matter 智能家居的通用語言
Matter由連接標準聯(lián)盟(CSA)創(chuàng)建,旨在解決智能家居的互操作性問題。Matter 基于簡單性、互操作性、可靠性和安全
發(fā)表于 05-19 15:35
解讀新發(fā)布的 Matter 1.4:推動智能家居設備互操作性的關鍵升級
著Matter 1.4的發(fā)布,智能家居和物聯(lián)網(wǎng)(IoT)行業(yè)迎來了新的里程碑。Matter作為全球統(tǒng)一的智能家居互聯(lián)協(xié)議,在互操作性、安全性和能效優(yōu)化等方面取得了重大突破。本文將從Ma
Kotlin 1.8.0發(fā)布,改進性能和Swift的互操作性
評論