호환성(compatibility): 자바는 이미 성숙한 플랫폼이기 때문에 하위 호환성을 깨뜨리는 변화에 대해서 극도로 민감하다. 이미 많은 벤더들이 크든 작든 자바 플랫폼에 많은 투자를 하고 있기 때문에, 새로운 자바 플랫폼이 이전 환경과 호환되지 않는다면 막대한 규모의 경제적 손실이 발생할 것이다. 실례로 Java 5에 Generics를 추가하는 여러 가지 대안 중에 가장 효율적인 방법은 아니었지만 JVM을 전혀 수정하지 않는 대안이 선택된 바 있다.

개발의 편의(Ease of Development): Java 5의 Generics나 어노테이션(annotation)은 개발의 편의를 위한 지원이라 볼 수 있다. 이와 관련된 Java 6의 항목은 스크립트 언어 지원, 쉬운 데이터베이스 접근, 소스 코드 컴파일, 어노테이션 처리, GUI 디자인 도구 등을 들 수 있다.

진단, 모니터링, 관리(Disposability, Monitoring & Management): Java 5에 포함되었던 JMX(Java Management Extension)이나 JVMTI(Java Virtual Machine Tool Interface) 등이 여기에 해당한다. 특히 JVMTI는 기존의 디버깅 인터페이스(JVMDI)와 프로파일링 인터페이스(JVMPI)를 통합해서 하나로 만들어서, 다양한 자바 개발 도구 작성에 도움을 주고 있다. 여기에 디버깅 플래그 없이 시작된 어플리케이션의 진단이나, 현재 수행 중인 자바 어플리케이션의 힙 메모리를 살펴볼 수 있는 기능 등이 추가적으로 필요할 것이다.

기업 환경 데스크톱(Enterprise Desktop): 최근에는 웹브라우저 기반의 가벼운 클라이언트(thin client)가 가지는 한계 때문에 리치 클라이언트(rich client)가 다시 주목을 받고 있다. 현재 자바는 네이티브 데스크톱 환경과의 통합이나 텍스트 출력, 테이블 표시 및 조작 등의 기능이 부족한 상태이다.

XML과 웹 서비스: 원래 자바 5에서 웹 서비스 관련 클라이언트 스택을 모두 제공할 예정이었는데, 릴리즈 시간을 맞추지 못하고 제외된 바가 있다. 그 사이에 XML과 웹 서비스에 관련된 요구 사항은 더욱 커졌는데, 자바 6은 이러한 요구사항을 반영하고 있다.

투명성(transparency): Java 5까지 자바 플랫폼의 개발 과정을 보면, 썬이 작업을 끝마칠 때까지 어떤 식으로 구현되는지에 대한 내용을 전혀 알 수가 없었다. 반대로 자바 6 이후부터는 이러한 명세서(specification) 작성과 참조 구현(reference implementation) 개발 과정에 투명성을 주었다. 현재도 자바 개발 사이트에서 자바 6의 JDK를 다운받아 설치하고 실행해 볼 수 있다.

자바 6에 포함된 가장 큰 변화 중에 하나는, 클래스 파일의 포맷을 일부 변경하였다는 점이다. 이 변경은 “Split Verification”이란 개념을 지원하기 위해서이다.

현재 자바 클래스 파일을 JVM이 로딩할 때는 올바른 클래스 파일인지 검증하는 과정을 거친다. 그런데 클래스 파일 검증은 상당한 시간이 걸리고 메모리 자원도 많이 요구하는 프로세스이므로, Java ME 같이 리소스가 제한된 환경에서는 클래스 파일 검증 자체가 힘들어지는 경우가 종종 있었다. 그래서 Java ME를 사용하는 일부 플랫폼은 클래스 파일 검증 기능을 사용하지 않는 경우도 생겼는데, 이렇게 하면 성능은 향상되어도 심각한 보안 문제를 초래할 수 있다.

Java ME(CDC, CLDC)는 이에 대한 대안으로 클래스 파일을 생성한 쪽에서 일부 검증을 미리해서 보낸 후에, 클래스를 로딩하는 쪽은 간단한 계산만으로 클래스 파일이 안전하다는 것을 증명할 수 있게 만들었다. 원래는 JVM 쪽에서 모두 해야 할 검증의 임무를 분담했다는 점에 착안하여 이러한 검증 과정을 "Split Verification"이라고 부른다. Java 6에서는 "Split Verification"을 SE에서도 지원하기 위해 클래스 파일 포맷을 일부 수정하는 작업을 한 것이다.