Hi Roger,
Thanks for doing this. Replacing ancient bytecode generators makes
it much easier to support new features like value types.
The diff of ProxyGenerator is not quite right (might be due to
the rename?) as some code are unchanged but shown as modified.
Thanks Claes,
I'll run some tests :)
Cheers,
Peter.
On 16/08/2019 9:14 PM, Claes Redestad wrote:
Hi Peter,
by explicitly ensuring the file system has been initialized before
installing a SecurityManager using a hook in System.setSecurityManager,
the patch at hand takes step to ensure things
Looks good.
Thanks,
Alexander
On 8/16/2019 1:36 PM, Andy Herrick wrote:
Please review the jpackage fix for bug [1] at [2].
This is a fix for the JDK-8200758-branch branch of the open sandbox
repository (jpackage).
[1] https://bugs.openjdk.java.net/browse/JDK-8229791
[2]
I've created https://bugs.openjdk.java.net/browse/JDK-8229840 to track
this task.
- Alexey
On 8/16/2019 5:04 PM, Alexander Matveev wrote:
Looks good.
Is it possible to have test for this new option? If yes, then as part
of this fix or as separate issue should be fine.
Thanks,
Alexander
Looks good.
Is it possible to have test for this new option? If yes, then as part of
this fix or as separate issue should be fine.
Thanks,
Alexander
On 8/16/2019 11:28 AM, Alexey Semenyuk wrote:
Please review the jpackage fix for bug [1] at [2].
This is a fix for the JDK-8200758-branch
Looks good.
- Alexey
On 8/16/2019 4:36 PM, Andy Herrick wrote:
Please review the jpackage fix for bug [1] at [2].
This is a fix for the JDK-8200758-branch branch of the open sandbox
repository (jpackage).
[1] https://bugs.openjdk.java.net/browse/JDK-8229791
[2]
Looks good.
Thanks,
Alexander
On 8/16/2019 12:12 PM, Alexey Semenyuk wrote:
Makes sense. Looks good then.
- Alexey
On 8/16/2019 3:08 PM, Andy Herrick wrote:
On 8/16/2019 2:26 PM, Alexey Semenyuk wrote:
Andy,
I think we want this change in all Windows jtreg tests as they all
use this
looks good
/Andy
On 8/16/2019 2:28 PM, Alexey Semenyuk wrote:
Please review the jpackage fix for bug [1] at [2].
This is a fix for the JDK-8200758-branch branch of the open sandbox
repository (jpackage).
- add --linux-app-category command line option
[1]
Please review the jpackage fix for bug [1] at [2].
This is a fix for the JDK-8200758-branch branch of the open sandbox
repository (jpackage).
[1] https://bugs.openjdk.java.net/browse/JDK-8229791
[2] http://cr.openjdk.java.net/~herrick/8229791/webrev.02/
Thanks,
Andy
Hi Vladimir,
I performed lots of benchmarks:
1. I updated my own sort-bench (jmh based) and run many tests (all
distributions + permutations) on integer arrays for sizes = 50, 100, 150, 200,
500, 1000, 2000:
In this benchmark, the metric is (minimum + stddev) and it gives the overall
score:
Please review an enhancement to replace the java.lang.reflect.Proxy
class file generation.
The new generator uses ASM and generates stackmaps. The implementation
follows
the same structure as before but has many differences as it leverages
ASM for generating the bytecode.
A Combo test is
Makes sense. Looks good then.
- Alexey
On 8/16/2019 3:08 PM, Andy Herrick wrote:
On 8/16/2019 2:26 PM, Alexey Semenyuk wrote:
Andy,
I think we want this change in all Windows jtreg tests as they all
use this windowless Hello test.
yes - but except for testing launching app from shortcut
On 8/16/2019 2:26 PM, Alexey Semenyuk wrote:
Andy,
I think we want this change in all Windows jtreg tests as they all use
this windowless Hello test.
yes - but except for testing launching app from shortcut of the
installed app, the automated tests run the app and capture it's output,
so
Please review the jpackage fix for bug [1] at [2].
This is a fix for the JDK-8200758-branch branch of the open sandbox
repository (jpackage).
- add --linux-app-category command line option
[1] https://bugs.openjdk.java.net/browse/JDK-8213941
2]
Andy,
I think we want this change in all Windows jtreg tests as they all use
this windowless Hello test.
- Alexey
On 8/16/2019 2:22 PM, Andy Herrick wrote:
Please review the jpackage fix for bug [1] at [2].
This is a fix for the JDK-8200758-branch branch of the open sandbox
repository
Please review the jpackage fix for bug [1] at [2].
This is a fix for the JDK-8200758-branch branch of the open sandbox
repository (jpackage).
[1] https://bugs.openjdk.java.net/browse/JDK-8229786
[2] http://cr.openjdk.java.net/~herrick/8229786
Thanks,
Andy
+1
On 8/16/19 12:51 PM, Sean Mullan wrote:
+1 from me as well.
--Sean
On 8/16/19 12:38 PM, Alan Bateman wrote:
On 16/08/2019 13:30, Claes Redestad wrote:
How about this:
http://cr.openjdk.java.net/~redestad/8229773/webrev.03/
Also simplified BuiltinClassLoader#getPermissions since the
+1 from me as well.
--Sean
On 8/16/19 12:38 PM, Alan Bateman wrote:
On 16/08/2019 13:30, Claes Redestad wrote:
How about this:
http://cr.openjdk.java.net/~redestad/8229773/webrev.03/
Also simplified BuiltinClassLoader#getPermissions since the jrt-specific
optimization is now redundant.
On 16/08/2019 13:30, Claes Redestad wrote:
How about this:
http://cr.openjdk.java.net/~redestad/8229773/webrev.03/
Also simplified BuiltinClassLoader#getPermissions since the jrt-specific
optimization is now redundant.
Looks good.
-Alan
On 2019-08-15 21:21, Alan Bateman wrote:
On 15/08/2019 16:22, Claes Redestad wrote:
(adding back core-libs-dev)
Hi Roger,
seems easy enough to add a writeReplace:
http://cr.openjdk.java.net/~redestad/8229773/webrev.02
This mostly looks good. In LazyCodeSourcePermissionCollection it think
Hi Peter,
by explicitly ensuring the file system has been initialized before
installing a SecurityManager using a hook in System.setSecurityManager,
the patch at hand takes step to ensure things stay neutral w.r.t.
Permission initialization order when using any SecurityManager. It's not
Hello Alan,
Yes, we are aware of those issues.
I mean documenting that system Permission classes should be loaded
before setting a custom SecurityManager, accessing the file system is
important, so if you haven't loaded the necessary classes before setting
a custom SecurityManager, it won't
On 15/08/2019 12:53, Andrew Dinn wrote:
Hi Alan,
Any further input on this patch forthcoming?
I think the main changes since I looked at it previously have been in
the tests.
On non-Linux platforms, FileChannel.map should throw UOE when invoked
with a mode map of READ_ONLY_SYNC or
On 15/08/2019 23:20, Peter Firmstone wrote:
:
The following code is included in the constructor of our
SecurityManager implementation, I suspect we may need to add some
classes to this list, perhaps this is something that needs documenting?
The checkPermission method of custom security
24 matches
Mail list logo
