OK. I was not aware of this. I thought that it was the Java 9
implementation (StackLocator/ProcessIdUtil) that caused the problem.
On 2017-12-03 06:30, Ralph Goers wrote:
Let’s go back to this post.
Assume we figured out how to get rid of all the stuff you consider to be not
required to be i
Yes, log4j-core-android would be a good idea. But yes, we have to solve
the API problem first.
On 2017-12-02 17:40, Ralph Goers wrote:
FWIW, it would make sense to me to make a log4j-core-android that is a subset
of what is in core, if that is possible. Of course, the API problem has to be
s
The problem is that we cannot just remove stuff from log4j-api now,
since that would break binary/source compatibility for existing users.
If I understand it correctly, due to the Java 9 modules, if we move
stuff from log4j-api to log4j-core we have to change package, right? And
we don't want re
Let’s go back to this post.
Assume we figured out how to get rid of all the stuff you consider to be not
required to be in the API. Even if we did that it still would not work in
Android so long as the API contains module-info.java, because that class can
only be compiled for Java 9. So ther
JNA does the same kind of magic to extract DLLs IIRC but that is for the
lib path, not the classpath.
Gary
On Sat, Dec 2, 2017 at 5:01 PM, Remko Popma wrote:
> On second thought, without a custom class loader we’d first need to copy
> these classes into the classpath.
>
> This may not always be
On second thought, without a custom class loader we’d first need to copy
these classes into the classpath.
This may not always be possible and sounds like a bad idea anyway.
So please ignore my previous email.
On Sun, Dec 3, 2017 at 8:38 Remko Popma wrote:
>
> > On Dec 3, 2017, at 1:38, Ralph
> On Dec 3, 2017, at 1:38, Ralph Goers wrote:
>
> I see several issues:
>
> StackLocator:
>This cannot be removed from the API is the API as LogManager.getLogger()
> calls it. Converting the Java 9 version to use Reflection would add enough
> overhead that it probably wouldn’t be worth it
I suppose we could have the log4j-api have a transitive dependency on
log4j-api-java9 only when the build target is Java 9.
Ralph
> On Dec 2, 2017, at 3:03 PM, Ralph Goers wrote:
>
> So this is the other problem. It is complaining that it doesn’t support Java
> 9 class files. That would be m
So this is the other problem. It is complaining that it doesn’t support Java 9
class files. That would be module-info.java I am sure.
Ralph
> On Dec 2, 2017, at 2:02 PM, Gary Gregory wrote:
>
> Here you go, from one of my work projects:
>
> [WARNING] Unable to process class module-info.class
Here you go, from one of my work projects:
[WARNING] Unable to process class module-info.class in JarAnalyzer File
C:\Users\ggregory\.m2\repository\org\slf4j\slf4j-api\1.8.0-alpha2\slf4j-api-1.8.0-alpha2.jar
org.apache.bcel.classfile.ClassFormatException: Invalid byte tag in
constant pool: 19
I think Slf4j 1.8-alpha has the same problem, not 100% sure.
Gary
On Sat, Dec 2, 2017 at 11:03 AM, Matt Sicker wrote:
> Are there other Java 9 ready libraries that are having the same problem in
> Android?
>
> On 2 December 2017 at 10:40, Ralph Goers
> wrote:
>
> > FWIW, it would make sense to
Are there other Java 9 ready libraries that are having the same problem in
Android?
On 2 December 2017 at 10:40, Ralph Goers wrote:
> FWIW, it would make sense to me to make a log4j-core-android that is a
> subset of what is in core, if that is possible. Of course, the API problem
> has to be so
FWIW, it would make sense to me to make a log4j-core-android that is a subset
of what is in core, if that is possible. Of course, the API problem has to be
solved first.
Ralph
> On Dec 2, 2017, at 9:38 AM, Ralph Goers wrote:
>
> I see several issues:
>
> StackLocator:
> This cannot be
I see several issues:
StackLocator:
This cannot be removed from the API is the API as
LogManager.getLogger() calls it. Converting the Java 9 version to use
Reflection would add enough overhead that it probably wouldn’t be worth it to
use it. Also, you would have to figure out how to cod
Ok, you have some fair points there.
Main take-away for me is that if we want Log4j2's API to become ubiquitous
it needs to be at least painless for everyone.
Don't known about the "too much stuff" in log4j-api - bit vague and not
actionable.
What can we do, concretely?
log4j-api
-
1) I'
I fully understand Oleg's point of view.
If we aim for Log4j 2's API to be the standard logging API/facade for
Java/JVM (eventually replacing SLF4J), then we have painted ourselves
into a corner by allowing log4j-api to grow out of bounds, and not
paying enough attention to the compatibility p
Hi All:
I had migrated HttpClient 5 to Log4j 2 but now there is push back due to
the mess Java 9 has made of the META-INF folder and our adding support for
Java 9 modules perhaps too soon.
Please see http://markmail.org/message/yyoj4zs3ieyaept5 and comment on that
thread please.
Gary
17 matches
Mail list logo
