자바 비판

Criticism of Java

Java 프로그래밍 언어와 Java 소프트웨어 플랫폼은 제네릭 구현, 강제 객체 지향 프로그래밍, 서명되지 않은 숫자의 처리, 부동 소수점 산술의 구현, 1차 Java VM 구현의 보안 취약성 이력 HotSpot 등의 설계 선택으로 비판을 받아왔다. 자바어로 작성된 소프트웨어, 특히 초기 버전은 다른 프로그래밍 언어로 작성된 소프트웨어에 비해 성능이 뛰어나다는 비판을 받아왔다. 개발자들은 또한 복잡한 자바 프로그램을 작성할 때 그들 모두와 함께 작동해야 하는 다양한 자바 구현의 차이점을 고려해야 한다고 언급했다.[1]

언어 구문 및 의미론

제네릭스

추가 정보: 자바의 제네릭

Java 5.0에 제네릭을 추가했을 때, 이미 클래스의 큰 프레임워크가 존재했기 때문에(이 중 다수는 이미 사용되지 않음), 이러한 기존 클래스의 마이그레이션 호환성과 재사용이 가능하도록 유형 삭제를 사용하여 제네릭을 구현했다. 이것은 다른 언어에 비해 제공할 수 있는 특징을 제한했다.[2][3]

제네릭은 유형 삭제를 사용하여 구현되기 때문에 템플릿 매개 변수 E의 실제 유형은 런타임에 사용할 수 없다. 따라서 자바에서는 다음과 같은 연산이 불가능하다.[4] 

공중의 계급 마이클래스<E> {     공중의 정태의 공허하게 하다 마이메토드(오브젝트 항목) {         만일 (항목 의 예. E) {  //컴파일러 오류             ...         }         E 항목 2 = 새로운 E();   //컴파일러 오류         E[] 아이어레이 = 새로운 E[10]; //컴파일러 오류     } }

명사지향성

참고 항목: 객체 지향 프로그래밍 § 비평

설계에 의해 자바는 프로그래머들이 서로 상호작용하는 명사(클래스)의 관점에서 해결책을 생각하도록 하고, 동사(방법)를 그 명사 위에서 또는 그 명사에 의해 수행될 수 있는 연산으로 생각하도록 장려한다.[5] 스티브 예게는 이것이 한 클래스가 언어표현성에 불필요한 제약을 초래한다고 주장한다. 왜냐하면 한 클래스는 언어표현성을 조작하는 여러 기능을 가질 수 있지만, 한 클래스에 구속되어 있고, 여러 종류에서는 결코 조작할 수 없기 때문이다.[6]

많은 다른 다중 패러다임 언어는 최상위 구조로서 기능을 지원한다. 기능 과부하(하나의 동사, 복수명사), 일반적 기능(하나의 동사, 일정한 성질을 가진 명사 계열)과 같은 다른 특징과 결합하면 프로그래머가 명사 또는 동사의 관점에서 특정 문제를 해결할지를 결정할 수 있다. 자바 버전 8은 몇 가지 기능적인 프로그래밍 기능을 도입했다.

코드와 하드웨어 간의 숨겨진 관계

2008년 미국 국방부 소프트웨어 기술지원국(Center of Defense Software Technology Support)은 "Journal of Defense Software Engineering"에 제1언어로서의 자바의 부적응성에 대해 논하는 기사를 실었다. 단점은 학생들이 "소스 프로그램과 하드웨어가 실제로 무엇을 할 것인가"와 "어떤 방법 호출이 최종적으로 실행될지 알기가 극도로 어렵기 때문에 쓰여진 내용에 대한 런타임 비용에 대한 감각을 개발하는 것"이 불가능하다는 것이었다.[7] 2005년에 조엘 스폴스키는 그의 에세이 "자바 스쿨의 페릴스"에서 자바를 대학 커리큘럼의 과대중점이라고 비판했다.[8] 네드 바첼더와 같은 다른 사람들은 스폴스키의 해설이 오히려 '주관적인 낭군'[9]에 가깝다고 주장하면서 스폴스키가 이해하기 어려운 언어의 부분을 비판한 것에 대해 동의하지 않는다.

서명되지 않은 정수 유형

자바에는 서명되지 않은 고유 정수 유형이 부족하다. 서명되지 않은 데이터는 C로 작성된 프로그램에서 생성되는 경우가 많으며, 이러한 유형이 부족하여 C와 자바 간의 직접적인 데이터 교환을 방해한다. 서명되지 않은 대수는 암호화를 포함한 다수의 숫자 처리 분야에서도 사용되기 때문에 이러한 작업에 자바를 더욱 불편하게 할 수 있다.[10] 변환 코드와 더 큰 데이터 유형을 사용하여 이 문제를 해결할 수 있지만, 서명되지 않은 데이터를 처리하기 위해 Java를 사용하는 것은 번거롭다. 32비트 부호화 정수를 사용하여 16비트 부호화 값을 무손실, 64비트 부호화 정수 32비트 부호화되지 않은 정수를 보유할 수 있지만 64비트 부호화되지 않은 정수를 보유할 수 있는 더 큰 유형은 없다. 모든 경우에 소비되는 메모리는 두 배가 될 수 있으며, 일반적으로 두 개의 보완적 오버플로에 의존하는 모든 논리는 다시 작성되어야 한다. 추상화되면 함수 호출은 일부 다른 언어의 고유인 많은 작업에 필요하게 된다. 또는 자바의 부호화된 정수를 사용하여 같은 크기의 부호화되지 않은 정수를 에뮬레이트하는 것이 가능하지만, 이를 위해서는 비트 연산에 대한 상세한 지식이 필요하다.[11] 서명되지 않은 정수 유형에 대한 일부 지원은 JDK 8에서 제공되었지만 서명되지 않은 바이트에 대해서는 제공되지 않았으며 자바 언어에 대한 지원도 없었다.[12]

작업자 과부하

자바는 사용자 정의 운영자를 지원하지 않는다는 비판을 받아왔다.[citation needed]연산자 과부하는 가독성을 향상시키므로,[13] 그 부재는 특히 복잡한 숫자와 행렬과 같이 수학적인 객체를 나타내는 클래스의 경우 자바코드의 가독성을 떨어뜨릴 수 있다. Java에는 연산자를 숫자로 사용하지 않는 용도가 하나만 있다. + 끈 연결용 그러나 이는 StringBuilder 인스턴스를 생성하기 위한 코드를 생성하는 컴파일러에 의해 구현된다. 즉, 사용자 정의 연산자 오버로드를 생성하는 것은 불가능하다.

복합값 유형

자바에는 C의 구조체, 참조를 통해 간접적으로 조작되는 데이터 묶음 등 복합 가치 유형이 부족하다. 값 유형은 때때로 참조가 있는 클래스보다 빠르고 작을 수 있다.[14][15][16] 예를 들어, Java의 경우 HashMap 에 대한 일련의 참고 자료로 구현된다. HashMap.Entry 키 [17]및 가치 객체에 대한 참조를 포함하는 객체. 무언가를 찾는 것은 비효율적인 이중 비참조를 필요로 한다. 만약 Entry 값 유형이었고, 어레이는 키-값 쌍을 직접 저장할 수 있어 첫 번째 간접적인 요소가 제거되고, 참조의 인접성이 증가하며, 메모리 사용과 힙 조각화를 줄일 수 있었다. 또한 자바에서 지원하는 일반적인 원시형이라면 키와 값을 어레이에 직접 저장할 수 있어 양방향 레벨이 모두 제거될 수 있다.

대형 배열

자바는 그동안 2개31(약 21억) 이상의 요소 배열을 지원하지 않아 비판을 받아왔다.[18][19][20] 이것은 언어의 제한이다; 자바 언어 규격 10.4절은 다음과 같이 명시한다.

배열은 int 값으로 인덱싱되어야 함... 인덱스 값이 긴 배열 구성 요소에 액세스하려고 하면 컴파일 시간 오류가 발생한다.[21]

대형 어레이를 지원하려면 JVM도 변경해야 한다.[22] 이러한 제한은 수집이 20억 요소로[23] 제한되고 2GB보다 큰 연속 파일 세그먼트를 메모리로 매핑할 수 없는 등의 영역에서 나타난다.[24] 자바에도 다차원 배열(단일 간접 접속 메모리 블록을 연속적으로 할당)이 부족하여 과학 및 기술 컴퓨팅 성능을 제한한다.[15]

자바에서는 어레이를 초기화하는 효율적인 방법이 없다. 어레이를 선언할 때 JVM은 런타임에 요소를 하나씩 설정하는 지침이 포함된 바이트 코드로 어레이를 컴파일한다. Java 메서드는 64KB보다 클 수 없기 때문에 코드에서 직접 할당된 값이 있는 적당한 크기의 배열은 컴파일에서 "오류: 코드가 너무 크다"라는 메시지를 던질 것이다.[25][better source needed]

원시 요소와 어레이의 통합

배열과 원시성은 다소 특수하므로 계급과 다르게 취급할 필요가 있다. 이는 범용도서관을 만들 때 많은 변종적 기능이 필요하기 때문에 비판을[26] 받아왔다.

병렬주의

Per Brinch Hansen은 1999년에[27] Java의 일반적인 병렬 처리, 특히 모니터의 구현은 안전하고 신뢰할 수 있는 병렬 프로그래밍에 필요한 보증과 시행을 제공하지 않는다고 주장했다. 프로그래머가 설계와 코딩 규약을 제정할 수 있는 반면, 컴파일러는 이를 시행하려고 시도하지 않기 때문에 프로그래머는 자신도 모르게 불안하거나 신뢰할 수 없는 코드를 작성할 수 있다.

직렬화

Java는 객체 직렬화라고 불리는 메커니즘을 제공하며, 여기서 객체는 그 자체와 그 필드에 대한 유형 정보와 함께 그것의 데이터 필드를 포함하는 바이트의 시퀀스로 표현될 수 있다. 객체가 직렬화된 후에 객체는 나중에 역직렬화될 수 있다. 즉, 객체의 데이터를 나타내는 형식 정보와 바이트를 메모리에서 객체를 재생성하는 데 사용할 수 있다.[28] 이는 매우 심각한 이론적, 실제적 보안 위험을 야기한다.[29][30]

부동 소수점 산술

자바의 부동소수점 산술은 크게 IEEE 754(이진 부동소수점 산술 표준)를 기반으로 하고 있지만, 일부 의무화된 표준특성은 사용해도 지원되지 않는다. strictfp 예외 플래그 및 방향 반올림과 같은 수정자. IEEE 754에 의해 정의된 확장 정밀도 유형(많은 프로세서에서 지원됨)은 자바에서 지원하지 않는다.[31][32][33]

퍼포먼스

추가 정보: Java 성능

2000년 이전에는 Java 1.3에서 HotSpot VM을 구현했을 때 그 성능에 대한 비판이 많았다. Java는 최적화된 네이티브 코드와 비교할 수 있는 속도로 실행된다는 것이 입증되었으며, 현대의 JVM 구현은 사용 가능한 가장 빠른 언어 플랫폼 중 하나로 정기적으로 벤치마킹된다(일반적으로 C 및 C++[34]보다 3배 이상 느리지 않음).

초기 버전 이후 성능이 크게 향상되었다.[35] 네이티브 컴파일러에 대한 JIT 컴파일러의 성능은 일부 최적화된 테스트에서 상당히 유사한 것으로 나타났다.[35][36][37]

자바 바이트 코드는 가상 머신에 의해 런타임에 해석될 수 있거나, 로딩 시간 또는 런타임에 컴파일되어 컴퓨터의 하드웨어에서 직접 실행되는 네이티브 코드로 실행될 수 있다. 해석은 네이티브 실행보다 느리지만, 로딩 시간이나 런타임에 컴파일하면 초기 성능 저하가 발생한다. 현대의 JVM 구현에서는 모두 컴파일 접근방식을 사용하므로 초기 시작 시간 이후에는 성능이 네이티브 코드와 유사하다.

게임 디자이너 겸 프로그래머 존 D. 카맥은 2005년 휴대전화로 자바에 대해 "가장 큰 문제는 자바(Java)가 정말 느리다는 것이다. 순수한 cpu/메모리/디스플레이/통신 수준에서, 대부분의 현대 휴대폰은 게임보이 어드밴스보다 상당히 더 나은 게임 플랫폼이어야 한다. Java와 함께 대부분의 전화기에서는 4.77mhz(sic) IBM PC의 CPU 파워와 모든 것에 대한 형편없는 제어력을 갖게 된다."[38]

보안

추가 정보: Java 보안

Java 플랫폼은 사용자가 "샌드박스" 방식으로 신뢰할 수 없는 바이트 코드를 실행하여 악의적이거나 잘못 작성된 소프트웨어로부터 보호할 수 있도록 설계된 보안 아키텍처를[39] 제공한다. 이 "샌드박스" 기능은 로컬 파일 시스템이나 네트워크에 액세스하거나 임의 명령을 실행하는 등 악성코드에 의해 악용될 수 있는 플랫폼 기능 및 API에 대한 액세스를 제한함으로써 사용자를 보호하기 위한 것이다.

2010년에는 오라클을 비롯한 자바 구현이 사용하는 샌드박스화 메커니즘의 보안 결함을 겨냥한 악성 소프트웨어가 크게 증가했다. 이러한 결함으로 인해 신뢰할 수 없는 코드가 샌드박스 제한을 우회하여 사용자가 공격에 노출될 수 있다. 결함은 보안 업데이트에 의해 수정되었지만 업데이트 없이 여전히 컴퓨터에서 악용되었다.[40]

비평가들은 사용자들이 Java 설치를 가지고 있는지 모르기 때문에 업데이트하지 않거나 어떻게 업데이트해야 하는지를 제안해왔다. 많은 조직은 사용자에 의해 소프트웨어 설치를 제한하지만 업데이트 배포는 더디다.[40][41]

오라클은 알려진 보안 버그에 대한 업데이트를 신속하게 제공하지 않는다는 비판을 받아왔다.[42] 오라클이 마침내 Java 7에서 널리 알려진 결함에 대한 패치를 출시했을 때, 오라클이 결함에 영향을 받지 않는다고 말한 엔터프라이즈 애플리케이션에서 널리 사용되었음에도 불구하고, 사용자들의 기계에서 Java 6를 제거했다.[43]

2007년 마르코 피스토이아가 이끄는 연구팀은 스택 검사를 바탕으로 자바 보안 모델의 또 다른 중요한 결함을 폭로했다.[44] 보안에 민감한 리소스에 액세스할 때 보안 관리자는 호출 스택을 이동하는 코드를 트리거하여 호출 스택에 있는 각 방법의 코드베이스에 리소스에 액세스할 권한이 있는지 확인하십시오. 이는 합법적이고 보다 특권적인 프로그램이 다른 사람에게 속아 자신의 권한을 남용하게 될 때마다 벌어지는 혼란스러운 대리공격을 막기 위한 것이다. 혼란스럽고 부차적인 문제는 특정 유형의 특권 상승이다. Pistoia는 보안에 민감한 자원에 접근할 때, 자원을 획득하는 것을 담당하는 코드가 더 이상 스택에 있지 않을 수 있다고 보았다. 예를 들어 과거에 실행된 방법은 사용할 리소스를 결정하는 개체 필드의 값을 수정했을 수 있다. 그 메서드 콜은 검사할 때 더 이상 스택에 있지 않을 수 있다.

일부 권한은 암시적으로 Java의 권한과 동일하다. AllPermission. 여기에는 현재 보안 관리자를 변경할 수 있는 권한(그리고 스택 검사를 잠재적으로 무시할 수 있는 권한으로 교체), 사용자 정의 클래스 로더를 인스턴스화하고 사용할 수 있는 권한(연결하도록 선택할 수 있음)이 포함된다. AllPermission 로딩 시 악의적인 클래스에 대한 권한) 및 사용자 지정 권한 생성(그 권한은 자신만큼 강력하다고 선언할 수 있음) AllPermission 그것을 통해서. implies 방법. 이러한 문제는 피스토아의 자바 보안에 관한 두 가지 책인 자바 2 네트워크 보안(Second Edition)과 엔터프라이즈 자바 보안(Enterprise Java Security)에 기록되어 있다.

병렬 설치

Java 7 이전에는 설치 관리자가 이전 Java 설치를 검색하거나 제거하지 않는 것이 일반적이었다. Windows 컴퓨터에서는 Java 6의 여러 설치를 같은 컴퓨터에 보는 것이 꽤 일반적이었는데, 이는 단지 사소한 개정만으로 달라진다. 다중 설치가 허용되며 특정 버전에 의존하는 프로그램에서 사용할 수 있다.

이는 새로운 Java 설치는 새로운 언어 기능과 버그 수정을 제공할 수 있지만, 악성 프로그램은 이전 버전을 사용할 수 있기 때문에 보안 취약점을 수정하지 않는다는 효과가 있다.

Java 7은 Java 6 또는 이전 버전이 아닌 그 자체의 이전 버전을 업데이트했다.[45]

자동 업데이트

2014년 현재 일반적인 타사 툴(예: Adobe Flash 및 Adobe Reader)은 보안 취약성에 대한 정밀 조사 대상이 되어 왔다. Adobe 등은 Windows의 자동 업데이트로 이동했다. 여기에는 사용자 작업이 필요하지 않으며, 보안 문제가 사용자나 관리자의 최소한의 노력으로 신속하게 해결되도록 보장한다.

2015년 현재 자바 8은 여전히 사용자 스스로 자바 업데이트를 요구한다. 그러나 Windows에서는 관리자 권한이 있는 사용자만 소프트웨어를 업데이트할 수 있다. Windows Java 업데이터는 자주 사용자 계정 컨트롤 상승 프롬프트를 트리거한다. 사용자가 무엇을 선택하든 여전히 동일한 "Java 업데이트 필요" 메시지를 받는다.

참고 항목

메모들

  1. ^ Wong, William (27 May 2002). "Write Once, Debug Everywhere". electronicdesign.com. Archived from the original on 21 March 2009. Retrieved 3 August 2008. So far, the "write-once, run-everywhere" promise of Java hasn't come true. The bulk of a Java application will migrate between most Java implementations, but taking advantage of a VM-specific feature causes porting problems.
  2. ^ "Generics in Java". Object Computing, Inc. Archived from the original on 2 January 2007. Retrieved 9 December 2006.
  3. ^ "What's Wrong With Java: Type Erasure". 6 December 2006. Retrieved 9 December 2006.
  4. ^ "Type Erasure".
  5. ^ "Java SE Specifications".
  6. ^ Yegge, Steve. "Execution in the Kingdom of Nouns".
  7. ^ Robert B.K. Dewar; Edmond Schonberg (1 January 2008). "Computer Science Education: Where Are the Software Engineers of Tomorrow?". CrossTalk Jan 2008. U.S. DOD Software Technology Support Center. Archived from the original on 12 April 2009. Retrieved 15 March 2015. The Pitfalls of Java as a First Programming Language [...] Students found it hard to write programs that did not have a graphic interface, had no feeling for the relationship between the source program and what the hardware would actually do, and (most damaging) did not understand the semantics of pointers at all, which made the use of C in systems programming very challenging.
  8. ^ Joel Spolsky (29 December 2005). "Joel on Software - The Perils of JavaSchools". joelonsoftware. Retrieved 18 November 2015. It's bad enough that JavaSchools fail to weed out the kids who are never going to be great programmers, which the schools could justifiably say is not their problem. Industry, or, at least, the recruiters-who-use-grep, are surely clamoring for Java to be taught. But JavaSchools also fail to train the brains of kids to be adept, agile, and flexible enough to do good software design
  9. ^ Ned Batchelder (1 January 2006). "Joel Spolsky is a crotchety old man". nedbatchelder.com. Retrieved 2 February 2016. Why does Joel pick out pointers and recursion as the two gatekeeper concepts? Because he found them difficult? As Tim Bray points out, Java is perfectly adept at recursion, and concurrency may be a more important and difficult concept to master in any case. The emphasis on recursion in Lisp languages is a bit over the top, and doesn't carry into other programming cultures. Why do people think it's so important for software engineering? Don't get me wrong: I love recursion when it's the right tool for the job, but that is just not that often to warrant Joel's focus on it as a fundamental concept.
    While we're hunting around for tough concepts that separate the men from the boys, what about the one that got Joel and I into a tussle two years ago: Exceptions. He doesn't like them, basically, because they confuse him. Is this any different than a Java guy not liking pointers? Yes, you can avoid exceptions and use status returns, but you can also try really hard to avoid pointers. Does that mean you should? So Joel's got the concepts he likes (pointers and recursion), and laments their decline, but doesn't seem to notice that there are newer concepts that he's never caught on to, which the Java kiddies feel at home with.
  10. ^ "Java libraries should provide support for unsigned integer arithmetic". Bug Database, Sun Developer Network. Oracle. Retrieved 18 January 2011.
  11. ^ Owen, Sean R. (5 November 2009). "Java and unsigned int, unsigned short, unsigned byte, unsigned long, etc. (Or rather, the lack thereof)". Retrieved 9 October 2010.
  12. ^ "Unsigned Integer Arithmetic API now in JDK 8 (Joseph D. Darcy's Oracle Weblog)". Retrieved 15 May 2016.
  13. ^ "C++ Operator Overloading". 7 April 2016.
  14. ^ Java Grande Forum Panel (November 1998). "Java Grande Forum Report: Making Java Work for High-End Computing" (PDF). SC98.
  15. ^ a b Moreira, J.E.; S. P. Midkiff; M. Gupta; P. V. Artigas; M. Snir; R. D. Lawrence (2000). "Java programming for high-performance numerical computing". IBM Systems Journal. 39 (1): 21–56. CiteSeerX 10.1.1.13.1554. doi:10.1147/sj.391.0021. True rectangular multidimensional arrays are the most important data structures for scientific and engineering computing.
  16. ^ Hutchinson, Ben (14 June 2008). "The JVM needs Value Types". Retrieved 3 February 2012.
  17. ^ "java.util.HashMap Source Code". JDK 8. zGrepCode. Retrieved 6 August 2018.
  18. ^ Arndt, Holger; Bundschus, Markus; Naegele, Andreas (2009). "Towards a Next-Generation Matrix Library for Java" (PDF). 2009 33rd Annual IEEE International Computer Software and Applications Conference. pp. 460–467. CiteSeerX 10.1.1.471.7567. doi:10.1109/compsac.2009.67. ISBN 978-0-7695-3726-9. ...it is not possible in Java to have arrays with more than 231 entries...
  19. ^ "Why does Java's Collection.size() return an int?". Stack Overflow. Archived from the original on 26 March 2013. Retrieved 10 February 2012.
  20. ^ Carpenter, Bob (28 July 2010). "Big Bit-Packed Array Abstraction (for Java, C, etc.)". LingPipe Blog. Retrieved 10 February 2012.
  21. ^ James Gosling; Bill Joy; Guy Steele; Gilad Bracha. "The Java Language Specification" (Third ed.). Addison Wesley. Retrieved 6 February 2012.
  22. ^ Lowden, James. "Proposal: Large arrays (take two)". Java.net coin-dev mailing list. Retrieved 10 February 2012.
  23. ^ "java.util.Collection". Java™ Platform, Standard Edition 7 API Specification. Retrieved 10 February 2012.
  24. ^ "java.nio.ByteBuffer". Java™ Platform, Standard Edition 7 API Specification. Retrieved 6 February 2012.
  25. ^ David Flanagan. Java in a Nutshell. p. 77.
  26. ^ Sherman R. Alpert (IBM) (1998). "Primitive Types Considered Harmful". Java Report, November, 1998 (Volume 3, Number 11). Retrieved 18 November 2015.
  27. ^ Brinch Hansen (April 1999). "Java's Insecure Parallelism" (PDF). SIGPLAN. Retrieved 13 October 2012.; 대체 url
  28. ^ Geekforgeeks 웹사이트의 예와 함께 Java의 직렬화 및 탈직렬화
  29. ^ 직렬화는 반드시 죽어야 한다 보안 문제 및 임의 객체 직렬화 관련 문제. dzone.com
  30. ^ Bloch, Joshua (2018). Effective Java. Addison-Wesley. pp. 339–345. ISBN 978-0-13-468599-1.
  31. ^ Kahan, W.; Joseph D. Darcy (1 March 1998). "How Java's Floating-Point Hurts Everyone Everywhere" (PDF). Retrieved 9 December 2006.
  32. ^ "Types, Values, and Variables". Sun Microsystems. Retrieved 9 December 2006.
  33. ^ "Java theory and practice: Where's your point? Tricks and traps with floating point and decimal numbers". IBM. 1 January 2003. Retrieved 19 November 2011.
  34. ^ "Computer Language Benchmarks Game: Java vs Gnu C++". benchmarksgame.alioth.debian.org. Archived from the original on 13 January 2015. Retrieved 19 November 2011.
  35. ^ a b J.P.Lewis & Ulrich Neumann. "Performance of Java versus C++". Graphics and Immersive Technology Lab, University of Southern California.
  36. ^ "The Java Faster than C++ Benchmark". Retrieved 15 May 2016.
  37. ^ FreeTTS - 2009년 3월 25일 Wayback Machine, Willie Walker, Paul Lamre, Philip Kwok에 보관된 성능 사례 연구
  38. ^ John D. Carmack (27 March 2005). "Cell phone adventures". John Carmack's Blog. armadilloaerospace.com. Archived from the original on 24 November 2015. Retrieved 10 November 2015.
  39. ^ Java SE 플랫폼 보안 아키텍처. 오라클. 2013년 4월 23일 발견
  40. ^ a b "Researchers Highlight Recent Uptick in Java Security Exploits".
  41. ^ "Have you checked the Java?". Archived from the original on 3 September 2012. Retrieved 25 November 2010.
  42. ^ "Oracle knew about critical Java flaws since April". 30 August 2012. Retrieved 30 August 2012.
  43. ^ "'Silent but deadly' Java security update breaks legacy apps - dev". Retrieved 15 May 2016.
  44. ^ Pistoia, Marco; Banerjee, Anindya; Naumann, David A. (May 2007). "Beyond Stack Inspection: A Unified Access-Control and Information-Flow Security Model". 2007 IEEE Symposium on Security and Privacy (SP '07). IEEE: 149–163. doi:10.1109/sp.2007.10. ISBN 978-0-7695-2848-9.
  45. ^ "Attachment A". www.java.com. Retrieved 3 March 2018.

외부 링크