leylon / javaparser

Automatically exported from code.google.com/p/javaparser
0 stars 0 forks source link

ModifierSet breaks backward compatibility #32

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
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 commented 8 years ago
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

GoogleCodeExporter commented 8 years ago
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 commented 8 years ago
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