Humberto S. N. dos Anjos wrote:
Just to add a little note: C# (I'm not sure about the other .NET languages)
deals with this issue by adding a new access modifier, internal, that makes
the class/method/field/property visible by all classes in the same assembly.
Could this behavior be emulated usi
> > Woudln't it be great if this was addressed at the language level?
> > Something like declaring "friend" packages or something like that.
> > Then the public modifier would basically fulfil the need for this kind
> > of "provides" or "exposes" declaration?
Just to add a little note: C# (I'm not
Peter Donald wrote:
What you are asking for here is new language extensions - effectively
an "assembly" or "jar" access specifier to go along with private,
protected, public and package access. This would be very useful -
particularly if different jars/assemblies were of higher importance in
ru
Dmitry Serebrennikov wrote:
Well, I can think of one thing I would like, some way for the
packages contained in a JAR file be able to inform the underlying
runtime not only its external dependencies, but also what it provides
(or what it exposes). Due to limitations in the Java
visibility/prot
Dalibor Topic wrote:
I think that would be pretty interesting, actually. One of the hard
challenges so far for me has been efficient support for 'profiles'[1]
in class libraries. What I have done in Kaffe is just a simple
mechanism to select the classes to build as part of a profile, but
that u
Richard S. Hall wrote:
Well, I can think of one thing I would like, some way for the packages
contained in a JAR file be able to inform the underlying runtime not
only its external dependencies, but also what it provides (or what it
exposes). Due to limitations in the Java visibility/protection
Well, I can think of one thing I would like, some way for the packages
contained in a JAR file be able to inform the underlying runtime not
only its external dependencies, but also what it provides (or what it
exposes). Due to limitations in the Java visibility/protection rules,
sometimes it i
Ricky Clarkson wrote:
I might have misunderstood this thread, but it seems to have some
relation to ivy, a dependency manager, see
http://www.jayasoft.fr/org/modules/ivy/overview.php
Yes, this IVY does sound like it is related, but not quite the same
thing. IVY sounds like a component repositor
Richard S. Hall wrote:
Peter Donald wrote:
Richard S. Hall wrote:
However, while I agree that Sun's implementation does provide some
modularity mechanisms, there seems to be two short comings:
1. The mechanisms themselves do not go far enough, they only provide
minimal capabilities.
True
I might have misunderstood this thread, but it seems to have some
relation to ivy, a dependency manager, see
http://www.jayasoft.fr/org/modules/ivy/overview.php
On 11/05/05, Richard S. Hall <[EMAIL PROTECTED]> wrote:
> Peter Donald wrote:
>
> > Richard S. Hall wrote:
> >
> >> However, while I agr
Peter Donald wrote:
Richard S. Hall wrote:
However, while I agree that Sun's implementation does provide some
modularity mechanisms, there seems to be two short comings:
1. The mechanisms themselves do not go far enough, they only provide
minimal capabilities.
True but what more do you ne
Richard S. Hall wrote:
However, while I agree that Sun's implementation does provide some
modularity mechanisms, there seems to be two short comings:
1. The mechanisms themselves do not go far enough, they only provide
minimal capabilities.
True but what more do you need at the runtime lev
Peter Donald wrote:
Java already has the ability to define "Optional Packages"/Extensions
that have similar features to OSGis bundles. For an overview check out
http://java.sun.com/j2se/1.3/docs/guide/extensions/versioning.html
You can declare the id/version/vendor for both the specification and
Hi,
Richard S. Hall wrote:
Just to raise the point about class library modularity again, since it
is related to this comment. Access [and assumptions about access] to
these types of classes is problematic when trying to implement
stronger Java modularity mechanisms, such as is the case with the
Tom Tromey wrote:
* com.sun.*. Those pesky java programmers often end up using unfree
APIs. I'm not sure what Harmony could do here; maybe pressure Sun
into make it much more difficult to do this?
Just to raise the point about class library modularity again, since it
is related to this comment
15 matches
Mail list logo
