On Wed, 11 Jun 2025 03:09:16 GMT, Prasanta Sadhukhan <psadhuk...@openjdk.org> wrote:
> > I think a better solution is to create a new `MediaTracker`, and start anew > > with id of zero. > > The `TRACKER_KEY` is used only by `ImageIcon`, so it shouldn't break any > > apps. > > If we create a new MediaTracker in ImageIcon and start anew with id of zero, > then if application is having its own MediaTracker to track then when it > calls for tracker.checkID(0) or tracker.statusID(0) then it will be confusing > to which image it is referring to Why is it? `ImageIcon` has its own instance of `MediaTracker`. Yes, technically, it's possible to get this instance from `AppContext` but no application should do it. If an application needs to load images, it has to create its own instance of `MediaTracker`. Since `MediaTracker` API requires a caller provided id, the instance of `MediaTracker` can't be shared, otherwise there's a clash in ids. > …so I guess this current PR is more simpler in the sense it will notify > ABORTED status for all images which overflows so that application can start > anew with new ImageIcon and then use their MediaTracker to track this new > ImageIcon. Could you elaborate please? The `mediaTrackerID` is a static field in `ImageIcon`; `MediaTracker` is also a static-like shared instance that's stored in `AppContext`. This means if `mediaTrackerID` overflows, the application can't use `new ImageIcon` to load any more images — the application can no longer work. The application can do nothing about it. > Other thing that can be done is to modify "int" to "long" for all ids to > further the overflow goalpost whereby `MediaTracker.checkID,addImage, > statusID` signature will be changed..I dont think it will break any > application but it will require CSR and since this issue is earmarked as > Enhancement, maybe submitter also wanted that but I am not sure of going that > route unless there is consensus on it.. I thought about it, and using `long` instead of `int` was my first idea. Yet `MediaTracker` API needs to be modified. But it won't solve the underlying problem: `long` can also wrap around into negative numbers. It'll take much longer, but `long` will wrap around. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25666#issuecomment-2962253908
