Package jetbrains.mps.reloading

Interface IClassPathItem

All Superinterfaces:

ClassBytesProvider

All Known Implementing Classes:

CompositeClassPathItem, JarFileClassPathItem, RealClassPathItem

public interface IClassPathItem
extends ClassBytesProvider

Why methods of these class are deprecated and get removed one by one? The reason is their contract is vague. Whether getAvailableClasses(String) returns anonymous inner classes or not, whether hasClass(String) answers true for them and ClassBytesProvider.getClassBytes(String) treats inner/anonymous classes in any special way. What's in the name of inner class, whether it's dot-separated (human-friendly notation) or '$'-separated (computer-frriendly) is unspecified. It is easier to throw this class away than to enforce a contract.

Nested Class Summary

Nested classes/interfaces inherited from interface jetbrains.mps.reloading.ClassBytesProvider

ClassBytesProvider.ClassBytes, ClassBytesProvider.DefaultClassBytes

Method Summary

Modifier and Type	Method	Description
void	accept(IClassPathItemVisitor visitor)
static IClassPathItem	createClassPathItem(Collection<String> cp)
List<RealClassPathItem>	flatten()
Iterable<String>	getAvailableClasses(String namespace)	Deprecated. the only distinction between this method and getRootClasses(String) is that this one gives inner classes, but is it something anyone care about? The only use of this method (getAvailableClasses().iterator().hasNext()) would work the same with getRootClasses (inner classes could not be there it there are no outer)
URL	getResource(String name)	The contract is the same as in the ClassLoader.getResource(String)
Enumeration<URL>	getResources(String name)
Iterable<String>	getRootClasses(String namespace)	Deprecated. The only client of this method doesn't seem to be really bound to particular iteration order and could live with API like getAllClasses()
Iterable<String>	getSubpackages(String namespace)	Deprecated. there are 2 uses of the method, 1 is to be replaced with hasPackage(String), another shall get refactored as there's no need in specific iteration order
boolean	hasClass(String name)
boolean	hasPackage(String name)
IClassPathItem	optimize()

Methods inherited from interface jetbrains.mps.reloading.ClassBytesProvider

getClass, getClassBytes

Method Detail

hasClass

boolean hasClass(String name)

hasPackage

boolean hasPackage(@NotNull
                   String name)

Parameters:

name - qualified package name

Returns:

true if this classpath item knows about classes in specified package or any subpackage thereof.

getResource

@Nullable
URL getResource(String name)

The contract is the same as in the ClassLoader.getResource(String)

Returns:

a URL object or null if no resource was found or the invoker does not have required privileges

getResources

Enumeration<URL> getResources(String name)

getRootClasses

@Deprecated
Iterable<String> getRootClasses(String namespace)

Deprecated.

The only client of this method doesn't seem to be really bound to particular iteration order and could live with API like getAllClasses()

getAvailableClasses

@Deprecated
Iterable<String> getAvailableClasses(String namespace)

Deprecated.

the only distinction between this method and getRootClasses(String) is that this one gives inner classes, but is it something anyone care about? The only use of this method (getAvailableClasses().iterator().hasNext()) would work the same with getRootClasses (inner classes could not be there it there are no outer)

getSubpackages

@Deprecated
Iterable<String> getSubpackages(String namespace)

Deprecated.

there are 2 uses of the method, 1 is to be replaced with hasPackage(String), another shall get refactored as there's no need in specific iteration order

flatten

List<RealClassPathItem> flatten()

optimize

IClassPathItem optimize()

accept

void accept(IClassPathItemVisitor visitor)

createClassPathItem

@NotNull
static IClassPathItem createClassPathItem(Collection<String> cp)