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
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
t;
> 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 source incompatibility issue is not a big deal, as said in this thread,
&g
ve, 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 has been bu
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
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
/rzwitserloot/?after=t1_jacpsj6=1=new=t1_jaa3x0q_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.json. Food for thought.
>
> > the java.util.log ex
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:34 PM Ethan McCue wrote:
>
ers.
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 the
t 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 javascript-
>>eval
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
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
> classes/str
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, and I was wondering
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
ions.
[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:
>
> ...huh
&g
.
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 module for t
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 implementat
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
(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 least
>
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
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 java.lang.U
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 java.u
M 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:23 PM Ethan
ple, 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).
>
> Anyway, that’s just my 2 cents on the
ch 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 API for r
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
ation 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 that you take ownership of a
> L
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
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, Ethan McCue wr
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
> *Subject: *Re: Propo
ade-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 post, immutable refers to
> shallow immuta
a.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
33 matches
Mail list logo
