This document lists changes made to the ClassPath APIs. Please ask on the
dev@java.netbeans.org
or nbdev@netbeans.org
mailing list if you have any questions about the details of a
change, or are wondering how to convert existing code to be compatible.
Fuller descriptions of all changes can be found below (follow links).
Not all deprecations are listed here, assuming that the deprecated APIs continue to essentially work. For a full deprecation list, please consult the Javadoc.
ClassPath
API changed to be pluggable and better support build system
ClassPath
switching among several ClassPath
instances
GlobalPathRegistry
ClassPath
API changed to be pluggable and better support build system
GlobalPathRegistry
These API specification versions may be used to indicate that a module requires a certain API feature in order to function. For example, if you see here a feature you need which is labelled 1.20, your manifest should contain in its main attributes the line:
OpenIDE-Module-Module-Dependencies: org.netbeans.api.java.classpath/1 > 1.20
ClassPath
switching among several ClassPath
instances
GlobalPathRegistry
ClassPath
API changed to be pluggable and better support build system
GlobalPathRegistry
org.netbeans.api.java.queries.BinaryForSourceQuery
org.netbeans.spi.java.queries.BinaryForSourceQueryImplementation
org.netbeans.spi.java.queries.BinaryForSourceQueryImplementation2
org.netbeans.api.java.classpath.ClassPath
ClassPath
API changed to be pluggable and better support build system
org.netbeans.spi.java.classpath.ClassPathFactory
org.netbeans.spi.java.classpath.ClassPathImplementation
org.netbeans.spi.java.classpath.ClassPathProvider
org.netbeans.spi.java.classpath.support.ClassPathSupport
ClassPath
switching among several ClassPath
instances
ClassPath
API changed to be pluggable and better support build system
org.netbeans.spi.java.classpath.support.CompositePathResourceBase
org.netbeans.spi.java.classpath.FilteringPathResourceImplementation
org.netbeans.spi.java.classpath.FlaggedClassPathImplementation
org.netbeans.api.java.classpath.GlobalPathRegistry
GlobalPathRegistry
org.netbeans.spi.java.classpath.GlobalPathRegistryImplementation
org.netbeans.spi.java.classpath.support.PathResourceBase
org.netbeans.spi.java.classpath.PathResourceImplementation
org.netbeans.api.java.queries.SourceForBinaryQuery
org.netbeans.spi.java.queries.support.SourceForBinaryQueryImpl2Base
org.netbeans.spi.java.queries.SourceForBinaryQueryImplementation2
BinaryForSourceQuery
BinaryForSourceQueryImplementation2
; made by: jtulach
New Result2
and new BinaryForSourceQueryImplementation2
that allows one to specify that binaries should be used instead
of compiling the sources (if the binaries are already compiled and
newer).
ClassPath
switching among several ClassPath
instances
ClassPathSupport
; made by: tzezula
Added a factory method into ClassPathSupport
creating a ClassPath
switching among several ClassPath
instances.
ClassPath
; made by: tzezula
Added a policy for handling in archive paths while converting the ClassPath
to String
.
The ClassPath.toString
takes a PathEmbeddingMode
parameter determining how the in archive
path is handled. It can be included into stringified root, omitted from it, or handled as an invalid classpath root.
GlobalPathRegistry
GlobalPathRegistryImplementation
; made by: tzezula
Added a SPI interface to allow different implementations of the GlobalPathRegistry
.
The GlobalPathRegistry
uses the first instance od the GlobalPathRegistryImplementation
registered in the global Lookup
ClassPath
FlaggedClassPathImplementation
; made by: tzezula; issues:
#245155
Added flags to ClassPath
Added a constant representing an empty ClassPath like java.util.Collections.EMPTY_LIST. This ClassPath has no entries and never fires any events.
The copy of the ClassPath API was used by generic scripting framework, which cannot depend on the java cluster. To remove this copy of the ClassPath API the java API needs to be splitted into the ClassPath API (IDE cluster) and the rest of the java API (java cluster).
ClassPath
ClassPathSupport
; made by: jglick; issues:
#59311
ClassPath.toString(PathConversionMode)
and
ClassPathSupport.createClassPath(String)
can be used to easily convert between traditional string classpaths
and NetBeans' internal representation.
ClassPath
FilteringPathResourceImplementation
; made by: jglick; issues:
#49026
Classpath implementations can now specify which files and folders/packages to include
or exclude. (This could be used for binary classpaths such as COMPILE
but
currently only excludes on SOURCE
paths are honored by Java language features.)
It is possible for clients of existing ClassPath
methods to have made
assumptions about their behavior that are no longer true.
ClassPath
API changed to be pluggable and better support build system
ClassPath
ClassPathProvider
ClassPathFactory
ClassPathImplementation
PathResourceImplementation
ClassPathSupport
CompositePathResourceBase
PathResourceBase
; made by: jglick
ClassPath
is now final, not abstract. (Not
incompatible, since the constructor was never public.) Same
for ClassPath.Entry
.
getClassPath
now looks for
ClassPathProvider
s rather than delegating to the
filesystems mounted in Repository
.
The classpath type DEBUG
was deprecated.
SOURCE
and BOOT
were added.
ClassPath.Entry.getURL()
was added.
There is a complete SPI for creating ClassPath
instances.
Code which just called ClassPath.getClassPath
and so on as API clients should still be safe, but
passing null as a reference file no longer works.
GlobalPathRegistry
GlobalPathRegistry
; made by: jglick
GlobalPathRegistry
to represent
classpaths of current interest, typically from open projects.
Note that GlobalPathRegistry
serves some of the
same functions as Repository.default
used to,
but client code should be reviewed carefully for usage.
null
. Although the implementation functioned that way
from the beginning, it is considered an incompatible change (tightening of
the contract).
SourceForBinaryQueryImpl2Base
; made by: tzezula; issues:
#129884
Added support base class for SourceForBinaryQueryImplementation2 which delegates to other SourceForBinaryQueryImplementations.
SourceForBinaryQuery
SourceForBinaryQueryImplementation2
; made by: tzezula; issues:
#128695
It is possible for the SouceForBinaryQuery provider to specify whether the java module should prefer sources or binaries. In general sources should be preferred for projects where user can make modification. The binaries should be preferred for libraries and platforms where sources may not be complete or correct.
BinaryForSourceQuery
BinaryForSourceQueryImplementation
; made by: tzezula
The new API BinaryForSourceQuery was added to allow clients to find out the output (class files) corresponding to source root. The query uses instances of a SPI interface BinaryForSourceQueryImplementation registered in the system lookup to find out the binaries. When no binary is found it uses the default algorithm (SFBQ.findSources(ClassPath.EXECUTE) == sourceRoot)