How to emulate C# 'internal' access modifier?

Discussion in 'Java' started by z-man, Oct 3, 2006.

  1. z-man

    z-man Guest

    Hi all

    Is there a way to emulate the (cross-package) assembly access modifier
    "internal" of C#?
    I need to let some classes *within* the same assembly (you know: the
    same JAR) to cooperate, despite belonging to distinct (yet omogeneous)
    packages, the way it's achieved in C# assemblies using the "internal"
    modifier.

    This is an example:

    package myProject.util;
    import myProject.core.*;
    public class Widget{
    ...

    Proof proof = new Proof();
    // Should call across the packages...
    proof.setTitle("You method work, don't you?");
    }

    package myProject.core;
    public class Proof
    {
    public String getTitle(){...}

    // This is problematic...
    void setTitle(String value){...}
    }

    Thank you for your advise!
    z-man, Oct 3, 2006
    #1
    1. Advertising

  2. z-man wrote:
    > Is there a way to emulate the (cross-package) assembly access modifier
    > "internal" of C#?
    > I need to let some classes *within* the same assembly (you know: the
    > same JAR) to cooperate, despite belonging to distinct (yet omogeneous)
    > packages, the way it's achieved in C# assemblies using the "internal"
    > modifier.


    Java does not support access control by deployment unit.

    Best workaround could be one jar = one package and
    default package visibility.

    Arne
    =?ISO-8859-1?Q?Arne_Vajh=F8j?=, Oct 3, 2006
    #2
    1. Advertising

  3. z-man

    z-man Guest

    On 10/03/2006 12:44 PM, Arne Vajhøj wrote:
    > z-man wrote:
    >> Is there a way to emulate the (cross-package) assembly access modifier
    >> "internal" of C#?
    >> I need to let some classes *within* the same assembly (you know: the
    >> same JAR) to cooperate, despite belonging to distinct (yet omogeneous)
    >> packages, the way it's achieved in C# assemblies using the "internal"
    >> modifier.

    >
    > Java does not support access control by deployment unit.
    >
    > Best workaround could be one jar = one package and
    > default package visibility.
    >
    > Arne


    Thank you, Arne!

    The lack of such a scope modifier is, anyway, a shame, IMHO...
    z-man, Oct 3, 2006
    #3
  4. Breaking access rules is questionable. Given that you want to do that
    is it true that you want to do it for a handful of methods or do you
    want to be able to access alot of methods?

    Say that setTitle is the only one you need:

    Can't you make:

    package myProject.core;
    public class BulletHole extends Proof {
    public void externalTitleSet(String tit) {
    validate(tit); // assuming setTitle is package private for a
    reason
    setTitle(tit);
    }

    }


    > The lack of such a scope modifier is, anyway, a shame, IMHO...


    The lack of such a scope modifier means that deliberate choices I made
    carefully are not ignored wholesale.

    Cheers,
    Opalinski

    http://www.geocities.com/opalpaweb/
    opalinski from opalpaweb, Oct 3, 2006
    #4
  5. z-man schrieb:
    > On 10/03/2006 12:44 PM, Arne Vajhøj wrote:
    >> z-man wrote:
    >>> Is there a way to emulate the (cross-package) assembly access modifier
    >>> "internal" of C#?
    >>> I need to let some classes *within* the same assembly (you know: the
    >>> same JAR) to cooperate, despite belonging to distinct (yet omogeneous)
    >>> packages, the way it's achieved in C# assemblies using the "internal"
    >>> modifier.

    ....
    >
    > The lack of such a scope modifier is, anyway, a shame, IMHO...


    No, it isn't. JARs aren't part of the Java language.

    Bye
    Michael
    Michael Rauscher, Oct 3, 2006
    #5
  6. z-man

    Ed Guest

    Michael Rauscher skrev:

    > z-man schrieb:
    > > On 10/03/2006 12:44 PM, Arne Vajhøj wrote:
    > >> z-man wrote:


    > ...
    > >
    > > The lack of such a scope modifier is, anyway, a shame, IMHO...

    >
    > No, it isn't. JARs aren't part of the Java language.
    >
    > Bye
    > Michael


    I think an access modifier between package-private and global would be
    a great thing for Java; so that a class could be visible to a specified
    group of packages and not to all others.

    I don't know C#, but this internal modifier comes damn close: it's just
    a pity that they link it to assmeblies (deployment units) rather than
    to plain-ol' namespaces. I'd agree that thinking in jars isn't too
    useful during design (though thinking in terms of deployment (on
    multiple processors) is often crucial).

    ..ed

    --
    www.EdmundKirwan.com - Home of The Fractal Class Composition.

    Download Fractality, free Java code analyzer:
    www.EdmundKirwan.com/servlet/fractal/frac-page130.html
    Ed, Oct 3, 2006
    #6
  7. Ed schrieb:
    > Michael Rauscher skrev:
    >
    >> z-man schrieb:
    >>> On 10/03/2006 12:44 PM, Arne Vajhøj wrote:
    >>>> z-man wrote:

    >
    >> ...
    >>> The lack of such a scope modifier is, anyway, a shame, IMHO...

    >> No, it isn't. JARs aren't part of the Java language.
    >>
    >> Bye
    >> Michael

    >
    > I think an access modifier between package-private and global would be
    > a great thing for Java; so that a class could be visible to a specified
    > group of packages and not to all others.


    Yep and I agree that it shouldn't depend on JARs or deployment units.

    It shouldn't be hard to introduce a namespace for grouping packages
    together. A "group" keyword in conjunction with an "internal" keyword
    should be enough. No need to have "physical" things like (JAR-)files,
    directories etc.

    package xyz group a.b.c;
    internal class A {}

    package abc group a.b.c;
    class B {
    A a;
    }

    Something like this would be a fine thing I think.

    Bye
    Michael
    Michael Rauscher, Oct 3, 2006
    #7
  8. z-man

    z-man Guest

    On 10/03/2006 06:40 PM, Michael Rauscher wrote:
    > Ed schrieb:
    >> Michael Rauscher skrev:
    >>
    >>> z-man schrieb:
    >>>> On 10/03/2006 12:44 PM, Arne Vajhøj wrote:
    >>>>> z-man wrote:

    >>
    >>> ...
    >>>> The lack of such a scope modifier is, anyway, a shame, IMHO...
    >>> No, it isn't. JARs aren't part of the Java language.
    >>>
    >>> Bye
    >>> Michael

    >>
    >> I think an access modifier between package-private and global would be
    >> a great thing for Java; so that a class could be visible to a specified
    >> group of packages and not to all others.

    >
    > Yep and I agree that it shouldn't depend on JARs or deployment units.
    >
    > It shouldn't be hard to introduce a namespace for grouping packages
    > together. A "group" keyword in conjunction with an "internal" keyword
    > should be enough. No need to have "physical" things like (JAR-)files,
    > directories etc.
    >
    > package xyz group a.b.c;
    > internal class A {}
    >
    > package abc group a.b.c;
    > class B {
    > A a;
    > }
    >
    > Something like this would be a fine thing I think.
    >
    > Bye
    > Michael


    Yeah, that's the whole point!
    I admit that my thought was simplistic, rough and inappropriate (I agree
    that deployment units, both JARs and assemblies, are inappropriate for
    language scoping).
    Anyway, I think that your insight about package grouping solves the
    whole problem with an elegant solution.

    Wouldn't it be nice to submit such a proposal to the Community Process?

    Best Regards.
    z-man, Oct 3, 2006
    #8
  9. z-man

    Ed Guest

    z-man skrev:

    > On 10/03/2006 06:40 PM, Michael Rauscher wrote:
    > > Ed schrieb:
    > >> Michael Rauscher skrev:
    > >>
    > >>> z-man schrieb:
    > >>>> On 10/03/2006 12:44 PM, Arne Vajhøj wrote:
    > >>>>> z-man wrote:
    > >>


    >
    > Yeah, that's the whole point!
    > I admit that my thought was simplistic, rough and inappropriate (I agree
    > that deployment units, both JARs and assemblies, are inappropriate for
    > language scoping).
    > Anyway, I think that your insight about package grouping solves the
    > whole problem with an elegant solution.
    >
    > Wouldn't it be nice to submit such a proposal to the Community Process?


    One of the Sun boys had a proposal, I only heard about it from Mister
    Hawtin the other day: I'm waiting to contact the Gilad when he next
    accepts comments on his blog:
    http://blogs.sun.com/gbracha/entry/developing_modules_for_development

    And as a matter of interest, I had almost the exact same idea as Mister
    Rauscher:
    http://www.edmundkirwan.com/servlet/fractal/frac-page56.html

    ..ed

    --

    www.EdmundKirwan.com - Home of The Fractal Class Composition
    Ed, Oct 3, 2006
    #9
  10. z-man

    Bill Medland Guest

    Michael Rauscher wrote:

    > Ed schrieb:
    >> Michael Rauscher skrev:
    >>
    >>> z-man schrieb:
    >>>> On 10/03/2006 12:44 PM, Arne Vajhøj wrote:
    >>>>> z-man wrote:

    >>
    >>> ...
    >>>> The lack of such a scope modifier is, anyway, a shame, IMHO...
    >>> No, it isn't. JARs aren't part of the Java language.
    >>>
    >>> Bye
    >>> Michael

    >>
    >> I think an access modifier between package-private and global would be
    >> a great thing for Java; so that a class could be visible to a specified
    >> group of packages and not to all others.

    >
    > Yep and I agree that it shouldn't depend on JARs or deployment units.
    >
    > It shouldn't be hard to introduce a namespace for grouping packages
    > together. A "group" keyword in conjunction with an "internal" keyword
    > should be enough. No need to have "physical" things like (JAR-)files,
    > directories etc.
    >
    > package xyz group a.b.c;
    > internal class A {}
    >
    > package abc group a.b.c;
    > class B {
    > A a;
    > }
    >
    > Something like this would be a fine thing I think.
    >
    > Bye
    > Michael

    But then isn't someone in a year or two going to ask for the next layer
    outside the group?
    Why not go with the equivalent of the C++ "friend" concept, with explicit
    specification of "non-normal" relationships.

    (However I do wonder what is going on in the design if two packages are
    having to work together so deeply that they have informal relationships
    that cannot be permitted for the general public)
    --
    Bill Medland
    Bill Medland, Oct 3, 2006
    #10
  11. Bill Medland schrieb:
    > Michael Rauscher wrote:
    >
    >> Ed schrieb:
    >>> Michael Rauscher skrev:
    >>>
    >>>> z-man schrieb:
    >>>>> On 10/03/2006 12:44 PM, Arne Vajhøj wrote:
    >>>>>> z-man wrote:
    >>>> ...
    >>>>> The lack of such a scope modifier is, anyway, a shame, IMHO...
    >>>> No, it isn't. JARs aren't part of the Java language.
    >>>>
    >>>> Bye
    >>>> Michael
    >>> I think an access modifier between package-private and global would be
    >>> a great thing for Java; so that a class could be visible to a specified
    >>> group of packages and not to all others.

    >> Yep and I agree that it shouldn't depend on JARs or deployment units.
    >>
    >> It shouldn't be hard to introduce a namespace for grouping packages
    >> together. A "group" keyword in conjunction with an "internal" keyword
    >> should be enough. No need to have "physical" things like (JAR-)files,
    >> directories etc.
    >>
    >> package xyz group a.b.c;
    >> internal class A {}
    >>
    >> package abc group a.b.c;
    >> class B {
    >> A a;
    >> }
    >>
    >> Something like this would be a fine thing I think.
    >>
    >> Bye
    >> Michael

    > But then isn't someone in a year or two going to ask for the next layer
    > outside the group?


    Example?

    One might declare a package to belong to more than to one group by comma
    separated lists, e.g.

    package abc group a.b.c, d.e.f;

    Also, I could image the usage of wildcards, e. g. to have a package to
    belong to immediate subgroups in namespace a.b one could write

    package abc group a.b.*;

    Or to have a package to belong to all subgroups in namespace a.b one
    could write:

    package abc group a.b.**;

    Why not?

    (I've to mention that I haven't really brainstormed on the "solutions" I
    gave, so this and the previous are just my short-term thoughts)

    > Why not go with the equivalent of the C++ "friend" concept, with explicit
    > specification of "non-normal" relationships.


    AFAIK C++'s "friend" concept exposes all fields/methods even if they're
    private.

    >
    > (However I do wonder what is going on in the design if two packages are
    > having to work together so deeply that they have informal relationships
    > that cannot be permitted for the general public)


    You can always declare anything to be public, that isn't the point. The
    key is information hiding.

    If there's some information (field/method) that should be available only
    to a few other packages, why should I allow the public to access it?

    Bye
    Michael
    Michael Rauscher, Oct 4, 2006
    #11
  12. Ed schrieb:
    > And as a matter of interest, I had almost the exact same idea as Mister
    > Rauscher:


    That's no suprise to me as it's seems to be really obvious ;)

    Bye
    Michael
    Michael Rauscher, Oct 4, 2006
    #12
  13. z-man

    Bill Medland Guest

    Michael Rauscher wrote:

    > Bill Medland schrieb:
    >> Michael Rauscher wrote:
    >>
    >>> Ed schrieb:
    >>>> Michael Rauscher skrev:
    >>>>
    >>>>> z-man schrieb:
    >>>>>> On 10/03/2006 12:44 PM, Arne Vajhøj wrote:
    >>>>>>> z-man wrote:
    >>>>> ...
    >>>>>> The lack of such a scope modifier is, anyway, a shame, IMHO...
    >>>>> No, it isn't. JARs aren't part of the Java language.
    >>>>>
    >>>>> Bye
    >>>>> Michael
    >>>> I think an access modifier between package-private and global would be
    >>>> a great thing for Java; so that a class could be visible to a specified
    >>>> group of packages and not to all others.
    >>> Yep and I agree that it shouldn't depend on JARs or deployment units.
    >>>
    >>> It shouldn't be hard to introduce a namespace for grouping packages
    >>> together. A "group" keyword in conjunction with an "internal" keyword
    >>> should be enough. No need to have "physical" things like (JAR-)files,
    >>> directories etc.
    >>>


    >> Why not go with the equivalent of the C++ "friend" concept, with explicit
    >> specification of "non-normal" relationships.

    >
    > AFAIK C++'s "friend" concept exposes all fields/methods even if they're
    > private.


    I vaguely remember being able to do it at the method level (and a quick look
    at Stroustrup suggests I am not going out of my mind)

    >
    >>
    >> (However I do wonder what is going on in the design if two packages are
    >> having to work together so deeply that they have informal relationships
    >> that cannot be permitted for the general public)

    >
    > You can always declare anything to be public, that isn't the point. The
    > key is information hiding.


    from whom?

    >
    > If there's some information (field/method) that should be available only
    > to a few other packages, why should I allow the public to access it?


    Why should information be made available to other packages but not to the
    public? If the classes are tightly enough related to warrant access to
    each other why are they not in the same package?

    >
    > Bye
    > Michael


    --
    Bill Medland
    Bill Medland, Oct 4, 2006
    #13
  14. z-man wrote:
    > The lack of such a scope modifier is, anyway, a shame, IMHO...


    A Java jar file is not a good unit to base
    accessibility on, because classes can be added to
    it later.

    A .NET DLL is (as far as I know) immutable.

    Arne
    =?ISO-8859-1?Q?Arne_Vajh=F8j?=, Oct 4, 2006
    #14
  15. Bill Medland schrieb:
    >>> Why not go with the equivalent of the C++ "friend" concept, with explicit
    >>> specification of "non-normal" relationships.

    >> AFAIK C++'s "friend" concept exposes all fields/methods even if they're
    >> private.

    >
    > I vaguely remember being able to do it at the method level (and a quick look
    > at Stroustrup suggests I am not going out of my mind)


    How can one declare which class may access this method?

    >
    >>> (However I do wonder what is going on in the design if two packages are
    >>> having to work together so deeply that they have informal relationships
    >>> that cannot be permitted for the general public)

    >> You can always declare anything to be public, that isn't the point. The
    >> key is information hiding.

    >
    > from whom?


    From other parts of the system, of course. Do you make all of your
    members public or do you declare your instance variables private? From
    whom do you want to hide them?

    >
    >> If there's some information (field/method) that should be available only
    >> to a few other packages, why should I allow the public to access it?

    >
    > Why should information be made available to other packages but not to the
    > public? If the classes are tightly enough related to warrant access to
    > each other why are they not in the same package?


    Because relationships aren't limited to only two classes?

    Bye
    Michael
    Michael Rauscher, Oct 4, 2006
    #15
  16. z-man

    Ed Guest

    Ed, Oct 4, 2006
    #16
  17. z-man

    Bill Medland Guest

    Michael Rauscher wrote:

    > Bill Medland schrieb:
    >>>> Why not go with the equivalent of the C++ "friend" concept, with
    >>>> explicit specification of "non-normal" relationships.
    >>> AFAIK C++'s "friend" concept exposes all fields/methods even if they're
    >>> private.

    >>
    >> I vaguely remember being able to do it at the method level (and a quick
    >> look at Stroustrup suggests I am not going out of my mind)

    >
    > How can one declare which class may access this method?


    OK. I apologise. I got it the wrong way around. You are right; it exposes
    the whole class to a specified friend. However it is to a specified
    friend, which is the bit that I believe is important. (And we could even
    suggest a further restriction that friendliness could be attached to fields
    or methods of a class rather than the whole class).

    >
    >>
    >>>> (However I do wonder what is going on in the design if two packages are
    >>>> having to work together so deeply that they have informal relationships
    >>>> that cannot be permitted for the general public)
    >>> You can always declare anything to be public, that isn't the point. The
    >>> key is information hiding.

    >>
    >> from whom?

    >
    > From other parts of the system, of course. Do you make all of your
    > members public or do you declare your instance variables private? From
    > whom do you want to hide them?

    Some things you want to hide from the general public; some things you even
    want to hide from your colleagues. Some things are exported capability of
    your package, others are shared among the members of the package and others
    are restricted to the class. See below.
    >
    >>
    >>> If there's some information (field/method) that should be available only
    >>> to a few other packages, why should I allow the public to access it?

    >>
    >> Why should information be made available to other packages but not to the
    >> public? If the classes are tightly enough related to warrant access to
    >> each other why are they not in the same package?

    >
    > Because relationships aren't limited to only two classes?


    Huh? I never said they were. However if there is a relationship between two
    members of two distinct packages that is not permitted between the general
    public and the member then I suggest the packaging is wrong.

    >
    > Bye
    > Michael


    --
    Bill Medland
    Bill Medland, Oct 4, 2006
    #17
  18. z-man

    z-man Guest

    On 10/04/2006 07:04 PM, Bill Medland wrote:
    > Michael Rauscher wrote:
    >
    >> Bill Medland schrieb:


    [snip]

    >>>>> (However I do wonder what is going on in the design if two packages are
    >>>>> having to work together so deeply that they have informal relationships
    >>>>> that cannot be permitted for the general public)
    >>>> You can always declare anything to be public, that isn't the point. The
    >>>> key is information hiding.
    >>> from whom?

    >> From other parts of the system, of course. Do you make all of your
    >> members public or do you declare your instance variables private? From
    >> whom do you want to hide them?

    > Some things you want to hide from the general public; some things you even
    > want to hide from your colleagues. Some things are exported capability of
    > your package, others are shared among the members of the package and others
    > are restricted to the class. See below.
    >>>> If there's some information (field/method) that should be available only
    >>>> to a few other packages, why should I allow the public to access it?
    >>> Why should information be made available to other packages but not to the
    >>> public? If the classes are tightly enough related to warrant access to
    >>> each other why are they not in the same package?

    >> Because relationships aren't limited to only two classes?

    >
    > Huh? I never said they were. However if there is a relationship between two
    > members of two distinct packages that is not permitted between the general
    > public and the member then I suggest the packaging is wrong.


    If you limit your reasoning to the established orthodox language
    semantics from mama Sun, then you're undoubtedly right to say so.

    But considering that, as Ed suggests [1], when projects grow there could
    be some necessity to unclutter single bloated packages splitting them
    into omogeneous "sub"packages though keeping tight connections among
    them. I think that's just a matter of scope granularity and there's no
    scandal to request a mid-level (elegant) expansion.

    [1] http://www.edmundkirwan.com/servlet/fractal/frac-page54.html
    z-man, Oct 5, 2006
    #18
  19. z-man

    z-man Guest

    On 10/04/2006 07:04 PM, Bill Medland wrote:
    > Michael Rauscher wrote:
    >>>>> (However I do wonder what is going on in the design if two packages are
    >>>>> having to work together so deeply that they have informal relationships
    >>>>> that cannot be permitted for the general public)
    >>>> You can always declare anything to be public, that isn't the point. The
    >>>> key is information hiding.
    >>> from whom?

    >> From other parts of the system, of course. Do you make all of your
    >> members public or do you declare your instance variables private? From
    >> whom do you want to hide them?

    > Some things you want to hide from the general public; some things you even
    > want to hide from your colleagues. Some things are exported capability of
    > your package, others are shared among the members of the package and others
    > are restricted to the class. See below.
    >>>> If there's some information (field/method) that should be available only
    >>>> to a few other packages, why should I allow the public to access it?
    >>> Why should information be made available to other packages but not to the
    >>> public? If the classes are tightly enough related to warrant access to
    >>> each other why are they not in the same package?

    >> Because relationships aren't limited to only two classes?

    >
    > Huh? I never said they were. However if there is a relationship between two
    > members of two distinct packages that is not permitted between the general
    > public and the member then I suggest the packaging is wrong.


    Real-world examples from authoritative projects where just a weak
    comment enforces the proper access to public (though semantically
    internal) class members (what an awkward workaround! -- are all THEY
    stupid or are YOU wrong?):

    org.apache.ojb.broker.Identity constructors [1]
    org.apache.xml.utils.StringToStringTable [2]
    iwork.state.ReflectionLocalVariable [3]
    hp.opencall.media.sms.tl.Parameter [4]
    com.gemstone.persistence.collections.CuHashMap [5]
    com.saxonica.schema.SchemaTypeImpl [6]
    org.eclipse.tptp.platform.analysis.core.history.AnalysisHistory [7]
    ....

    [1] http://db.apache.org/ojb/api/org/apache/ojb/broker/Identity.html
    [2]
    http://xml.apache.org/xalan-j/apidocs/org/apache/xml/utils/StringToStringTable.html
    [3]
    http://iwork.stanford.edu/docs/javadoc/iwork/state/ReflectionLocalVariable.html
    [4]
    http://techsolutions.hp.com/en/6154/hp/opencall/media/sms/tl/Parameter.html
    [5]
    http://www.facetsodb.com/downloads/...mstone/persistence/collections/CuHashMap.html
    [6]
    http://www.saxonica.com/documentation/javadoc/com/saxonica/schema/SchemaTypeImpl.html
    [7]
    http://download.eclipse.org/tptp/4....rm/analysis/core/history/AnalysisHistory.html
    z-man, Oct 5, 2006
    #19
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mark Kamoski
    Replies:
    1
    Views:
    2,743
    Herfried K. Wagner
    Jul 23, 2003
  2. =?Utf-8?B?YWppdA==?=

    access modifier for webcontrols

    =?Utf-8?B?YWppdA==?=, Nov 17, 2004, in forum: ASP .Net
    Replies:
    1
    Views:
    370
    Eliahu
    Nov 17, 2004
  3. Skinny Guy
    Replies:
    0
    Views:
    903
    Skinny Guy
    Jun 10, 2004
  4. dost
    Replies:
    5
    Views:
    1,159
    Phlip
    Apr 28, 2006
  5. Ron

    Web Services - Internal Access Modifier

    Ron, Jul 14, 2003, in forum: ASP .Net Web Services
    Replies:
    0
    Views:
    132
Loading...

Share This Page