[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jakartaee-platform-dev] about the status of atinject
|
Hi Tom!
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.
Makes sense?
LieGrue,
strub
> Am 10.05.2019 um 09:08 schrieb Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx>:
>
> Hi,
>
> 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!
>
> Tom
>
> 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/>
>> https://www.apress.com/us/search?query=Juneau
>>
>> 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
>>>> <mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx
>>>> <mailto:mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx>>:
>>>>
>>>> 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 [1]. 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.
>>>
>>> LieGrue,
>>> strub
>>>
>>>
>>> [1] https://www.apache.org/licenses/LICENSE-2.0.html#patent
>>> _______________________________________________
>>> jakartaee-platform-dev mailing list
>>> jakartaee-platform-dev@xxxxxxxxxxx
>>> <mailto: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
>> _______________________________________________
>> jakartaee-platform-dev mailing list
>> jakartaee-platform-dev@xxxxxxxxxxx
>> <mailto: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
>>
>>
>>
>> --
>> Christian Kaltepoth
>> Blog: http://blog.kaltepoth.de/
>> Twitter: http://twitter.com/chkal
>> GitHub: https://github.com/chkal
>>
>>
>> _______________________________________________
>> 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
>>
>
> --
> 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
> 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
