On 03/04/2017 22:38, Simon Nash wrote:
:
My comment was regarding the change of value for OS_NAME. Given that
there is
no compatibility issue here, does it make sense for the new value to
be something
that is no longer current in Apple terminology?
Just on compatibility then just to say tha
On 03/04/2017 21:54, Stephen Felts wrote:
The jlr.Module -> jl.Module can cause some other problems.
It breaks source code compatibility
That's right, it's a source incompatible change (one that arises
whenever a new type is added to java.lang.). The impact section of the
proposal [1] has mo
> On Apr 3, 2017, at 4:10 PM, mark.reinh...@oracle.com wrote:
>
> 2017/4/3 14:50:52 -0700, mandy.ch...@oracle.com:
>>> On Apr 3, 2017, at 2:39 PM, mark.reinh...@oracle.com wrote:
>>> 2017/4/3 13:35:30 -0700, si...@cjnash.com:
...
I am not sure why we would change to osx for Mac wh
2017/4/2 23:28:02 -0700, ch...@hazelcast.com:
> First of all, I understand the idea behind this change and I think it
> certainly makes sense but from my impression the default is wrong, as
> Volker already pointed out.
>
> Over the last few days I (with the help of others) put together a
> docume
2017/4/3 14:50:52 -0700, mandy.ch...@oracle.com:
>> On Apr 3, 2017, at 2:39 PM, mark.reinh...@oracle.com wrote:
>> 2017/4/3 13:35:30 -0700, si...@cjnash.com:
>>> ...
>>>
>>> I am not sure why we would change to osx for Mac when the Mac developers
>>> have recently dropped the Mac OS X terminology
2017/4/3 10:52:02 -0700, alasdair.notting...@gmail.com:
> I’m the lead for WebSphere Liberty at IBM. Liberty uses a java agent,
> and this proposal will affect us. Our Java Agent is used to update the
> bytecode of our classes to add in instrumentation for debug logging
> and performance monitoring
2017/4/3 9:44:43 -0700, Andrew Dinn :
> On 03/04/17 16:50, Alan Bateman wrote:
>> ...
>>
>> Java SE 9 / JDK 9 brings strong encapsulation. The access control for
>> the Java Language and VM has been extended to modules so that modules
>> that don't want their internals to be accessed from code out
> On Apr 3, 2017, at 2:39 PM, mark.reinh...@oracle.com wrote:
>
> 2017/4/3 13:35:30 -0700, si...@cjnash.com:
>> On 03/04/2017 21:15, mark.reinh...@oracle.com wrote:
>>> 2017/4/3 11:41:03 -0700, mandy.ch...@oracle.com:
Webrev:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8175819/webre
2017/4/3 13:35:30 -0700, si...@cjnash.com:
> On 03/04/2017 21:15, mark.reinh...@oracle.com wrote:
>> 2017/4/3 11:41:03 -0700, mandy.ch...@oracle.com:
>>> Webrev:
>>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8175819/webrev.00/
>>>
>>> ...
>>>
>>> This shows the old and new value of OS_NAME
On 03/04/2017 22:07, Mandy Chung wrote:
On Apr 3, 2017, at 1:35 PM, Simon Nash wrote:
On 03/04/2017 21:15, mark.reinh...@oracle.com wrote:
I am not sure why we would change to osx for Mac when the Mac developers
have recently dropped the Mac OS X terminology and changed it to macOS.
Just to
I note that Phil pushed the changes to OpenJFX in time for build 164 so
that problem, at least, is resolved.
-- Kevin
Stephen Felts wrote:
The jlr.Module -> jl.Module can cause some other problems.
It breaks source code compatibility that is totally unrelated to JDK9 (code
that has been
> On Apr 3, 2017, at 1:35 PM, Simon Nash wrote:
>
> On 03/04/2017 21:15, mark.reinh...@oracle.com wrote:
>
> I am not sure why we would change to osx for Mac when the Mac developers
> have recently dropped the Mac OS X terminology and changed it to macOS.
Just to be clear, there is no plan to
On Apr 3, 2017, at 12:03 PM, Gregg Wonderly wrote:
>
> Alan, it is exactly this kind of comment from the team which just tears apart
> the whole view that you might actually be considering what everyone in the
> Java community needs.
I think *this* comment is unfair to Alan. I read Alan as s
The jlr.Module -> jl.Module can cause some other problems.
It breaks source code compatibility that is totally unrelated to JDK9 (code
that has been compiling for 20 years). Unfortunately, the name Module is
pretty popular – I saw 7 occurrences of the following.
$ cat Test.java
import t
On 03/04/2017 21:15, mark.reinh...@oracle.com wrote:
2017/4/3 11:41:03 -0700, mandy.ch...@oracle.com:
Webrev:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8175819/webrev.00/
...
This shows the old and new value of OS_NAME/OS_ARCH properties
in the `release` file:
JDK 8
2017/4/3 11:41:03 -0700, mandy.ch...@oracle.com:
> Webrev:
> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8175819/webrev.00/
>
> ...
>
> This shows the old and new value of OS_NAME/OS_ARCH properties
> in the `release` file:
>
> JDK 8 JDK 9
> -
Hi,
I can share three examples of agents I've developed the past few
years where this change is or could have been disruptive to some extent:
*JettyConsole:*
JettyConsole takes war files and make them "executable" with java -jar by
embedding the Jetty servlet container inside the war file. HTTP/
On 03/04/2017 19:49, Rafael Winterhalter wrote:
I just found out about this change to restrict redefining some modules:
http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/52cdbd4a5999 and I can
only repeat my warning that this further restriction will make it harder to
migrate to Java 9 and migh
Yes that is really good. I was really happy to see that. I can’t wait for a
Java 8 release that contains the fix (u121 on the mac does not). The reason I
brought it up is because that long standing weird error message is resolved
using the attach api to add the agent. I’m sure I’m not the only p
Alan, it is exactly this kind of comment from the team which just tears apart
the whole view that you might actually be considering what everyone in the Java
community needs. There are people who always deploy with a security manager
because they are deploying Java on a network or with Subject
We have a number of changes accumulated in the jake forest that we need
to bring to jdk9/dev soon.
The bulk of changes relate to #MoveModuleAndLayerClasses [1] and so a
bit disruptive for those using the JDK 9 EA builds and the new APIs.
The revised proposed for #VersionsInModuleNames reverts
Again, I want to stress that from my position we are completely ignoring
desktop Java users who will update Java to JDK 9 and never know that they’ve
broken something by doing that.
Java is not a server only enterprise deployed environment…
Gregg
> On Apr 2, 2017, at 6:39 PM, Stephen Felts wr
I just found out about this change to restrict redefining some modules:
http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/52cdbd4a5999 and I can
only repeat my warning that this further restriction will make it harder to
migrate to Java 9 and might break tools in the process. It does neither
seem
On 03/04/2017 18:52, Alasdair Nottingham wrote:
Hi,
I’m the lead for WebSphere Liberty at IBM. Liberty uses a java agent, and this
proposal will affect us. Our Java Agent is used to update the bytecode of our classes
to add in instrumentation for debug logging and performance monitoring. In g
Webrev:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8175819/webrev.00/
This revisits the OS name and arch in packaging JDK modules
to extend the module descriptor with ModuleTarget class file
attribute. We considered matching with the system properties.
Linux x64 JDK can run on a system who
Changeset: 4205f4220e41
Author:alanb
Date: 2017-04-03 14:57 +0100
URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4205f4220e41
Remove unused methods
! src/java.base/share/classes/java/lang/System.java
! src/java.base/share/classes/jdk/internal/misc/JavaLangAccess.java
! src/jav
Hi,
I’m the lead for WebSphere Liberty at IBM. Liberty uses a java agent, and this
proposal will affect us. Our Java Agent is used to update the bytecode of our
classes to add in instrumentation for debug logging and performance monitoring.
In general it is attached via -javaagent, which wont b
On [1] the conclusion given the premise is not unreasonable. The file
name can be easily changed by a developer or build tool to match the
expected module name. However, it is the premise I strongly object to:
"The fundamental problem here is that we're trying to infer a .. name..."
Inferring a n
Hello Mandy,
thank you.
I did run it on Windows 10.
> Am 03.04.2017 um 19:27 schrieb Mandy Chung :
>
> I created a JBS issue:
> https://bugs.openjdk.java.net/browse/JDK-8177980
>
> What platform are you running on? This works on linux but I can reproduce
> the problem on OSX (related to
I created a JBS issue:
https://bugs.openjdk.java.net/browse/JDK-8177980
What platform are you running on? This works on linux but I can reproduce the
problem on OSX (related to case-insensitive file system).
Mandy
> On Apr 3, 2017, at 8:54 AM, Rabea Gransberger wrote:
>
> Hello,
>
> while
One of the key problems with the current proposal is the required use of the
command line to enabled this feature.
Alternative proposals (besides suggesting moving this to JDK10, which I agree
with) have suggested other ways to configure the option.
Since JDK9 has set the precedent of configuring
Hey Alan,
What about (just coming up with this idea, so most probably not
thought through) using an async-signed agent system. Users would
have to add trusted certificates to their local store (as you do
with apt on Ubuntu for repositories) and agent being signed with a
trusted key would have the
On 03/04/17 16:50, Alan Bateman wrote:
>> Also, can you provide a reason why you are so agin agent-hoisting from
>> within a JVM? Is there a reason why it is such a cardinal sin?
> As Mark said, this discussion got off to a bad start. We might have to
> explain the issue again.
Sure, only I don't
On 03/04/2017 15:15, Russell Gold wrote:
Upon further testing, this turns out to be less capable than the
“Unsafe” version - in particular, I cannot create a test stub in a
closed package. The problem is that unit tests often need to do a
number of things like this that make no sense in a prod
Thanks for the continued feedback on this difficult issue.
FYI:
http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2017-April/000666.html
http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2017-April/000667.html
- Mark
On 03/04/2017 17:28, Reto Merz wrote:
It was already suggested in another thread by Gregg Wonderly:
Why not introduce a new method
java.lang.SecurityManager#checkAttachAgent(x)?
So the implementation can accept/reject an "attach agent request"
dynamically at runtime.
x could be some additiona
It was already suggested in another thread by Gregg Wonderly:
Why not introduce a new method java.lang.SecurityManager#checkAttachAgent(x)?
So the implementation can accept/reject an "attach agent request" dynamically
at runtime.
x could be some additional infos provided by the agent (eg: certific
Hello,
while migrating example code to Java 9 Modules I ran into a problem:
ResourceBundle bundle = ResourceBundle.getBundle("de.rgra.nl.messages");
System.out.println(bundle.getString("I18n.message"));
The properties file path is:
src\de\rgra\nl\messages.properties
The code works on Java 8 an
On 03/04/2017 15:19, Andrew Dinn wrote:
:
Well, Byteman is definitely in the cross hairs by virtue of both counts
if those are the criteria (but I still don't see Byteman as a problem
that requires disruption :-)
That said, I don't quite follow how your last statement relates to the
proposed ch
On 03/04/17 13:23, Alan Bateman wrote:
> On 03/04/2017 07:28, Christoph Engelbert wrote:
> 1. Whether the agent depends on instrumentation of classes in core
> modules (java.base in particular).
>
> 2. Whether the agent is deployed as a library that load an agent into
> the current VM.
>
> The co
Upon further testing, this turns out to be less capable than the “Unsafe”
version - in particular, I cannot create a test stub in a closed package. The
problem is that unit tests often need to do a number of things like this that
make no sense in a production environment.
The problem has to do
Changeset: 52cdbd4a5999
Author:alanb
Date: 2017-04-03 14:46 +0100
URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/52cdbd4a5999
JVMTI needs to allow for non-modifiable modules
! src/share/vm/prims/jvmti.xml
! src/share/vm/prims/jvmtiEnv.cpp
On 03/04/2017 13:17, Matej Novotny wrote:
Thanks for suggestion!
I'll definitely look at that direction and see if it suffices.
Good, and please report back your experiences.
I could imagine you starting out using MethodHandles.privateLookupIn but
it would be nice to get to the point where t
On 03/04/2017 07:28, Christoph Engelbert wrote:
Hi Mark, hi others,
First of all, I understand the idea behind this change and I think it certainly
makes sense but from my impression the default is wrong, as Volker already
pointed out.
Over the last few days I (with the help of others) put t
Thanks for suggestion!
I'll definitely look at that direction and see if it suffices.
Matej
- Original Message -
> From: "Alan Bateman"
> To: "Matej Novotny" , jigsaw-dev@openjdk.java.net
> Cc: "Martin Kouba"
> Sent: Friday, March 31, 2017 4:28:34 PM
> Subject: Re: setAccessible() alter
45 matches
Mail list logo
