| RE: [cross-project-issues-dev] Is everyone always visible? |
David,
Just the fact that a class isn't protected or private is already a good
hint that someone else might need it. Have you ever had clients who
figure out they can get at internals of a class reflectively
(AccessibleObject.setAccessible(true)) despite the access protections
you've put in place? You'd be amazed what folks will do to accomplish
their goals, so welcome to the real world! :-) I'm not sure if you
actually track absolutely all your adopters to know what's being used and
what isn't but I would imagine not and hence your policy could only apply
to new things, not to any existing things, which you must assume are being
used by someone. Keep in mind that many adopters won't glance at a thing
you're doing until after you release, so again, welcome to the real world!
And don't take this question the wrong way, but don't you have better
things to do, such as making WTP more usable or growing the community by
answering newsgroup questions, than making the framework less accessible?
:-p Note that even with APIs there are dangerous break-everyone behaviors
one could inflict, e.g., imagine what IContentDescription.BOM_UTF_16BE[0] =
'<'; IContentDescription.BOM_UTF_16BE[1] = '?'; would do. You really
can't legislate against stupidity and even malice is difficult to prevent.
Just try to find an expert in Java security; you'll be hard pressed! I
remember folks wanting EMF to stop throwing security violations in certain
places and they would suggest changes, all of which did a great job
eliminating the exception, but did so by creating a security hole rather
than by fixing it...
>From what I'm seeing, I think the community has spoken and they're telling
you "Just say no to closed!" Where is the community that's giving you a
different message?
Ed Merks/Toronto/IBM@IBMCA
mailto: merks@xxxxxxxxxx
905-413-3265 (t/l 969)
David M Williams
<david_williams@u
s.ibm.com> To
Sent by: Cross project issues
cross-project-iss <cross-project-issues-dev@eclipse.o
ues-dev-bounces@e rg>
clipse.org cc
Subject
09/10/2007 01:00 RE: [cross-project-issues-dev] Is
AM everyone always visible?
Please respond to
Cross project
issues
<cross-project-is
sues-dev@eclipse.
org>
Oh, I love being controversial :)
So, I'll say that so far, all these strong opinions haven't said anything
to change my mind.
Mostly because I can tell you haven't read the proposed policy or any of
the background mailing list links :)
This isn't about making an effort to hide internals. This is about not
strictly requiring everyone to _always_ list everything
in the manifest.mf file. We in WTP are fully aware almost all of our
simply "internals" would still have to be listed,
but that's not what this is about. I think any package we decided fit
within our policy would not be missed by anyone.
(If it was, we failed at implementing our policy!).
I'm curious ... those of you that feel so strongly about this ... do you
think all Classes should be public? And we should
no longer use "protected" or default (package) access for Classes? I'm
wondering what you think is different about this
proposal I'm making, and those cases? Are "we" just old fashioned, stuck in
our ways, and missing out on a innovations that have occurred
in improving specifications?
Jeff McAffer
<Jeff_McAffer@xxxxxxxxxx>
Sent by: To
cross-project-issues-dev-bounces@e Cross project issues
clipse.org <cross-project-issues-dev@e
clipse.org>
cc
09/09/2007 10:34 PM
Subject
RE:
Please respond to [cross-project-issues-dev]
Cross project issues Is everyone always visible?
<cross-project-issues-dev@eclipse
.org>
It just wouldn't be September without this topic coming up... Guess it is
David's turn to get slapped around a bit... ;-)
I am firmly with Chris and Mik. Many years ago I proposed something much
along the lines of what you are suggesting. The out-pouring was quite
dramatic. Then a couple years ago someone misunderstood something I said
for such a proposal. It took about a month of email to calm that one down.
In the end the "winning" argument is that without exporting of some kind,
people just cannot access the code. Where is the win in that? The PDE/JDT
folks have done a wonderful job of tooling x-internal and x-friends. The
upcoming API tooling will enhance this by allowing for postmortem and
third-party API/internal usage analysis. Further more, you can run the
platform in "strict" mode and get the effect you are looking for. With all
these mechanisms, people do not have any excuse for using non-API other
than "we thought long and hard and really needed to call that method,
access that class, ..." As open source bundle producers our job is to
inform our users of the API and intended use models. For the most part the
consumers are adults who can choose for themselves if they want to color
outside the lines.
Since the decision is so black and white, pursuing this direction will also
require considerable effort and debate within the community as you decide
which code to export and which to banish.
Chris' point about the code being freely available and modifiable is bang
on as well. All this would do in the end is force people to fork *your*
bundle to add the export. We'd have a configuration nightmare.
Finally, rightly or wrongly, there are quite a number of commercial
products (some you know all too well) that use internals. Who is to say
that the code you are looking to banish would not be the subject of such
wandering eyes?
In short, just say "no"
Jeff
"Mik Kersten" <beatmik@xxxxxxx>
Sent by:
cross-project-issues-dev-bounces@
eclipse.org To
"'Cross project issues'"
<cross-project-issues-dev@ec
09/09/2007 08:53 PM lipse.org>
cc
Please respond to Subject
Cross project issues RE:
<cross-project-issues-dev@eclips [cross-project-issues-dev]
e.org> Is everyone always visible?
I very strongly agree with the points that Chris raises.
As someone who has to evolve and maintain an API, I wholeheartedly
sympathize with the desire to hide some of the internals that can make a
framework fragile or result in a burden when integrators complain about
changing internals. But in my opinion the benefits to integrators far
outweigh the relatively small burden to the project. Those building APIs
can never predict all the interesting ways that their framework will get
extended, which is why access to internals has been such a key enabler of
extensibility for the Platform. By being at the bottom of the stack the
Platform exposes itself to more of a maintenance burden more than any other
project, and they have done an amazing job leading by example, and putting
safeguards in place when needed. The following blog post has a summary of
why I think it?s so important to have access to all of the code in an open
framework: http://tasktop.com/blog/?p=5
As a practical matter, for our 3.0 cycle Mylyn is planning to better
support JEE development via WTP-specific extensions, such as those already
prototyped in Spring IDE. The Mylyn Platform/SDK extensions could not
exist if any of the SDK had inaccessible internals, even those that the API
developers thought nobody would ever want to access. This is because Mylyn
is an extension that crosscuts typical API boundaries by layering over the
tools entire UI and models beneath that UI. If WTP starts hiding packages
this would either preclude or severely limit the Mylyn integration for WTP,
and we would get stuck doing exactly the ?crazy stuff? that Chris is
referring to.
Mik
From: cross-project-issues-dev-bounces@xxxxxxxxxxx
[mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Chris
Aniszczyk
Sent: Saturday, September 08, 2007 1:59 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Is everyone always visible?
I don't think this is a good idea personally. WTP isn't a commercial
product, it's an open source project. The community expects that they can
access any code, internal or not. If you prevent them from accessing
certain classes, they'll do crazy stuff like Equinox Transforms (
http://wiki.eclipse.org/Equinox_Transforms) to get the MANIFEST.MF the way
they like it.
My inclination is no to the change especially since this is going from a
"everything open come join the party" to "something things are closed"
model.
After reading your policy, how will you implement #1? It seems this would
only be possible for future packages.
"The only packages that can be made "hidden" are ones that no adopter
currently uses and that no one in WTP currently uses, even test plugins..."
In response to what other projects do, I think that's a fantastic idea to
document how other projects treat API (although most I believe will follow
the traditional Platform model)
Cheers,
---
Chris Aniszczyk | IBM Lotus | Eclipse Committer |
http://mea-bloga.blogspot.com | +1.860.839.2465
(Embedded image moved to file: pic22723.gif)Inactive hide details for David
M Williams---09/08/2007 04:26:09 AM---As philosophical as that sounds ... I
really am asking abDavid M Williams---09/08/2007 04:26:09 AM---As
philosophical as that sounds ... I really am asking about Java code. :) I
hope everyone knows
From: David M Williams/Raleigh/IBM@IBMUS
To: Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
Date: 09/08/2007 04:26 AM
Subject: [cross-project-issues-dev] Is everyone always visible?
As philosophical as that sounds ... I really am asking about Java code. :)
I hope everyone knows that package visibility outside it's bundle is
controlled by whether it is listed in the manifest.mf file.
Historically, we in WTP have followed the Eclipse Platform's policy of
always making every package visible to others, even if it was
not API and even if it really was never used any where else. But, now we in
WTP are considering to change our policy, to allow some
packages to be hidden, if they really are completely internal. We see this
potentially as an improved way to specify API's, along with
the usual correct use of x-internal, x-friend, etc. And also, we hope it
will motivate us to be more careful in our future code and designs to
better separate API from implementation.
So, two things came to mind:
1. What do other projects do?, and
2. Would it be useful to request each project in Ganymede to document their
policy?
To address both these questions, I've started
Ganymede_Policies_on_Package_Visibility as a place where Projects
can specify, and link to, their written policy on the matter.
So, if you would please, take a minute and fill in the tables listed there,
if you think it would be useful.
I created the table assuming each top level project would have one policy,
and that it would not differ from component to
component ... so, that's another thing ... let me know if that's an
incorrect assumption.
And, by all means, respond here if you have strong feelings about what a
project's policy should be.
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Attachment:
pic22723.gif
Description: GIF image
