Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 530307

Summary:

State records 100 Changes Only

Product:

[Eclipse Project] JDT

Reporter:

Christian Dietrich <christian.dietrich.opensource>

Component:

Core

Assignee:

JDT-Core-Inbox <jdt-core-inbox>

Status:

CLOSED WONTFIX

QA Contact:

Severity:

normal

Priority:

CC:

stephan.herrmann

Version:

4.8

Target Milestone:

---

Hardware:

OS:

Mac OS X

Whiteboard:

stalebug

Attachments:

Description	Flags
Sample	none

Description Christian Dietrich

2018-01-25 08:41:47 EST

Created attachment 272406 [details]
Sample

I had a discussion with andrey Loskutov on a wired bevaviour of the Xtext Java Integration. This issue is known to Xtext as https://github.com/eclipse/xtext-eclipse/issues/453 it is part of the Xtext Codebase since long long ago and its partially cause by internal api. We know that using internal api is bad. never the less Andrey asked my to file this bug to discuss on the issue.

- Xtext hooks into JDT Builder State Class.
- We watch structurallyChangedTypes to find out which types really change or which where touched only. We already have a IElementChangedListener but additionally rely on the structurallyChangedTypes and the lastStructuralBuildTime of the Java Builder State.
- Unfortunately JDT reports structurallyChangedTypes only if the number is < 100.
- so if there is a incremental build with bigger changes xtext wont catch these

you can find a example attached. it requires xtext domain model inplace to see the  effects with xtext. the jdt behaviour should be observale without.

the project contains a generator and a toucher. the generator creates a bunch of java files, the toucher changes these so that the xtext (.dmodel) files should become red

Comment 1 Stephan Herrmann

2018-01-25 08:57:59 EST

My first guess would be that MaxStructurallyChangedTypes is somehow involved in deciding to abort incremental build and scheduling a full build instead. Do you happen to know?

Asking because: if JDT "gives up" on incremental build, then we won't even bother to compute the full set of structurally changed types, essentially because that would be more expensive than the savings it could enable.

Comment 2 Christian Dietrich

2018-01-25 09:00:19 EST

good point. i have not thought on this secenario yet

Comment 3 Eclipse Genie

2020-01-20 15:56:17 EST

This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug.

If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.

Comment 4 Christian Dietrich

2020-01-20 16:10:02 EST

still the case

Comment 5 Stephan Herrmann

2020-01-20 16:42:58 EST

(In reply to Christian Dietrich from comment #4)
> still the case

Have you checked the relation to when we abort incremental build and start a full build instead? (see comment 1).