On 2/27/06, Werner Punz <[EMAIL PROTECTED]> wrote:
I *wish* that this were true ... but that's not reality. Any value you pick for the base JDK platform (or any other dependency) automatically omits any developers who might say "I'd be happy to try it, but I can't use it given my organization's required platform strategy." And, if the platform in question is your J2EE app server that doesn't support a particular JVM version, then there really is little that individual developers can do to influence the decisions. (You may, however, have a reason to go back and talk to the archtects of these projects, and to the recalcitrant vendors, if your 1.5 based project becomes popular anyway :-).
Adam Winer schrieb:
> That won't work: ADF Faces requires JDK 1.5, period. That is, of course,
> subject to change based on MyFaces dev discussion, but at the moment,
> that's the state of things.
>
Please do not change that ;-)
No seriously, 1.5 brings so many good things onto the table, that
enforcing people to use 1.5 only helps the adoption.
I *wish* that this were true ... but that's not reality. Any value you pick for the base JDK platform (or any other dependency) automatically omits any developers who might say "I'd be happy to try it, but I can't use it given my organization's required platform strategy." And, if the platform in question is your J2EE app server that doesn't support a particular JVM version, then there really is little that individual developers can do to influence the decisions. (You may, however, have a reason to go back and talk to the archtects of these projects, and to the recalcitrant vendors, if your 1.5 based project becomes popular anyway :-).
Having to drag 1.3 and 1.4 around because of corporate policy is a huge
burden on many developers who would love to use annotations to simplify
their work.
MyFaces has to support 1.4 due to standardization reasons (well tomahawk
out of goodwill) but moving an already established 1.5 codebase back to
1.4, please, dont :-)
In the framework space (i.e. Shale) I am dealing with this by providing fundamental functionality in a 1.4-compatible manner, and adding an optional layer on top that provides annotations-based support (no more declaring managed beans, or registering components). It sucks that I cannot use 1.5 APIs in the basic codebase, but this was a deliberate choice, made ***only*** because it reduces the burden to immediate adoption. I'm not sure a similar strategy works as well for a component library, however :-(.
Craig
