FULL PRODUCT VERSION :
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-beta2-b51)
Java HotSpot(TM) Client VM (build 1.5.0-beta2-b51, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
 customer  Windows XP [Version 5.1.2600]

A DESCRIPTION OF THE PROBLEM :
A private final int variable of a class can be modified via reflection

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
just execute the source below

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
an IllegalAccessException should be thrown
ACTUAL -
the value can be set without exception

ERROR MESSAGES/STACK TRACES THAT OCCUR :
--- xxxxx ---

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.lang.reflect.*;

public class Test
{
	public static void main(String[] tooralooraloo) throws Throwable
	{
		Change change = new Change(42);
		System.out.println("before: "+change);
		
		Field f = change.getClass().getDeclaredField("number");
		f.setAccessible(true);
		
		f.set(change, new Integer(666) );
		System.out.println("after: "+change);
	}
}

class Change
{
	private final int number;
	
	Change(int x)
	{
		number = x;
	}
	
	public String toString()
	{
		return number + "";
	}
}
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
--- xxxxx ---

Release Regression From : 1.4.2
The above release value was the last known release where this 
bug was known to work. Since then there has been a regression.

(Incident Review ID: 276697) 
======================================================================

N/A

This is the expected behaviour.  After much deliberation, bug 5044412 modified
the specification of Field.set to allow modification of the field if it is
non-static and setAccessible(true) has succeeded.  The specification of Field.set contains more details.

In making this change, we reverted to the behaviour which existed prior to
jdk1.3.

--   xxxxx@xxxxx   2004-06-09

Alternating the debvaiour to and fro is not very useful. since an application developed with jdk 1.4.x need not to check whether untrusted code can access to a final variable, this has now to be done an leads to weak security when running and compiling old code with the new vm.

Oh, and by the way, the documentation of Field.set
still says, if the underlying field is final, this method will 
throw an IllegalAccessException

The final API for JDK 5.0 has apparently been corrected to describe the behavior.  In 1.4.2 it said  "If the underlying field is final, the method throws an IllegalAccessException."  Now in 5.0 we have "If the underlying field is final, the method throws an IllegalAccessException unless setAccessible(true) has succeeded for this field and this field is non-static."