JMOD 형식은 기존 JAR 형식과 다소 유사하지만, 자바 8에서처럼 별도의 공유 객체 파일을 제공하지 않고, 네이티브 코드를 단일 파일의 일부로 포함할 수 있도록 수정됐다. 메이븐에 모듈을 게시하는 등 대부분의 개발자의 경우, 자체 모듈을 JMOD보다는 모듈식 JAR로 패키징하는 것이 더 좋다. / JIMAGE 형식은 자바 런타임 이미지를 나타내는 데 사용된다. 자바 8 이전까지는 두 가지 런타임 이미지(JDK와 자바 실행 환경(Java Runtime Environment, JRE))만 존재했지만, 이는 대부분 역사적 우연이었다. 오라클은 완전한 모듈화를 향한 디딤돌로 자바 8(및 콤팩트 프로파일)과 함께 Server JRE를 도입했다. 이 이미지는 기본적으로 서버 측 애플리케이션의 요구 사항에 맞춰 더 작은 공간을 차지하기 위해 일부 기능(예: GUI 프레임워크)을 제거했다.
--- p.34

자바 11에서 다양한 주문을 모델링하고 싶다고 가정해보겠다. 이 경우 두 가지 대안 중 하나를 선택해야 한다. 첫째, 실제 타입을 보유하는 상태 필드를 가진 단일 구현 클래스(또는 레코드)인 FXOrder를 선택할 수 있다. 이 패턴은 상태 필드가 열거형이고 이 객체가 실제로 어떤 타입을 의미하는지를 나타내는 정보를 제공함으로써 작동한다. 이 패턴은 필드가 가질 수 있는 모든 타입의 경우를 애플리케이션 프로그래머가 일일이 체크하고 추적해야 하므로 차선책이 될 수 있다. 또는 기본 추상 클래스인 BaseOrder를 선언하고 이를 서브클래싱해서 구체적인 타입인 MarketOrder와 LimitOrder를 가지도록 할 수 있다.
--- p.86

많은 오퍼레이션 코드에는 여기저기서 몇 바이트를 절약하기 위한 바로 가기 형식shortcut form이 있다. 일반적인 패턴은 특정 로컬 변수가 다른 변수보다 훨씬 더 자주 액세스되므로 로컬 변수를 인수로 지정하는 대신 ‘로컬 변수에 직접 일반 연산을 수행’하라는 것을 의미하는 특수한 오퍼레이션 코드를 사용하는 것이 합리적이다. 예를 들어 load/store 패밀리 내에서 aload_0, dstore_2와 같은 오퍼레이션 코드는 동등한 바이트 시퀀스인 aload 00 또는 dstore 02보다 1바이트 더 짧다.
--- p.138

FutureTask 클래스는 흔히 사용되는 Future 인터페이스의 구현 중 하나이며, Runnable도 구현한다. 이는 FutureTask를 실행자에게 전달할 수 있다는 것을 의미한다. FutureTask의 API는 기본적으로 Future와 Runnable이 결합된 형태다. get(), cancel(), isDone(), isCancelled(), run()과 같은 메서드가 있다. 그러나 실제 작업을 수행하는 마지막 메서드는 클라이언트 코드가 직접 호출하는 것이 아니라 실행자에 의해 호출된다. / FutureTask에는 편리한 생성자 두 가지가 제공된다. 하나는 Callable을 사용하고, 다른 하나는 Runnable을 사용한다(이 경우에는 Executors.callable()을 사용하여 Runnable을 Callable로 변환한다). 이는 작업을 유연하게 처리할 수 있는 방법을 제공하며, 작업을 Callable로 작성한 다음 Runnable 형태인 FutureTask로 래핑해서 실행자에게 실행을 예약하고 필요한 경우 취소할 수 있다.
--- p.245

컨테이너는 배포를 위한 더욱 일관된 패키징의 세계를 열었다. 예전에는 애플리케이션의 바이트들을 배포 환경에 복사하는 방법, 운영체제 의존성을 관리하는 방법, 심지어 프로세스 시작을 관리하는 방법까지 모두 제각각이었다. 컨테이너는 이 모든 것에 대한 해답을 제공하므로 엄청난 양의 도구와 사용자 정의 스크립트가 필요하지 않다. 또한 배포 환경과 컨테이너의 콘텐츠 사이에 단열 기능을 제공한다. 컨테이너 엔진은 컨테이너 내부를 어떻게 배치할지 신경 쓸 필요 없이 요청이 있을 때 스스로 시작하는 방법만 알면 된다. 컨테이너 이미지의 패키징은 시스템 계층에 대해 선언적이고, 소스 컨트롤된 설명을 사용한 서비스형 인프라스트럭처(infrastructure as a service, IaaS)의 중요한 예다. 과거에는 주의 깊은 명령형 구성이 필요했던 것과 달리 현재는 더욱 간편하게 이뤄진다.
--- p.486

하스켈과 같은 많은 함수형 언어는 지연 평가에 크게 의존한다. 코틀린은 JVM 언어로, 핵심 실행 모델에서 지연 평가를 중심으로 두지 않는다. 그러나 Lazy 인터페이스를 통해 필요한 곳에 지연을 위한 최상의 지원을 제공한다. 이것은 처리를 지연시키거나 아예 건너뛰려고 할 때, 표준 구조를 제공한다. / 일반적으로 Lazy를 직접 구현하지 않고 lazy() 함수를 사용해서 인스턴스를 생성한다. 가장 간단한 형태로 lazy()는 람다를 취하며 해당 람다의 반환 타입이 반환된 인터페이스 T의 타입을 결정한다. 람다는 value가 명시적으로 요청할 때까지 실행되지 않는다. 또한 다음과 같이 이미 값을 계산했는지 확인할 수도 있다.