#LJCConf Meet a Project

[Graham Allan]

If you came to chat to me at the LJC Open Conference and are looking for how to get involved with Mutability Detector, you've came to the right place :)

To get a feel for what Mutability Detector does, and what it's used for, check out some of the blog posts at: http://mutability-detector.blogspot.co.uk/

A wiki page describing how to get started developing is here: http://code.google.com/p/mutability-detector/wiki/HowToContribute

One open issue is a particularly low-hanging fruit: http://code.google.com/p/mutability-detector/issues/detail?id=31

I hope some of you are eager to get involved.

Remember, there are no silly questions!

Kind regards,
Graham

[Joe Wong]

Hi Graham,

I can see the change submitted to the MutabilityAssert.java source file in the svn repo. If this is the case I take it you will either want to generate the javadocs or mark the issue as resolved and close it.

Cheers,

Joe.

[Graham Allan]

Ah yes, sorry about that, I have it fixed in the java source file, but
not in the Javadoc.

I have another TODO list that I need to complete before releasing 0.9
( http://code.google.com/p/mutability-detector/source/browse/trunk/MutabilityDetector/trunk/MutabilityDetector/Release-0.9-TODO.txt
)

I don't expect any of that to make much sense, but I'll try to get a
chance to make it more friendly to newcomers at some point in the next
few days.

Joe, besides me not closing off issues properly, has anything else
stuck out as being a hindrance to getting started helping out?

Regards,
Graham

[Joe Wong]

Firstly I think you've done a great job with the way the project is publicised, all of the online resources. The todo list is fine however a thread discussing issues in more detail would be really nice :)

As I currently understand it the mutability detector provides tests of mutability/immutability of a given Java class. The tests work very well (with only a few outstanding exceptions which the user can specify). From reading the blog and Google it looks like users are mostly interested in true positive results and false negative results for immutable classes only (i.e. software will correctly identify mutability/immutability however if incorrect an exception needs to be made). The mutability detector may not cover all cases but it should come very close. As long as users are aware that this currently covers the majority of cases required for immutability I don't see why an rc1 can't be released. Some cases such as Java String will still require a resolution (or a hard-coded compromise).

Would looking at how other languages handle issues such as concurrency and see if they apply to the Java String issue?

Could we run this on other pieces of software? Maybe pitching this to other opensource Java Concurrency projects would help promote further feedback and improve the mutability detector.

I hope the above helps. From the list I will start on the first one I like unless you've got one you'd like me to check out.

Cheers,

Joe.

[Graham Allan]

Hey Joe,

Comments inline:

On 2 December 2012 22:39, Joe Wong <joeb...@googlemail.com> wrote:
> Firstly I think you've done a great job with the way the project is
> publicised, all of the online resources. The todo list is fine however a
> thread discussing issues in more detail would be really nice :)
>

If I get a chance I'll convert the to do list into issues on
googlecode where a discussion can be held for each item. I'll also
mark each one with a difficulty/effort level.

> As I currently understand it the mutability detector provides tests of
> mutability/immutability of a given Java class. The tests work very well
> (with only a few outstanding exceptions which the user can specify). From
> reading the blog and Google it looks like users are mostly interested in
> true positive results and false negative results for immutable classes only
> (i.e. software will correctly identify mutability/immutability however if
> incorrect an exception needs to be made). The mutability detector may not
> cover all cases but it should come very close. As long as users are aware
> that this currently covers the majority of cases required for immutability I
> don't see why an rc1 can't be released. Some cases such as Java String will
> still require a resolution (or a hard-coded compromise).
>

I think that's an accurate description :)

> Would looking at how other languages handle issues such as concurrency and
> see if they apply to the Java String issue?
>
> Could we run this on other pieces of software? Maybe pitching this to other
> opensource Java Concurrency projects would help promote further feedback and
> improve the mutability detector.
>

I think looking for other projects would be a great idea. My efforts
on this so far have been trying to find uses of @Immutable annotation
to look for potential users. Perhaps this could be extended to look
for other terms (i.e. using the word "immutable" in javadoc). Then
submitting test cases to those projects. Even just testing out
Mutability Detector and feeding back the results would be really
useful. Perhaps you'd like to give this a go to get more familiar with
using it? Perhaps a naive search like
"http://grepcode.com/search/?query=immutable" may lead to a project
worth digging in to?

Another thing I've been meaning to do is take a look at JSR 308[0],
and it's checker implementation for the @Immutable annotation. I'd
love to see how usage of the IGJ Immutability Checker[1] compares to
Mutability Detector. A blog post, or just a thread on this mailing
list to have a discussion about it would be awesome.

> I hope the above helps. From the list I will start on the first one I like
> unless you've got one you'd like me to check out.
>

There's been some great work by Mani to port from googlecode to
GitHub. Mani, is there anything Joe would be able to help out with for
that? (Assuming this interests you, Joe)

Kind regards,
Graham


[0] http://types.cs.washington.edu/jsr308/
[1] http://types.cs.washington.edu/checker-framework/current/checkers-manual.html#igj-checker

[Joe Wong]

Hello Graham, Mani,

I really like the issues list and priority idea. I don't mind looking at setting up a bug tracking system such as trac (wiki and issue tracking) and providing hosting for this. Issue tracking should be done properly IMHO to avoid duplicate issues as well as a clearer understanding of the issue. Trac looks like it would work well with Git since this is being configured by Mani. Git was something we briefly discussed, very glad to see it may be useful. Also this will be a new challenge to me as I've never setup an issue tracking system, expect this to take a bit of time to get configured tho.

Setting up Git should be simple. Creating a repository is free and adding the code is pretty fast, just don't forget the project README.md file. How this will integrate with trac I don't know but look forward to seeing if it will work with a public repository.

I've found a few concurrent java classes which use the Threading library however it is incorrect to assume immutability is required in all of these cases. One being the JEdit project found through Krugle. In this case immutability may not be a primary concern just creating a new thread to separate foreground/background tasks and reduce blocking.

I am interested in Machine Learning algorithms. This area is heavy on memory usage but also requires correct implementation of models. I will look for a few examples of these models with immutable implementations. If I have to I will start implementing immutable models tested against real datasets (e.g. the non-linear iris dataset will require a non-linear algorithm to perform separation of the 3 iris classes). Also there are enough papers with examples out there to do verify against (Netflix prize?)! I believe that this is a general and useful real world example that will demonstrate how useful the mutability detector really is.

Another area of interest would be Android projects. There tends to be different threads for different tasks e.g. user interface, background processing. This holds where the heavy lifting is just about possible in Java and has not been implemented in C (as it now appears the case). I have not actively looked for Android projects with immutable classes but it could be something we throw at the London Android Meetup group. A good example would be projects implementing fancy SLAM (Simultaneous Localisation And Mapping) implementations, this is an algorithm used to map a scene and can be used to add virtual 3D objects into a moving video scene in real time. This if it isn't already is a very useful bit of functionality to have implemented on a phone. This would be scheduled as a background process and may require some immutable code especially since many very modern smart phones provide threading functionality and concurrency can be a pain.

I hope these ideas help, let me know if you have any questions.

Cheers,

Joe.

[Graham Allan]

Hey Joe,

Comments inline:

On 5 December 2012 22:45, Joe Wong <joeb...@googlemail.com> wrote:
> Hello Graham, Mani,
>
> I really like the issues list and priority idea. I don't mind looking at
> setting up a bug tracking system such as trac (wiki and issue tracking) and
> providing hosting for this. Issue tracking should be done properly IMHO to
> avoid duplicate issues as well as a clearer understanding of the issue. Trac
> looks like it would work well with Git since this is being configured by
> Mani. Git was something we briefly discussed, very glad to see it may be
> useful. Also this will be a new challenge to me as I've never setup an issue
> tracking system, expect this to take a bit of time to get configured tho.
>
> Setting up Git should be simple. Creating a repository is free and adding
> the code is pretty fast, just don't forget the project README.md file. How
> this will integrate with trac I don't know but look forward to seeing if it
> will work with a public repository.
>

With Mani's help the move to GitHub has just been completed. It has an
integrated wiki and issue tracker, so I don't think there's any need
to add Trac to the setup. And I made sure to have a README.md :)

> I've found a few concurrent java classes which use the Threading library
> however it is incorrect to assume immutability is required in all of these
> cases. One being the JEdit project found through Krugle. In this case
> immutability may not be a primary concern just creating a new thread to
> separate foreground/background tasks and reduce blocking.
>
> I am interested in Machine Learning algorithms. This area is heavy on memory
> usage but also requires correct implementation of models. I will look for a
> few examples of these models with immutable implementations. If I have to I
> will start implementing immutable models tested against real datasets (e.g.
> the non-linear iris dataset will require a non-linear algorithm to perform
> separation of the 3 iris classes). Also there are enough papers with
> examples out there to do verify against (Netflix prize?)! I believe that
> this is a general and useful real world example that will demonstrate how
> useful the mutability detector really is.
>

Yup this is the kind of thing I was thinking of in terms of finding
real use cases for MD.

> Another area of interest would be Android projects. There tends to be
> different threads for different tasks e.g. user interface, background
> processing. This holds where the heavy lifting is just about possible in
> Java and has not been implemented in C (as it now appears the case). I have
> not actively looked for Android projects with immutable classes but it could
> be something we throw at the London Android Meetup group. A good example
> would be projects implementing fancy SLAM (Simultaneous Localisation And
> Mapping) implementations, this is an algorithm used to map a scene and can
> be used to add virtual 3D objects into a moving video scene in real time.
> This if it isn't already is a very useful bit of functionality to have
> implemented on a phone. This would be scheduled as a background process and
> may require some immutable code especially since many very modern smart
> phones provide threading functionality and concurrency can be a pain.
>

I never even thought about Android code, that's a great point. MD has
never even been tested on Android as far as I know. I have no idea if
the different bytecode representation would cause a problem (MD
analyses the Java bytecode, the equivalent for Android is... dex I
think). Do you have experience developing for Android? It would be
good to just "kick the tyres" and see if MD works even a little bit :)

> I hope these ideas help, let me know if you have any questions.
>

They're much appreciated, thank you.

Kind regards,
Graham

[Mani Sarkar]

> I hope the above helps. From the list I will start on the first one I like
> unless you've got one you'd like me to check out.
>

There's been some great work by Mani to port from googlecode to
GitHub. Mani, is there anything Joe would be able to help out with for
that? (Assuming this interests you, Joe)

Sorry Graham, I just saw this message come, too late to say anything - basically its my mailing list settings I get messages few days after they have been posted.

Do we have anything else that needs to be done for your new and shiny github repo? How about for the other two projects in their own repos, they are kinda isolated from the main one and don't share the wiki - is that an Idea make that happen? 

[Graham Allan]

Hey Mani,

I think the GitHub work is complete. I explicitly want the projects to
be separate, so I don't see a need to join them.
ClientOfMutabilityDetector doesn't really concern users, only
developers. With the other two, if people raise issues on either I'm
happy to answer them. Maybe just needs some more info for the FindBugs
plugin to point back to the main project.

Thanks again, you did a great job.

~ Graham

[Mani Sarkar]

Hey Graham,

Your compliments are very welcome!

Btw our Mutability detector was mentioned at a course I recently attended and that gives me further incentive to use it in my projects.

More about it in the coming days and weeks! Hopefully I will be able to get my head around it soon enough.

Regards,

Mani

[Graham Allan]

Cool. Do you remember what context it came up in? Hopefully whoever
mentioned it had nice things to say :)

[Mani Sarkar]

Aah it was just an intro to mutability when the topic was discussed and a link to our repo was mentioned (i think it was the github repo). So nothing specific was spoken of but that your work is recognised which is a highlight of the gesture.

Cheers,

Mani

On Tue, Dec 18, 2012 at 10:19 PM, Graham Allan <grundl...@gmail.com> wrote:

Cool. Do you remember what context it came up in? Hopefully whoever
mentioned it had nice things to say :)

On 17 December 2012 23:08, Mani Sarkar <sadh...@gmail.com> wrote:
> Hey Graham,
>
> Your compliments are very welcome!
>
> Btw our Mutability detector was mentioned at a course I recently attended
> and that gives me further incentive to use it in my projects.
>
> More about it in the coming days and weeks! Hopefully I will be able to get
> my head around it soon enough.
>
> Regards,
> Mani
>
>

--
Twitter: @theNeomatrix369

Blog: http://neomatrix369.wordpress.com

Don't chase success, rather aim for "Excellence", and success will come chasing after you!