as all java developers, i was learnt to use private where possible.
took me quite a while before i found there was a default access
specifier... but out of habit i still kept typing 'private'.
as all java developers lazyness wins in the end. so i started to use
the default access specifying
I guess, you use default (package-protected) if something is an internal
implementation detail shared within a particular package; but it needs
to be shared, otherwise, why expose it, even inside a package?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Default means package protected - other classes in the same package can
call those methods/fields, kind of the same as protected.
The slight difference from protected is that inheriting classes in other
packages cannot access the package protected methods/fields, only the
protected and public
| package; but it needs to be shared, otherwise, why expose it,
| even inside a package?
i know what it means. i ask the opposite question: why would i hide it
?
regards, tom.
| -Original Message-
| From: [EMAIL PROTECTED]
| [mailto:[EMAIL PROTECTED] On Behalf Of
| Tom Baeyens
|
Why shouldn't the implementation details of an accessor be hidden? It's
the general problem of maintainable code based on limiting the
interaction of components to supportable contracts vs allowing arbitrary
access to implementation details.
-Original Message-
From: [EMAIL PROTECTED]
Because then we have integration issues like relying on non-public API
of deployers, jms impl, etc. I can use everything I can see.
Tom Baeyens wrote:
| package; but it needs to be shared, otherwise, why expose it,
| even inside a package?
i know what it means. i ask the opposite question:
Encapsulation is an important OO principal. Only elements that are
intended for public consumption should be visible because they can be
changed less often (backwards compatibility).
-Original Message-
From: [EMAIL PROTECTED] [mailto:jboss-
[EMAIL PROTECTED] On Behalf Of Tom Baeyens
I have seen this build error in the past but have usually hacked past it
somehow.
I took new 4.0.x source this afternoon and can't seem to get past this
build error:
BUILD FAILED
/disk2/src/jboss_jan/jboss-4.0/jmx/build.xml:152:
/disk2/src/jboss_jan/jboss-4.0/thirdparty/xdoclet/lib not
I pulled the source and built without any issues.
Please verify that you have used the following checkout commands:
Cvs co -r Branch_4_0 jboss-4.0.x
Note that the module name is jboss-4.0.x and not jboss-4.0.
Ruel Loehr
JBoss QA
-Original Message-
From: [EMAIL PROTECTED]
I see that the security module has become dependent on the transaction
module to support the suspention of the tm in the
DatabaseServerLoginModule. The TransactionDemarcationSupport being used
for this can almost be put into the j2ee module as a utility class as
the majority of its dependencies
That did it for me, I was checking the branch into a local folder named
jboss-4.0, issuing cvs co -r Branch_4_0 jboss-4.0.x, did the trick.
Thank you,
Scott
On Wed, 2006-01-04 at 17:44 -0600, Ruel Loehr wrote:
I pulled the source and built without any issues.
Please verify that you have
11 matches
Mail list logo
