Mojo
  1. Mojo
  2. MOJO-1458

Fix non-forked APT invocation to not hack system class loader

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: apt
    • Labels:
      None
    • Complexity:
      Intermediate
    • Number of attachments :
      0

      Description

      Hacking the system class loader like currently in AptUtils is bad:

      Method method = URLClassLoader.class.getDeclaredMethod( "addURL", new Class[] { URL.class } );
      method.setAccessible( true );
      method.invoke( ClassLoader.getSystemClassLoader(), new Object[] { toolsJar.toURL() } );
      

      In particular, this won't work with the class loader boundaries in Maven 3.x. See also TOBAGO-256 for a related issue.

      Instead of hacking other people's class loaders, the plugin should create its own class loader.

        Issue Links

          Activity

          Hide
          Benjamin Bentmann added a comment -

          Fixed in r11286.

          Show
          Benjamin Bentmann added a comment - Fixed in r11286 .
          Hide
          Jon Osborn added a comment -

          Hmmm...seems to be ok. But what about using jrockit? They have some classes that have to load from this tools.jar also. the usage of name.startsWith() would seem to exclude packages other than com.sun. True?

          Show
          Jon Osborn added a comment - Hmmm...seems to be ok. But what about using jrockit? They have some classes that have to load from this tools.jar also. the usage of name.startsWith() would seem to exclude packages other than com.sun. True?
          Hide
          Benjamin Bentmann added a comment -

          I don't have access to JRockit but the code works also for IBM's JDKs. At least the main class loaded by the plugin must be in the com.sun.* packages and if JRockit really delegates the class loading related work to classes in other packages, well, have somebody fill an issue and we tune plugin. Nothing is perfect, but hacking the system (or any other) class loader like before is a no-no.

          Show
          Benjamin Bentmann added a comment - I don't have access to JRockit but the code works also for IBM's JDKs. At least the main class loaded by the plugin must be in the com.sun.* packages and if JRockit really delegates the class loading related work to classes in other packages, well, have somebody fill an issue and we tune plugin. Nothing is perfect, but hacking the system (or any other) class loader like before is a no-no.

            People

            • Assignee:
              Benjamin Bentmann
              Reporter:
              Benjamin Bentmann
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: