M6 was a long milestone - there was one extra week of development - and hence we could do a little bit more. There are quite a few new features and a few API additions as well.
JDT always provided extension points to contribute Quick Fixes/Assists. However, it was hard for contributors to supply the right IJavaCompletionProposal required by IQuickFixProcessor and IQuickAssistProcessor interfaces. This has been improved as JDT now provides the following default implementations for correction proposals
This makes it easier to implement quick fixes/assists that operate on .java files and use an ASTRewrite. Of course you could always use the internal implementations, but then your code would be littered with forbidden access warnings and the implementations could change any time :)
The bracket matching support in Java Editor has been improved, and among other things it now supports highlighting of enclosing brackets.
This can be configured on the Java > Editor preference page.
There are a few more interesting items, like Selectively ignore errors/warnings from source folders and
Null analysis treats org.eclipse.core.runtime.Assert like Java assert. You can read the complete list here.
As always, feedback is greatly appreciated especially in the form of bug reports!
JDT always provided extension points to contribute Quick Fixes/Assists. However, it was hard for contributors to supply the right IJavaCompletionProposal required by IQuickFixProcessor and IQuickAssistProcessor interfaces. This has been improved as JDT now provides the following default implementations for correction proposals
- org.eclipse.jdt.ui.text.java.correction.ChangeCorrectionProposal
- org.eclipse.jdt.ui.text.java.correction.CUCorrectionProposal
- org.eclipse.jdt.ui.text.java.correction.ASTRewriteCorrectionProposal
This makes it easier to implement quick fixes/assists that operate on .java files and use an ASTRewrite. Of course you could always use the internal implementations, but then your code would be littered with forbidden access warnings and the implementations could change any time :)
The bracket matching support in Java Editor has been improved, and among other things it now supports highlighting of enclosing brackets.
While the feature is visible in Java editor, the infrastructure is in Platform/Text. Hence, if anyone wishes to add the same functionality to other editors they can make use of the following types
- org.eclipse.jface.text.source.DefaultCharacterPairMatcher
- org.eclipse.jface.text.source.MatchingCharacterPainter
Marcel Bruch, of Code Recommenders fame, added the concept of sorting to the content assist framework by adding several new APIs on the content assistant and the processor - see org.eclipse.jface.text.contentassist.ICompletionProposalSorter. Thanks Marcel, and hope to see more contributions from you in future! :-)
Null analysis treats org.eclipse.core.runtime.Assert like Java assert. You can read the complete list here.
As always, feedback is greatly appreciated especially in the form of bug reports!
I'm truly looking forward to dig into your org.eclipse.jdt.ui.text.java.correction APIs. Offering own quick fixes and creating java completion proposals is (at least, was) quite challenging (before). I'm curios how this has changed...
ReplyDelete@Marcel Let us know if you still find something challenging.
ReplyDeleteBecause you asked... ;)
ReplyDeleteNot directly related to the new API, but reusing proposals:
In http://goo.gl/n5eT6 I've put the subclasses of existing IJavaCompletionProposals in which we made a few changes to widen the "IsPrefix" checks. Unfortunately, there are a few final classes which forced me to create a complete copy of the final class instead of subclassing and adapting the isPrefix method (see http://goo.gl/3Bx8f for one such example) Is final required for these classes?
These IJavaCompletionProposal types you refer to are for code completion, and not quick fixes, right? In general, we in JDT do not make stuff API (or non-final) unless asked for. From a quick glance at LazyGenericTypeProposal, I do not see a reason for it to be final. You can open bugs for stuff which you think can be API, and we can discuss on a case by case basis.
ReplyDeleteJust recommended a student to look at and use the new corrections API to implement his "annotations recommender" on top of it. Hope it very easy to use - 1 week until EclipseCon for a demo ;)
ReplyDeleteNice. Looking forward to using the new bracket highlighting.
ReplyDelete