Java 15 support?

[marciox25]

Is this in the making or you guys wont support it?
Also, Im using it on java 8 and it works great. But I wonder if there is a way we can set a renaming mask.
Because what I have noticed, it is pretty easy to "remake" the code. Sometimes it doesnt even use the same renaming convention for 2 different variables. Eg, we have an "int value", and an "double valueD".
Both of those could be changed to "int a" and "double a". but it instead changes to "double b".

Am I doing something wrong?

        <inoutpair in="${temp.jar.no.obfs}/protocolsNoCrypt.jar" out="${temp.jar.obfs}/protocols.jar"/>
        <rename replaceClassNameStrings="true">
            <keep>
                <class classes="none"
                       methods="none"
                       fields="none">
                    <patternset>
                        <include name="r.*"/>
                    </patternset>
                </class>
            </keep>
            <adjust replaceName="true" replaceContent="true">
                <include name="r/*"/>
            </adjust>
        </rename>
    </yguard>
    
    
    
    Ive also seen the following setting:
    
   <property name="obfuscation-prefix" value="x"/>
    
    But how do I use it properly?

[Sebastian Müller]

Regarding the "naming convention for variables" - there is none; variables don't have names in .class files. This information is not part of the bytecode unless you add debug information. What you are seeing are the names generated by your decompiler. If you want to see different names, change the decompiler.

If you think I am wrong, please provide more details as to what names you are referring, ideally with a snippet of bytecode and disassembly.

[marciox25]

Regarding the "naming convention for variables" - there is none; variables don't have names in .class files. This information is not part of the bytecode unless you add debug information. What you are seeing are the names generated by your decompiler. If you want to see different names, change the decompiler.

If you think I am wrong, please provide more details as to what names you are referring, ideally with a snippet of bytecode and disassembly.

I think I mean properties.
On other obfuscators, we can provide a String prefix so the obfuscator uses for obfuscating methodnames, class names and even properties for example in the class

public class test {
int test;
double test2;
}

for the properties test and test2, here, sometimes they get changed to the letter "a" for both, but sometimes one gets "a" and other gets "b". Is there somehow a way to force it to give the same name where possible?

[Lennard Berger]

In descending order of importance the items that probably need adjustments to be able to support Java 15:

• Records
• Sealed Classes
• Text Blocks

As of now I am not aware of any plans to support Java 15 in the near future. Frankly there are few people who use Java 15 in production yet, even fewer of them are yWorks customers. Support for Java 15 via a pull request or as a sponsored feature by another organization could push this up the agenda.
As for the obfuscation mask please open a dedicated issue: provide a verbose description of your problem, potentially including byte code so we can look into your issue.

All the best

[Sebastian Müller]

@marciox25

for the properties test and test2, here, sometimes they get changed to the letter "a" for both, but sometimes one gets "a" and other gets "b". Is there somehow a way to force it to give the same name where possible?

(Just so that we are on the same level (and with yGuard we are talking java bytecode so we should really use the right names to avoid confusion): these are not "properties" but "class fields".)

Unless you specify the mapping manually, no, there is currently no way of forcing this.
Could you please explain:

• What would be the benefits of doing so?
• How would you like to see this implemented from a user's perspective? (what should the configuration look like)

[Lennard Berger]

#108 supsersedes this.