자바 애플릿

Java applet
과학 출판물의 보충 데모 자료로 작성된 자바 애플릿
3D 하드웨어 액셀러레이션을 사용하여 서버에서[1] 다운로드한 .pdb 형식의 3D 파일을 시각화하는 Java 애플릿
생물물리학적 토픽을 나타내는 간단한 애니메이션용 애플릿 사용(전압 게이트를 [2]랜덤하게 이동하는 이온 통과)
계산에 Java 애플릿 사용– Mandelbrot[3] 세트를 집중적으로 시각화
애플릿의 실행 속도는 체스를 두는 간단한 [4]컴퓨터 게임을 만들기에 충분하다.
NASA World Wind(오픈 소스)는 OpenGL과 주문형 데이터 다운로드를 많이 활용하여 상세한 세계 3D 지도를 제공하는 2세대[5] 애플릿입니다.
Java 애플릿을 사용하여 하드웨어 수준에서 서버 콘솔에 대한 웹 액세스
2차원 푸리에 변환을 이용한 화상 처리 시연

자바 애플릿은 자바 프로그래밍 언어 또는 자바 바이트 코드로 컴파일되어 자바 바이트 코드의 형태로 사용자에게 전달되는 또 다른 프로그래밍 언어로 작성된 작은 애플리케이션입니다.사용자가 웹 페이지에서 Java 애플릿을 실행한 후 웹 브라우저 자체와는 다른 프로세스로 Java Virtual Machine(JVM; Java 가상 머신) 내에서 애플릿이 실행되었습니다.Java 애플릿은 웹 페이지 프레임, 새 응용 프로그램 창, Sun의 AppletViewer 또는 애플릿 테스트를 위한 독립 실행형 도구에 나타날 수 있습니다.

자바 애플릿은 1995년에 출시된 자바 언어의 첫 번째 버전에서 도입되었다.2013년부터 주요 웹 브라우저는 애플릿 실행에 사용된 기본 기술에 대한 지원을 단계적으로 중단하기 시작했으며, 2015-2017년에는 애플릿을 완전히 실행할 수 없게 되었습니다.[6][7][8][9][10] Java 애플릿은 2017년에 Java 9에 의해 폐지되었습니다.

Java 애플릿은 보통 Java로 작성되지만 Jython, JRuby, [11]Pascal, Scala, NetRexx 또는 Eiffel(SmartEifel 경유)과 같은 다른 언어도 사용할 수 있습니다.

자바 애플릿은 매우 빠른 속도로 실행되며 2011년까지 [citation needed]자바스크립트보다 몇 배 더 빨랐다.JavaScript와 달리 Java 애플릿은 3D 하드웨어 가속에 액세스할 수 있어 단순하지 않고 계산 집약적인 시각화에 적합합니다.브라우저가 캔버스 기술(특히 3D [12][13]그래픽의 경우 WebGL)[14]과 적시에 컴파일된 JavaScript를 통해 하드웨어 가속 그래픽을 지원하게 되면서 속도 차이가 [citation needed]덜 눈에 띄게 되었습니다.

Java 바이트코드는 크로스 플랫폼(또는 플랫폼에 의존하지 않음)이기 때문에 Java 애플릿은 Microsoft Windows, FreeBSD, Unix, macOS 및 Linux를 포함한 많은 플랫폼에서 클라이언트에 의해 실행될 수 있습니다.표준 Oracle JVM 바이트 코드 실행을 지원하지 않는 모바일 장치에서는 실행할 수 없습니다.Android 장치는 Java로 작성된 코드를 Android Runtime용으로 실행할 수 있습니다.

개요

애플릿은 HTML만으로는 제공할 수 없는 웹 응용 프로그램에 대화형 기능을 제공하기 위해 사용됩니다.마우스 입력을 캡처할 수 있으며 버튼이나 체크박스와 같은 컨트롤도 있습니다.사용자의 조작에 응답하여 애플릿은 제공된 그래픽 콘텐츠를 변경할 수 있습니다.따라서 애플릿은 시연, 시각화 및 교육에 매우 적합합니다.물리학에서 심장 생리학까지 다양한 과목을 공부하기 위한 온라인 애플릿 컬렉션이 있습니다.

애플릿은 텍스트 영역일 수도 있습니다.예를 들어 일부 리모트시스템에 크로스 플랫폼명령줄 인터페이스를 제공합니다.필요한 경우 애플릿은 전용 영역을 벗어나 별도의 창으로 실행할 수 있습니다.그러나 애플릿은 애플릿 전용 영역 밖의 웹 페이지 콘텐츠에 대한 제어가 거의 없기 때문에 다른 유형의 브라우저 확장과 달리 일반적으로 사이트 외관을 개선하는 데 유용하지 않습니다(단, 뉴스 티커나 WYSIWYG 에디터 같은 애플릿도 알려져 있습니다).애플릿은 브라우저가 기본적으로 지원하지 않는 형식으로 미디어를 재생할 수도 있습니다.

HTML로 코드화된 페이지에는 애플릿에 전달되는 매개 변수가 포함될 수 있습니다.따라서 전달된 파라미터에 따라 동일한 애플릿의 외관이 다를 수 있습니다.

HTML5 이전부터 애플릿을 사용할 수 있었기 때문에 최신 CSS와 자바스크립트 인터페이스 DOM이 표준으로 제공되었기 때문에 마우스 오버나 탐색 버튼과 같은 사소한 효과에도 널리 사용되었습니다.접근성과 시스템 자원의 오용에 큰 문제를 일으켰던 이 접근방식은 더 이상 사용되지 않으며 그 시점에서도 강하게 권장되지 않았습니다.

기술 정보

대부분의 브라우저는 자바 애플릿을 샌드박스에서 실행하여 애플릿이 파일 [15]시스템과 같은 로컬 데이터에 액세스하지 못하도록 했습니다.애플릿 코드를 웹 서버에서 다운로드한 후 브라우저가 애플릿을 웹 페이지에 삽입하거나 애플릿의 사용자 인터페이스를 보여주는 새 창을 엽니다.

첫 번째 구현에서는 클래스별로 애플릿클래스를 다운로드하는 작업이 포함되었습니다.클래스는 작은 파일이지만 많은 파일이 있기 때문에 애플릿은 로드 속도가 느린 컴포넌트로 평판이 나 있습니다.하지만, 그 이후로는.jars는, 통상, 이미지 파일과 같은 사이즈(킬로바이트에서 수메가바이트)의 단일 파일로 애플릿이 전달됩니다.

Java 시스템 라이브러리와 런타임은 하위 호환성이 있으므로 Java 가상 머신의 현재 버전과 향후 버전 모두에서 실행되는 코드를 작성할 수 있습니다.

유사한 테크놀로지

많은 Java 개발자, 블로그 및 잡지는 애플릿 [16]대신 Java Web Start 기술을 사용할 것을 권장했습니다.Java Web Start 에서는 수정되지 않은 애플릿코드를 기동할 수 있었습니다.이 코드는 (부팅 브라우저가 아닌) 다른 창에서 실행됩니다.

Java Servlet은 서버 측 애플릿과 같은 비공식적으로 비교되기도 하지만 언어, 기능 및 애플릿에 대한 여기서 설명하는 각각의 특성에서 다릅니다.

웹 페이지에 내장

애플릿은 폐지된 것을 사용하여 웹 페이지에 표시됩니다.appletHTML [17]요소 또는 권장 사항object요소.[18]그embed요소를 Mozilla 패밀리브라우저에서 사용할[19] 수 있습니다(embed는 HTML 4에서는 권장되지 않지만 HTML 5)에 포함되어 있습니다.애플릿의 소스 및 위치를 지정합니다.둘다요.object그리고.embed태그는 Java 가상 시스템을 다운로드하여 설치하거나(필요한 경우) 플러그인 페이지로 연결할 수도 있습니다. applet그리고.object태그는 (초기 상태가 아닌) 특정 상태에서 시작하는 시리얼화된 애플릿 로드도 지원합니다.또한 태그는 브라우저가 어떠한 이유로 애플릿을 실행할 수 없는 경우 애플릿 대신 표시되는 메시지를 지정합니다.

하지만,object2010년에 공식적으로 추천된 태그로,object태그는 브라우저 간에 아직 일관성이 없었고 Sun은 이전 버전을 계속 추천했다.applet태그는 가장 많이 사용되는 브라우저에서 일관되게 지원되는 유일한 태그였기 때문에 멀티브라우저 [20]환경에서 배포하기 위한 태그입니다.여러 브라우저를 지원하려면object애플릿을 삽입하기 위한 태그에는 JavaScript(브라우저를 인식하고 태그를 조정하는 것), 추가 브라우저 고유 태그 사용 또는 서버 측에서 적합한 출력을 제공해야 합니다.

Java 브라우저 플러그인은 NPAPI에 의존했지만, 거의 모든 웹 브라우저 벤더는 NPAPI에 대한 지원을 중단했거나, 오래된 버전과 보안 문제로 인해 이를 구현하지 않았습니다.2016년 1월 Oracle은 JDK 9 기반 Java 런타임 환경이 브라우저 [21]플러그인을 중단할 것이라고 발표했습니다.

이점

Java 애플릿에는 다음과 같은 [22]장점이 있습니다.

  • FreeBSD, Linux, Microsoft Windows 및 macOS 상에서 동작시키는 것은 간단했습니다.즉, 크로스 플랫폼이 됩니다.애플릿은 21세기 첫 10년 동안 대부분의 웹 브라우저에 의해 지원되었지만, 그 이후로 대부분의 브라우저는 보안상의 이유로 애플릿 지원을 중단했습니다.
  • 동일한 애플릿은 최신 플러그인 버전뿐만 아니라 설치된 Java 버전에서도 동시에 작동합니다.단, 애플릿에 새로운 버전의 Java Runtime Environment(JRE; Java 런타임 환경)가 필요한 경우 클라이언트는 대량 다운로드 중에 대기해야 합니다.
  • 대부분의 웹 브라우저는 애플릿을 캐시했기 때문에 웹 페이지로 돌아갈 때 바로 로딩할 수 있었습니다.또한 애플릿은 첫 번째 애플릿을 실행한 후 JVM이 이미 실행 중이었고 후속 애플릿이 빠르게 실행되었습니다(브라우저를 새로 시작할 때마다 JVM을 재시작해야 합니다).JRE 버전 1.5 이후에서는 브라우저가 페이지 간을 이동할 때 성능 향상을 제거하기 위한 보안 조치로 JVM이 재시작되었습니다.
  • 서버로부터 클라이언트로 작업을 이동해, 유저/클라이언트의 수에 따라 Web 솔루션의 확장성을 높였습니다.
  • 독립 실행형 프로그램(Google 어스 등)이 웹 서버와 통신하는 경우, 일반적으로 해당 서버는 클라이언트 소프트웨어를 업데이트하지 않은 사용자를 위해 모든 이전 버전을 지원해야 합니다.반면 브라우저는 최신 애플릿 버전을 로드(및 캐시)했기 때문에 레거시 버전을 지원할 필요가 없습니다.
  • 애플릿은 체스보드의 그림 위치 등 사용자 상태 변경을 자연스럽게 지원했습니다.
  • 개발자는 메인 루틴(애플릿의 클래스 또는 별도의 클래스)을 만들고 애플릿에서 init()와 start()를 호출함으로써 애플릿을 직접 개발하고 디버깅할 수 있습니다.이것에 의해, 그들이 좋아하는 Java SE 개발 환경에서 개발할 수 있습니다.AppleViewer 프로그램 또는 웹 브라우저에서 애플릿을 다시 테스트하여 보안 제한 사항을 준수하는지 확인하기만 하면 됩니다.
  • 신뢰할 수 없는 애플릿은 로컬머신에 액세스 할 수 없고, 그 애플릿의 송신원 서버에만 액세스 할 수 있습니다.이를 통해 애플릿은 대체되는 네이티브 실행 파일보다 훨씬 더 안전하게 실행할 수 있습니다.단, 서명된 애플릿은 사용자가 동의하면 실행 중인 머신에 대한 풀액세스를 가질 수 있습니다.
  • Java 애플릿은 속도가 빨랐고 기본적으로 설치된 소프트웨어와 비슷한 성능을 보였습니다.

단점들

Java 애플릿은 다른 클라이언트 측 웹 기술에 비해 다음과 같은 단점이 있었습니다.

  • Java 애플릿은 복잡하고 무거운 소프트웨어 패키지인 Java Runtime Environment(JRE; Java 런타임 환경)에 의존합니다.또한 일반적으로 웹 브라우저용 플러그인이 필요했습니다.일부 조직에서는 관리자가 설치한 소프트웨어만 허용합니다.그 결과, JRE 및 플러그인의 인스톨을 요구하기 위해 관리자에게 연락하는 것이 정당화될 정도로 중요한 애플릿이 아닌 한, 사용자는 애플릿을 표시할 수 없었습니다.
  • 애플릿에 시스템에서 사용할 수 있는 것보다 새로운 JRE가 필요한 경우 처음 실행하는 사용자는 대용량 JRE 다운로드가 완료될 때까지 기다려야 합니다.
  • iOS 또는 Android 모바일 브라우저는 Java 애플릿을 전혀 [23]실행하지 않습니다.모든 플랫폼에서 애플릿이 폐지되기 전부터 데스크톱 브라우저는 모바일 운영 체제의 부상과 동시에 Java 애플릿 지원을 단계적으로 중단했습니다.
  • 애플릿의 콘텐츠를 스크린 리더가 이용할 수 있도록 하는 기준이 없었다.따라서 애플릿은 특별한 요구를 가진 사용자들의 웹사이트 접근성을 해쳤다.
  • 클라이언트측 스크립팅과 마찬가지로 보안상의 제약으로 인해 신뢰할 수 없는 애플릿이 원하는 목표를 달성하기 어렵거나 불가능할 수 있습니다.JAVA JRE 설치에서 java.policy 파일을 편집하는 것만으로 로컬파일 시스템 또는 시스템클립보드 또는 브라우저에 애플릿을 제공한 네트워크 소스 이외의 네트워크소스에 대한 접근을 허가할 수 있습니다.
  • 대부분의 사용자는 신뢰할 수 없는 애플릿과 신뢰할 수 있는 애플릿의 차이에는 관심이 없었기 때문에 보안에는 큰 도움이 되지 않았습니다.신뢰할 수 없는 애플릿을 실행하는 기능은 결국 모든 애플릿을 제거하기 전에 이 문제를 해결하기 위해 완전히 제거되었습니다.

호환성 관련 소송

Sun은 Java 버전 간의 호환성을 유지하기 위해 많은 노력을 기울였으며, 필요에 따라 법으로 Java의 이식성을 강화했습니다.Oracle도 같은 전략을 계속하고 있는 것 같습니다.

1997년: Sun vs Microsoft

1997년 [24]소송은 마이크로소프트가 자체 수정 Java Virtual Machine을 만들어 Internet Explorer에 탑재한 후 제기되었습니다.Microsoft는 java.awt, java.wt 및 java.io 패키지 내의 클래스에 약 50개의 메서드와 50개의[24] 필드를 추가했습니다.기타 수정사항으로는 RMI 기능 삭제 및 Java Native Interface를 JNI에서 RNI로 대체하는 것이 있습니다.RMI는 자바 간 통신만 쉽게 지원하고 마이크로소프트 DCOM 기술과 경쟁하기 때문에 제거됐다.이러한 변경에 의존하거나 부주의하게 사용한 애플릿은 마이크로소프트의 Java 시스템 내에서만 작동합니다.Sun은 상표권 침해에 대해 소송을 제기했습니다.Java의 요점은 독점적 확장이 없어야 하고, 그 코드가 어디에서나 통해야 한다는 것이었습니다.마이크로소프트는 Sun에게 2000만 달러를 지불하기로 합의했고, Sun은 수정 [25]없이 제한된 기간 동안만 Java를 사용할 수 있는 제한된 라이센스를 부여하는 데 동의했습니다.

2002: Sun vs Microsoft

Microsoft는 수정되지 않은 자체 Java 가상 머신을 계속 출하했습니다.시간이 지남에 따라 매우 구식이 되었지만 Internet Explorer에서는 여전히 기본값이 되었습니다.이후 연구에 따르면 이 시대의 애플릿은 종종 Swing과 다른 새로운 기능들을 [26]제한적으로 반영하는 그들만의 클래스를 포함하고 있는 것으로 밝혀졌다.2002년 Sun은 마이크로소프트의 불법 독점 시도가 자바 플랫폼에 해를 끼쳤다며 반독점 소송을 제기했다.Sun은 Sun의 Java 테크놀로지의 현재 바이너리 구현을 Windows의 일부로 배포하고, 오래된 Microsoft 데스크톱 운영체제용 권장 업데이트로 배포하고, Microsoft의 가상 머신의 배포를 중지하도록 요구했습니다(이전 소송에서 합의한 라이센스 기간이 [25]만료되었기 때문에).마이크로소프트는 반독점 문제에 대해 7억 달러, 특허 문제에 대해서는 9억 달러, [27][non-primary source needed]그리고 향후 Sun의 소프트웨어를 사용하기 위해 3억 5천만 달러의 로열티 비용을 지불했다.

보안.

매우 다른 보안 모델을 가진 애플릿 타입은 서명된 애플릿과 서명되지 않은 애플릿 [28]두 가지가 있었습니다.Java SE 7 Update 21(2013년 4월)부터 애플릿 및 Web-Start 앱은 신뢰할 수 있는 인증서로 서명하도록 권장되며 서명되지 않은 애플릿을 [29]실행하면 경고 메시지가 나타납니다.또한 Java 7 Update 51부터는 서명되지 않은 애플릿이 기본적으로 차단되었습니다. Java [30]제어판에서 예외를 생성하여 실행할 수 있습니다.

서명 없음

서명되지 않은 애플릿에 대한 제한은 "엄격한" 것으로 이해되었습니다. 애플릿 다운로드 사이트에는 로컬 파일 시스템과 웹 액세스가 제한되어 있지 않습니다. 그 밖에도 많은 중요한 제한이 있습니다.예를 들어 모든 시스템 속성에 액세스하거나 자체 클래스 로더를 사용하거나 네이티브 코드를 호출하거나 로컬 시스템에서 외부 명령을 실행하거나 Java 릴리스에 포함된 핵심 패키지에 속하는 클래스를 재정의할 수 없습니다.이러한 프레임은 스탠드아론 프레임 내에서 실행할 수 있지만 이러한 프레임에는 신뢰할 수 없는 애플릿임을 나타내는 헤더가 포함되어 있습니다.액세스 컨트롤러가 발신자 코드의 스택 전체를 체크하고, 콜이 부적절한 로케이션으로부터 발신되고 있지 않은 것을 확인하기 위해서, 금지된 메서드의 최초의 콜에 성공해도, 시큐러티 홀은 자동적으로 작성되지 않습니다.

모든 복잡한 시스템과 마찬가지로 Java가 처음 출시된 이후 많은 보안 문제가 발견되어 수정되었습니다.이들 중 일부(Calendar serialization security bug 등)는 아무도 눈치채지 못한 채 수년간 지속되었습니다.다른 것들은 [citation needed]야생에서 악성코드에 의해 사용되고 있는 것으로 밝혀졌다.

일부 연구에서는 애플릿이 브라우저를 손상시키거나 CPU 리소스를 과도하게 사용하는 것을 언급하지만, 이는 진정한 보안 결함으로 분류되지 않고 뉘앙스로 분류됩니다.다만, 서명되지 않은 애플릿은, 시스템의 다른 부분에서의 복수의 중대한 설정 에러의 편성을 부정 이용하는 복합 공격에 관련하는 경우가 있습니다.서명되지 않은 애플릿은 코드 베이스로 서버와 통신할 수 있지만 내부에서 실행하면 방화벽을 우회할 수 있기 때문에 호스트되는 서버에서 직접 실행하는 것은 더 위험할 수 있습니다.또한 애플릿은 자신이 호스트하는 서버에 대한 DoS 공격을 시도할 수 있지만, 일반적으로 웹 사이트를 관리하는 사용자도 애플릿을 관리하므로, 이는 불합리합니다.커뮤니티는 소스 코드를 확인하거나 전용 도메인에서 애플릿을 실행하여 이 문제를 해결할 수 있습니다.

서명되지 않은 애플릿은 원본 서버에 호스트된 멀웨어 다운로드를 시도할 수도 있습니다.그러나 이러한 파일을 임시 폴더(과도 데이터)에만 저장할 수 있으며, 이를 실행하여 공격을 완료할 수 있는 수단이 없습니다.이러한 방법으로 Phoenix와 [citation needed]시베리아의 공격을 확산시키기 위해 애플릿을 사용하려는 시도가 있었지만, 이러한 공격들은 내부적으로 Java를 사용하지 않고 여러 가지 다른 방법으로 배포되었습니다.

서명된

서명된[31] 애플릿에는 브라우저가 원격으로 실행되는 독립 인증 기관 서버를 통해 확인해야 하는 시그니처가 포함되어 있습니다.이 시그니처의 작성에는, 전용의 툴과 권한 있는 서버의 유지보수 담당자와의 상호 작용이 필요합니다.서명이 확인되고 현재 머신의 사용자도 승인하면 서명된 애플릿은 더 많은 권한을 얻을 수 있으며 일반 스탠드아론 프로그램과 동등해집니다.그 이유는 애플릿의 작성자가 현재 알려져 있으며 고의적인 [vague]손해에 대한 책임이 있다는 것입니다.이 방법을 사용하면 클라이언트 측 스크립팅으로는 불가능한 많은 작업에 애플릿을 사용할 수 있습니다.단, 이 방법에서는 신뢰할 수 있는 사용자를 결정하는 사용자의 책임이 더 커집니다.이와 관련된 문제로는 응답하지 않는 권한 서버, 인증서 발급 시 서명자 ID의 잘못된 평가, 사용자가 승인하지 않는 작업을 수행하는 기존의 애플릿 퍼블리셔 등이 있습니다.따라서 Java 1.1에서 나타난 서명된 애플릿은 실제로 더 많은 보안 문제를 가지고 있을 수 있습니다.

자기 서명

자체 서명 애플릿은 개발자가 서명한 애플릿으로 보안 위험을 초래할 수 있습니다.자바 플러그인은 자체 서명 애플릿의 기능과 안전성이 개발자에 의해서만 보장되고 독립적으로 확인되지 않았기 때문에 자체 서명 애플릿에 대한 승인을 요청할 때 경고를 제공합니다.이러한 자기서명증명서는 일반적으로 서드파티제의 보안 확인이 중요하지 않은 출시 전 개발 중에만 사용되지만 대부분의 애플릿 개발자는 사용자가 애플릿의 안전을 신뢰할 수 있도록 서드파티제의 서명을 요구합니다.

Java 보안 문제는 클라이언트 측 스크립팅[32][citation needed] 플랫폼의 유사한 문제와 근본적으로 다르지 않습니다.특히 서명된 애플릿과 관련된 모든 문제는 Microsoft ActiveX 컴포넌트에도 적용됩니다.

2014년을 기점으로 자체 서명된 애플릿과 서명되지 않은 애플릿은 일반적으로 사용 가능한 Java 플러그인 또는 Java Web Start에서 더 이상 허용되지 않습니다.따라서 Java 애플릿을 도입하려는 개발자는 상용 소스로부터 신뢰할 수 있는 인증서를 획득하는 것 외에 다른 대안이 없습니다.

대체 수단

애플릿으로 가능한 범위 전체를 만족시키는 대체 테크놀로지(Web[33] Assembly 및 JavaScript 등)가 존재합니다.JavaScript는 같은 페이지에서 애플릿과 공존할 수 있으며 애플릿을 실행하는 데 도움을 줄 수 있으며(예를 들어 별도의 프레임 또는 플랫폼 회피책 제공), 나중에 애플릿 코드에서 호출할 수 있습니다.Javascript가 기능과 성능을 향상시키면서 애플릿의 지원 및 사용은 결국 삭제될 때까지 감소했습니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ "The home site of the 3D protein viewer (Openastexviewer) under LGPL". Archived from the original on 1 August 2009. Retrieved 21 September 2009.
  2. ^ "Generation of an action potential in cardiac cells using interactive java applet. Excitable media. movies excitable media Fitzhug nagumo beeler reuter luo rudy model mathematical cell modeling". Thevirtualheart.org. Retrieved 22 March 2022.
  3. ^ "The home site of the Mandelbrot set applet under GPL". Archived from the original on 8 May 2013. Retrieved 29 July 2013.
  4. ^ "The home site of the chess applet under BSD". Archived from the original on 7 September 2009.
  5. ^ "Archived copy". Archived from the original on 4 April 2009. Retrieved 25 September 2009.{{cite web}}: CS1 maint: 제목으로 아카이브된 복사(링크)
  6. ^ "Java 9 Release Notes". Oracle.com.
  7. ^ "JEP 289: Deprecate the Applet API". Openjdk.java.net. Retrieved 22 March 2022.
  8. ^ "JPG blog: Moving to a Plugin-Free Web". Blogs.oracle.com.
  9. ^ "JPG blog: Further Updates to 'Moving to a Plugin-Free Web'". Blogs.oracle.com.
  10. ^ "Java Client Roadmap Update" (PDF). Oracle.com. Retrieved 22 March 2022.
  11. ^ "FPC JVM - Free Pascal wiki". Wiki.freepascal.org. Retrieved 22 March 2022.
  12. ^ "canvas - HTML". Mozilla Developer Network. Retrieved 15 August 2015.
  13. ^ "WebGL - Web API Interfaces". Mozilla Developer Network. Retrieved 15 August 2015.
  14. ^ "Design Elements - Chrome V8". Retrieved 15 August 2015.
  15. ^ McGraw, Gary; Felten, Edward (1999). "What Untrusted Java Code Can't Do". Securingjava.com. Retrieved 26 December 2021.
  16. ^ Srinivas, Raghavan N. (6 July 2001). "Java Web Start to the rescue". JavaWorld. Retrieved 2020-07-13.
  17. ^ "Objects, Images, and Applets in HTML documents". W3.org. Retrieved 22 March 2022.
  18. ^ "Objects, Images, and Applets in HTML documents". W3.org. Retrieved 22 March 2022.
  19. ^ "Java Downloads for All Operating Systems". Java.com. 14 August 2012. Retrieved 14 June 2013.
  20. ^ "Sun's position on applet and object tags". Archived from the original on 9 June 2010. Retrieved 14 January 2010.
  21. ^ "Oracle deprecates the Java browser plugin, prepares for its demise". Ars Technica. Retrieved 15 April 2016.
  22. ^ Java 애플릿 테크놀로지에 대한 Oracle 공식 개요
  23. ^ "How do I get Java for Mobile device?". Java.com. 30 July 2014.
  24. ^ a b Zukowski, John (1 October 1997). "What does Sun's lawsuit against Microsoft mean for Java developers?". JavaWorld. Retrieved 2020-07-13.
  25. ^ a b "Sun's page, devoted for the lawsuits against Microsoft". Archived from the original on 19 August 2009.
  26. ^ Kenai.com (2011) 2011년 8월 23일 Wayback Machine에서 아카이브 확인 애플릿 코드에서 발견된 가장 일반적인 문제.
  27. ^ "Microsoft and Sun Microsystems Enter Broad Cooperation Agreement; Settle Outstanding Litigation: Ten Year Agreement Sets New Framework for Industry Cooperation; Reduces Cost and Complexity for Customers". 25 February 2010. Archived from the original on 25 February 2010. Retrieved 22 March 2022.
  28. ^ "What Applets Can and Cannot Do (The Java™ Tutorials > Deployment > Java Applets)". Docs.oracle.com. Retrieved 22 March 2022.
  29. ^ "Java Applet & Web Start - Code Signing". Oracle. Retrieved 28 February 2014.
  30. ^ "What should I do when I see a security prompt from Java?". Oracle. Retrieved 28 February 2014.
  31. ^ "Java Applet Security Java 2 Platform Security InformIT". Informit.com. Retrieved 22 March 2022.
  32. ^ "To be fair, significantly more World Wide Web users use the Netscape product than use the Microsoft product today, though the gap appears to be closing". Wiley.com. Retrieved 17 March 2017.
  33. ^ "Mozilla tries to do Java as it should have been – with a WASI spec for all devices, computers, operating systems". Theregister.com. Retrieved 6 October 2020.

외부 링크

Wikimedia Commons에는 Java 애플릿과 관련된 미디어가 있습니다.