That tracks.
The component I, personally, might want JSON available internally for is an
artifact resolution API [1]. Gradle's module metadata is out there in the
world and could be worth consuming [2]. That's neither here nor there
though.
I'd say that the JEP as written could use some rework
On 25/11/2022 13:27, Ethan McCue wrote:
...huh
>>The recent removal of Nashorn has indicated several places were
>> javascript were used in the JDK mainly due to it's built-in support for
>> parsing JSON//None of those seem like they would have been using nashorn in the
past, so i wonder what
...huh
>> The recent removal of Nashorn has indicated several places were
>> javascript were used in the JDK mainly due to it's built-in support for
>> parsing JSON
None of those seem like they would have been using nashorn in the
past, so i wonder what this is referring to.
On Fri, Nov 25,
On 25/11/2022 02:04, Ethan McCue wrote:
I suppose while I'm asking questions - what exactly are the parts of
the JDK making use of ad-hoc json? Maybe we could ship *something* as
a jdk.internal module for those use cases?
JEP 198 pre-dates records, sealed classes, pattern matching, ... and I
I suppose while I'm asking questions - what exactly are the parts of the
JDK making use of ad-hoc json? Maybe we could ship *something* as a
jdk.internal module for those use cases?
On Thu, Nov 24, 2022 at 8:55 PM Ethan McCue wrote:
> I'm reading JEP 198 and sketching out what an implementation
I'm reading JEP 198 and sketching out what an implementation could look
like pursuant to this old conversation.
https://mail.openjdk.org/pipermail/discuss/2020-April/005401.html
My biggest question right now is what does the JEP mean exactly by
"document context"
- Parsing APIs which allow
