On Mon, May 31, 2010 at 10:41, Jukka Zitting wrote:
> Basically, JCR-2640 is a case of two client-facing classes A and B
> both using shared internal state X. In the pre-JCR-2640 state class B
> would access X through package-private methods on A, which causes a
> tight coupling between A and B an
Hi,
On Mon, May 31, 2010 at 10:19 AM, Felix Meschberger wrote:
> On 31.05.2010 09:41, Jukka Zitting wrote:
>> On Mon, May 31, 2010 at 9:39 AM, Felix Meschberger
>> wrote:
>>> Let me add another word here: We must not drive the architecture of
>>> anything by the desire to avoid public method in
Hi,
On 31.05.2010 09:41, Jukka Zitting wrote:
> Hi,
>
> On Mon, May 31, 2010 at 9:39 AM, Felix Meschberger wrote:
>> Let me add another word here: We must not drive the architecture of
>> anything by the desire to avoid public method in internal classes.
>
> Did anyone suggest that? Seems to me
Hi,
On Mon, May 31, 2010 at 9:39 AM, Felix Meschberger wrote:
> Let me add another word here: We must not drive the architecture of
> anything by the desire to avoid public method in internal classes.
Did anyone suggest that? Seems to me like this whole thread is a big
misunderstanding.
BR,
Ju
Hi,
Let me add another word here: We must not drive the architecture of
anything by the desire to avoid public method in internal classes.
This will certainly lead to a bad and unmaintainable design because it
requires mixing classes in the same packages, which do not belong
together from an arch
Hi,
I'm sorry about the tone of my mails.
I just want to avoid that we run into the trap of making Jackrabbit 3
much too complicated and complex for the sake of being "modular". I
agree there shouldn't be many public implementation methods, but what
I don't want to do is add additional "glue" cla
hi,
On Fri, May 28, 2010 at 10:31, Thomas Müller wrote:
> Could those who suggest to get rid of the public implementation
> methods please submit a patch for the Jackrabbit 3 prototype? We can
> discuss from there.
I don't think that's necessary. if there are specific concerns about
the jackrabb
> well, i don't ;) i don't think that a proper oo design will
> necessarily be "overly complex".
Having everything convoluted just for the sake of avoiding public
implementation methods is completely unrelated to proper OO design. It
may be your understanding of proper OO design, but it's definite
On Fri, May 28, 2010 at 7:26 AM, KÖLL Claus wrote:
> Hi,
>
> I must agree with Thomas.
well, i don't ;) i don't think that a proper oo design will
necessarily be "overly complex".
cheers
stefan
> From my point of view public methods are no not so a problem.
> I would prefere public Methods over
Hi,
I must agree with Thomas.
>From my point of view public methods are no not so a problem.
I would prefere public Methods over complexity.
I think the use of Interfaces is the best way and if someone wants to use
internals
he will find a way ... (reflection ..)
Information and documentation wou
Hi,
I completely agree with Justin.
> Package-protected
I think it does have it's use, but for more complex products it's just
not enough. Somewhat related: in Java 1.0.2 you could use "private
protected": http://www.jguru.com/faq/view.jsp?EID=15576
> Security
For real security, you either nee
IIUC, this is about "package-protected" methods and constructors vs.
"public" ones.
Package-protected is in my opinion a bad/useless feature of Java,
since it just makes it hard to (internally) reuse classes from other
packages, while you can still circumvent the security given by it by
simply put
On 5/26/10 8:09 AM, Jukka Zitting wrote:
> Hi,
>
> Not sure how this became portrayed as a security problem. Not exposing
> implementation details through public API is a basic OO design
> principle.
>
> BR,
>
> Jukka Zitting
AFAICT, implementation details aren't exposed through the public API
e
On Wed, May 26, 2010 at 2:09 PM, Jukka Zitting wrote:
> Hi,
>
> Not sure how this became portrayed as a security problem. Not exposing
> implementation details through public API is a basic OO design
> principle.
i agree
cheers
stefan
>
> BR,
>
> Jukka Zitting
>
Hi,
If you think it's "proper OO" and such, could you please provide *one*
example of a larger project that does *not* have public implementation
methods?
Regards,
Thomas
> Not exposing implementation details through public API
> is a basic OO design principle.
> i think with a proper design and packaging, this will not be a problem.
I don't think you talk about the same thing here.
Proper OO is using interfaces, and not casting to implementation classes.
For exa
On Wed, May 26, 2010 at 2:09 PM, Jukka Zitting wrote:
> Hi,
>
> Not sure how this became portrayed as a security problem. Not exposing
> implementation details through public API is a basic OO design
> principle.
agreed. i think with a proper design and packaging, this will not be a problem.
rega
Hi,
Not sure how this became portrayed as a security problem. Not exposing
implementation details through public API is a basic OO design
principle.
BR,
Jukka Zitting
Do we want have public methods in the Jackrabbit 3 implementation that
can possibly be misused (if somebody casts to an implementation
class)? See the discussion at
https://issues.apache.org/jira/browse/JCR-2640
The advantage of not having public classes: people can't cast
implementation classes a
19 matches
Mail list logo
