| Validating JvmType imports [message #836406] |
Wed, 04 April 2012 08:56  |
Eclipse User |
|
|
|
Karsten Thoms posted some code to validate Java imports in a DSL: https://kthoms.wordpress.com/2012/04/03/jvmtype-import-check/
But the code has one problem: org.eclipse.xtext.common.types.access.IJvmTypeProvider is not a public API (access is "discouraged" (?) in the access rules of the plug-in org.eclipse.xtext.common.types 2.2.1)
Since this is an extremely useful example: Is the code in the blog post wrong or should I file enhancement request to make this API public?
|
|
|
|
|
|
| Re: Validating JvmType imports [message #841552 is a reply to message #840798] |
Wed, 11 April 2012 09:03  |
| Eclipse User |
|
|
|
Hi Aaron,
it will become public API as soon as we have the feeling that it's
mature enough. We don't have the resources to maintain poorly designed
APIs and apply deprecation strategies thus we warn clients that the
referenced code may change.
What you consider pretty stable is not necessarily stable from our
perspective, e.g. the resource set may be a to broad context for the
lookup environment of a type (which indeed it is).
Regards,
Sebastian
--
Need professional support for Eclipse Modeling?
Go visit: http://xtext.itemis.com
Am 10.04.12 16:21, schrieb Aaron Digulla:
> Karsten Thoms wrote on Fri, 06 April 2012 14:55
>> You can add @SuppressWarnings("restriction")
>> to your class.
>
>
> Well, yes but I was rised to pay heed to warnings ;)
>
> My main complaint is that I must add the annotation to the class
> (because I also get warnings for the imports), so the scope of the
> annotation to too broad for my liking.
>
> Okay, I can work around this by not using imports but FQ names but,
> well, it would be better if Xtext would offer an official API for this.
>
> I think that many DSLs need to interface Java code and the API to check
> imports and type names should be pretty stable.
|
|
|
| Re: Validating JvmType imports [message #843660 is a reply to message #841552] |
Fri, 13 April 2012 04:46 |
| Eclipse User |
|
|
|
I understand. Here is the recipe for a workaround:
- Create another class which contains *only* restricted API calls (i.e. methods that simply delegate, no logic).
- Add @SuppressWarnings("restriction") to that class
- Inject this class into your code
This way, there is no risk to suppress too many warnings (or the wrong ones) and all the "risky" code is in one place.
|
|
|
Powered by
FUDForum. Page generated in 0.05203 seconds
Home