Changeset: 95a356ccc6a0
Author:amurillo
Date: 2016-07-14 15:47 +
URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/95a356ccc6a0
Added tag jdk-9+127 for changeset a42768b48cb0
! .hgtags
Changeset: e47c36d0fc79
Author:alanb
Date: 2016-07-15 06:44 +0100
URL:
At least someone replied to my question.
On 7/14/16 5:44 AM, Russell Gold wrote:
On Jul 12, 2016, at 1:31 PM, Eric Johnson wrote:
What infuriates me is that in all this discussion, I don't see anyone talking about a
threat analysis. What are we trying to protect, from whom, and why? I see com
Agreed with Jason. It's okay to say thank you, but no thank you. A third
party library maintainer, no matter how well-intentioned, has absolutely no
say over the way I design, assemble, and run my operations. Reflection is
risky, yes, but it's my risk to take. If I bust down the wrong wall and do
s
Changeset: b7ce08828bfc
Author:jjg
Date: 2016-07-14 15:28 -0700
URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/b7ce08828bfc
update javadoc usage messages for --release
!
src/jdk.javadoc/share/classes/com/sun/tools/javadoc/resources/javadoc.properties
!
src/jdk.javadoc/
> On Jul 14, 2016, at 5:07 PM, John Rose wrote:
>
> On Jul 14, 2016, at 4:51 AM, 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 what
>> setAc
Changeset: f4927f52aa7b
Author:bpatel
Date: 2016-07-05 13:30 -0700
URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/f4927f52aa7b
8157987: overview-summary.html generated by javadoc should include module
information
Reviewed-by: jjg, ksrini
!
src/jdk.javadoc/share/classes
> On Jul 14, 2016, at 4:56 AM, Stephane Epardaud wrote:
>
> So how about a Java Language annotation (say, @RequiresExport) that we could
> place on IoC framework annotation definitions (say, @Entity, from JPA) that
> would tell the compiler that any type annotated with @Entity must be exported
On Jul 14, 2016, at 4:51 AM, 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 what
> setAccessible is used for. It would certainly be nice for a
> fr
On 14/07/2016 21:20, Jochen Theodorou wrote:
What I would wish for at this moment is a document explaining the
runtime aspects of the module system, including limitations reflection
and normal method calls, as well as things like layers / runtime
generated modules - as well as the methods t
On 14.07.2016 17:54, mark.reinh...@oracle.com wrote:
2016/7/14 5:35:25 -0700, Andrew Haley :
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 order to give us the feedback we need to ratify the JD
Changeset: ecacc79ccd57
Author:darcy
Date: 2016-07-07 10:16 -0700
URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ecacc79ccd57
8152174: Type annotations with a missing type throw NullPointerException
Reviewed-by: jfranck
! src/java.base/share/classes/sun/reflect/annotation/Type
Changeset: 0c671c1b6e7a
Author:amurillo
Date: 2016-07-07 18:34 +
URL: http://hg.openjdk.java.net/jigsaw/jake/rev/0c671c1b6e7a
Merge
Changeset: 802f90289006
Author:erikj
Date: 2016-07-08 08:55 +0200
URL: http://hg.openjdk.java.net/jigsaw/jake/rev/802f90289006
80
Changeset: fe4e11bd2423
Author:amurillo
Date: 2016-07-14 15:47 +
URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/fe4e11bd2423
Added tag jdk-9+127 for changeset 06d706c70634
! .hgtags
Changeset: 1a5ac817edf5
Author:alanb
Date: 2016-07-14 17:34 +0100
URL: ht
Changeset: 25442c9a17c8
Author:amurillo
Date: 2016-07-07 18:35 +
URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/25442c9a17c8
Merge
-
src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfigVerifier.java
-
src/jdk.vm.ci/share/classes/jdk.vm.
Changeset: 1f093d3f8cd9
Author:amurillo
Date: 2016-07-14 15:47 +
URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/1f093d3f8cd9
Added tag jdk-9+127 for changeset 8fab452b6f47
! .hgtags
Changeset: 7c54157a0468
Author:alanb
Date: 2016-07-14 17:39 +0100
URL: ht
Changeset: c52e02265f8a
Author:lana
Date: 2016-06-20 06:13 -0700
URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/c52e02265f8a
8159324: JDK9 message drop 10 resource updates
Summary: JDK9 message drop resource updates - openjdk
Reviewed-by: rfield, alanb, joehw
Contributed-by: l
Changeset: 3aed7bc5b6b4
Author:amurillo
Date: 2016-07-14 15:47 +
URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/3aed7bc5b6b4
Added tag jdk-9+127 for changeset ff07be6106fa
! .hgtags
Changeset: a7f4e5226a14
Author:alanb
Date: 2016-07-14 17:34 +0100
URL:
On 14/07/16 16:54, mark.reinh...@oracle.com wrote:
> 2016/7/14 5:35:25 -0700, Andrew Haley :
>> 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 order to give us the feedback we need to ratify
2016/7/14 5:35:25 -0700, Andrew Haley :
> 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 order to give us the feedback we need to ratify the JDK 9
> specification. But you know where this is g
I'll raise this subject over in the Log4J community where I am also active.
Just note 1.x is EOL and is no longer maintained. Moving to 2.x is a whole
redesign and the two are not compatible (neither binary nor configuration
wise). 2.x is way better but it's not drop-and-replace. If you have a
depe
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 of
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 should
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 established
>>> consensus, preferably un
On Thu, Jul 14, 2016 at 9:10 AM, dalibor topic wrote:
>
> so it looks like it's getting adopted a little bit faster than log4j 1.x
> originally was.
Yes my concern there esp is around the way in which it breaks: subtle
change in behavior, not some obvious exception message (such as when
someone a
On 07/14/2016 05:28 AM, Alan Bateman wrote:
On 14/07/2016 11:16, Andrew Haley wrote:
:
OK. But "in the very long term" such a basic language change needs
all stakeholders to be consulted.
I agree (although it's not really a language change in that it's API way
to suppress access checks specif
Thanks for the comments/suggestion, and apologies for a belated reply.
I've updated the patch to use -Xlint:exports, which I agree is more
consistent with the existing lint keys.
The updated patch for the first phase is here:
http://cr.openjdk.java.net/~jlahoda/8153362/langtools.02-phase1/
An
On 14.07.2016 14:31, Robert Muir wrote:
On Thu, Jul 14, 2016 at 8:22 AM, dalibor topic wrote:
I'd suggest moving on [1] to a maintained version of that dependency, such
as 2.6.x currently seems to be.
I'm not complaining about the issue: I'm simply trying to put things
in perspective, com
> On Jul 12, 2016, at 1:31 PM, Eric Johnson wrote:
>
> What infuriates me is that in all this discussion, I don't see anyone talking
> about a threat analysis. What are we trying to protect, from whom, and why? I
> see comments about how implementation details of the JRE (such as "com.sun"
>
Hello,
Please review the fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8159214
The fix is located at:
http://cr.openjdk.java.net/~naoto/8159214/webrev.04/
Naoto
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 what
>> setAccessible is used fo
On Thu, Jul 14, 2016 at 8:22 AM, dalibor topic wrote:
>
>
> I'd suggest moving on [1] to a maintained version of that dependency, such
> as 2.6.x currently seems to be.
I'm not complaining about the issue: I'm simply trying to put things
in perspective, communicate a bit of a reality check as to
On 14.07.2016 13:37, Robert Muir wrote:
On Tue, Jul 12, 2016 at 4:25 PM, Alan Bateman wrote:
Java 9 breaks log4j 1.2.x out of box. Think about how widely used that
one is! And its no longer maintained!
I'd suggest moving on [1] to a maintained version of that dependency,
such as 2.6.x curr
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 what
setAccessible is used for. It would certainly be nice for a
framework to be ab
On 14/07/2016 12:37, Robert Muir wrote:
:
Java 9 breaks log4j 1.2.x out of box. Think about how widely used that
one is! And its no longer maintained!
Sure, its only if you use MDC, and its not even Jigsaw that does it
(relates to version changes). See
https://github.com/elastic/elasticsearch/
On Tue, Jul 12, 2016 at 4:25 PM, Alan Bateman wrote:
> Going off-topic slightly but when you do run into issues and if they aren't
> already listed as compatibility issues then please bring them up. So far
> then I think the vast majority of issues that we have heard about relate to
> the changes
2016-07-14 12:40 GMT+02:00 dalibor topic :
> I have to run to catch my whale bus now.[0]
It's a set of incremental updates that made France being slightly
different than this vision, it's a good thing to discuss some of those
changes that will motivate wether or not whales will be able to
instrum
On 14.07.2016 11:57, Andrew Dinn wrote:
On 14/07/16 10:44, dalibor topic wrote:
I believe that this was discussed before at
http://mail.openjdk.java.net/pipermail/jpms-spec-observers/2015-September/000122.html
Thank you for the link, Dalibor. It does indeed appear that the
possibility of rem
> On 13 Jul 2016, at 23:33, Paul Benedict wrote:
>
> If I may opine on this matter -- and do so respectfully toward all parties
> mentioned -- aside from Tim Ellison responding first, every other message
> is between David and Mark. The discussion thread is a really good read and
> a strong poin
On 14/07/2016 11:16, Andrew Haley wrote:
:
OK. But "in the very long term" such a basic language change needs
all stakeholders to be consulted.
I agree (although it's not really a language change in that it's API way
to suppress access checks specified by the language).
:
Yes, indeed, and t
On 14/07/16 10:56, Alan Bateman wrote:
> This project (and JSR) is not proposing to remove setAccessible as that
> would break many things. The comment that Andrew Dinn picked up started
> with "In the very long term ..." and is a throw away comment on where
> the platform needs to go long term. In
On 13/07/2016 19:10, Sibabrata Sahoo wrote:
Hi,
Please review the following patch for "Additional modular test for
"auth.login.defaultCallbackHandler" property".
Probably best to bring this to security-dev for review + sponsor.
-Alan.
On 14/07/16 10:44, dalibor topic wrote:
> I believe that this was discussed before at
> http://mail.openjdk.java.net/pipermail/jpms-spec-observers/2015-September/000122.html
Thank you for the link, Dalibor. It does indeed appear that the
possibility of removal of this API has indeed been mentioned
So how about a Java Language annotation (say, @RequiresExport) that we
could place on IoC framework annotation definitions (say, @Entity, from
JPA) that would tell the compiler that any type annotated with @Entity
must be exported?
That would solve the issue of making sure that users would not
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 established
consensus, preferably under the aegis of the JSR EG. It certainly does
not seem
On 14.07.2016 10:59, Andrew Dinn wrote:
On 13/07/16 17:00, Alan Bateman wrote:
On 13/07/2016 12:47, David M. Lloyd wrote:
Isn't that what this entire thread is about? And also, what the whole
#ReflectiveAccessToNonExportedTypes issue is about?
I think that's a good question, esp as some fra
On 13/07/16 17:00, Alan Bateman wrote:
> On 13/07/2016 12:47, David M. Lloyd wrote:
>> Isn't that what this entire thread is about? And also, what the whole
>> #ReflectiveAccessToNonExportedTypes issue is about?
> I think that's a good question, esp as some frameworks allow for
> annotations or c
46 matches
Mail list logo
