안드로이드는 자바와 동일합니까? 제가 말하는 것은 동등하지 않습니다. 제가 말하는 것은 P = NP 에서처럼 동등합니다.
동등한 클래스/바이트 코드 형식은 여러 수준에서 Android 와 Java 는 분명히 동일합니다. 안드로이드 응용 프로그램은 Java 언어로 작성되었으며 JDK 의 javac (또는 ECJ 와 같은 유사한 도구) 를 사용하여 컴파일됩니다. 이 프로세스는 표준 Java 바이트 코드 (. 클래스 파일) 을 참조하십시오. 이 파일들은 다음으로 변환됩니다. Android 의 dex 파일, Java 클래스 파일이며 사용 관점에서 형식이 다릅니다. 예, 이것은 더 나은 형식입니다. 손의 디자인은 1994 부터 크게 개선되었다. 하지만 GIF 형식의 그림을 더 고급스럽고 완벽하며 완전히 동등한 PNG 형식으로 변환할 수 있는 것처럼 바이트 스트림은 완전히 다릅니다.
동등한 파일 형식은 세부적인 면에서 크게 다르며, 주로 최적화를 위한 것이다. 예를 들어, 비효율적인 비디오 데이터 스트림에만 만족하고 여러 프레임에 걸쳐 하이 엔드 압축 기술을 사용하지 않는다면 MPEGLA 비디오 디코딩 특허의 번거로움을 피할 수 있습니다.
안드로이드 특정 클래스 파일 디자인에는 몇 가지 동기가 있습니다. 이는 Sun 의 지적 재산권 보호와의 충돌을 피하기 위해 분명히 주요 요인이다. 어쨌든 구글은 자바에서 아직 멀었다. 두 파일 형식은 매우 유사합니다. 이들은 특정 기본 데이터 구조에서 다르지만 문법적으로 일관되며 동일한 정보를 저장합니다. JavaSE 또는 JavaME VM 에서는 "Android 클래스" 를 로드하기 위해 시스템 클래스 로더에. dex 파서를 쉽게 추가할 수 있다고 생각합니다.
안드로이드 SDK 는 에 의존합니다. 자바-> 。 클래스->; 사실. Dex 변환은 보잘것없고 손실이 없다. "손실되지 않음" 사실은 매우 중요합니다. GIF = PNG 이면 손상된 JPG 파일과는 달리 동일한 정보를 디코딩할 수 없습니다. JVM 과 Dalvik 이 독립적이라면 컴파일된 코드를 다른 코드로 변환하는 비교적 간단한 도구를 작성하기가 어렵습니다. 손실 없음: 정보 손실 없음, 중복성을 사용하여 한 VM 에서 일류이지만 다른 VM 에서는 그렇지 않으며 한 VM 에서 다른 VM 의 핵심 API 를 구현하기 위해 추가 런타임 계층이 필요하지 않습니다.
나는 dx 변환기가 얼마나 복잡한지 안다. 나는 그것의 소스 코드를 보았다. 그 바이트 코드 변환기는 SSA 를 통해 구성된 거대하고 완전한 기능을 갖춘 디컴파일/재컴파일 프로그램입니다. 하지만 이 변환기는 개념적으로 여전히 중요하지 않습니다. Java 바이트 코드에서 Dalvik 바이트 코드로의 매핑은 설계상 부드럽습니다. 레지스터 아키텍처의 미세 부분을 기준으로 스택을 최적화합니다. VM 계층의 유형 체계와 같은 중요한 것은 완전히 일치한다. ) 을 참조하십시오
VM 이 Dalvik 및 JVM 과 동일하다는 것을 쉽게 알 수 있습니다. 소스 코드나 바이트 코드 형식뿐만 아니라 런타임 버전도 마찬가지입니다. 일단 "안드로이드 클래스" 가 Dalvik VM 에 로드되면 Java 클래스처럼 실행되고 작동합니다. Java 프로그래밍 (고급 및 저급 세부 사항) 을 알고 있다면 Android 프로그래밍도 알고 있습니다. 너는 단지 새로운 API 와 프레임워크 개념을 배우기만 하면 된다. 이들은 피어 시스템입니다.
너는 마이크로소프트의 것을 기억하고 있다. 그물? 언제. 네트가 태어나자마자 자바 진영은 신속하게 비난에 반격했다. 자바 표절망. 나도 그 중 하나이지만, 오늘 나는 문제를 더 잘 보았다. 예, 심각한 표절의 산물이었습니다. C# 1.0 은 ... 한 언어와 다른 언어를 구별하는 가장 쉬운 방법은 ToString () 과 toString () 과 같은 일반적인 스타일을 보는 것입니다. 하지만 가장 중요한 VM 규범에서 마이크로소프트는 많은 숙제를 했다. CLR, CLI, 핵심 프레임워크는 모두 Java 와 매우 다르므로 등식 JVM = CLR 이라고 할 수 없습니다. 간단한 파일 형식 변환 도구를 사용하여 컴파일된 Java 클래스를 에서 사용할 수 있도록 변환할 수 없습니다. NET 런타임.
증거를 원하십니까? 너는 IKVM 만 보면 알 수 있다. 이것은 자바 (Java) 와 NET 는 플랫폼 간에 호환되므로 Java 코드는 CLR (또는 이와 동등한 것) 에 있을 수 있습니다. Mono 와 같은 NET 런타임은 변경되지 않습니다 ... 그러나 IKVM 은 dx 와 같은 간단한 파일 형식 변환기가 아닙니다. Java 클래스의 변환과 Java 핵심 API 의 적응은 매우 복잡합니다. 간단한 HelloWorld 프로그램에도 마찬가지입니다. 각 플랫폼의 내부 메커니즘 (예: 반사, 보안, 병렬 처리, 예외 처리, 바이트 코드 검증, I/O 및 기타 핵심 API) 은 기본적으로 동일하지만 세부 사항은 완전히 다릅니다. 일부 막다른 골목 상황으로 인해 IKVM 은 Java 코드를 계속 실행할 수 있도록 여러 개의 화환을 뚫게 됩니다. NET 가상 시스템. OpenJDK 소스 코드의 전체 JavaSE API 를 수용하기 위해 거대한 추가 런타임 계층에 의존해야 합니다. 몇 년 동안 저는 IKVM 의 발전에 세심한주의를 기울였습니다. 이 멋진 IKVM 블로그를 읽었습니다. 그래서 Java 프로그램과 JavaSE 응용 프로그램을 적응시키기 위해 충분히 알고 있습니다. 그물. 작업은 아직 완료되지 않았습니다. 그리고 많은 부분은 약간의 성능 손실을 대가로 해야 한다. ) 을 참조하십시오
(기존 비주얼 j++비주얼 j # 는 단순한 자바가 아닙니다. 네트워크 변환기. 말하고 싶지는 않지만, Visual J# 와 Java 의 호환성은 최초의 IKVM 보다 별로 좋지 않다고 말할 수 있습니다. ) 을 참조하십시오
나는 P = NP 를 토론에 도입했다. 어떤 사람들은 튜링등가 이론을 도입하여 어떤 튜링이 완비된 플랫폼/언어 /VM 도 서로 동등하다고 말한다. 맞습니다. 하지만 이 문제와 관련이 없습니다. 튜링 모델은 너무 일반화됩니다. 이런 피상적인 가치로 생각하면 더 많은 소프트웨어 특허 제도가 파괴될 수 있다. (비록 나쁜 것은 아니지만! ) 을 참조하십시오. 우리는 지상에 JVM 에 해당하는 선을 그려야 한다. 실제 요구에 더 가깝고 튜링과 동등한 선을 멀리해야 한다. 내 의견으로는, 이 사소한 이진 형식 변환, 고갈된 고급 소스 코드 및 런타임 호환성으로 인해 Android 는 Java 와 동등한 라인 내에 분명히 있습니다.
API 와 런타임은 동일합니다. Android 는 상당히 큰 JavaSE APIs 의 하위 집합을 사용했다. Harmony Project 의 이러한 API 는 완전히 새로운 구현이지만 JavaSE 를 기반으로 모델링됩니다. 만약 TCK 라이센싱 문제가 아니라면 Harmony 는 JavaSE 인증을 받을 수 있었다. 그러나 이것은 Harmony 와 JavaSE APIs 가 완전히 동등하다는 사실을 바꿀 수 없다. 이것은 의도적이지 우연이 아니다. 유명한 JRuby 인물인 Charles Nutter 가 최근 쓴 것처럼 ：
Android 는 Java 1.5 클래스 라이브러리의 불완전하지만 상당히 큰 하위 집합을 지원합니다. 이 하위 집합은 매우 커서 복잡한 JRuby 프로젝트를 Android 에서 실행할 수 있으며 수정이나 제한이 거의 없습니다.
Dalvik 은 JVM 과 너무 가깝고 완전히 상세한 JMM 을 포함한 대부분의 JVM 사양과 완벽하게 호환되어야 할 것 같습니다 (Android 가 Java 스타일의 스레드와 동시성을 지원하는 것처럼 고급 java.util.concurrent 패키지로 깊숙이 들어가 있음). 그런데 Dalvik 이 새 VM 이거나 Dalvik 이 Java 클래스를 실행할 수 없다는 말이 왜 그렇게 많습니까 (이 소송을 논의하는 포럼과 블로그의 90% 가 모두 이런 견해를 가지고 있음)?
마지막으로, 이 블로그는 갑골문과 구글 소송에 대한 법적 근거가 아니다. Android = Java 와 관련이 없는 경우 주제에서 벗어난 댓글을 무시하겠습니다. 나는' 안드로이드는 자바와 무관하다' 는 이런 쓸데없는 말을 싫어한다. 구글과 안드로이드의 지지자들은 더 의미 있는 논점을 찾아야 한다.
나는 모든 세부 사항과 최종 결과가 나올 때까지 나의 모든 선견지명으로 이 소송의 진전을 지켜볼 것이다. 네가 내막 소식을 가지고 있지 않으면 순진하지 마라. 냉정을 유지하다. 우리는 갑골문이나 구글의 모든 진정한 동기와 계획을 모른다. 우리는 이 화면 뒤에 있는 이야기를 모른다. 2007 년 구글이 처음으로 안드로이드의 탄생을 선언한 이후 (JavaME 생태 환경 붕괴로 이어진) 손씨는 이에 대해 뼈에 사무쳤지만, 결국 꼬리를 끼고 행동해야 했다. 저는 6,543.8+0 억 달러의 주주지주회사가 이타적일 것이라고 믿지 않습니다. 구글은, 갑골문은, 제가 가장 좋아하는 손주들조차도 믿지 않습니다. 지켜봅시다. ) 을 참조하십시오
나는 구글이 Java 에서 너무 멀리 떨어지지 않는 Java 스타일 기반 플랫폼 (as) 을 만들 수 없다고 믿지 않는다. 그물). Dalvik 및 Android 프레임워크는 많은 기존 Java 프로그램, 클래스 라이브러리, Java 천재, Java 도구 체인과 매우 호환되는 욕구의 최종 결과일 수 있습니다. 마이크로소프트는 기성 자바 이식의 장점을 포기하고 새로운 것을 창조했다. 그물. 구글은 그렇게 하지 않았습니다.
이 Android = Java 방정식은 분명히 모든 것을 포함하지 않습니다 (일대일 대응 아님). 각 플랫폼마다 고유한 API 가 있습니다. 물론 Android 는 Linux 기반 커널, 그래픽 시스템, 통신 스택 등을 포함한 완전한 운영 체제입니다. 분명히, 나는 가장 일반적으로 사용되는 부분, 즉 자바 소스 코드, 자바 클래스 (형식에 관계없이), Java APIs (수천 개의 공통 Java SEAAPIs 포함) 및 우수한 클래스 Java 가상 시스템에 의존하는 Java 중심 사용자 영역/애플리케이션 프레임워크만 말합니다. Android 와 다른 Java 플랫폼 간의 관계에 대한 정확한 표현은 버전 사용 개념이다. 나는 "안드로이드는' J' 가 없다" 는 블로그를 기억한다. 글쎄, 나는 아직 늦지 않았다고 말했다: 안드로이드가 Java GE(Java Google 버전) 로 이름을 바꿀 것을 제안한다. 이렇게 하면 다시는 혼란을 일으키지 않을 것이다.
전환 대상: 5 1CTO 기술 포럼