Re: [Log4j] Apache HttpClient 5, Log4j and Slf4j

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

Re: [Log4j] Apache HttpClient 5, Log4j and Slf4j

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

Re: [Log4j] Apache HttpClient 5, Log4j and Slf4j

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

Re: [Log4j] Apache HttpClient 5, Log4j and Slf4j

> 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

Re: SLF4J now requires Java 6

Requiring Java 8 minimum would make more sense to start with for Core and the other modules. It's too bad that Java 8 and 9 added language features that would have been immensely useful for maintaining a backwards compatible API (default and private methods on interfaces), though I suppose that wil

Re: [Log4j] Apache HttpClient 5, Log4j and Slf4j

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

Re: [Log4j] Apache HttpClient 5, Log4j and Slf4j

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

SLF4J now requires Java 6

And here you are complaining we haven’t moved to Java 8 as the minimum... http://slf4j.42922.n3.nabble.com/qos-ch-slf4j-5f0078-slf4j-api-now-requires-Java-6-td4026870.html Ralph

Re: [Log4j] Apache HttpClient 5, Log4j and Slf4j

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

Re: [Log4j] Apache HttpClient 5, Log4j and Slf4j

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

Re: [Log4j] Apache HttpClient 5, Log4j and Slf4j

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

Re: [Log4j] Apache HttpClient 5, Log4j and Slf4j

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

Re: [Log4j] Apache HttpClient 5, Log4j and Slf4j

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

Re: [Log4j] Apache HttpClient 5, Log4j and Slf4j

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'

Re: [Log4j] Apache HttpClient 5, Log4j and Slf4j

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