[jira] [Comment Edited] (CASSANDRA-9608) Support Java 11
[
https://issues.apache.org/jira/browse/CASSANDRA-9608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17233556#comment-17233556
]
Yakir Gibraltar edited comment on CASSANDRA-9608 at 11/17/20, 12:41 PM:
Hi [~snazy] [~benedict] [~jasobrown] Possible small bug in {{cassandra-env.sh:}}
[https://github.com/apache/cassandra/blob/trunk/conf/cassandra-env.sh#L98]
The following command incorrect:
{{echo "$JVM_OPTS" | grep -q "^-[X]log:gc"}}
Should be:
{{echo "$JVM_OPTS" | grep -qe "-[X]log:gc"}}
The variable {{$JVM_OPTS}} not starting with {{-Xlog..}} , and always return
1, remove {{^}} and add {{-eq}} will solve the problem.
It's causing that {{cassandra-env.sh}} ignoring variable of {{-Xlog}} in
{{jvm11-server.options}} and {{jvm8-server.options}}
was (Author: yakir.g):
Hi [~snazy] Possible small bug in {{cassandra-env.sh:}}
[https://github.com/apache/cassandra/blob/trunk/conf/cassandra-env.sh#L98]
The following command incorrect:
{{echo "$JVM_OPTS" | grep -q "^\-\[X\]log:gc"}}
Should be:
{{echo "$JVM_OPTS" | grep -qe "\-\[X\]log:gc"}}
The variable {{$JVM_OPTS}} not starting with {{-Xlog..}} , and always return
1, remove {{^}} and add {{-eq}} will solve the problem.
It's causing that {{cassandra-env.sh}} ignoring variable of {{-Xlog}} in
{{jvm11-server.options}} and {{jvm8-server.options}}
> Support Java 11
> ---
>
> Key: CASSANDRA-9608
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9608
> Project: Cassandra
> Issue Type: Task
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Low
> Labels: Java11
> Fix For: 4.0, 4.0-alpha1
>
> Attachments: jdk_9_10.patch
>
>
> This ticket is intended to group all issues found to support Java 9 in the
> future.
> From what I've found out so far:
> * Maven dependency {{com.sun:tools:jar:0}} via cobertura cannot be resolved.
> It can be easily solved using this patch:
> {code}
> - artifactId="cobertura"/>
> + artifactId="cobertura">
> +
> +
> {code}
> * Another issue is that {{sun.misc.Unsafe}} no longer contains the methods
> {{monitorEnter}} + {{monitorExit}}. These methods are used by
> {{o.a.c.utils.concurrent.Locks}} which is only used by
> {{o.a.c.db.AtomicBTreeColumns}}.
> I don't mind to start working on this yet since Java 9 is in a too early
> development phase.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-9608) Support Java 11
[
https://issues.apache.org/jira/browse/CASSANDRA-9608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17233556#comment-17233556
]
Yakir Gibraltar edited comment on CASSANDRA-9608 at 11/17/20, 12:41 PM:
Hi [~snazy] Possible small bug in {{cassandra-env.sh:}}
[https://github.com/apache/cassandra/blob/trunk/conf/cassandra-env.sh#L98]
The following command incorrect:
{{echo "$JVM_OPTS" | grep -q "^\-\[X\]log:gc"}}
Should be:
{{echo "$JVM_OPTS" | grep -qe "\-\[X\]log:gc"}}
The variable {{$JVM_OPTS}} not starting with {{-Xlog..}} , and always return
1, remove {{^}} and add {{-eq}} will solve the problem.
It's causing that {{cassandra-env.sh}} ignoring variable of {{-Xlog}} in
{{jvm11-server.options}} and {{jvm8-server.options}}
was (Author: yakir.g):
Hi [~snazy] Possible small bug in {{cassandra-env.sh:}}
[https://github.com/apache/cassandra/blob/trunk/conf/cassandra-env.sh#L98]
The following command incorrect:
{{echo "$JVM_OPTS" | grep -q "^-[X]log:gc"}}
Should be:
{{echo "$JVM_OPTS" | grep -qe "-[X]log:gc"}}
The variable {{$JVM_OPTS}} not starting with {{-Xlog..}} , and always return
1, remove {{^}} and add {{-e}}q will solve the problem.
It's causing that {{cassandra-env.sh}} ignoring variable of {{-Xlog}} in
{{jvm11-server.options}} and {{jvm8-server.options}}
> Support Java 11
> ---
>
> Key: CASSANDRA-9608
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9608
> Project: Cassandra
> Issue Type: Task
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Low
> Labels: Java11
> Fix For: 4.0, 4.0-alpha1
>
> Attachments: jdk_9_10.patch
>
>
> This ticket is intended to group all issues found to support Java 9 in the
> future.
> From what I've found out so far:
> * Maven dependency {{com.sun:tools:jar:0}} via cobertura cannot be resolved.
> It can be easily solved using this patch:
> {code}
> - artifactId="cobertura"/>
> + artifactId="cobertura">
> +
> +
> {code}
> * Another issue is that {{sun.misc.Unsafe}} no longer contains the methods
> {{monitorEnter}} + {{monitorExit}}. These methods are used by
> {{o.a.c.utils.concurrent.Locks}} which is only used by
> {{o.a.c.db.AtomicBTreeColumns}}.
> I don't mind to start working on this yet since Java 9 is in a too early
> development phase.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-9608) Support Java 11
[
https://issues.apache.org/jira/browse/CASSANDRA-9608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16555601#comment-16555601
]
Jason Brown edited comment on CASSANDRA-9608 at 7/25/18 3:37 PM:
-
[Latest dtest
run|https://circleci.com/workflow-run/de2c755e-7b00-40af-a413-917be3175b96],
with the dtest PR, was basically all green. The only failure was related to
CASSANDRA-14574. I'm currently running trunk with that dtest PR to make sure we
are still good there.
UPDATE: [dtest
run|https://circleci.com/workflow-run/02c41705-2e38-4658-9be9-153e529233f7] on
current trunk and [~snazy]'s dtest PR look fine. Three tests failed, but all
unrelated.
was (Author: jasobrown):
[Latest dtest
run|https://circleci.com/workflow-run/de2c755e-7b00-40af-a413-917be3175b96],
with the dtest PR, was basically all green. The only failure was related to
CASSANDRA-14574. I'm currently running trunk with that dtest PR to make sure we
are still good there.
> Support Java 11
> ---
>
> Key: CASSANDRA-9608
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9608
> Project: Cassandra
> Issue Type: Task
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Minor
> Fix For: 4.x
>
> Attachments: jdk_9_10.patch
>
>
> This ticket is intended to group all issues found to support Java 9 in the
> future.
> From what I've found out so far:
> * Maven dependency {{com.sun:tools:jar:0}} via cobertura cannot be resolved.
> It can be easily solved using this patch:
> {code}
> - artifactId="cobertura"/>
> + artifactId="cobertura">
> +
> +
> {code}
> * Another issue is that {{sun.misc.Unsafe}} no longer contains the methods
> {{monitorEnter}} + {{monitorExit}}. These methods are used by
> {{o.a.c.utils.concurrent.Locks}} which is only used by
> {{o.a.c.db.AtomicBTreeColumns}}.
> I don't mind to start working on this yet since Java 9 is in a too early
> development phase.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-9608) Support Java 11
[
https://issues.apache.org/jira/browse/CASSANDRA-9608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16551975#comment-16551975
]
Benedict edited comment on CASSANDRA-9608 at 7/22/18 11:22 PM:
---
I assume this is to handle e.g. the removal of Unsafe.monitorEnter/monitorExit?
A simple improvement to this would be to use a volatile \{{ReentrantLock}}
instead of a long thread id, that is allocated only on contention. This isn't
quite as cheap as Unsafe.monitorEnter/monitorExit, as the inflated lock is
never repurposed until flush.
If we wanted, we could probably implement a partially re-usable one, which
might be applicable elsewhere, or we could have a static ConcurrentMap to inflate only precisely when needed (though this will cost more
CPU/memory bandwidth and allocations).
Or we could implement some static helper methods to help us lock against a
property using a special inflated lock object, that can be used for
synchronisation until there is no contention, and the last owning thread sets
the property to null on completion. This is something I could rustle up fairly
quickly, so let me know if you want me to produce a utility class for this.
was (Author: benedict):
I assume this is to handle e.g. the removal of Unsafe.monitorEnter/monitorExit?
A simple improvement to this would be to use a volatile WaitQueue instead of a
long thread id, that is allocated only on contention, then used as any other
WaitQueue to manage waiting threads. This isn't quite as cheap as
Unsafe.monitorEnter/monitorExit, as the inflated lock is never repurposed until
flush. If we wanted, we could probably implement a partially re-usable one,
which might be applicable elsewhere, or we could have a static
ConcurrentMap to inflate only precisely when needed (though
this will cost more CPU/memory bandwidth and allocations).
> Support Java 11
> ---
>
> Key: CASSANDRA-9608
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9608
> Project: Cassandra
> Issue Type: Task
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Minor
> Fix For: 4.x
>
> Attachments: jdk_9_10.patch
>
>
> This ticket is intended to group all issues found to support Java 9 in the
> future.
> From what I've found out so far:
> * Maven dependency {{com.sun:tools:jar:0}} via cobertura cannot be resolved.
> It can be easily solved using this patch:
> {code}
> - artifactId="cobertura"/>
> + artifactId="cobertura">
> +
> +
> {code}
> * Another issue is that {{sun.misc.Unsafe}} no longer contains the methods
> {{monitorEnter}} + {{monitorExit}}. These methods are used by
> {{o.a.c.utils.concurrent.Locks}} which is only used by
> {{o.a.c.db.AtomicBTreeColumns}}.
> I don't mind to start working on this yet since Java 9 is in a too early
> development phase.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-9608) Support Java 11
[
https://issues.apache.org/jira/browse/CASSANDRA-9608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16529779#comment-16529779
]
Robert Stupp edited comment on CASSANDRA-9608 at 7/2/18 12:11 PM:
--
Thanks for the feedback, [~jasobrown]
I've addressed the comments on the PR in a new commit on the branch and most
points in your comments above.
Regarding {{JMXServerUtils}}: I wanted to preserve the existing behavior, but I
agree that reflection itself is not "awesome". But should be addressed in a
separate ticket IMO.
Regarding the {{jvm*.options}} files: Moved the Java checks and related into
{{cassandra.in.sh}} and removed the {{clients.in.sh}} file(s). Also renamed the
server .options files - so we now have {{jvm*-clients.options}} and
{{jvm*-server.options}} files.
The changes for Windows are a bit difficult as I do not have a Windows box or
VM. Should we defer the Windows part to a follow-up ticket? As long as J11 is
experimental, it's ok-ish IMO. Updated the minimum patch version for J8 though.
was (Author: snazy):
Thanks for the feedback, [~jasobrown]
I've addressed the comments on the PR in a new commit on the branch and most
points in your comments above.
Regarding {{JMXServerUtils}}: I wanted to preserve the existing behavior, but I
agree that reflection itself is not "awesome". But should be addressed in a
separate ticket IMO.
Regarding the {{jvm*.options}} files: Moved the Java checks and related into
{{cassandra.in.sh}} and removed the {{clients.in.sh}} file(s). Also renamed the
server .options files - so we now have {{jvm*-clients.options}} and
{{jvm*-server.options}} files.
The changes for Windows are a bit difficult as I do not have a Windows box or
VM. Should we defer the Windows part to a follow-up ticket?
> Support Java 11
> ---
>
> Key: CASSANDRA-9608
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9608
> Project: Cassandra
> Issue Type: Task
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Minor
> Fix For: 4.x
>
> Attachments: jdk_9_10.patch
>
>
> This ticket is intended to group all issues found to support Java 9 in the
> future.
> From what I've found out so far:
> * Maven dependency {{com.sun:tools:jar:0}} via cobertura cannot be resolved.
> It can be easily solved using this patch:
> {code}
> - artifactId="cobertura"/>
> + artifactId="cobertura">
> +
> +
> {code}
> * Another issue is that {{sun.misc.Unsafe}} no longer contains the methods
> {{monitorEnter}} + {{monitorExit}}. These methods are used by
> {{o.a.c.utils.concurrent.Locks}} which is only used by
> {{o.a.c.db.AtomicBTreeColumns}}.
> I don't mind to start working on this yet since Java 9 is in a too early
> development phase.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-9608) Support Java 11
[
https://issues.apache.org/jira/browse/CASSANDRA-9608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16528880#comment-16528880
]
Jason Brown edited comment on CASSANDRA-9608 at 6/30/18 8:21 PM:
-
Added more comments to the PR, and have the following:
* JMXServerUtils - I'm not sure sure what to do with this one. I'm not
thrilled with just using reflection to get at an instance of
{{JMXPluggableAuthenticator}}, expecially when the behavior it provides doesn't
appear to be anything special. Further, it looks like {{AuthenticationProxy}}
does most of the same functionality anyway. That being said, I am not a
JMX/JAAS expert in any way, and I'd love [~beobal]'s input on whether we could
eliminate {{JMXPluggableAuthenticatorWrapper}} in lieu of something similar to
{{AuthenticationProxy}}. This being said, I would be OK-ish if we stick with
the existing {{JMXPluggableAuthenticator}} as it ties directly into the jdk's
JMX subsystem and changes that happen there we would just get out of the box,
rather than needing to attempt feature parity with it.
* build.xml - we used to reference the jdkoverride in the javac step of the
{{build}} task. That seems to have been lost from the current build.xml file.
Further, it's not entirely clear to me what that jdkoverride is actually doing,
particularly in the java compilation step. I'll look into purpose of the sole
class in that directory, CRC32.class
** UPDATE : looks like the CRC32.class was related to CASSANDRA-8614, which
tried to optimize for java8 jvms (over java7). Thus, I think we can eliminate
this jdkoverride thing altogether - the build.xml variable reference and the
dummy class file in {{src/jdkoverrides}}.
Review ongoing ...
was (Author: jasobrown):
Added more comments to the PR, and have the following:
* JMXServerUtils - I'm not sure sure what to do with this one. I'm not
thrilled with just using reflection to get at an instance of
{{JMXPluggableAuthenticator}}, expecially when the behavior it provides doesn't
appear to be anything special. Further, it looks like {{AuthenticationProxy}}
does most of the same functionality anyway. That being said, I am not a
JMX/JAAS expert in any way, and I'd love [~beobal]'s input on whether we could
eliminate {{JMXPluggableAuthenticatorWrapper}} in lieu of something similar to
{{AuthenticationProxy}}. This being said, I would be OK-ish if we stick with
the existing {{JMXPluggableAuthenticator}} as it ties directly into the jdk's
JMX subsystem and changes that happen there we would just get out of the box,
rather than needing to attempt feature parity with it.
* build.xml - we used to reference the jdkoverride in the javac step of the
{{build}} task. That seems to have been lost from the current build.xml file.
Further, it's not entirely clear to me what that jdkoverride is actually doing,
particularly in the java compilation step. I'll look into purpose of the sole
class in that directory, CRC32.class
Review ongoing ...
> Support Java 11
> ---
>
> Key: CASSANDRA-9608
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9608
> Project: Cassandra
> Issue Type: Task
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Minor
> Fix For: 4.x
>
> Attachments: jdk_9_10.patch
>
>
> This ticket is intended to group all issues found to support Java 9 in the
> future.
> From what I've found out so far:
> * Maven dependency {{com.sun:tools:jar:0}} via cobertura cannot be resolved.
> It can be easily solved using this patch:
> {code}
> - artifactId="cobertura"/>
> + artifactId="cobertura">
> +
> +
> {code}
> * Another issue is that {{sun.misc.Unsafe}} no longer contains the methods
> {{monitorEnter}} + {{monitorExit}}. These methods are used by
> {{o.a.c.utils.concurrent.Locks}} which is only used by
> {{o.a.c.db.AtomicBTreeColumns}}.
> I don't mind to start working on this yet since Java 9 is in a too early
> development phase.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-9608) Support Java 11
[
https://issues.apache.org/jira/browse/CASSANDRA-9608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16528880#comment-16528880
]
Jason Brown edited comment on CASSANDRA-9608 at 6/30/18 8:10 PM:
-
Added more comments to the PR, and have the following:
* JMXServerUtils - I'm not sure sure what to do with this one. I'm not
thrilled with just using reflection to get at an instance of
{{JMXPluggableAuthenticator}}, expecially when the behavior it provides doesn't
appear to be anything special. Further, it looks like {{AuthenticationProxy}}
does most of the same functionality anyway. That being said, I am not a
JMX/JAAS expert in any way, and I'd love [~beobal]'s input on whether we could
eliminate {{JMXPluggableAuthenticatorWrapper}} in lieu of something similar to
{{AuthenticationProxy}}. This being said, I would be OK-ish if we stick with
the existing {{JMXPluggableAuthenticator}} as it ties directly into the jdk's
JMX subsystem and changes that happen there we would just get out of the box,
rather than needing to attempt feature parity with it.
* build.xml - we used to reference the jdkoverride in the javac step of the
{{build}} task. That seems to have been lost from the current build.xml file.
Further, it's not entirely clear to me what that jdkoverride is actually doing,
particularly in the java compilation step. I'll look into purpose of the sole
class in that directory, CRC32.class
Review ongoing ...
was (Author: jasobrown):
Added more comments to the PR, and have the following:
* JMXServerUtils - I'm not sure sure what to do with this one. I'm not
thrilled with just using reflection to get at an instance of
{{JMXPluggableAuthenticator}}, expecially when the behavior it provides doesn't
appear to be anything special. Further, it looks like {{AuthenticationProxy}}
does most of the same functionality anyway. That being said, I am not a
JMX/JAAS expert in any way, and I'd love [~beobal]'s input on whether we could
eliminate {{JMXPluggableAuthenticatorWrapper}} in lieu of something similar to
{{AuthenticationProxy}}. This being said, I would be OK-ish if we stick with
the existing {{JMXPluggableAuthenticator}} as it ties directly into the jdk's
JMX subsystem and changes that happen there we would just get out of the box,
rather than needing to attempt feature parity with it.
Review ongoing ...
> Support Java 11
> ---
>
> Key: CASSANDRA-9608
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9608
> Project: Cassandra
> Issue Type: Task
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Minor
> Fix For: 4.x
>
> Attachments: jdk_9_10.patch
>
>
> This ticket is intended to group all issues found to support Java 9 in the
> future.
> From what I've found out so far:
> * Maven dependency {{com.sun:tools:jar:0}} via cobertura cannot be resolved.
> It can be easily solved using this patch:
> {code}
> - artifactId="cobertura"/>
> + artifactId="cobertura">
> +
> +
> {code}
> * Another issue is that {{sun.misc.Unsafe}} no longer contains the methods
> {{monitorEnter}} + {{monitorExit}}. These methods are used by
> {{o.a.c.utils.concurrent.Locks}} which is only used by
> {{o.a.c.db.AtomicBTreeColumns}}.
> I don't mind to start working on this yet since Java 9 is in a too early
> development phase.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-9608) Support Java 11
[
https://issues.apache.org/jira/browse/CASSANDRA-9608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16528880#comment-16528880
]
Jason Brown edited comment on CASSANDRA-9608 at 6/30/18 8:07 PM:
-
Added more comments to the PR, and have the following:
* JMXServerUtils - I'm not sure sure what to do with this one. I'm not
thrilled with just using reflection to get at an instance of
{{JMXPluggableAuthenticator}}, expecially when the behavior it provides doesn't
appear to be anything special. Further, it looks like {{AuthenticationProxy}}
does most of the same functionality anyway. That being said, I am not a
JMX/JAAS expert in any way, and I'd love [~beobal]'s input on whether we could
eliminate {{JMXPluggableAuthenticatorWrapper}} in lieu of something similar to
{{AuthenticationProxy}}. This being said, I would be OK-ish if we stick with
the existing {{JMXPluggableAuthenticator}} as it ties directly into the jdk's
JMX subsystem and changes that happen there we would just get out of the box,
rather than needing to attempt feature parity with it.
Review ongoing ...
was (Author: jasobrown):
Added more comments to the PR, and have the following:
* JMXServerUtils - I'm not sure sure what to do with this one. I'm not
thrilled with just using reflection to get at an instance of
\{{JMXPluggableAuthenticator}}, expecially when the behavior it provides
doesn't appear to be anything special. Further, it looks like
\{{AuthenticationProxy}} does most of the same functionality anyway. That being
said, I am not a JMX/JAAS expert in any way, and I'd love @beobal's input on
whether we could eliminate \{{JMXPluggableAuthenticatorWrapper}} in lieu of
something similar to \{{AuthenticationProxy}}. This being said, I would be
OK-ish if we stick with the existing \{{JMXPluggableAuthenticator}} as it ties
directly into the jdk's JMX subsystem and changes that happen there we would
just get out of the box, rather than needing to attempt feature parity with it.
Review ongoing ...
> Support Java 11
> ---
>
> Key: CASSANDRA-9608
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9608
> Project: Cassandra
> Issue Type: Task
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Minor
> Fix For: 4.x
>
> Attachments: jdk_9_10.patch
>
>
> This ticket is intended to group all issues found to support Java 9 in the
> future.
> From what I've found out so far:
> * Maven dependency {{com.sun:tools:jar:0}} via cobertura cannot be resolved.
> It can be easily solved using this patch:
> {code}
> - artifactId="cobertura"/>
> + artifactId="cobertura">
> +
> +
> {code}
> * Another issue is that {{sun.misc.Unsafe}} no longer contains the methods
> {{monitorEnter}} + {{monitorExit}}. These methods are used by
> {{o.a.c.utils.concurrent.Locks}} which is only used by
> {{o.a.c.db.AtomicBTreeColumns}}.
> I don't mind to start working on this yet since Java 9 is in a too early
> development phase.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
