The type “com.sun.tools.javac.util.Assert” is not accessible [closed]
Could you please help me to understand why this type not accessible is?
Versions:
Eclips / Photon Release (4.8.0)
selenium-java-3.14.0
JavaSE-10
screenshot
java
closed as off-topic by Michael Butscher, Progman, Unheilig, mpromonet, Raedwald Nov 13 '18 at 22:00
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions seeking debugging help ("why isn't this code working?") must include the desired behavior, a specific problem or error and the shortest code necessary to reproduce it in the question itself. Questions without a clear problem statement are not useful to other readers. See: How to create a Minimal, Complete, and Verifiable example." – Michael Butscher, mpromonet, Raedwald
add a comment |
Could you please help me to understand why this type not accessible is?
Versions:
Eclips / Photon Release (4.8.0)
selenium-java-3.14.0
JavaSE-10
screenshot
java
closed as off-topic by Michael Butscher, Progman, Unheilig, mpromonet, Raedwald Nov 13 '18 at 22:00
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions seeking debugging help ("why isn't this code working?") must include the desired behavior, a specific problem or error and the shortest code necessary to reproduce it in the question itself. Questions without a clear problem statement are not useful to other readers. See: How to create a Minimal, Complete, and Verifiable example." – Michael Butscher, mpromonet, Raedwald
More context please
– Michael
Nov 13 '18 at 12:03
3
When you're using Java 9 or greater you have no access to com.sun packages any more, they are not exposed by the new modular jdk
– Blagoj Atanasovski
Nov 13 '18 at 12:29
provide us more code please
– Ivan Aracki
Nov 13 '18 at 12:34
2
You shouldn't be using thatAssert
class in your code. My bet is that you should be usingAssert
from the JUnit APIs.
– Stephen C
Nov 13 '18 at 13:14
Do not usecom.sun.*
classes. They are an internal part of the JDK, are undocumented and can change or disappear without warning in any new JDK version.
– Jesper
Nov 13 '18 at 13:14
add a comment |
Could you please help me to understand why this type not accessible is?
Versions:
Eclips / Photon Release (4.8.0)
selenium-java-3.14.0
JavaSE-10
screenshot
java
Could you please help me to understand why this type not accessible is?
Versions:
Eclips / Photon Release (4.8.0)
selenium-java-3.14.0
JavaSE-10
screenshot
java
java
edited Nov 13 '18 at 12:26
Arsen Papoyan
asked Nov 13 '18 at 11:54
Arsen PapoyanArsen Papoyan
62
62
closed as off-topic by Michael Butscher, Progman, Unheilig, mpromonet, Raedwald Nov 13 '18 at 22:00
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions seeking debugging help ("why isn't this code working?") must include the desired behavior, a specific problem or error and the shortest code necessary to reproduce it in the question itself. Questions without a clear problem statement are not useful to other readers. See: How to create a Minimal, Complete, and Verifiable example." – Michael Butscher, mpromonet, Raedwald
closed as off-topic by Michael Butscher, Progman, Unheilig, mpromonet, Raedwald Nov 13 '18 at 22:00
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions seeking debugging help ("why isn't this code working?") must include the desired behavior, a specific problem or error and the shortest code necessary to reproduce it in the question itself. Questions without a clear problem statement are not useful to other readers. See: How to create a Minimal, Complete, and Verifiable example." – Michael Butscher, mpromonet, Raedwald
More context please
– Michael
Nov 13 '18 at 12:03
3
When you're using Java 9 or greater you have no access to com.sun packages any more, they are not exposed by the new modular jdk
– Blagoj Atanasovski
Nov 13 '18 at 12:29
provide us more code please
– Ivan Aracki
Nov 13 '18 at 12:34
2
You shouldn't be using thatAssert
class in your code. My bet is that you should be usingAssert
from the JUnit APIs.
– Stephen C
Nov 13 '18 at 13:14
Do not usecom.sun.*
classes. They are an internal part of the JDK, are undocumented and can change or disappear without warning in any new JDK version.
– Jesper
Nov 13 '18 at 13:14
add a comment |
More context please
– Michael
Nov 13 '18 at 12:03
3
When you're using Java 9 or greater you have no access to com.sun packages any more, they are not exposed by the new modular jdk
– Blagoj Atanasovski
Nov 13 '18 at 12:29
provide us more code please
– Ivan Aracki
Nov 13 '18 at 12:34
2
You shouldn't be using thatAssert
class in your code. My bet is that you should be usingAssert
from the JUnit APIs.
– Stephen C
Nov 13 '18 at 13:14
Do not usecom.sun.*
classes. They are an internal part of the JDK, are undocumented and can change or disappear without warning in any new JDK version.
– Jesper
Nov 13 '18 at 13:14
More context please
– Michael
Nov 13 '18 at 12:03
More context please
– Michael
Nov 13 '18 at 12:03
3
3
When you're using Java 9 or greater you have no access to com.sun packages any more, they are not exposed by the new modular jdk
– Blagoj Atanasovski
Nov 13 '18 at 12:29
When you're using Java 9 or greater you have no access to com.sun packages any more, they are not exposed by the new modular jdk
– Blagoj Atanasovski
Nov 13 '18 at 12:29
provide us more code please
– Ivan Aracki
Nov 13 '18 at 12:34
provide us more code please
– Ivan Aracki
Nov 13 '18 at 12:34
2
2
You shouldn't be using that
Assert
class in your code. My bet is that you should be using Assert
from the JUnit APIs.– Stephen C
Nov 13 '18 at 13:14
You shouldn't be using that
Assert
class in your code. My bet is that you should be using Assert
from the JUnit APIs.– Stephen C
Nov 13 '18 at 13:14
Do not use
com.sun.*
classes. They are an internal part of the JDK, are undocumented and can change or disappear without warning in any new JDK version.– Jesper
Nov 13 '18 at 13:14
Do not use
com.sun.*
classes. They are an internal part of the JDK, are undocumented and can change or disappear without warning in any new JDK version.– Jesper
Nov 13 '18 at 13:14
add a comment |
1 Answer
1
active
oldest
votes
You shouldn't be using that Assert
class in your code. It is internal to the Java compiler, and not intended for reuse.
There have been warnings in the Sun / Oracle documentation for many years that user code should not depend on the internal com.sun.*
APIs. Starting with Java 9, access to these and other internal APIs have been closed off by the module system. It is possible to allow the access ... but you shouldn't if you have an alternative.
- These APIs are undocumented, and may be withdrawn without any notice, causing portability problems when you upgrade your JVM to a newer release.
- Some Java implementations don't implement these APIs, leading to portability problems when you try to use a JVM from a different vendor.
My bet is that you should be using Assert
from the JUnit APIs, and that you have picked up the bogus import
by accepting an (incorrect) auto-correction suggested by your IDE.
The best solution is to change your code to use org.junit.Assert
or something equivalent.
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
You shouldn't be using that Assert
class in your code. It is internal to the Java compiler, and not intended for reuse.
There have been warnings in the Sun / Oracle documentation for many years that user code should not depend on the internal com.sun.*
APIs. Starting with Java 9, access to these and other internal APIs have been closed off by the module system. It is possible to allow the access ... but you shouldn't if you have an alternative.
- These APIs are undocumented, and may be withdrawn without any notice, causing portability problems when you upgrade your JVM to a newer release.
- Some Java implementations don't implement these APIs, leading to portability problems when you try to use a JVM from a different vendor.
My bet is that you should be using Assert
from the JUnit APIs, and that you have picked up the bogus import
by accepting an (incorrect) auto-correction suggested by your IDE.
The best solution is to change your code to use org.junit.Assert
or something equivalent.
add a comment |
You shouldn't be using that Assert
class in your code. It is internal to the Java compiler, and not intended for reuse.
There have been warnings in the Sun / Oracle documentation for many years that user code should not depend on the internal com.sun.*
APIs. Starting with Java 9, access to these and other internal APIs have been closed off by the module system. It is possible to allow the access ... but you shouldn't if you have an alternative.
- These APIs are undocumented, and may be withdrawn without any notice, causing portability problems when you upgrade your JVM to a newer release.
- Some Java implementations don't implement these APIs, leading to portability problems when you try to use a JVM from a different vendor.
My bet is that you should be using Assert
from the JUnit APIs, and that you have picked up the bogus import
by accepting an (incorrect) auto-correction suggested by your IDE.
The best solution is to change your code to use org.junit.Assert
or something equivalent.
add a comment |
You shouldn't be using that Assert
class in your code. It is internal to the Java compiler, and not intended for reuse.
There have been warnings in the Sun / Oracle documentation for many years that user code should not depend on the internal com.sun.*
APIs. Starting with Java 9, access to these and other internal APIs have been closed off by the module system. It is possible to allow the access ... but you shouldn't if you have an alternative.
- These APIs are undocumented, and may be withdrawn without any notice, causing portability problems when you upgrade your JVM to a newer release.
- Some Java implementations don't implement these APIs, leading to portability problems when you try to use a JVM from a different vendor.
My bet is that you should be using Assert
from the JUnit APIs, and that you have picked up the bogus import
by accepting an (incorrect) auto-correction suggested by your IDE.
The best solution is to change your code to use org.junit.Assert
or something equivalent.
You shouldn't be using that Assert
class in your code. It is internal to the Java compiler, and not intended for reuse.
There have been warnings in the Sun / Oracle documentation for many years that user code should not depend on the internal com.sun.*
APIs. Starting with Java 9, access to these and other internal APIs have been closed off by the module system. It is possible to allow the access ... but you shouldn't if you have an alternative.
- These APIs are undocumented, and may be withdrawn without any notice, causing portability problems when you upgrade your JVM to a newer release.
- Some Java implementations don't implement these APIs, leading to portability problems when you try to use a JVM from a different vendor.
My bet is that you should be using Assert
from the JUnit APIs, and that you have picked up the bogus import
by accepting an (incorrect) auto-correction suggested by your IDE.
The best solution is to change your code to use org.junit.Assert
or something equivalent.
edited Nov 13 '18 at 13:31
answered Nov 13 '18 at 13:20
Stephen CStephen C
519k70572929
519k70572929
add a comment |
add a comment |
More context please
– Michael
Nov 13 '18 at 12:03
3
When you're using Java 9 or greater you have no access to com.sun packages any more, they are not exposed by the new modular jdk
– Blagoj Atanasovski
Nov 13 '18 at 12:29
provide us more code please
– Ivan Aracki
Nov 13 '18 at 12:34
2
You shouldn't be using that
Assert
class in your code. My bet is that you should be usingAssert
from the JUnit APIs.– Stephen C
Nov 13 '18 at 13:14
Do not use
com.sun.*
classes. They are an internal part of the JDK, are undocumented and can change or disappear without warning in any new JDK version.– Jesper
Nov 13 '18 at 13:14