Externs Configuration Not Preventing Code Obfuscation

[loveslikey]

Description:
I'm encountering an issue with the j2cl-maven-plugin where the externs configuration is not preventing code obfuscation as expected.

Steps to Reproduce:

1. Created an externs.js file in the Java root directory with the following content:

/**
 * @externs
 */
function MButton() {
}

MButton.prototype.getText = function () {
}

2. Configured the j2cl-maven-plugin according to the documentation
3. Built the project using Maven

Current Behavior:
The MButton class and its methods are still being obfuscated in the output, despite being defined in the externs file.

Expected Behavior:
The MButton class and its getText method should be preserved in their original form without obfuscation, as specified in the externs file.

Environment:

• j2cl-maven-plugin version: [please specify your version]
• Java version: [please specify your version]
• Operating System: [please specify your OS]
• Maven version: [please specify your version]

Additional Context:
I'm following the documentation for configuring externs, but the configuration doesn't seem to be taking effect. Are there any additional steps or configuration settings required to properly implement externs?

Configuration Details:
Please share any relevant parts of your Maven configuration if possible:

[Your maven plugin configuration here]

Thank you for your help in resolving this issue.

[niloc132]

Can you provide an example showing this? My very basic understanding is that what you have here isn't going to be enough, assuming MButton is a Java class. At the very least, I think you will need two other pieces:

• Code to actually export the Java/js MButton class to the MButton name in the global namespace
• A jsdoc comment on MButton explicitly marking MButton as a @constructor, not just a function. I'm not sure if this is actually required, but it should be there for completeness.

Java semantics are "respected" in your j2cl-compiled app by not actually loading any classes or running any code when your JS file is loaded by the browser. Even if you explicitly use MButton, the generated .js files from j2cl are closure modules, so something needs to explicitly import and use it from JS. Likely it could be enough to tack on a MButton.native.js that assigns window["MButton"] = MButton - if so, you can probably go further and get a lot of this "for free" in plain Java with @GWT3Export from https://github.com/treblereel/gwt3-processors.

[loveslikey]

@niloc132 thank your reply.

@JsType(name = "MButton")
public class MButton {
    private String text;
    private boolean enabled=true;
    private EventListener clickEventHandler;
    private FrontOperateType operateType=FrontOperateType.Empty;
    private String dialog;
    @JsMethod
    public String getText() {
        return text;
    }
    @JsMethod
    public void setText(String text) {
        this.text = text;
    }

    @JsMethod
    public void setEnabled(boolean enabled) {
        this.enabled = enabled;
    }
    @JsMethod
    public boolean isEnabled() {
        return enabled;
    }
    @JsMethod
    public EventListener getClickEventHandler() {
        return clickEventHandler;
    }
    @JsMethod
    public void addClickEventListener(EventListener value) {
        this.clickEventHandler = value;
    }
    public void removeClickEventListener(EventListener value) {
        this.clickEventHandler = null;
    }
    @JsMethod
    public String getOperateTypeString() {
        return operateType.toString();
    }

    public FrontOperateType getOperateType() {
        return operateType;
    }
    public void setOperateType(FrontOperateType operateType) {
        this.operateType = operateType;
    }
    @JsMethod
    public String getDialog() {
        return dialog;
    }
    public void setDialog(String dialog) {
        this.dialog = dialog;
    }
    public void setFrontOperate(FrontOperateType operateType,String dialog) {
        this.setOperateType(operateType);
        this.setDialog(dialog);
    }

    public enum FrontOperateType {
        Empty,
        OpenDialog,
        CloseDialog
    }
}

goog.module("MButton");
const MButton = goog.require("com.major.acss.ui.component.MButton");
goog.exportSymbol("MButton",MButton);
goog.exportSymbol("MButton.prototype.getText",MButton.prototype.getText);
goog.exportSymbol("MButton.prototype.setText",MButton.prototype.setText);
goog.exportSymbol("MButton.prototype.setEnabled",MButton.prototype.setEnabled);
goog.exportSymbol("MButton.prototype.isEnabled",MButton.prototype.isEnabled);
goog.exportSymbol("MButton.prototype.getClickEventHandler",MButton.prototype.getClickEventHandler);
goog.exportSymbol("MButton.prototype.addClickEventListener",MButton.prototype.addClickEventListener);
goog.exportSymbol("MButton.prototype.getOperateTypeString",MButton.prototype.getOperateTypeString);
goog.exportSymbol("MButton.prototype.getDialog",MButton.prototype.getDialog);

/**
 * @externs
 */

/**
 * @constructor
 */
function MButton() {
}

MButton.prototype.getText = function () {
}

the class is still being obfuscated in the output JavaScript. Here's what I'm seeing in the compiled code:
the output javascript ：

ba.exportSymbol("MButton",J9);
ba.exportSymbol("MButton.prototype.getText",J9.prototype.getText);
ba.exportSymbol("MButton.prototype.setText",J9.prototype.setText);
ba.exportSymbol("MButton.prototype.setEnabled",J9.prototype.setEnabled);
ba.exportSymbol("MButton.prototype.isEnabled",J9.prototype.isEnabled);
ba.exportSymbol("MButton.prototype.getClickEventHandler",J9.prototype.getClickEventHandler);

As you can see, while the exported symbol names are preserved as "MButton", the actual class implementation is still being obfuscated to J9. Is there additional configuration needed to prevent this obfuscation?

[niloc132]

As you can see, while the exported symbol names are preserved as "MButton", the actual class implementation is still being obfuscated to J9. Is there additional configuration needed to prevent this obfuscation?

This is the expected and correct behavior for the code you've written - the Java type name is being obfuscated/optimized, but a reference to it should be now exported to goog.global aka window as MButton, same as if you wrote

window["MButton"] = MButton;

in the .native.js or some other .js file. Now you can access the constructor of the type by its unobfuscated name - but other references in your compile code are minified for better size/performance.

If this isn't what you want, closure-compiler might not be for you - can you explain the concern that this raises, why being usable by name isn't enough?

[loveslikey]

Thank you for your detailed explanation. Let me clarify why I need to prevent the obfuscation of MButton to J9.

Currently, the compiled output looks like this:

ba.exportSymbol("MButton", J9);
ba.exportSymbol("MButton.prototype.getText", J9.prototype.getText);

My goal is to intercept and modify the constructor behavior of MButton when it's called from JavaScript. I want to do this by modifying the prototype chain, like this:

// Solution 1: Save original class and replace
const OriginalMButton = MButton;
// Replace MButton globally with a Proxy
MButton = new Proxy(MButton, {
  construct(target, args) {
    console.log('new construct, return new Object');
    return {
      name: 'Custom Object',
      customProp: 'Some Value'
    };
  }
});

The issue is that I have a large codebase with many Java classes that create MButton instances:

MButton b1 = new MButton();

This gets compiled to:

let b1 = new J9();

Because of this obfuscation, even though I've replaced the MButton constructor's prototype chain, b1 is still an unmodified MButton because it's using the obfuscated name J9.

I know I could work around this in Java by doing something like:

MButton b1 = JsBridge.wrapperObject(new MButton());

However, this would require modifying a large amount of code. I'm looking for a more generic solution that wouldn't require changing every instance creation in the Java code.

Is there a way to prevent the obfuscation of the class name so that all constructor calls (both from Java and JavaScript) go through the same unobfuscated name?

[niloc132]

I think you're going to have a hard time here, by the nature of the closure module system - there is no guarantee that after compilation that you have a single symbol that represents the type you're after. For example, in BUNDLE or another mode, the closure modules are lazily evaluated function wrappers, so getting an "instance of the constructor" is a function call, and new is called on the result of that. Very roughly:

var MButtonModule = memoize(function() {
  return class BMutton {
    constructor() {
      //..
    }
    getText() {
      return "foo";
    }
  };
});
//...
var MyPanelModule = function() {
  var MButton = MButtonModule();
  var BasePanel = BasePanelModule();
  return class MyPanel extends BasePanel {
    constructor() {
      addWidget(new MButton());
      //...
    }
  };
}

Among other things, this lets Java class initialization happen when it is expected with minimal compilation. Added layers of compilation then will do more rewriting, and there is no guarantee that you'll get exactly what you want.

Instead, you might be able to write some JS in MButton.native.js that reassigns the MButton value before it is even exported, so that every other module that imports it already sees the proxy wrapper - the code snippet you have above looks about right for that. Check the generated MButton.java.impl.js to see if you need to adjust some names, etc.

Or, since JS supports some aliasing (and Java doesn't), you could see about making a fake "subclass" of this type that simply wraps and exports the wrap, and be sure to use the subtype everywhere. Can make this easier by making your constructors protected, so that Java won't let you call them.

These approaches may have some problems if you ever subclass your own types though, since Java (and j2cl's own calling conventions) will have certain expectations about how that will work. I am assuming this is a non-issue, since otherwise you wouldn't be able to reassign the type name as your example shows you doing. That said, it does raise one other possibility in my mind: do this as you would do it in Java. That is, provide some DI/factory that offers the types, and in that factory do the proxy wrapping (presumably in plain Java, though it could be in some native JS). That would entirely resolve the subclass issue, and make your code somewhat more transparent, in that every caller naturally will expect to get a proxy, since they asked for it.

@treblereel maybe you have some other thoughts? I know you did some work with js proxies in j2cl...

If you described this use case and the original expected solution on the closure-compiler mailing list, it might be that there is a way, but I'm not aware of it, and I doubt either externs or exports can manage it.