[jsr294-modularity-eg] Module boundaries
Peter Kriens
peter.kriens at aqute.biz
Mon Feb 16 08:00:23 EST 2009
There are two possibilities: The doc I sent is missing a requirement,
in which case I think you should post the requirement and not a
solution to an unstated requirement. Or you just provide an
alternative solution to a listed requirement that might be better or
worse, in that case I think an analysis starting with the document is
needed to show its shortcoming.
Anyway, you seem to be posting on the observer list. I think that if
you want to participate you should be part of the EG, please contact
Alex. I am not sure how the IP flow works with suggestions from the
observer list?
Kind regards,
Peter Kriens
On 16 feb 2009, at 11:37, Christopher Brind wrote:
> The tables look a bit rubbish in plain text, so for clarity:
>
> The class visibility keywords we have right now are:
> - public (class:yes, package:yes, subclass:yes, world:yes)
> - protected (class:yes, package:yes, subclass:yes, world:no)
> - no modifier (class:yes, package:yes, subclass:no, world:no)
> - private (class:yes, package:no, subclass:no, world:no)
>
> What I am proposing is:
> - public (class:yes, package:yes, parent package:yes, subclass:yes,
> world:yes)
> - protected (class:yes, package:yes, parent package:no, subclass:yes,
> world:no)
> - internal (class:yes, package:yes, parent package:yes, subclass:no,
> world:no)
> - no modifier (class:yes, package:yes, parent package:no, subclass:no,
> world:no)
> - private (class:yes, package:no, parent package:no, subclass:no,
> world:no)
>
> I hope that is clearer for those with plain text email readers.
>
> Regards,
> Chris
>
>
>
> 2009/2/16 Christopher Brind <brindy at brindy.org.uk>
>
>> Hi Peter,
>>
>> Thanks for the response.
>>
>> However, even in your simple example, it raises the question why
>>> uk/org/brindy/app/ can look down into uk/org/brindy/app/geo? This
>>> seems to
>>> be the opposite of modularity? How does the scoping work with
>>> multiple
>>> containers?
>>
>>
>> 1) It solves the 'problem' defined by JSR 294, which I think we have
>> established is probably 'out of date'.
>> 2) My solution isn't necessarily a proposal of 'modularity', see #1.
>> 3) I'm used to structuring applications (and OSGi bundles) in this
>> way.
>> Utility classes tend to be public anyway, so internal doesn't
>> affect those.
>> 4) This is a very minimal change to Java as far as I can see, this
>> is taken
>> from my blog where I was 'thinking out loud' about it a couple of
>> weeks ago,
>> though I spotted a mistake and have fixed it here:
>>
>> The class visibility keywords we have right now are:
>>
>> *Access Levels* Modifier Class Package Subclass World public Y Y Y Y
>> protected Y Y Y N *no modifier* Y Y N N private Y N N N Source:
>> http://java.sun.com/docs/books/tutorial/java/javaOO/
>> accesscontrol.html
>>
>> So add an extra column and row to that table:
>> *Access Levels* Modifier Class Package Subclass Parent
>> Package
>> World public Y Y Y Y
>> Y protected Y Y Y N
>> N *internal
>> **Y
>> **Y
>> **N
>> **Y
>> **N
>> * *no modifier* Y Y N N
>> N private Y N N N
>> N
>> To me, internal is very similar to 'no modifier' (commonly known as
>> package
>> private) except that classes in the parent package can access
>> them. This
>> means I no longer need to make classes in my child package public
>> in order
>> to access, which means that I am no longer (to quote the JSR)
>> "forced to
>> declare elements of the program that are needed by other subparts
>> of the
>> implementation as public".
>>
>> That all said, it has been established a lot has changed since the
>> original
>> JSR 294 proposal. Perhaps what I am proposing is something new, or
>> perhaps
>> JSR 294 needs to be rejected and redefined so that everyone is
>> clear on what
>> it's actual goals are? Personally, I don't think JSR 294 is
>> talking about
>> modularity, but that doesn't seem to be the view of the Expert
>> Group. =)
>>
>> Regards,
>> Chris
>>
>>
>>
>> 2009/2/16 Peter Kriens <peter.kriens at aqute.biz>
>>
>> Well, I suggest you write down the rules for you internal
>> keyword ... I
>>> think what you want is very close to what the current proposal
>>> form a
>>> programmer's point of view, you only need one more file to mark
>>> your module
>>> boundary.
>>>
>>> .
>>> module-info : module Geo;
>>>
>>> uk/org/brindy/app/geo
>>> Geo: module class Geo { ... new GeoSupport() ... }
>>> GeoSupport: class GeoSuport { ... }
>>>
>>> uk/org/brindy/app:
>>> Main: public class Main { ... new Geo() ... }
>>>
>>>
>>> However, even in your simple example, it raises the question why
>>> uk/org/brindy/app/ can look down into uk/org/brindy/app/geo? This
>>> seems to
>>> be the opposite of modularity? How does the scoping work with
>>> multiple
>>> containers? How do module systems interact with this? You probably
>>> can write
>>> down a proposal more terse than I did (I know, I have a tendency
>>> to be
>>> verbose) but I find it a surprisingly complex area. The devil is
>>> in the
>>> details.
>>>
>>> About masquerading. Without security you cannot prevent this, and
>>> actually
>>> IBM raised an explicit requirement for modules that cross JAR
>>> boundaries so
>>> they can wrap a big system in multiple JARs. Preventing
>>> masquerading, is an
>>> area where module systems can shine with signing and other security
>>> mechanisms, and these aspects are out of scope for 294. The way I
>>> see it is
>>> that the compiler should have no module system specific knowledge,
>>> it should
>>> provide a language based model that can be leveraged by module
>>> systems that
>>> provide additional features.
>>>
>>> The compile time and deploy time model are different in Java. This
>>> has its
>>> disadvantages because you can get different behavior. However, a
>>> key goal of
>>> OSGi has always been reusability. Reusability implies that you
>>> have little
>>> control over your deployment, so you need to write your components
>>> with as
>>> little assumptions as possible and be explicit about your
>>> dependencies. With
>>> a standard compile model but allowing runtime deployment to
>>> provide a
>>> suitable environment for a specific purpose, I think you increase
>>> reusability. Constraining them to be exactly the same will do the
>>> opposite
>>> imho.
>>>
>>> Kind regards,
>>>
>>> Peter Kriens
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On 14 feb 2009, at 01:37, Christopher Brind wrote:
>>>
>>> Hi Richard,
>>>>
>>>> So you are saying that masquerading is acceptable and JSR 294 is
>>>> not
>>>> going
>>>> to even try to prevent it?
>>>>
>>>> If that is the case, why is what is being proposed/discussed for
>>>> JSR 294
>>>> so
>>>> complicated?
>>>>
>>>> For instance, a simpler solution would be to create a new type
>>>> modifier
>>>> which bridges the gap between public and package private,
>>>> allowing types
>>>> with the modifier to be accessed by classes in the parent package
>>>> only.
>>>>
>>>> e.g. for want of a better name lets call it 'internal' (I think I
>>>> read
>>>> internal suggested before, but can't think of a better name, sorry)
>>>>
>>>> uk/org/brindy/app/geo
>>>> Geo: internal class Geo { ... new GeoSupport() ... }
>>>> GeoSupport: class GeoSuport { ... }
>>>>
>>>> uk/org/brindy/app:
>>>> Main: public class Main { ... new Geo() ... }
>>>>
>>>>
>>>> That results in minimal changes to Java, is easy to understand
>>>> and seems
>>>> to
>>>> 'fix' the problem described in the original JSR 294.
>>>>
>>>> Regards,
>>>> Chris
>>>>
>>>>
>>>> 2009/2/13 Richard S. Hall <heavy at ungoverned.org>
>>>>
>>>> Isn't such masquerading possible in approaches that allow separate
>>>>> compilation? I am not sure this is an issue. For example,
>>>>> nothing stops
>>>>> me
>>>>> from creating a class in someone else's package and adding it to
>>>>> a JAR
>>>>> file
>>>>> to get package-private access.
>>>>>
>>>>> -> richard
>>>>>
>>>>> Christopher Brind wrote:
>>>>>
>>>>> Hi,
>>>>>>
>>>>>> I have to admit that I read the straw-man with a mixture of both
>>>>>> excitement and trepidation. :)
>>>>>>
>>>>>> The first question that springs to mind is, what is to stop me
>>>>>> from
>>>>>> contributing to the 'Felix' module example in a way that then
>>>>>> exposes
>>>>>> some
>>>>>> of the module private functionality, e.g. via a delegate?
>>>>>>
>>>>>> So, for example, let's say that I have downloaded a JAR which
>>>>>> contains
>>>>>> the
>>>>>> Felix classes from the example in the straw-man. I could
>>>>>> compile the
>>>>>> following in order to contribute to the Felix module (source tree
>>>>>> example
>>>>>> like in the straw-man):
>>>>>> module-info: module Felix;
>>>>>>
>>>>>> org/apache/felix/framework
>>>>>> PublicFelix: package org.apache.felix.framework;
>>>>>> public class PublicFelix { ... }
>>>>>>
>>>>>> I then repackage the downloaded JAR adding the PublicFelix
>>>>>> class. The
>>>>>> result is that because I told the compiler that the PublicFelix
>>>>>> class
>>>>>> is in
>>>>>> the Felix module, it can access the Felix class. The code in the
>>>>>> PublicFelix class is basically a delegate for the Felix class,
>>>>>> but
>>>>>> since the
>>>>>> PublicFelix class is accessible from anywhere the ultimate
>>>>>> result is
>>>>>> that
>>>>>> the module system has been circumvented.
>>>>>>
>>>>>> The implication of this seems to be that if you want to prevent
>>>>>> this
>>>>>> from
>>>>>> happening then you will have to provide the binaries in a
>>>>>> format which
>>>>>> prevents tampering. For instance, if the original Felix module
>>>>>> was
>>>>>> compiled
>>>>>> and then bundled as a signed JAR I could not contribute to the
>>>>>> module
>>>>>> as
>>>>>> described above as that will break the JAR's signature.
>>>>>> However, the
>>>>>> proposal says that types in a module can be loaded from multiple
>>>>>> containers,
>>>>>> e.g. URL Class Loader. How do I protect my module's internal
>>>>>> implementation
>>>>>> in this case?
>>>>>>
>>>>>> Regards,
>>>>>> Chris
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2009/2/13 Peter Kriens <peter.kriens at aqute.biz <mailto:
>>>>>> peter.kriens at aqute.biz>>
>>>>>>
>>>>>>
>>>>>> Enclosed find the first strawman proposal for nested modules.
>>>>>> This
>>>>>> was not easy :-( but I tried hard to make it as clear as
>>>>>> possible.
>>>>>> I guess sending docs will probably not work or create too much
>>>>>> CO2, so here is the link: http://www.aqute.biz/JSR294/HomePage.
>>>>>> Enjoy.
>>>>>>
>>>>>> Kind regards,
>>>>>>
>>>>>> Peter Kriens
>>>>>>
>>>>>>
>>>>>> On 4 feb 2009, at 10:32, Alex Buckley wrote:
>>>>>>
>>>>>> Yes, setting module membership at runtime effectively
>>>>>> simulates 'internal', where the .NET assembly-build operation
>>>>>> is done lazily.
>>>>>>
>>>>>> Module nesting sounds interesting. Could you please send some
>>>>>> source code which exhibits how it would impact module-private
>>>>>> accessibility?
>>>>>>
>>>>>> We can certainly have a phone call. I am travelling
>>>>>> internationally for the next week and, in practice, will not
>>>>>> be back in the office until Tuesday 17th.
>>>>>>
>>>>>> EG members, please indicate when on 17-20th February you
>>>>>> could
>>>>>> be available. Good times would be 9am West Coast, 12pm East
>>>>>> Coast, 6pm France.
>>>>>>
>>>>>> Alex
>>>>>>
>>>>>> Peter Kriens wrote:
>>>>>>
>>>>>> Ok, so you allow a module boundary to be set in runtime,
>>>>>> this will make the module keyword in unbound modules
>>>>>> reflect the semantics of the .NET 'internal' concept? I
>>>>>> agree we should then have a discussion later about how
>>>>>> the
>>>>>> compiler gets the unbound module boundaries.(Do we have
>>>>>> an
>>>>>> action list for these things?)
>>>>>> If I look at software projects than there will be a
>>>>>> tendency to put a set of related packages into a bound
>>>>>> module, where a number of these bound modules are
>>>>>> packaged
>>>>>> in a JAR (the unbound module). This seems to scream for
>>>>>> nesting of bound modules?
>>>>>> VM -> unbound module -> bound module +-> package ->
>>>>>> type -+
>>>>>> ^ |
>>>>>> ^ |
>>>>>> +--------------+
>>>>>> +--------+
>>>>>> And, can we please, pretty please, have a kick-off phone
>>>>>> conference now we're a group starting to work on this?
>>>>>> Kind regards,
>>>>>> Peter Kriens
>>>>>> On 3 feb 2009, at 01:47, Alex Buckley wrote:
>>>>>>
>>>>>> .NET is not Java.
>>>>>>
>>>>>> Compiled types in .NET live in non-executable modules
>>>>>> (.netmodule files). To be executed, modules must be
>>>>>> packaged into assemblies (.dll/.exe files).
>>>>>> This packaging makes "internal" a bit tricky.
>>>>>> "internal" is specified as "accessible from the same
>>>>>> program", where a program is merely a bunch of source
>>>>>> files. A C# compiler must take it on trust that the
>>>>>> .netmodule which accesses an "internal" artifact will
>>>>>> be packaged in the same assembly as the .netmodule
>>>>>> which declares the artifact.
>>>>>>
>>>>>> This is not unreasonable, since .netmodules MUST be
>>>>>> packaged. But if packaged "wrongly", code accessing
>>>>>> an
>>>>>> "internal" artifact which the compiler promised was
>>>>>> accessible will fail at runtime. You do not want
>>>>>> language features to behave like this. There is
>>>>>> effectively a hole in the C# spec caused by the
>>>>>> greater CLI spec stratifying loadable code into
>>>>>> non-executable and executable.
>>>>>>
>>>>>> Java is different. A JVM does not require classfiles
>>>>>> to be packaged in any way before executing them. Nor
>>>>>> does the reference implementation of a Java compiler
>>>>>> require classfiles to be packaged before compiling
>>>>>> against them. These things are not going to change.
>>>>>> Since module-private accessibility is a language and
>>>>>> VM construct, it cannot depend on the future
>>>>>> packaging
>>>>>> of code still being compiled or compiled against.
>>>>>>
>>>>>> (What it can depend on is an API consulted by a Java
>>>>>> compiler to discover whether module M version X and
>>>>>> module M version Y have "equal" versions. The API
>>>>>> implementation would be honor-bound to give
>>>>>> consistent
>>>>>> answers, similar to classloaders. We'll get to that
>>>>>> API soon, I hope.)
>>>>>>
>>>>>> This boils down to saying the module-private
>>>>>> accessibility and module membership go hand-in-hand
>>>>>> for me. In any case, the first thing a programmer
>>>>>> will
>>>>>> ask when seeing a module-private member is: "What
>>>>>> module does this member belong to?". The answer
>>>>>> should
>>>>>> NOT be "it depends on a compiler flag or invocation
>>>>>> of
>>>>>> jar".
>>>>>>
>>>>>> I will shortly send a Java language grammar and
>>>>>> classfile format which reflect these views.
>>>>>>
>>>>>> Now, I know this issue is not going to go away. I
>>>>>> therefore propose that IN ADDITION to encoding module
>>>>>> membership in source, it should be possible for the
>>>>>> host system to determine module membership. If you
>>>>>> REALLY want the answer above to be "it depends on a
>>>>>> compiler flag or invocation of jar", you can do that.
>>>>>> But a Java compiler/VM must defer to the membership
>>>>>> in
>>>>>> a source/class file if it exists.
>>>>>>
>>>>>> Is that enough of a weakening of my requirements #1
>>>>>> and #2?
>>>>>>
>>>>>> Alex
>>>>>>
>>>>>> Peter Kriens wrote:
>>>>>>
>>>>>> Hmm. .NET shows that you do not have to know all
>>>>>> the module boundaries during compilation.
>>>>>> 'internal' indicates inside the assembly and the
>>>>>> source assembly is clearly not known during
>>>>>> compilation. This concept looks attractively
>>>>>> simple and is in line with common practice.
>>>>>> For 294, during compilation, the JAR files and
>>>>>> project source can easily be used inside the
>>>>>> compiler for the scope. During runtime, the
>>>>>> module
>>>>>> system can set this boundary.
>>>>>> However, I also like a module concept that is
>>>>>> defined in the language. This will be more
>>>>>> complex
>>>>>> (and probably should be hierarchical) but it
>>>>>> should be not attempt to define the deployment
>>>>>> artifact nor dependencies. That is, it should be
>>>>>> more like namespaces.
>>>>>> Kind regards,
>>>>>> Peter Kriens
>>>>>> On 28 jan 2009, at 03:56, Alex Buckley wrote:
>>>>>>
>>>>>> I am happy to discuss module-private
>>>>>> accessibility first, in that it addresses the
>>>>>> limitations of packages on which we all
>>>>>> agree.
>>>>>>
>>>>>> The issue we cannot ignore is that to check
>>>>>> module-private accessibility at compile-time
>>>>>> means knowing the modules to which the
>>>>>> requesting and requested types belong. If I
>>>>>> invoke:
>>>>>>
>>>>>> javac Foo.java Bar.java
>>>>>>
>>>>>> where Foo.java refers to Bar, then a compiler
>>>>>> must be able to compute at least the module
>>>>>> name to which Foo belongs as Foo is compiled,
>>>>>> if Bar is found to be module-private as it is
>>>>>> compiled. There are no deployment artifacts
>>>>>> around yet. It shouldn't be a surprise that
>>>>>> Foo.class and Bar.class are subsequently
>>>>>> emitted to encode their module membership.
>>>>>>
>>>>>> So with module accessibility comes module
>>>>>> membership. Module dependencies are a quite
>>>>>> different topic which we'll get to soon
>>>>>> enough, and they are the place where
>>>>>> minimizing new concepts is essential.
>>>>>>
>>>>>> Alex
>>>>>>
>>>>>> Peter Kriens wrote:
>>>>>>
>>>>>> I think it would make sense to work from
>>>>>> first principles
>>>>>> 1. What problem are we trying to solve?
>>>>>> 2. How do we scope this problem to an
>>>>>> acceptable area for all?
>>>>>> 3. What requirements should the solution
>>>>>> fulfill
>>>>>> I would like to have a short discussion
>>>>>> about the problem so we are sure we are
>>>>>> all on the same page. I can start off
>>>>>> with
>>>>>> the problem I think we are trying to
>>>>>> solve.
>>>>>> Modularity
>>>>>> Modularity is the art of encapsulation
>>>>>> and
>>>>>> hiding. A module limits the amount of
>>>>>> information outside its boundaries. This
>>>>>> reduces the overall complexity of a
>>>>>> system
>>>>>> because it becomes possible to reason
>>>>>> (and
>>>>>> change) locally about a module instead of
>>>>>> understanding the whole system, and it
>>>>>> provides a local namespace that is easier
>>>>>> to work with for humans than a global
>>>>>> namespace.
>>>>>> Java provides modularity in many
>>>>>> places. A
>>>>>> type encapsulates its fields and methods
>>>>>> and selectively exposes them to other
>>>>>> types with the access modifies: private,
>>>>>> protected and public. A package
>>>>>> encapsulates a number of types and
>>>>>> resources. And last, but not least, the
>>>>>> class loader provides a class space that
>>>>>> can be distinct from other class spaces.
>>>>>> The modularity that is enabled with class
>>>>>> loaders has been exploited by many.
>>>>>> However, the Java Language has little to
>>>>>> say about class loaders; it is outside
>>>>>> the
>>>>>> scope of the language.
>>>>>> So what problem do we need to solve,
>>>>>> seeing that Java provides already so many
>>>>>> forms of modularity? There is a sense in
>>>>>> the community that packages are too small
>>>>>> for modules. Though the package names
>>>>>> hint
>>>>>> at a hierarchy (and this is how they are
>>>>>> found in a file system), this hierarchy
>>>>>> does not provide a preferential treatment
>>>>>> for children. Many programs consist of
>>>>>> hundreds of packages. However, except for
>>>>>> the limited package concept, the
>>>>>> programmer cannot indicate that the
>>>>>> visibility of an artifact should be
>>>>>> limited to the program, or part of the
>>>>>> program.
>>>>>> A large number of delivery formats have
>>>>>> been created over the years, most of the
>>>>>> based on the JAR format (which is also
>>>>>> not
>>>>>> a part of the language): WAR, EAR, OSGi
>>>>>> bundles, midlets, xlets, and likely many
>>>>>> more proprietary formats. Usually, the
>>>>>> modularity of these modules is based on a
>>>>>> rather simplistic hierarchical class
>>>>>> loader model. That is, all classes in
>>>>>> ancestors are visible, but not any
>>>>>> siblings or their children. The language
>>>>>> is moot on the point of this type of
>>>>>> encapsulation.
>>>>>> Delivery modules contain types that
>>>>>> depend
>>>>>> on types in other delivery modules. There
>>>>>> is no uniformly agreed Java standard to
>>>>>> model these dependencies. During build
>>>>>> time, the compiler is provided with a
>>>>>> linear list of JARs and the compiler
>>>>>> picks
>>>>>> the first type that matches a name. Only
>>>>>> the name is encoded in the class file,
>>>>>> not
>>>>>> the originating delivery module. During
>>>>>> runtime, the same process is used to find
>>>>>> classes, albeit in a hierarchical class
>>>>>> loader model. This has all so far been
>>>>>> outside the Java Language.
>>>>>> It is crucial that we distinguish the
>>>>>> language/logic modularity and the
>>>>>> modularity based on the deployment
>>>>>> artifact. Interestingly, in my
>>>>>> understanding, .NET makes such a
>>>>>> distinction between the modularity of a
>>>>>> delivery unit (called an assembly) and
>>>>>> the
>>>>>> finer grained modularity inside a
>>>>>> delivery
>>>>>> unit, represented by namespaces. The
>>>>>> "internal" keyword indicates that the
>>>>>> artifact is visible only inside an
>>>>>> assembly and the "namespace" keyword
>>>>>> provides a hierarchical namespace.
>>>>>> Therefore, one can identify two problems
>>>>>> in the Java platform concerning
>>>>>> modularity
>>>>>> 1. Packages are too limited for proper
>>>>>> language/logic modularity
>>>>>> 2. Lack of a runtime module concept that
>>>>>> is related to deployment
>>>>>> artifacts (physical modularity)
>>>>>> Looking at the proposed time frame (EDR
>>>>>> by
>>>>>> mid-April), attacking both problems
>>>>>> simultaneously seems rather unrealistic
>>>>>> based on my limited experience. I
>>>>>> therefore suggest to start with problem
>>>>>> #1: Packages are too limited for proper
>>>>>> language/logic modularity. What do you
>>>>>> think?
>>>>>> Kind regards,
>>>>>> Peter Kriens
>>>>>> On 27 jan 2009, at 05:31, Alex Buckley
>>>>>> wrote:
>>>>>>
>>>>>> Comments welcome.
>>>>>>
>>>>>> 1) Packages are typically arranged in
>>>>>> hierarchies, but types can only be
>>>>>> used across different branches of the
>>>>>> hierarchy by being made public,
>>>>>> which exposes implementation details
>>>>>> too widely. Information hiding is
>>>>>> further reduced by interface members
>>>>>> always being public.
>>>>>>
>>>>>> Non-solution: hierarchical package
>>>>>> membership. Redefining existing
>>>>>> well-known semantics is always a bad
>>>>>> idea, and this one is especially
>>>>>> complicated. There would need to be a
>>>>>> way to stop package-private
>>>>>> artifacts from being accessible to
>>>>>> subpackages, or else we would be
>>>>>> strengthening information hiding in
>>>>>> one place only to weaken it
>>>>>> elsewhere. Also, there would need to
>>>>>> be a way to configure the depth of
>>>>>> exposure of package-private
>>>>>> artifacts,
>>>>>> since artifacts in package A
>>>>>> should sometimes be accessible to A.B
>>>>>> and not to A.B.C, and so on.
>>>>>>
>>>>>> 2) Dependencies of one type on
>>>>>> another
>>>>>> are expressed in source and
>>>>>> classfiles, but there is no standard
>>>>>> way for a Java compiler or JVM to
>>>>>> interact with its environment to read
>>>>>> and resolve dependencies. This
>>>>>> causes compile-time and runtime
>>>>>> environments to differ, and
>>>>>> complicates
>>>>>> any effort to version types available
>>>>>> in the (compile-time or runtime)
>>>>>> environment.
>>>>>>
>>>>>> Non-solution: standardize the
>>>>>> CLASSPATH. One list for all
>>>>>> programs and
>>>>>> libraries in the JVM makes versioning
>>>>>> almost meaningless, and packages
>>>>>> whose types occur in multiple
>>>>>> CLASSPATH entries can behave
>>>>>> poorly. (See
>>>>>> Peter Kriens' presentation at Devoxx
>>>>>> 2008.)
>>>>>>
>>>>>> 3) Many packages have grown large
>>>>>> over
>>>>>> the years. They are effectively
>>>>>> impossible to refactor now, since it
>>>>>> is binary-incompatible to rename
>>>>>> types and dangerous to "split"
>>>>>> packages. The next-best option is
>>>>>> to let
>>>>>> subsets be taken of existing
>>>>>> packages,
>>>>>> and deliver subsets
>>>>>> independently, but there is no
>>>>>> mechanism in the Java language or
>>>>>> JVM for
>>>>>> that.
>>>>>>
>>>>>> Non-solution: a mechanism for
>>>>>> renaming
>>>>>> packages and types outside the
>>>>>> Java language. This would require
>>>>>> updating Java's model of binary
>>>>>> compatibility, and would make source
>>>>>> code incomprehensible.
>>>>>>
>>>>>> Alex
>>>>>>
>>>>>> _______________________________________________
>>>>>> jsr294-modularity-eg mailing list
>>>>>> jsr294-modularity-eg at cs.oswego.edu
>>>>>> <mailto:
>>>>>> jsr294-modularity-eg at cs.oswego.edu
>>>>>>
>>>>>>>
>>>>>>> <mailto:
>>>>>> jsr294-modularity-eg at cs.oswego.edu
>>>>>> <mailto:
>>>>>> jsr294-modularity-eg at cs.oswego.edu
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>> http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------
>>>>>>
>>>>>> _______________________________________________
>>>>>> jsr294-modularity-eg mailing list
>>>>>> jsr294-modularity-eg at cs.oswego.edu
>>>>>> <mailto:jsr294-modularity-eg at cs.oswego.edu
>>>>>> >
>>>>>>
>>>>>> http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> jsr294-modularity-eg mailing list
>>>>>> jsr294-modularity-eg at cs.oswego.edu
>>>>>> <mailto:jsr294-modularity-eg at cs.oswego.edu>
>>>>>>
>>>>>> http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg
>>>>>>
>>>>>> _______________________________________________
>>>>>> jsr294-modularity-eg mailing list
>>>>>> jsr294-modularity-eg at cs.oswego.edu
>>>>>> <mailto:jsr294-modularity-eg at cs.oswego.edu>
>>>>>>
>>>>>> http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg
>>>>>>
>>>>>> _______________________________________________
>>>>>> jsr294-modularity-eg mailing list
>>>>>> jsr294-modularity-eg at cs.oswego.edu
>>>>>> <mailto:jsr294-modularity-eg at cs.oswego.edu>
>>>>>>
>>>>>> http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg
>>>>>>
>>>>>> _______________________________________________
>>>>>> jsr294-modularity-eg mailing list
>>>>>> jsr294-modularity-eg at cs.oswego.edu
>>>>>> <mailto:jsr294-modularity-eg at cs.oswego.edu>
>>>>>> http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-
>>>>>> eg
>>>>>>
>>>>>> _______________________________________________
>>>>>> jsr294-modularity-eg mailing list
>>>>>> jsr294-modularity-eg at cs.oswego.edu
>>>>>> <mailto:jsr294-modularity-eg at cs.oswego.edu>
>>>>>> http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> jsr294-modularity-eg mailing list
>>>>>> jsr294-modularity-eg at cs.oswego.edu
>>>>>> <mailto:jsr294-modularity-eg at cs.oswego.edu>
>>>>>> http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>
>>
More information about the jsr294-modularity-observer
mailing list