Java 뉴스 정리: Spring AI, Spring Modulith 1.0, Testcontainers Desktop 소개
InfoQ 홈페이지 뉴스 Java 뉴스 요약: Spring AI, Spring Modulith 1.0, Testcontainers Desktop 소개
2023년 8월 28일 12분 분량의 읽기
~에 의해
마이클 레드리치
이번 주의 2023년 8월 21일 Java 요약에는 OpenJDK, JDK 22, JDK 21, Jakarta EE, BellSoft, Spring Modulith 1.0, Spring Boot, Spring Authorization Server, Spring Batch, Spring AI, Testcontainers, Open Liberty, Quarkus, MicroProfile의 뉴스가 포함되어 있습니다. 측정항목 및 원격 측정, Micronaut, Groovy, Tomcat, Grails, JHipster Lite, Vert.x Pinot 클라이언트, Yupiik Fusion 및 SpringOne 컨퍼런스.
Oracle의 Project Loom 설계자이자 기술 책임자인 Ron Pressler는 JEP 초안 8307341, JNI 사용 제한 준비를 도입했으며 제한된 메소드 사용과 함께 본질적으로 안전하지 않은 JNI(Java Native Interface)의 사용을 제한할 것을 제안했습니다. JDK 22의 최종 기능이 될 것으로 예상되는 FFM(외부 함수 및 메모리) API. JDK 22부터 시작하는 정렬 전략에는 FFM 사용자가 안전하지 않은 네이티브를 활성화하지 않는 한 JNI 사용에 대한 Java 런타임 표시 경고가 있습니다. 명령줄에서 액세스합니다. JDK 22 이후 릴리스에서는 JNI를 사용하면 경고 대신 예외가 발생할 것으로 예상됩니다.
JDK용 회귀 테스트 하네스 버전 7.3.1,jtreg가 출시되었으며 다음에 도입된 회귀를 수정하는 JDK에 통합할 준비가 되었습니다.jtreg 7.3은 Windows에서 기본 환경 변수를 올바르게 설정하는 것을 방해했습니다. 이번 릴리스에 대한 자세한 내용은 릴리스 노트에서 확인할 수 있습니다.
빌드 35는 JDK 21 초기 액세스 빌드의 현재 빌드로 남아 있습니다. 이 빌드에 대한 자세한 내용은 릴리스 노트에서 확인할 수 있습니다.
다양한 문제에 대한 수정 사항이 포함된 빌드 11의 업데이트를 포함하는 JDK 22 초기 액세스 빌드의 빌드 12도 지난 주에 출시되었습니다. 이 빌드에 대한 자세한 내용은 릴리스 노트에서 확인할 수 있습니다.
JDK 22 및 JDK 21의 경우 개발자는 Java 버그 데이터베이스를 통해 버그를 보고하는 것이 좋습니다.
Eclipse Foundation의 Jakarta EE 개발자 옹호자인 Ivar Grimstad는 주간 Hashtag Jakarta EE 블로그에서 Jakarta Data, Jakarta MVC 및 Jakarta NoSQL 사양을 Jakarta EE 11 플랫폼에 추가하려는 동의에 대한 투표 결과를 제공했습니다. 이 사양 중 하나만,자카르타 데이터, 지나 갔다.
자카르타 MVC 포함에 반대하거나 기권한 사람들의 의견:
이는 현재 일부 채택된 성숙한 사양이지만, 이를 필수로 만들기 전에 공급업체 측에서 더 많은 채택이 있어야 합니다. 이전에 다른 사람들이 언급했듯이 모든 프로필에 독립 실행형 사양으로 추가할 수 있으므로 지금은 누구도 이 기능을 사용하는 데 방해가 되지 않으며 향후 버전에 추가하려는 수요가 더 많이 발생합니다(또는 다음 버전 릴리스에 업데이트 이유를 제시합니다). 계획).
나는 이 일을 격려하고 앞으로도 계속되길 바랍니다. 플랫폼의 최종 채택을 기대합니다.
저는 이것이 플랫폼에 대한 흥미로운 추가라고 생각하며, 우리는 이미 그것을 즉시 사용할 수 있는 GlassFish에 추가했습니다. 그러나 우리는 몇 가지 우려 사항을 가지고 있습니다. 그 중에는 Jakarta MVC가 Jakarta REST를 기반으로 하는 반면, Jakarta EE의 기존 MVC 프레임워크는 Jakarta Servlet을 기반으로 한다는 사실도 있습니다. REST에 새로운 API를 기반으로 하면 Jakarta EE의 "HTTP 처리 API"가 핵심인지 더욱 혼란스러워집니다. 우리는 Jakarta REST를 기반으로 하는 플랫폼에 어떤 것이든 수용하기 전에 먼저 Jakarta Servlet과 Jakarta REST 사이에 공통 기반이 구축되는 것을 보고 싶습니다.
Jakarta NoSQL 포함에 반대하거나 기권한 사람들의 의견:
현재 아키텍처 설계에는 자카르타 플랫폼 릴리스에 대해 계획된 것보다 더 자주 업데이트가 필요한 것 같습니다. 이는 현재 플랫폼 외부에 유지해야 한다는 강력한 주장을 제시합니다. 또 다른 요구 사항은 Jakarta Data 및 Jakarta Config를 먼저 추가하는 것입니다. 일반적으로 NoSQL을 지원하는 것은 좋은 생각이므로 향후 변경될 수 있습니다.