I dare to speak for Tomas on this issue an I think this is an
intentional change; please use forName(JavaProject, String) to find
your class. In new project system, there are no assumptions on
libraries or jre used, so you have to parser the JavaProject instance
to supply that information. Because there may be several projects
opened at a time, the environment may change from project to project.

There could be some defaults used, but it seems that it is better to
break a functionality in a defined way for a major version than to
trace strange bugs of type "why feature XXX does not work with
jre-specific classes/libraries added to the project/..." in all code.

Yes, Svata is absolutely right. This was an intentional change. Use 
ClassElement.forName(JavaProject, String).

Simply altering the method to return null, trading compile time errors
for runtime errors, is not an acceptable solution.  At the very least
you should have thrown a runtime exception, such as
UnsupportedOperationException.  As it is, callers have no way of
knowing that the data returned (null) is bogus unless they happen to
examine the source or use a debugger.

You also should not be both deprecating APIs and removing their
functionality simultaneously.  The point of deprecation is to issue
compile-time warnings while preserving functionality, so that callers
have a chance for at least one release to switch to a new API.  When
you change the functionality, callers instantly break.

Either remove the method or restore its functionality.

A agree that throwing RuntimeException is better than returning null.
But the functionality can not be preserved.
If the source hierarchy hasn't classpath it is unable to do anything,
it is a cost for replacing "mounted filesystem == classpath" approach.
The NetBeans 4.0 is not compatible with NetBeans 3.x and this is one
of the points where the compatibility can not be preserved.

I will change the method to throw RuntimeException.

If the functionality is not going to be preserved then the API should 
be removed.  Throwing a runtime exception only delays the discovery 
process and perhaps masks it.  Better to discover when you compile 
that your code is broken than wait until runtime.  Moreover the 
former is guaranteed, the later is subject to use.  

In either case (removal or throwing an exception) the high-impact 
integration process should be followed.  All developers should be 
warned of this change and have opportunity to modify their code in 
advance of the integration.  We need to keep the code working and not 
introduce regressions -- especially ones that may not be caught until 
long after the integration that introduced them.

I agree.

Reopening this until the method is removed.  See Jeff's note about the
process for doing this.

The projects prototype has been canceled so the issue is irrelevant.
For more details see
http://www.netbeans.org/servlets/ReadMsg?msgId=619519&listName=nbdiscuss

Reorganization of java component