ed classes and fields, for example.
Is there a proposal to allow this?
--
Andrew Haley (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
On 19/05/17 11:11, Peter Levart wrote:
> On 05/19/2017 01:17 AM, Nicolai Parlog wrote:
>> With illegal access being permitted by default much fewer developers
>> will be aware of the problem and much less pressure will be put on
>> library and framework maintainers as well as on project management
On 18/05/17 15:48, mark.reinh...@oracle.com wrote:
> - The proposed default mode enables the run-time system to issue a
> warning message, possibly at some time long after startup, without
> having been explicitly requested to do so. This may be a surprise
> in production environments,
On 04/04/17 17:35, mark.reinh...@oracle.com wrote:
> This does raise another question, though: Should we use "aarch32"
> instead of "arm32" for the 32-bit ARM architecture?
Probably not. I believe that "aarch32" is historical revisionism
coming from ARM: it didn't exist as a name before AArch64
On 04/04/17 16:12, mark.reinh...@oracle.com wrote:
> The trouble here is that "arm64" and "aarch64" are effectively synonyms
> for the ISA, but in the JDK we've wound up using them as the names of
> two different ports.
>
> A JMOD file built for the 64-bit ARM architecture will (one hopes) run
>
On 15/02/17 21:56, Christian Thalinger wrote:
>
>> On Feb 14, 2017, at 4:38 AM, Andrew Haley <a...@redhat.com> wrote:
>>
>> On 14/02/17 14:37, Alan Bateman wrote:
>>> --patch-module can be used to patch any module in the boot layer. So if
>>&g
On 14/02/17 14:37, Alan Bateman wrote:
> --patch-module can be used to patch any module in the boot layer. So if
> you are looking to override or add classes then --patch-module should work.
Aha! Thanks,
Andrew.
On 14/02/17 13:34, Doug Simon wrote:
> I don’t know how one patches a module in the middle of the module
> graph. That is, we use --patch-module and --upgrade-module-path to
> override the jdk.vm.compiler module in the JDK. I don’t know what
> that means for modules such as jdk.aot that depend on
On 13/02/17 14:34, Alan Bateman wrote:
> The small subset of the JSR-250 defined "Common Annotations" that you
> see in Java SE is part of the web services stack that was added in Java
> SE 6. If it weren't for JAX-WS then these annotations would have no
> business being in Java SE or the JDK.
On 12/12/16 15:11, Uwe Schindler wrote:
> Thanks for taking care! Your proposal is still the "volatile only
> during safepoint" idea? I remember our discussions last FOSDEM and
> this is why I brought it up in this mail thread (see my original
> mail referring to your name).
It's the same idea.
On 12/12/16 14:56, Carsten Varming wrote:
> Do you have a pointer to a discussion about the changes to the JMM you
> propose?
I haven't written it up yet. There's a little bit more in the bug
description, but not much more than I've said here.
Andrew.
On 11/12/16 18:33, Peter Levart wrote:
> In order for deallocation to be effective and, above all, safe, user has
> to know the whole story of a buffer (s)he intends to deallocate and the
> story of all possible derived buffers. I don't believe one can create a
> safe program by choosing to
On 16/10/16 19:52, Robert Scholte wrote:
> To enforce the discipline, the java compiler should IMHO at least
> check if all required modules are indeed required and if the
> transitive required modules are indeed transitive.
How can the compiler possibly know this? There are ways of requiring
a
On 27/09/16 11:59, Alan Bateman wrote:
> javac could probably emit a better message here. In any case, can you
> add `--add-modules java.logging` to this. The issue is that you are
> compiling TestClass "as if" it's in the java.compiler module but that
> module does not require java.logging.
Sorry, this should be simple, but I don't get it.
In this program:
import java.util.logging.Logger;
public class TestClass {
}
aph@arm64:~/SPECjvm2016/unpack$
~/hs-comp/build/linux-aarch64-normal-server-release/images/jdk/bin/javac
--add-reads
On 15/07/16 19:29, Gregg Wonderly wrote:
>
>> On Jul 14, 2016, at 6:51 AM, Andrew Haley <a...@redhat.com> wrote:
>>
>>> This is #ReflectiveAccessToNonExportedTypes on the JSR 376 issues list.
>>> The problem is reasonably well understood and there are seve
On 14/07/16 16:54, mark.reinh...@oracle.com wrote:
> 2016/7/14 5:35:25 -0700, Andrew Haley <a...@redhat.com>:
>> At Red Hat we have many Java programmers. We also have many
>> customers who are Java programmers. I am trying to persuade people
>> to try out JDK 9 in or
On 14/07/16 11:28, Alan Bateman wrote:
>> > Yes, indeed, and that is potentially a significant problem. My
>> > comment stands: there is a serious possibility that his will make it
>> > impossible to use (non-exported) Jigsaw modules for some kinds of
>> > programming. This is exactly the kind
On 14/07/16 09:59, Andrew Dinn wrote:
> If this aspect of how Java currently works is to be removed then I
> believe it needs to be done so on the basis of a publicly established
> consensus, preferably under the aegis of the JSR EG. It certainly does
> not seem right to me that such a goal
On 14/07/16 10:56, Alan Bateman wrote:
> On 14/07/2016 10:03, Andrew Haley wrote:
>
>> On 14/07/16 09:59, Andrew Dinn wrote:
>>> If this aspect of how Java currently works is to be removed then I
>>> believe it needs to be done so on the basis of a publicly establi
On 14/07/16 13:14, Alan Bateman wrote:
>
> On 14/07/2016 12:51, Andrew Haley wrote:
>> :
>> Forgive me if I've missed something, but
>> #ReflectiveAccessToNonExportedTypes does not deal with the need to
>> make fields or methods accessible to the framework. That's
21 matches
Mail list logo
