On 2/22/19 9:55 PM, Roger Riggs wrote:
Hi,
After a closer look, I'd take the route of the 01 webrev.
It is more localized and does not force the function signature needed
by pthread_create to be propagated elsewhere.
The code can be a lot more comprehensible by renaming the CallIntFunc
I'm wondering how jpackage searches for modules. I tried to build a very
simple example (using Build 17 of jpackage), but jpackage always claims
that the module can't be found.
~$ ./jpackage create-image \
--output /data/projects/javam/de.asysgmbh.app.test/target/image \
--name test \
+1
Much cleaner, since it does not need to be more general.
I'd probably add a comment to the ThreadJavaMain method
to say why it is needed.
BTW, it looks like the indents have gotten mixed up between 2 spaces and 4.
For the libjli it should be 4 spaces.
But this change is probably not the
Hi Andrew,
I think initializing LangReflectAccess in AccessibleObject
is a better fix. Besides moving clinit to AccessibleObject,
ReflectionFactory::langReflectAccess can simply assert
if langReflectAccess is non-null. Attached is the patch
that you can reference.
We should do more testing
Hi Joe,
Thanks for cleaning up jdeprscan.
For computing the set of releases, I'd prefer to see a stream that looks like
this:
final Set releasesWithForRemoval =
IntStream.rangeClosed(9, Runtime.version().feature())
.mapToObj(Integer::toString)
> I think the original idea was that the "general contract" was that
> collections contained elements whose membership was defined by equals().
> However, for a very long time now there have been collections in the JDK such
> as SortedSet and IdentityHashMap (more precisely, IdentityHashMap's
On 2/15/19 11:30 AM, Alan Snyder wrote:
I think this situation is a mess.
The “general contract” of a Collection, I believe, is that it contains zero
or more identified member objects, as defined by appropriate equals() method.
I know this is hard to specify precisely, but I presume we all
Tobias:
After the latest fix (JDK-8217798: modular jar linking in jpackage) the
following now works:
jpackage create-image --module
de.asysgmbh.app.test/de.asysgmbh.app.test.Main --module-path
/data/projects/javam/de.asysgmbh.app.test/target/modules ...
will work fine, but
jpackage
> On Feb 25, 2019, at 9:09 AM, Dmitry Chuyko wrote:
>
> On 2/22/19 9:55 PM, Roger Riggs wrote:
>> Hi,
>>
>> After a closer look, I'd take the route of the 01 webrev.
>> It is more localized and does not force the function signature needed
>> by pthread_create to be propagated elsewhere.
>>
Thank you Andy, for clarifying. I thought i was missing some detail.
Guess, I will have to be a bit more patient. ;-)
/Tobias Oelgarte
On 25.02.19 22:20, Andy Herrick wrote:
Tobias:
After the latest fix (JDK-8217798: modular jar linking in jpackage)
the following now works:
jpackage
Hi Stuart,
Will push with suggested refactoring; thanks for the review,
-Joe
On 2/25/2019 10:40 AM, Stuart Marks wrote:
Hi Joe,
Thanks for cleaning up jdeprscan.
For computing the set of releases, I'd prefer to see a stream that
looks like this:
final Set releasesWithForRemoval =
Hi Andy,
Updated version looks fine as well.
Thank,
Alexander
On 2/25/2019 5:19 AM, Andy Herrick wrote:
I uploaded webrev version 04
(http://cr.openjdk.java.net/~herrick/8218055/webrev.04) which is same
as version 03 except "JLink" is changed to "jlink" in several messages.
/ANdy
On
On 2/25/19 5:12 AM, Andrew Leonard wrote:
Hi Mandy,
I must admit I don't completely follow the logic of the existing
Modifier init of langReflectAccess, the comment indicates a "protocol
between java.lang and java.lang.reflect".
That sets up the shared secret for ReflectionFactory to
On 21/02/2019 15:04, Langer, Christoph wrote:
Hi Alan,
here is the next
iteration:http://cr.openjdk.java.net/~clanger/webrevs/8213031.7/
I focused on your comments regarding implementation details:
:
Are there other major implementation points left? If not I guess we should
start refining
This looks good
/Andy
On 2/22/2019 5:26 PM, Alexander Matveev 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).
- User provided version was not display, because it was added as
additional
Hi Mandy,
I must admit I don't completely follow the logic of the existing Modifier
init of langReflectAccess, the comment indicates a "protocol between
java.lang and java.lang.reflect". I can try moving the clinit code from
Modifier to AccessibleObject, but I question is there some reason it
Hi Alan,
The J9 tests are run against build "images".
Cheers
Andrew
Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
Phone internal: 245913, external: 01962 815913
internet email: andrew_m_leon...@uk.ibm.com
From: Alan Bateman
To: Andrew Leonard , Roger
I uploaded webrev version 04
(http://cr.openjdk.java.net/~herrick/8218055/webrev.04) which is same as
version 03 except "JLink" is changed to "jlink" in several messages.
/ANdy
On 2/22/2019 2:37 PM, Mandy Chung wrote:
On 2/22/19 9:50 AM, Andy Herrick wrote:
revised webrev t address
Hi Mandy,
I can confirm "just" moving the clinit code into AccessibleObject does
resolve the J9 issue as well, without changing ReflectionFactory...
What's your thoughts?
Thanks
Andrew
Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
Phone internal: 245913, external:
19 matches
Mail list logo
