Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartabatch-dev] Generics need to move post-EE9
Right, this can be enhanced by enforcing compile type checks but rational was that it shouldn't change much actually since these methods are never called in user land and code generally delegates to another "service" which is typed. Main impacting part for the users is the data "injections", not the outcome.

That said, the point was mainly the fact we don't need any breaking change to get this feature in and this remains valid ;).

Romain Manni-Bucau
@rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book


Le mer. 11 mars 2020 à 14:12, Martijn Dashorst <martijn.dashorst@xxxxxxxxx> a écrit :
Unfortunately readItem still has Object as return type rather than R, as does checkPointInfo() (returning Serializable rather than C).

Martijn


On Wed, Mar 11, 2020 at 1:34 PM Romain Manni-Bucau <rmannibucau@xxxxxxxxx> wrote:
Yes or no ;)


In Java >= 8 it can even be done at interface level with default methods, so no breaking change needed IMHO.

Romain Manni-Bucau
@rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book


Le mer. 11 mars 2020 à 12:45, Scott Kurz <skurz@xxxxxxxxxx> a écrit :

Romain,

I agree that in terms of the significance of the function, generics is not a big deal . However if Jakarta is strongly encouraging semantic versioning, as in https://semver.org/, then, well, we are talking about an incompatible API change: we'd be breaking source compatibility (even if binary compatibility were still present).

------------------------------------------------------
Scott Kurz
WebSphere Batch and Developer Experience
skurz@xxxxxxxxxx
--------------------------------------------------------

Inactive hide details for Romain Manni-Bucau ---03/11/2020 02:11:02 AM---Hi Scott, Think a 2.x can add it, it is not a centralRomain Manni-Bucau ---03/11/2020 02:11:02 AM---Hi Scott, Think a 2.x can add it, it is not a central feature by itself, just very

From: Romain Manni-Bucau <rmannibucau@xxxxxxxxx>
To: jakartabatch developer discussions <jakartabatch-dev@xxxxxxxxxxx>
Date: 03/11/2020 02:11 AM
Subject: [EXTERNAL] Re: [jakartabatch-dev] Generics need to move post-EE9
Sent by: jakartabatch-dev-bounces@xxxxxxxxxxx




Hi Scott,

Think a 2.x can add it, it is not a central feature by itself, just very expected and convenient but does not enable a single use case we can't already do.

That said it asks questions about companion features so I agree we should do it after jakarta namespace move - but quite shortly after.

Romain

Le mar. 10 mars 2020 à 23:30, Scott Kurz <skurz@xxxxxxxxxx> a écrit :
    So while I raised the issue:
    https://github.com/eclipse-ee4j/batch-api/issues/13
    asking should we consider adding generics (for the various "item" types and others), I think it is simply too late at this point.

    I think there was an opportunity and unfortunately I just wasn't engaged enough in the project to take advantage of this. At this point we'd be jeopardizing the whole EE 9 plan.

    This would be the case even if we knew exactly what changes we wanted to make and had tested them in runtime impls, which isn't the case.

    Looking ahead,

    I'm not sure of an easy, non-breaking way to make such a change. If we were to follow semantic version that could even push generics into a 3.0 release.
    Not quite the normal progression to go so long between 1.0 and 2.0, then quick do a 3.0.

    The generics seem even more useful with jobs constructed in Java (rather than XML)... maybe if we tie generics to that function, which we've also talked about recently, we would have a decent-enough story.

    Thoughts?
    ------------------------------------------------------
    Scott Kurz
    WebSphere Batch and Developer Experience
    skurz@xxxxxxxxxx
    --------------------------------------------------------
    _______________________________________________
    jakartabatch-dev mailing list
    jakartabatch-dev@xxxxxxxxxxx
    To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartabatch-dev_______________________________________________
    jakartabatch-dev mailing list
    jakartabatch-dev@xxxxxxxxxxx
    To unsubscribe from this list, visit     https://www.eclipse.org/mailman/listinfo/jakartabatch-dev



_______________________________________________
jakartabatch-dev mailing list
jakartabatch-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartabatch-dev
_______________________________________________
jakartabatch-dev mailing list
jakartabatch-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartabatch-dev


--
Become a Wicket expert, learn from the best: http://wicketinaction.com
_______________________________________________
jakartabatch-dev mailing list
jakartabatch-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartabatch-dev

Back to the top