Offcanvas

������JDK

“자바 플랫폼에 정적 이미지 도입” 프로젝트 레이든(Project Leyden) 시작

‘프로젝트 레이든(Project Leyden)’은 자바 플랫폼에 정적 이미지를 도입하여 느린 시작 및 성능 문제를 완화하고자 한다.  느린 시작, 최대 성능 도달까지 걸리는 시간, 큰 설치 공간 등 자바의 문제점을 해결하기 위한 프로젝트가 현재 진행 중이다. 2년 넘게 논의된 ‘프로젝트 레이든’은 JDK 및 자바 플랫폼에 정적 이미지를 도입하여 이러한 문제점을 해결할 계획이다.    지난 5월 20일(현지 시각) 오픈JDK 커뮤니티에서 오라클의 자바 플랫폼 그룹 수석 아키텍트 마크 라인홀드는 이 프로젝트를 시작한다고 밝혔다.  그에 따르면 정적 이미지는 애플리케이션에서 파생된 독립 실행형 프로그램으로, 해당 애플리케이션만 실행한다. 정적 이미지는 로드할 수 있는 클래스와 관련하여 폐쇄된 환경(closed world)이다. 런타임 시 이미지 외부에서 클래스를 로드할 수 없으며, 클래스를 동적으로 생성할 수도 없다. 이 폐쇄된 환경의 제약 조건은 특히 기존의 자바 프레임워크 및 라이브러리가 기반으로 하는 런타임 리플렉션과 클래스 로딩 기능에서 자바의 자연적 역동성을 엄격하게 제한한다.  라인홀드는 “모든 애플리케이션이 이 제약 조건에 적합한 것은 아니며, 모든 개발자가 이 제약 조건을 기꺼이 받아들이는 것도 아니다”라면서, “처음부터 폐쇄된 환경의 제약 조건을 채택하는 대신, 제약 조건의 스펙트럼을 탐색하고 이것이 어떤 최적화를 가능하게 하는지 알아내는 점진적인 접근 방식을 추진할 것”이라고 말했다.  그 결과 최적화는 폐쇄된 환경의 제약 조건보다 약할 수 있다. 하지만 (제약 조건이 약해) 최적화는 더 넓은 범위의 기존 코드에 적용될 수 있어 유용할 것이라고 그는 덧붙였다. 아울러 이 프로젝트는 핫스팟 JVM(HotSpot JVM), C2 컴파일러(C2 compiler), 애플리케이션 클래스-데이터 공유(application class-data sharing), 제이링크 코드 도구(jlink cod...

자바 플랫폼 정적 이미지 JDK 오픈JDK 프로젝트 레이든

2022.05.24

‘프로젝트 레이든(Project Leyden)’은 자바 플랫폼에 정적 이미지를 도입하여 느린 시작 및 성능 문제를 완화하고자 한다.  느린 시작, 최대 성능 도달까지 걸리는 시간, 큰 설치 공간 등 자바의 문제점을 해결하기 위한 프로젝트가 현재 진행 중이다. 2년 넘게 논의된 ‘프로젝트 레이든’은 JDK 및 자바 플랫폼에 정적 이미지를 도입하여 이러한 문제점을 해결할 계획이다.    지난 5월 20일(현지 시각) 오픈JDK 커뮤니티에서 오라클의 자바 플랫폼 그룹 수석 아키텍트 마크 라인홀드는 이 프로젝트를 시작한다고 밝혔다.  그에 따르면 정적 이미지는 애플리케이션에서 파생된 독립 실행형 프로그램으로, 해당 애플리케이션만 실행한다. 정적 이미지는 로드할 수 있는 클래스와 관련하여 폐쇄된 환경(closed world)이다. 런타임 시 이미지 외부에서 클래스를 로드할 수 없으며, 클래스를 동적으로 생성할 수도 없다. 이 폐쇄된 환경의 제약 조건은 특히 기존의 자바 프레임워크 및 라이브러리가 기반으로 하는 런타임 리플렉션과 클래스 로딩 기능에서 자바의 자연적 역동성을 엄격하게 제한한다.  라인홀드는 “모든 애플리케이션이 이 제약 조건에 적합한 것은 아니며, 모든 개발자가 이 제약 조건을 기꺼이 받아들이는 것도 아니다”라면서, “처음부터 폐쇄된 환경의 제약 조건을 채택하는 대신, 제약 조건의 스펙트럼을 탐색하고 이것이 어떤 최적화를 가능하게 하는지 알아내는 점진적인 접근 방식을 추진할 것”이라고 말했다.  그 결과 최적화는 폐쇄된 환경의 제약 조건보다 약할 수 있다. 하지만 (제약 조건이 약해) 최적화는 더 넓은 범위의 기존 코드에 적용될 수 있어 유용할 것이라고 그는 덧붙였다. 아울러 이 프로젝트는 핫스팟 JVM(HotSpot JVM), C2 컴파일러(C2 compiler), 애플리케이션 클래스-데이터 공유(application class-data sharing), 제이링크 코드 도구(jlink cod...

2022.05.24

“자바 동시성, 더 쉬워진다” 새 오픈JDK 제안 

오픈JDK(OpenJDK) 커뮤니티에서 인큐베이션 중인 새로운 제안 ‘구조화된 동시성(JEP 428: Structured Concurrency)’은 서로 다른 자바 스레드에서 실행되는 여러 작업을 단일 작업 단위로 처리한다.  현재 오픈JDK 커뮤니티에서 인큐베이팅하고 있는 계획으로 멀티스레드 프로그래밍이 더 쉬워질 예정이다. ‘구조화된 동시성’ 제안은 서로 다른 스레드에서 실행되는 여러 작업을 단일 작업 단위로 처리하는 라이브러리를 도입한다. 해당 제안에 따르면 새 라이브러리는 오류 처리 및 취소를 간소화하고, 안정성을 개선하며, 관찰 가능성을 향상시킨다.    이 제안의 목표는 멀티스레드 코드의 안정성과 관찰 가능성을 개선하는 것 그리고 취소 및 종료로 발생하는 일반적인 위험(예: 스레드 유출 및 취소 지연 등)을 제거할 수 있는 동시 프로그래밍 스타일을 촉진하는 것이다. 현시점에서 구조화된 동시성 제안은 특정 버전의 자바를 대상으로 하진 않는다.  제안에 따르면 구조화된 동시성은 단일 스레드 코드 개발자가 다뤄야 하는 가독성 및 유지관리를 위한 멀티스레드 프로그래밍 접근 방식이다. 이는 작업이 동시 하위 작업으로 분할되면 모두 같은 위치, 즉 작업의 코드 블록으로 돌아간다는 원칙을 따른다. 동일한 코드 블록으로 돌아가면 동시 하위 작업의 수명은 구문 블록으로 제한된다. 형제 하위 작업이 동일한 블록에 국한되기 때문에 하나의 단위로 추론하고 관리할 수 있다. 하위 작업은 결과를 기다리고 실패를 모니터링하는 작업(외부 블록의 코드)을 대신하여 작동한다.  단일 스레드 코드를 지원하는 구조화된 프로그래밍 기술과 마찬가지로 멀티스레드를 지원하는 구조화된 동시성은 2가지 아이디어에서 비롯된다. (1) 코드 블록을 통한 실행 흐름에서 잘 정의된 진입점 및 종료점 그리고 (2) 코드 중첩을 미러링하는 방식으로 작업 수명을 엄격하게 중첩하는 것이다. 또한 런타임에서 구조화된 동시성은 동일한 상위 작업이 가지고 있는 ...

자바 오픈JDK JEP 동시성

2022.05.20

오픈JDK(OpenJDK) 커뮤니티에서 인큐베이션 중인 새로운 제안 ‘구조화된 동시성(JEP 428: Structured Concurrency)’은 서로 다른 자바 스레드에서 실행되는 여러 작업을 단일 작업 단위로 처리한다.  현재 오픈JDK 커뮤니티에서 인큐베이팅하고 있는 계획으로 멀티스레드 프로그래밍이 더 쉬워질 예정이다. ‘구조화된 동시성’ 제안은 서로 다른 스레드에서 실행되는 여러 작업을 단일 작업 단위로 처리하는 라이브러리를 도입한다. 해당 제안에 따르면 새 라이브러리는 오류 처리 및 취소를 간소화하고, 안정성을 개선하며, 관찰 가능성을 향상시킨다.    이 제안의 목표는 멀티스레드 코드의 안정성과 관찰 가능성을 개선하는 것 그리고 취소 및 종료로 발생하는 일반적인 위험(예: 스레드 유출 및 취소 지연 등)을 제거할 수 있는 동시 프로그래밍 스타일을 촉진하는 것이다. 현시점에서 구조화된 동시성 제안은 특정 버전의 자바를 대상으로 하진 않는다.  제안에 따르면 구조화된 동시성은 단일 스레드 코드 개발자가 다뤄야 하는 가독성 및 유지관리를 위한 멀티스레드 프로그래밍 접근 방식이다. 이는 작업이 동시 하위 작업으로 분할되면 모두 같은 위치, 즉 작업의 코드 블록으로 돌아간다는 원칙을 따른다. 동일한 코드 블록으로 돌아가면 동시 하위 작업의 수명은 구문 블록으로 제한된다. 형제 하위 작업이 동일한 블록에 국한되기 때문에 하나의 단위로 추론하고 관리할 수 있다. 하위 작업은 결과를 기다리고 실패를 모니터링하는 작업(외부 블록의 코드)을 대신하여 작동한다.  단일 스레드 코드를 지원하는 구조화된 프로그래밍 기술과 마찬가지로 멀티스레드를 지원하는 구조화된 동시성은 2가지 아이디어에서 비롯된다. (1) 코드 블록을 통한 실행 흐름에서 잘 정의된 진입점 및 종료점 그리고 (2) 코드 중첩을 미러링하는 방식으로 작업 수명을 엄격하게 중첩하는 것이다. 또한 런타임에서 구조화된 동시성은 동일한 상위 작업이 가지고 있는 ...

2022.05.20

"오라클은 시들, 아마존은 상승세" 2022 자바 생태계 현황 보고서

뉴 렐릭(New Relic)의 ‘2022 자바 생태계 현황 보고서(2022 State of the Java Ecosystem)’에 따르면 오라클 자바(Oracle JDK) 사용률이 34%로 떨어졌고, 아마존은 22%로 증가했다.    미국의 애플리케이션 모니터링 회사 뉴 렐릭의 최신 보고서는 자바 시장에서 오라클의 점유율이 여전히 지배적이긴 하지만 오라클 자바의 인기가 불과 2년 전보다 절반 수준으로 떨어졌다고 밝혔다. 4월 26일(현지 시각) 공개된 이 보고서는 뉴 렐릭에 성능 데이터를 제공하는 수백만 개의 애플리케이션에서 수집한 데이터를 분석한 결과다.  2020년 오라클은 자바 시장의 약 75%를 차지하는 가장 인기 있는 공급업체였다. 물론 2022년에도 34.48%의 시장 점유율로 1위 자리를 지키긴 했지만 2년 전과 비교하면 (사용률이) 절반 수준으로 쪼그라들었다. 반면 아마존은 2020년 2.18%에서 올해 22.04%로 크게 성장해 오라클의 뒤를 쫓고 있다.  오라클이 2021년 9월 릴리즈된 JDK 17을 통해 개방적인 자세로 복귀하기 전, 오라클JDK 11 버전부터 ‘제한적인 라이선스’를 적용한다고 발표한 이후 오라클 바이너리의 인기가 떨어지고 있는 추세라고 보고서는 설명했다. 이클립스 어댑티움(11.48%), 아줄 시스템(8.17%), 레드햇(6.05%), 아이스티(5.38%), 우분투(2.91%), 벨소프트(2.5%)가 그 뒤를 이었다.  이 밖에 2022 자바 생태계 현황 보고서의 다른 결과는 아래와 같다.  • ‘자바 11’이 가장 일반적으로 사용되는 자바 버전이 됐다. 2018년 출시된 LTS 릴리즈인 자바 11은 현재 프로덕션 환경에 있는 애플리케이션의 48% 이상에서 사용되고 있다. 2020년의 11.11%에서 증가한 수치다. 자바 8은 46.45%로 2위를 차지했다. 자바 8은 2020년 84.48%의 시장 점유율을 기록한 바 있다. • 프로덕션 환경에 있는 애플리...

자바 오픈JDK 오라클 아마존

2022.04.29

뉴 렐릭(New Relic)의 ‘2022 자바 생태계 현황 보고서(2022 State of the Java Ecosystem)’에 따르면 오라클 자바(Oracle JDK) 사용률이 34%로 떨어졌고, 아마존은 22%로 증가했다.    미국의 애플리케이션 모니터링 회사 뉴 렐릭의 최신 보고서는 자바 시장에서 오라클의 점유율이 여전히 지배적이긴 하지만 오라클 자바의 인기가 불과 2년 전보다 절반 수준으로 떨어졌다고 밝혔다. 4월 26일(현지 시각) 공개된 이 보고서는 뉴 렐릭에 성능 데이터를 제공하는 수백만 개의 애플리케이션에서 수집한 데이터를 분석한 결과다.  2020년 오라클은 자바 시장의 약 75%를 차지하는 가장 인기 있는 공급업체였다. 물론 2022년에도 34.48%의 시장 점유율로 1위 자리를 지키긴 했지만 2년 전과 비교하면 (사용률이) 절반 수준으로 쪼그라들었다. 반면 아마존은 2020년 2.18%에서 올해 22.04%로 크게 성장해 오라클의 뒤를 쫓고 있다.  오라클이 2021년 9월 릴리즈된 JDK 17을 통해 개방적인 자세로 복귀하기 전, 오라클JDK 11 버전부터 ‘제한적인 라이선스’를 적용한다고 발표한 이후 오라클 바이너리의 인기가 떨어지고 있는 추세라고 보고서는 설명했다. 이클립스 어댑티움(11.48%), 아줄 시스템(8.17%), 레드햇(6.05%), 아이스티(5.38%), 우분투(2.91%), 벨소프트(2.5%)가 그 뒤를 이었다.  이 밖에 2022 자바 생태계 현황 보고서의 다른 결과는 아래와 같다.  • ‘자바 11’이 가장 일반적으로 사용되는 자바 버전이 됐다. 2018년 출시된 LTS 릴리즈인 자바 11은 현재 프로덕션 환경에 있는 애플리케이션의 48% 이상에서 사용되고 있다. 2020년의 11.11%에서 증가한 수치다. 자바 8은 46.45%로 2위를 차지했다. 자바 8은 2020년 84.48%의 시장 점유율을 기록한 바 있다. • 프로덕션 환경에 있는 애플리...

2022.04.29

“자바에 가상 스레드 가져온다”··· 새 오픈JDK 제안

하드웨어 자원을 효율적으로 사용하는 한편, 동시 프로그래밍을 훨씬 더 쉽게 만드는 것을 목표로 하는 새로운 개발 제안이 오픈JDK 커뮤니티에 제출됐다.  처리량이 많은 동시 애플리케이션을 작성, 유지관리, 모니터링하는 데 필요한 리소스를 ‘크게’ 줄이기 위한 자바용 가상 스레드가 제안됐다.    지난 11월 15일 게시된 오라클의 JEP 초안은 자바 표준 버전의 일부로 가상 스레드를 제안했다(프리뷰). 가상 스레드는 운영체제(OS) 스레드를 나타내는 자바의 플랫폼 스레드를 경량의 사용자-모드 스레드 구현으로 보완하여, 하드웨어를 효율적으로 사용하고 비용을 대폭 절감하고자 한다.  해당 제안서에 따르면 스레드는 트랜잭션 등의 동시성 단위를 나타내는 데 유용하다. 하지만 현재 자바의 스레드 구현은 각 자바 스레드에 OS 스레드를 사용하는데, OS 스레드는 (소켓보다) 희소하고, 비용도 많이 든다. 이는 최신 서버가 OS 스레드보다 훨씬 더 많은 동시 트랜잭션을 처리할 수 있다는 의미라고 개발팀은 설명했다.  처리량이 많은 서버 소프트웨어를 작성하는 개발자는 하드웨어를 (낭비하지 않고) 효율적으로 사용해야 했고, 따라서 트랜잭션 간에 스레드를 공유해야 했다.  이 작업은 각 트랜잭션에서 새 스레드 생성 비용을 절감하기 위해 다른 트랜잭션에 스레드를 대여하는 스레드 풀을 사용하여 수행됐다. 이것으로 충분하지 않다면  개발자는 I/O를 대기하는 트랜잭션 중간에도 스레드를 풀에 반환했다.  그 결과, 별도의 호환되지 않는 API 집합을 필요로 하는 비동기식 프로그래밍 방식이 생성되고, 문제 해결, 디버깅, 모니터링 및 프로파일링도 어려워진다. 가상 스레드는 OS 스레드를 차단하지 않는 java.lang.Thread의 사용자-모드 구현으로, 최적에 가까운 하드웨어 활용을 지원한다. 또한 이는 높은 처리량과 높은 수준의 동시성을 허용하며, 해당 프로그램은 자바 플랫폼 및 도구의 스레드 기반...

자바 가상 스레드 오픈JDK

2021.11.18

하드웨어 자원을 효율적으로 사용하는 한편, 동시 프로그래밍을 훨씬 더 쉽게 만드는 것을 목표로 하는 새로운 개발 제안이 오픈JDK 커뮤니티에 제출됐다.  처리량이 많은 동시 애플리케이션을 작성, 유지관리, 모니터링하는 데 필요한 리소스를 ‘크게’ 줄이기 위한 자바용 가상 스레드가 제안됐다.    지난 11월 15일 게시된 오라클의 JEP 초안은 자바 표준 버전의 일부로 가상 스레드를 제안했다(프리뷰). 가상 스레드는 운영체제(OS) 스레드를 나타내는 자바의 플랫폼 스레드를 경량의 사용자-모드 스레드 구현으로 보완하여, 하드웨어를 효율적으로 사용하고 비용을 대폭 절감하고자 한다.  해당 제안서에 따르면 스레드는 트랜잭션 등의 동시성 단위를 나타내는 데 유용하다. 하지만 현재 자바의 스레드 구현은 각 자바 스레드에 OS 스레드를 사용하는데, OS 스레드는 (소켓보다) 희소하고, 비용도 많이 든다. 이는 최신 서버가 OS 스레드보다 훨씬 더 많은 동시 트랜잭션을 처리할 수 있다는 의미라고 개발팀은 설명했다.  처리량이 많은 서버 소프트웨어를 작성하는 개발자는 하드웨어를 (낭비하지 않고) 효율적으로 사용해야 했고, 따라서 트랜잭션 간에 스레드를 공유해야 했다.  이 작업은 각 트랜잭션에서 새 스레드 생성 비용을 절감하기 위해 다른 트랜잭션에 스레드를 대여하는 스레드 풀을 사용하여 수행됐다. 이것으로 충분하지 않다면  개발자는 I/O를 대기하는 트랜잭션 중간에도 스레드를 풀에 반환했다.  그 결과, 별도의 호환되지 않는 API 집합을 필요로 하는 비동기식 프로그래밍 방식이 생성되고, 문제 해결, 디버깅, 모니터링 및 프로파일링도 어려워진다. 가상 스레드는 OS 스레드를 차단하지 않는 java.lang.Thread의 사용자-모드 구현으로, 최적에 가까운 하드웨어 활용을 지원한다. 또한 이는 높은 처리량과 높은 수준의 동시성을 허용하며, 해당 프로그램은 자바 플랫폼 및 도구의 스레드 기반...

2021.11.18

“자바에 범용 제네릭 가져온다”··· 오픈JKD 프로젝트 제안

‘범용 제네릭(universal generics)’은 자바 유형 변수가 기본형과 참조형을 포괄하도록 하여 다른 유형에서 코드를 쉽게 확장하거나 재사용할 수 있도록 지원한다.  오픈JDK 제안에 따르면 자바가 (이 언어를) 더 쉽게 사용할 수 있도록 하는 범용 제네릭을 지원할 계획이다.    범용 제네릭은 오픈JDK 커뮤니티에 올라온 3가지 제안을 통해 제공될 예정이다. 오라클은 이 제안들이 클래스의 유연성과 기본형의 성능을 결합해 자바 언어 및 JVM을 크게 변화시킬 것이라고 말했다. 3가지 JEP(JDK Enhancement Proposals)는 각각 서로 다른 기능을 지원하지만 앞서 언급한 이점을 얻으려면 세 가지 모두가 필요하다.  이중 핵심은 지난 2월 작성돼 10월 29일 업데이트된 JEP다. 해당 JEP의 내용은 다음과 같다. 자바 유형 변수가 두 유형에 적용될 수 있도록 해 일반 코드에서 참조 및 기본값 유형 처리를 통합한다는 것이다.  사용자-선언 기본 객체로 자바 객체 모델을 개선한다는 내용의 2번째 JEP는 전제 조건으로 사용된다. 세 번째 JEP는 기본형(int, double 등)을 객체와 통합한다. 이 밖에 추가 JEP를 통해 표준 라이브러리 업데이트를 통한 null 경고 해결, 라이브러리 전문화, JVM에서의 일반 API 런타임 특수화 등을 도입할 계획이다.  범용 제네릭 계획은 사용자-정의 기본형에서 바로 작동할 수 있도록 제네릭 API가 기본값 유형을 지원하게끔 권장하고 있다. 참조 유형도 지원된다. 이는 궁극적으로 자바 제네릭의 기본 동작이어야 하므로 기본값 유형이 자바 생태계에 완전히 참여할 수 있다고 제안서는 명시하고 있다.  자바에 범용 제네릭이 지원될 시기는 언급되지 않았다. 이를 구현하기까지는 몇 년이 걸릴 전망이다.  범용 제네릭은 플랫폼의 기존 제네릭 기능도 확장할 수 있다. 2004년에 도입된 자바 2 플랫폼 스탠다드 에디션 5.0은...

자바 오픈JDK 범용 제네릭

2021.11.11

‘범용 제네릭(universal generics)’은 자바 유형 변수가 기본형과 참조형을 포괄하도록 하여 다른 유형에서 코드를 쉽게 확장하거나 재사용할 수 있도록 지원한다.  오픈JDK 제안에 따르면 자바가 (이 언어를) 더 쉽게 사용할 수 있도록 하는 범용 제네릭을 지원할 계획이다.    범용 제네릭은 오픈JDK 커뮤니티에 올라온 3가지 제안을 통해 제공될 예정이다. 오라클은 이 제안들이 클래스의 유연성과 기본형의 성능을 결합해 자바 언어 및 JVM을 크게 변화시킬 것이라고 말했다. 3가지 JEP(JDK Enhancement Proposals)는 각각 서로 다른 기능을 지원하지만 앞서 언급한 이점을 얻으려면 세 가지 모두가 필요하다.  이중 핵심은 지난 2월 작성돼 10월 29일 업데이트된 JEP다. 해당 JEP의 내용은 다음과 같다. 자바 유형 변수가 두 유형에 적용될 수 있도록 해 일반 코드에서 참조 및 기본값 유형 처리를 통합한다는 것이다.  사용자-선언 기본 객체로 자바 객체 모델을 개선한다는 내용의 2번째 JEP는 전제 조건으로 사용된다. 세 번째 JEP는 기본형(int, double 등)을 객체와 통합한다. 이 밖에 추가 JEP를 통해 표준 라이브러리 업데이트를 통한 null 경고 해결, 라이브러리 전문화, JVM에서의 일반 API 런타임 특수화 등을 도입할 계획이다.  범용 제네릭 계획은 사용자-정의 기본형에서 바로 작동할 수 있도록 제네릭 API가 기본값 유형을 지원하게끔 권장하고 있다. 참조 유형도 지원된다. 이는 궁극적으로 자바 제네릭의 기본 동작이어야 하므로 기본값 유형이 자바 생태계에 완전히 참여할 수 있다고 제안서는 명시하고 있다.  자바에 범용 제네릭이 지원될 시기는 언급되지 않았다. 이를 구현하기까지는 몇 년이 걸릴 전망이다.  범용 제네릭은 플랫폼의 기존 제네릭 기능도 확장할 수 있다. 2004년에 도입된 자바 2 플랫폼 스탠다드 에디션 5.0은...

2021.11.11

오픈JDK, 새 제안 공개··· "호스트 이름 및 주소 확인을 위한 SPI 정의"

오픈JDK(OpenJDK) 커뮤니티가 호스트 이름 및 주소 확인을 위한 SPI(Service Provider Interface)를 개발 중이다. 자바 애플리케이션에서 인터넷 주소 지정을 세밀하게 제어할 수 있도록 하는 것이 목표다.    현재 검토 중인 JEP(JDK Enhancement Proposal)에 따르면 호스트 이름 확인을 위한 SPI가 개발될 예정이고, 이를 통해 java.net.InetAddress는 운영 플랫폼의 내장 리졸버 이외의 리졸버도 사용할 수 있다.  java.net.InetAddress API는 호스트 이름을 IP(Internet Protocol) 주소로 확인하고 그 반대의 경우도 마찬가지다. 현재 API는 운영체제의 네이티브 리졸버를 사용하며, 일반적으로 로컬 호스트 파일과 DNS(Domain Name System)의 조합을 사용하도록 구성돼 있다. 이름 및 주소 확인을 위한 SPI를 정의하는 목표는 다음과 같다.  • 사용자 정의: 리졸버 API를 사용하면 프레임워크와 애플리케이션이 확인 결과를 세밀하게 제어할 수 있고, 기존 라이브러리를 사용자 정의 리졸버로 개조할 수 있다.  • ‘프로젝트 룸(Project Loom)’: InetAddress API를 사용한 확인 작업은 현재 OS 호출에서 차단된다. 이는 룸(Loom)의 사용자 모드 가상 스레드에 관한 문제다. 확인 작업이 완료되길 기다리는 동안 기본 플랫폼 스레드가 다른 가상 스레드를 서비스하는 것을 막기 때문이다. 대체 리졸버는 DNS 클라이언트 프로토콜을 차단 없이 직접 구현할 수 있다.  • 새로운 네트워크 프로토콜: 리졸버 API를 사용하면 QUIC(Quick UDP Internet Connections)를 통한 DNS, TLS(Transport Layer Security), HTTPS와 같은 새로운 확인 프로토콜을 원활하게 통합할 수 있다.  • 테스트: 프로토타입 및 테스트에서 호스트 이름...

오픈JDK 자바 오라클

2021.09.10

오픈JDK(OpenJDK) 커뮤니티가 호스트 이름 및 주소 확인을 위한 SPI(Service Provider Interface)를 개발 중이다. 자바 애플리케이션에서 인터넷 주소 지정을 세밀하게 제어할 수 있도록 하는 것이 목표다.    현재 검토 중인 JEP(JDK Enhancement Proposal)에 따르면 호스트 이름 확인을 위한 SPI가 개발될 예정이고, 이를 통해 java.net.InetAddress는 운영 플랫폼의 내장 리졸버 이외의 리졸버도 사용할 수 있다.  java.net.InetAddress API는 호스트 이름을 IP(Internet Protocol) 주소로 확인하고 그 반대의 경우도 마찬가지다. 현재 API는 운영체제의 네이티브 리졸버를 사용하며, 일반적으로 로컬 호스트 파일과 DNS(Domain Name System)의 조합을 사용하도록 구성돼 있다. 이름 및 주소 확인을 위한 SPI를 정의하는 목표는 다음과 같다.  • 사용자 정의: 리졸버 API를 사용하면 프레임워크와 애플리케이션이 확인 결과를 세밀하게 제어할 수 있고, 기존 라이브러리를 사용자 정의 리졸버로 개조할 수 있다.  • ‘프로젝트 룸(Project Loom)’: InetAddress API를 사용한 확인 작업은 현재 OS 호출에서 차단된다. 이는 룸(Loom)의 사용자 모드 가상 스레드에 관한 문제다. 확인 작업이 완료되길 기다리는 동안 기본 플랫폼 스레드가 다른 가상 스레드를 서비스하는 것을 막기 때문이다. 대체 리졸버는 DNS 클라이언트 프로토콜을 차단 없이 직접 구현할 수 있다.  • 새로운 네트워크 프로토콜: 리졸버 API를 사용하면 QUIC(Quick UDP Internet Connections)를 통한 DNS, TLS(Transport Layer Security), HTTPS와 같은 새로운 확인 프로토콜을 원활하게 통합할 수 있다.  • 테스트: 프로토타입 및 테스트에서 호스트 이름...

2021.09.10

레코드 및 배열 패턴 外··· 구체화되는 ‘자바 18’ 미리보기

출시까지 아직 7개월가량 남았지만 ‘자바 18’이 구체화되기 시작했다. 지금까지 레코드 및 배열 패턴 그리고 문자 집합에 관한 개발 제안이 오픈JDK 커뮤니티에서 제기됐다.   오픈 JDK 커뮤니티의 ‘JDK(Java Development Kit) 18’ 페이지에 공식 기능이 나열돼 있는 건 아니지만 자바 기술의 JEP(JDK Enhancement Proposal) 인덱스에 자바 18용으로 제안된 두 가지 기능이 언급돼 있다. 그 내용은 다음과 같다.  • 레코드 패턴 및 배열 패턴(프리뷰): 레코드 패턴, 배열 패턴 및 유형 패턴(JEP 394)을 중첩해 패턴 매칭의 표현성과 유용성을 크게 향상시킬 수 있다. 제안서에 따르면 목표는 패턴 매칭을 확장해 정교하고 구성 가능한 데이터 쿼리를 표현하는 것 그리고 유형 패턴의 구문이나 의미를 변경하지 않는 것이다.  • 표준 자바 API의 기본 문자 집합으로 UTF-8 지정: 이 변경을 통해 기본 문자 집합을 사용하는 API는 모든 구현, 운영체제, 로케일 및 구성에서 일관되게 작동한다. 목표는 코드가 기본 문자 집합을 사용할 때 자바 프로그램을 예측할 수 있고 이식할 수 있도록 만드는 것, 표준 API가 기본 문자 집합을 사용하는 위치를 명확하게 하는 것, 콘솔 I/O를 제외한 표준 자바 API 전체에서 UTF-8로 표준화하는 것이다. 새로운 자바 표준 또는 JDK 특정 API를 정의하는 것이 목표는 아니라고 제안서는 덧붙였다.   한편 표준 자바의 6개월 릴리즈 주기에 따르면 ‘자바 18’은 2022년 3월 발표될 계획이다. JDK 18에서 예상되는 또 다른 기능은 (오는 9월 프로덕션 릴리즈로 출시될) JDK 17 릴리즈에서 프리뷰로 공개된 스위치 표현식 및 명령문에 관한 패턴 일치다. 또 JDK 17에서 인큐베이터 단계에 있는 외부 기능 및 메모리 API도 포함된다.  현재 릴리즈 캔디데이트인 JDK 17은 (출시 이후) 장기 지원(LTS) 릴리즈로 설정...

자바 오라클 자바 18 오픈JDK

2021.08.23

출시까지 아직 7개월가량 남았지만 ‘자바 18’이 구체화되기 시작했다. 지금까지 레코드 및 배열 패턴 그리고 문자 집합에 관한 개발 제안이 오픈JDK 커뮤니티에서 제기됐다.   오픈 JDK 커뮤니티의 ‘JDK(Java Development Kit) 18’ 페이지에 공식 기능이 나열돼 있는 건 아니지만 자바 기술의 JEP(JDK Enhancement Proposal) 인덱스에 자바 18용으로 제안된 두 가지 기능이 언급돼 있다. 그 내용은 다음과 같다.  • 레코드 패턴 및 배열 패턴(프리뷰): 레코드 패턴, 배열 패턴 및 유형 패턴(JEP 394)을 중첩해 패턴 매칭의 표현성과 유용성을 크게 향상시킬 수 있다. 제안서에 따르면 목표는 패턴 매칭을 확장해 정교하고 구성 가능한 데이터 쿼리를 표현하는 것 그리고 유형 패턴의 구문이나 의미를 변경하지 않는 것이다.  • 표준 자바 API의 기본 문자 집합으로 UTF-8 지정: 이 변경을 통해 기본 문자 집합을 사용하는 API는 모든 구현, 운영체제, 로케일 및 구성에서 일관되게 작동한다. 목표는 코드가 기본 문자 집합을 사용할 때 자바 프로그램을 예측할 수 있고 이식할 수 있도록 만드는 것, 표준 API가 기본 문자 집합을 사용하는 위치를 명확하게 하는 것, 콘솔 I/O를 제외한 표준 자바 API 전체에서 UTF-8로 표준화하는 것이다. 새로운 자바 표준 또는 JDK 특정 API를 정의하는 것이 목표는 아니라고 제안서는 덧붙였다.   한편 표준 자바의 6개월 릴리즈 주기에 따르면 ‘자바 18’은 2022년 3월 발표될 계획이다. JDK 18에서 예상되는 또 다른 기능은 (오는 9월 프로덕션 릴리즈로 출시될) JDK 17 릴리즈에서 프리뷰로 공개된 스위치 표현식 및 명령문에 관한 패턴 일치다. 또 JDK 17에서 인큐베이터 단계에 있는 외부 기능 및 메모리 API도 포함된다.  현재 릴리즈 캔디데이트인 JDK 17은 (출시 이후) 장기 지원(LTS) 릴리즈로 설정...

2021.08.23

“자바 상태 API로 앱 시작 속도 높인다”··· 새 오픈JDK 프로젝트 제안

자바 런타임의 ‘상태(state)’를 저장해 인스턴스를 빠르게 시작하는 것을 목표로 하는 새로운 개발 제안이 오픈JDK(OpenJDK) 커뮤니티에서 제기됐다. 제안서에 따르면 이를 통해 자바 애플리케이션의 긴 시작 시간을 단축할 수 있다.    자바 소프트웨어 제공업체 아줄(Azul)의 선임 소프트웨어 엔지니어 안톤 코즐로프가 오픈JDK 커뮤니티에 제안한 ‘CRaC(Coordinated Restore at Checkpoint)’ 프로젝트는 애플리케이션과 런타임 간의 조정을 통해 상태를 저장하고 복원하는 것을 목표로 한다. 또한 제안서는 자바 런타임이 가상머신 스냅샷, 컨테이너 스냅샷, 리눅스의 CRIU(Checkpoint/Restore In Userspace) 프로젝트 등 상태를 저장하는 여러 방법을 지원하도록 할 것이라고 전했다.  자바 런타임의 상태(스냅샷, 체크포인트)를 저장해 자바 애플리케이션의 긴 시작 시간과 워밍업을 줄일 수 있다는 게 제안서의 설명이다. 저장된 상태가 인스턴스를 빠르게 시작(복원)하는 데 사용된다.  한편 상태를 저장한 후 실행 환경이 변경될 수 있는 등의 몇 가지 문제가 있다고 제안서는 밝혔다. 여러 인스턴스가 저장된 상태에서 동시에 시작되는 경우 고유성(uniqueness)을 확보해야 하고 실행이 어느 시점에서 분산돼야 하는 것도 또 다른 문제라고 덧붙였다.  제안서는 이러한 문제를 해결하는 실질적인 방법은 자바 애플리케이션이 상태를 저장하고 복원하는 시기를 인식하도록 하는 것이라고 말했다. 그렇게 되면 애플리케이션이 환경 변화를 처리할 수 있고, 해당 환경에서 고유성을 확보할 수도 있다.  이어서 제안서는 상태가 복원되지 않거나 혹은 복원 후에 제대로 작동하지 않을 경우 상태를 저장하지 않도록 API 및 런타임에서 안전 검사(safety checks)를 검토하고 있다고 덧붙였다.  API는 JEP(JDK Enhancement Proposal) 프로세스에...

자바 오픈JDK

2021.07.22

자바 런타임의 ‘상태(state)’를 저장해 인스턴스를 빠르게 시작하는 것을 목표로 하는 새로운 개발 제안이 오픈JDK(OpenJDK) 커뮤니티에서 제기됐다. 제안서에 따르면 이를 통해 자바 애플리케이션의 긴 시작 시간을 단축할 수 있다.    자바 소프트웨어 제공업체 아줄(Azul)의 선임 소프트웨어 엔지니어 안톤 코즐로프가 오픈JDK 커뮤니티에 제안한 ‘CRaC(Coordinated Restore at Checkpoint)’ 프로젝트는 애플리케이션과 런타임 간의 조정을 통해 상태를 저장하고 복원하는 것을 목표로 한다. 또한 제안서는 자바 런타임이 가상머신 스냅샷, 컨테이너 스냅샷, 리눅스의 CRIU(Checkpoint/Restore In Userspace) 프로젝트 등 상태를 저장하는 여러 방법을 지원하도록 할 것이라고 전했다.  자바 런타임의 상태(스냅샷, 체크포인트)를 저장해 자바 애플리케이션의 긴 시작 시간과 워밍업을 줄일 수 있다는 게 제안서의 설명이다. 저장된 상태가 인스턴스를 빠르게 시작(복원)하는 데 사용된다.  한편 상태를 저장한 후 실행 환경이 변경될 수 있는 등의 몇 가지 문제가 있다고 제안서는 밝혔다. 여러 인스턴스가 저장된 상태에서 동시에 시작되는 경우 고유성(uniqueness)을 확보해야 하고 실행이 어느 시점에서 분산돼야 하는 것도 또 다른 문제라고 덧붙였다.  제안서는 이러한 문제를 해결하는 실질적인 방법은 자바 애플리케이션이 상태를 저장하고 복원하는 시기를 인식하도록 하는 것이라고 말했다. 그렇게 되면 애플리케이션이 환경 변화를 처리할 수 있고, 해당 환경에서 고유성을 확보할 수도 있다.  이어서 제안서는 상태가 복원되지 않거나 혹은 복원 후에 제대로 작동하지 않을 경우 상태를 저장하지 않도록 API 및 런타임에서 안전 검사(safety checks)를 검토하고 있다고 덧붙였다.  API는 JEP(JDK Enhancement Proposal) 프로세스에...

2021.07.22

오픈JDK 커뮤니티, 새 제안 공개··· “자바 패턴 매칭 개선한다” 

자바에서 패턴 매칭의 표현력을 개선하는 것 그리고 데이터 지향 쿼리를 활성화하는 것을 목표로 하는 2가지 개발 제안서 초안이 오픈JDK 커뮤니티에서 제기됐다.  자바 프로그래밍에서 레코드 패턴과 배열 패턴 그리고 스위치 표현식 및 구문의 패턴 매칭을 개선하는 기능이 제안됐다. 하지만 이 기능들이 언제 지원될지는 아직 정해지진 않았다.    지난 3월 23일 온라인 프레젠테이션에서 오라클의 기술 부문 컨설팅 담당 개빈 비어맨이 2가지 오픈 JDK 프로젝트 제안을 공개하면서 이러한 기능들을 언급했다. 이들은 앞으로 출시 예정인 (하지만 정확하게 결정되진 않은) 자바 릴리즈에 프리뷰 단계로 포함될 예정이다. 올해 9월로 예정된 JDK 17 릴리즈에 포함될 것으로 예상되고 있다.  제안서 초안에 따르면 자바에서 유형 패턴(자바16부터 지원)과 함께, 레코드 패턴 및 배열 패턴을 지원하면 패턴 매칭의 표현력과 효용성이 크게 향상되며 더욱더 정교하고 구성 가능한 데이터 쿼리를 활성화할 수 있다. 레코드 패턴, 배열 패턴, 유형 패턴은 패턴 내의 패턴처럼 중첩될 수 있다. 유형 패턴의 구문 또는 의미는 변경되지 않는다고 제안서는 덧붙였다.  패턴 매칭은 프로그램의 공통 로직, 즉 객체에서 구성 요소의 조건부 추출을 허용하는 메커니즘이다. 해당 제안서는 지난 3월 16일에 발표된 JDK 16에서 Instanceof 연산자가 유형 패턴을 취하고 패턴 매칭을 수행하도록 확장됐다고 설명했다. 이번 레코드 패턴 및 배열 패턴 제안은 Instanceof의 패턴 매칭(JEP 394)을 기반으로 한다.  한편 스위치에 대한 패턴 매칭을 제기한 제안서 초안에 따르면 이를 사용해 각각 특정 작업이 있는 여러 패턴에 대해 표현식을 테스트할 수 있으므로 복잡한 데이터 지향 쿼리를 안전하고 간결하게 표현할 수 있다.  이 제안의 목표는 스위치 패턴이 케이스 레이블에 표시되도록 하고 원하는 경우 널-호스틸리티(null-ho...

자바 오픈JDK 패턴 매칭 자바 17

2021.03.25

자바에서 패턴 매칭의 표현력을 개선하는 것 그리고 데이터 지향 쿼리를 활성화하는 것을 목표로 하는 2가지 개발 제안서 초안이 오픈JDK 커뮤니티에서 제기됐다.  자바 프로그래밍에서 레코드 패턴과 배열 패턴 그리고 스위치 표현식 및 구문의 패턴 매칭을 개선하는 기능이 제안됐다. 하지만 이 기능들이 언제 지원될지는 아직 정해지진 않았다.    지난 3월 23일 온라인 프레젠테이션에서 오라클의 기술 부문 컨설팅 담당 개빈 비어맨이 2가지 오픈 JDK 프로젝트 제안을 공개하면서 이러한 기능들을 언급했다. 이들은 앞으로 출시 예정인 (하지만 정확하게 결정되진 않은) 자바 릴리즈에 프리뷰 단계로 포함될 예정이다. 올해 9월로 예정된 JDK 17 릴리즈에 포함될 것으로 예상되고 있다.  제안서 초안에 따르면 자바에서 유형 패턴(자바16부터 지원)과 함께, 레코드 패턴 및 배열 패턴을 지원하면 패턴 매칭의 표현력과 효용성이 크게 향상되며 더욱더 정교하고 구성 가능한 데이터 쿼리를 활성화할 수 있다. 레코드 패턴, 배열 패턴, 유형 패턴은 패턴 내의 패턴처럼 중첩될 수 있다. 유형 패턴의 구문 또는 의미는 변경되지 않는다고 제안서는 덧붙였다.  패턴 매칭은 프로그램의 공통 로직, 즉 객체에서 구성 요소의 조건부 추출을 허용하는 메커니즘이다. 해당 제안서는 지난 3월 16일에 발표된 JDK 16에서 Instanceof 연산자가 유형 패턴을 취하고 패턴 매칭을 수행하도록 확장됐다고 설명했다. 이번 레코드 패턴 및 배열 패턴 제안은 Instanceof의 패턴 매칭(JEP 394)을 기반으로 한다.  한편 스위치에 대한 패턴 매칭을 제기한 제안서 초안에 따르면 이를 사용해 각각 특정 작업이 있는 여러 패턴에 대해 표현식을 테스트할 수 있으므로 복잡한 데이터 지향 쿼리를 안전하고 간결하게 표현할 수 있다.  이 제안의 목표는 스위치 패턴이 케이스 레이블에 표시되도록 하고 원하는 경우 널-호스틸리티(null-ho...

2021.03.25

“자바 객체 헤더 줄인다”··· 새 오픈JDK 프로젝트 제안 

자바 객체 헤더를 절반 이상 축소하는 것을 목표로 하는 새로운 개발 제안이 오픈JKD 오픈소스 자바 커뮤니티에서 제기됐다. 제안서에 따르면 이를 통해 모든 자바 워크로드에서 메모리 및 CPU 사용량을 줄일 수 있다.    지난 3월 9일(현지 시각) 게시된 새 개발 제안은 자바가 더 작은 객체 헤더를 얻을 수 있고 따라서 메모리 사용량을 개선할 수 있다는 게 주요 내용이다.  ‘프로젝트 릴리퍼트(Project Lilliput)’로 명명된 이 개발 제안을 올린 레드햇(RedHat)의 수석 소프트웨어 엔지니어 로만 켄케는 객체 헤더를 64bit로 줄이는 방법을 모색하고자 한다고 밝혔다.  현재 64bit 핫스팟(HotSpot) VM에서 자바 객체는 128bit 객체 헤더, 64bit 다목적 헤더 단어, 64bit 클래스 포인터를 갖는다. 켄케는 평균 객체 크기가 5~6단어인 경우 현재 객체 헤더 크기가 중요하다고 설명한다. 헤더 크기를 축소하면 메모리 압박이 크게 감소돼 대규모 인-메모리 데이터베이스이든 아니면 작은 컨테이너화된 애플리케이션이든 상관없이 모든 자바 워크로드에서 전체 CPU 및 메모리 사용량을 줄일 수 있기 때문이다. 해당 제안서에서 언급한 프로젝트 릴리퍼트의 구체적인 이점은 다음과 같다.  • 힙(heap) 사용량 감소  • 더 높은 객체 할당 비율  • 가비지 수집 활동 감소 • 객체 패킹 강화 프로젝트 릴리퍼트의 또 다른 목표는 헤더 레이아웃을 더 유연하게 만드는 것, 그리고 비트(bit) 사용 방법에 관한 빌드 타임(또는 런타임) 구성을 허용하는 것이다. 이 밖에 객체 헤더를 64bit로 줄이는 것에서 나아가 32bit로 줄이는 것도 추가적인 목표라고 그는 전했다.  한편 켄케는 객체 헤더가 객체의 잠금 상태를 표시하고, 가비지 컬렉션에서 각 객체의 살아남은 횟수(Age)를 추적하며, ID 해시코드 및 유형 정보를 저장하는 등의 목적으로 사용(및 오버로드)...

자바 오픈JDK 오픈소스 커뮤니티 개발 제안 자바 객체 헤더 자바 워크로드 메모리 CPU

2021.03.12

자바 객체 헤더를 절반 이상 축소하는 것을 목표로 하는 새로운 개발 제안이 오픈JKD 오픈소스 자바 커뮤니티에서 제기됐다. 제안서에 따르면 이를 통해 모든 자바 워크로드에서 메모리 및 CPU 사용량을 줄일 수 있다.    지난 3월 9일(현지 시각) 게시된 새 개발 제안은 자바가 더 작은 객체 헤더를 얻을 수 있고 따라서 메모리 사용량을 개선할 수 있다는 게 주요 내용이다.  ‘프로젝트 릴리퍼트(Project Lilliput)’로 명명된 이 개발 제안을 올린 레드햇(RedHat)의 수석 소프트웨어 엔지니어 로만 켄케는 객체 헤더를 64bit로 줄이는 방법을 모색하고자 한다고 밝혔다.  현재 64bit 핫스팟(HotSpot) VM에서 자바 객체는 128bit 객체 헤더, 64bit 다목적 헤더 단어, 64bit 클래스 포인터를 갖는다. 켄케는 평균 객체 크기가 5~6단어인 경우 현재 객체 헤더 크기가 중요하다고 설명한다. 헤더 크기를 축소하면 메모리 압박이 크게 감소돼 대규모 인-메모리 데이터베이스이든 아니면 작은 컨테이너화된 애플리케이션이든 상관없이 모든 자바 워크로드에서 전체 CPU 및 메모리 사용량을 줄일 수 있기 때문이다. 해당 제안서에서 언급한 프로젝트 릴리퍼트의 구체적인 이점은 다음과 같다.  • 힙(heap) 사용량 감소  • 더 높은 객체 할당 비율  • 가비지 수집 활동 감소 • 객체 패킹 강화 프로젝트 릴리퍼트의 또 다른 목표는 헤더 레이아웃을 더 유연하게 만드는 것, 그리고 비트(bit) 사용 방법에 관한 빌드 타임(또는 런타임) 구성을 허용하는 것이다. 이 밖에 객체 헤더를 64bit로 줄이는 것에서 나아가 32bit로 줄이는 것도 추가적인 목표라고 그는 전했다.  한편 켄케는 객체 헤더가 객체의 잠금 상태를 표시하고, 가비지 컬렉션에서 각 객체의 살아남은 횟수(Age)를 추적하며, ID 해시코드 및 유형 정보를 저장하는 등의 목적으로 사용(및 오버로드)...

2021.03.12

서서히 구체화되는 ‘자바 17’··· “향상된 PRNG 지원”

아직 9월은 아니지만 ‘자바 17(Java 17)’이 서서히 구체화되기 시작했다. 표준 자바로의 업그레이드를 목표로, 유사 난수 생성기(Pseudo Random Number Generator; PRNG)를 향상하는 개발 제안이 오픈JDK 커뮤니티에서 제기됐다.    JDK 17 릴리스 계획의 일부인 이 제안은 점프 가능한(jumpable) PRNG, 분할 가능한(splittable) PRNG 알고리즘(LXM)의 추가 클래스를 포함해 유사 난수 생성기를 지원하는 새로운 인터페이스 타입 및 구현을 제공한다. 새로운 인터페이스와 RandomGenerator는 기존의 모든 PRNG와 새로운 PRNG에 일관된 API를 지원한다. 또 4개의 특수 RandomGenerator 인터페이스가 제공된다. 이 제안의 목표는 다음과 같다.  • 애플리케이션에서 다양한 PRNG 알고리즘을 서로 바꿔서 사용할 수 있도록 한다.  • PRNG 객체의 스트림을 제공하여 스크림 기반 프로그래밍 지원을 향상한다.  • 기존 PRNG 클래스에서 코드 중복을 제거한다.  • 클래스 java.util.Random의 기존 동작을 보존한다.  또한 이는 다른 PRNG 알고리즘을 수용할 수 있는 프레임워크를 제공하기 위해서 수많은 다른 PRNG 알고리즘의 구현을 제공하는 것이 목표는 아니지만 이미 다른 프로그래밍 언어 환경에 널리 구축돼 있는 3가지 공통 알고리즘을 추가했다고 개발팀은 전했다.  앞으로 몇 개월 동안 JDK 17에는 더 많은 기능이 제안될 예정이다. 외부 링커 API, 벡터 API, 외부 메모리 액세스 API 등이 포함될 가능성이 크다. 이는 모두 2021년 3월 출시 예정인 JDK 16 릴리스에서 인큐베이터 단계에 있는 것들이다. JDK 16의 두 번째 프리뷰에서 공개된 실드 클래스(Sealed classes)는 JDK 17에서 GA될 것으로 보인다.  JDK 17의 얼리-액세스 오픈소스 빌드...

자바 자바 17 오픈JDK JDK 17 유사 난수 생성기 PRNG

2021.02.10

아직 9월은 아니지만 ‘자바 17(Java 17)’이 서서히 구체화되기 시작했다. 표준 자바로의 업그레이드를 목표로, 유사 난수 생성기(Pseudo Random Number Generator; PRNG)를 향상하는 개발 제안이 오픈JDK 커뮤니티에서 제기됐다.    JDK 17 릴리스 계획의 일부인 이 제안은 점프 가능한(jumpable) PRNG, 분할 가능한(splittable) PRNG 알고리즘(LXM)의 추가 클래스를 포함해 유사 난수 생성기를 지원하는 새로운 인터페이스 타입 및 구현을 제공한다. 새로운 인터페이스와 RandomGenerator는 기존의 모든 PRNG와 새로운 PRNG에 일관된 API를 지원한다. 또 4개의 특수 RandomGenerator 인터페이스가 제공된다. 이 제안의 목표는 다음과 같다.  • 애플리케이션에서 다양한 PRNG 알고리즘을 서로 바꿔서 사용할 수 있도록 한다.  • PRNG 객체의 스트림을 제공하여 스크림 기반 프로그래밍 지원을 향상한다.  • 기존 PRNG 클래스에서 코드 중복을 제거한다.  • 클래스 java.util.Random의 기존 동작을 보존한다.  또한 이는 다른 PRNG 알고리즘을 수용할 수 있는 프레임워크를 제공하기 위해서 수많은 다른 PRNG 알고리즘의 구현을 제공하는 것이 목표는 아니지만 이미 다른 프로그래밍 언어 환경에 널리 구축돼 있는 3가지 공통 알고리즘을 추가했다고 개발팀은 전했다.  앞으로 몇 개월 동안 JDK 17에는 더 많은 기능이 제안될 예정이다. 외부 링커 API, 벡터 API, 외부 메모리 액세스 API 등이 포함될 가능성이 크다. 이는 모두 2021년 3월 출시 예정인 JDK 16 릴리스에서 인큐베이터 단계에 있는 것들이다. JDK 16의 두 번째 프리뷰에서 공개된 실드 클래스(Sealed classes)는 JDK 17에서 GA될 것으로 보인다.  JDK 17의 얼리-액세스 오픈소스 빌드...

2021.02.10

마이크로소프트, 윈도우 10 온 ARM으로의 오픈소스 자바 포팅 진전 발표

마이크로소프트의 자바 엔지니어링 그룹(JEG)이 오픈JDK(오픈소스 자바)를 윈도우 10 온 ARM64 기반 기기로 포팅하는데 진전을 거뒀다고 보고했다. 이 이니셔티브의 첫 단계를 6월 말 완료했다는 보고다. 회사의 초기 변경은 오픈JDK 프로젝트에 업스트림되고 있는 중이다.  이번 포팅은 레드햇과의 파트너십을 통해 오픈JDK에 제출됐다. 초기 액세스 바이너리는 기트허브를 통해 제공된다.  마이크로소프트는 특유의 에너지 효율적인 아키텍처로 인해 ARM64가 노트북과 서버 분야에 확대 적용되고 있음을 목격하고 있다고 밝혔다. 아직 기능이 완전한 상태에 이르지는 않았지만 이번 포팅은 오픈JDK 팁 브랜치에 기반하고 있으며, SPEC SERT 및 SPEC 자바 스윗과 같은 레퍼런스 워크로드를 구동할 수 있는 상태다.  현재 개발자는 이미 윈도우 10 ARM64 호환 노트북 상에서 자바 개발을 시작할 수 있다. ARM64용 비주얼 스튜디오 코드 내의 코어 자바 익스텐션 및 아파치 메이븐과 같은 도구를 통해서다.  마이크로소프트의 오픈JDK 포팅 시도는 2019년 제이클래리티 인수의 일환으로 추진됐다. 해당 인수로 회사의 개발자 부문에 자바 엔지니어링 그룹이 설립됐었다. 한편 마이크로소프트의 경쟁사 애플도 ARM 명령어 세트에 기반한 맥용 자체 CPU 제조 계획을 밝힌 바 있다. -> 리누스 토발즈 “애플의 ARM 전환 환영한다··· 강력한 ARM 데스크톱 기대” ciokr@idg.co.kr  

JEG 마이크로소프트 오픈JDK 윈도우 10 온 ARM

2020.07.14

마이크로소프트의 자바 엔지니어링 그룹(JEG)이 오픈JDK(오픈소스 자바)를 윈도우 10 온 ARM64 기반 기기로 포팅하는데 진전을 거뒀다고 보고했다. 이 이니셔티브의 첫 단계를 6월 말 완료했다는 보고다. 회사의 초기 변경은 오픈JDK 프로젝트에 업스트림되고 있는 중이다.  이번 포팅은 레드햇과의 파트너십을 통해 오픈JDK에 제출됐다. 초기 액세스 바이너리는 기트허브를 통해 제공된다.  마이크로소프트는 특유의 에너지 효율적인 아키텍처로 인해 ARM64가 노트북과 서버 분야에 확대 적용되고 있음을 목격하고 있다고 밝혔다. 아직 기능이 완전한 상태에 이르지는 않았지만 이번 포팅은 오픈JDK 팁 브랜치에 기반하고 있으며, SPEC SERT 및 SPEC 자바 스윗과 같은 레퍼런스 워크로드를 구동할 수 있는 상태다.  현재 개발자는 이미 윈도우 10 ARM64 호환 노트북 상에서 자바 개발을 시작할 수 있다. ARM64용 비주얼 스튜디오 코드 내의 코어 자바 익스텐션 및 아파치 메이븐과 같은 도구를 통해서다.  마이크로소프트의 오픈JDK 포팅 시도는 2019년 제이클래리티 인수의 일환으로 추진됐다. 해당 인수로 회사의 개발자 부문에 자바 엔지니어링 그룹이 설립됐었다. 한편 마이크로소프트의 경쟁사 애플도 ARM 명령어 세트에 기반한 맥용 자체 CPU 제조 계획을 밝힌 바 있다. -> 리누스 토발즈 “애플의 ARM 전환 환영한다··· 강력한 ARM 데스크톱 기대” ciokr@idg.co.kr  

2020.07.14

'텍스트 블록 추가' 등… 구체적으로 드러나는 자바 15

자바의 다음 버전에는 텍스트 블록이 추가되고 나스호른(Nashorn) 자바스크립트 엔진이 삭제될 예정이다.  지난주에 자바 14가 일반 가용성에 도달하면서 후속 버전인 자바 15에 대한 작업이 시작됐다. 자바 15는 2020년 9월 공개될 예정이다.     현재까지 알려진 바로는 텍스트 블록 추가와 나스호른(Nashorn) 자바스크립트 엔진 제거의 두 가지 공식 변경 사항이 있다. 자바 개발 키트 15의 공식 오픈JDK 페이지에는 아직 언급되지 않았지만 제안서 자체의 오픈JDK 페이지에는 JDK 15가 대상 릴리스로 표시되어 있다. 나스호른 제거는 공식 JDK 15페이지에서 언급됐다. JDK 14와 JDK 13에서 미리 볼 수 있는 두 개의 오픈JDK 15 제안 중 텍스트 블록은 여러 줄의 소스 코드에 걸쳐 있는 문자열을 쉽게 표현할 수 있게 하면서 공통 이스케이프 시퀀스를 피함으로써 자바 프로그램 작성 작업을 단순화하기 위한 것이다.  텍스트 블록은 대부분 이스케이프 시퀀스가 필요하지 않고 예측 가능한 방식으로 문자열의 형식을 자동으로 지정하며 개발자가 원하는 경우 형식을 제어할 수 있는 여러 줄 문자열 리터럴이다. 텍스트 블록 제안의 목표는 자바 이외의 언어로 작성된 코드를 나타내는 자바 프로그램에서 문자열의 가독성을 높이기 위함이다. 또 다른 목표는 새로운 구문이 문자열 리터럴과 동일한 문자열 집합을 표현하고 동일한 이스케이프 시퀀스를 해석하며 문자열 리터럴과 동일한 방식으로 조작할 수 있도록 규정하여 문자열 리터럴에서 마이그레이션을 지원하는 것이다. 오픈JDK 개발자는 명시적인 공백과 새 줄(newline control) 제어를 관리하기 위해 이스케이프 시퀀스를 추가하려고 한다. 한편 2014년 3월 JDK 8에서 등장한 나스호른은 그랄VM(GraalVM)과 같은 기술로 인해 더 이상 사용되지 않다. 오픈JDK 15 제안은 나스호른 API 및 나스호른을 호출하는 데 사용되는 jjs 명령줄 도구를 제거해...

오라클 자바15 자바14 자바 개발자 키트 나스호른 Nashorn 오픈JDK LTS 자바스크립트 자바 텍스트 블록

2020.04.07

자바의 다음 버전에는 텍스트 블록이 추가되고 나스호른(Nashorn) 자바스크립트 엔진이 삭제될 예정이다.  지난주에 자바 14가 일반 가용성에 도달하면서 후속 버전인 자바 15에 대한 작업이 시작됐다. 자바 15는 2020년 9월 공개될 예정이다.     현재까지 알려진 바로는 텍스트 블록 추가와 나스호른(Nashorn) 자바스크립트 엔진 제거의 두 가지 공식 변경 사항이 있다. 자바 개발 키트 15의 공식 오픈JDK 페이지에는 아직 언급되지 않았지만 제안서 자체의 오픈JDK 페이지에는 JDK 15가 대상 릴리스로 표시되어 있다. 나스호른 제거는 공식 JDK 15페이지에서 언급됐다. JDK 14와 JDK 13에서 미리 볼 수 있는 두 개의 오픈JDK 15 제안 중 텍스트 블록은 여러 줄의 소스 코드에 걸쳐 있는 문자열을 쉽게 표현할 수 있게 하면서 공통 이스케이프 시퀀스를 피함으로써 자바 프로그램 작성 작업을 단순화하기 위한 것이다.  텍스트 블록은 대부분 이스케이프 시퀀스가 필요하지 않고 예측 가능한 방식으로 문자열의 형식을 자동으로 지정하며 개발자가 원하는 경우 형식을 제어할 수 있는 여러 줄 문자열 리터럴이다. 텍스트 블록 제안의 목표는 자바 이외의 언어로 작성된 코드를 나타내는 자바 프로그램에서 문자열의 가독성을 높이기 위함이다. 또 다른 목표는 새로운 구문이 문자열 리터럴과 동일한 문자열 집합을 표현하고 동일한 이스케이프 시퀀스를 해석하며 문자열 리터럴과 동일한 방식으로 조작할 수 있도록 규정하여 문자열 리터럴에서 마이그레이션을 지원하는 것이다. 오픈JDK 개발자는 명시적인 공백과 새 줄(newline control) 제어를 관리하기 위해 이스케이프 시퀀스를 추가하려고 한다. 한편 2014년 3월 JDK 8에서 등장한 나스호른은 그랄VM(GraalVM)과 같은 기술로 인해 더 이상 사용되지 않다. 오픈JDK 15 제안은 나스호른 API 및 나스호른을 호출하는 데 사용되는 jjs 명령줄 도구를 제거해...

2020.04.07

"자바를 iOS로 이식하자"··· 새 오픈JDK 프로젝트 제안

애플 iOS에서 자바를 사용할 수 있도록 하는 새로운 개발 제안이 오픈JDK 커뮤니티에서 제기됐다. 오픈JDK 모바일 프로젝트를 다시 시작해 iOS와 안드로이드용 오픈JDK 클래스와 API를 만드는 것이 주요 내용이다.   모바일 개발업체 글루온(Gluon)의 조한 보스는 최근 이런 내용의 글을 커뮤니티에 올렸다. 오픈JDK 모바일은 자바 개발자에게 익숙한 툴을 이용해 오픈JDK 소스 리파지토리 최신 버전과 같은 API를 iOS와 안드로이드에 제공하는 데 집중해 왔다. 그러나 최우선 과제는 iOS였다. 전통적인 자바 지원이 취약했기 때문이다. 애플은 자바 가상머신을 iOS에서 실행하는 것을 허용하지 않고 있다.   오픈JDK 모바일에 대한 새 계획을 실행하려면 빌드와 함께 코드를 컴파일하기 위해 GraalVM 컴파일러가 필요하다(보스는 적시 컴파일은 iOS에서 고려하지 않고 있다고 말했다). 이후 컴파일된 자바 코드는 목표로 하는 운영체제에 맞춰 컴파일된 네이티브 라이브러리와 연동되고 해당 운영체제에서 최종적으로 실행된다. 현재 자바 11을 기반으로 iOS에서 이런 방식으로 작동하도록 이미 구현을 마쳤다.   GraalVM 네이티브 이미지와 오픈JDK 클래스를 이용하면 개발자가 애플의 개발 규정을 준수하는 애플리케이션을 만들 수 있다. iOS용 소프트웨어를 개발하기 위해 오브젝티브 C나 스위프트를  배울 필요도 없게 된다. 보스는 "자바를 모바일 게임 부문에 활용하는 시기는 다소 늦었지만 크로스 플랫폼의 장점은 여전하다. 핵심 요건인 보안을 충족하면서 개발할 수 있다. 클라우드 서비스로의 보안 연결도 가능하기 때문에 모바일 개발에 실제로 매우 적합한 언어가 될 수 있다"라고 말했다.   한편 안드로이드 개발의 경우 처음부터 자바가 사용됐다. 단, 보스에 따르면, 안드로이드는 자바 11과 호환되지 않고 자체 개발 툴인 안드로이드 스튜디오(Android Studio)와 자체 프로시저를 사용한다. 그는 "많은 개발자가...

자바 iOS 오픈JDK

2019.07.11

애플 iOS에서 자바를 사용할 수 있도록 하는 새로운 개발 제안이 오픈JDK 커뮤니티에서 제기됐다. 오픈JDK 모바일 프로젝트를 다시 시작해 iOS와 안드로이드용 오픈JDK 클래스와 API를 만드는 것이 주요 내용이다.   모바일 개발업체 글루온(Gluon)의 조한 보스는 최근 이런 내용의 글을 커뮤니티에 올렸다. 오픈JDK 모바일은 자바 개발자에게 익숙한 툴을 이용해 오픈JDK 소스 리파지토리 최신 버전과 같은 API를 iOS와 안드로이드에 제공하는 데 집중해 왔다. 그러나 최우선 과제는 iOS였다. 전통적인 자바 지원이 취약했기 때문이다. 애플은 자바 가상머신을 iOS에서 실행하는 것을 허용하지 않고 있다.   오픈JDK 모바일에 대한 새 계획을 실행하려면 빌드와 함께 코드를 컴파일하기 위해 GraalVM 컴파일러가 필요하다(보스는 적시 컴파일은 iOS에서 고려하지 않고 있다고 말했다). 이후 컴파일된 자바 코드는 목표로 하는 운영체제에 맞춰 컴파일된 네이티브 라이브러리와 연동되고 해당 운영체제에서 최종적으로 실행된다. 현재 자바 11을 기반으로 iOS에서 이런 방식으로 작동하도록 이미 구현을 마쳤다.   GraalVM 네이티브 이미지와 오픈JDK 클래스를 이용하면 개발자가 애플의 개발 규정을 준수하는 애플리케이션을 만들 수 있다. iOS용 소프트웨어를 개발하기 위해 오브젝티브 C나 스위프트를  배울 필요도 없게 된다. 보스는 "자바를 모바일 게임 부문에 활용하는 시기는 다소 늦었지만 크로스 플랫폼의 장점은 여전하다. 핵심 요건인 보안을 충족하면서 개발할 수 있다. 클라우드 서비스로의 보안 연결도 가능하기 때문에 모바일 개발에 실제로 매우 적합한 언어가 될 수 있다"라고 말했다.   한편 안드로이드 개발의 경우 처음부터 자바가 사용됐다. 단, 보스에 따르면, 안드로이드는 자바 11과 호환되지 않고 자체 개발 툴인 안드로이드 스튜디오(Android Studio)와 자체 프로시저를 사용한다. 그는 "많은 개발자가...

2019.07.11

IDG 설문조사

회사명:한국IDG 제호: ITWorld 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아00743 등록일자 : 2009년 01월 19일

발행인 : 박형미 편집인 : 박재곤 청소년보호책임자 : 한정규
사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2022 International Data Group. All rights reserved.

10.4.0.13