On 15/09/2021 11:34 pm, Aleksey Shipilev wrote:
On Wed, 15 Sep 2021 12:45:51 GMT, David Holmes wrote:
But perhaps we should be looking to remove "core" going forward?
Yes, we should consider it. @magicus [told
me](https://github.com/openjdk/jdk/pull/5440#discussion_r705464312) that somebody
You are right there's no check. One could be added by a motivated party ..
The minimum for Linux may be as old as 1.2.3 but safer is 2.3.1 since
we rely on that for AAT font support.
I can't (quickly) speak to any important bug fixes in later releases we
may need, just API / functionality.
-p
On Tue, 16 Mar 2021 16:56:22 GMT, Phil Race wrote:
>> From a build perspective this partially reverts
>> https://bugs.openjdk.java.net/browse/JDK-8249821 except that it keeps
>> the harfbuzz sources separate and still supports building and running
>> against a system harfbuzz which is only of
On Wed, 15 Sep 2021 10:02:19 GMT, Aleksey Shipilev wrote:
> As the follow-up for Zero-specific JDK-8273494, we might want to clean up
> build system logic for all VM variants: stop impersonating "server" VMs for
> all of them. This basically leaves "core" and "custom" variants to be handled
>
On Wed, 15 Sep 2021 09:55:22 GMT, Aleksey Shipilev wrote:
> Building with --with-jvm-variants=core currently produces a binary that
> replies an odd version:
>
>
> $ build/linux-x86_64-core-fastdebug/images/jdk/bin/java -version
> openjdk version "18-internal" 2022-03-15
> OpenJDK Runtime Envi
On Wed, 15 Sep 2021 08:42:40 GMT, Julia Boes wrote:
>> src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpsServer.java
>> line 152:
>>
>>> 150: return server;
>>> 151: }
>>> 152:
>>
>> Too bad we couldn't simplify the setting up a basic certificate for https.
>
> That wou
On Wed, 15 Sep 2021 12:45:51 GMT, David Holmes wrote:
> But perhaps we should be looking to remove "core" going forward?
Yes, we should consider it. @magicus [told
me](https://github.com/openjdk/jdk/pull/5440#discussion_r705464312) that
somebody wanted for "core" to remain, the last time the r
On Wed, 15 Sep 2021 12:56:34 GMT, David Holmes wrote:
> Did you test building all variants into one image?
Yes, I did, but I think the build system is confused about the VM feature sets.
I have a vague recollection that ether @magicus or someone else at one point
suggested eliminating multi-va
On Wed, 15 Sep 2021 10:02:19 GMT, Aleksey Shipilev wrote:
> As the follow-up for Zero-specific JDK-8273494, we might want to clean up
> build system logic for all VM variants: stop impersonating "server" VMs for
> all of them. This basically leaves "core" and "custom" variants to be handled
>
On Wed, 15 Sep 2021 09:55:22 GMT, Aleksey Shipilev wrote:
> Building with --with-jvm-variants=core currently produces a binary that
> replies an odd version:
>
>
> $ build/linux-x86_64-core-fastdebug/images/jdk/bin/java -version
> openjdk version "18-internal" 2022-03-15
> OpenJDK Runtime Envi
As the follow-up for Zero-specific JDK-8273494, we might want to clean up build
system logic for all VM variants: stop impersonating "server" VMs for all of
them. This basically leaves "core" and "custom" variants to be handled with
this patch.
Additional testing:
- [x] Linux x86_64 `core` bui
Building with --with-jvm-variants=core currently produces a binary that replies
an odd version:
$ build/linux-x86_64-core-fastdebug/images/jdk/bin/java -version
openjdk version "18-internal" 2022-03-15
OpenJDK Runtime Environment (fastdebug build 18-internal+0-adhoc.shade.jdk)
OpenJDK 64-Bit VM
On Wed, 15 Sep 2021 03:14:04 GMT, Jaikiran Pai wrote:
>> FWIW `.z` is the extension of the old Unix `compress` program.
>
>> FWIW `.z` is the extension of the old Unix `compress` program.
>
> Thank you Florent, I wasn't aware of that.
related PR for reference: https://github.com/openjdk/jdk/pul
> This change implements a simple web server that can be run on the
> command-line with `java -m jdk.httpserver`.
>
> This is facilitated by adding an entry point for the `jdk.httpserver` module,
> an implementation class whose main method is run when the above command is
> executed. This is th
On Thu, 9 Sep 2021 10:17:02 GMT, Aleksey Shipilev wrote:
> Currently, the build system defaults the libjvm.so location to "server".
> This makes looking for `libjvm.so` awkward, see JDK-8273487 for example. We
> need to see if moving the libjvm.so to a proper location breaks anything.
>
> Ad
On Thu, 9 Sep 2021 10:17:02 GMT, Aleksey Shipilev wrote:
> Currently, the build system defaults the libjvm.so location to "server".
> This makes looking for `libjvm.so` awkward, see JDK-8273487 for example. We
> need to see if moving the libjvm.so to a proper location breaks anything.
>
> Ad
On Tue, 14 Sep 2021 15:56:28 GMT, Jim Laskey wrote:
>> This change implements a simple web server that can be run on the
>> command-line with `java -m jdk.httpserver`.
>>
>> This is facilitated by adding an entry point for the `jdk.httpserver`
>> module, an implementation class whose main meth
On Wed, 15 Sep 2021 07:49:38 GMT, Michael McMahon wrote:
>> Or maybe - which would be more accurate:
>>
>>
>> with the given {@code statusCode} and the body bytes' length (or {@code -1}
>> if the body is empty).
>
> I agree with your second suggestion. It's better not to refer to the
> 'Conte
On Tue, 14 Sep 2021 16:45:08 GMT, Daniel Fuchs wrote:
>> Just a rewording, maybe.
>
> Hmm... Maye that should be "The response headers *are sent*". The non-obvious
> technical details is that the response headers are sent before the body - as
> soon as you call `sendResponseHeaders`. The link
On Tue, 14 Sep 2021 13:38:27 GMT, Daniel Fuchs wrote:
>> src/jdk.httpserver/share/classes/com/sun/net/httpserver/Headers.java line
>> 106:
>>
>>> 104: var h = headers.entrySet().stream()
>>> 105: .collect(Collectors.toUnmodifiableMap(
>>> 106: Ent
On Tue, 14 Sep 2021 16:51:40 GMT, Daniel Fuchs wrote:
>> src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpHandlers.java
>> line 129:
>>
>>> 127: * response body bytes are a {@code UTF-8} encoded byte
>>> sequence of
>>> 128: * {@code body}. The response {@linkplain
>>> Ht
21 matches
Mail list logo
