Get string representation of javadsl Content and Media Type

[mdedetrich]

Currently in the javadsl its not possible to get the string representation of the Content-Type/Media-Type because its only the scaladsl that implements the value function (via the ValueRenderable trait). This PR adds the value method to the core Java interfaces (the render method is anyways implemented in the subclasses hence why this PR is compiling without any additional changes)

As a workaround I currently have to do this (its in kotlin but should be understandable)

internal fun contentTypeToString(contentType: ContentType): String {
    return when (contentType) {
        is org.apache.pekko.http.scaladsl.model.ContentType ->
            return contentType.value()
        else -> throw RuntimeException("Unsupported content type: ${contentType::class.qualifiedName}")
    }
}

This works because it just so happens that every javdsl ContentType is also a scaladsl ContentType

[pjfanning]

lgtm - the 1.1.x branch exists now so this is safe to merge but I would appreciate a delay on the merge until we get #631 merged

[mdedetrich]

lgtm - the 1.1.x branch exists now so this is safe to merge but I would appreciate a delay on the merge until we get #631 merged

I would wait for 1.2.x, there is a workaround and since we are adding methods to an interface we should be bumping the minor version

[pjfanning]

lgtm - the 1.1.x branch exists now so this is safe to merge but I would appreciate a delay on the merge until we get #631 merged

I would wait for 1.2.x, there is a workaround and since we are adding methods to an interface we should be bumping the minor version

• we use 'main' branch for the development version and 1.2.0 is becoming the development version
• future 1.1.x patch releases will be built using the '1.1.x' branch

[raboof]

We should probably edit CustomMediaTypesExampleTest to use the new .value() instead of the current .toString().

[mdedetrich]

We should probably edit CustomMediaTypesExampleTest to use the new .value() instead of the current .toString().

Done

[mdedetrich]

@pjfanning Can you re-review this PR given @raboof 's comments?

[pjfanning]

@pjfanning Can you re-review this PR given @raboof 's comments?

The changes look ok. We still need to block the merge until we have the 1.1.x branch and related CI builds.

[raboof]

We still need to block the merge until we have the 1.1.x branch and related CI builds.

I think I missed why we'd want to delay this merge - this PR as it now stands seems like a regular backwards-compatible change (assuming nobody inherited from ContentType or MediaType, which seems like a reasonable assumption)?

[pjfanning]

We still need to block the merge until we have the 1.1.x branch and related CI builds.

I think I missed why we'd want to delay this merge - this PR as it now stands seems like a regular backwards-compatible change (assuming nobody inherited from ContentType or MediaType, which seems like a reasonable assumption)?

The PR currently has @since 1.2.0. If these change to @since 1.1.1 then we don't need to start preparing for 1.2.0 snapshots.

[raboof]

We still need to block the merge until we have the 1.1.x branch and related CI builds.

I think I missed why we'd want to delay this merge - this PR as it now stands seems like a regular backwards-compatible change (assuming nobody inherited from ContentType or MediaType, which seems like a reasonable assumption)?

The PR currently has @since 1.2.0. If these change to @since 1.1.1 then we don't need to start preparing for 1.2.0 snapshots.

Aah, gotcha. This begs the question whether those @since annotations are really worth having. I can easily imagine situations where it isn't clear yet whether the next release will be a minor, patch or major one. Should/have we discuss(ed) this on the mailinglist?

[pjfanning]

We still need to block the merge until we have the 1.1.x branch and related CI builds.

I think I missed why we'd want to delay this merge - this PR as it now stands seems like a regular backwards-compatible change (assuming nobody inherited from ContentType or MediaType, which seems like a reasonable assumption)?

The PR currently has @since 1.2.0. If these change to @since 1.1.1 then we don't need to start preparing for 1.2.0 snapshots.

Aah, gotcha. This begs the question whether those @since annotations are really worth having. I can easily imagine situations where it isn't clear yet whether the next release will be a minor, patch or major one. Should/have we discuss(ed) this on the mailinglist?

I guess we can discuss the philosophies around using since annotations on the mailing list - I would strongly argue that we can't change the established approach in a patch release.

[raboof]

We still need to block the merge until we have the 1.1.x branch and related CI builds.

I think I missed why we'd want to delay this merge - this PR as it now stands seems like a regular backwards-compatible change (assuming nobody inherited from ContentType or MediaType, which seems like a reasonable assumption)?

The PR currently has @since 1.2.0. If these change to @since 1.1.1 then we don't need to start preparing for 1.2.0 snapshots.

Aah, gotcha. This begs the question whether those @since annotations are really worth having. I can easily imagine situations where it isn't clear yet whether the next release will be a minor, patch or major one. Should/have we discuss(ed) this on the mailinglist?

I guess we can discuss the philosophies around using since annotations on the mailing list

OK, I can start that thread.

I would strongly argue that we can't change the established approach in a patch release.

OK. AFAICS the 1.1.x branch has already been created, meaning the @since 1.2.0 is correct, right? Is there anything that still needs to be done before #631 can be un-drafted and merged?

[mdedetrich]

I think I missed why we'd want to delay this merge - this PR as it now stands seems like a regular backwards-compatible change (assuming nobody inherited from ContentType or MediaType, which seems like a reasonable assumption)?

So actually, the reason for putting it in 1.2.0 is that while its not a breaking compatible change it is a forwards breaking change (hence the MiMa changes) which is allowed by semver in minor version bumps and not patch (its only backwards compatibility thats disallowed, this has to be done in a major patch update).

[pjfanning]

approved for main branch merge - now that main branch is repurposed for v1.2 dev

[mdedetrich]

Thanks, I will go ahead and merge it.