Problems with the head of SVN

[Traroth]

Hi,

I just made a checkout of the last version of the trunk, and it looks great!

However, I got some issues. I was able to build the main/java, but some classes seem to be missing in SVN for the main/test.

Another thing is that AnalysisSession is an interface and not a class, probably because it was changed recently. How can I get it running?

Regards,


Alexis Dufrenoy

[Graham Allan]

Hi Alexis,

Great to hear you're taking a look! Comments inline.

On 5 July 2012 23:02, Traroth <tra...@gmail.com> wrote:

Hi,

I just made a checkout of the last version of the trunk, and it looks great!

However, I got some issues. I was able to build the main/java, but some classes seem to be missing in SVN for the main/test.

The test build is running successfully in continuous integration, could you please paste the log?  I have performed a clean checkout to attempt to reproduce. With the following commands I get a build success:

$ svn checkout http://mutability-detector.googlecode.com/svn/trunk/MutabilityDetector/trunk/MutabilityDetector/ mutability-detector-read-only

$ cd mutability-detector-read-only/

$ mvn test

Hopefully the message you're seeing will hopefully illuminate what the problem is.

 

Another thing is that AnalysisSession is an interface and not a class, probably because it was changed recently. How can I get it running?

The example shown on the wiki[1] is out of date by a few releases at least. It was only your question on StackOverflow that made me notice it! I plan to commit a working code example to trunk that I can simply link to which will provide a good overview of usage. In the meantime, the following snippet should help you get started:

public final class RuntimeAnalysisExample {

    private final AnalysisSession analysisSession = ThreadUnsafeAnalysisSession.createWithCurrentClassPath();

    private void run(Object requiredToBeImmutable) {

        RequestedAnalysis requestedAnalysis = analysisSession.resultFor(Dotted.fromClass(requiredToBeImmutable.getClass()));

        AnalysisResult result = requestedAnalysis.result;

        if(result.isImmutable.equals(IsImmutable.IMMUTABLE)) {

            // rest safe in the knowledge the class is immutable, share across threads with joyful abandon

        } else if(result.isImmutable.equals(IsImmutable.NOT_IMMUTABLE)) {

            // be careful here: make defensive copies, don't publish the reference, read Java Concurrency In Practice right away!

        }

    }

    

    public static void main(String[] args) {

        new RuntimeAnalysisExample().run(makeParam());

    }

    

    private static Object makeParam() {

        return new java.util.Date();

    }

}

Couple of things to note:

ThreadUnsafeAnalysisSession is, as you might expect, not thread safe. You should perform your own synchronisation around the instance you use if you're in a multithreaded environment. 

Using the factory method createWithCurrentClassPath() means that, among other things, the JDK classes will be analysed from the current runtime, and any class which is on the classpath is available for analysis. 

I realise now that having to deal with several types (RequestedAnalysis/AnalysisResult/IsImmutable) is a bit cumbersome. The runtime API definitely needs a bit of love :-)

There is an overloaded version of createWithCurrentClassPath() which takes a Configuration instance. This is a very raw feature, and the API is subject to change, but it would allow you to pass in an instance which hardcoded, for example, java.lang.String as immutable.

HTH, any questions let me know.

Kind regards,

Graham

[1] http://code.google.com/p/mutability-detector/wiki/MainPage

 

Regards,


Alexis Dufrenoy

[Traroth]

Hi,

Thank you for your tips. About the missing classes, actually, I integrated the code in Eclipse, and some of the classes used in test are simply missing. For example, org.mutabilitydetector.AnalysisSessionTest is looking for a org.mutabilitydetector.benchmarks.ImmutableExample class, which doesn't exist. Or org.mutabilitydetector.benchmarks.visibility.NonFinalFieldsCheckerTest which is looking for a org.mutabilitydetector.benchmarks.settermethod.ImmutableUsingPrivateFieldSettingMethod, which doesn't exist either.
There is a whole bunch of them, so I will not list them all, unless you really want me to do so...

Regards,


Alexis

On Friday, July 6, 2012 12:42:37 AM UTC+2, Graham Allan wrote:

Hi Alexis,

Great to hear you're taking a look! Comments inline.

[Graham Allan]

Ah, in that case I understand what has happened. You just need to add
another source folder ( src/test/benchmarks ) to the eclipse project.
This package contains a collection of classes which don't contain test
cases (e.g. JUnit tests) but are the classes analysed during JUnit
tests.

Placing that folder on the build path should solve the problem you're
seeing. Any problems be sure to post back here :)

I had assumed most people who wanted to build the project would just
use "mvn eclipse:eclipse" to generate all the necessary eclipse files
(.project, .classpath, etc). If you don't mind me asking, is there a
reason you didn't try this?

Kind regards,
Graham

[Traroth]

I'm working with Eclipse and the M2E plugin.
For those who could get the same problem:

• Add the M2E Extras plugin for Eclipse.. Eclipse Update site: https://repository.sonatype.org/content/repositories/forge-sites/m2e-extras/0.14.0/N/0.14.0.201109282148/
• Select the Mojo buildhelper plugin
• Run an install with you pom.xml
• Add the src/test/benchmarks folder to the source folders in your project properties
• Clean your project

And everything should work just fine.

Alexis Dufrenoy

On Saturday, July 7, 2012 4:05:24 PM UTC+2, Graham Allan wrote:

Ah, in that case I understand what has happened. You just need to add
another source folder ( src/test/benchmarks ) to the eclipse project.
This package contains a collection of classes which don't contain test
cases (e.g. JUnit tests) but are the classes analysed during JUnit
tests.

Placing that folder on the build path should solve the problem you're
seeing. Any problems be sure to post back here :)

I had assumed most people who wanted to build the project would just
use "mvn eclipse:eclipse" to generate all the necessary eclipse files
(.project, .classpath, etc). If you don't mind me asking, is there a
reason you didn't try this?

Kind regards,
Graham