GWT 툴킷: Java를 사용하여 강력한 JavaScript 프런트 엔드 구축

이전에 Google Web Toolkit으로 알려졌던 GWT Web Toolkit은 Java 프로그래밍 언어를 사용하여 복잡한 브라우저 기반 애플리케이션을 빌드하고 최적화하기 위한 개발 도구 세트입니다.

GWT가 "웹 앱을 작성하기 위한 또 다른 Java 도구"가 아닌 이유는 툴킷의 핵심이 Java를 JavaScript(HTML 및 CSS는 물론)로 변환하여 개발자가 프론트 엔드 웹 애플리케이션을 작성할 수 있도록 하는 컴파일러라는 사실입니다. Java의 모든 장점을 활용합니다.

GWT에는 웹 플랫폼과의 인터페이스를 위한 강력한 상호 운용성 아키텍처가 포함되어 있으므로 Java와 JavaScript를 혼합하여 사용하는 것도 쉽습니다. JNI(Java Native Interface)를 통해 JVM(Java Virtual Machine)이 플랫폼별 루틴을 호출할 수 있는 것과 마찬가지로(예: 특정 하드웨어 기능에 액세스하거나 다른 언어의 외부 라이브러리 사용) GWT를 사용하면 대부분의 응용 프로그램을 Java로 만든 다음 필요한 경우 특정 웹 API를 사용하거나 기존 JavaScript 라이브러리를 활용하여 "네이티브로 전환"하고 JavaScript로 이동합니다.

GWT는 Google 제품으로 태어났지만 2011년 말에 오픈 소스로 졸업했으며 현재 GWT Open Source Project 라는 이름으로 Apache License(버전 2)로 릴리스됩니다. Google, RedHat, ArcBees, Vaadin, Sencha를 비롯한 여러 회사의 대표와 커뮤니티의 독립 개발자로 구성된 운영 위원회에서 관리합니다.

과거와 미래의 GWT

Google Web Toolkit은 2006년에 처음 출시되었습니다. Google 엔지니어가 AdWords, Google Wallet 및 Google Flights와 같은 복잡한 브라우저 기반 응용 프로그램을 개발하는 데 도움이 되는 도구로 만들어졌으며 최근에는 Google 스프레드시트 및 받은 편지함 애플리케이션.

2006년에는 브라우저(및 JavaScript 인터프리터)가 표준화되지 않았습니다. 프론트 엔드 코드는 느리고 버그가 많으며 안정적으로 사용하기 어려웠습니다. 웹 개발을 위한 고품질 라이브러리와 프레임워크가 거의 완전히 부족했습니다. 예를 들어 jQuery는 올해까지 존재하지도 않았습니다. 따라서 Google의 엔지니어는 대규모 웹 애플리케이션을 개발할 수 있도록 기존 도구와 역량을 활용하기로 결정했습니다. Java는 잘 알려져 있고 Eclipse와 같은 IDE에 완벽하게 통합되어 있는 그들의 요구에 가장 적합한 언어였습니다. 그래서 Google Web Toolkit이 시작되었습니다.

목표는 브라우저 간의 차이점을 숨기고 Java 컴파일러 내에서 효율적인 JavaScript를 작성하는 데 필요한 트릭을 캡슐화하여 개발자가 브라우저 기술의 압제에서 벗어나도록 하는 것이었습니다.

물론 지난 10년 동안 웹은 변했습니다. 브라우저는 더 빨라지고 구현 표준에 수렴되었으며 jQuery, Angular, Polymer 및 React를 포함하여 멋진 프론트엔드 프레임워크와 라이브러리가 많이 개발되었습니다. 따라서 자연스럽게 물어볼 수 있는 첫 번째 질문은 "GWT가 여전히 유용한가요?"입니다.

한마디로: 그렇습니다 .

현대 웹 개발의 맥락에서 브라우저를 대상으로 하는 것은 불가피하며 JavaScript는 프론트 엔드 애플리케이션의 공용어 가 되었습니다. 그러나 물론 다른 도구와 언어는 다른 작업에 더 적합합니다. 소수의 유사한 프로젝트와 함께 GWT는 개발자가 JavaScript를 사용하도록 제한하지 않고 브라우저를 대상으로 하는 것을 목표로 합니다.

GWT와 같은 "웹으로 컴파일" 도구의 개발 및 사용은 가까운 장래에 World Wide Web 컨소시엄의 WebAssembly 그룹에 의해 촉진될 것입니다. JavaScript로 컴파일하는 도구를 위한 광대한 공간이 있을 뿐만 아니라, 이 접근 방식은 계산의 일부를 브라우저로 오프로드하고, 기존 코드와 라이브러리를 재사용하고, 백엔드와 프론트엔드 간에 코드를 공유하는 등 다양한 컨텍스트에서 실제 요구 사항을 충족할 수 있습니다. , 기존 역량과 워크플로를 사용하고 다양한 언어의 기능을 활용합니다(예: GWT의 경우 정적 입력).

GWT 프로젝트는 곧 버전 2.8을 출시할 예정이며 버전 3.0이 개발 중이며 작업이 크게 개선되었습니다.

• JavaScript와의 재창조된 상호 운용성
• 개선된(거의 완전히 재작성된) 컴파일러
• 최신 Java 지원(예: 람다)

사실 GWT 3.0의 대부분의 기능은 이미 공개된 Git 저장소에서 사용할 수 있습니다. 여기에서 트렁크를 확인하고 여기 문서에 따라 GWT를 컴파일하십시오.

GWT 커뮤니티

GWT가 2011년에 오픈 소스가 된 이후로 커뮤니티는 프로젝트 발전에 중추적인 역할을 맡았습니다.

모든 개발은 gwt.googlesource.com에서 호스팅되는 Git 리포지토리에서 이루어지며 모든 코드 검토는 gwt-review.googlesource.com에서 수행됩니다. 이 페이지에서 툴킷 개발에 관심이 있는 사람은 누구나 기여할 수 있으며 커뮤니티에서 어떤 작업을 하고 있는지 확인할 수 있습니다. 지난 몇 년 동안 Google 직원이 아닌 사람들의 새 패치 비율이 2012년 약 5%에서 지난해 약 25%로 증가하여 참여가 증가하고 있음을 확인했습니다.

올해 커뮤니티는 미국과 유럽에서 몇 가지 큰 회의를 위해 모였습니다. Vaadin이 주관하는 GWT.create는 지난 1월 독일 뮌헨과 캘리포니아 마운틴뷰에서 개최되었으며, 수십 개국에서 600명이 넘는 참가자가 참가했습니다. 11월 11일 이탈리아 피렌체에서 커뮤니티 주도 GWT 컨퍼런스인 GWTcon의 두 번째 에디션을 개최합니다.

GWT는 무엇에 적합합니까?

Vaadin에서 발표하는 GWT 툴킷에 대한 연례 설문조사에서는 GWT의 개발 진화, 개발자가 툴킷에 대해 어떻게 느끼는지, 좋은 점과 나쁜 점 등에 대해 논의합니다. 또한 이 설문조사를 통해 툴킷이 무엇을 위해 사용되고 있는지, 사용자 커뮤니티가 어떻게 변화하고 있으며, 툴킷의 미래에 대한 개발자의 기대치를 파악할 수 있습니다.

2015년 GWT의 미래 보고서 는 여기에서 볼 수 있으며, GWT가 대규모 웹 애플리케이션을 구축하는 데 매우 인기가 있음을 분명히 합니다. 예를 들어, 14페이지에 "대부분의 응용 프로그램은 데이터가 많고 하루에 많은 시간을 작업해야 하는 비즈니스 응용 프로그램입니다."라고 명시되어 있습니다.

예상대로 GWT의 자연 환경은 코드의 유지 관리가 중요하고 대규모 팀이 Java 언어의 구조에서 이점을 얻는 대규모 웹 응용 프로그램 분야라고 쉽게 결론지을 수 있습니다.

반면에 GWT에서 생성된 코드에 대한 벤치마크를 보면(예: 작년 GWT.create 컨퍼런스의 기조연설, 7, 8, 11페이지) 성능 및 코드 크기에 비해 컴파일된 JavaScript는 놀랍도록 훌륭합니다. 올바르게 사용하면 얻은 성능은 손으로 쓴 최고의 JavaScript와 비슷합니다. 결과적으로 GWT를 사용하여 Java 라이브러리를 웹으로 이식하는 것이 실제로 가능합니다.

이것은 GWT에 대한 또 다른 이상적인 시나리오를 조명합니다. Java 에코시스템은 JavaScript에서 바로 사용할 수 있는 고품질 라이브러리로 가득 차 있습니다. GWT 컴파일러를 사용하여 이러한 라이브러리를 웹에 적용할 수 있습니다. 즉, GWT를 사용하면 Java와 JavaScript 모두에서 사용할 수 있는 라이브러리를 혼합하여 브라우저에서 실행할 수 있습니다.

이 접근 방식은 PicShare 개발에서 볼 수 있습니다. 여기에서 일반적으로 웹용으로 고려되지 않는 여러 Java 라이브러리(예: NyARToolkit)를 GWT를 사용하여 브라우저로 이식하고 WebRTC 및 WebGL을 포함한 웹 API와 결합하여 다음을 수행할 수 있습니다. 완전히 웹 기반 증강 현실 도구를 얻으십시오. 지난 1월 2015 GWT.create 컨퍼런스에서 PicShare를 발표하게 된 것을 자랑스럽게 생각합니다.

Under the Hood: Java를 JavaScript로 전환

GWT Toolkit은 다소 복잡한 도구 세트이지만 Eclipse와의 놀랍도록 사용하기 쉬운 통합 덕분에 누구나 즉시 사용을 시작할 수 있습니다.

GWT를 사용하여 간단한 애플리케이션을 만드는 것은 Java 개발 프로젝트에 대한 배경 지식이 있는 사람이라면 누구에게나 비교적 쉽습니다. 그러나 "실제로 일어나는" 상황을 이해하려면 툴킷의 주요 구성요소를 분석할 가치가 있습니다.

• 자바-자바스크립트 변환기
• 에뮬레이트된 Java 런타임 환경
• 상호 운용성 계층

GWT의 최적화 컴파일러

컴파일러가 어떻게 작동하는지에 대한 심도 있는 설명은 아주 일찍부터 고도로 기술적인 것이 되어 깊이 파고들 필요는 없지만 일반적인 개념 중 일부는 살펴볼 가치가 있습니다.

가장 먼저 이해해야 할 것은 GWT가 소스 코드 수준에서 번역을 통해 Java를 JavaScript로 컴파일한다는 것입니다. 즉, Java 소스가 JavaScript 로 번역됩니다(기술 용어로 변환됨). 이것은 자바 바이트코드를 실행하는 자바스크립트로 작성된 일종의 자바 가상 머신을 갖는 것과 대조적입니다. (이는 실제로 가능하며 Doppio에서 사용하는 접근 방식이지만 GWT가 작동하는 방식은 아닙니다.)

대신 Java 코드는 코드의 구문 요소를 나타내는 추상 구문 트리(AST)로 나뉩니다. 그런 다음 동등한(최적화된) Javascript AST에 매핑되고 최종적으로 실제 JavaScript 코드로 다시 변환됩니다.

트랜스파일의 장단점을 평가하는 것은 이 게시물의 목적과 거리가 멀지만 이 방법을 사용하면 GWT가 브라우저 고유의 다른 기능과 함께 JavaScript 인터프리터의 가비지 수집 서비스를 직접 활용할 수 있다는 점을 관찰하겠습니다.

물론 까다로운 부분도 있습니다. 예를 들어, JavaScript에는 Java의 64비트 long 정수 유형을 포함할 수 없는 숫자 유형이 하나만 있으므로 long 유형은 컴파일러에서 몇 가지 특별한 처리가 필요합니다. 또한 Java 정적 유형 지정은 JavaScript에서 직접적인 의미가 없으므로 예를 들어 변환 후 유형 변환 작업을 동일하게 유지하기 위해 특별한 주의를 기울여야 합니다.

반면에 트랜스파일의 쉽게 이해할 수 있는 이점은 GWT가 Java 수준 과 JavaScript 수준에서 최적화(크기와 성능 모두에 대해)를 수행할 수 있다는 것입니다. 결과 표준 JavaScript 코드는 배포 파이프라인에서 추가로 처리될 수도 있습니다. 예를 들어, 이제 표준 GWT 배포에 통합된 일반적인 관행에는 고도로 전문화된 JavaScript-to-JavaScript Closure Compiler(Google 신의 또 다른 선물)를 사용하여 변환기의 JavaScript 출력 최적화가 포함됩니다.

내가 아는 GWT 컴파일러에 대한 가장 심도 있는 설명은 이 슬라이드 데크와 그 출처에 대한 원문에서 찾을 수 있습니다. 여기에서 코드 분할을 수행하는 GWT의 기능, 브라우저에서 독립적으로 로드할 여러 개의 개별 스크립트 파일을 생성하는 기능과 같은 컴파일 프로세스의 다른 멋진 기능에 대한 세부 정보를 찾을 수 있습니다.

에뮬레이트된 JRE

Java-to-JavaScript 컴파일러는 거의 모든 Java 응용 프로그램이 의존하는 핵심 라이브러리를 제공하는 JRE(Java Runtime Environment)의 구현으로 보완되지 않는 한 새로운 것에 불과합니다. 대략적으로 말하자면, Collections 또는 String 메소드 없이 Java에서 작업하는 것은 실망스러울 것이며 물론 이러한 라이브러리를 이식하는 것은 엄청난 작업입니다. GWT는 이 구멍을 소위 에뮬레이트된 JRE로 채웁니다.

Emulated JRE는 Java JRE를 완전히 다시 구현한 것이 아니라 클라이언트 측에서 유용하고 사용할 수 있는 일종의 클래스 및 메소드 선택입니다. Java JRE에 있지만 Emulated JRE에서는 찾을 수 없는 기능은 세 가지 범주로 나뉩니다.

• 클라이언트 측으로 이식할 수 없는 것. 예를 들어, java.lang.Thread 또는 java.io.File 은 Java와 동일한 의미를 가진 브라우저에서 구현할 수 없습니다. 브라우저 페이지는 단일 스레드이며 파일 시스템에 직접 액세스할 수 없습니다.

• 구현할 수 있지만 코드 크기, 성능 또는 종속성 측면에서 "비용이 너무 많이" 드는 것이므로 커뮤니티에서 GWT 내부에 두지 않는 것을 선호합니다. 예를 들어 이 범주에 포함된 Java 리플렉션( java.lang.reflect )은 트랜스파일러가 각 유형에 대한 클래스 정보를 유지해야 하고 컴파일된 JavaScript의 크기가 커지도록 합니다.

• 아무도 관심을 가지지 않았기 때문에 구현되지 않은 것입니다.

Emulated JRE가 필요에 맞지 않는 경우(예: 제공되지 않은 클래스가 필요한 경우), GWT를 사용하여 고유한 구현을 작성할 수 있습니다. <super-source> 태그를 통해 사용할 수 있는 이 강력한 메커니즘을 사용하면 에뮬레이트되지 않은 JRE의 일부를 사용하는 새로운 외부 라이브러리를 적용할 때 문제를 피할 수 있습니다.

JRE의 일부를 완전히 구현하는 것은 지나치게 복잡하거나 불가능할 수도 있습니다. 따라서 특정 작업의 경우 고유한 구현이 특정 경우에 작동하더라도 Java JRE의 의미를 엄격하게 따르지 않을 수 있습니다. 실제로 클래스를 프로젝트에 다시 제공하는 것을 고려하고 있다면 포함된 각 클래스가 원래 Java JRE와 동일한 의미를 따르는 것이 에뮬레이트된 JRE에 대해 가장 중요하다는 것을 기억하십시오. 이를 통해 누구나 Java 코드를 JavaScript로 재컴파일할 수 있고 예상한 결과를 얻을 수 있다고 믿을 수 있습니다. 커뮤니티에 코드를 다시 제공하기 전에 항상 코드가 철저히 테스트되었는지 확인하십시오.

상호 운용성 계층

실제 웹 애플리케이션 제작을 위한 효과적인 도구가 되려면 GWT를 통해 개발자가 기본 플랫폼과 쉽게 상호 작용할 수 있어야 합니다. 즉, 브라우저와 DOM입니다.

처음부터 GWT는 JSNI(JavaScript Native Interface)를 통해 이러한 상호 작용을 지원하도록 구축되어 브라우저 내 API에 쉽게 액세스할 수 있습니다. 예를 들어, GWT 컴파일러에 고유한 구문 기능을 사용하여 다음 Java 코드를 작성할 수 있습니다.

 public static native void nativeMethod(T1 a1, T2 a2, ...) /*-{ //place your JavaScript code here }-*/;

JavaScript에서 메소드 본문을 자유롭게 구현할 수 있습니다. JavaScriptObject(JSO)에서 JavaScript 개체를 래핑하고 Java 코드에서 액세스할 수 있도록 만들 수도 있습니다.

이 레이어가 작동하는 위치의 예는 UI 구성 컨텍스트에서 찾을 수 있습니다. 주류 Java는 항상 표준 위젯 툴킷을 사용하여 기본 운영 체제의 창 및 입력 시스템에 액세스하기 위해 Java 기본 인터페이스를 활용하여 UI 요소를 구축했습니다. GWT의 상호 운용성 계층은 동일한 작업을 수행하므로 기존 위젯이 브라우저 내에서 원활하게 작동합니다. 유일한 차이점은 이 경우 기본 시스템이 브라우저와 DOM이라는 것입니다.

그러나 기본 프론트 엔드 프레임워크는 최근 몇 년 동안 빠르게 개선되었으며 오늘날에는 GWT의 위젯에 비해 상당한 이점을 제공합니다. 이러한 프레임워크가 정교해짐에 따라 JSNI에서 구현하려는 시도는 상호 운용성 계층 아키텍처의 단점을 노출했습니다. 버전 2.7부터 GWT는 Java 주석을 기반으로 하는 새로운 접근 방식인 JsInterop을 도입하여 GWT 클래스를 JavaScript와 빠르고 쉽게 통합할 수 있습니다. 더 이상 JSNI 메소드나 JSO 클래스를 작성할 필요가 없습니다. 대신 @JSType 또는 @JSProperty 와 같은 주석을 사용하면 기본 JavaScript 클래스가 Java인 것처럼 작업할 수 있습니다.

JsInterop의 전체 사양은 아직 진행 중이며 최신 업데이트는 GWT 저장소에서 소스를 컴파일해야만 시도할 수 있습니다. 그러나 이것이 GWT가 진화하는 웹 플랫폼을 따라갈 수 있도록 하는 새로운 방향이라는 것은 이미 분명합니다.

JsInterop을 활용하는 진행 중인 프로젝트 중 하나는 최근 출시된 gwt-polymer-elements로, Polymer의 모든 Iron 및 Paper 요소를 GWT에서 사용할 수 있습니다. 이 라이브러리에서 흥미로운 점은 개발자가 Java API를 손으로 생성할 필요가 없다는 것입니다. 이 프로젝트는 gwt-api-generator를 사용하여 Polymer 라이브러리와 JSDoc 주석을 구문 분석하여 대부분의 인터페이스를 직접 생성합니다. 이렇게 하면 바인딩을 최신 상태로 쉽게 유지할 수 있습니다.

마지막 단어

지난 2년 동안 컴파일러, 상호 운용성 계층, 생성된 코드의 성능 및 크기가 향상됨에 따라 GWT가 "또 다른 웹 개발 도구"일 뿐만 아니라 대규모의 복잡한 웹 응용 프로그램 개발 및 더 간단한 응용 프로그램을 멋지게 만들기 위한 탁월한 선택이 될 수도 있습니다.

저는 개발자와 컨설턴트로 일할 때 매일 GWT를 사용하지만, 브라우저 기능의 한계를 뛰어넘고 최신 웹 응용 프로그램이 데스크탑 응용 프로그램만큼 강력할 수 있음을 보여줄 수 있기 때문에 대부분 GWT를 좋아합니다.

GWT 프로젝트의 커뮤니티는 정말 활발하며 GWT를 기반으로 하는 새로운 라이브러리, 프로젝트 및 애플리케이션이 지속적으로 제안되고 있습니다. 플로렌스에서 커뮤니티 중심의 GWTcon2015가 11월 11일에 열립니다. 이 지역에 계시다면 핵심 개발자들을 만나 이 놀라운 툴킷의 발전에 참여할 수 있는 모든 기회에 대해 배우시기 바랍니다.