[jira] [Created] (LANG-816) introduce ConstantUtils class to prevent Javac from inlining constants

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

[jira] [Created] (LANG-816) introduce ConstantUtils class to prevent Javac from inlining constants

ASF GitHub Bot (Jira)
Julius Davies created LANG-816:
----------------------------------

             Summary: introduce ConstantUtils class to prevent Javac from inlining constants
                 Key: LANG-816
                 URL: https://issues.apache.org/jira/browse/LANG-816
             Project: Commons Lang
          Issue Type: Wish
            Reporter: Julius Davies
            Priority: Trivial


ConstantUtils currently contains a set of methods to ensure constants are not inlined by javac.
 
For example, typically a developer might declare a constant like

  public final static int MAGIC_NUMBER = 5;

Should a different jar file refer to this, and the MAGIC_NUMBER is changed a later date (e.g., MAGIC_NUMBER = 6), the different jar file will need to recompile itself.  This is because javac typically inlines the primitive or String constant directly into the bytecode, and removes the reference to the MAGIC_NUMBER field.

To help the other jar (so that it does not need to recompile when constants are changed) the original developer can declare their constant using one of the CONST() utility methods, instead:

  public final static int MAGIC_NUMBER = CONST(5);

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

       
Reply | Threaded
Open this post in threaded view
|

[jira] [Updated] (LANG-816) introduce ConstantUtils class to prevent Javac from inlining constants

ASF GitHub Bot (Jira)

     [ https://issues.apache.org/jira/browse/LANG-816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Julius Davies updated LANG-816:
-------------------------------

    Description:
ConstantUtils currently contains a set of methods to ensure constants are not inlined by javac.
 
For example, typically a developer might declare a constant like
{code}
  public final static int MAGIC_NUMBER = 5;
{code}
Should a different jar file refer to this, and the MAGIC_NUMBER is changed a later date (e.g., MAGIC_NUMBER = 6), the different jar file will need to recompile itself.  This is because javac typically inlines the primitive or String constant directly into the bytecode, and removes the reference to the MAGIC_NUMBER field.

To help the other jar (so that it does not need to recompile when constants are changed) the original developer can declare their constant using one of the CONST() utility methods, instead:
{code}
  public final static int MAGIC_NUMBER = CONST(5);
{code}


I imagine the code would look something like this:

{code}
    public static boolean CONST(boolean v) { return v; }
    public static byte CONST(byte v) { return v; }
    public static char CONST(char v) { return v; }
    public static short CONST(short v) { return v; }
    public static int CONST(int v) { return v; }
    public static long CONST(long v) { return v; }
    public static float CONST(float v) { return v; }
    public static double CONST(double v) { return v; }
    public static <T> T CONST(T t) { return t; }
{code}

  was:
ConstantUtils currently contains a set of methods to ensure constants are not inlined by javac.
 
For example, typically a developer might declare a constant like

  public final static int MAGIC_NUMBER = 5;

Should a different jar file refer to this, and the MAGIC_NUMBER is changed a later date (e.g., MAGIC_NUMBER = 6), the different jar file will need to recompile itself.  This is because javac typically inlines the primitive or String constant directly into the bytecode, and removes the reference to the MAGIC_NUMBER field.

To help the other jar (so that it does not need to recompile when constants are changed) the original developer can declare their constant using one of the CONST() utility methods, instead:

  public final static int MAGIC_NUMBER = CONST(5);

   

> introduce ConstantUtils class to prevent Javac from inlining constants
> ----------------------------------------------------------------------
>
>                 Key: LANG-816
>                 URL: https://issues.apache.org/jira/browse/LANG-816
>             Project: Commons Lang
>          Issue Type: Wish
>            Reporter: Julius Davies
>            Priority: Trivial
>
> ConstantUtils currently contains a set of methods to ensure constants are not inlined by javac.
>  
> For example, typically a developer might declare a constant like
> {code}
>   public final static int MAGIC_NUMBER = 5;
> {code}
> Should a different jar file refer to this, and the MAGIC_NUMBER is changed a later date (e.g., MAGIC_NUMBER = 6), the different jar file will need to recompile itself.  This is because javac typically inlines the primitive or String constant directly into the bytecode, and removes the reference to the MAGIC_NUMBER field.
> To help the other jar (so that it does not need to recompile when constants are changed) the original developer can declare their constant using one of the CONST() utility methods, instead:
> {code}
>   public final static int MAGIC_NUMBER = CONST(5);
> {code}
> I imagine the code would look something like this:
> {code}
>     public static boolean CONST(boolean v) { return v; }
>     public static byte CONST(byte v) { return v; }
>     public static char CONST(char v) { return v; }
>     public static short CONST(short v) { return v; }
>     public static int CONST(int v) { return v; }
>     public static long CONST(long v) { return v; }
>     public static float CONST(float v) { return v; }
>     public static double CONST(double v) { return v; }
>     public static <T> T CONST(T t) { return t; }
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

       
Reply | Threaded
Open this post in threaded view
|

[jira] [Updated] (LANG-816) introduce ConstantUtils class to prevent Javac from inlining constants

ASF GitHub Bot (Jira)
In reply to this post by ASF GitHub Bot (Jira)

     [ https://issues.apache.org/jira/browse/LANG-816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Julius Davies updated LANG-816:
-------------------------------

    Description:
ConstantUtils currently contains a set of methods to ensure constants are not inlined by javac.
 
For example, typically a developer might declare a constant like
{code}
  public final static int MAGIC_NUMBER = 5;
{code}
Should a different jar file refer to this, and the MAGIC_NUMBER is changed a later date (e.g., MAGIC_NUMBER = 6), the different jar file will need to recompile itself.  This is because javac typically inlines the primitive or String constant directly into the bytecode, and removes the reference to the MAGIC_NUMBER field.

To help the other jar (so that it does not need to recompile when constants are changed) the original developer can declare their constant using one of the CONST() utility methods, instead:
{code}
  public final static int MAGIC_NUMBER = CONST(5);
{code}


I imagine the code would look something like this:

{code}
public static boolean CONST(boolean v) { return v; }
public static byte CONST(byte v) { return v; }
public static char CONST(char v) { return v; }
public static short CONST(short v) { return v; }
public static int CONST(int v) { return v; }
public static long CONST(long v) { return v; }
public static float CONST(float v) { return v; }
public static double CONST(double v) { return v; }
public static <T> T CONST(T t) { return t; }
{code}

  was:
ConstantUtils currently contains a set of methods to ensure constants are not inlined by javac.
 
For example, typically a developer might declare a constant like
{code}
  public final static int MAGIC_NUMBER = 5;
{code}
Should a different jar file refer to this, and the MAGIC_NUMBER is changed a later date (e.g., MAGIC_NUMBER = 6), the different jar file will need to recompile itself.  This is because javac typically inlines the primitive or String constant directly into the bytecode, and removes the reference to the MAGIC_NUMBER field.

To help the other jar (so that it does not need to recompile when constants are changed) the original developer can declare their constant using one of the CONST() utility methods, instead:
{code}
  public final static int MAGIC_NUMBER = CONST(5);
{code}


I imagine the code would look something like this:

{code}
    public static boolean CONST(boolean v) { return v; }
    public static byte CONST(byte v) { return v; }
    public static char CONST(char v) { return v; }
    public static short CONST(short v) { return v; }
    public static int CONST(int v) { return v; }
    public static long CONST(long v) { return v; }
    public static float CONST(float v) { return v; }
    public static double CONST(double v) { return v; }
    public static <T> T CONST(T t) { return t; }
{code}

   

> introduce ConstantUtils class to prevent Javac from inlining constants
> ----------------------------------------------------------------------
>
>                 Key: LANG-816
>                 URL: https://issues.apache.org/jira/browse/LANG-816
>             Project: Commons Lang
>          Issue Type: Wish
>            Reporter: Julius Davies
>            Priority: Trivial
>
> ConstantUtils currently contains a set of methods to ensure constants are not inlined by javac.
>  
> For example, typically a developer might declare a constant like
> {code}
>   public final static int MAGIC_NUMBER = 5;
> {code}
> Should a different jar file refer to this, and the MAGIC_NUMBER is changed a later date (e.g., MAGIC_NUMBER = 6), the different jar file will need to recompile itself.  This is because javac typically inlines the primitive or String constant directly into the bytecode, and removes the reference to the MAGIC_NUMBER field.
> To help the other jar (so that it does not need to recompile when constants are changed) the original developer can declare their constant using one of the CONST() utility methods, instead:
> {code}
>   public final static int MAGIC_NUMBER = CONST(5);
> {code}
> I imagine the code would look something like this:
> {code}
> public static boolean CONST(boolean v) { return v; }
> public static byte CONST(byte v) { return v; }
> public static char CONST(char v) { return v; }
> public static short CONST(short v) { return v; }
> public static int CONST(int v) { return v; }
> public static long CONST(long v) { return v; }
> public static float CONST(float v) { return v; }
> public static double CONST(double v) { return v; }
> public static <T> T CONST(T t) { return t; }
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

       
Reply | Threaded
Open this post in threaded view
|

[jira] [Updated] (LANG-816) introduce ConstantUtils class to prevent Javac from inlining constants

ASF GitHub Bot (Jira)
In reply to this post by ASF GitHub Bot (Jira)

     [ https://issues.apache.org/jira/browse/LANG-816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Julius Davies updated LANG-816:
-------------------------------

    Description:
ConstantUtils could contain a set of methods to ensure constants are not inlined by javac.
 
For example, typically a developer might declare a constant like
{code}
  public final static int MAGIC_NUMBER = 5;
{code}
Should a different jar file refer to this, and the MAGIC_NUMBER is changed a later date (e.g., MAGIC_NUMBER = 6), the different jar file will need to recompile itself.  This is because javac typically inlines the primitive or String constant directly into the bytecode, and removes the reference to the MAGIC_NUMBER field.

To help the other jar (so that it does not need to recompile when constants are changed) the original developer can declare their constant using one of the CONST() utility methods, instead:
{code}
  public final static int MAGIC_NUMBER = CONST(5);
{code}


I imagine the code would look something like this:

{code}
public static boolean CONST(boolean v) { return v; }
public static byte CONST(byte v) { return v; }
public static char CONST(char v) { return v; }
public static short CONST(short v) { return v; }
public static int CONST(int v) { return v; }
public static long CONST(long v) { return v; }
public static float CONST(float v) { return v; }
public static double CONST(double v) { return v; }
public static <T> T CONST(T t) { return t; }
{code}

  was:
ConstantUtils currently contains a set of methods to ensure constants are not inlined by javac.
 
For example, typically a developer might declare a constant like
{code}
  public final static int MAGIC_NUMBER = 5;
{code}
Should a different jar file refer to this, and the MAGIC_NUMBER is changed a later date (e.g., MAGIC_NUMBER = 6), the different jar file will need to recompile itself.  This is because javac typically inlines the primitive or String constant directly into the bytecode, and removes the reference to the MAGIC_NUMBER field.

To help the other jar (so that it does not need to recompile when constants are changed) the original developer can declare their constant using one of the CONST() utility methods, instead:
{code}
  public final static int MAGIC_NUMBER = CONST(5);
{code}


I imagine the code would look something like this:

{code}
public static boolean CONST(boolean v) { return v; }
public static byte CONST(byte v) { return v; }
public static char CONST(char v) { return v; }
public static short CONST(short v) { return v; }
public static int CONST(int v) { return v; }
public static long CONST(long v) { return v; }
public static float CONST(float v) { return v; }
public static double CONST(double v) { return v; }
public static <T> T CONST(T t) { return t; }
{code}

   

> introduce ConstantUtils class to prevent Javac from inlining constants
> ----------------------------------------------------------------------
>
>                 Key: LANG-816
>                 URL: https://issues.apache.org/jira/browse/LANG-816
>             Project: Commons Lang
>          Issue Type: Wish
>            Reporter: Julius Davies
>            Priority: Trivial
>
> ConstantUtils could contain a set of methods to ensure constants are not inlined by javac.
>  
> For example, typically a developer might declare a constant like
> {code}
>   public final static int MAGIC_NUMBER = 5;
> {code}
> Should a different jar file refer to this, and the MAGIC_NUMBER is changed a later date (e.g., MAGIC_NUMBER = 6), the different jar file will need to recompile itself.  This is because javac typically inlines the primitive or String constant directly into the bytecode, and removes the reference to the MAGIC_NUMBER field.
> To help the other jar (so that it does not need to recompile when constants are changed) the original developer can declare their constant using one of the CONST() utility methods, instead:
> {code}
>   public final static int MAGIC_NUMBER = CONST(5);
> {code}
> I imagine the code would look something like this:
> {code}
> public static boolean CONST(boolean v) { return v; }
> public static byte CONST(byte v) { return v; }
> public static char CONST(char v) { return v; }
> public static short CONST(short v) { return v; }
> public static int CONST(int v) { return v; }
> public static long CONST(long v) { return v; }
> public static float CONST(float v) { return v; }
> public static double CONST(double v) { return v; }
> public static <T> T CONST(T t) { return t; }
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

       
Reply | Threaded
Open this post in threaded view
|

[jira] [Updated] (LANG-816) introduce ConstantUtils class to prevent Javac from inlining constants

ASF GitHub Bot (Jira)
In reply to this post by ASF GitHub Bot (Jira)

     [ https://issues.apache.org/jira/browse/LANG-816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Julius Davies updated LANG-816:
-------------------------------

    Description:
ConstantUtils could contain a set of methods to ensure constants are not inlined by javac.
 
For example, typically a developer might declare a constant like
{code}
  public final static int MAGIC_NUMBER = 5;
{code}
Should a different jar file refer to this, and the MAGIC_NUMBER is changed a later date (e.g., MAGIC_NUMBER = 6), the different jar file will need to be recompiled.  This is because javac typically inlines the primitive or String constant directly into the bytecode, and removes the reference to the MAGIC_NUMBER field.

To help the other jar (so that it does not need to recompile when constants are changed) the original developer can declare their constant using one of the CONST() utility methods, instead:
{code}
  public final static int MAGIC_NUMBER = CONST(5);
{code}


I imagine the code would look something like this:

{code}
public static boolean CONST(boolean v) { return v; }
public static byte CONST(byte v) { return v; }
public static char CONST(char v) { return v; }
public static short CONST(short v) { return v; }
public static int CONST(int v) { return v; }
public static long CONST(long v) { return v; }
public static float CONST(float v) { return v; }
public static double CONST(double v) { return v; }
public static <T> T CONST(T t) { return t; }
{code}

  was:
ConstantUtils could contain a set of methods to ensure constants are not inlined by javac.
 
For example, typically a developer might declare a constant like
{code}
  public final static int MAGIC_NUMBER = 5;
{code}
Should a different jar file refer to this, and the MAGIC_NUMBER is changed a later date (e.g., MAGIC_NUMBER = 6), the different jar file will need to recompile itself.  This is because javac typically inlines the primitive or String constant directly into the bytecode, and removes the reference to the MAGIC_NUMBER field.

To help the other jar (so that it does not need to recompile when constants are changed) the original developer can declare their constant using one of the CONST() utility methods, instead:
{code}
  public final static int MAGIC_NUMBER = CONST(5);
{code}


I imagine the code would look something like this:

{code}
public static boolean CONST(boolean v) { return v; }
public static byte CONST(byte v) { return v; }
public static char CONST(char v) { return v; }
public static short CONST(short v) { return v; }
public static int CONST(int v) { return v; }
public static long CONST(long v) { return v; }
public static float CONST(float v) { return v; }
public static double CONST(double v) { return v; }
public static <T> T CONST(T t) { return t; }
{code}

   

> introduce ConstantUtils class to prevent Javac from inlining constants
> ----------------------------------------------------------------------
>
>                 Key: LANG-816
>                 URL: https://issues.apache.org/jira/browse/LANG-816
>             Project: Commons Lang
>          Issue Type: Wish
>            Reporter: Julius Davies
>            Priority: Trivial
>
> ConstantUtils could contain a set of methods to ensure constants are not inlined by javac.
>  
> For example, typically a developer might declare a constant like
> {code}
>   public final static int MAGIC_NUMBER = 5;
> {code}
> Should a different jar file refer to this, and the MAGIC_NUMBER is changed a later date (e.g., MAGIC_NUMBER = 6), the different jar file will need to be recompiled.  This is because javac typically inlines the primitive or String constant directly into the bytecode, and removes the reference to the MAGIC_NUMBER field.
> To help the other jar (so that it does not need to recompile when constants are changed) the original developer can declare their constant using one of the CONST() utility methods, instead:
> {code}
>   public final static int MAGIC_NUMBER = CONST(5);
> {code}
> I imagine the code would look something like this:
> {code}
> public static boolean CONST(boolean v) { return v; }
> public static byte CONST(byte v) { return v; }
> public static char CONST(char v) { return v; }
> public static short CONST(short v) { return v; }
> public static int CONST(int v) { return v; }
> public static long CONST(long v) { return v; }
> public static float CONST(float v) { return v; }
> public static double CONST(double v) { return v; }
> public static <T> T CONST(T t) { return t; }
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

       
Reply | Threaded
Open this post in threaded view
|

[jira] [Commented] (LANG-816) introduce ConstantUtils class to prevent Javac from inlining constants

ASF GitHub Bot (Jira)
In reply to this post by ASF GitHub Bot (Jira)

    [ https://issues.apache.org/jira/browse/LANG-816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13440012#comment-13440012 ]

Sebb commented on LANG-816:
---------------------------

I like this idea.

JMeter had the same problem with its Version class which contains constants for the version and SVN revision.
The solution we adopted was to make the constants private and add getters for the constants.

I suspect the CONST solution may be marginally more efficient as the method is only evaluated once when the class is instantiated. [In the case of the JMeter getter, the JVM will probably inline the method.]
               

> introduce ConstantUtils class to prevent Javac from inlining constants
> ----------------------------------------------------------------------
>
>                 Key: LANG-816
>                 URL: https://issues.apache.org/jira/browse/LANG-816
>             Project: Commons Lang
>          Issue Type: Wish
>            Reporter: Julius Davies
>            Priority: Trivial
>
> ConstantUtils could contain a set of methods to ensure constants are not inlined by javac.
>  
> For example, typically a developer might declare a constant like
> {code}
>   public final static int MAGIC_NUMBER = 5;
> {code}
> Should a different jar file refer to this, and the MAGIC_NUMBER is changed a later date (e.g., MAGIC_NUMBER = 6), the different jar file will need to be recompiled.  This is because javac typically inlines the primitive or String constant directly into the bytecode, and removes the reference to the MAGIC_NUMBER field.
> To help the other jar (so that it does not need to recompile when constants are changed) the original developer can declare their constant using one of the CONST() utility methods, instead:
> {code}
>   public final static int MAGIC_NUMBER = CONST(5);
> {code}
> I imagine the code would look something like this:
> {code}
> public static boolean CONST(boolean v) { return v; }
> public static byte CONST(byte v) { return v; }
> public static char CONST(char v) { return v; }
> public static short CONST(short v) { return v; }
> public static int CONST(int v) { return v; }
> public static long CONST(long v) { return v; }
> public static float CONST(float v) { return v; }
> public static double CONST(double v) { return v; }
> public static <T> T CONST(T t) { return t; }
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

       
Reply | Threaded
Open this post in threaded view
|

[jira] [Commented] (LANG-816) introduce ConstantUtils class to prevent Javac from inlining constants

ASF GitHub Bot (Jira)
In reply to this post by ASF GitHub Bot (Jira)

    [ https://issues.apache.org/jira/browse/LANG-816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13440102#comment-13440102 ]

Stephen Colebourne commented on LANG-816:
-----------------------------------------

I'd suggest adding this to ObjectUtils if it gets done.
               

> introduce ConstantUtils class to prevent Javac from inlining constants
> ----------------------------------------------------------------------
>
>                 Key: LANG-816
>                 URL: https://issues.apache.org/jira/browse/LANG-816
>             Project: Commons Lang
>          Issue Type: Wish
>            Reporter: Julius Davies
>            Priority: Trivial
>
> ConstantUtils could contain a set of methods to ensure constants are not inlined by javac.
>  
> For example, typically a developer might declare a constant like
> {code}
>   public final static int MAGIC_NUMBER = 5;
> {code}
> Should a different jar file refer to this, and the MAGIC_NUMBER is changed a later date (e.g., MAGIC_NUMBER = 6), the different jar file will need to be recompiled.  This is because javac typically inlines the primitive or String constant directly into the bytecode, and removes the reference to the MAGIC_NUMBER field.
> To help the other jar (so that it does not need to recompile when constants are changed) the original developer can declare their constant using one of the CONST() utility methods, instead:
> {code}
>   public final static int MAGIC_NUMBER = CONST(5);
> {code}
> I imagine the code would look something like this:
> {code}
> public static boolean CONST(boolean v) { return v; }
> public static byte CONST(byte v) { return v; }
> public static char CONST(char v) { return v; }
> public static short CONST(short v) { return v; }
> public static int CONST(int v) { return v; }
> public static long CONST(long v) { return v; }
> public static float CONST(float v) { return v; }
> public static double CONST(double v) { return v; }
> public static <T> T CONST(T t) { return t; }
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

       
Reply | Threaded
Open this post in threaded view
|

[jira] [Updated] (LANG-816) Introduce CONST() methods to prevent Javac from inlining constants

ASF GitHub Bot (Jira)
In reply to this post by ASF GitHub Bot (Jira)

     [ https://issues.apache.org/jira/browse/LANG-816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Julius Davies updated LANG-816:
-------------------------------

      Component/s: lang.*
         Due Date: 23/Aug/12
    Fix Version/s: 3.2
         Assignee: Julius Davies
          Summary: Introduce CONST() methods to prevent Javac from inlining constants  (was: introduce ConstantUtils class to prevent Javac from inlining constants)
   

> Introduce CONST() methods to prevent Javac from inlining constants
> ------------------------------------------------------------------
>
>                 Key: LANG-816
>                 URL: https://issues.apache.org/jira/browse/LANG-816
>             Project: Commons Lang
>          Issue Type: Wish
>          Components: lang.*
>            Reporter: Julius Davies
>            Assignee: Julius Davies
>            Priority: Trivial
>             Fix For: 3.2
>
>
> ConstantUtils could contain a set of methods to ensure constants are not inlined by javac.
>  
> For example, typically a developer might declare a constant like
> {code}
>   public final static int MAGIC_NUMBER = 5;
> {code}
> Should a different jar file refer to this, and the MAGIC_NUMBER is changed a later date (e.g., MAGIC_NUMBER = 6), the different jar file will need to be recompiled.  This is because javac typically inlines the primitive or String constant directly into the bytecode, and removes the reference to the MAGIC_NUMBER field.
> To help the other jar (so that it does not need to recompile when constants are changed) the original developer can declare their constant using one of the CONST() utility methods, instead:
> {code}
>   public final static int MAGIC_NUMBER = CONST(5);
> {code}
> I imagine the code would look something like this:
> {code}
> public static boolean CONST(boolean v) { return v; }
> public static byte CONST(byte v) { return v; }
> public static char CONST(char v) { return v; }
> public static short CONST(short v) { return v; }
> public static int CONST(int v) { return v; }
> public static long CONST(long v) { return v; }
> public static float CONST(float v) { return v; }
> public static double CONST(double v) { return v; }
> public static <T> T CONST(T t) { return t; }
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

       
Reply | Threaded
Open this post in threaded view
|

[jira] [Resolved] (LANG-816) Introduce CONST() methods to prevent Javac from inlining constants

ASF GitHub Bot (Jira)
In reply to this post by ASF GitHub Bot (Jira)

     [ https://issues.apache.org/jira/browse/LANG-816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Julius Davies resolved LANG-816.
--------------------------------

    Resolution: Fixed

Committed.  Revision 1376505.

http://svn.apache.org/viewvc?view=revision&revision=1376505
               

> Introduce CONST() methods to prevent Javac from inlining constants
> ------------------------------------------------------------------
>
>                 Key: LANG-816
>                 URL: https://issues.apache.org/jira/browse/LANG-816
>             Project: Commons Lang
>          Issue Type: Wish
>          Components: lang.*
>            Reporter: Julius Davies
>            Assignee: Julius Davies
>            Priority: Trivial
>             Fix For: 3.2
>
>
> ConstantUtils could contain a set of methods to ensure constants are not inlined by javac.
>  
> For example, typically a developer might declare a constant like
> {code}
>   public final static int MAGIC_NUMBER = 5;
> {code}
> Should a different jar file refer to this, and the MAGIC_NUMBER is changed a later date (e.g., MAGIC_NUMBER = 6), the different jar file will need to be recompiled.  This is because javac typically inlines the primitive or String constant directly into the bytecode, and removes the reference to the MAGIC_NUMBER field.
> To help the other jar (so that it does not need to recompile when constants are changed) the original developer can declare their constant using one of the CONST() utility methods, instead:
> {code}
>   public final static int MAGIC_NUMBER = CONST(5);
> {code}
> I imagine the code would look something like this:
> {code}
> public static boolean CONST(boolean v) { return v; }
> public static byte CONST(byte v) { return v; }
> public static char CONST(char v) { return v; }
> public static short CONST(short v) { return v; }
> public static int CONST(int v) { return v; }
> public static long CONST(long v) { return v; }
> public static float CONST(float v) { return v; }
> public static double CONST(double v) { return v; }
> public static <T> T CONST(T t) { return t; }
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

       
Reply | Threaded
Open this post in threaded view
|

[jira] [Commented] (LANG-816) Introduce CONST() methods to prevent Javac from inlining constants

ASF GitHub Bot (Jira)
In reply to this post by ASF GitHub Bot (Jira)

    [ https://issues.apache.org/jira/browse/LANG-816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13440968#comment-13440968 ]

Julius Davies commented on LANG-816:
------------------------------------

Additional improvements thanks to ggregory's tip committed in r1376829.

http://svn.apache.org/viewvc?view=revision&revision=1376829
               

> Introduce CONST() methods to prevent Javac from inlining constants
> ------------------------------------------------------------------
>
>                 Key: LANG-816
>                 URL: https://issues.apache.org/jira/browse/LANG-816
>             Project: Commons Lang
>          Issue Type: Wish
>          Components: lang.*
>            Reporter: Julius Davies
>            Assignee: Julius Davies
>            Priority: Trivial
>             Fix For: 3.2
>
>
> ConstantUtils could contain a set of methods to ensure constants are not inlined by javac.
>  
> For example, typically a developer might declare a constant like
> {code}
>   public final static int MAGIC_NUMBER = 5;
> {code}
> Should a different jar file refer to this, and the MAGIC_NUMBER is changed a later date (e.g., MAGIC_NUMBER = 6), the different jar file will need to be recompiled.  This is because javac typically inlines the primitive or String constant directly into the bytecode, and removes the reference to the MAGIC_NUMBER field.
> To help the other jar (so that it does not need to recompile when constants are changed) the original developer can declare their constant using one of the CONST() utility methods, instead:
> {code}
>   public final static int MAGIC_NUMBER = CONST(5);
> {code}
> I imagine the code would look something like this:
> {code}
> public static boolean CONST(boolean v) { return v; }
> public static byte CONST(byte v) { return v; }
> public static char CONST(char v) { return v; }
> public static short CONST(short v) { return v; }
> public static int CONST(int v) { return v; }
> public static long CONST(long v) { return v; }
> public static float CONST(float v) { return v; }
> public static double CONST(double v) { return v; }
> public static <T> T CONST(T t) { return t; }
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira