My concern is that issues with existing workarounds were given lower priority. Now many workarounds will disappear, but I'm worried that the priorities will not be reconsidered.
I think part of the problem is the fact that Java does not have a good way of marking an API as experimental. Anything public can never change, so JDK developers don't make things public if they are not quite happy with the API yet, even though some bits would be useful for others. As a consequence, they get no or very little feedback on a private API, thus slowing the progress towards the non-experimental API even more. Sure, experimental functionality could still be dropped at any time, but that is not happening here. The functionality remains, it is just going to be hidden. Robert makes a good point that designing a stable API for something that is currently private and possibly ugly is much more work than pulling ad-hoc hacks with the experimental API. I believe Jira issues are mostly there, I'm just skeptical that all of the issues currently targeted for 9 will actually be resolved in 9. On Wed, Apr 8, 2015 at 1:23 PM, Robert Krüger <krue...@lesspain.de> wrote: > OK, while I wrote this, all the other replies came in. So I see that your > recommendation for the cases I mentioned is then to patch OpenJDK and > submit Jira issues. Fair enough. > > Regarding Jira issues, we are already doing that. Regarding code > contribution, this is a different thing, because in many cases a hack to > expose something that should be there is quick but designing a consistent > API that exposes the missing things is often something that requires a > different qualification. > > >>
