interface constants and security

[Yin99]

Joshua Bloch who wrote "Effective Java - Programming Language Guide"
says you should disallow the use of "public static final" array fields.
He argues that the contents of all non-empty array fields are mutable,
so attackers can modify your 'constants' if you ignore this rule.

My Question is does creating Interface Constants (which are "public
static final" by default) prone to this vuneralbility Mr. Bloch speaks
of?

Yin99

 

[Heiner Kücker]

Yin99 wrote

Joshua Bloch who wrote "Effective Java - Programming Language Guide"
says you should disallow the use of "public static final" array fields.
He argues that the contents of all non-empty array fields are mutable,
so attackers can modify your 'constants' if you ignore this rule.

My Question is does creating Interface Constants (which are "public
static final" by default) prone to this vuneralbility Mr. Bloch speaks
of?

Yin99

No, simple values and simple Objects (java.lang.*)
are immutable with the
public static final
modifier.

Complex Objects with public values or set methods
and arrays are not immutable.

An Issue to making arrays immutable is wrapping
with an class:

public class ImmutableStringArray
{
/** the Array */
private static String[] CONST_STR_ARR = new String[] { "a" , "b" , "c" };

/** the immutable wrapper get method */
public String getValue( int pIndex )
{
return CONST_STR_ARR[ pIndex ];
}
}


--
Heiner Kuecker
Internet: http://www.heinerkuecker.de http://www.heiner-kuecker.de
JSP WorkFlow PageFlow Page Flow FlowControl Navigation: http://www.control-and-command.de
Java Expression Formula Parser: http://www.heinerkuecker.de/Expression.html
CnC Template Technology http://www.heinerkuecker.de/Expression.html#templ
Domain Specific Languages http://www.heinerkuecker.de/DomainParser.html

 

[Chris Smith]

No, simple values and simple Objects (java.lang.*)
are immutable with the
public static final
modifier.

I see what you're trying to say, but I think that's a very poor way to
put it. Whether an object is immutable or not has nothing to do with
whether it is "simple", or whether it belongs to the java.lang.*
package. It would be better to not say anything about classes that are
simple or that reside in java.lang.

The conditions for an immutable object, on the other hand, are:

1. The class is final.
2. No methods modify the object state.
3. All fields are either private, or they are final and are either
primitive or point to other immutable objects.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Chris Smith]

Joshua Bloch who wrote "Effective Java - Programming Language Guide"
says you should disallow the use of "public static final" array fields.
He argues that the contents of all non-empty array fields are mutable,
so attackers can modify your 'constants' if you ignore this rule.

My Question is does creating Interface Constants (which are "public
static final" by default) prone to this vuneralbility Mr. Bloch speaks
of?

The two have nothing to do with each other. Declaring your constants in
interfaces does NOT prevent the problem Joshua Bloch mentions, but
neither does it make it any more likely. So don't place constants in
public arrays, regardless of whether the arrays are declared in an
interface or not.

There are, though, enough other good reasons why declaring constants in
interfaces is a bad idea, that no one should be doing it.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Chris Uppal]

There are, though, enough other good reasons why declaring constants in
interfaces is a bad idea, that no one should be doing it.

Seems a bit strong to me. If there are some constant values that form part of
some contract, then why /not/ define corresponding constants in the
corresponding Java interface ?

Actually, I'm struggling to think of /any/ reason why defining constants in
interfaces might be considered a bad idea (that doesn't apply to constants in
classes just as well). The only ones I can think of pertain to the
innapropriate use of constants in interfaces, but that's because they are
innapropriate, not because they are constants.

-- chris

 

[Chris Smith]

Seems a bit strong to me. If there are some constant values that form part of
some contract, then why /not/ define corresponding constants in the
corresponding Java interface ?

Actually, I'm struggling to think of /any/ reason why defining constants in
interfaces might be considered a bad idea (that doesn't apply to constants in
classes just as well). The only ones I can think of pertain to the
innapropriate use of constants in interfaces, but that's because they are
innapropriate, not because they are constants.

There are two cases here, actually:

1. If the interface is actually used as an interface, then defining
constants there means that those constants will *always* be acessible by
those unqualified names. No one implementing the interface gets a
choice in the matter. That raises some red flags, but might be
acceptable if it's just unthinkable that someone would implement the
interface without using those constants. In most cases, though,
constants of this type are non-type-safe enumerations, and new code
should provide them as a nested enum with 1.5.

2. If the interface only exists to hold constants, then I will stick to
my statement that it's never a good idea. The only reason to do this is
to allow people to implement that interface for the sole purpose of not
needing to qualify constant names. The problem with this is that you've
now made a committment in the external interface of that class;
implementing that interface is a very public thing to do. This is an
abomination. Fortunately, once everyone moves to 1.5, they can use
import static, which is *not* advertized in the public interface of the
class that uses it.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Chris Uppal]

There are two cases here, actually:

1. If the interface is actually used as an interface, then defining
constants there means that those constants will *always* be acessible by
those unqualified names. No one implementing the interface gets a
choice in the matter.

But then the question arises of where else the constants should go. The new
enum stuff is one answer, but it can't really be the /only/ answer unless we
are willing to admit that Java was fundamentally broken pre-1.5 (I am, as you
may remember, perfectly willing to claim that Java is in various ways
fundamentally broken, but I wouldn't list this among the issues ;-).

2. If the interface only exists to hold constants, then I will stick to
my statement that it's never a good idea. The only reason to do this is
to allow people to implement that interface for the sole purpose of not
needing to qualify constant names.

Agreed that this is a hacky, inappropriate, use of interfaces.

-- chris