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
.It is highly recommended to use edu.tum.cs.isabelle.setup.Setup#makeEnvironment to instantiate implementations.
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.impl
. See alsoSetup.defaultPackageName
.Contract
Environment
. There must be aBuildInfo
class in the same package.java.nio.file.Path
). There must be no other constructors. The constructor should beprivate
.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.