Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ModifierSet breaks backward compatibility #32

Closed
GoogleCodeExporter opened this issue Jun 3, 2015 · 3 comments
Closed

ModifierSet breaks backward compatibility #32

GoogleCodeExporter opened this issue Jun 3, 2015 · 3 comments

Comments

@GoogleCodeExporter
Copy link

ModifierSet looks like this:

    public static final int PUBLIC = 1;
    public static final int PRIVATE = 2;
    public static final int PROTECTED = 4;
    public static final int STATIC = 8;
    public static final int FINAL = 16;
    public static final int SYNCHRONIZED = 32;
    public static final int VOLATILE = 64;
    public static final int TRANSIENT = 128;
    public static final int NATIVE = 256;
    public static final int ABSTRACT = 1024;
    public static final int STRICTFP = 2048;.

Ordinal of those values was different: public, protected, private...
Also why is suddenly ABSTRACT = 1024 and not 512?

Original issue reported on code.google.com by paul.sz...@gmail.com on 26 Jan 2010 at 7:31

@GoogleCodeExporter
Copy link
Author

The value of the constants from ModifierSet where changed in order to follow the
java.lang.ModifierSet.

This change was asked in Issue 22.

But they are only constants, their values should not affect the runtime if you 
are
referencing the constants. Unless you are persisting these values. Is this your 
problem?

Original comment by jges...@gmail.com on 28 Jan 2010 at 1:48

  • Added labels: Type-Other
  • Removed labels: Type-Defect

@GoogleCodeExporter
Copy link
Author

I've built an abstraction above javaparser and changing ModifireSet ordering 
broke
some of my code. But I've fixed that already so no problem. But anyone 
depending on
int values of your fields might be surprised with version 1.0.8.

One last question: why abstract is not 512?

Beside that great work with Java Parser! Thx once again for this tool.

Original comment by paul.sz...@gmail.com on 28 Jan 2010 at 8:14

@GoogleCodeExporter
Copy link
Author

Ok Paul, I understand your point, sorry about that.

About the abstract modifier, this value is 512 because the abstract modifier in
java.lang.reflect.Modifier is 512 too. This is the reason.

Thank you.

Original comment by jges...@gmail.com on 28 Jan 2010 at 10:41

  • Changed state: WontFix

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant