Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [transformer-dev] Question about package rename scope

Thank you, BJ, for your prompt response!

I think I understand what's going on. I have integrated the transformer into our org.eclipse.osgi.internal.hookregistry.ClassLoaderHook subclass, by implementing:

public byte[] processClass(String name, byte[] classbytes, ClasspathEntry classpathEntry, BundleEntry entry, ClasspathManager manager)

to call into the transformer and return the possibly transformed classbytes.

This works great for any class that is not getting renamed as part of the transformation, but if the class itself is subject to renaming, I run into an issue because the class name passed to ClassLoader.loadClass (e.g., javax/servlet/ServletException) no longer matches the renamed class (jakarta/servlet/ServletException), resulting in this error:

Caused by: java.lang.NoClassDefFoundError: jakarta/servlet/ServletException (wrong name: javax/servlet/ServletException)
        at java.base/java.lang.ClassLoader.defineClass1(Native Method)
        at java.base/java.lang.ClassLoader.defineClass(
        at org.eclipse.osgi.internal.loader.ModuleClassLoader.defineClass(
        at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.defineClass(
        at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findClassImpl(
        at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findLocalClassImpl(
        at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findLocalClassImpl(
        at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findLocalClass(
        at org.eclipse.osgi.internal.loader.ModuleClassLoader.findLocalClass(
        at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(
        at org.eclipse.osgi.internal.loader.BundleLoader.findClass0(
        at org.eclipse.osgi.internal.loader.BundleLoader.findClass(
        at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(
        at java.base/java.lang.ClassLoader.loadClass(

Do you have any suggestion for how to make this scenario work as well? 


On Thursday, April 11, 2024 at 03:35:02 PM GMT+2, BJ Hargrave via transformer-dev <transformer-dev@xxxxxxxxxxx> wrote:

Transformer does not need the old or new packages on the classpath to transform. It uses the information in the transformation rules to determine the mapping from old package names to new package names and processes the class files in the artifact being transformed. This is primarily done by mutating the constant pool in the class file to use the new names instead of the old names.



BJ Hargrave
Senior Technical Staff Member, IBM // office: +1 386 848 1781
Open Source Development // mobile: +1 386 848 3788




From: transformer-dev <transformer-dev-bounces@xxxxxxxxxxx> on behalf of jan luehe via transformer-dev <transformer-dev@xxxxxxxxxxx>
Date: Thursday, April 11, 2024 at 06:25
To: transformer-dev@xxxxxxxxxxx <transformer-dev@xxxxxxxxxxx>
Cc: jan luehe <janluehe@xxxxxxxxx>
Subject: [EXTERNAL] [transformer-dev] Question about package rename scope

Is my assumption correct that in order for the transformer to be able to apply the package rename rules at,


This Message Is From an External Sender

This message came from outside your organization.



Is my assumption correct that in order for the transformer to be able to apply the package rename rules at, the target packages of the renames ("newPackageName", e.g., jakarta.servlet), must already exist on the class path of the hosting app, so that the renamed references can be correctly resolved? 


For example, if the hosting app still has jakarta.servlet-api-4.0.4.jar (which provides the "old" javax.servlet) on its class path, then the rename rule from javax.servlet to jakarta.servlet will fail. 


In other words, only class references to "currentPackageName" will be renamed (e.g, "Foo implements javax.servlet.Servlet"), but not the class definitions themselves ("package javax.servlet; public interface Servlet { ... }").


Could you please confirm? Thank you!

transformer-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top