Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] [External] : Re: Simplifying the platform by merging some specs?

On 3/8/22 8:50 AM, Romain Manni-Bucau wrote:
The key in this discussion is the goal merging everything would reach.
The only gain I see is to make the release smoother.
The drawbacks I see is to couple more specs quite easily, increase the contribution level (spec becomes more complex by becoming plural, think how easy it is to contribute to an EE server compared to a standalone implementation for ex) and therefore reduce the number of people in the spec and by consequence the quality of the industry covering of the releases. But at the end if it is to merge specs to keep them independent it has no real value IMHO. If it is to really merge them (ex: JSON-P+JSON-B in the same PDF), then it will increase the user entry cost too so reduce the adoption.

there is no PDF for JSONP, so one would need to be created by someone - add that to the overall "cost" of the merge.

Does anything block arbitrary user to create say org.glassfish.jakarta.json with the proposed structure, deploy that to central and advertise that as an entry point to Jakarta EE defined JSON world in Java provided by GlaasFish project? Something like this should also probably come with some "default" implementations to be really useful for end users. (Feel free to replace GlassFish with whatever is preferred, the "default" CI can be whatever the provider of such module decides to use)


So overall the question from my window is: is the release cost so high? The RC discussion seems to answer that it is "no" so I'm not sure there is a benefit there.

Romain Manni-Bucau
@rmannibucau <;!!ACWV5N9M2RV99hQ!egoFkUMikujSDC9nytvcPgOeJ93Z4QQMN9SJjZrpyzgFDTZETliRSk-gbvV-xoSZbmU$> | Blog <;!!ACWV5N9M2RV99hQ!egoFkUMikujSDC9nytvcPgOeJ93Z4QQMN9SJjZrpyzgFDTZETliRSk-gbvV-WvtUSKA$> | Old Blog <;!!ACWV5N9M2RV99hQ!egoFkUMikujSDC9nytvcPgOeJ93Z4QQMN9SJjZrpyzgFDTZETliRSk-gbvV--tTz2GY$> | Github <;!!ACWV5N9M2RV99hQ!egoFkUMikujSDC9nytvcPgOeJ93Z4QQMN9SJjZrpyzgFDTZETliRSk-gbvV-DAha-eU$> | LinkedIn <;!!ACWV5N9M2RV99hQ!egoFkUMikujSDC9nytvcPgOeJ93Z4QQMN9SJjZrpyzgFDTZETliRSk-gbvV--MHBTEk$> | Book <;!!ACWV5N9M2RV99hQ!egoFkUMikujSDC9nytvcPgOeJ93Z4QQMN9SJjZrpyzgFDTZETliRSk-gbvV-N3CiuuI$>

Le lun. 7 mars 2022 à 23:51, Brian Stansberry <brian.stansberry@xxxxxxxxxx <mailto:brian.stansberry@xxxxxxxxxx>> a écrit :

    On Mon, Mar 7, 2022 at 4:07 PM arjan tijms <arjan.tijms@xxxxxxxxx
    <mailto:arjan.tijms@xxxxxxxxx>> wrote:


        On Thu, Mar 3, 2022 at 8:47 PM Brian Stansberry
        <mailto:brian.stansberry@xxxxxxxxxx>> wrote:

            Agreed. I know in WildFly we integrate a number of libraries
            that use JSONP but not JSONB, and those libraries are used
            outside of appservers.

            And in WildFly you can configure a server installation
            without JSONB support if you don't need it. I know other
            servers provide similar slimming ability.

        Is it absolutely needed to have the specs split to enable that?

        What about having multiple modules within the spec?
        E.g. jakarta.json as a module that includes
        both jakarta.json.processing and jakarta.json.bind. Application
        developers who want to use JSON could simply use jakarta.json.
        But libraries that specifically need to bind to
        jakarta.json.processing, can bind to only that.

        We considered splitting up Faces in dozens of modules, so people
        could omit things they do not want (say, omit the navigation
        rules, or omit the resource library contracts). Naturally we
        don't dream of splitting up Faces in a dozen new specs.

    Sure, as long as the specs are producing finer grained artifacts and
    impls do the same we can create JBoss Modules modules that allow
    your slimmed server to just have what you want.

    A risk of combining things even though they are modularized within
    the spec is that modularization breaks down over time, but that kind
    of risk can be managed.

        Kind regards,

        jakartaee-platform-dev mailing list
        To unsubscribe from this list, visit

-- Brian Stansberry
    Principal Architect, Red Hat JBoss EAP
    jakartaee-platform-dev mailing list
    To unsubscribe from this list, visit

jakartaee-platform-dev mailing list
To unsubscribe from this list, visit;!!ACWV5N9M2RV99hQ!egoFkUMikujSDC9nytvcPgOeJ93Z4QQMN9SJjZrpyzgFDTZETliRSk-gbvV-HhnmLwM$

Back to the top