Statics issues

Peter Levart peter.levart at gmail.com
Sat Dec 20 11:34:54 UTC 2014


Hi,

I joined the list yesterday and read the thread about static fields and 
initialization. I have a feeling the 
one-static-variable-per-source-definition is the desired direction. 
Especially when the number of specialized classes is an implementation 
detail. With one variable per class you would get separate variables per 
each primitive specialization combination, but reference type variables 
do not get specialized classes, which would be confusing.

If static variables are a special case then this should be consistently 
applied to other areas:

public class ValhallaTest {

     static int counter;

     static synchronized <any T> void count(T arg) {
         if (!Thread.holdsLock(ValhallaTest.class)) {
             throw new IllegalStateException("Not synchronized on 
ValhallaTest.class");
         }
         counter++;
         System.out.println("Counting " + counter);
     }

     public static void main(String[] args) {
         count("A");
         count(BigDecimal.ONE);
         count(1);

         System.out.println(counter);
     }
}


This prints:

Counting 1
Counting 2
Specializing method ValhallaTest$count${0=I}.count(Ljava/lang/Object;)V 
with class=[] and method=[I]
Exception in thread "main" java.lang.IllegalStateException: Not 
synchronized on ValhallaTest.class
         at ValhallaTest$count${0=I}/1096979270.count(ValhallaTest.java:12)
         at ValhallaTest.main(ValhallaTest.java:21)


The specializer should also rewrite specialized synchronized static 
methods so they synchronize on the "host" class object.

More "hiding" of specialized classes might be necessary. What would 
happen with the following code:

<any T> void m(T arg) {
     synchronized(getClass()) {
     }
}

This could be "fixed" by not allowing things like Foo<int>.class and 
making Object.getClass() always return the "host" class regardless of 
implementation class. But that means something like:

     this.getClass().cast(this)

...could throw ClassCastException then...

This could be "fixed" by getClass() returning a special interface class 
object that is implemented by "host" class AND all specialized classes.

Reflection issues left behind for now.

I have doubts about "fixing" Object.getClass(), but for static 
synchronized methods I think they should be fixed.

Regards, Peter




More information about the valhalla-dev mailing list