On 12/02/2015 04:49 PM, Alex Buckley wrote:
On 12/2/2015 1:34 PM, Paul Benedict wrote:
Alex, the primary benefit of annotations (vs. XML) is delivering code
and configuration in one bundle. It's unnecessary to deliver
configuration separately (i.e., XML) if you have a component that
primarily has one way of being configured. That's exactly why
annotations are very valuable in EE development and can displace
configuration files. Because of the bundling, no, I have no any
expectation of going into a text editor for modification.
Totally agree so far.
On the contrary, the discussion on these boards make me believe the
module information is going to be more fluid. Right now it's expressing
dependencies, but it seems frameworks and other tools may want to add
their own bits of information along the way. This, like the Manifest, I
do have expectations for editing at will. Perhaps I want to add data
only I care about, and I may want to see what others have added. That's
all a possibility.
Now we reach the disagreement. We don't think the module declaration
will be as fluid as you do. Yes, frameworks and other tools will want to
modify module declarations (usually by addition of dependencies or
exports) but that's a handful of actors, all of whom are perfectly
capable of using ASM. 99.99% of humans have no business modifying
someone else's module declaration by hand, so there is no reason for it
to be easy.
I am baffled as to the basis for this assertion. This kind of change in
fact happens (present tense) frequently - very frequently if you have
any kind of system for updates. Modules get split or merged,
implementations from one vendor get swapped out for another, multiple
versions of things are introduced. I honestly can say that I do not
understand how the Jigsaw team arrives at this kind of conclusion with
literally zero production experience!
But, with that said, I am unsure the point you're trying to make. The
Module Descriptor is neither annotation nor XML and doesn't configure
code. Rather, it configures the build-time and/or run-time environment.
It's practically a weak "make" file or IDE project configuration in its
current form. It's very odd to take this information and shoe-horn it
into a class file.
A module declaration configures code -- "exports" determines the
accessibility of types.
A module declaration ALSO configures the build-time and run-time
environment -- I agree that "requires" is the same kind of dependence
widget as found in an IDE project configuration. (Though "requires
public" is quite a bit more powerful.)
Sure, you could configure accessibility with @Exported on public type
declarations, and configure the build-time and run-time environment with
a module.xml file. But if we're going to introduce the concept of a
module to millions of Java developers, we see value in consolidating
both kinds of configuration in one place -- a place that's fluid during
development and not very fluid thereafter.
Alex
Cheers,
Paul
On Wed, Dec 2, 2015 at 2:16 PM, Alex Buckley <alex.buck...@oracle.com
<mailto:alex.buck...@oracle.com>> wrote:
On 12/2/2015 8:31 AM, Paul Benedict wrote:
All that information is locked in binary format but it
should be human readable. I should be able to go in myself and
do this with
a text editor. I shouldn't have to compile a file anymore than I
have to
compile my MANIFEST.MF or web.xml or application.xml. This is
all about
configuration; not executable code.
Annotations are human readable in source code but end up "locked in
binary format". Entity mappings and REST endpoints (since we're
speaking of EE constructs like application.xml) are configuration
... do you expect to be able to use a text editor to modify them?
Is there any more to say on the issue of "source-flowing-to-binary
versus structured-text" than is already rehearsed at
http://stackoverflow.com/questions/182393/xml-configuration-versus-annotation-based-configuration
?
Alex
--
- DML
