The execution context internally used by the underlying PIDE implementation.
The execution context internally used by the underlying PIDE implementation.
It is allowed to override the execution context of internal PIDE implementation during initialization, but it must remain fixed afterwards. This field must be set to that execution context.
Implementations should ensure that the underlying thread pool consists of daemon threads, rendering disposing of running systems unnecessary. (The secondary reason is to avoid a hanging JVM when user code did not handle an exception, the main thread gets terminated, but worker threads are keeping the JVM alive.)
This is exposed to the user via
System#executionContext.
Abstract interface for an Isabelle environment of a particular version in a path with an underlying PIDE machinery.
As opposed to a mere logic-less
Setup, an environment knows how to manage Isabelle processes. It can also manage multiple running processes at the same time.A subclass of this class is called implementation throughout
libisabelle. TheImplementationsclass serves as a registry of those and using it is strongly recommended. (Since subclasses shouldprotecttheir constructors, manual instantiation would not work anyway.)For multi-home or multi-version scenarios, it is highly recommended that users create environments through the appropriate function of a registry. See its documentation for an explanation.
If in doubt, users should prefer the direct (manual) instantiation.
While implementations may be created freely by users, it is recommended to only use the bundled implementations for the supported Isabelle versions. By convention, they live in the package
edu.tum.cs.isabelle.impland their class name is alsoEnvironment.Contract
java.nio.file.Path). There must be no other constructors. The constructor should beprotected, but must be accessible from any class in the isabelle package.Implementation, where the given identifier corresponds to the version identifier.Footnote
Due to name clashes in the underlying PIDE machinery (which is provided by Isabelle itself and is not under control of
libisabelle), it is impossible to have multiple environments for different versions in the same class loader. This is the primary reason why this class exists in the first place, to enable seamless abstraction over multiple PIDEs.As the caveat above states, not even multi-home scenarios are supported without going through a registry. The user has to ensure that this happens, since this class does not attempt to detect such a situation. While in principle it could do so, it would require the introduction of even more global mutable state. It might do so in the future.