Eclipse Community Forums: Rich Client Platform (RCP) » Discouraged accesses

Home » Eclipse Projects » Rich Client Platform (RCP) » Discouraged accesses - consequences?

Discouraged accesses - consequences? [message #463727]

Thu, 15 February 2007 02:12

Eclipse User

Originally posted by: unidad.gmx.net

Hi!

I'm quite new to the RCP-stuff and I'm developing
a little standalone-RCP-Application.
(Kind of a college term project)

I'm implementing several features and the whole thing evolves.

There's one point I'm not sure about. I have several warnings about
discouraged access:

e.g.:

************************************************************ ***************************
Discouraged access: The type JavaFileEditorInput is not accessible due
to restriction on required library
C:\eclipse\eclipse321\plugins\org.eclipse.ui.editors_3.2.1.r 321_v20060721.jar
************************************************************ ***************************

I assume, one should avoid discouraged accesses, but I can't see the
disadvantages if there are any.

Maybe one can clarify this a bit.

Greetings, Hermann

Re: Discouraged accesses - consequences? [message #463735 is a reply to message #463727]

Thu, 15 February 2007 03:28

Eclipse User

Hermann Maier wrote:

> Hi!
>
> I'm quite new to the RCP-stuff and I'm developing
> a little standalone-RCP-Application.
> (Kind of a college term project)
>
> I'm implementing several features and the whole thing evolves.
>
> There's one point I'm not sure about. I have several warnings about
> discouraged access:
>
> e.g.:
>
> ************************************************************ ***************************
>
> Discouraged access: The type JavaFileEditorInput is not accessible due
> to restriction on required library
> C:\eclipse\eclipse321\plugins\org.eclipse.ui.editors_3.2.1.r 321_v20060721.jar
>
> ************************************************************ ***************************
>
>
> I assume, one should avoid discouraged accesses, but I can't see the
> disadvantages if there are any.

For example that this class will be deleted in 3.3 because it is an
internal class. If you use such a class today you can be broken tomorrow.

Dani

>
> Maybe one can clarify this a bit.
>
> Greetings, Hermann
>

Re: Discouraged accesses - consequences? [message #463742 is a reply to message #463735]

Thu, 15 February 2007 03:48

Eclipse User

Originally posted by: unidad.gmx.net

Hi Dani!

Daniel Megert schrieb:
[disadvantages discouraged accesses]
>
> For example that this class will be deleted in 3.3 because it is an
> internal class. If you use such a class today you can be broken tomorrow.
>
> Dani

Okay. That's no problem for me now.

I "deliver" a small standalone-Eclipse-3.2-RCP-App, based on fixed
sources. (It's no commercial thing.) If another one wants to migrate it
to be based on further Eclipse-versions, it's his problem. ;)

Of course this is very bad programming style. If I can avoid it, I would
like to.

Is "every functionality" also available through some public API?

For instance I use Eclipse 3.2 and want to save a file in a
"saveAs"-dialog outside the workspace. Is there perhaps another
"legal" way doing this in Eclipse 3.2 without using JavaFileEditorInput,
which provides the discouraged access?
(I've read your solution with Eclipse 3.3, but unless it's a stable
release, I won't try it. I've enough to do with this one. ;)

Greetings, Hermann

Re: Discouraged accesses - consequences? [message #463775 is a reply to message #463742]

Thu, 15 February 2007 08:43

Eclipse User

Hermann Maier wrote:
>
> Is "every functionality" also available through some public API?

No ... while all of the source is available for use, only certain parts
are public API.

> For instance I use Eclipse 3.2 and want to save a file in a
> "saveAs"-dialog outside the workspace. Is there perhaps another
> "legal" way doing this in Eclipse 3.2 without using JavaFileEditorInput,
> which provides the discouraged access?

It depends on what you want to do in your RCP. For example, you can
find the ActionFactory.SAVE_AS action and add that in your
ApplicationActionBarAdvisor, or use your own action and call the save as
command (the id can be found in the plug-in registry view,
org.eclipse.ui.file.saveAs).

But if you wanted to skip steps, like not have Save As pop open a
dialog, that you can't do without touching internal code.

Later,
PW

Re: Discouraged accesses - consequences? [message #463788 is a reply to message #463742]

Thu, 15 February 2007 10:48

Eclipse User

Hermann Maier wrote:

> Hi Dani!
>
> Daniel Megert schrieb:
> [disadvantages discouraged accesses]
>
>>
>> For example that this class will be deleted in 3.3 because it is an
>> internal class. If you use such a class today you can be broken
>> tomorrow.
>>
>> Dani
>
>
> Okay. That's no problem for me now.
>
> I "deliver" a small standalone-Eclipse-3.2-RCP-App, based on fixed
> sources. (It's no commercial thing.) If another one wants to migrate
> it to be based on further Eclipse-versions, it's his problem. ;)
>
> Of course this is very bad programming style. If I can avoid it, I
> would like to.
>
> Is "every functionality" also available through some public API?

No.

>
> For instance I use Eclipse 3.2 and want to save a file in a
> "saveAs"-dialog outside the workspace. Is there perhaps another
> "legal" way doing this in Eclipse 3.2 without using
> JavaFileEditorInput, which provides the discouraged access?

Only by writing your own editor input.

> (I've read your solution with Eclipse 3.3, but unless it's a stable
> release, I won't try it. I've enough to do with this one. ;)
>
> Greetings, Hermann

Re: Discouraged accesses - consequences? [message #463815 is a reply to message #463788]

Thu, 15 February 2007 16:47

Eclipse User

Originally posted by: unidad.gmx.net

Hi!

Daniel Megert schrieb:
> Hermann Maier wrote:

>> For instance I use Eclipse 3.2 and want to save a file in a
>> "saveAs"-dialog outside the workspace. Is there perhaps another
>> "legal" way doing this in Eclipse 3.2 without using
>> JavaFileEditorInput, which provides the discouraged access?
>
> Only by writing your own editor input.

So, the cleanest solution would be, that I copy the source-code of
JavaFileEditorInput in one of my own classes and so the functionality
will persist, even if JavaFileEditorInput changes in underlying plugins?

Greetings, Hermann

Re: Discouraged accesses - consequences? [message #463821 is a reply to message #463815]

Fri, 16 February 2007 03:01

Eclipse User

Hermann Maier wrote:

> Hi!
>
> Daniel Megert schrieb:
>
>> Hermann Maier wrote:
>
>
>>> For instance I use Eclipse 3.2 and want to save a file in a
>>> "saveAs"-dialog outside the workspace. Is there perhaps another
>>> "legal" way doing this in Eclipse 3.2 without using
>>> JavaFileEditorInput, which provides the discouraged access?
>>
>>
>> Only by writing your own editor input.
>
>
> So, the cleanest solution would be, that I copy the source-code of
> JavaFileEditorInput in one of my own classes and so the functionality
> will persist, even if JavaFileEditorInput changes in underlying plugins?

In your case where an API exists in the next version it makes more sense
to use the internal class in your 3.2.x based plug-in(s) and make a new
version for Eclipse 3.3 that uses the new FileStoreEditorInput API.

Dani

>
> Greetings, Hermann

Re: Discouraged accesses - consequences? [message #463823 is a reply to message #463821]

Fri, 16 February 2007 03:38

Eclipse User

Originally posted by: unidad.gmx.net

Daniel Megert schrieb:

> In your case where an API exists in the next version it makes more sense
> to use the internal class in your 3.2.x based plug-in(s) and make a new
> version for Eclipse 3.3 that uses the new FileStoreEditorInput API.
>
> Dani

Okay, thanks for your input!

Hermann

Re: Discouraged accesses - consequences? [message #463855 is a reply to message #463727]

Fri, 16 February 2007 17:38

Eclipse User

Hermann,
Note that if your RCP application is running with the osgi framework in strict
mode (osgi.resolverMode=strict), then this would result in class not found
exceptions at runtime.

-Andrew

Hermann Maier wrote:
> Hi!
>
> I'm quite new to the RCP-stuff and I'm developing
> a little standalone-RCP-Application.
> (Kind of a college term project)
>
> I'm implementing several features and the whole thing evolves.
>
> There's one point I'm not sure about. I have several warnings about
> discouraged access:
>
> e.g.:
>
> ************************************************************ ***************************
>
> Discouraged access: The type JavaFileEditorInput is not accessible due
> to restriction on required library
> C:\eclipse\eclipse321\plugins\org.eclipse.ui.editors_3.2.1.r 321_v20060721.jar
>
> ************************************************************ ***************************
>
>
> I assume, one should avoid discouraged accesses, but I can't see the
> disadvantages if there are any.
>
> Maybe one can clarify this a bit.
>
> Greetings, Hermann
>

Re: Discouraged accesses - consequences? [message #463879 is a reply to message #463815]

Mon, 19 February 2007 10:20

Eclipse User

Originally posted by: lamont_gilbert.rigidsoftware.com

On Thu, 15 Feb 2007 22:47:11 +0100, Hermann Maier wrote:

> Hi!
>
> Daniel Megert schrieb:
>> Hermann Maier wrote:
>
>>> For instance I use Eclipse 3.2 and want to save a file in a
>>> "saveAs"-dialog outside the workspace. Is there perhaps another "legal"
>>> way doing this in Eclipse 3.2 without using JavaFileEditorInput, which
>>> provides the discouraged access?
>>
>> Only by writing your own editor input.
>
> So, the cleanest solution would be, that I copy the source-code of
> JavaFileEditorInput in one of my own classes and so the functionality will
> persist, even if JavaFileEditorInput changes in underlying plugins?
>
> Greetings, Hermann

The cleanest solution would be to implement your own version of
IEditorInput I have a JavaFileEditorInput myself and its rediculously
simple. Perhaps you can achieve that with simply copy from Eclipse.

Previous Topic:	MasterDetailsBlock and visible actions
Next Topic:	Adding a new context menu (not items to an existing)

Goto Forum:

-=] Back to Top [=-

Current Time: Mon Mar 17 08:29:45 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter