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.
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
