It sounds interesting, but as "the modeling guy" I know that a great many "normal Java programmers" do not like modeling and will not like (and often not know how to read), a class diagram.

It's also hard to imagine how this can scale when my project has hundreds of classes and my workspace has thousands of them.

Are you planning to use something like Zest for diagram layout?

https://www.eclipse.org/gef/zest/

I haven't seen much sign of active life from MoDisco lately but they might well provide similar things:

https://www.eclipse.org/MoDisco/

Hi

Interesting question, but doing precisely what you outline could be a complete waste of time. Something similar could be very useful.

Most of our tools are based on the text paradigm; text editors that are made more scalable by scrolling/folding and more intelligible by projections such as outlines/hierarchies. The projections often use a tree structure for which intelligibility may be assisted by child-folding/ancestor-omission/alphabetical-ordering. This approach is good at conveying list/tree-structured information where the sole relationship of interest can be organised by children/siblings. Repeated named elements require repeated independent text.

Alternative tools use the graph paradigm; graphical editors that are made more scalable by 2-D scrolling (but not folding). Outlines and hierarchies can help. Neighbourhood/successor/predecessor sub-graphs can help too. Graphs are good for displaying graph-structured information, a single box/node for each named-element (no repeats), a line/edge for each relationship, diverse relationships can use line annotations/styling.

For some purposes text is much better, for other purposes graphs are much better. Text is generally more scalable. You need to understand the difference and focus your 'class diagram' attention on problems for which graphs are better.

A further important difference lies in sequential readability. For text we naturally start at the first character and read on. Sometimes we read the outline and use it to fast index to text that we then read. IMHO most graphical drawings are only useful to the original author for whom there was a sequential drawing order that enabled the author to get their ideas in order. During or after drawing, the layout is often contrived to make the drawing maximally visible in some artificial rectangle; drawings in publications are particularly bad this way. An independent reader of the diagram does not know where the story starts. As a minimum, a well-drawn diagram needs a well-written editorial paragraph to guide the reader through the middle-out, bottom-up, left-to-right organisation and focus of the diagram.

A catastrophic problem for Java users is the obfuscation of the code.

For modellers, where UML is encouraged, but often ignored, the 'code' has a simpler structure comprising class and properties with inheritance and reference relationships. There may be operations, but these tend to be secondary queries rather than primary functionality. Auto-drawing this functionality is hard, but perhaps tools have not worked hard enough on folding (so that a class-ancestry appears as a single 'class').

For EMF modellers, the simple class structure is typically obfuscated by getter/setters per property and by interface/implementation per-class; the implemented data is therefore missing from the interface where you would like to find it. Any diagram is therefore bloated to show two boxes per class, and operation boxes around every property.

For EMF Java, where the auto-generation imposes a very strong discipline, a tool could invert the auto-generation to show a nicer picture, but as soon as non-trivial custom code, let alone pure manual Java code, is in use there is a huge problem.

Consequently I would conclude that any attempt to auto-draw 'class' diagrams for typical Eclipse Java code is doomed to failure; you will have much too much to display and the underlying design concepts will be obfuscated.

i.e. zoom out from here will hit excess detail before anything useful is visible. Although a judicious combination of show/hide neighbours may enable the user to tailor the drawing to something useful.

Yesterday, I was trying to understand some EMF code, and on reflection some of my understanding could have been aided by a graphical tool.

Problem: How does my code in MyClass::myMethod() access YourClass::yourData? Solution.
- Select MyClass::myMethod()
- Create a new 'navigation class diagram' for the selection (perhaps called "MyClass::myMethod() Navigation")
- Select YourClass::yourData
- Add the selection to "MyClass::myMethod() Navigation" (perhaps tailored to up-to 5 class search radius, up-to 2 class sub-optimal search)
Result: "MyClass::myMethod() Navigation" shows me the optimum navigation path to YourClass::yourData and alternate paths that are not more than two steps longer.

Problem: How does MyClass ensure that YourClass::yourData is initialized before it is read? Solution.
- Select YourClass::yourData
- Create a new 'access class diagram' for the selection (perhaps called "YourClass::yourData Access")
- Select MyClass
- Add the selection to "YourClass::yourData Access" (not sure how to tailor a search)
Result: "YourClass::yourData Access" shows me in horizontal order
- MyClass ancestor/descendant class methods from which writes can be triggered
- the call-trees that perform the writes
- YourClass::yourData
- the call-trees that perform the reads
- MyClass ancestor/descendant methods from which reads can be triggered

NB. Some kind of pseudo primitives will need to be defined so that Map::put is a known write, and Collection::isEmpty is a known read.

Many other programming challenges could be assisted in this way.

Problem: Is MyClass::myData threadsafe? Solution:
- Select MyClass
- Create a new 'thread safety class diagram' for the selection (perhaps called "MyClass Thread Safety")
- Select MyClass::myData1
- Add the selection to "MyClass Thread Safety"
- Select MyClass::myData2
- Add the selection to "MyClass Thread Safety"
The reads/write call-trees to myData are added to the diagram where a thick 'circle' surrounds myData1, myData2 with synchronized methods bridging the circle. Any call-tree not including a suitable synchronized gets a big red thick line. Redundant synchronized operations get a thin red line.

Ideally this kind of "MyClass Thread Safety" diagram can be saved and its semantics automatically executed by a Java Semantics Analysis Builder.