‘C 언어’는 지난 1972년 개발돼 지금까지 전 세계적으로 널리 사용되고 있으며, 소프트웨어 시대의 핵심적인 기본 구성요소로 군림하고 있다. 하지만 지난 수십 년 동안 새로운 언어가 많이 등장했다. 그중에는 노골적으로 C 언어의 아성에 도전한 언어도 있었고, 인기를 끌면서 C 언어를 조금씩 갉아먹은 언어도 있었다. 여기서는 C 언어와 C++, 자바, C#, 러스트, 파이썬 그리고 ‘쌩신입’ 카본을 비교해 살펴봤다.    C vs. C++ C 언어의 가장 흔한 비교 대상은 C++다. 이름에서 알 수 있는 것처럼 C++는 C 언어의 확장판으로 개발됐다. C++의 구문 및 접근 방식은 C와 유사하지만 이는 네임 스페이스, 템플릿, 예외 처리, 자동 메모리 관리 등 C에서는 기본 제공하지 않는 매우 유용한 기능을 지원한다. 데이터베이스나 머신러닝 시스템 등 최상급 성능을 요하는 프로젝트는 C++의 이러한 기능을 사용해 작성되는 경우가 많다. 또한 C++는 C보다 훨씬 더 적극적인 확장 중이다. 곧 출시될 C++ 23은 모듈, 코루틴, 더 빠른 컴파일, 모듈화된 표준 라이브러리 등 많은 기능을 제공할 예정이다. 반면에 C 표준의 최신 버전(C2x)은 추가 기능이 거의 없으며, 하위 호환성 유지에 주안점을 두고 있다.  문제는 C++의 모든 장점이 동시에 단점으로 작용하기도 한다는 것인데, 이 단점이 크다. C++의 기능을 많이 사용할수록 복잡성이 증가하며, 결과를 통제하기가 어려워진다. C++의 특정 부분만 제한적으로 사용하면 최악의 문제는 대부분 피할 수 있다. 이러한 복잡성을 원천적으로 차단하기도 한다. 예를 들면 리눅스 커널(Linux Kernel) 개발팀은 C++를 기피하며, 대부분의 리눅스는 여전히 C로 작성된다(현재 러스트를 향후 커널 추가를 위한 언어로 보고 있긴 하다).  물론 C++가 고수준 기능을 풍부히 갖추고 있는 이유는 분명하다. 하지만 현재와 미래의 프로젝트 및 프로젝트팀에 미니멀리즘이 더 적합하다면...

7일 전

오픈JDK(OpenJDK) 커뮤니티에서 인큐베이션 중인 새로운 제안 ‘Extent-local Variables(JEP 429)’은 자바 스레드 간 데이터 공유를 지원한다.    자바 스레드 간 데이터 공유가 더 쉬워질 전망이다. 새로운 오픈JDK 제안이 아직 개발 중인 ‘extent-local’ 변수 API를 소개했다. 이 API를 통해 개발자는 한 스레드 안에서는 물론 차일드 스레드(child threat) 간 데이터를 공유할 수 있는 프로그래밍 모델을 제공받는다. 더 많은 가상 스레드를 손쉽게 다룬다는 점을 비롯해 현재 threat-local 변수보다 더 낫다고 해당 제안은 주장했다.  이 제안은 이 API의 목표 4가지를 제시했다.  사용 편의성: 데이터 플로우의 로직을 간소화한다.  일괄성: 공유된 데이터의 전반적인 라이프사이클을 코드의 구문 구조에서 바로 볼 수 있게 한다.  보안성: 공유된 데이터는 인증된 호출자만 접근할 수 있다.  성능: 공유된 데이터를 변경할 수 없도록 해 많은 스레드 간의 데이터 공유를 가능케하고 런타임을 최적화한다.  새로운 extent local 변수 API 제안은 특정 자바 버전을 명시하지 않았다. 가장 빠른 예상 출시일은 2023년 3월 예정인 Java 20일 것이다. Java 19 또는 Java Development Kit 19는 9월 20일에 배포될 예정이며 새로운 기능이 포함되지 않는다.  이번 제안은 자바 프로그래밍 언어 자체에 아무런 영향을 끼치지 않는 추가 기능이다. threat local 변수에서 extent local 변수 API로 이전이 강제되거나 ThreatLocal API 지원이 끊길 가능성은 없다. ciokorea@idg.co.kr

2022.09.13

11년 된 표준 자바 릴리즈 ‘자바 7’의 끝이 다가왔다. 오라클은 이 릴리즈의 확장 지원을 2022년 7월 말 중단할 예정이라고 밝혔다.    공식적인 확장 지원(Extended Support)이 중단되기 때문에 ‘자바 7’은 오라클 평생 지원 정책(Oracle Lifetime Support Policy)에 따라 오라클 라이선스가 종료되는 시점까지 제공되는 지원 모드(Sustaining Support)로 전환된다. 추가 패치 업데이트, 버그 또는 보안 수정, 기능 배포는 지원되지 않으며, 제한된 지원만 제공된다.  2011년 7월 28일 출시된 ‘자바 7’은 오라클이 2010년 자바를 개발한 썬 마이크로시스템즈(Sun Microsystems) 인수 이후 5년 만에 처음으로 선보인 메이저 자바 릴리즈였다. 확장 지원 종료는 오라클 퓨전 미들웨어(Oracle Fusion Middleware)의 특정 이전 버전에서 (인증된) 자바 개발 키트(Java Development Kit)를 더 이상 사용할 수 없다는 의미다.  7월 22일 마지막으로 업데이트된 오라클 지원 게시판에 의하면 자바 SE 7을 사용하는 지원 고객은 자바 SE 버전 8 또는 11 등 지원되는 표준 자바 버전으로 업그레이드해야 한다.  뉴렐릭(New Relic)이 지난 4월 발표한 자바 생태계 보고서에서 애플리케이션의 1.71%가 프로덕션 환경에서 여전히 자바 7을 사용하고 있는 것으로 조사됐다. 자바 7 또는 자바 6을 사용하는 애플리케이션의 대부분은 업그레이드되지 않은 레거시 애플리케이션이었다고 회사 측은 전했다.  최신 자바 릴리즈인 버전 18은 필수 소프트웨어 업데이트 및 연중무휴 서비스를 포함한 프리미어 지원(Premier Support)이 9월까지 제공될 예정이다. 이전 버전인 자바 17은 LTS 릴리즈이기 때문에 몇 년간 프리미어 지원이 제공된다. 오라클의 표준 자바 지원 로드맵은 이곳에서 확인할 수 있다. ciokr@id...

2022.07.27

소프트웨어 분야에서 가장 흥미로운 현상 중 하나는 자바의 끈질긴 생명력이다. 언어이자 플랫폼으로써 자바는 기술 세계의 급격한 변화를 거치면서도 생존했고 자바 내부 구조도 그에 맞춰 변화됐다. 자바는 어떻게 해서 20년 이상 엔터프라이즈와 오픈소스에서 모두 중심을 유지하고 있을까? 가장 중요한 몇 가지 요소를 살펴보자.   자바 커뮤니티 프로세스 자바는 여러 가지 작업을 더 편리하게 하기 위한 대안으로 탄생했다. 지금은 그동안 반복된 도전에도 불구하고 모두가 인정하는 엔터프라이즈 소프트웨어의 기둥이다. 급격한 변화를 겪으면서도 자바가 그 생명력을 유지하는 이유는 무엇일까? 한 가지 중요한 요소는 개발자의 참여를 이끌어 자바의 활발하고 동적인 힘을 유지하는 거버넌스 구조와 이를 통해 촉진되는 커뮤니티의 열정이다. 자바의 거버넌스는 매끄럽고 기계적인 운영과는 거리가 멀어서, 서로 경쟁하는 이해와 조직의 혼란스러운 조합이다. 이들은 자바 커뮤니티 프로세스(JCP)와 자바 사양 요청(JSR)을 통해 저마다 목소리를 낸다. JCP는 자바 기술에 대해 깊은 관심을 두고 있는 사람들의 기여와 충돌 해결을 위한 창구다. 관료주의와 정치, 창의성의 독특한 조합이다. 현실의 민주주의와 비슷하다고 할 수 있다. 자바가 성공적으로 람다와 클로저를 포용한 것은 오랜 자바 프로그래머에게는 정말 놀라운 사건이었다. 객체 지향 프로그래밍 언어에 함수 구조를 추가한다는 것은 많은 논란을 일으킨 과감한 결단이었다. 하이버네이트, 스프링(각각 JSR 317, JSR 330)과 같은 기술에 의해 도입된 개념도 공식 플랫폼에 흡수됐다. 자바처럼 광범위하게 사용되는 기술이 여전히 새로운 아이디어를 통합한다는 것은 고무적인 일이다. 커뮤니티에 대한 자바의 기민한 대응은 유용한 개선을 도입하도록 이끈다. 개발자는 자신이 속한 시스템이 변화하는 세계에서 성공하기 위해 끊임없이 개선되는, 살아있는 시스템이라고 느끼게 된다. 자바의 동시성 모델을 재설계하기 위한 대대적인 작업인 프로젝트 룸(...

2022.07.22

이 상표명은 전설적이다. 그러나 썬 마이크로시스템즈가 프로그래밍 언어에 커피명을 어떻게, 왜 붙였는지는 여전히 확실하지 않다.  타임 매거진이 자바(Java)를 1995년의 최고의 제품 10종 가운데 하나로 지정한 이후, 자바는 미국 IT 마케팅 분야에 새로운 전설로 자리매김했다. 썬 마이크로시스템즈(Sun Microsystems)의 이 탁월한 기술이 원래대로 오크(Oak)나 그린토크(Greentalk)라는 이름을 유지했다면 어땠을까? 이처럼 성공했을까? 모를 일이다. 멋진 오픈소스 프로그래밍 환경을 배포하면 당연히 인기가 있을 것이다. 이를 무엇으로 부를 것인지는 중요하지 않다. 그러나 차세대 애플리케이션 개발자를 위한 썬(Sun)의 새 프로그래밍 언어에게는 브랜드 정체성이 중요했다. 그리고 그 일을 맡은 사람들은 커피 이름을 상표로 확정했다. 그러나 자바(Java)라는 이름이 선택된 배경은 적어도 일정부분 미스터리다.  원래 1996년 자바월드(JavaWorld)에 의해 출간된 내용을 정리한 이 집단 인터뷰는, ‘자바’라는 이름의 탄생에 대한 멋진 회고를 제공한다.  Matthew Hamm (CC BY 2.0) 자바는 어떻게 자바가 되었나  썬의 당시 수석 엔지니어였던 프랭크 옐린은 “변호사들이 ‘오크(OAK)’라는 이름을 사용할 수 없다고 했었다. 그 이유에 대해 오크 테크놀로지(Oak Technologies)라는 회사가 이미 상표로 등록했기 때문이라고 했었다”라고 전했다.  그는 “새 이름에 대한 아이디어를 찾기 위해 회의가 열렸다. 당시 라이브 오크(Live Oak)라고 불린 집단의 모든 구성원이 참석했다. 10개의 유망한 이름이 최종적으로 선택되었고, 이것들을 법무지원 부서로 보냈는데, 3개의 이름이 통과되어 돌아왔다. 그것은 자바(Java), DNA, 실크(Silk) 였다. ‘자바’라는 이름을 누가 처음 제안했는지는 아무도 기억하지 못했다. 오직 한 사람이 그 이름을 창안했음을 시사한다”라고...

2022.07.19

자바는 널리 사용되며 많은 요소가 자바에 의존하는 만큼 소프트웨어 인프라의 중요한 한 부분이다. 이 때문에 자바 플랫폼은 안정성을 중시하지만, 한편으로는 변화하는 환경에 적극적으로 대응하고 있다. 자바를 사용하는 사람들의 창의성도 이런 변화에 한몫한다. 이때문에 자바에는 높은 수준의 안정성을 달성하면서 변화를 수용하기 위해 공식적인 프로세스가 있다. 여기서는 자바 플랫폼이 어떤 방식으로 향상되는지를 대략적으로 알아보고, 앞으로 적용될 가장 중요한 새로운 기능에 대해서도 살펴본다.      자바 커뮤니티 프로세스  오랜 경력의 자바 개발자라 해도 자바 플랫폼이 개발, 유지되는 방식에 대해서는 잘 모를 수 있다. 큰 그림으로 들어가기 전에 자바 프로세스가 어떻게 동작하는지부터 알아보자. 핵심은 자바가 실질적으로 오픈소스라는 데 있다. 즉, 마음만 먹으면 자바에 기여할 수 있다. 기여자에게 말하고 그룹에 가입하고 제안을 제출하고 버그를 수정하면 된다.  자바 개발의 뿌리는 자바 커뮤니티 프로세스(Java Community Process, JCP)다. JCP는 수정 사항을 자바 플랫폼에 적용하는 방법을 정의하고, 이 프로세스 자체의 수정도 허용하는 일종의 자기인식적 문서라고 할 수 있다. JCP 최신 버전은 2019년에 채택된 2.11이다.  JCP는 사람들이 맡을 수 있는 다양한 역할에 대한 정의를 포함해서 자바의 새로운 기능과 변경(즉, 기술 사양)을 제안, 검토, 승인하는 방식을 공식화한다. 이와 같은 역할은 자바 사용자 커뮤니티가 플랫폼 관리에 참여할 수 있는 환경을 제공하는 데 도움이 된다.    자바 사양 요청  JCP는 새로운 기능과 변경 제안을 위해 자바 사양 요청(Java Specification Request, JSR)을 사용한다. JSR은 표준화된 양식을 통해 만들 수 있으며, 양식을 사용하려면 무료 JCP 계정을 만들어야 한다.  짐작할 수 있겠지...

2022.06.09

‘어답티움 마켓플레이스(The Adoptium Marketplace)’에서는 오라클이 아닌 이클립스, 마이크로소프트, IBM, 아줄 등 다른 회사의 표준 자바 바이너리에 액세스할 수 있다.   조심하라, 오라클 자바. 이클립스 재단이 여러 소스의 표준 자바 바이너리에 액세스할 수 있는 온라인 마켓플레이스를 열었다.    이클립스가 (산하의) 어댑티움 워킹 그룹(Adoptium Working Group)과 협력하여 ‘어답티움 마켓플레이스’를 구축하고 있으며, 이 마켓플레이스는 오픈JDK(OpenJDK)를 기반으로 하는 자바 SE 기술 호환성 키트(TCK) 인증 및 이클립스 AQAvit(Adoptium Quality Assurance) 자바 바이너리를 제공할 예정이다. TCK가 자바 호환성을 테스트한다면 AQAvit는 성능 및 확장성을 테스트한다.  어답티움 마켓플레이스에 참여할 조직에는 이클립스(테무린(Temurin) 런타임), 마이크로소프트(마이크로소프트의 자체 오픈JDK(Microsoft Build of OpenJDK)), IBM(스메루(Semeru) 런타임 인증 에디션), 화웨이(비솅(Bi Sheng)), 알리바바 클라우드(드래곤웰(Dragonwell)), 레드햇(자체 오픈JDK), 아줄(오픈JDK 줄루 빌드(Zulu Builds of OpenJDK))이 있다. 알리바바 클라우드와 마이크로소프트의 빌드는 7월에 나올 예정이다.  표준 자바의 개발 책임자이자 이클립스의 멤버이기도 한 오라클은 이에 참여하지 않는다. 이클립스의 전무이사 마이크 밀린코비치는 “오라클에도 참여를 요청했지만 현재까지는 동참하지 않기로 했다”라고 말했다. 애플리케이션 모니터링 업체 뉴 렐릭(New Relic)의 최근 연구에 따르면 오라클 자바가 여전히 이 분야를 주도하고 있지만 시장 점유율은 2020년 75%에서 올해 34.48%로 떨어졌다.  이클립스의 자카르타 EE 엔터프라이즈 자바(Jakarta EE enterpri...

2022.05.27

美 애플리케이션 보안 전문 기업 베라코드(Veracode)의 CTO와 함께 로그4j 취약점의 여파, 오픈소스 보안 문제 인식을 높이는 방법 등을 살펴본다.  지난 2021년 12월 초 수백만 개의 애플리케이션에서 사용되는 오픈소스 자바 구성요소 ‘로그4j’에서 일련의 취약점이 발견되면서 전 세계의 기업 보안팀은 비상 경계 태세에 돌입해야 했다.    이는 미국 사이버 보안 및 인프라 보안국(CISA; Cybersecurity and Infrastructure Security Agency)을 비롯해 다른 국가의 CERT(Computer Emergency Response Team)에서도 경고했을 만큼 큰 사건이었으며, 아울러 보안 및 오픈소스 소프트웨어 생태계, 개발자가 오픈소스 구성요소를 사용하고 추적하는 방법에 관한 새로운 논의를 촉발했다.  여기서는 베라코드의 설립자 겸 CTO이자 애플리케이션 보안 및 취약점 분야에서 20년 이상의 경력을 갖춘 보안 업계 베테랑인 크리스 위소팔과 ‘로그4j 취약점의 여파와 오픈소스 보안의 미래’를 주제로 나눈 대화를 정리했다. ‘로그4j’의 중요성과 여파 “로그4j는 ‘광범위하게 사용돼 거의 모든 서버에 영향을 미칠 수 있다는 점에서’ 개발팀이 일상적으로 다루는 것과는 확실히 다른 유형의 취약점이었다. 이는 거의 모든 기업에 영향을 미쳤고, 모든 기업의 여러 개발팀, 즉 회사를 위해 새로운 일을 하는 팀과 1년에 한 번 정도 코드를 변경하는 유지관리 모드에 있는 팀을 강타했다.”  “베라코드는 SaaS 업체이기 때문에 모든 고객을 살펴볼 수 있다. 작년에 스캔한 수십만 개의 애플리케이션 중에서, 특히 기업 고객을 관심 있게 살펴봤다. 95%의 기업 고객이 자바를 쓰고 있었다. 이는 자바가 얼마나 인기 있는지를 보여준다. 만약 자바에 이와 같은 취약점이 또 있다면 그 역시 널리 퍼질 것이다.” “아울러 88%는 로그4j를 사용하고, 58%는 취약한 버전을 쓴다고 답했다....

2022.05.26

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

2022.05.20

젯브레인(JetBrains)에서 만든 크로스 플랫폼 오픈소스 프로그래밍 언어의 최신 버전 ‘코틀린 1.7.0’이 베타 릴리즈 단계에 도달했다. 이번 업데이트는 빌더 타입 추론 변경사항과 새로운 메모리 관리자 등을 특징으로 한다.    회사에 따르면 빌더 추론은 일반 빌더 함수를 호출할 때 유용한 타입 추론이다. 이는 컴파일러가 람다 인수 내 다른 호출의 타입 정보를 사용하여 해당 호출의 타입 인수를 추론하는 데 도움을 준다.  1.7.0 베타에서는 -Xenable-builder-inference 컴파일러 옵션을 지정하지 않고 일반 타입 추론이 충분한 타입 정보를 얻을 수 없을 때 빌더 추론이 자동으로 활성화된다. 즉, 이제 개발자는 추가 주석이나 옵션을 적용하지 않고 빌더 타입 추론을 사용하는 빌더를 작성할 수 있다는 설명이다. 이번 변경사항으로 빌더 추론 안정화에 가까워졌다고 젯브레인은 밝혔다.  또 베타 릴리즈에는 새로운 코틀린/네이티브 메모리 관리자 알파 버전이 제공된다. 이 관리자는 JVM과 네이티브 플랫폼 간의 차이를 제거한다. 회사에 의하면 개발자는 안드로이드와 iOS 모두에서 작동하는 크로스 플랫폼 모바일 애플리케이션을 더 쉽게 구축할 수 있다. 아울러 스레드 간 객체 공유 제한이 제거되고, 특정한 관리나 주석이 필요하지 않은 ‘누수 없는(leak-free)’ 동시 프로그래밍 기본 요소가 지원된다. 새 메모리 관리자는 향후 버전에서 디폴트로 제공될 예정이다.  코틀린 1.7.0 베타 설치 지침은 이곳에서 확인할 수 있다. 이 밖에 베타의 다른 기능은 아래와 같다.  • ‘확실히 nullable이 아닌(definitely non-nullable types)’ 타입이 안정화됐다. 이는 지난달 공개된 코틀린 1.6.20에서 도입됐으며, 현재 디폴트로 활성화된다. 일반 자바 클래스 및 인터페이스를 확장할 때 개발자에게 향상된 상호운용성을 지원하는 타입을 제공한다.  • min()와...

2022.05.19

웹어셈블리를 훨씬 더 쉽게 작성하는 법부터 머신러닝을 지원하는 시각적 언어까지 새로운 프로그래밍 도구 11가지를 살펴본다. 이는 어쩌면 소프트웨어 작성 방식을 재정의할지도 모른다.  영국의 시인 알렉산더 포프는 “희망은 인간의 가슴에서 영원히 샘솟는다(Hope springs eternal in the human breast)”라고 말했으니 해커가 아닌 시인이라 할지라도 새로운 프로그래밍 언어 발견에 대한 희망을 이해할 것이라 본다. 소프트웨어 개발자들은 유니코드 문자의 독특한 조합으로 만들어진 언어가 마침내 모든 문제를 해결하여 몇 번의 클릭만으로 쉽게 코딩할 수 있길 영원히 희망하고 있다.  포프는 분명 답을 상상하기만 하면 될 정도로 직관적인 구문에 대한 희망을 이해할 것이다. 또한 그는 올림픽에서 볼 수 있는 트리플 악셀 혹은 대회전 활강처럼 (사실은 그렇지 않지만) 힘들지 않고 우아해 보이는 새로운 코드를 손에 넣으려는 열망을 높이 평가할 것이다.    하지만 오늘날의 언어 대부분은 기발함이나 코딩 역량을 보여주기 위해 만들어지진 않았다. 이는 개발자(창작자)가 간절하게 해결하고자 했던 문제에 해결책을 내놓으면서 만들어졌다. 대다수의 개발자가 하나 이상의 오래된 기성 언어로 코딩을 계속하겠지만 코딩 문제를 해결하는 데 도움이 되는 새로운 도구도 ‘영원히’ 찾고 있다. 특히, 도메인별 언어(DSL)의 부상에서 이러한 경향을 볼 수 있다. 이러한 언어는 특정 도메인에 초점을 맞추고 있으며, 범용적으로 사용하진 못한다. 하지만 바로 그런 이유로 도구 상자에서 특별한 위치를 차지할 수 있다.  여기서는 틈새시장을 찾은 11개의 새로운 언어를 살펴본다. 비록 지금 당장 필요한 것은 아니지만 이 모두는 현재 하는 일을 개선할 무언가를 갖고 있다. 리액티브 클로저(Reactive Clojure) 이는 클로저(Clojure)와 리액트(React)를 결합한 결과다. 즉, 리액티브 프론트엔드의 모든 가능성과 클로저의...

2022.05.11

분산 이벤트 스트리밍 플랫폼 ‘아파치 카프카(Apache Kafka)’의 메타데이터 관리 도구 ‘주키퍼(ZooKeeper)’가 단계적으로 제거될 예정이다.    아파치 카프카 프로젝트 관리 위원회(Apache Kafka project Management Committee)의 멤버이자 컨플루언트(Confluent)의 엔지니어 콜린 맥케이브는 “주키퍼를 사용하면 클러스터 메타데이터를 저장하고 동적 구성, 토픽, 토픽 내 파티션을 관리할 수 있지만 관리 계층을 추가하는 문제점이 있다”라면서, “하지만 카프카 내부에 메타데이터를 저장하면 더 쉽게 관리할 수 있고, 버전 관리 등의 문제를 해결할 수 있다”라고 말했다.  주키퍼는 내부적으로 관리되는 메타데이터용 프토로콜인 ‘카프카 라프트(Kafka Raft) 또는 크라프트(KRaft)’로 대체된다. 크라프트 모드에서 카프카 메타데이터는 분산 로그에 저장된다. 맥케이브는 “확장성이 주된 이점이다. 아울러 관리도 개선될 것”이라고 밝혔다. 카프카 사용자는 카프카 클러스터를 관리하기 위해 별도의 시스템을 구축할 필요가 없다고 그는 덧붙였다.  주키퍼 지원이 정확히 언제 중단될지는 발표되지 않았다. 현재는 카프카 3.3 릴리즈에서 크라프트를 GA 버전으로 제공하고, 카프카 4.0에서 주키퍼를 제거할 계획이다. 오는 8월에 출시될 카프카 3.3에는 주키퍼와 크라프트 옵션이 모두 포함된다. 맥케이브는 “크라프트 모드가 곧 프로덕션으로 전환될 예정이다. 이는 해당 프로젝트의 큰 발전일 것”이라고 전했다.  크라프트 모드는 지난 2021년 4월 릴리즈된 카프카 2.8부터 사용할 수 있었지만 프로덕션 준비 상태는 아니었다. 이는 카프카 3.3에서 프로덕션 준비 릴리즈로 제공될 예정이다. 맥케이브는 “주키퍼를 사용해왔던 개발자의 학습 곡선이 가파르지는 않을 것”이라면서, “개발자를 위해 동일한 API가 지원된다. 운영자는 몇 가지 학습해야 할 것이 있을 수 있다. 새로운 관리자가 이를...

2022.05.10

뉴 렐릭(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

오라클이 프로그래밍 언어이자 개발 플랫폼인 자바의 최신 버전 ‘자바 18(Java 18)’을 출시했다. 최신 버전에는 안전성과 보안성이 더욱 향상된 수 천 가지 기능과 함께 개발자의 생산성을 더욱 향상시켜 줄 9가지 플랫폼 업데이트 사항이 포함되었다고 업체 측은 설명했다. 회사에 따르면 특히 이번에 업데이트된 9개의 JEP(JDK Enhancement Proposal, JDK 개선 제안) 중 JEP 413은 자바 API 설명서에 코드 스니펫(Code Snippets)을 추가하는 기능으로, API 설명서에 샘플 소스코드를 추가하거나, 프로토타입 생성 또는 테스트용 간이 웹 서버(JEP 408)를 추가하는 작업이 대폭 간소화됐다. 또한 개발자들은 벡터 API(JEP 417)와 외부 함수 및 API(JEP 419) 등 두 가지 인큐베이팅 모듈과 스위치(Switch) 문 패턴 매칭(JEP 420) 등 미리보기 기능도 활용할 수 있다. 오라클 자바 플랫폼 그룹 소프트웨어 개발 부사장인 조지 사브는 “자바 18은 오라클이 6개월마다 기업 및 개발자들에게 더욱 개선된 기능을 신속하게 제공하겠다는 약속을 지속적으로 지켜 나가고 있음을 여실히 입증하고 있다”라며, “우리는 지속적인 기술 투자를 통해 자바 개발 키트뿐만 아니라 자바 SE 플랫폼의 성능과 안정성, 보안성을 끊임없이 향상시키고 있다”라고 말했다. 오라클은 최근 온프레미스 환경 또는 모든 클라우드 환경에서의 자바 런타임 및 애플리케이션 관리를 돕기 위해 오라클 클라우드 인프라스트럭처(OCI)의 새로운 네이티브 서비스인 자바 매니지먼트 서비스(JMS)도 공개했다. JMS는 전사적인 자바 배포 관리에 필요한 정보를 제공하며 OCI 워크로드 및 자바 SE 구독자들은 해당 서비스를 함께 사용할 수 있다. 자바 18은 오픈JDK 프로젝트 및 자바 커뮤니티 프로세스(JCP)를 통한 오라클 엔지니어들과 전 세계 자바 개발자 공동체 일원들의 폭넓은 협업을 바탕으로 탄생했다. 이를 통해 지속적인 혁신이 제공...

2022.03.29

룸(Loom)은 (오픈JDK에 의해 호스팅되는) 자바/JVM 생태계에서 비교적 새로운 프로젝트다., 전통적인 동시성 모델(concurrency models)이 가진 한계를 극복하려는 시도다. 특히 룸은 자바 스레드(Java threads)를 대체할 경량의 대안이고, 이들을 관리할 새 언어 구조를 가지고 있다. 이와 관련해 앞으로 일어날 중요한 변화를 개략적으로 살펴본다. 파이버: 자바 가상 스레드  리스팅 1에서 볼 수 있듯이 전통적인 자바 동시성은 스레드(Thread) 및 러너블(Runnable) 클래스에 의해 관리된다 (새 명칭의 스레드를 시작하고 해당 명칭을 출력).  리스팅 1. 전통적인 자바로 스레드를 시작하기 이 모델은 꽤 이해하기 쉽다. 그리고 자바는 이를 처리함에 있어 여러 풍부한 지원을 제공하고 있다. 단점은 자바 스레드가 운영체제 내의 스레드에 직접 매핑 된다는 점이다. 이러한 매핑은 동시 실행되는 자바 앱의 확장성을 심하게 제한한다. 이는 앱 스레드와 운영체제 스레드 사이의 1대1 관계를 의미할 뿐 아니라 스레드를 최적으로 정돈할 메커니즘이 전혀 없음을 의미하기도 한다. 예를 들어 서로 밀접하게 연계된 스레드들이 상이한 프로세스를 공유할 수 있고, 그렇다면 동일 프로세스 상에서 힙 메모리를 공유하는 데 따른 혜택이 없어진다. 룸이 얼마나 야심적인 변화를 지향하는 지를 쉽게 시사하는 숫자가 있다. 현재의 자바 스레딩은 심지어 육중한 서버에서조차 스레드 수가 많아 봐야 수천 개이다. 룸은 이 한계를 수백만 개로 확대하려 한다. 이게 자바 서버 확장성에 있어서 갖는 함의는 지극히 파격적이다. 표준적인 요청 처리는 스레드 수와 연계되기 때문이다.  해법은 일종의 가상 스레딩을 도입하는 것이다. 여기서는 자바 스레드가 기저의 OS 스레드로부터 분리되고, JVM(Java Virtual Machine)은 두 스레드의 관계를 한층 효과적으로 관리할 수 있다. 프로젝트 룸은 애당초 파이버(fiber)라는 새로운 가상...

2022.03.14

표준 자바(Java)의 다음 버전에는 외부 함수 및 메모리 API, 벡터 API, 스위치 표현식 패턴 매칭, 범용 제네릭 등이 포함되리라 예상된다.   2주 후 ‘자바 18(Java 18)’이 프로덕션 릴리즈로 출시됨에 따라 ‘자바 19(Java 19)’가 형태를 갖추기 시작했다. 표준 자바의 다음 릴리즈는 자바 런타임 외부 코드와 상호 운용하는 API와 함께 추진될 예정이다. 이는 범용 제네릭, RISC-V 포트 등을 포함하는 잠재적인 제안 가운데 첫 번째다.    현재 오픈JDK(OpenJDK) 커뮤니티에 올라와 있는 자바 19 제안은 자바 프로그램이 자바 런타임 외부의 코드 및 데이터와 상호 운용할 수 있는 외부 함수 및 메모리 API다. 이 기능은 오는 9월 공개될 JDK(Java Development Kit) 19에서 미리 볼 수 있다.  ‘JEP(JDK Enhancement Proposal) 424’로 식별되는 외부 함수 및 메모리 API는 외부 메모리에 액세스하여 JVM 외부의 코드를 호출한다. 이 API는 JDK 17의 인큐베이터 단계에 포함됐었으며, 3월 22일 릴리즈될 JDK 18에서 다시 인큐베이팅될 예정이다. JDK 19에서 이 API는 피드백에 따라 개선 사항을 통합하는 프리뷰 단계로 이동한다. JDK 19는 6개월 동안 지원되는 자바의 단기 릴리즈다.  이 밖에 JDK 19에서 지원할 가능성이 큰 기능은 벡터 API다. 이는 JDK 18에서 세 번째로 인큐베이팅되고 있으며, 네 번째 인큐베이팅이 제안됐다. 이 API는 최적의 벡터 명령어로 런타임에 컴파일하는 벡터 계산을 표현한다. JDK 18에서 두 번째 프리뷰를 진행 중인 스위치 표현식 및 문의 패턴 매칭도 제공할 가능성이 높은 또 다른 기능이다.  오라클은 올해 자바에서 4가지 이니셔티브를 계속 발전시켜 나갈 것이라고 밝혔다. 여기에는 ▲고급 JVM 및 언어 기능을 인큐베이팅하기 위한 프로젝트 발할라(Project V...

2022.03.11

제이레벨(JRebel)의 설문조사 결과에 따르면 전문 자바 개발자의 3분의 1 이상이 메인 애플리케이션에 8년 된 자바 버전을 사용하고 있는 것으로 나타났다.  8년 전 출시된 자바 8이 여전히 가장 많이 사용되는 자바 버전인 것으로 조사됐다. 하지만 설문 조사 결과 자바 17로 업그레이드할 계획인 기업도 많은 것으로 드러났다.     ‘메인 애플리케이션에 어떤 JDK(Java Development Kit) 프로그래밍 언어를 사용하는가?’라는 질문에 전체 응답자의 37%가 자바 8이라고 밝혔다. 2위는 자바 11(29%)이었다. 그다음으로는 자바 12 이상(12%), 코틀린(8%), 그루비(6%), 자바 7 이상(5%), 스칼라(3%) 순이었다.  ‘2022 자바 개발자 생산성 보고서(2022 Java Developer Productivity Report)’는 지난 2012년 10월부터 2022년 1월까지 전문 자바 개발자 876명을 대상으로 실시한 설문조사 결과를 담았다.  자바 8(2014년 3월 출시)과 자바 11(2018년 9월 출시)은 모두 수년간 오라클의 지원을 받는 LTS(Long-Term Support) 릴리즈다. 비 LTS 릴리즈(자바 9, 자바 10, 자바 12, 자바 15 등)는 6개월 동안만 지원을 받는다.  한편 소속 기업의 업그레이드 계획을 알고 있다고 밝힌 응답자 가운데 37%는 향후 6개월 안에 작년 9월 출시된 LTS 릴리즈인 ‘JDK 17’로 업데이트할 계획이라고 언급했다. 아울러 향후 6개월에서 12개월 안에 JDK 17로 업그레이드할 예정이라고 지목한 비율도 25%에 달했다. ‘JDK 18’은 비 LTS 릴리즈이며, 오는 3월 22일 공개된다.  회사에 따르면 ‘2022 자바 개발자 생산성 보고서’는 자바 기술과 자바 애플리케이션 개발에 관한 현 접근 방식에 초점을 맞추고 있다. 제이레벨(JRebel)은 퍼포스에서 만든 자바 개발 도구다. 이 밖에 다...

2022.03.04