[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [jakartaee-platform-dev] about the status of atinject
- From: Guillermo GonzÃlez de AgÃero <z06.guillermo@xxxxxxxxx>
- Date: Sat, 11 May 2019 09:02:23 +0200
- Delivered-to: firstname.lastname@example.org
Totally agree. For 3rd party libs there's no difference between using a spec whose development has moved elsewhere, and using a dead spec.
Nothing prevents them to keep using the (unchanged) javax version.
Yes, this is surely something to take into consideration.
Would the JCP maintain atinject?
My answer is: no
We tried to have smallish additions for CDI-2.0 and also already had talks with a few of the involved people.
ccing Atoine because he also has a stance in this story and it would be great if he also might share his opinion on the topic.
Back then it was not possible to change anything as the EG did not come to live up again and Oracle doesn't own anything for atinject. So they simply will not touch it - likely ever. This is not legally an actual problem but only an extremely defensive position on Oracle side. Which is perfectly fine from their pov. Happy to be proven wrong, but I don't think this is likely to change.
So no, if there will ever be a change necessary, then we need other ways to deal with it for CDI, EJB, etc.
Otoh the compatility with javax.inject.Inject is practically deminished to people being familiar with the annotations.
Not much more. That's because an application or library written for CDI will never run on Spring or picoContainer. Or vice versa. Also moving javax.inject to jakarta.inject only for Jakarta will still allow all the other libs to use javax.inject IF they want. Ideally even allowing co-existance.
> Am 10.05.2019 um 09:08 schrieb Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx>:
> I fully understand your desire to get atInject changed but I'm not
> really happy if atInject gets forked because it is not only used in
> Spring/JavaEE applications but in simple Java-Applications via Google
> Guice or Eclipse DI to name 2 libraries implementing the standard.
> Forking it means that you potentially put pressure not only to EE world
> but the rest of the Java ecosystem. If I'm not wrong it is still
> possible to evolve atInject but you need to keep it in the JCP, would
> that be the better way to go for atInject.
> I fully understand that those frameworks could still use the "legacy"
> javax-namespace but you open the door for fragmentation in a part of the
> java ecosystem who would not have been affected at all!
> On 10.05.19 08:10, Christian Kaltepoth wrote:
>> I'm also +1 for integrating AtInject into Jakarta EE.
>> And +1 for contacting the former EG first.
>> Am Fr., 10. Mai 2019 um 05:57 Uhr schrieb Josh Juneau
>> <juneau001@xxxxxxxxx <mailto:juneau001@xxxxxxxxx>>:
>>Â Â+1 on forking for Jakarta EE.
>>Â ÂJosh Juneau
>>Â Âjuneau001@xxxxxxxxx <mailto:juneau001@xxxxxxxxx>
>>Â Âhttp://jj-blogger.blogspot.com <http://jj-blogger.blogspot.com/>
>>Â ÂOn May 9, 2019, at 4:01 PM, Mark Struberg <struberg@xxxxxxxxxx
>>Â Â<mailto:struberg@xxxxxxxxxx>> wrote:
>>>>Â ÂAm 09.05.2019 um 21:54 schrieb Mike Milinkovich
>>>>Â ÂThe patent grant in the ALv2 is far, far weaker than the patent
>>>>Â Âgrants in the Jakarta EE Spec Process.
>>>Â ÂThis is a very broad argument and we should rather clarify this to
>>>Â Âavoid confusing non legally trained readers.
>>>Â ÂI personally strongly believe that the patent grant in the ALv2 is
>>>Â Âabsolutely sufficient.
>>>Â ÂThe main difference afaict is that for some older specs Oracle
>>>Â Âwanted to sign over patents to them, while the ALv2 only _grants_
>>>Â Âpatent licenses to *every* downstream consumer . So the ALv2
>>>Â Âpatent grant is - in my eyes - evenmore aligned with the new
>>>Â ÂJakarta Specification License than the old (imo overreaching)
>>>Â Âhandling. It's also way more practical also in hindsight of tax law.
>>>Â ÂAnyway, since I don't believe that there are any patents filed for
>>>Â Âatinject stuff anyway it is hopefully a merely theoretical
>>>Â Âdiscussion. So I will stop here.
>>>Â ÂAnd first we need to focus on whether JakartaEE is interested to
>>>Â Âfork atinject at all - from a purely business demand point of view.
>>>Â Â https://www.apache.org/licenses/LICENSE-2.0.html#patent
>>>Â Âjakartaee-platform-dev mailing list
>>>Â ÂTo change your delivery options, retrieve your password, or
>>>Â Âunsubscribe from this list, visit
>>Â Âjakartaee-platform-dev mailing list
>>Â ÂTo change your delivery options, retrieve your password, or
>>Â Âunsubscribe from this list, visit
>> Christian Kaltepoth
>> Blog: http://blog.kaltepoth.de/
>> Twitter: http://twitter.com/chkal
>> GitHub: https://github.com/chkal
>> jakartaee-platform-dev mailing list
>> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> Tom Schindl, CTO
> BestSolution.at EDV Systemhaus GmbH
> Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
> jakartaee-platform-dev mailing list
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
jakartaee-platform-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit