Re: [jakartaee-platform-dev] javax.inject

[Alasdair Nottingham <alasdair.nottingham@xxxxxxxxx>]

I don’t know how I feel about this. One of the points of Inject was to have the same annotation for multiple injection runtimes and forking it would essentially result in us having a different class from everyone else (I’m assuming it would get renamed to jakarta.inject). This would seem to defeat the point/value in the annotation. 

Alasdair Nottingham

> On Jun 5, 2019, at 5:12 PM, Bill Shannon <bill.shannon@xxxxxxxxxx> wrote:
> 
> Lilian BENOIT wrote on 6/5/19 1:37 PM:
>> Why do we mandatory fork it ?
>> 
>> Why do we use it as dependency ?
>> If it is necessary, we could do maintenance release on JCP ? JCP is broken ?
> 
> JSR-330 is owned by SpringSource and Bob Lee, neither of which has shown any
> willingness to update that spec based on the needs of Java EE.  That's we
> we attempted to "move" it to Eclipse.  "We" can't update it at the JCP,
> only the owners can.
> 
>> In java commmunity, we have @Inject and @Autowired.
>> Spring support JSR330, but almost all developer using @Autowired.
>> Why spring community should support new @Inject (of Jakarta)
> 
> Spring uses a number of Java EE APIs.  That community will need to decide
> whether to stick with the no-longer-changing Java EE 8 versions of those
> APIs, or whether to switch to the Jakarta EE versions and track their
> evolution.
> 
>> Jakarta plateforme must it absorbs all specifications ?
>> It's a example of my previous mail: must we have jakarta community vs others
>> communities ?
>> 
>> A another example, it's PR #14 that it mentionned javax.sql.XAConnection and
>> others classes of JDK (JDBC part) must move on JTA.
>> (https://github.com/eclipse-ee4j/jakartaee-platform/pull/14/commits/9fb02c1df52006d70d72776fb4bc1045ad340814)
> 
> JSR 907 [1] split the JTA API into two pieces.  javax.transaction stayed
> with Java EE / Jakarta EE and the subset that was included in Java SE was
> removed from Java SE by JEP 320 [2].  javax.transaction.xa remained with
> Java SE and no longer needs to be defined by Java EE since it is inherited
> from Java SE.  This ugly overlap of JTA between Java SE and Java EE has
> now been cleaned up.
> 
> 
> [1] https://jcp.org/en/jsr/detail?id=907
> [2] https://openjdk.java.net/jeps/320
> _______________________________________________
> jakartaee-platform-dev mailing list
> jakartaee-platform-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev