JDK-6424327 : JavaFileManager().getClassLoader(CLASS_PATH) throws UnsupportedOperationException
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 6
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 2006-05-10
  • Updated: 2010-04-02
  • Resolved: 2006-05-10
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6Resolved
Related Reports
Duplicate :  
Description
I have a customer who tried running the following:

    @Override public void attachTo( final CommandEnvironment env ) {
	super.attachTo(env);
	classLoader = env.getJavaFileManager().getClassLoader( CLASS_PATH );
    }

Jackpot currently returns an unmodified DefaultFileManager instance, which throws the following exception:

Caused by: java.lang.UnsupportedOperationException
	at com.sun.tools.javac.util.ListBuffer.add(ListBuffer.java:205)
	at
com.sun.tools.javac.util.DefaultFileManager.getClassLoader(DefaultFileManager.java:664)
	at sixexperiment.PEC.attachTo(PEC.java:20)

This is due to ListBuffer.add() not being implemented.

Comments
WORK AROUND Jackpot can fix its own copy of DefaultFileManager, since it doesn't allow the customer to define the FileManager.
10-05-2006

SUGGESTED FIX In ListBuffer, change: public boolean add(A a) { throw new UnsupportedOperationException(); } to: public boolean add(A a) { append(a); return true; } This change adheres to the semantics of java.util.List.add(Object) while probably calling the method which was intended in the code for DefaultFileManager.getClassLoader().
10-05-2006