On 09/10/2015 22:15, Martin Buchholz wrote:
Latest jigsaw b83 works well with the temporary hacks we have in place in
jsr166 CVS, but we do see one jtreg test failure.
Running a modern jdk with only -Xmx2m is pushing it, but you probably don't
want to arbitrarily increase jdk memory requirements
Latest jigsaw b83 works well with the temporary hacks we have in place in
jsr166 CVS, but we do see one jtreg test failure.
Running a modern jdk with only -Xmx2m is pushing it, but you probably don't
want to arbitrarily increase jdk memory requirements just for jigsaw.
Should be bump up the -Xmx
On 10/09/2015 11:33 AM, Alex Buckley wrote:
On 10/9/2015 1:03 AM, Jaroslav Bachorik wrote:
Well, if anything the @CP annotation is related to
javax.management.openmbean package. All the OpenType and CompositeData
definitions are in this package. @CP annotation is used to influence the
way a Comp
On 10/9/2015 1:03 AM, Jaroslav Bachorik wrote:
Well, if anything the @CP annotation is related to
javax.management.openmbean package. All the OpenType and CompositeData
definitions are in this package. @CP annotation is used to influence the
way a CompositeData instance is reconstructed into an i
On 10/09/2015 06:54 PM, Alan Bateman wrote:
On 09/10/2015 16:36, Peter Levart wrote:
:
Sorry, but I must be missing something.
When you compile a class (not an MXBean as Daniel pointed out, but a
data object class) with JDK9, it can't be used on JDK8 because of
class file version.
Whe
Changeset: 67a090f8d062
Author:jfdenise
Date: 2015-10-09 18:01 +0200
URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/67a090f8d062
Rework and simplification of plugins config. Simplified ordering.
Reviewed-by: jlaskey
! src/jdk.jlink/share/classes/jdk/tools/jimage/JImageTask.jav
On 09/10/2015 16:36, Peter Levart wrote:
:
Sorry, but I must be missing something.
When you compile a class (not an MXBean as Daniel pointed out, but a
data object class) with JDK9, it can't be used on JDK8 because of
class file version.
When you compile a class with JDK8, it can't conta
On 10/09/2015 02:30 PM, Jaroslav Bachorik wrote:
To answer my question: "How is one supposed to compile an MXBean that
would work in JDK8- and at the same time in JDK9+ without java.desktop
in the module graph?"
Annotate the constructor with the both the @j.b.CP and the new @CP. In
JDK 9 the
Looks ok to me Miran.
-Chris.
On 09/10/15 12:00, Miroslav Kos wrote:
Hi everybody,
could I ask for review?
JBS: https://bugs.openjdk.java.net/browse/JDK-8134418
webrev: http://cr.openjdk.java.net/~mkos/8134418/jaxws.02/
The change is pretty straightforward, there are different codepaths for
g
Changeset: 75c194907490
Author:mkos
Date: 2015-10-09 15:00 +0100
URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/75c194907490
8134418 javax/xml/bind/jxc/8046817/GenerateEnumSchema.java failing in jake
! test/ProblemList.jake.txt
Changeset: 2313eb85fadd
Author:mkos
Date: 2015-10-09 14:59 +0100
URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/2313eb85fadd
8134418 javax/xml/bind/jxc/8046817/GenerateEnumSchema.java failing in jake
!
src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/model/impl/
On 09/10/15 14:30, Jaroslav Bachorik wrote:
Would it be possible for javac to recognise a class is an MXBean and
turn-on -parameters for such classes only by default? Too hacky?
Definitely :) Hacky as heck :)
I agree with Jaroslav.
FWIW - The @CP is not used for the MXBean itself, but for th
On 9.10.2015 14:21, Peter Levart wrote:
On 10/09/2015 02:07 PM, Jaroslav Bachorik wrote:
On 9.10.2015 13:42, Peter Levart wrote:
Hi,
I don't think it has been mentioned before, but is
@ConstructorProperties still necessary in JDK8+ ? Couldn't the
j.l.r.Constructor#getParameters() be used ins
On 10/09/2015 02:07 PM, Jaroslav Bachorik wrote:
On 9.10.2015 13:42, Peter Levart wrote:
Hi,
I don't think it has been mentioned before, but is
@ConstructorProperties still necessary in JDK8+ ? Couldn't the
j.l.r.Constructor#getParameters() be used instead?
This requires the class to be com
On 9.10.2015 13:42, Peter Levart wrote:
Hi,
I don't think it has been mentioned before, but is
@ConstructorProperties still necessary in JDK8+ ? Couldn't the
j.l.r.Constructor#getParameters() be used instead?
This requires the class to be compiled with '-parameters' switch.
How is one suppo
On 09/10/2015 12:42, Peter Levart wrote:
Hi,
I don't think it has been mentioned before, but is
@ConstructorProperties still necessary in JDK8+ ? Couldn't the
j.l.r.Constructor#getParameters() be used instead?
How is one supposed to compile an MXBean that would work in JDK8 and
at the same
Hi,
I don't think it has been mentioned before, but is
@ConstructorProperties still necessary in JDK8+ ? Couldn't the
j.l.r.Constructor#getParameters() be used instead?
How is one supposed to compile an MXBean that would work in JDK8 and at
the same time in JDK9+ without java.desktop in the
Changeset: 26f5411f52f4
Author:alanb
Date: 2015-10-09 11:05 +0100
URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/26f5411f52f4
Update code source for patch directory when using -Xpatch
! src/java.base/share/classes/jdk/internal/misc/BuiltinClassLoader.java
Changeset: 9e9452626
On 09/10/2015 12:00, Miroslav Kos wrote:
Hi everybody,
could I ask for review?
JBS: https://bugs.openjdk.java.net/browse/JDK-8134418
webrev: http://cr.openjdk.java.net/~mkos/8134418/jaxws.02/
The change is pretty straightforward, there are different codepaths
for given method and the paramet
Hi everybody,
could I ask for review?
JBS: https://bugs.openjdk.java.net/browse/JDK-8134418
webrev: http://cr.openjdk.java.net/~mkos/8134418/jaxws.02/
The change is pretty straightforward, there are different codepaths for
given method and the parametrized type can be either java.lang.Class
or
On 09/10/2015 09:27, Jayaprakash Arthanareeswaran wrote:
:
At the moment, in Eclipse IDE, users can add any JRE to a
project's build path, regardless of the JRE that the IDE is
running on.
For e.g. users can have multiple installations/versions of JRE 8
in different projec
Alan Bateman wrote on 10/09/2015 12:46:21 PM:
> Can you expand a bit more on this? Are you looking for the jrtfs update
> so that you can access the jrt file system in a different JDK 9 image?
> At the moment it is limited to JDK 8 accessing a JDK 9 image, there is
> still work required to have a
On 8.10.2015 21:29, Alex Buckley wrote:
On 10/8/2015 11:56 AM, Alan Bateman wrote:
On 08/10/2015 19:41, Alex Buckley wrote:
Also, this annotation type introduces a new package,
javax.management.annotation. I support *.annotation packages in
general (e.g. to group a growing number of exciting an
On 09/10/2015 05:26, Jayaprakash Arthanareeswaran wrote:
The ability that you need, and which you're currently missing, is the
ability to load code (modules) from an alternate JDK image.
This is what we (the eclipse team) is missing as well and I haven't
heard anything along these line
24 matches
Mail list logo
