org.codehaus.janino.Mod vs java.lang.reflect.Modifier

[Matt Fowles]

All~

While working with Janino, I noticed that the Mod class replicates the
java builtin class Modifier.  Is there a reason for this duplication?
Would a patch which deprecates or removes Mod in favor of Modifier
being of interest?

Matt

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Arno Unkrig]

Hi Matt,

the reason being is that JANINO does not BUILD UPON reflection: All of
IClass, IMethod, IClassLoader, Mod etc. are independent from reflection,
although they are analogous in many ways.

Then, when you want to use LOADED classes, you use the
ClassLoaderIClassLoader and the ReflectionI* classes which BRIDGE
between JANINO and reflection.

Also, the older JDKs lack some important modifier definitions like
SYNTHETIC (0x1000). Since JANINO brings some Java 5 functionality to
older JREs (back to 1.2.2), it is inevitable to redefine certain
information.

Admittedly, the class name "Mod" was a bad choice; it should rather have
been "IClass.IModifier" in analogy with the other IClass.I* classes. But
that would break existing client code, and there is no good enough
reason to do it. (I'll add a respective notice to the JAVADOC of Mod.)


CU

Arno

Matt Fowles schrieb:

> All~
>
> While working with Janino, I noticed that the Mod class replicates the
> java builtin class Modifier.  Is there a reason for this duplication?
> Would a patch which deprecates or removes Mod in favor of Modifier
> being of interest?
>
> Matt
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Matt Fowles]

Arno~

Thanks for the detailed explanation as to the choice.  A useful
routine to add to the mod class would be:

    /**
     * Convert a {@link java.lang.reflect.Modifier} to a {@link
org.codehaus.janino.Mod}
     * @param mod bit mask of modifiers from {@link java.lang.reflect.Modifier}
     * @return bit mask of modifiers for {@link org.codehaus.janino.Mod}
     */
    public static short convertToJavaModifier(int mod) {
        short res = 0;
        if(Modifier.isAbstract(mod))    { res = Mod.changeAccess(res,
Mod.ABSTRACT);    }
        if(Modifier.isFinal(mod))       { res = Mod.changeAccess(res,
Mod.FINAL);       }
        if(Modifier.isInterface(mod))   { res = Mod.changeAccess(res,
Mod.INTERFACE);   }
        if(Modifier.isNative(mod))      { res = Mod.changeAccess(res,
Mod.NATIVE);      }
        if(Modifier.isPrivate(mod))     { res = Mod.changeAccess(res,
Mod.PRIVATE);     }
        if(Modifier.isProtected(mod))   { res = Mod.changeAccess(res,
Mod.PROTECTED);   }
        if(Modifier.isPublic(mod))      { res = Mod.changeAccess(res,
Mod.PUBLIC);      }
        if(Modifier.isStatic(mod))      { res = Mod.changeAccess(res,
Mod.STATIC);      }
        if(Modifier.isStrict(mod))      { res = Mod.changeAccess(res,
Mod.STRICTFP);    }
        if(Modifier.isSynchronized(mod)){ res = Mod.changeAccess(res,
Mod.SYNCHRONIZED);}
        if(Modifier.isTransient(mod))   { res = Mod.changeAccess(res,
Mod.TRANSIENT);   }
        if(Modifier.isVolatile(mod))    { res = Mod.changeAccess(res,
Mod.VOLATILE);    }
        return res;
    }

possibly the other direction is useful too, but I have not needed it yet.

Matt


On Mon, Apr 28, 2008 at 3:46 PM, Arno Unkrig <arno@...> wrote:

> Hi Matt,
>
>  the reason being is that JANINO does not BUILD UPON reflection: All of
> IClass, IMethod, IClassLoader, Mod etc. are independent from reflection,
> although they are analogous in many ways.
>
>  Then, when you want to use LOADED classes, you use the
> ClassLoaderIClassLoader and the ReflectionI* classes which BRIDGE between
> JANINO and reflection.
>
>  Also, the older JDKs lack some important modifier definitions like
> SYNTHETIC (0x1000). Since JANINO brings some Java 5 functionality to older
> JREs (back to 1.2.2), it is inevitable to redefine certain information.
>
>  Admittedly, the class name "Mod" was a bad choice; it should rather have
> been "IClass.IModifier" in analogy with the other IClass.I* classes. But
> that would break existing client code, and there is no good enough reason to
> do it. (I'll add a respective notice to the JAVADOC of Mod.)
>
>
>  CU
>
>  Arno
>
>  Matt Fowles schrieb:
>
> >
> >
> >
> > All~
> >
> > While working with Janino, I noticed that the Mod class replicates the
> > java builtin class Modifier.  Is there a reason for this duplication?
> > Would a patch which deprecates or removes Mod in favor of Modifier
> > being of interest?
> >
> > Matt
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list, please visit:
> >
> >    http://xircles.codehaus.org/manage_email
> >
> >
> >
> >
> >
>
>
>  ---------------------------------------------------------------------
>  To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email