Using Java 6 or later, the classpath option supports wildcards. Note the following:
- Use straight quotes (
"
)
- Use
*
, not *.jar
Windows
java -cp "Test.jar;lib/*" my.package.MainClass
Unix
java -cp "Test.jar:lib/*" my.package.MainClass
This is similar to Windows, but uses :
instead of ;
. If you cannot use wildcards, bash
allows the following syntax (where lib
is the directory containing all the Java archive files):
java -cp "$(printf %s: lib/*.jar)"
(Note that using a classpath is incompatible with the -jar
option. See also: Execute jar file with multiple classpath libraries from command prompt)
Understanding Wildcards
From the Classpath document:
Class path entries can contain the basename wildcard character *
, which is considered equivalent to specifying a list of all the files
in the directory with the extension .jar
or .JAR
. For example, the
class path entry foo/*
specifies all JAR files in the directory named
foo. A classpath entry consisting simply of *
expands to a list of all
the jar files in the current directory.
A class path entry that contains *
will not match class files. To
match both classes and JAR files in a single directory foo, use either
foo;foo/*
or foo/*;foo
. The order chosen determines whether the
classes and resources in foo
are loaded before JAR files in foo
, or
vice versa.
Subdirectories are not searched recursively. For example, foo/*
looks
for JAR files only in foo
, not in foo/bar
, foo/baz
, etc.
The order in which the JAR files in a directory are enumerated in the
expanded class path is not specified and may vary from platform to
platform and even from moment to moment on the same machine. A
well-constructed application should not depend upon any particular
order. If a specific order is required then the JAR files can be
enumerated explicitly in the class path.
Expansion of wildcards is done early, prior to the invocation of a
program's main method, rather than late, during the class-loading
process itself. Each element of the input class path containing a
wildcard is replaced by the (possibly empty) sequence of elements
generated by enumerating the JAR files in the named directory. For
example, if the directory foo
contains a.jar
, b.jar
, and c.jar
, then
the class path foo/*
is expanded into foo/a.jar;foo/b.jar;foo/c.jar
,
and that string would be the value of the system property
java.class.path
.
The CLASSPATH
environment variable is not treated any differently from
the -classpath
(or -cp
) command-line option. That is, wildcards are
honored in all these cases. However, class path wildcards are not
honored in the Class-Path jar-manifest
header.
Note: due to a known bug in java 8, the windows examples must use a backslash preceding entries with a trailing asterisk: https://bugs.openjdk.java.net/browse/JDK-8131329
I have to ask a question in return: is your GenSet
"checked" or "unchecked"?
What does that mean?
Checked: strong typing. GenSet
knows explicitly what type of objects it contains (i.e. its constructor was explicitly called with a Class<E>
argument, and methods will throw an exception when they are passed arguments that are not of type E
. See Collections.checkedCollection
.
-> in that case, you should write:
public class GenSet<E> {
private E[] a;
public GenSet(Class<E> c, int s) {
// Use Array native method to create array
// of a type only known at run time
@SuppressWarnings("unchecked")
final E[] a = (E[]) Array.newInstance(c, s);
this.a = a;
}
E get(int i) {
return a[i];
}
}
Unchecked: weak typing. No type checking is actually done on any of the objects passed as argument.
-> in that case, you should write
public class GenSet<E> {
private Object[] a;
public GenSet(int s) {
a = new Object[s];
}
E get(int i) {
@SuppressWarnings("unchecked")
final E e = (E) a[i];
return e;
}
}
Note that the component type of the array should be the erasure of the type parameter:
public class GenSet<E extends Foo> { // E has an upper bound of Foo
private Foo[] a; // E erases to Foo, so use Foo[]
public GenSet(int s) {
a = new Foo[s];
}
...
}
All of this results from a known, and deliberate, weakness of generics in Java: it was implemented using erasure, so "generic" classes don't know what type argument they were created with at run time, and therefore can not provide type-safety unless some explicit mechanism (type-checking) is implemented.
Best Answer
I think there are only two ways two ways to know when a method of an EJB (or any other class) is called:
Bad solution: using the Java Debug Interface (JDI) you can know which line is executed, as you know it when you are debugging Java with your IDE. It's complicated and there are some problems when you are debugging an application in the same JVM where JDI runs.
Good solution: as Thomas Owens says, AOP is the recommended solution. If you are not using it in your project now, this is a good reason for using it.