Substantia nigra

From Wikipedia, the free encyclopedia

https://en.wikipedia.org/wiki/Substantia_nigra 

 

Substantia nigra
Substantia nigra highlighted in red.
Section through superior colliculus showing Substantia nigra.
Details
Part of	Midbrain, Basal ganglia
Identifiers
Latin	Substantia nigra
Acronym(s)	SN
MeSH	D013378
NeuroNames	536
NeuroLex ID	birnlex_789
TA98	A14.1.06.111
TA2	5881
FMA	67947

The substantia nigra (SN) is a basal ganglia structure located in the midbrain that plays an important role in reward and movement. Substantia nigra is Latin for "black substance", reflecting the fact that parts of the substantia nigra appear darker than neighboring areas due to high levels of neuromelanin in dopaminergic neurons. Parkinson's disease is characterized by the loss of dopaminergic neurons in the substantia nigra pars compacta.

Although the substantia nigra appears as a continuous band in brain sections, anatomical studies have found that it actually consists of two parts with very different connections and functions: the pars compacta (SNpc) and the pars reticulata (SNpr). The pars compacta serves mainly as a projection to the basal ganglia circuit, supplying the striatum with dopamine. The pars reticulata conveys signals from the basal ganglia to numerous other brain structures.

Structure

Coronal slices of human brain showing the basal ganglia, globus pallidus: external segment (GPe), subthalamic nucleus (STN), globus pallidus: internal segment (GPi), and substantia nigra (SN, red). The right section is the deeper one, closer to the back of the head

Diagram of the main components of the basal ganglia and their interconnections

Anatomical overview of the main circuits of the basal ganglia, substantia nigra is shown in black. Picture shows 2 coronal slices that have been superimposed to include the involved basal ganglia structures. + and – signs at the point of the arrows indicate respectively whether the pathway is excitatory or inhibitory in effect. Green arrows refer to excitatory glutamatergic pathways, red arrows refer to inhibitory GABAergic pathways and turquoise arrows refer to dopaminergic pathways that are excitatory on the direct pathway and inhibitory on the indirect pathway.

See also: Primate basal ganglia system

The substantia nigra, along with four other nuclei, is part of the basal ganglia. It is the largest nucleus in the midbrain, lying dorsal to the cerebral peduncles. Humans have two substantiae nigrae, one on each side of the midline.

The SN is divided into two parts: the pars reticulata (SNpr) and the pars compacta (SNpc), which lies medial to the pars reticulata. Sometimes, a third region, the pars lateralis, is mentioned, though it is usually classified as part of the pars reticulata. The (SNpr) and the internal globus pallidus (GPi) are separated by the internal capsule.

Pars reticulata

Main article: Pars reticulata

The pars reticulata bears a strong structural and functional resemblance to the internal part of the globus pallidus. The two are sometimes considered parts of the same structure, separated by the white matter of the internal capsule. Like those of the globus pallidus, the neurons in pars reticulata are mainly GABAergic.

Afferent connections

The main input to the SNpr derives from the striatum. It comes by two routes, known as the direct and indirect pathways. The direct pathway consists of axons from medium spiny cells in the striatum that project directly to pars reticulata. The indirect pathway consists of three links: a projection from striatal medium spiny cells to the external part of the globus pallidus; a GABAergic projection from the globus pallidus to the subthalamic nucleus, and a glutamatergic projection from the subthalamic nucleus to the pars reticulata. Thus, striatal activity via the direct pathway exerts an inhibitory effect on neurons in the (SNpr) but an excitatory effect via the indirect pathway. The direct and indirect pathways originate from different subsets of striatal medium spiny cells: They are tightly intermingled, but express different types of dopamine receptors, as well as showing other neurochemical differences.

Efferent connections

Significant projections occur to the thalamus (ventral lateral and ventral anterior nuclei), superior colliculus, and other caudal nuclei from the pars reticulata (the nigrothalamic pathway), which use GABA as their neurotransmitter. In addition, these neurons form up to five collaterals that branch within both the pars compacta and pars reticulata, likely modulating dopaminergic activity in the pars compacta.

Function

The substantia nigra is an important player in brain function, in particular, in eye movement, motor planning, reward-seeking, learning, and addiction. Many of the substantia nigra's effects are mediated through the striatum. The nigral dopaminergic input to the striatum via the nigrostriatal pathway is intimately linked with the striatum's function. The co-dependence between the striatum and substantia nigra can be seen in this way: when the substantia nigra is electrically stimulated, no movement occurs; however, the symptoms of nigral degeneration due to Parkinson's is a poignant example of the substantia nigra's influence on movement. In addition to striatum-mediated functions, the substantia nigra also serves as a major source of GABAergic inhibition to various brain targets.

Pars reticulata

Main article: Pars reticulata § Function

The pars reticulata of the substantia nigra is an important processing center in the basal ganglia. The GABAergic neurons in the pars reticulata convey the final processed signals of the basal ganglia to the thalamus and superior colliculus. In addition, the pars reticulata also inhibits dopaminergic activity in the pars compacta via axon collaterals, although the functional organization of these connections remains unclear.

The GABAergic neurons of the pars reticulata spontaneously fire action potentials. In rats, the frequency of action potentials is roughly 25 Hz. The purpose of these spontaneous action potentials is to inhibit targets of the basal ganglia, and decreases in inhibition are associated with movement. The subthalamic nucleus gives excitatory input that modulates the rate of firing of these spontaneous action potentials. However, lesion of the subthalamic nucleus leads to only a 20% decrease in pars reticulata firing rate, suggesting that the generation of action potentials in the pars reticulata is largely autonomous, as exemplified by the pars reticulata's role in saccadic eye movement. A group of GABAergic neurons from the pars reticulata projects to the superior colliculus, exhibiting a high level of sustained inhibitory activity. Projections from the caudate nucleus to the superior colliculus also modulate saccadic eye movement. Altered patterns of pars reticulata firing such as single-spike or burst firing are found in Parkinson's disease and epilepsy.

Pars compacta

Main article: Pars compacta § Function

The most prominent function of the pars compacta is motor control, though the substantia nigra's role in motor control is indirect; electrical stimulation of the substantia nigra does not result in movement, due to mediation of the striatum in the nigral influence of movement. The pars compacta sends excitatory input to the striatum via D1 pathway that excites and activates the striatum, resulting in the release of GABA onto the globus pallidus to inhibit its inhibitory effects on the thalamic nucleus. This causes the thalamocortical pathways to become excited and transmits motor neuron signals to the cerebral cortex to allow the initiation of movement, which is absent in Parkinson's disease. However, lack of pars compacta neurons has a large influence on movement, as evidenced by the symptoms of Parkinson's. The motor role of the pars compacta may involve fine motor control, as has been confirmed in animal models with lesions in that region.

The pars compacta is heavily involved in learned responses to stimuli. In primates, dopaminergic neuron activity increases in the nigrostriatal pathway when a new stimulus is presented. Dopaminergic activity decreases with repeated stimulus presentation. However, behaviorally significant stimulus presentation (i.e. rewards) continues to activate dopaminergic neurons in the substantia nigra pars compacta. Dopaminergic projections from the ventral tegmental area (bottom part of the "midbrain" or mesencephalon) to the prefrontal cortex (mesocortical pathway) and to the nucleus accumbens (mesolimbic pathway – "meso" referring to "from the mesencephalon"... specifically the ventral tegmental area) are implicated in reward, pleasure, and addictive behavior. The pars compacta is also important in spatial learning, the observations about one's environment and location in space. Lesions in the pars compacta lead to learning deficits in repeating identical movements, and some studies point to its involvement in a dorsal striatal-dependent, response-based memory system that functions relatively independent of the hippocampus, which is traditionally believed to subserve spatial or episodic-like memory functions.

The pars compacta also plays a role in temporal processing and is activated during time reproduction. Lesions in the pars compacta leads to temporal deficits. As of late, the pars compacta has been suspected of regulating the sleep-wake cycle, which is consistent with symptoms such as insomnia and REM sleep disturbances that are reported by patients with Parkinson's disease. Even so, partial dopamine deficits that do not affect motor control can lead to disturbances in the sleep-wake cycle, especially REM-like patterns of neural activity while awake, especially in the hippocampus.

Clinical significance

The substantia nigra is critical in the development of many diseases and syndromes, including parkinsonism and Parkinson's disease. There exist a study showing that high-frequency stimulation delivery to the left substantia nigra can induce transient acute depression symptoms.

Parkinson's disease

Substantia nigra with loss of cells and Lewy body pathology

Main article: Parkinson's disease

Parkinson's disease is a neurodegenerative disease characterized, in part, by the death of dopaminergic neurons in the SNpc. The major symptoms of Parkinson's disease include tremor, akinesia, bradykinesia, and stiffness. Other symptoms include disturbances to posture, fatigue, sleep abnormalities, and depressed mood.

The cause of death of dopaminergic neurons in the SNpc is unknown. However, some contributions to the unique susceptibility of dopaminergic neurons in the pars compacta have been identified. For one, dopaminergic neurons show abnormalities in mitochondrial complex 1, causing aggregation of alpha-synuclein; this can result in abnormal protein handling and neuron death. Secondly, dopaminergic neurons in the pars compacta contain less calbindin than other dopaminergic neurons. Calbindin is a protein involved in calcium ion transport within cells, and excess calcium in cells is toxic. The calbindin theory would explain the high cytotoxicity of Parkinson's in the substantia nigra compared to the ventral tegmental area. Regardless of the cause of neuronal death, the plasticity of the pars compacta is very robust; Parkinsonian symptoms do not generally appear until at least 30% of pars compacta dopaminergic neurons have died. Most of this plasticity occurs at the neurochemical level; dopamine transport systems are slowed, allowing dopamine to linger for longer periods of time in the chemical synapses in the striatum.

Menke, Jbabdi, Miller, Matthews and Zari (2010) used diffusion tensor imaging, as well as T1 mapping to assess volumetric differences in the SNpc and SNpr, in participants with Parkinson's compared to healthy individuals. These researchers found that participants with Parkinson's consistently had a smaller substantia nigra, specifically in the SNpr. Because the SNpr is connected to the posterior thalamus, ventral thalamus and specifically, the motor cortex, and because participants with Parkinson's disease report having a smaller SNprs (Menke, Jbabdi, Miller, Matthews and Zari, 2010), the small volume of this region may be responsible for motor impairments found in Parkinson's disease patients. This small volume may be responsible for weaker and/or less controlled motor movements, which may result in the tremors often experienced by those with Parkinson's.

Oxidative stress and oxidative damage in the SNpc are likely key drivers in the etiology of Parkinson’s disease as individuals age. DNA damages caused by oxidative stress can be repaired by processes modulated by alpha-synuclein. Alpha synuclein is expressed in the substantia nigra, but its DNA repair function appears to be compromised in Lewy body inclusion bearing neurons. This loss may trigger cell death.

Schizophrenia

See also: Dopamine hypothesis of schizophrenia

Increased levels of dopamine have long been implicated in the development of schizophrenia. However, much debate continues to this day surrounding this dopamine hypothesis of schizophrenia. Despite the controversy, dopamine antagonists remain a standard and successful treatment for schizophrenia. These antagonists include first generation (typical) antipsychotics such as butyrophenones, phenothiazines, and thioxanthenes. These drugs have largely been replaced by second-generation (atypical) antipsychotics such as clozapine and paliperidone. In general, these drugs do not act on dopamine-producing neurons themselves, but on the receptors on the post-synaptic neuron.

Other, non-pharmacological evidence in support of the dopamine hypothesis relating to the substantia nigra include structural changes in the pars compacta, such as reduction in synaptic terminal size. Other changes in the substantia nigra include increased expression of NMDA receptors in the substantia nigra, and reduced dysbindin expression. Increased NMDA receptors may point to the involvement of glutamate-dopamine interactions in schizophrenia. Dysbindin, which has been (controversially) linked to schizophrenia, may regulate dopamine release, and low expression of dysbindin in the substantia nigra may be important in schizophrenia etiology. Due to the changes to the substantia nigra in the schizophrenic brain, it may eventually be possible to use specific imaging techniques (such as neuromelanin-specific imaging) to detect physiological signs of schizophrenia in the substantia nigra.

Wooden Chest Syndrome

Wooden chest, also called fentanyl chest wall rigidity syndrome, is a rare side effect of synthetic opioids such as Fentanyl, Sulfentanil, Alfentanil, Remifentanil. It results in a generalised increase in skeletal muscle tone. The mechanism is thought to be via increased dopamine release and decreased GABA release in the nerves of the substantia nigra/striatum. The effect is most pronounced on the chest wall muscles and can lead to impaired ventilation. The condition is most commonly observed in anaesthesia where rapid and high doses of these drugs are given intravenously.

Multiple system atrophy

Multiple system atrophy characterized by neuronal degeneration in the striatum and substantia nigra was previously called striatonigral degeneration.

Chemical modification of the substantia nigra

Chemical manipulation and modification of the substantia nigra is important in the fields of neuropharmacology and toxicology. Various compounds such as levodopa and MPTP are used in the treatment and study of Parkinson's disease, and many other drugs have effects on the substantia nigra.

Amphetamine and trace amines

See also: Amphetamine and Trace amine

Studies have shown that, in certain brain regions, amphetamine and trace amines increase the concentrations of dopamine in the synaptic cleft, thereby heightening the response of the post-synaptic neuron. The various mechanisms by which amphetamine and trace amines affect dopamine concentrations have been studied extensively, and are known to involve both DAT and VMAT2. Amphetamine is similar in structure to dopamine and trace amines; as a consequence, it can enter the presynaptic neuron via DAT as well as by diffusing through the neural membrane directly. Upon entering the presynaptic neuron, amphetamine and trace amines activate TAAR1, which, through protein kinase signaling, induces dopamine efflux, phosphorylation-dependent DAT internalization, and non-competitive reuptake inhibition. Because of the similarity between amphetamine and trace amines, it is also a substrate for monoamine transporters; as a consequence, it (competitively) inhibits the reuptake of dopamine and other monoamines by competing with them for uptake, as well.

In addition, amphetamine and trace amines are substrates for the neuronal vesicular monoamine transporter, vesicular monoamine transporter 2 (VMAT2). When amphetamine is taken up by VMAT2, the vesicle releases (effluxes) dopamine molecules into the cytosol in exchange.

Cocaine

See also: Cocaine

Cocaine's mechanism of action in the human brain includes the inhibition of dopamine reuptake, which accounts for cocaine's addictive properties, as dopamine is the critical neurotransmitter for reward. However, cocaine is more active in the dopaminergic neurons of the ventral tegmental area than the substantia nigra. Cocaine administration increases metabolism in the substantia nigra, which can explain the altered motor function seen in cocaine-using subjects. The inhibition of dopamine reuptake by cocaine also inhibits the firing of spontaneous action potentials by the pars compacta. The mechanism by which cocaine inhibits dopamine reuptake involves its binding to the dopamine transporter protein. However, studies show that cocaine can also cause a decrease in DAT mRNA levels, most likely due to cocaine blocking dopamine receptors rather than direct interference with transcriptional or translational pathways.

Inactivation of the substantia nigra could prove to be a possible treatment for cocaine addiction. In a study of cocaine-dependent rats, inactivation of the substantia nigra via implanted cannulae greatly reduced cocaine addiction relapse.

Levodopa

See also: Levodopa

The substantia nigra is the target of chemical therapeutics for the treatment of Parkinson's disease. Levodopa (commonly referred to as L-DOPA), the dopamine precursor, is the most commonly prescribed medication for Parkinson's disease, despite controversy concerning the neurotoxicity of dopamine and L-DOPA. The drug is especially effective in treating patients in the early stages of Parkinson's, although it does lose its efficacy over time. Levodopa can cross the blood–brain barrier and increases dopamine levels in the substantia nigra, thus alleviating the symptoms of Parkinson's disease. The drawback of levodopa treatment is that it treats the symptoms of Parkinson's (low dopamine levels), rather than the cause (the death of dopaminergic neurons in the substantia nigra).

MPTP

See also: MPTP

MPTP, is a neurotoxin specific to dopaminergic cells in the brain, specifically in the substantia nigra. MPTP was brought to the spotlight in 1982 when heroin users in California displayed Parkinson's-like symptoms after using MPPP contaminated with MPTP. The patients, who were rigid and almost completely immobile, responded to levodopa treatment. No remission of the Parkinson's-like symptoms was reported, suggesting irreversible death of the dopaminergic neurons. The proposed mechanism of MPTP involves disruption of mitochondrial function, including disruption of metabolism and creation of free radicals.

Soon after, MPTP was tested in animal models for its efficacy in inducing Parkinson's disease (with success). MPTP induced akinesia, rigidity, and tremor in primates, and its neurotoxicity was found to be very specific to the substantia nigra pars compacta. In other animals, such as rodents, the induction of Parkinson's by MPTP is incomplete or requires much higher and frequent doses than in primates. Today, MPTP remains the most favored method to induce Parkinson's disease in animal models.

History

The substantia nigra was discovered in 1784 by Félix Vicq-d'Azyr, and Samuel Thomas von Sömmerring alluded to this structure in 1791. The differentiation between the substantia nigra pars reticulata and compacta was first proposed by Sano in 1910. In 1963, Oleh Hornykiewicz concluded from his observation that ‘‘cell loss in the substantia nigra (of Parkinson's disease patients) could well be the cause of the dopamine deficit in the striatum’’.

Component Object Model

From Wikipedia, the free encyclopedia

https://en.wikipedia.org/wiki/Component_Object_Model 

 

Component Object Model
Abbreviation	COM
Status	In force
First published	1993; 30 years ago
Latest version	Living standard 2021
Organization	Microsoft
Series	System Services
Base standards	MIDL, UUID
Related standards	replaced: DDE built upon COM: OLE, OLE Automation, Browser Helper Object, ActiveX, COM+, DCOM, Windows shell, DirectX, UMDF, Windows Runtime
Domain	Component Interfacing
Website	learn.microsoft.com/en-us/windows/win32/com/the-component-object-model

Component Object Model (COM) is a binary-interface standard for software components introduced by Microsoft in 1993. It is used to enable inter-process communication object creation in a large range of programming languages. COM is the basis for several other Microsoft technologies and frameworks, including OLE, OLE Automation, Browser Helper Object, ActiveX, COM+, DCOM, the Windows shell, DirectX, UMDF and Windows Runtime. The essence of COM is a language-neutral way of implementing objects that can be used in environments different from the one in which they were created, even across machine boundaries. For well-authored components, COM allows reuse of objects with no knowledge of their internal implementation, as it forces component implementers to provide well-defined interfaces that are separated from the implementation. The different allocation semantics of languages are accommodated by making objects responsible for their own creation and destruction through reference-counting. Type conversion casting between different interfaces of an object is achieved through the QueryInterface method. The preferred method of "inheritance" within COM is the creation of sub-objects to which method "calls" are delegated.

COM is an interface technology defined and implemented as standard only on Microsoft Windows and Apple's Core Foundation 1.3 and later plug-in application programming interface (API). The latter only implements a subset of the whole COM interface. For some applications, COM has been replaced at least to some extent by the Microsoft .NET framework, and support for Web Services through the Windows Communication Foundation (WCF). However, COM objects can be used with all .NET languages through .NET COM Interop. Networked DCOM uses binary proprietary formats, while WCF encourages the use of XML-based SOAP messaging. COM is very similar to other component software interface technologies, such as CORBA and Enterprise JavaBeans, although each has its own strengths and weaknesses. Unlike C++, COM provides a stable application binary interface (ABI) that does not change between compiler releases. This makes COM interfaces attractive for object-oriented C++ libraries that are to be used by clients compiled using different compiler versions.

History

One of the first methods of interprocess communication in Windows was Dynamic Data Exchange (DDE), first introduced in 1987, that allowed sending and receiving messages in so-called "conversations" between applications. Antony Williams, who was involved in the creation of the COM architecture, later distributed two internal papers in Microsoft that embraced the concept of software components: Object Architecture: Dealing With the Unknown – or – Type Safety in a Dynamically Extensible Class Library in 1988 and On Inheritance: What It Means and How To Use It in 1990. These provided the foundation of many of the ideas behind COM. Object Linking and Embedding (OLE), Microsoft's first object-based framework, was built on top of DDE and designed specifically for compound documents. It was introduced with Word for Windows and Excel in 1991, and was later included with Windows, starting with version 3.1 in 1992. An example of a compound document is a spreadsheet embedded in a Word for Windows document: as changes are made to the spreadsheet within Excel, they appear automatically inside the Word document.

In 1991, Microsoft introduced Visual Basic Extensions (VBX) with Visual Basic 1.0. A VBX is a packaged extension in the form of a dynamic-link library (DLL) that allows objects to be graphically placed in a form and manipulated by properties and methods. These were later adapted for use by other languages such as Visual C++. In 1992, when version 3.1 of Windows was released, Microsoft released OLE 2 with its underlying object model. The COM Application binary interface (ABI) was the same as the MAPI ABI (released in 1992), and like it was based on MSRPC and ultimately on the Open Group's DCE/RPC. While OLE 1 was focused on compound documents, COM and OLE 2 were designed to address software components in general. Text conversations and Windows messages had proved not to be flexible enough to allow sharing application features in a robust and extensible way, so COM was created as a new foundation, and OLE changed to OLE2. In 1994 OLE custom controls (OCXs) were introduced as the successor to VBX controls. At the same time, Microsoft stated that OLE 2 would just be known as "OLE", and that OLE was no longer an acronym, but a name for all of the company's component technologies. In early 1996, Microsoft found a new use for OLE Custom Controls, expanding their Web browser's capability to present content, renamed some parts of OLE relating to the Internet "ActiveX", and gradually renamed all OLE technologies to ActiveX, except the compound document technology that was used in Microsoft Office. Later that year, Microsoft extended COM to work across the network with DCOM.

Related technologies

COM was the major software development platform for Windows and, as such, influenced development of a number of supporting technologies. It was likewise heavily influenced by earlier technologies.

DDE

COM replaced DDE as the preferred form of interprocess communication.

DCE/RPC and MSRPC

As a cross-language component model, COM relies on an interface definition language, or IDL, to describe the objects and associated functions. The COM IDL is based heavily on the feature-rich DCE/RPC IDL, with object-oriented extensions. Microsoft's own implementation of DCE/RPC, known as MSRPC, is heavily used as the primary inter-process communication mechanism for Windows NT services and internal components, making it an obvious choice of foundation.

DCOM

DCOM (Distributed COM) extended the reach of COM from merely supporting a single user with separate applications communicating on the Windows desktop, to activating objects running under different security contexts, and on different machines across the network. With this were added necessary features for configuring which users have authority to create, activate and call objects, for identifying the calling user, as well as specifying required encryption for security of calls.

COM+

In order for Microsoft to provide developers with support for distributed transactions, resource pooling, disconnected applications, event publication and subscription, better memory and processor (thread) management, as well as to position Windows as an alternative to other enterprise-level operating systems, Microsoft introduced a technology called Microsoft Transaction Server (MTS) on Windows NT 4. With Windows 2000, that significant extension to COM was incorporated into the operating system (as opposed to the series of external tools provided by MTS) and renamed COM+. At the same time, Microsoft de-emphasized DCOM as a separate entity. Components that made use of COM+ services were handled more directly by the added layer of COM+, in particular by operating system support for interception. In the first release of MTS, interception was tacked on - installing an MTS component would modify the Windows Registry to call the MTS software, and not the component directly. Windows 2000 also revised the Component Services control panel application used to configure COM+ components.

An advantage of COM+ was that it could be run in "component farms". Instances of a component, if coded properly, could be pooled and reused by new calls to its initializing routine without unloading it from memory. Components could also be distributed (called from another machine). COM+ and Microsoft Visual Studio provided tools to make it easy to generate client-side proxies, so although DCOM was used to make the remote call, it was easy to do for developers. COM+ also introduced a subscriber/publisher event mechanism called COM+ Events, and provided a new way of leveraging MSMQ (a technology that provides inter-application asynchronous messaging) with components called Queued Components. COM+ events extend the COM+ programming model to support late-bound (see Late binding) events or method calls between the publisher or subscriber and the event system.

.NET

Main article: .NET Framework

Microsoft .NET provides means both to provide component technology, and to interact with COM+ (via COM-interop-assemblies); .NET provides wrappers to most of the commonly used COM controls. Microsoft .NET hides most detail from component creation and therefore eases development. .NET can leverage COM+ via the System.EnterpriseServices namespace, and several of the services that COM+ provides have been duplicated in recent releases of .NET. For example, the System.Transactions namespace in .NET provides the TransactionScope class, which provides transaction management without resorting to COM+. Similarly, queued components can be replaced by Windows Communication Foundation with an MSMQ transport. (MSMQ is a native COM component, however.) There is limited support for backward compatibility. A COM object may be used in .NET by implementing a Runtime Callable Wrapper (RCW). NET objects that conform to certain interface restrictions may be used in COM objects by calling a COM callable wrapper (CCW). From both the COM and .NET sides, objects using the other technology appear as native objects. See COM Interop. WCF (Windows Communication Foundation) eases a number of COM's remote execution challenges. For instance, it allows objects to be transparently marshalled by value across process or machine boundaries more easily.

Windows Runtime

Main article: Windows Runtime

Microsoft's Windows Runtime (or WinRT, not to be confused with Windows RT) programming and application model is essentially a COM-based API, although it relies on an enhanced COM. Because of its COM-like basis, Windows Runtime allows relatively easy interfacing from multiple languages, just as COM does, but it is essentially an unmanaged, native API. The API definitions are, however, stored in ".winmd" files, which are encoded in ECMA 335 metadata format, the same CLI metadata format that .NET uses with a few modifications. This common metadata format allows for significantly less overhead than P/Invoke when WinRT is invoked from .NET applications, and its syntax is much simpler.

Nano-COM (a.k.a XPCOM)

Nano-COM is an extremely small subset of the Component Object Model that is focused exclusively on the Application Binary Interface (ABI) aspects of COM that enable function and method calls across independently compiled modules/components. Nano-COM can be expressed easily in a single C++ header file that is portable to all C++ compilers. Nano-COM extends the native ABI of the underlying instruction architecture and OS to add support for typed object references (typical ABIs focus only on atomic types, structures, arrays and function calling conventions). The basis of Nano-COM was used by Mozilla to bootstrap Firefox (called XPCOM), and is currently in use as the base ABI technology for DirectX/Direct3D/DirectML.

A Nano-COM header file defines or names at least three types:

• GUID to identify interface types - this is effectively a 128 bit number
• HRESULT to identify error codes from method calls - this is effectively a standardized usage of 32-bit ints to well known values (S_OK, E_FAIL, E_OUTOFMEMORY, etc)
• IUnknown as the base type for all typed object references - this is effectively abstract virtual functions to support dynamic_cast<T>-style acquisition of new interface types and ref counting a la shared_ptr<T>

Many uses of Nano-COM also define two functions to address callee-allocated memory buffers as results

• <NanoCom>Alloc – called by method implementations to allocate raw buffers (not objects) that are returned to the caller
• <NanoCom>Free – called by method callers to free callee-allocated buffers once no longer in use

Some implementations of Nano-COM such as Direct3D eschew the allocator functions and restrict themselves to only use caller-allocated buffers.

Nano-COM has no notion of classes, apartments, marshaling, registration, etc. Rather, object references are simply passed across function boundaries and allocated via standard language constructs (e.g., C++ new operator).

Security

COM and ActiveX components are run as native code on the user's machine, with no sandboxing. There are therefore few restrictions on what the code can do. The prior practice of embedding ActiveX components on web pages with Internet Explorer did therefore lead to problems with malware infections. Microsoft recognized the problem with ActiveX as far back as 1996 when Charles Fitzgerald said, "We never made the claim up front that ActiveX is intrinsically secure". Recent versions of Internet Explorer prompt the user before installing ActiveX controls, enabling the user to disallow installation of controls from sites that the user does not trust. The ActiveX controls are signed with digital signatures to guarantee their authenticity. It is also possible to disable ActiveX controls altogether, or to allow only a selected few. The transparent support for out-of-process COM servers still promotes software safety in terms of process isolation. This can be useful for decoupling subsystems of large application into separate processes. Process isolation limits state corruption in one process from negatively affecting the integrity of the other processes, since they only communicate through strictly defined interfaces. Thus, only the affected subsystem needs to be restarted in order to regain valid state. This is not the case for subsystems within the same process, where a rogue pointer in one subsystem can randomly corrupt other subsystems.

Technical details

COM programmers build their software using COM-aware components. Different component types are identified by class IDs (CLSIDs), which are Globally Unique Identifiers (GUIDs). Each COM component exposes its functionality through one or more interfaces. The different interfaces supported by a component are distinguished from each other using interface IDs (IIDs), which are GUIDs too. COM interfaces have bindings in several languages, such as C, C++, Visual Basic, Delphi, Python and several of the scripting languages implemented on the Windows platform. All access to components is done through the methods of the interfaces. This allows techniques such as inter-process, or even inter-computer programming (the latter using the support of DCOM).

Interfaces

All COM components implement the IUnknown (custom) interface, which exposes methods for reference counting and type conversion (casting). A custom IUnknown interface consists of a pointer to a virtual method table that contains a list of pointers to the functions that implement the functions declared in the interface, in the same order that they are declared in the interface. The in-process invocation overhead is therefore comparable to virtual method calls in C++. In addition to custom interfaces, COM also supports dispatch interfaces inheriting from IDispatch. Dispatch interfaces support late binding for OLE Automation. This allows dispatch interfaces to be natively accessed from a wider range of programming languages than custom interfaces.

Classes

A COM class ("coclass") is a concrete implementation of one or more interfaces, and closely resembles classes in object-oriented programming languages. Classes are created based on their class ID (CLSID) or based on their programmatic identifier string (ProgID). Like many object-oriented languages, COM provides a separation of interface from implementation. This distinction is especially strong in COM, where objects cannot be accessed directly, but only through their interfaces. COM also has support for multiple implementations of the same interface, so that clients at runtime can choose which implementation of an interface to instantiate.

Interface Definition Language and type libraries

Type libraries contain metadata to represent COM types. These types are described using Microsoft Interface Definition Language (MSIDL/IDL). IDL files define object-oriented classes, interfaces, structures, enumerations and other user-defined types in a language independent manner. IDL is similar in appearance to C++ declarations with some additional keywords such as "interface" and "library" for defining interfaces and collections of classes. IDL also supports the use of bracketed attributes before declarations to provide additional information, such as interface GUIDs and the relationships between pointer parameters and length fields. IDL files are compiled by the MIDL compiler. For C/C++, the MIDL compiler generates a compiler-independent header file containing struct definitions to match the vtbls of the declared interfaces and a C file containing declarations of the interface GUIDs. C++ source code for a proxy module can also be generated by the MIDL compiler. This proxy contains method stubs for converting COM calls into remote procedure calls to enable DCOM for out-of-process communication. IDL files can also be compiled by the MIDL compiler into a type library (TLB). TLB files contain binary metadata that can be processed by different language compilers and runtime environments (e.g. VB, Delphi, .NET etc.) to generate language-specific constructs to represent the COM types defined in the TLB. For C++, this will convert the TLB back to its IDL representation.

Object framework

Because COM is a runtime framework, types have to be individually identifiable and specifiable at runtime. To achieve this, globally unique identifiers (GUIDs) are used. Each COM type is designated its own GUID for identification at runtime. In order for information on COM types to be accessible at both compile time and runtime, COM uses type libraries. It is through the effective use of type libraries that COM achieves its capabilities as a dynamic framework for the interaction of objects.

Consider the following example coclass definition in an IDL:

coclass SomeClass {
  [default] interface ISomeInterface;
};

The above code fragment declares a COM class named SomeClass which implements an interface named ISomeInterface.

This is conceptually equivalent to defining the following C++ class:

class SomeClass : public ISomeInterface {
  ...
  ...
};

where ISomeInterface is a C++ pure virtual class (sometimes called an abstract base class).

The IDL files containing COM interfaces and classes are compiled into type libraries (TLB) files, which can later be parsed by clients at runtime to determine which interfaces an object supports, and invoke an object's interface methods.

In C++, COM objects are instantiated with the CoCreateInstance function that takes the class ID (CLSID) and interface ID (IID) as arguments. Instantiation of SomeClass can be implemented as follows:

ISomeInterface* interface_ptr = NULL;
HRESULT hr = CoCreateInstance(CLSID_SomeClass, NULL, CLSCTX_ALL,
                              IID_ISomeInterface, (void**)&interface_ptr);

In this example, the COM sub-system is used to obtain a pointer to an object that implements ISomeInterface interface, and coclass CLSID_SomeClass's particular implementation of this interface is required.

Reference counting

All COM objects utilize reference counting to manage object lifetimes. The reference counts are controlled by the clients through the AddRef and Release methods in the mandatory IUnknown interface that all COM objects implement. COM objects are then responsible for freeing their own memory when the reference count drops to zero. Certain languages (e.g. Visual Basic) provide automatic reference counting so that COM object developers need not explicitly maintain any internal reference counter in their source codes. In C++, a coder may either perform explicit reference counting or use smart pointers to automatically manage the reference counts.

The following are guidelines for when to call AddRef and Release on COM objects:

• Functions and methods that return interface references (via return value or via "out" parameter) shall increment the reference count of the returned object before returning.
• Release must be called on an interface pointer before the pointer is overwritten or goes out of scope.
• If a copy is made on an interface reference pointer, AddRef should be called on that pointer.
• AddRef and Release must be called on the specific interface which is being referenced since an object may implement per-interface reference counts in order to allocate internal resources only for the interfaces which are being referenced.

Not all reference count calls are sent to remote objects over the wire; a proxy keeps only one reference on the remote object and maintains its own local reference count. To simplify COM development, Microsoft introduced ATL (Active Template Library) for C++ developers. ATL provides for a higher-level COM development paradigm. It also shields COM client application developers from the need to directly maintain reference counting, by providing smart pointer objects. Other libraries and languages that are COM-aware include the Microsoft Foundation Classes, the VC Compiler COM Support, VBScript, Visual Basic, ECMAScript (JavaScript) and Borland Delphi.

Programming

COM is a language agnostic binary standard that can be developed in any programming language capable of understanding and implementing its binary defined data types and interfaces. COM implementations are responsible for entering and leaving the COM environment, instantiating and reference-counting COM objects, querying objects for supported interfaces, as well as handling errors. The Microsoft Visual C++ compiler supports extensions to the C++ language referred to as C++ Attributes. These extensions are designed to simplify COM development and remove much of the boilerplate code required to implement COM servers in C++.

Registry usage

In Windows, COM classes, interfaces and type libraries are listed by GUIDs in the registry, under HKEY_CLASSES_ROOT\CLSID for classes and HKEY_CLASSES_ROOT\Interface for interfaces. COM libraries use the registry to locate either the correct local libraries for each COM object or the network location for a remote service.

Registration-free COM

Registration-Free COM (RegFree COM) is a technology introduced with Windows XP that allows Component Object Model (COM) components to store activation metadata and CLSID (Class ID) for the component without using the registry. Instead, the metadata and CLSIDs of the classes implemented in the component are declared in an assembly manifest (described using XML), stored either as a resource in the executable or as a separate file installed with the component. This allows multiple versions of the same component to be installed in different directories, described by their own manifests, as well as XCOPY deployment. This technique has limited support for EXE COM servers and cannot be used for system-wide components such as MDAC, MSXML, DirectX or Internet Explorer.

During application loading, the Windows loader searches for the manifest. If it is present, the loader adds information from it to the activation context. When the COM class factory tries to instantiate a class, the activation context is first checked to see if an implementation for the CLSID can be found. Only if the lookup fails, the registry is scanned.

Manually instantiating COM objects

COM objects can also be created manually, given the path of the DLL file and GUID of the object. This does not require the DLL or GUID to be registered in the system registry, and does not make use of manifest files. A COM DLL exports a function named DllGetClassObject. Calling DllGetClassObject with the desired GUID and IID_IClassFactory provides an instance of a factory object. The Factory object has a CreateInstance method, which can create instances of an object given an interface GUID. This is the same process internally used when creating instances of registered COM components.

If the created COM object instantiates another COM object using the generic CoCreateInstance API, it will try to do so in the usual generic way, using the registry or manifest files. But it can create internal objects (which may not be registered at all), and hand out references to interfaces to them, using its own private knowledge.

Process and network transparency

COM objects can be transparently instantiated and referenced from within the same process (in-process), across process boundaries (out-of-process), or remotely over the network (DCOM). Out-of-process and remote objects use marshalling to serialize method calls and return values over process or network boundaries. This marshalling is invisible to the client, which accesses the object as if it were a local in-process object.

Threading

In COM, threading is addressed through a concept known as apartments. An individual COM object lives in exactly one apartment, which might either be single-threaded or multi-threaded. There are three types of apartments in COM: Single-Threaded Apartment (STA), Multi-Threaded Apartment (MTA), and Thread Neutral Apartment (NA). Each apartment represents one mechanism whereby an object's internal state may be synchronized across multiple threads. A process can consist of multiple COM objects, some of which may use STA and others of which may use MTA. All threads accessing COM objects similarly live in one apartment. The choice of apartment for COM objects and threads are determined at run-time, and cannot be changed.

Apartment type	Description
Single-Threaded Apartment (STA), (ThreadingModel=Apartment)	A single thread is dedicated to execute the methods of the object. In such an arrangement, method calls from threads outside of the apartment are marshalled and automatically queued by the system (via a standard Windows message queue). Thus, the COM run-time provides automatic synchronization to ensure that each method call of an object is always executed to completion before another is invoked. The developer therefore does not need to worry about thread locking or race conditions.
Multi-Threaded Apartment (MTA), (ThreadingModel=Free)	The COM run-time provides no synchronization, and multiple threads are allowed to call COM objects simultaneously. COM objects therefore need to perform their own synchronization to prevent simultaneous access from multiple threads from causing a race condition. Calls to an MTA object from a thread in an STA are also marshalled.
Dynamically determined apartment (ThreadingModel=Both)	In the Both apartment mode, the server auto-selects STA or MTA at object creation to match the apartment type of the calling thread. This can be useful to avoid marshaling overhead when MTA servers are accessed by a STA thread.
Thread Neutral Apartment (NA), (ThreadingModel=Neutral)	A special apartment without any assigned threads. When an STA or MTA thread calls an NA object in the same process, then the calling thread temporarily leaves its apartment and executes code directly in the NA without any thread switching. Therefore, one can think of NA as an optimization for efficient interapartment method calls.

Threads and objects which belong to the same apartment follow the same thread access rules. Method calls which are made inside the same apartment are therefore performed directly without any assistance from COM. Method calls made across apartments are achieved via marshalling. This requires the use of proxies and stubs.

Criticisms

Since COM has a fairly complex implementation, programmers can be distracted by some of the "plumbing" issues.

Message pumping

When an STA is initialized it creates a hidden window that is used for inter-apartment and inter-process message routing. This window must have its message queue regularly "pumped". This construct is known as a "message pump". On earlier versions of Windows, failure to do so could cause system-wide deadlocks. This problem is complicated by some Windows APIs that initialize COM as part of their implementation, which causes a "leak" of implementation details.

Reference counting

Reference counting within COM may cause problems if two or more objects are circularly referenced. The design of an application must take this into account so that objects are not left orphaned. Objects may also be left with active reference counts if the COM "event sink" model is used. Since the object that fires the event needs a reference to the object reacting to the event, the latter's reference count will never reach zero. Reference cycles are typically broken using either out-of-band termination or split identities. In the out-of-band termination technique, an object exposes a method which, when called, forces it to drop its references to other objects, thereby breaking the cycle. In the split identity technique, a single implementation exposes two separate COM objects (also known as identities). This creates a weak reference between the COM objects, preventing a reference cycle.

DLL Hell

Because in-process COM components are implemented in DLL files and registration only allows for a single version per CLSID, they might in some situations be subject to the "DLL Hell" effect. Registration-free COM capability eliminates this problem for in-process components; registration-free COM is not available for out-of-process servers.

Java applet

From Wikipedia, the free encyclopedia

https://en.wikipedia.org/wiki/Java_applet 

A Java applet that was created as supplementary demonstration material for a scientific publication

A Java applet that uses 3D hardware acceleration to visualize 3D files in .pdb format downloaded from a server

Using applet for nontrivial animation illustrating biophysical topic (randomly moving ions pass through voltage gates)

Using a Java applet for computation – intensive visualization of the Mandelbrot set

Applets' running speed is sufficient for making e.g. nontrivial computer games that play chess.

NASA World Wind (open source) is a second generation applet that makes heavy use of OpenGL and on-demand data downloading to provide a detailed 3D map of the world.

Web access to the server console at the hardware level with the help of a Java applet

Demonstration of image processing using two dimensional Fourier transform

Java applets were small applications written in the Java programming language, or another programming language that compiles to Java bytecode, and delivered to users in the form of Java bytecode. The user launched the Java applet from a web page, and the applet was then executed within a Java virtual machine (JVM) in a process separate from the web browser itself. A Java applet could appear in a frame of the web page, a new application window, Sun's AppletViewer, or a stand-alone tool for testing applets.

Java applets were introduced in the first version of the Java language, which was released in 1995. Beginning in 2013, major web browsers began to phase out support for the underlying technology applets used to run, with applets becoming completely unable to be run by 2015–2017. Java applets were deprecated by Java 9 in 2017.

Java applets were usually written in Java, but other languages such as Jython, JRuby, Pascal, Scala, NetRexx, or Eiffel (via SmartEiffel) could be used as well.

Java applets run at very fast speeds and until 2011, they were many times faster than JavaScript.^{[citation needed]} Unlike JavaScript, Java applets had access to 3D hardware acceleration, making them well-suited for non-trivial, computation-intensive visualizations. As browsers have gained support for hardware-accelerated graphics thanks to the canvas technology (or specifically WebGL in the case of 3D graphics), as well as just-in-time compiled JavaScript, the speed difference has become less noticeable.

Since Java bytecode is cross-platform (or platform independent), Java applets could be executed by clients for many platforms, including Microsoft Windows, FreeBSD, Unix, macOS and Linux. They could not be run on mobile devices, which do not support running standard Oracle JVM bytecode. Android devices can run code written in Java compiled for the Android Runtime.

Overview

The applets are used to provide interactive features to web applications that cannot be provided by HTML alone. They can capture mouse input and also have controls like buttons or check boxes. In response to user actions, an applet can change the provided graphic content. This makes applets well-suited for demonstration, visualization, and teaching. There are online applet collections for studying various subjects, from physics to heart physiology.

An applet can also be a text area only; providing, for instance, a cross-platform command-line interface to some remote system. If needed, an applet can leave the dedicated area and run as a separate window. However, applets have very little control over web page content outside the applet's dedicated area, so they are less useful for improving the site appearance in general, unlike other types of browser extensions (while applets like news tickers or WYSIWYG editors are also known). Applets can also play media in formats that are not natively supported by the browser.

Pages coded in HTML may embed parameters within them that are passed to the applet. Because of this, the same applet may have a different appearance depending on the parameters that were passed.

As applets were available before HTML5, modern CSS and JavaScript interface DOM were standard, they were also widely used for trivial effects such as mouseover and navigation buttons. This approach, which posed major problems for accessibility and misused system resources, is no longer in use and was strongly discouraged even at the time.

Technical information

Most browsers executed Java applets in a sandbox, preventing applets from accessing local data like the file system. The code of the applet was downloaded from a web server, after which the browser either embedded the applet into a web page or opened a new window showing the applet's user interface.

The first implementations involved downloading an applet class by class. While classes are small files, there are often many of them, so applets got a reputation as slow-loading components. However, since .jars were introduced, an applet is usually delivered as a single file that has a size similar to an image file (hundreds of kilobytes to several megabytes).

Java system libraries and runtimes are backwards-compatible, allowing one to write code that runs both on current and on future versions of the Java virtual machine.

Similar technologies

Many Java developers, blogs and magazines recommended that the Java Web Start technology be used in place of applets. Java Web Start allowed the launching of unmodified applet code, which then ran in a separate window (not inside the invoking browser).

A Java Servlet is sometimes informally compared to be "like" a server-side applet, but it is different in its language, functions, and in each of the characteristics described here about applets.

Embedding into a web page

The applet would be displayed on the web page by making use of the deprecated applet HTML element, or the recommended object element. The embed element can be used with Mozilla family browsers (embed was deprecated in HTML 4 but is included in HTML 5). This specifies the applet's source and location. Both object and embed tags can also download and install Java virtual machine (if required) or at least lead to the plugin page. applet and object tags also support loading of the serialized applets that start in some particular (rather than initial) state. Tags also specify the message that shows up in place of the applet if the browser cannot run it due to any reason.

However, despite object being officially a recommended tag in 2010, the support of the object tag was not yet consistent among browsers and Sun kept recommending the older applet tag for deploying in multibrowser environments, as it remained the only tag consistently supported by the most popular browsers. To support multiple browsers, using the object tag to embed an applet would require JavaScript (that recognizes the browser and adjusts the tag), usage of additional browser-specific tags or delivering adapted output from the server side.

The Java browser plug-in relied on NPAPI, which nearly all web browser vendors have removed support for, or do not implement, due to its age and security issues. In January 2016, Oracle announced that Java runtime environments based on JDK 9 will discontinue the browser plug-in.

Advantages

A Java applet could have any or all of the following advantages:

• It was simple to make it work on FreeBSD, Linux, Microsoft Windows and macOS – that is, to make it cross-platform. Applets were supported by most web browsers through the first decade of the 21st century; since then, however, most browsers have dropped applet support for security reasons.
• The same applet would work on "all" installed versions of Java at the same time, rather than just the latest plug-in version only. However, if an applet requires a later version of the Java Runtime Environment (JRE) the client would be forced to wait during the large download.
• Most web browsers cached applets so they were quick to load when returning to a web page. Applets also improved with use: after a first applet is run, the JVM was already running and subsequent applets started quickly (the JVM will need to restart each time the browser starts afresh). JRE versions 1.5 and greater restarted the JVM when the browser navigates between pages, as a security measure which removed that performance gain.
• It moved work from the server to the client, making a web solution more scalable with the number of users/clients.
• If a standalone program (like Google Earth) talks to a web server, that server normally needs to support all prior versions for users who have not kept their client software updated. In contrast, a browser loaded (and cached) the latest applet version, so there is no need to support legacy versions.
• Applet naturally supported changing user state, such as figure positions on the chessboard.
• Developers could develop and debug an applet directly simply by creating a main routine (either in the applet's class or in a separate class) and calling init() and start() on the applet, thus allowing for development in their favorite Java SE development environment. All one had to do was to re-test the applet in the AppletViewer program or a web browser to ensure it conforms to security restrictions.
• An untrusted applet had no access to the local machine and can only access the server it came from. This makes applets much safer to run than the native executables that they would replace. However, a signed applet could have full access to the machine it is running on, if the user agreed.
• Java applets were fast, with similar performance to natively installed software.

Disadvantages

Java applets had the following disadvantages compared to other client-side web technologies:

• Java applets would depend on a Java Runtime Environment (JRE), a complex and heavy-weight software package. They also normally required a plug-in for the web browser. Some organizations only allow software installed by an administrator. As a result, users were unable to view applets unless one was important enough to justify contacting the administrator to request installation of the JRE and plug-in.
• If an applet requires a newer JRE than available on the system, the user running it the first time will need to wait for the large JRE download to complete.
• Mobile browsers on iOS or Android, never run Java applets at all. Even before the deprecation of applets on all platforms, desktop browsers phased out Java applet support concurrently with the rise of mobile operating systems.
• There was no standard to make the content of applets available to screen readers. Therefore, applets harmed the accessibility of a web site to users with special needs.
• As with any client-side scripting, security restrictions made it difficult or even impossible for some untrusted applets to achieve their desired goals. Only by editing the java.policy file in the JAVA JRE installation could one grant access to the local filesystem or system clipboard, or to network sources other than the one that served the applet to the browser.
• Most users did not care about the difference between untrusted and trusted applets, so this distinction did not help much with security. The ability to run untrusted applets was eventually removed entirely to fix this, before all applets were removed.

Compatibility-related lawsuits

Sun made considerable efforts to ensure compatibility is maintained between Java versions as they evolve, enforcing Java portability by law if required. Oracle seems to be continuing the same strategy.

1997: Sun vs Microsoft

The 1997 lawsuit, was filed after Microsoft created a modified Java Virtual Machine of their own, which shipped with Internet Explorer. Microsoft added about 50 methods and 50 fields into the classes within the java.awt, java.lang, and java.io packages. Other modifications included removal of RMI capability and replacement of Java Native Interface from JNI to RNI, a different standard. RMI was removed because it only easily supports Java to Java communications and competes with Microsoft DCOM technology. Applets that relied on these changes or just inadvertently used them worked only within Microsoft's Java system. Sun sued for breach of trademark, as the point of Java was that there should be no proprietary extensions and that code should work everywhere. Microsoft agreed to pay Sun $20 million, and Sun agreed to grant Microsoft limited license to use Java without modifications only and for a limited time.

2002: Sun vs Microsoft

Microsoft continued to ship its own unmodified Java virtual machine. Over the years it became extremely outdated yet still default for Internet Explorer. A later study revealed that applets of this time often contain their own classes that mirror Swing and other newer features in a limited way. In 2002, Sun filed an antitrust lawsuit, claiming that Microsoft's attempts at illegal monopolization had harmed the Java platform. Sun demanded Microsoft distribute Sun's current, binary implementation of Java technology as part of Windows, distribute it as a recommended update for older Microsoft desktop operating systems and stop the distribution of Microsoft's Virtual Machine (as its licensing time, agreed in the prior lawsuit, had expired). Microsoft paid $700 million for pending antitrust issues, another $900 million for patent issues and a $350 million royalty fee to use Sun's software in the future.

Security

There were two applet types with very different security models: signed applets and unsigned applets. Starting with Java SE 7 Update 21 (April 2013) applets and Web-Start Apps are encouraged to be signed with a trusted certificate, and warning messages appear when running unsigned applets. Further, starting with Java 7 Update 51 unsigned applets were blocked by default; they could be run by creating an exception in the Java Control Panel.

Unsigned

Limits on unsigned applets were understood as "draconian": they have no access to the local filesystem and web access limited to the applet download site; there are also many other important restrictions. For instance, they cannot access all system properties, use their own class loader, call native code, execute external commands on a local system or redefine classes belonging to core packages included as part of a Java release. While they can run in a standalone frame, such frame contains a header, indicating that this is an untrusted applet. Successful initial call of the forbidden method does not automatically create a security hole as an access controller checks the entire stack of the calling code to be sure the call is not coming from an improper location.

As with any complex system, many security problems have been discovered and fixed since Java was first released. Some of these (like the Calendar serialization security bug) persisted for many years with nobody being aware. Others have been discovered in use by malware in the wild.

Some studies mention applets crashing the browser or overusing CPU resources but these are classified as nuisances and not as true security flaws. However, unsigned applets may be involved in combined attacks that exploit a combination of multiple severe configuration errors in other parts of the system. An unsigned applet can also be more dangerous to run directly on the server where it is hosted because while code base allows it to talk with the server, running inside it can bypass the firewall. An applet may also try DoS attacks on the server where it is hosted, but usually people who manage the web site also manage the applet, making this unreasonable. Communities may solve this problem via source code review or running applets on a dedicated domain.

The unsigned applet can also try to download malware hosted on originating server. However it could only store such file into a temporary folder (as it is transient data) and has no means to complete the attack by executing it. There were attempts to use applets for spreading Phoenix and Siberia exploits this way, but these exploits do not use Java internally and were also distributed in several other ways.

Signed

A signed applet contains a signature that the browser should verify through a remotely running, independent certificate authority server. Producing this signature involves specialized tools and interaction with the authority server maintainers. Once the signature is verified, and the user of the current machine also approves, a signed applet can get more rights, becoming equivalent to an ordinary standalone program. The rationale is that the author of the applet is now known and will be responsible for any deliberate damage. This approach allows applets to be used for many tasks that are otherwise not possible by client-side scripting. However, this approach requires more responsibility from the user, deciding whom he or she trusts. The related concerns include a non-responsive authority server, wrong evaluation of the signer identity when issuing certificates, and known applet publishers still doing something that the user would not approve of. Hence signed applets that appeared from Java 1.1 may actually have more security concerns.

Self-signed

Self-signed applets, which are applets signed by the developer themselves, may potentially pose a security risk; java plugins provide a warning when requesting authorization for a self-signed applet, as the function and safety of the applet is guaranteed only by the developer itself, and has not been independently confirmed. Such self-signed certificates are usually only used during development prior to release where third-party confirmation of security is unimportant, but most applet developers will seek third-party signing to ensure that users trust the applet's safety.

Java security problems are not fundamentally different from similar problems of any client-side scripting platform. In particular, all issues related to signed applets also apply to Microsoft ActiveX components.

As of 2014, self-signed and unsigned applets are no longer accepted by the commonly available Java plugins or Java Web Start. Consequently, developers who wish to deploy Java applets have no alternative but to acquire trusted certificates from commercial sources.

Alternatives

Alternative technologies exist (for example, WebAssembly and JavaScript) that satisfy all or more of the scope of what was possible with an applet. JavaScript could coexist with applets in the same page, assist in launching applets (for instance, in a separate frame or providing platform workarounds) and later be called from the applet code. As JavaScript gained in features and performance, the support for and use of applets declined, until their eventual removal.