* Peter Firmstone:
> From our discussions, my interpretation is that OpenJDK is constrained
> by corporate security policy; any issues with SecurityManager
> infrastructure will be treated as confidential security issues and
> have to be fixed with internal resources. Community volunteers won't
>
On 2/08/2021 4:48 am, Alan Bateman wrote:
On 01/08/2021 15:28, Uwe Schindler wrote:
:
What I figured out: You intend to remove SecurityManager because it
does not fit your latest ideas how Java threads should behave. I know
the main problem is not "SecurityManager is too complex / too slow /
On Mon, 14 Jun 2021 17:00:29 GMT, Andrey Turbanov
wrote:
> I found few places, where code initially perform `Object[]
> Colleciton.toArray()` call and then manually copy array into another array
> with required type.
> This PR cleanups such places to more shorter call `T[]
> Collection.toArra
On Sat, 31 Jul 2021 20:42:10 GMT, Igor Ignatyev wrote:
>> Hi all,
>>
>> could you please review this big tedious and trivial(-ish) patch which moves
>> `sun.hotspot.WhiteBox` and related classes to `jdk.test.whitebox` package?
>>
>> the majority of the patch is the following substitutions:
>>
On Sat, 31 Jul 2021 20:42:10 GMT, Igor Ignatyev wrote:
>> Hi all,
>>
>> could you please review this big tedious and trivial(-ish) patch which moves
>> `sun.hotspot.WhiteBox` and related classes to `jdk.test.whitebox` package?
>>
>> the majority of the patch is the following substitutions:
>>
On 01/08/2021 15:28, Uwe Schindler wrote:
:
What I figured out: You intend to remove SecurityManager because it does not fit your latest ideas
how Java threads should behave. I know the main problem is not "SecurityManager is too complex
/ too slow / wrongly used /..." -- the main problem of so
On 01.08.21 16:28, Uwe Schindler wrote:
The problem is: you deprecate for removal without offering any API to replace
the main pain points:
...
- Disable damn java serialization completely
JDK 9+ JVM flag / security property, see JEP 290
-Djdk.serialFilter=!*
regards,
michael
Hi Peter.
- JEP 411, like every spec-changing JEP, is meant to allow those that use the
removed functionality
a migration path forward. The API elements that are deprecated for removal have
some years before
they are actually removed, so there’s nothing too urgent other than beginning
to think
On 01.08.21 18:35, Michael Bien wrote:
On 01.08.21 16:28, Uwe Schindler wrote:
The problem is: you deprecate for removal without offering any API to
replace the main pain points:
...
- Disable damn java serialization completely
JDK 9+ JVM flag / security property, see JEP 290
-Djdk.serialFil
Hi Andrew,
> > I'm working on the assumption that OpenJDK will close any external holes
> > currently defended by permission checks. It would be good if the JDK
> > was secure by default, with properties required to be set for allowing
> > such things as agents, management, parsing xml and serial
On 01/08/2021 03:14, Peter Firmstone wrote:
I'm working on the assumption that OpenJDK will close any external holes
currently defended by permission checks. It would be good if the JDK
was secure by default, with properties required to be set for allowing
such things as agents, management, pa
11 matches
Mail list logo
