『자바 프로그래머 육성』의 저자 벤 에반스: 보수적인 디자인 사고가 자바의 가장 큰 장점

Ben Evans는 jClarity의 공동 창립자입니다. 그의 회사는 개발 및 운영 팀에 도움이 되는 성능 도구와 서비스를 개발합니다. 그는 LJC(London Java User Group)의 조직자 중 한 명이자 JCP(Java Community Process) 집행 위원회의 회원으로 Java 생태계의 일부 표준을 정의하는 데 도움을 주고 있습니다. 그는 또한 "Java Champion" 영예를 안았습니다. 그는 "The Well-Grounded Java Developer"와 "Java Authoritative Technical Manual(6판)"(Java in a Nutshell)을 공동 집필했습니다. 그는 Java 플랫폼, 성능, 동시성 및 관련 주제에 대해 수많은 강의를 해왔습니다.

질문: "Java in a Nutshell"은 고전입니다. 이전 버전(5판)은 1,200페이지에 달했고, 6판은 중국에서 출판될 예정입니다. 10년이 지난 지금은 400페이지밖에 되지 않습니다. 두 판 사이에는 어떤 변화가 있었나요? 이번 10년은 Java에 어떤 의미가 있나요?

Java가 대중화되고 얼마 지나지 않아 "Java Definitive Technical Manual"의 초판이 출판되었습니다. 당시 사람들은 Java에 대한 상상력으로 가득 차 있었습니다. 다음 5판을 거치면서 책의 크기와 내용이 늘어났습니다. 따라서 여러 버전 사이에 진화적 관계가 있기 때문에 각 권의 초점은 다소 역사적입니다. 이는 여러 요인의 결과입니다. 그 이유 중 하나는 단순히 이전 버전에 비해 이 버전에서 추가되거나 삭제된 내용만 알면 됩니다. 그러나 더 중요한 것은 초기에는 대부분의 기업에서 Java의 수명주기가 길었기 때문에 매우 오래된 Java 버전을 자주 볼 수 있다는 것입니다. 따라서 다양한 버전 간의 차이점을 이해하는 것이 중요합니다. 따라서 특정 회사에서 특정 Java 버전을 작업할 때 해당 버전이 무엇인지 알면 무엇을 할 수 있고 무엇을 할 수 없는지, 이 버전이 다른 버전과 비교하여 어떤 변경 사항이 있는지도 알 수 있습니다.

새 판을 쓰기 시작하면서 가장 먼저 바꾸고 싶었던 것이 바로 이것이었습니다. 최신 버전의 Java 8(이 시점에서는 혼동하기 쉽습니다. "Java Authoritative Technical Manual"의 6판에서는 Java 8판에 대해 설명합니다)의 수명 주기가 이전보다 훨씬 짧기 때문입니다. 물론 이는 특정 도메인에 따라 다르지만 일반적인 사용법을 살펴보면 이전 버전(예: Java 6)은 매우 소수의 사람들만 사용하고 있음을 알 수 있습니다. 물론 아직도 버전 6 이전 버전을 사용하는 미친 사람들이 있고, 대부분의 사용자는 버전 7을 사용하고 있습니다. 이제 버전 8은 매우 빠른 속도로 시장을 점유하고 있으며 불과 반년 만에 이미 15~20%의 사용자가 Java 8을 사용하고 있습니다. 따라서 "Java 권위 있는 기술 매뉴얼"의 새 버전에서는 이전보다 더 개방적인 초점을 두고 Java 외부 세계에 주목하기 시작했으며 현재와 미래에 대해서도 논의할 예정입니다.

두 번째로 중요한 변화는 길이입니다. 5판은 1200페이지였는데, 6판은 그 중 3분의 1에 불과했습니다. 내가 한 일은 콘텐츠의 3분의 2를 삭제한 것이었습니다. 제5판을 읽었다면 Java의 주요 내용을 논의하는 것 외에도 이 책의 두 번째 부분이 인덱스에 관한 것임을 알고 있을 것입니다. 물론 이 역시 역사적 이유 때문이다. 자바가 처음 나왔을 때는 인터넷 사용이 그리 흔하지 않았기 때문에 이 책에 자체 색인이 있는 것은 매우 타당하다. 하지만 자바 플랫폼이 점점 더 커지고 있는 이유는 두 가지 더 있습니다. "The Definitive Java Technical Manual"의 첫 번째 장에서는 Java 버전의 진화를 논의하고 Java 플랫폼의 급속한 성장을 지적했습니다. Java 5 플랫폼에 대한 기본 지식을 설명하는 데 800페이지가 걸렸습니다. Java 5 시절에는 그랬습니다. Java 8을 논의하는 데 동일한 방법을 사용했다면 이 책은 최고 수준에 달했을 것입니다. 이 방법은 실현 가능하지 않다는 것을 알 수 있습니다. 누구도 그러한 책을 갖고 싶어하지 않을 것입니다. 또 다른 이유(아마도 이 두 가지가 관련되어 있음)는 사람들이 기술 정보를 사용하는 방식이 이제 어디에나 있고 사람들이 무거운 책을 들고 다니기를 꺼려하며 모든 색인을 PDF, 웹 사이트 등에서 온라인으로 찾을 수 있다는 것입니다. 자원에서. 따라서 이때 종이책 뒷면에 두꺼운 색인을 추가하는 것은 무리이다. 이는 "Java Definitive Technical Manual"의 두 버전 간의 주요 변경 사항입니다.

세 번째로 노력하는 것은 자바의 변화하는 트렌드와 패턴을 포착하는 것입니다. 그래서 예전에 Java를 어떻게 사용하는지에 대한 내용이 많이 삭제되었고, 좀 더 현대적인 사용법을 추가했습니다. 독자들은 가비지 수집, 메모리 할당, 동시 프로그래밍을 이해해야 합니다. 원본 버전은 원본 콘텐츠를 보존하는 데 중점을 두었기 때문에 많은 작업이 필요했습니다. 5판에 남은 내용의 1/3 중 6판에도 25~30% 정도만 남았습니다. 이 내용 역시 재편집되었으며 나머지 70% 정도는 완전히 새로운 내용입니다. .

Java 8이 출시될 때 이 책을 출판하고 싶었기 때문에 Java 8이 나오기 전에 집필을 시작했습니다. 나중에 처음에는 예상하지 못했던 작업(Java 8의 숨겨진 기능 등)이 나타났습니다. 하지만 이번에는 더 많은 경험을 쌓았기 때문에 Java 9가 나오는 2016년 4월에 다음 버전을 완성할 수 있기를 바랍니다. 사실 저는 구체적인 계획을 세웠어요.

질문: "기본을 갖춘 Java 개발자"에 대한 다음 계획이 있나요?

이번 'Java 프로그래머로 양성하는 방법' 프로젝트는 매우 좋았고, 글쓰기 과정도 매우 즐거웠습니다. 그러나 나는 "Java의 최종 기술 매뉴얼"을 집필하는 과정에서 많은 에너지를 쏟았으며 아마도 이 책의 제2판을 집필하지 못할 수도 있을 것 같습니다. 나는 이 책의 원 출판사인 매닝(Manning)과 이야기를 나눴지만 최신 상황을 알지 못하기 때문에 이 책의 제2판이 나오지 않을 가능성이 매우 높습니다.

질문: Java 전문가와 일반 Java 프로그래머의 차이점은 무엇인가요?

프로그래머의 레벨은 피라미드라고 볼 수 있고, 대략 3레벨로 나눌 수 있다고 생각합니다. 맨 아래에는 매우 열심히 일하는 프로그래머들이 있지만 프로그래밍 자체에는 거의 관심이 없을 수도 있습니다. 그들은 또한 일을 잘 할 수 있지만 퇴근 후에는 프로그래밍에 대해 생각하지 않을 것입니다. 이는 정상적인 현상이며, 소프트웨어 산업에는 많은 프로그래머가 필요하며 이러한 수요는 여전히 증가하고 있습니다. 중급 수준의 프로그래머는 더 많은 일을 하고 싶어하고, 웹사이트에서 기술 뉴스와 뉴스를 읽고, 다음 버전의 진행 상황을 따르고, 자신의 기술에 관심을 갖고 있습니다. 이 수준의 프로그래머는 매우 흥미롭습니다. 최고 수준의 프로그래머는 항상 장인 정신과 기술의 본질에 매료됩니다. 이 피라미드의 꼭대기에 도달하면 스스로 배우고 기술에 대한 더 깊은 이해를 얻을 수 있는 피드백 루프가 생기기 시작합니다. 하지만 가장 어려운 부분은 2단계에서 1단계로 어떻게 돌파하느냐 하는 점인 것 같아요. 자신이 하는 일 이외의 지식에 조금이라도 관심이 있다면 자신만의 요점을 찾아야 합니다. 이 점은 사람마다 다릅니다. 일단 자신을 매료시키는 분야를 찾으면, 호기심에 이끌려 깊이 있게 공부할 수 있습니다.

좋은 오픈소스 개발자는 자신의 문제점을 찾고, 자신을 괴롭히는 문제를 해결해야 한다는 말이 있습니다. 이것이 대부분의 사람들이 오픈소스 소프트웨어에 관심을 갖는 이유이고, 많은 사람들이 자바 개발자라고 불리는 이유이다. 관심 있는 점을 찾았는데, 이유를 모르니까 계속 배우는 게 성장의 비결이에요.

질문: Java 8에 Lambda가 추가되었지만 개발자들 사이에서는 Java 구문이 너무 장황하다는 불만이 항상 있었습니다. 이것이 많은 개발자와 팀이 Java 사용을 꺼리는 주된 이유라고 생각하십니까?

그렇지는 않은 것 같아요. 제임스 고슬링(James Gosling)은 Java의 언어 설계와 Java가 현재의 모습인 이유를 세 문장으로 설명합니다. 첫 번째 문장은 영어로 "블루 칼라"라고 불리는 언어입니다. 블루 칼라 근로자는 일선 업무에 종사하는 사람들이고, 화이트 칼라는 사무실 및 관리자의 업무를 나타냅니다. Java는 현직 프로그래머가 실제 문제를 해결할 수 있도록 설계된 블루 칼라 언어입니다. Java는 실제 비즈니스 문제를 해결하는 실용적인 언어입니다.

제임스 고슬링(James Gosling)은 2014년 JavaOne 컨퍼런스에서 초기 버전의 Java에는 나타나지 않았던 Lambda와 일부 디자인에 대해 다음과 같이 말했습니다. “어떤 작업을 수행하는 올바른 방법을 찾지 못하면 아무것도 없습니다. 하다. 이 문장은 느리고 보수적인 진화 설계 철학을 표현합니다. Java가 무엇인지 이해하려면 이것을 이해해야 합니다. 많은 사람들은 Java가 오래되었고 프로그래밍 언어가 바뀌어야 한다고 생각하지만, 실제 변화는 자기 자신이라는 사실을 이해하지 못합니다. 그들은 능력이 발전하고 더 멀리, 더 깊이 보기를 원하며 언어는 이를 반영합니다. 언어가 바뀌어야 하는 것이 아니라, 이 아이디어를 생각해낸 프로그래머 자신이 바뀌어야 한다는 것입니다. Java는 보수적으로 설계된 언어였으며 앞으로도 그럴 것입니다. 이는 Java의 주요 장점이기도 합니다.

James는 Java를 설계하려는 원래 의도를 설명하면서 다음과 같이 말했습니다. 제가 설계할 때 사람들은 자동 메모리 관리를 원하고 강력한 타이핑을 원하지만 이러한 기능은 생산직 근로자를 겁나게 할 것입니다. 예를 들어 스몰토크(Smalltalk)는 훌륭한 언어이지만, 너무 발전했고 개발자가 애플리케이션을 구축할 때 실제로 생각하는 방식과 동떨어져 있습니다. 그래서 Java는 이러한 아이디어 중 일부를 상속받아 단순화하고 이러한 아이디어를 언어와 형식으로 구현했습니다. 이러한 것들은 이 언어 설계의 기본 동기를 설명합니다.

그래서 확실히 자바는 장황한 언어라고 할 수 있지만, 추가 내용은 읽기 쉽도록 하기 위한 것이라고 생각합니다. 특히 당신이 초보 또는 중급 프로그래머라면, 중복되어 보이는 단어가 도움이 될 수 있습니다. 사람들은 생산성에 대한 요구가 점점 더 높아지고 있음을 항상 기억할 것입니다. 하지만 코드는 여전히 작성됩니다. 그래서 저는 Java가 장황하다고 생각하지 않습니다. 비록 몇 가지 고급 기능을 추가할 수 있지만 어떤 것들은 언어에서 결코 변경할 수 없기 때문에 안타깝습니다. 물론 우리는 발전할 것입니다. 그러나 제가 항상 말했듯이 사람들은 항상 언어로 성취할 수 있는 것보다 문법에 너무 많은 관심을 둡니다.

질문: 요즘 많은 대기업(Paypal 등)이 Java에서 Node.js로 전환하고 있습니다. Java와 Node.js가 각각 잘하는 분야는 무엇입니까? ?

이 질문에는 오해가 있습니다. 실제로 Java를 버리고 Node.js로 전환하는 회사는 많지 않았습니다. Paypal의 Node.js 지원 부분은 작으며 대부분의 Paypal 실행 코드는 여전히 Java입니다. Node.js는 파일럿 프로젝트에 참여하고 있으며 이는 이해할 수 있는 일입니다. Node.js는 몇 가지 흥미로운 아이디어가 포함된 흥미로운 환경입니다. Node.js는 매우 젊고 동시에 심각한 문제도 많이 안고 있기 때문에 Node.js의 향후 발전을 예측하기에는 너무 이르습니다. 따라서 다양한 개발자 웹사이트에서 Node를 지원하는 목소리가 많고 GitHub에 Node를 사용하여 Ardruino를 작성하거나 하드웨어를 가지고 노는 등 흥미로운 프로젝트가 많이 있지만, 프로덕션 환경의 모든 제품 중에서 Java가 대부분의 코드 줄. 기업은 정당한 이유 없이 작동 중인 소프트웨어를 포기하지 않을 것입니다. Node.js를 사용하는 기업가가 많지만 기업가는 빠르게 왔다가 ​​떠납니다.

최근 몇 년간 흥미로운 제품 중 하나인 트위터의 발전 과정을 관찰해 보면 초기에는 Ruby on Rails를 사용했다는 것을 알 수 있습니다. 3~4년 전부터 매우 귀여운 만화 캐릭터인 실패고래가 웹사이트에 등장하기 시작했습니다. 당황스러운 일이었고 무슨 일이 일어나고 있는지 알아보기 위해 많은 조사를 했고, 루비의 가비지 컬렉션을 살펴본 후 그들은 할 수 있는 일이 아무것도 없다는 것을 알게 되었습니다. 동시에 Java 파일럿 프로젝트는 성공적이었으며 Java가 확장성 문제를 해결할 수 있다는 것을 깨달았습니다. 그 후 18개월에 걸쳐 일부 JRuby를 준비 장소로 사용한 다음 전체 시스템을 Java로 다시 작성했습니다. 최종 효과도 매우 좋습니다. Java를 중심으로 새로운 서비스와 새로운 아키텍처를 도입했습니다. 옛날에는 Ruby가 엔터프라이즈 소프트웨어의 미래로 여겨졌으나 오늘날 Ruby는 많은 프로그래밍 언어 중 하나일 뿐입니다. 현재 가장 널리 사용되는 세 가지 언어는 Java, JavaScript, C/C++이지만 대부분의 JavaScript 코드는 클라이언트 측에 있습니다. 이 세 가지 언어가 제거되면 다른 언어의 시장 점유율이 줄어들게 됩니다. 아주 작습니다.

질문: 지금까지 Java 애플리케이션용 가상 호스팅 모델에서는 별도의 JVM 인스턴스를 호스팅하기 위해 전체 x86 가상 머신을 할당해야 했습니다. 상대적으로 말하면 인스턴스도 별도의 Java 애플리케이션을 호스팅합니다. 이 방법은 매우 비효율적이지만 Java는 기본적으로 다중 테넌트 가상화 및 클라우드 컴퓨팅 구성을 지원하지 않습니다. 다행스럽게도 커뮤니티에서 클라우드 컴퓨팅 문제를 해결하기 위한 다중 테넌트 Java 솔루션을 찾을 수 있습니다. 어떤 솔루션이 프로덕션 환경에 적용할 수 있을 만큼 성숙하다고 생각하십니까?

여기에는 가상화와 클라우드 및 멀티 테넌시를 혼합하는 것이 완전히 정확하지 않습니다. 예를 들어, QCon Shanghai에서는 docker에 대한 많은 공유가 있었습니다(docker는 가상화에 의존하지 않는 플랫폼입니다). 멋진 공유 중 하나는 Chris Swan으로부터 나왔습니다. 그는 CPU 메모리를 가상 환경에서 Docker 기반 환경으로 옮기는 것의 이점을 보여주었습니다. 아직 완벽하지는 않지만 Docker에서 Java를 실행하는 것만으로도 이미 추가적인 이점을 얻을 수 있습니다. 클라우드와 가상의 관계를 명확하게 정리해야 합니다. 또한 여러 JVM 호스트를 설정할 수 있는 등 수행할 수 있는 다른 작업도 많이 있습니다.

그런데 이 질문이 실제로 묻고 있는 것은 멀티 테넌시입니다. 이 문제와 관련하여 제가 생각하는 챔피언으로 꼽히는 제품이 하나 있는데, 바로 와라텍입니다. Waratek은 핫스팟이 아닌 별도의 JVM을 분리하고 그 안에서 호스트 JVM을 실행할 수 있습니다. JVM에서는 Java 가상 다중 테넌트 JVC가 실행되며 JVC는 매우 가볍습니다. Waratek은 실제로 사용할 수 있는 매우 성숙한 제품이라고 생각합니다. Deutsche Bank는 방금 첫 번째 JVM을 Waratek으로 이전할 것이라고 발표했습니다. Deutsche Bank가 이 제품을 승인했기 때문에 한 번 공부해 볼 가치가 있을 것입니다. .

질문: Java는 Scala와 자주 비교됩니다. 이 두 언어의 설계 목적에는 어떤 차이점이 있나요? 앞으로 두 언어가 정확히 같은 방향으로 발전할 가능성이 있을까요?

Java와 Scala는 매우 다른 언어입니다. 이전에 Java의 디자인 철학에 대해 이야기했다면 이제 Scala의 디자인 철학과 그 차이점에 대해 이야기할 수 있습니다. 스칼라는 원래 학계에서 나온 언어였는데, 원래 마틴 오데르스키(Martin Odersky)가 만든 언어를 피자(Pizza)라고 불렀다. 당시 자바는 아직 버전 4였다. 이 때 피자는 점차 자바 패러다임과 비슷한 기능을 몇 가지 추가하기 시작했는데, 이것도 역시 추가됐다. Java 5에서. Pizza의 기능 중 일부는 패러다임 역할을 합니다.

Martin은 매우 똑똑한 사람이고 Scala도 훌륭한 디자인을 많이 가지고 있습니다. 하지만 동시에 이 언어에도 문제가 있습니다. 때때로 "주방 싱크대" 언어라고도 하는데, 이는 사람들이 언어와 애증 관계를 갖고 있음을 보여줍니다. 이 비유의 의미는 싱크대에 다양한 물건이 너무 많다는 것입니다. 이것은 실제로 Scala의 문제입니다. 기능이 너무 많습니다. 언어 디자인에는 자바 디자인 프로세스에서도 중요한 원칙인 보수주의라는 규칙이 있습니다. 특히, 새로운 기능을 추가할 때마다(구체적인 예는 "Java 프로그래머 육성"의 14페이지에 설명되어 있음) 새로운 문제가 발생할 수도 있습니다. 귀하의 언어에 200개의 기능이 있고 하나를 더 추가하고 싶다면 해당 언어가 다른 모든 기능과 어떻게 상호 작용하는지 확인해야 합니다. Scala는 지속적으로 새로운 기능을 추가하고 있습니다. 이러한 기능이 어떻게 상호 작용하는지 아는 것은 어렵습니다. 스칼라가 변화를 수용할 수 있는 매우 유연한 커뮤니티를 갖고 있다고 해도 언어 기능의 변화는 쉽지 않습니다. 그래서 Scala는 뛰어난 성능을 많이 가지고 있지만 어떤 기능을 원하는지, 어떤 기능은 건드릴 수 없는지 결정해야 한다는 것을 알게 될 것입니다. 팀으로 프로그래밍할 때는 문제가 되지 않습니다. 진짜 문제는 현대 사회의 소프트웨어 스택이 코드에만 의존한 적이 없다는 것입니다. 문제는 함수 라이브러리에서 비롯됩니다. 작업이 대상 객체뿐만 아니라 다른 것에도 영향을 미치는 일부 Scala 기능이 있습니다. Scala의 기능이 많을수록 이러한 문제가 더 쉽게 겹쳐집니다.

또한 바이너리 호환성 문제로 항상 어려움을 겪고 있습니다. Java, Sun, Oracle은 이것이 Java의 가장 중요한 설계 개념이라고 항상 믿어왔기 때문에 Java 1.0에서 프로그램을 작성하고 이를 컴파일하고 Java 8 가상 머신에 넣을 수 있으며 여전히 실행될 수 있습니다. 달리기 속도는 예전보다 몇 배 더 빨라질 것입니다. 스칼라는 이에 대해 약속한 적이 없으며, 이전 버전에서도 문제가 발생할 것이다. 라이브러리 공간에서 이 문제는 훨씬 더 심각합니다. 라이브러리를 업그레이드할 때마다 전체 시스템이 충돌하기 때문에 많은 프로젝트가 Scala를 포기했다는 것을 알고 있습니다.

그러므로 이 두 언어의 디자인 아이디어는 매우 다릅니다. 사람들은 항상 새로운 것을 좋아하고, 처음 시도하는 사람이 많은 혜택을 누리는 것도 좋지만, 두 번째로 시도하는 사람을 선호하는 경우도 많습니다. 첫 번째 사람이 실수하는 것을 지켜보고 그로부터 배울 수 있습니다. 그리고 Java는 다른 사람의 실수로부터 배우는 언어입니다. 방금 프로그래머의 피라미드에 대해 언급했는데, 스칼라의 역할은 최상위 프로그래머의 사고를 자극하는 데 더 가깝습니다. Java는 피라미드 전체에 적용되는 언어이며 특히 저수준 및 중간 수준 프로그래머에게 적합합니다. 나는 앞으로도 수년 동안 강력하고 건강한 Scala 커뮤니티가 있을 것이라고 믿으며 그들과 아이디어를 교환하고 싶습니다. 하지만 스칼라가 틈새 언어에서 대중 언어로 성장할 것이라고는 생각하지 않습니다. 현재 지구상에는 수백 명의 Scala 프로그래머가 있지만 이 숫자는 최대 Java 프로그래머의 1%에 불과하며 이 비율은 계속해서 증가하지 않을 것 같습니다.