On Oct 13, 2011, at 10:06 AM, Marcel Offermans wrote: > On Oct 13, 2011, at 9:43 AM, Bram de Kruijff wrote: > >> Hi Marcel, >> >> 2011/10/12 Marcel Offermans <[email protected]>: >>> Guys, >>> After some discussions in AMDATU-420 and AMDATU-435 I decided to add two >>> pages to our wiki with some new conventions: >>> http://www.amdatu.org/confluence/display/Amdatu/Bundle+Packaging+Guidelines >>> and >>> http://www.amdatu.org/confluence/display/Amdatu/Components%2C+Services+and+Constants >>> Please review! >> >> Great job. I'm in favor of applying these. With regard to the (sneaky) >> constants stuff you might help me and other out with a GOOD vs BAD >> example. Eg. Are you saying that if the constant is on a class >> imported is will not get inlined or should we actually add getters? > > I'm saying that constants are always inlined by the compiler, so the class or > interface that contains them will not even show up in the bytecode. > Therefore, we only need to make sure that class or interface is available at > compile time. > > As an example, look at the FilterHandlerRegistry in web.dispatcher, which > contains an import of o.a.core.tenant.Tenant and uses it in a couple of > locations to refer to a constant. If you compile this code, that import will > completely disappear. > > Writing this, I discovered that I forgot to remove the optional import on > tenants (done in revision 1506) but the dispatcher bundle now does not need > to import the package anymore because it does not use it. > > I will add this example to the documentation as well, and come up with a > "bad" one. :)
I added some examples, but I'm not sure how to further clarify the fact that constants are inlined at compile time, and their interfaces don't show up as imports in the bytecode. Also, I'm going to start refactoring the platform to conform to these conventions, by for example removing service registrations of "empty" service interfaces. Greetings, Marcel _______________________________________________ Amdatu-developers mailing list [email protected] http://lists.amdatu.org/mailman/listinfo/amdatu-developers
