9 篇文章 含有標籤「Java」

🚀 使用 GitHub Copilot 代理模式現代化 Java 專案的逐步指南​

Source: https://github.blog/ai-and-ml/github-copilot/a-step-by-step-guide-to-modernizing-java-projects-with-github-copilot-agent-mode/

• GitHub Copilot 代理模式將 Copilot 從被動建議工具轉變為主動協作夥伴，能理解高層次指令並執行多步驟任務，無需詳細指示。
• 搭配 GitHub Copilot 應用現代化 VS Code 擴充功能，此工具組提供互動式、逐步指引，幫助開發者更快、更少錯誤地升級和遷移 Java 專案。
• 現代化流程包括：分析專案、生成升級計畫、自動應用變更、修復建構問題、驗證測試、檢測並修復 CVEs，並提供完整的摘要報告。
• 範例指令與程式碼片段：
  • 啟動代理會話後，輸入：

    Using Java upgrade tools,upgrade this project to Java 21. Analyze deprecated APIs, update Gradle dependencies, and propose a safe, testable migration plan.
    

  • 程式碼升級前後對比：

    // Before (deprecated constructor)
    View view = this.resolver.resolveViewName("intro", new Locale("EN"));
    
    // After Java 21 upgrade
    View view = this.resolver.resolveViewName("intro", Locale.of("EN"));
    

• 此外，它還支援將應用程式遷移到 Azure，進行雲端就緒評估，並將認證從地端遷移到 Microsoft Entra ID。
• 自動化 CVE 掃描是其關鍵安全功能，可智慧地提出安全版本替換或推薦替代函式庫，以維持安全合規。

📉 GitHub 2025 年 8 月可用性報告​

Source: https://github.blog/news-insights/company-news/github-availability-report-august-2025/

• 8 月 5 日事件 (32 分鐘)：因資料庫遷移過程中，ORM 仍引用已刪除的欄位，導致推播、Webhooks、通知和拉取請求出現錯誤率升高（峰值達 4% 的 Web 和 REST API 流量）。GitHub 通過部署變更，指示 ORM 忽略該欄位來緩解問題。此事件揭露了應用程式監控的漏洞以及跨環境更新的不足。
• 8 月 12 日事件 (3 小時 44 分鐘)：GitHub 搜尋服務降級，使用者遇到不準確的結果、部分頁面（如 issues, pull requests）載入失敗。問題源於負載平衡器與搜尋主機間的間歇性連線問題，最終導致重試佇列超載。通過限制搜尋索引管道和自動重啟搜尋主機解決。GitHub 隨後改進了內部監控、操作手冊並調整了負載平衡器。
• 8 月 27 日事件 (46 分鐘)：Copilot、Web 和 REST API 流量性能降級。此事件與 8 月 5 日類似，也是因資料庫遷移刪除欄位但 ORM 仍引用所致，導致 Copilot 請求高達 77% 的失敗率。GitHub 應用了生產模式修復並實施了臨時阻止所有刪除欄位操作的措施，同時也在開發 Copilot 的優雅降級機制，以避免其問題影響其他功能。

🤔 重新發掘學習的樂趣：Jason Lengstorf 談開發現況​

Source: https://github.blog/developer-skills/career-growth/rediscovering-joy-in-learning-jason-lengstorf-on-the-state-of-development/

• 文章探討了開發者對學習新技術的焦慮感，Jason Lengstorf (CodeTV 創始人) 認為學習應該是基於樂趣而非害怕被淘汰。
• AI 作為能力乘數而非取代者：AI 能顯著提升熟練開發者的速度，並加速初學者的學習過程。但若缺乏學習意願，AI 反而會製造更大的問題。
• 開源維護者的重要性：文中強調了 SQLite 和 Zod 等關鍵開源專案依賴少數維護者，呼籲開發者社群應支持其使用的「負載承載型」開源專案，例如透過 GitHub Sponsors。
• 未來網頁創新的趨勢：JavaScript 生態系目前處於停滯期，而 CSS 則蓬勃發展。Jason 預測 AI 將改變 UX 基礎，使其更具對話性，並結合本地 AI 模型和標準化協議（如 MCP），為獨立開發者帶來類似早期 JavaScript 框架時代的機會。

🔒 Docker @ Black Hat 2025：CVE 漏洞應對之道​

Source: https://www.docker.com/blog/docker-black-hat-2025-secure-software-supply-chain/

• 在 Black Hat 2025 大會上，CVE 漏洞成為核心議題，業界正從被動掃描轉向主動在軟體供應鏈源頭消除安全負債。
• 前進方向包括：使用強化版映像 (Hardened Images)、符合法規的工具以及強大的生態系合作夥伴關係 (如 Docker 與 Wiz)。
• 會議指出六大安全主題，強調掃描不足以應對，需要「零 CVE」的起始點，並透過提供 Debian 和 Alpine 等不同發行版，以及靈活的客製化能力來滿足企業需求。
• Docker Hardened Images (DHI) 提供零 CVE 的基礎映像，並附帶 SLA、SBOM (軟體物料清單) 和簽名證明，消除安全性與易用性之間的權衡。
• 即使是新興的 AI 工作負載，也能受益於既有的容器安全模式（隔離、閘道控制、執行前驗證），DHI 作為 AI 系統的可信啟動平台至關重要。

🔗 大規模保障供應鏈安全：從 71 個重要開源專案做起​

Source: https://github.blog/open-source/maintainers/securing-the-supply-chain-at-scale-starting-with-71-important-open-source-projects/

• Log4j 零日漏洞事件後，凸顯了開源庫安全性對整個軟體供應鏈的巨大影響，促使 GitHub 於 2024 年 11 月啟動「GitHub 安全開源基金」（GitHub Secure Open Source Fund）。
• 該基金為維護者提供資金支援，參與為期三週的專案，內容包含安全教育、導師指導、工具、認證及安全意識社群等，旨在提升安全影響力、降低風險，並大規模保護軟體供應鏈。
• 前兩期專案已集合來自 71 個重要開源專案的 125 位維護者，取得了顯著成果：
  • 修復了 1,100 多個由 CodeQL 檢測到的漏洞。
  • 發布了 50 多個新的常見漏洞與暴露（CVE），保護下游依賴項。
  • 阻止了 92 個新機密洩漏，並檢測和解決了 176 個已洩漏的機密。
  • 80% 的專案啟用了三個或更多基於 GitHub 的安全功能，63% 的專案表示對 AI 和 MCP 安全有更好理解。
  • 維護者利用 GitHub Copilot 進行漏洞掃描、安全審計、定義和實施模糊測試策略等。
• 專案涵蓋了 AI/ML 框架（如 Ollama, AutoGPT）、前端/全端框架（如 Next.js, shadcn/ui）、Web 伺服器/網路/閘道（如 Node.js）、DevOps/建置工具（如 Turborepo）、安全框架/身份/合規工具（如 Log4j）、以及開發者工具/CLI 助手（如 Charset-Normalizer, nvm, JUnit）等多個關鍵領域。
• 該計劃的成功關鍵在於：資金支援結合時間限制的專注訓練、互動式編碼經驗以及建立一個以安全為重點的社群，促進了維護者之間的快速交流與協作。

加速 Docker 強化映像的 FedRAMP 合規性 🚀​

Source: https://www.docker.com/blog/fedramp-compliance-with-hardened-images/

• FedRAMP 合規挑戰： 聯邦風險與授權管理計畫 (FedRAMP) 合規成本高昂（45 萬至 200 萬美元以上），且需耗時 12 至 18 個月，這期間競爭對手可能已搶佔政府合約。企業需面對 NIST SP 800-53 中超過 400 項嚴格的安全控制要求。
• Docker 強化映像 (DHI) 解決方案： Docker 硬化映像提供自動化、可稽核的安全解決方案，旨在加速 FedRAMP 合規流程並降低維護成本。DHI 是一系列精簡的映像，持續更新以確保幾乎沒有已知的 CVE。
• FIPS 140 合規性： DHI 支援 FIPS 140 驗證的密碼學模組，預配置並經過測試，可確保正確功能。每個 FIPS 合規映像都附有簽名的證明，列出使用的 FIPS 驗證軟體及其 CMVP 認證和測試結果連結，支援 OpenSSL、Bouncy Castle 和 Go 等主要開源密碼學模組。
• STIG 強化映像： Docker 根據國防信息系統局 (DISA) 發布的通用作業系統 (GPOS) SRG，創建了客製化的容器 STIG。STIG 強化映像在安全建構過程中會使用 OpenSCAP 進行掃描，結果會作為簽名證明提供，其中包含易於查看的 STIG 合規分數，並支援輸出為 HTML 和 XCCDF 格式，便於稽核。
• 持續合規性：
  • 漏洞減少： DHI 起始攻擊面減少高達 95%（按包數量計算），持續更新以確保幾乎沒有已知 CVE，並掃描病毒和機密。
  • 漏洞檢測與修復： Docker 持續監控 CVE 來源，DHI 對嚴重/高風險漏洞的修復 SLA 為 7 天，中/低風險為 30 天，幫助滿足 FedRAMP 修復時限。提供 VEX (Vulnerability Exploitability eXchange) 證明來過濾不適用漏洞。
  • 供應鏈透明度： DHI 使用 SLSA Build Level 3 安全建構管道，確保建構可驗證性與防篡改。提供簽名證明和多種 SBOM 格式。
  • 稽核證據： DHI 證明符合 in-toto 證明標準，作為 provenance、資產管理、漏洞掃描及 FIPS 合規性的安全證據。

Rust 與 Java：為您的專案選擇正確的工具 💻​

Source: https://blog.jetbrains.com/rust/2025/08/01/rust-vs-java/

• 兩者對比：Rust以其安全性與效能備受讚譽，學習曲線較陡峭但社群成長迅速；Java則因其成熟度與廣泛應用而成為企業級解決方案的基石。Rust的用戶群在2024年達到約227萬開發者，而Java因其成熟且穩健的生態系仍吸引數千萬開發者。
• Rust的演進與核心理念：起源於2006年Mozilla的專案，於2015年發布1.0穩定版。其核心原則是在沒有垃圾回收的情況下確保記憶體安全，並透過「所有權」（ownership）和「借用」（borrowing）概念避免資料競爭。它杜絕了空指針解引用、懸空指針或緩衝區溢位等常見錯誤。
• Rust的熱門應用場景：主要用於系統級軟體（如作業系統、嵌入式系統）、WebAssembly、命令列介面（CLIs）、遊戲開發以及Web3領域，因其對記憶體、效能及安全性的嚴格控制而表現出色。
• Java的歷史與核心理念：可追溯到1991年，於1995年發布。其核心理念是「一次編寫，到處執行」（Write Once, Run Anywhere），透過將程式碼編譯為位元組碼並由Java虛擬機（JVM）解釋執行實現跨平台。Java也嚴格遵循物件導向程式設計（OOP）和DRY（Don’t Repeat Yourself）原則。
• Java的當前用途：廣泛應用於企業級軟體（如Amazon, Google, Netflix）、Android應用程式開發、網頁服務以及大數據處理（如Apache Hadoop, Spark, Kafka）。
• 技術差異：
  • 執行時：Java依賴JVM，提供自動垃圾回收和JIT編譯，易於跨平台開發但有記憶體和啟動時間開銷。Rust則提供最小化執行時（zero-cost abstractions），無垃圾回收器，提供精細的記憶體和速度控制。
  • 效能：Rust因無垃圾回收和對資源的精細控制，提供可預測的高速執行。Java依賴JIT編譯器在執行時優化效能，但可能因垃圾回收導致啟動時間較長和不可預測的暫停。
  • 記憶體管理：Java透過垃圾回收自動管理記憶體。Rust則在編譯時透過所有權和借用系統強制執行記憶體安全，無需執行時垃圾回收，提供高效能和可靠性。
  • 學習曲線：Java對初學者較為友好，尤其是熟悉物件導向程式設計的開發者。Rust的學習曲線較陡峭，其所有權概念和借用檢查器可能讓新手感到挫折，但提供了穩定高效的程式碼。
• 工具與生態系差異：
  • IDEs：Java有IntelliJ IDEA、Eclipse、NetBeans等成熟IDE。Rust在IDE支援上進步顯著，有RustRover，IntelliJ IDEA也透過插件支援Rust。
  • 建構系統與套件管理器：Rust擁有統一的工具鏈Cargo，集建構系統、套件管理器和依賴管理器於一身，使用簡單。Java則有多種建構工具，如Maven和Gradle，功能強大但配置較為複雜。
  • 除錯與分析工具：Java擁有數十年發展的成熟除錯和分析工具。Rust除錯依賴GDB或LLDB，但生態系仍在演進。
  • 開發者體驗：Java提供成熟的企業級開發體驗。Rust的體驗更現代、簡化且社群化，尤其適合注重安全性、效率和簡潔工具流程的開發者。
• 社群與採用差異：
  • 社群規模與活躍度：Java擁有龐大且成熟的社群。Rust的社群雖較新，但活躍且快速成長。
  • 函式庫與框架：Java擁有龐大的函式庫與框架生態系，如Spring、Jakarta EE。Rust的函式庫生態系仍在擴展，在系統程式設計、嵌入式開發、遊戲引擎等領域表現出色。
  • 行業採用與職缺趨勢：Java在企業軟體、Android和後端開發領域仍有高需求。Rust的職缺市場雖小但快速成長，被Mozilla、Dropbox、Amazon等公司用於效能或安全關鍵應用。
• 共同點：兩者都旨在防止常見的記憶體相關錯誤；提供強大的並行支援（Java使用傳統線程和java.util.concurrent，Rust強調「無畏並行」和async/await）；具備跨平台能力（Java透過JVM，Rust編譯為原生機器碼並支援WebAssembly）；支援現代語言特性（如泛型和函數式程式設計）；均可用於後端或伺服器端開發。
• 選擇建議：Rust適用於需要低層次控制、極致效能和記憶體安全的場景（如作業系統、設備驅動、高效能運算、WebAssembly）。Java則適用於大型企業應用，重視穩定性、可維護性和成熟生態系（如Android、網路服務、大數據處理）。
• 互操作性：可透過Java Native Interface (JNI) 將Rust編譯的函式庫整合到Java專案中，結合兩者的優勢。

⚙️ Upcoming Changes to JetBrains .NET Tools​

Source: https://blog.jetbrains.com/dotnet/2025/07/25/upcoming-changes-to-dotnet-tools/

• JetBrains 將依據用戶回饋和使用數據，對其 .NET 工具進行一系列精簡與調整，旨在提升工具效能並聚焦核心功能。
• 2025.2 版本更新重點：
  • dotCover 精簡化： 獨立的 dotCover 工具將被精簡以提升性能並降低複雜度。命令列運行器已現代化，指令整合至統一的 dotcover cover 介面，配置檔從 XML 轉換為簡潔的純文字參數檔。
  • 移除部分不常用過濾選項（方法/類別過濾器、檔案路徑過濾器、原始碼註解過濾器），並終止對舊版應用程式類型（如 IIS Express, WCF, WinRT, 外部 .NET 程序）的支援。
  • Rider 中 Mono 和 Unity 專案的程式碼覆蓋率分析終止： Rider 2025.2 起將不再提供 Mono 和 Unity 專案的覆蓋率分析，因使用率低且增加了技術債。待 Unity 遷移至 CoreCLR（預計 Unity 7 LTS 後）將恢復 Unity 專案的覆蓋率分析。
  • Visual Studio 的 TeamCity 擴充功能終止： 為了簡化工具鏈並專注於更具影響力的開發體驗，此擴充功能將被停用。
• 2025.3 版本更新重點：
  • Rider 中的動態程式分析 (DPA) 功能整合： DPA 將不再作為獨立工具，其分析能力將進一步整合到 Monitoring 工具中，並作為 dotUltimate 許可證的一部分提供（與 dotTrace 和 dotMemory 分析器相同）。
• 這些變更旨在釋放開發資源，以持續改進工具的性能、穩定性和核心功能。

用 Java 和 Spring AI 輕鬆建立 Generative AI 應用 🛠️🤖​

來源： Docker官方博客

這篇文章介紹如何使用 Java 和 Spring AI，不需學習 Python，便能快速構建本地的 GenAI 應用。重點在於整合 Docker Model Runner、Testcontainers 進行本地模型管理與測試，並利用 Grafana 進行觀測，提升開發與運維的效率。