Don't know much about C++, but from your example, it seems like "const
A* ya" is syntactic sugar for marking all of the member fields as final. You
can achieve that in Java like this:

<wontCompile>
class A {
 final public int i;
}
</wontCompile>

But if you do that, you need to make sure that i gets initialized somehow;
e.g., via a constructor:

<betterCode>
class A {
 final public int i;

 public A(int initialValueForI) {
   this.i = initialValueForI;
 }
}
</betterCode>

   - Oliver

You cannot do this in Java :-(

Starting programming in Java, I first missed
this construct, but you can live without it.

Hovewer if you want to assure that the
compiler forbids you when ANY method
changes the contents of an instance
when the method isn't allowed you can
use a "dirty workaround".

1. Declare all members of the class
   private or protected.
2. Define an Interface with similar name
   that ONLY defines those methods that
   don't changes the "contents" of an
   instance.
3. Tell your original class to implement
   this interface.
4. Use the interface instead of the original
   class for local vars or parameters if
   you want to have them "const"

Example:

public class Const {
 public static void main(String[] args) {
   Klasse k = new Klasse();
   normal(k);
   konst(k);
 }

 static void normal(Klasse k) {
   k.set(-42);
   k.negate();
   System.out.println(k.get());
 }

 static void konst(KlasseC kC) {
   kC.set(-42);   // Compile-Error
   kC.negate();   // Compile-Error
   System.out.println(kC.get());  // OK
 }
}

interface KlasseC {
 public int get();
}
class Klasse implements KlasseC {
 protected int i;

 public void set(int i) {this.i = i;}
 public int get() {return i;}
 public void negate() {i = -i;}
}

But this is only a "dirty" solution. If one
of the "get"-methods of your methods
return an object itself, this wan't work
in "deep"

Leroy42

No.

There are, however, various patterns and idioms for handling the
requirement.  These include:

1. The simplest way to make on object "constant" is to only give out
copies of the object.  That way, the other side can modify their private
copy all they like, without having any impact on program correctness.  
There are obvious performance costs.

2. The other option is to use a single object, but arrange for different
interfaces to that object based on const-ness.  This requires that you
separate the exposed API of the object into interfaces in the first
place.  There are three variations:

* Variation 2a: "False Unmodifiability"

Here, you define two interfaces and a class.

   public interface UnmodifiableValue
   {
       public String getName();
   }

   public interface Value extends UnmodifiableValue
   {
       public void setName(String name);
   }

   public class ValueImpl implements Value { ... }

You can then pass around references of type Value or UnmodifiableValue.  
It's "false" because a simple cast would allow someone to treat an
unmodifiable value as modifiable.  Of course, the same is true of
const-ness in C++, where const_cast<T> can be used to accomplish this
goal.  This is, in fact, the closest thing Java has to C's const when
applied to objects.

* Variation 2b: "Optional Operations"

Here, you write an adapter that just throws exceptions from some
operations.  This is poor OO design, but nevertheless is sometimes used
when simplicity is valued above correctness of the exposed interface.

   public interface Value
   {
       public String getName();
       public void setName(String name);
   }

   public class ValueImpl implements Value { ... }

   // and a method somewhere
   static Value unmodifiableValue(final Value base)
   {
       return new Value() {
           public void setName(String name)
           {
               throw new UnsupportedOperationException();
           }

           public String getName()
           {
               return base.getName();
           }

       };
   }

This is used in the Collections API, for example.

Variation 2c. "Interface Adapter"

This is a combination of the previous two.  2a provide compile-time
const-ness.  2b provides runtime const-ness.  This provides both.

   public interface UnmodifiableValue
   {
       public String getName();
   }

   public interface Value extends UnmodifiableValue
   {
       public void setName(String name);
   }

   public class ValueImpl implements Value { ... }

   // and a method somewhere
   static UnmodifiableValue unmodifiableValue(final Value base)
   {
       return new Value() {
           public String getName()
           {
               return base.getName();
           }

       };
   }

Hopefully, one of the above will meet your needs.

the closest to that is as immutable object. The next best thing is an
interface-style reference to an object with no mutating methods.

There are several others tricks.

see http://mindprod.com/jgloss/immutable.html