I think what has been proposed so far is powerful enough to perform that
task *if* there is an intermediate object in the mix.
if (
// Assuming a dual pattern for JsonString.of and the SAP
// strategy outlined in the doc
json instanceof index(0, JsonString::of).decode(var firstName)
)
I think you missed a 2.5 which is to use the information in DOM objects to
perform useful work.
On Wed, May 21, 2025, 1:04 PM Archie Cobbs wrote:
> On Wed, May 21, 2025 at 11:30 AM Paul Sandoz
> wrote:
>
>> I consider this a “known unknown” (in the words of Mr. Rumsfeld). We
>> would need to ex
In the my world - which I am again very interested in revisiting once there
is a version of patterns I can touch - you may approach that problem in the
following way:
sealed interface Content extends JsonEncodable {
static Content fromJson(Json json) {
return switch (json) {
What I mean by central in this context isn't that it's at the core of
things and features are built on top of it - as you note it is a valid
transformation of the hierarchy.
What I mean is that absent other construction/deconstruction apis it is the
most convenient avenue for those tasks. So code
I think it's worth noting that the way you used the prospective API in your
ONNX code is not representative of how the API would generally be used in a
jdk-only scenario. Custom making a general transformation from JsonValue ->
Record is outside the ken of i'd say most. I'd be interested in an
expe
I think we should pull apart those concerns a little:
I am of the opinion that the API is more important at this stage than the
actual implementation, save for the places where having an API of a
particular shape mandates implementation choices.
> The JsonNull/JsonNumber/JsonString/JsonValue here
something implementing an
interface differently).
On Fri, May 16, 2025 at 2:26 PM wrote:
>
>
> ------
>
> *From: *"Ethan McCue"
> *To: *"Remi Forax"
> *Cc: *"Paul Sandoz" , "core-libs-dev" <
> core-libs-
I present for your consideration the library I made when spiraling about
this problem space a few years ago
https://github.com/bowbahdoe/json
https://javadoc.io/doc/dev.mccue/json/latest/dev.mccue.json/dev/mccue/json/package-summary.html
Notably missing during the design process here were patter
Just so there are some strawman arguments against:
* Does altering Set.of to maintain order increase its memory footprint? If
the answer is yes, does that matter? If the answer is no, is there a new
standalone collection type to add?
SetThatIsOrderedInTheSameMannerAsPythonsSetIsOrderedAndThusHasNo
esentable in module infos regardless.
On Mon, Dec 16, 2024 at 10:40 PM Peter Firmstone <
peter.firmst...@zeus.net.au> wrote:
> If you don't wish to use version numbers, why not generate a SHA256 hash
> of each module instead?
>
> --
> Regards,
>
> Peter
>
> O
ory.
On Mon, Dec 16, 2024 at 2:26 AM Alan Bateman
wrote:
> On 16/12/2024 02:12, Ethan McCue wrote:
> > I am experimenting with making a package repository where modules are
> > the artifacts (bundled as JMODs) and not jars. In this context we lack
> > information about what ve
p.
On Sat, Dec 14, 2024 at 12:20 AM Alan Bateman
wrote:
> On 14/12/2024 08:02, Ethan McCue wrote:
> > Hi all,
> >
> > Not sure if this is best for core-libs or langtools, but best I can
> > tell there is no way to determine the hash of a module programmatically.
>
&g
Hi all,
Not sure if this is best for core-libs or langtools, but best I can tell
there is no way to determine the hash of a module programmatically.
Hashes of dependent modules are recorded in JMOD files
jmod describe jdks/aarch64_windows/jmods/java.base.jmod
java.base@23.0.1
platform linu
Placement in the standard library aside, I think Java needs value types and
patterns before a non-throwing version of Math.multiplyExact can be made
that achieves the same semantic goals.
switch (Maths.multiplyExact(a, b)) {
case Product.of(long result) -> {}
case Product.overflow() -> {}
Hi all,
Elliot[1] and I have been digging into the HTTP(S) server implementation
provided by the jdk.httpserver module.
It hasn't taken long to notice that the provided implementation
is...lacking. Both in performance, as it places extremely low and errors
out on benchmarks [2][3], and in polish,
One of the examples in the String Template JEPs, and a stated motivating
factor behind its design, is SQL. Template processors are objects so that
use cases like constructing SQL statements aren't injection prone.
The questions I want to pose are:
* Should java.sql provide an implementation of Te
tests are using 'var' and different collections
> heavily.
>
> And the situation is a little worst than that because in between now and
> the time people will use Java 21, a lot of codes will be written using Java
> 11 and 17 and may found incompatible later.
>
> A
ufficiently disruptive, we
> conduct a corpus experiment to evaluate the impact on the change on many
> public Java libraries. Back in Project Coin in JDK 7, that basic approach
> was used to help quantify various language design choices and the
> infrastructure to run such experiments h
I guess this a good time to ask, ignoring the benefit part of a cost
benefit analysis, what mechanisms do we have to measure the number of
codebases relying on type inference this will break?
Iirc Adoptium built/ran the unit tests of a bunch of public repos, but it's
also a bit shocking if the jtr
Link to the proxy which I forgot to include
https://gist.github.com/bowbahdoe/eb29d172351162408eab5e4ee9d84fec
On Tue, Feb 28, 2023 at 12:16 PM Ethan McCue wrote:
> As an update to my character arc, I documented and wrote up an explanation
> for the prototype library I was working
.reveddit.com/y/rzwitserloot/?after=t1_jacpsj6&limit=1&sort=new&show=t1_jaa3x0q&removal_status=all
On Fri, Dec 16, 2022 at 6:23 PM Ethan McCue wrote:
> Sidenote about "Project Galahad" - I know Graal uses json for a few things
> including a reflection-config.js
bad, actually.
[1]: I do apologize for the code sketches consistently being "what I think
an interaction with a tree api should look like."
That is what I have been thinking about for a while so it's hard to resist.
[2]: https://youtu.be/dOgfWXw9VrI?t=1225
On Thu, Dec 15, 2022 at 6:
On Thu, Dec 15, 2022 at 6:26 PM Ethan McCue wrote:
> > The 95%+ use case for working with JSON for your average java coder is
> best done with data binding.
>
> To be brave yet controversial: I'm not sure this is neccesarily true.
>
> I will elaborate and respond to
>>it, that is that number, as long.
>>- If the element is a string, parse it into a long, then get me a
>>list with this one long value (because IEEE double rules mean sometimes
>> you
>>have to put these things in string form or they get mangled by
I'm writing this to drive some forward motion and to nerd-snipe those who
know better than I do into putting their thoughts into words.
There are three ways to process JSON[1]
- Streaming (Push or Pull)
- Traversing a Tree (Realized or Lazy)
- Declarative Databind (N ways)
Of these, JEP-198 expli
Subtract one negative from that last clause
On Wed, Dec 14, 2022 at 12:02 PM Ethan McCue wrote:
> Thank you!
>
> And yeah - I'll send a separate email opining on the directions that can
> go.
>
> The features that should be incorporated/designed for (value
> classe
more real than in 2014
when the JEP was made - so I don't think this isn't a horrible time to
start some movement.
On Wed, Dec 14, 2022 at 3:14 AM Alan Bateman
wrote:
> On 14/12/2022 03:36, Ethan McCue wrote:
> > Hey all,
> >
> > I'm doodling on JEP-198, an
Hey all,
I'm doodling on JEP-198, and I was wondering if anyone had a line on the
boilerplate needed to add a new module to the build.
Just adding
src/
java.json/
share/
classes/
module-info.java
java/
json/
Json.java
...
was enough
users avoid allocations.
[1]:
https://mail.openjdk.org/pipermail/core-libs-dev/2022-September/094231.html
[2]:
https://docs.gradle.org/current/userguide/publishing_gradle_module_metadata.html
On Fri, Nov 25, 2022 at 9:08 AM Alan Bateman
wrote:
> On 25/11/2022 13:27, Ethan McCue wrote:
ng to.
On Fri, Nov 25, 2022 at 2:52 AM Alan Bateman
wrote:
> 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 mo
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 i
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 a
(always so hard to remember to reply all)
On Thu, Nov 24, 2022 at 8:26 PM Ethan McCue wrote:
> The use here is giving help to the user on
> misspelled classes/methods/fields like "new ArayList".
>
> For now we've just copy pasted the class since that seems the leas
There are some modules like jdk.internal.le which contain no
publicly exported packages. In some of the experimentation we are doing, We
want to use the jdk.internal.org.jline.utils.Levenshtien class from
jdk.compiler.
Mechanically, we can do this without creating any new modules by adding a
quali
t; On Fri, Nov 18, 2022 at 6:23 PM Ethan McCue wrote:
>
>> I think there is potentially actionable feedback in that the exception
>> thrown when users bump into this limitation kinda sucks
>>
>> jshell> Arrays.asList(1, 2, 3).add(4);
>> | Exception j
st regards,
>>
>> -- daniel
>>
>> On 18/11/2022 16:29, Andreas Røsdal wrote:
>> > Yes, the exception comes when adding objects to the returned list. So I
>> > would like a convenient way to use Arrays to convert an array to a
>> > normal modifiable j
at 11:29 AM Andreas Røsdal
wrote:
> Yes, the exception comes when adding objects to the returned list. So I
> would like a convenient way to use Arrays to convert an array to a normal
> modifiable java.util.ArrayList, instead of this AbstractList.
>
>
> On Fri, Nov 18, 2022 at 5:2
s://xkcd.com/927/). For example, if the JDK were to adopt Gradle as
> the tool to use to build the JDK, it could de-facto become the “JDK build
> tool”. Other projects formerly part of the JDK, like JavaFX, are already
> using Gradle (though not as effectively as they could).
>
> Any
rent philosophies such that
> agreeing on a single dependency management tool may be too ambitious.
>
> Scott
>
>
> On Sep 9, 2022, at 9:59 AM, Ethan McCue wrote:
>
> This email is mostly to test the waters, I expect some hostility.
>
> Say, as a premise, that an A
This email is mostly to test the waters, I expect some hostility.
Say, as a premise, that an API for resolving external dependencies was
something that the JDK concerned itself with providing.
I think the foundation for that is there - the POM v4 format is more or
less around forever, maven style
ich from the conversation so
far isn't that unrealistic
On Fri, Aug 26, 2022 at 11:20 AM John Hendrikx
wrote:
>
> On 24/08/2022 15:38, Ethan McCue wrote:
>
> A use case that doesn't cover is adding to a collection.
>
> Say as part of a method's contract you state
ote:
>
>
> --
>
> *From: *"Ethan McCue"
> *To: *"Remi Forax"
> *Cc: *"John Hendrikx" , "core-libs-dev" <
> core-libs-dev@openjdk.org>
> *Sent: *Wednesday, August 24, 2022 4:27:01 PM
> *Subject: *Re: Proposal: C
ew owners
> back.
>
> Its cleaner to design the APIs to be defensive, either the API should
> handle the List creation itself (and only expose immutable Lists) or make
> defensive copies before using or saving it.
>
> $0.02, Roger
>
>
> On 8/24/22 9:38 AM, Etha
}
}
}
}
On Wed, Aug 24, 2022 at 10:03 AM Remi Forax wrote:
>
>
> --
>
> *From: *"Ethan McCue"
> *To: *"John Hendrikx"
> *Cc: *"core-libs-dev"
> *Sent: *Wednesday, August 24, 2022 3:38:26 PM
>
but I think that's an acceptable trade-off.
>
> --John
>
> PS. Chosen names are just for illustration; there is some discussion as
> what "unmodifiable" vs "immutable" means in the context of collections that
> may contain elements that are mutable. In this
er/src/java.base/share/classes/java/util/List.java#L1068
>
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/ImmutableCollections.java#L168
>
> Paul.
>
> > On Aug 23, 2022, at 4:49 PM, Ethan McCue wrote:
> >
> > Hi all,
> >
Hi all,
I am running into an issue with the collections framework where I have to
choose between good semantics for users and performance.
Specifically I am taking a java.util.List from my users and I need to
choose to either
* Not defensively copy and expose a potential footgun when I pass that
47 matches
Mail list logo
