Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo


#180 RFE: refactor to follow JavaBeans patterns


Just a general comment on the API: many of the visualisation objects (layouts, VisualizationViewer, etc) require many objects at construction time. In my applications I rarely have access to the Graph at the point when I am constructing the visualisation code. It would be nice to have default constructors (making JUNG more compatible with GUI Editors, btw) and set these properties through standard Javabeans getters/setters.

In many cases the objects do indeed reveal Javabeans getters/setters anyway, so my workaround is to create an empty dummy graph allowing me to construct objects in a block, then set the Graph later when I have access to it.


  • Anonymous

    (I've renamed this to better reflect the RFE)

    The API for many JUNG objects requires objects at construction, without providing a no-parameter construction. Also, many "setX" methods do a lot of extra work (especially in the Layout code) and there is a lot of funky lazy initialisation going on.

    This RFE can be summarised as:

    * provide no-argument constructers for all objects that don't absolutely need final fields
    * implement the JavaBeans getter/setter pattern whilst minimising the amount of lazy initialisation (have a look at Lombok to dramatically reduce the boilerplate in doing this)

    I believe doing this would make the JUNG API a much easier API to use, whilst also dramatically simplifying the codebase :-)


  • Anonymous

    • summary: Many instantiations require objects --> RFE: refactor to follow JavaBeans patterns