[EJB_SPEC-17] Prune EJB 2 backwards compatibility Created: 08/Jul/11 Updated: 28/Jul/13
|Fix Version/s:||Future version|
|Remaining Estimate:||Not Specified|
|Time Spent:||Not Specified|
|Original Estimate:||Not Specified|
It has been more than five years since EJB 3/Java EE 5 was finalized. In terms of the technology industry, that's almost a life-time. At this point, I don't think it is sensible to continue to support the flawed EJB 2 development model. Pruning it in EJB 3.2 would significantly simplify the EJB specification/implementations going forward.
|Comment by exabrial [ 10/Oct/11 ]|
I couldn't agree more. CORBA and EJB2 should both be pruned. Jettisoning the deadweight would also lower the bar to getting a container certified EJB3.2
|Comment by marina vatkina [ 10/Oct/11 ]|
Nothing will change for EJB 3.2 certification even if we mark them as proposed optional. See the Java EE Platform spec for the details of the pruning process.
|Comment by arjan tijms [ 01/Dec/11 ]|
Would it be at least an option to move all text covering EJB2 material in the EJB3 spec to an appendix or even better to a separate document?
There is currently a rather large portion of the EJB3 spec still devoted to EJB2. It's intertwined with the main text, which IMO makes it unnecessarily hard for 'normal developers' to use the spec as a fallback reference guide.
What about in addition to EJB Lite defining another subset of full EJB called EJB Legacy Free, that excluded EJB2 and Corba?
|Comment by marina vatkina [ 08/Feb/13 ]|
Can't prune EJB 3.2 without pruning interop, and the latter is not happening in EE7
|Comment by arjan tijms [ 28/Jul/13 ]|
I remarked this quite a while ago, but as a (rather late) example of this.
17.3.2 Method Permissions says the following:
This is rather wordy to anyone who doesn't even know (and wants to know) about anything related to EJB 2. E.g. the average person who started using EJB in version 3.
Without the EJB 2 references, the text could be:
IMHO the latter makes it much easier to understand the theory that's being discussed. Note that this text is just one example. Large parts of the spec are (IMHO) unnecessary complicated to read because of all those EJB 2 references. For EJB 3 developers those are really not applicable and the reader has to mentally filter this noise away.