Loading today’s stories
Build1 distinct publisher3 min readUpdated
Two JEPs moved to Proposed to Target for JDK 28: a built-in JSON parsing and generation API that ships as an incubator feature, and formal deprecation of the macOS/x64 port.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
Two OpenJDK proposals were elevated from Candidate to Proposed to Target for JDK 28 in the week covered by InfoQ's August 10, 2026 Java roundup: JEP 540, Simple JSON API (Incubator), and JEP 541, Deprecate the macOS/x64 Port for Removal [1][2][3]. One touches the dependency list of nearly every service that speaks HTTP; the other starts an official clock on Intel-based Macs.
The parenthetical in JEP 540's title is the planning story. The JEP defines a simple, standard API for parsing and generating JSON documents without the need for an external library, and implements RFC 8259 [4][5]. It also supersedes JEP 198, Light-Weight JSON API, which is now closed and withdrawn [6], which is worth remembering before anyone treats this as settled: a built-in JSON API has been proposed in the JDK before and did not ship. The honest read for an operator is that this is worth a spike branch, not a ticket to remove Jackson or Gson. The dependency arithmetic changes when the API leaves the incubator, and that step is not what moved this week [3].
JEP 541 is the more consequential item for anyone with hardware or CI in their planning horizon. The JEP proposes to deprecate the macOS/x64 port because Apple no longer supports this architecture, with the intent to remove the port in a future release to save maintenance costs [7][8]. The stated model is JEP 449, Deprecate the Windows 32-bit x86 Port for Removal [9]. Deprecation is not removal, and no removal release is named [8], but the direction is now explicit enough to act on: audit Intel Mac developer machines, macOS/x64 build agents, and any customer-facing artefact you still produce for that target, and decide who pays for the migration and when.
Both proposals are still in review. The JEP 540 review was expected to conclude on Monday, August 17, 2026, seven days after the roundup, and the JEP 541 review on Friday, August 21, 2026, eleven days after [10][11][1][2]. Meanwhile JDK 28 early access reached build 11, carrying fixes over build 10, while JDK 27 early access remained at build 34 [12][13].
There is a mild irony in the timing on the enterprise side. In his Hashtag Jakarta EE blog, Ivar Grimstad, Jakarta EE Developer Advocate at the Eclipse Foundation, reported that Jakarta JSON Binding 3.1 has had an M1 out for a while with an M2 shaping up, and that Jakarta JSON Processing 2.2 is planning an M1 shortly [14][15][16]. Jakarta CDI 5.0 is up for release review, and Jakarta RESTful Web Services 5.0 is waiting on three required +1s before its pull requests can merge and an M1 can be produced [17][18]. So the platform is moving toward its own JSON API while the EE JSON specifications continue on a separate track, and shops on both will carry two answers to the same question for a while.
The only item on this list that needs attention this week rather than next quarter is Open Liberty 26.0.0.8, whose GA release delivers bug fixes and resolutions for numerous CVEs that can all result in denial of service [19]. Among them is CVE-2026-50645, where nothing restricts the number of attachment headers a message can contain when it is deserialized by Apache CXF [20].
What to watch: whether the two reviews closed on schedule on August 17 and August 21 [10][11]; whether a later JEP names an actual removal release for macOS/x64 rather than a future one [8]; and whether JEP 540 gets a second incubator round in JDK 29 or graduates. Until it graduates, keep the JSON library in the build file.
Follow any of these and your For You feed starts watching them — no settings page required.
Ranked by verification strength, evidence, and original report placement.
InfoQ published a Java news roundup for the week of August 10, 2026, covering OpenJDK, Jakarta EE, GlassFish, JNoSQL, Open Liberty and LangChain4j news.
JEP 541, Deprecate the macOS/x64 Port for Removal, has been elevated from Candidate to Proposed to Target for JDK 28.
JEP 540, Simple JSON API (Incubator), has been elevated from Candidate to Proposed to Target for JDK 28.
JEP 540 defines a simple, standard API for parsing and generating JSON documents without the need for an external library.
JEP 540 implements RFC 8259, The JavaScript Object Notation (JSON) Data Interchange Format.
JEP 540 supersedes JEP 198, Light-Weight JSON API, which is now closed and withdrawn.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Procedurally precise but single-sourced
Every claim is specific and checkable - JEP numbers, status transitions, review close dates, build numbers, spec milestone letters, CVE identifiers - and the roundup attributes the Jakarta EE material to a named, quoted primary source. What holds the score down is that the cluster contains exactly one publisher, with no independent confirmation of the JEP status changes and no follow-up establishing whether the reviews concluded as scheduled.
Early access only, no production usage
Adoption evidence is confined to artifact availability: a JDK 28 early-access build in which the incubating JSON API and the deprecation notice can be exercised, and adjacent ecosystem releases from the same week. The JSON API is explicitly an incubator module and JEP 541 names no removal release, and the source discloses no downloads, deployments, or production usage for any of it. The one item with real deployment pressure is the Open Liberty security release urging upgrades.
Reported flatter than its consequences
The source makes no promotional claims at all: statuses, dates and identifiers are stated without adjectives, and the incubator caveat and the missing removal release are both disclosed. If anything the framing understates consequence slightly - a standard JSON API entering the JDK and formal deprecation of Intel Mac support are placed as two paragraphs inside a routine weekly list, with no treatment of migration impact or of overlap with existing JSON libraries and Jakarta JSON specs.
Neutral aggregator over stakeholder inputs
The publisher is a developer trade outlet reporting third-party project activity, with no stake disclosed or evident in the outcomes, and the claims are procedural facts that are cheap to verify. Moderate rather than low because the underlying inputs are stakeholder self-reports: the Jakarta EE 12 status comes from the Eclipse Foundation's own Jakarta EE Developer Advocate, and the Open Liberty section reproduces a vendor release narrative that ends in an upgrade recommendation.
Solid on facts, thin on corroboration and outcome
Confidence is reasonable that the reported process states and releases are accurate, because they are narrow, dated and attributable. It is limited by having a single publisher, no cross-check, no confirmation that either review concluded successfully, and no evidence at all about real-world use of the incubating JSON API or the practical scope of the macOS/x64 deprecation.
build
Flux moves GitOps' source of truth into registries you own, and mirroring becomes the prerequisite1 distinct publisher
build
The AI-training bans live on the big infrastructure blogs, not the small publications1 distinct publisher
build
When code becomes write-only, the tests become the reviewable artifact1 distinct publisher
build
The argmax layer was doing more work than anyone credited1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
1 article · August 16, 2026