You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Ralph Goers <ra...@dslextreme.com> on 2017/03/15 15:07:29 UTC
Java 9 support
I know how to implement the StackWalker code but I don’t quite know how to get it into the build. The main build needs to keep using Java 7 but of course the StackWalker stuff needs to be compiled with Java 9. Technically, I know how I could do that except I have no idea how it would work in Jenkins. It would also mean that everyone would be required to have Java 9 installed in order to do the build.
An alternate approach would be to have the Java 9 specific classes in a separate repo with its own build. It would have to be “released” but we really wouldn’t need or want to release those jars to Maven Central as they would only be needed in the Log4j build - the classes would be copied into the Log4j jar.
If any of you know we can set a Jenkins variable to point to the latest Java 9 version that could solve the problem.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Java 9 support
Posted by Remko Popma <re...@gmail.com>.
Sorry, no idea. A separate repo sounds cleaner, but I haven't spent as much
time as you thinking about this, so perhaps I'm wrong. It would be nice to
not require Java 9 unless you want to compile the StackWalker stuff...
On Thu, Mar 16, 2017 at 12:07 AM, Ralph Goers <ra...@dslextreme.com>
wrote:
> I know how to implement the StackWalker code but I don’t quite know how to
> get it into the build. The main build needs to keep using Java 7 but of
> course the StackWalker stuff needs to be compiled with Java 9. Technically,
> I know how I could do that except I have no idea how it would work in
> Jenkins. It would also mean that everyone would be required to have Java 9
> installed in order to do the build.
>
> An alternate approach would be to have the Java 9 specific classes in a
> separate repo with its own build. It would have to be “released” but we
> really wouldn’t need or want to release those jars to Maven Central as they
> would only be needed in the Log4j build - the classes would be copied into
> the Log4j jar.
>
> If any of you know we can set a Jenkins variable to point to the latest
> Java 9 version that could solve the problem.
>
> Ralph
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
Re: Java 9 support
Posted by Ralph Goers <ra...@dslextreme.com>.
I opened https://issues.apache.org/jira/browse/FELIX-5527 <https://issues.apache.org/jira/browse/FELIX-5527>. Apparently the problem is with bnd-tools who seem to be ignoring the problem because Java 9 isn’t final. Since OSGi bundles don’t or won’t have support for multi-release jars they will fall back to using the slower methods. It is possible to address this by using something similar to how we load the binding between the Log4j API and the implementation, but I am reluctant to do this since Java 9 introduced something specifically for this purpose.
Ralph
> On Mar 16, 2017, at 7:55 AM, Matt Sicker <bo...@gmail.com> wrote:
>
> OSGi and Jigsaw have considerable overlap in concepts, so I'm assuming there will be integration efforts eventually. However, a friend went to JavaOne a year or two ago, and the Jigsaw folk were very dismissive of OSGi in general despite one of the leading OSGi spec leads being on the Jigsaw project.
>
> On 16 March 2017 at 08:37, Ralph Goers <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
> Nevermind. I moved the dependency plugin after the bundle plugin so that the classes are copied after the bundle plugin runs and all is well. I have no idea how that will impact the OSGi bundle though. Then again, I have no idea if OSGi will support multi-release jars.
>
> Ralph
>
>> On Mar 15, 2017, at 11:36 PM, Ralph Goers <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
>>
>> I have built the Java 9 code. Now I am copying the classes into the log4j-api jar. They have to be placed at META-INF/versions/9. However, when I do this I am getting an error from the Maven bundle plugin.
>>
>> [INFO] --- maven-bundle-plugin:3.2.0:manifest (default) @ log4j-api ---
>> [ERROR] Manifest org.apache.logging.log4j:log4j-api:jar:2.8.2-SNAPSHOT : Classes found in the wrong directory: {META-INF/versions/9/org/apache/logging/log4j/util/ReflectionUtil.class=org.apache.logging.log4j.util.ReflectionUtil, META-INF/versions/9/org/apache/logging/log4j/util/ClassPredicate.class=org.apache.logging.log4j.util.ClassPredicate, META-INF/versions/9/org/apache/logging/log4j/util/ClassNamePredicate.class=org.apache.logging.log4j.util.ClassNamePredicate}
>> [ERROR] Error(s) found in manifest configuration
>>
>> Any idea on how to get around this?
>>
>> Ralph
>>
>>
>>
>>
>>
>>> On Mar 15, 2017, at 9:14 AM, Ralph Goers <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
>>>
>>> I don’t see a problem with it. What is released will still run fine on Java 7. It will just have some Java 9 components in the jar. The release is scheduled for late July. I haven’t seen any indication that it will be pushed again. I would rather be ready to take advantage of Java 9 on the day it is released then be playing catch-up.
>>>
>>> Ralph
>>>
>>>> On Mar 15, 2017, at 8:38 AM, Mikael Ståldal <mikael.staldal@magine.com <ma...@magine.com>> wrote:
>>>>
>>>> It would be bad to require Java 9 to build the main project as long as Java 9 is not released.
>>>>
>>>> On Wed, Mar 15, 2017 at 4:27 PM, Ralph Goers <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
>>>> I can’t change the JDK from JDK 1.7. The rest of the build must be compiled at Java 7 since that is what we support. I only want to compile the new classes with Java 9.
>>>>
>>>> Using a profile is a very good solution. We would have to run the build twice but that would be OK. I will give that a try.
>>>>
>>>> Ralph
>>>>
>>>>> On Mar 15, 2017, at 8:13 AM, Matt Sicker <boards@gmail.com <ma...@gmail.com>> wrote:
>>>>>
>>>>> You can change the JDK from "JDK 1.7 (latest)" to one of the JDK 9 versions. Since there's no official release of 9 yet, they don't seem to have a "JDK 9 (latest)" profile set up on Jenkins yet.
>>>>>
>>>>> As for building this, the best solution I've seen so far basically involves a bit of manual configuration using some inline ant tasks or similar overly complicated nonsense which doesn't work well in any IDE to date. It may be worth investigating the existing maven plugin ecosystem and seeing if we need a custom plugin developed for this. Could be a useful feature addition to maven-compiler-plugin, though I haven't tried contributing to Maven yet.
>>>>>
>>>>> Using Maven profiles would help with this so that we can still build most of the project locally with JDK 1.7 or 1.8 as I doubt everyone wants to install JDK 9 on all their development machines while it's still in beta.
>>>>>
>>>>> On 15 March 2017 at 10:07, Ralph Goers <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
>>>>> I know how to implement the StackWalker code but I don’t quite know how to get it into the build. The main build needs to keep using Java 7 but of course the StackWalker stuff needs to be compiled with Java 9. Technically, I know how I could do that except I have no idea how it would work in Jenkins. It would also mean that everyone would be required to have Java 9 installed in order to do the build.
>>>>>
>>>>> An alternate approach would be to have the Java 9 specific classes in a separate repo with its own build. It would have to be “released” but we really wouldn’t need or want to release those jars to Maven Central as they would only be needed in the Log4j build - the classes would be copied into the Log4j jar.
>>>>>
>>>>> If any of you know we can set a Jenkins variable to point to the latest Java 9 version that could solve the problem.
>>>>>
>>>>> Ralph
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org <ma...@logging.apache.org>
>>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org <ma...@logging.apache.org>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>>
>>>> Mikael Ståldal
>>>> Senior software developer
>>>>
>>>> Magine TV
>>>> mikael.staldal@magine.com <ma...@magine.com>
>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com <http://www.magine.com/>
>>>>
>>>> Privileged and/or Confidential Information may be contained in this message. If you are not the addressee indicated in this message
>>>> (or responsible for delivery of the message to such a person), you may not copy or deliver this message to anyone. In such case,
>>>> you should destroy this message and kindly notify the sender by reply email.
>>>
>>
>
>
>
>
> --
> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
Re: Java 9 support
Posted by Matt Sicker <bo...@gmail.com>.
OSGi and Jigsaw have considerable overlap in concepts, so I'm assuming
there will be integration efforts eventually. However, a friend went to
JavaOne a year or two ago, and the Jigsaw folk were very dismissive of OSGi
in general despite one of the leading OSGi spec leads being on the Jigsaw
project.
On 16 March 2017 at 08:37, Ralph Goers <ra...@dslextreme.com> wrote:
> Nevermind. I moved the dependency plugin after the bundle plugin so that
> the classes are copied after the bundle plugin runs and all is well. I have
> no idea how that will impact the OSGi bundle though. Then again, I have no
> idea if OSGi will support multi-release jars.
>
> Ralph
>
> On Mar 15, 2017, at 11:36 PM, Ralph Goers <ra...@dslextreme.com>
> wrote:
>
> I have built the Java 9 code. Now I am copying the classes into the
> log4j-api jar. They have to be placed at META-INF/versions/9. However, when
> I do this I am getting an error from the Maven bundle plugin.
>
> [INFO] --- maven-bundle-plugin:3.2.0:manifest (default) @ log4j-api ---
> [ERROR] Manifest org.apache.logging.log4j:log4j-api:jar:2.8.2-SNAPSHOT :
> Classes found in the wrong directory: {META-INF/versions/9/org/
> apache/logging/log4j/util/ReflectionUtil.class=org.
> apache.logging.log4j.util.ReflectionUtil, META-INF/versions/9/org/
> apache/logging/log4j/util/ClassPredicate.class=org.
> apache.logging.log4j.util.ClassPredicate, META-INF/versions/9/org/
> apache/logging/log4j/util/ClassNamePredicate.class=org.
> apache.logging.log4j.util.ClassNamePredicate}
> [ERROR] Error(s) found in manifest configuration
>
> Any idea on how to get around this?
>
> Ralph
>
>
>
>
>
> On Mar 15, 2017, at 9:14 AM, Ralph Goers <ra...@dslextreme.com>
> wrote:
>
> I don’t see a problem with it. What is released will still run fine on
> Java 7. It will just have some Java 9 components in the jar. The release
> is scheduled for late July. I haven’t seen any indication that it will be
> pushed again. I would rather be ready to take advantage of Java 9 on the
> day it is released then be playing catch-up.
>
> Ralph
>
> On Mar 15, 2017, at 8:38 AM, Mikael Ståldal <mi...@magine.com>
> wrote:
>
> It would be bad to require Java 9 to build the main project as long as
> Java 9 is not released.
>
> On Wed, Mar 15, 2017 at 4:27 PM, Ralph Goers <ra...@dslextreme.com>
> wrote:
>
>> I can’t change the JDK from JDK 1.7. The rest of the build must be
>> compiled at Java 7 since that is what we support. I only want to compile
>> the new classes with Java 9.
>>
>> Using a profile is a very good solution. We would have to run the build
>> twice but that would be OK. I will give that a try.
>>
>> Ralph
>>
>> On Mar 15, 2017, at 8:13 AM, Matt Sicker <bo...@gmail.com> wrote:
>>
>> You can change the JDK from "JDK 1.7 (latest)" to one of the JDK 9
>> versions. Since there's no official release of 9 yet, they don't seem to
>> have a "JDK 9 (latest)" profile set up on Jenkins yet.
>>
>> As for building this, the best solution I've seen so far basically
>> involves a bit of manual configuration using some inline ant tasks or
>> similar overly complicated nonsense which doesn't work well in any IDE to
>> date. It may be worth investigating the existing maven plugin ecosystem and
>> seeing if we need a custom plugin developed for this. Could be a useful
>> feature addition to maven-compiler-plugin, though I haven't tried
>> contributing to Maven yet.
>>
>> Using Maven profiles would help with this so that we can still build most
>> of the project locally with JDK 1.7 or 1.8 as I doubt everyone wants to
>> install JDK 9 on all their development machines while it's still in beta.
>>
>> On 15 March 2017 at 10:07, Ralph Goers <ra...@dslextreme.com>
>> wrote:
>>
>>> I know how to implement the StackWalker code but I don’t quite know how
>>> to get it into the build. The main build needs to keep using Java 7 but of
>>> course the StackWalker stuff needs to be compiled with Java 9. Technically,
>>> I know how I could do that except I have no idea how it would work in
>>> Jenkins. It would also mean that everyone would be required to have Java 9
>>> installed in order to do the build.
>>>
>>> An alternate approach would be to have the Java 9 specific classes in a
>>> separate repo with its own build. It would have to be “released” but we
>>> really wouldn’t need or want to release those jars to Maven Central as they
>>> would only be needed in the Log4j build - the classes would be copied into
>>> the Log4j jar.
>>>
>>> If any of you know we can set a Jenkins variable to point to the latest
>>> Java 9 version that could solve the problem.
>>>
>>> Ralph
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>
>>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>>
>>
>
>
> --
> [image: MagineTV]
>
> *Mikael Ståldal*
> Senior software developer
>
> *Magine TV*
> mikael.staldal@magine.com
> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>
> Privileged and/or Confidential Information may be contained in this
> message. If you are not the addressee indicated in this message
> (or responsible for delivery of the message to such a person), you may not
> copy or deliver this message to anyone. In such case,
> you should destroy this message and kindly notify the sender by reply
> email.
>
>
>
>
>
--
Matt Sicker <bo...@gmail.com>
Re: Java 9 support
Posted by Ralph Goers <ra...@dslextreme.com>.
Nevermind. I moved the dependency plugin after the bundle plugin so that the classes are copied after the bundle plugin runs and all is well. I have no idea how that will impact the OSGi bundle though. Then again, I have no idea if OSGi will support multi-release jars.
Ralph
> On Mar 15, 2017, at 11:36 PM, Ralph Goers <ra...@dslextreme.com> wrote:
>
> I have built the Java 9 code. Now I am copying the classes into the log4j-api jar. They have to be placed at META-INF/versions/9. However, when I do this I am getting an error from the Maven bundle plugin.
>
> [INFO] --- maven-bundle-plugin:3.2.0:manifest (default) @ log4j-api ---
> [ERROR] Manifest org.apache.logging.log4j:log4j-api:jar:2.8.2-SNAPSHOT : Classes found in the wrong directory: {META-INF/versions/9/org/apache/logging/log4j/util/ReflectionUtil.class=org.apache.logging.log4j.util.ReflectionUtil, META-INF/versions/9/org/apache/logging/log4j/util/ClassPredicate.class=org.apache.logging.log4j.util.ClassPredicate, META-INF/versions/9/org/apache/logging/log4j/util/ClassNamePredicate.class=org.apache.logging.log4j.util.ClassNamePredicate}
> [ERROR] Error(s) found in manifest configuration
>
> Any idea on how to get around this?
>
> Ralph
>
>
>
>
>
>> On Mar 15, 2017, at 9:14 AM, Ralph Goers <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
>>
>> I don’t see a problem with it. What is released will still run fine on Java 7. It will just have some Java 9 components in the jar. The release is scheduled for late July. I haven’t seen any indication that it will be pushed again. I would rather be ready to take advantage of Java 9 on the day it is released then be playing catch-up.
>>
>> Ralph
>>
>>> On Mar 15, 2017, at 8:38 AM, Mikael Ståldal <mikael.staldal@magine.com <ma...@magine.com>> wrote:
>>>
>>> It would be bad to require Java 9 to build the main project as long as Java 9 is not released.
>>>
>>> On Wed, Mar 15, 2017 at 4:27 PM, Ralph Goers <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
>>> I can’t change the JDK from JDK 1.7. The rest of the build must be compiled at Java 7 since that is what we support. I only want to compile the new classes with Java 9.
>>>
>>> Using a profile is a very good solution. We would have to run the build twice but that would be OK. I will give that a try.
>>>
>>> Ralph
>>>
>>>> On Mar 15, 2017, at 8:13 AM, Matt Sicker <boards@gmail.com <ma...@gmail.com>> wrote:
>>>>
>>>> You can change the JDK from "JDK 1.7 (latest)" to one of the JDK 9 versions. Since there's no official release of 9 yet, they don't seem to have a "JDK 9 (latest)" profile set up on Jenkins yet.
>>>>
>>>> As for building this, the best solution I've seen so far basically involves a bit of manual configuration using some inline ant tasks or similar overly complicated nonsense which doesn't work well in any IDE to date. It may be worth investigating the existing maven plugin ecosystem and seeing if we need a custom plugin developed for this. Could be a useful feature addition to maven-compiler-plugin, though I haven't tried contributing to Maven yet.
>>>>
>>>> Using Maven profiles would help with this so that we can still build most of the project locally with JDK 1.7 or 1.8 as I doubt everyone wants to install JDK 9 on all their development machines while it's still in beta.
>>>>
>>>> On 15 March 2017 at 10:07, Ralph Goers <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
>>>> I know how to implement the StackWalker code but I don’t quite know how to get it into the build. The main build needs to keep using Java 7 but of course the StackWalker stuff needs to be compiled with Java 9. Technically, I know how I could do that except I have no idea how it would work in Jenkins. It would also mean that everyone would be required to have Java 9 installed in order to do the build.
>>>>
>>>> An alternate approach would be to have the Java 9 specific classes in a separate repo with its own build. It would have to be “released” but we really wouldn’t need or want to release those jars to Maven Central as they would only be needed in the Log4j build - the classes would be copied into the Log4j jar.
>>>>
>>>> If any of you know we can set a Jenkins variable to point to the latest Java 9 version that could solve the problem.
>>>>
>>>> Ralph
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org <ma...@logging.apache.org>
>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org <ma...@logging.apache.org>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>>>
>>>
>>>
>>>
>>> --
>>>
>>>
>>> Mikael Ståldal
>>> Senior software developer
>>>
>>> Magine TV
>>> mikael.staldal@magine.com <ma...@magine.com>
>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com <http://www.magine.com/>
>>>
>>> Privileged and/or Confidential Information may be contained in this message. If you are not the addressee indicated in this message
>>> (or responsible for delivery of the message to such a person), you may not copy or deliver this message to anyone. In such case,
>>> you should destroy this message and kindly notify the sender by reply email.
>>
>
Re: Java 9 support
Posted by Ralph Goers <ra...@dslextreme.com>.
I have built the Java 9 code. Now I am copying the classes into the log4j-api jar. They have to be placed at META-INF/versions/9. However, when I do this I am getting an error from the Maven bundle plugin.
[INFO] --- maven-bundle-plugin:3.2.0:manifest (default) @ log4j-api ---
[ERROR] Manifest org.apache.logging.log4j:log4j-api:jar:2.8.2-SNAPSHOT : Classes found in the wrong directory: {META-INF/versions/9/org/apache/logging/log4j/util/ReflectionUtil.class=org.apache.logging.log4j.util.ReflectionUtil, META-INF/versions/9/org/apache/logging/log4j/util/ClassPredicate.class=org.apache.logging.log4j.util.ClassPredicate, META-INF/versions/9/org/apache/logging/log4j/util/ClassNamePredicate.class=org.apache.logging.log4j.util.ClassNamePredicate}
[ERROR] Error(s) found in manifest configuration
Any idea on how to get around this?
Ralph
> On Mar 15, 2017, at 9:14 AM, Ralph Goers <ra...@dslextreme.com> wrote:
>
> I don’t see a problem with it. What is released will still run fine on Java 7. It will just have some Java 9 components in the jar. The release is scheduled for late July. I haven’t seen any indication that it will be pushed again. I would rather be ready to take advantage of Java 9 on the day it is released then be playing catch-up.
>
> Ralph
>
>> On Mar 15, 2017, at 8:38 AM, Mikael Ståldal <mikael.staldal@magine.com <ma...@magine.com>> wrote:
>>
>> It would be bad to require Java 9 to build the main project as long as Java 9 is not released.
>>
>> On Wed, Mar 15, 2017 at 4:27 PM, Ralph Goers <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
>> I can’t change the JDK from JDK 1.7. The rest of the build must be compiled at Java 7 since that is what we support. I only want to compile the new classes with Java 9.
>>
>> Using a profile is a very good solution. We would have to run the build twice but that would be OK. I will give that a try.
>>
>> Ralph
>>
>>> On Mar 15, 2017, at 8:13 AM, Matt Sicker <boards@gmail.com <ma...@gmail.com>> wrote:
>>>
>>> You can change the JDK from "JDK 1.7 (latest)" to one of the JDK 9 versions. Since there's no official release of 9 yet, they don't seem to have a "JDK 9 (latest)" profile set up on Jenkins yet.
>>>
>>> As for building this, the best solution I've seen so far basically involves a bit of manual configuration using some inline ant tasks or similar overly complicated nonsense which doesn't work well in any IDE to date. It may be worth investigating the existing maven plugin ecosystem and seeing if we need a custom plugin developed for this. Could be a useful feature addition to maven-compiler-plugin, though I haven't tried contributing to Maven yet.
>>>
>>> Using Maven profiles would help with this so that we can still build most of the project locally with JDK 1.7 or 1.8 as I doubt everyone wants to install JDK 9 on all their development machines while it's still in beta.
>>>
>>> On 15 March 2017 at 10:07, Ralph Goers <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
>>> I know how to implement the StackWalker code but I don’t quite know how to get it into the build. The main build needs to keep using Java 7 but of course the StackWalker stuff needs to be compiled with Java 9. Technically, I know how I could do that except I have no idea how it would work in Jenkins. It would also mean that everyone would be required to have Java 9 installed in order to do the build.
>>>
>>> An alternate approach would be to have the Java 9 specific classes in a separate repo with its own build. It would have to be “released” but we really wouldn’t need or want to release those jars to Maven Central as they would only be needed in the Log4j build - the classes would be copied into the Log4j jar.
>>>
>>> If any of you know we can set a Jenkins variable to point to the latest Java 9 version that could solve the problem.
>>>
>>> Ralph
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org <ma...@logging.apache.org>
>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org <ma...@logging.apache.org>
>>>
>>>
>>>
>>>
>>> --
>>> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>>
>>
>>
>>
>> --
>>
>>
>> Mikael Ståldal
>> Senior software developer
>>
>> Magine TV
>> mikael.staldal@magine.com <ma...@magine.com>
>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com <http://www.magine.com/>
>>
>> Privileged and/or Confidential Information may be contained in this message. If you are not the addressee indicated in this message
>> (or responsible for delivery of the message to such a person), you may not copy or deliver this message to anyone. In such case,
>> you should destroy this message and kindly notify the sender by reply email.
>
Re: Java 9 support
Posted by Ralph Goers <ra...@dslextreme.com>.
I don’t see a problem with it. What is released will still run fine on Java 7. It will just have some Java 9 components in the jar. The release is scheduled for late July. I haven’t seen any indication that it will be pushed again. I would rather be ready to take advantage of Java 9 on the day it is released then be playing catch-up.
Ralph
> On Mar 15, 2017, at 8:38 AM, Mikael Ståldal <mi...@magine.com> wrote:
>
> It would be bad to require Java 9 to build the main project as long as Java 9 is not released.
>
> On Wed, Mar 15, 2017 at 4:27 PM, Ralph Goers <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
> I can’t change the JDK from JDK 1.7. The rest of the build must be compiled at Java 7 since that is what we support. I only want to compile the new classes with Java 9.
>
> Using a profile is a very good solution. We would have to run the build twice but that would be OK. I will give that a try.
>
> Ralph
>
>> On Mar 15, 2017, at 8:13 AM, Matt Sicker <boards@gmail.com <ma...@gmail.com>> wrote:
>>
>> You can change the JDK from "JDK 1.7 (latest)" to one of the JDK 9 versions. Since there's no official release of 9 yet, they don't seem to have a "JDK 9 (latest)" profile set up on Jenkins yet.
>>
>> As for building this, the best solution I've seen so far basically involves a bit of manual configuration using some inline ant tasks or similar overly complicated nonsense which doesn't work well in any IDE to date. It may be worth investigating the existing maven plugin ecosystem and seeing if we need a custom plugin developed for this. Could be a useful feature addition to maven-compiler-plugin, though I haven't tried contributing to Maven yet.
>>
>> Using Maven profiles would help with this so that we can still build most of the project locally with JDK 1.7 or 1.8 as I doubt everyone wants to install JDK 9 on all their development machines while it's still in beta.
>>
>> On 15 March 2017 at 10:07, Ralph Goers <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
>> I know how to implement the StackWalker code but I don’t quite know how to get it into the build. The main build needs to keep using Java 7 but of course the StackWalker stuff needs to be compiled with Java 9. Technically, I know how I could do that except I have no idea how it would work in Jenkins. It would also mean that everyone would be required to have Java 9 installed in order to do the build.
>>
>> An alternate approach would be to have the Java 9 specific classes in a separate repo with its own build. It would have to be “released” but we really wouldn’t need or want to release those jars to Maven Central as they would only be needed in the Log4j build - the classes would be copied into the Log4j jar.
>>
>> If any of you know we can set a Jenkins variable to point to the latest Java 9 version that could solve the problem.
>>
>> Ralph
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org <ma...@logging.apache.org>
>> For additional commands, e-mail: log4j-dev-help@logging.apache.org <ma...@logging.apache.org>
>>
>>
>>
>>
>> --
>> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>
>
>
>
> --
>
>
> Mikael Ståldal
> Senior software developer
>
> Magine TV
> mikael.staldal@magine.com <ma...@magine.com>
> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com <http://www.magine.com/>
>
> Privileged and/or Confidential Information may be contained in this message. If you are not the addressee indicated in this message
> (or responsible for delivery of the message to such a person), you may not copy or deliver this message to anyone. In such case,
> you should destroy this message and kindly notify the sender by reply email.
Re: Java 9 support
Posted by Mikael Ståldal <mi...@magine.com>.
It would be bad to require Java 9 to build the main project as long as Java
9 is not released.
On Wed, Mar 15, 2017 at 4:27 PM, Ralph Goers <ra...@dslextreme.com>
wrote:
> I can’t change the JDK from JDK 1.7. The rest of the build must be
> compiled at Java 7 since that is what we support. I only want to compile
> the new classes with Java 9.
>
> Using a profile is a very good solution. We would have to run the build
> twice but that would be OK. I will give that a try.
>
> Ralph
>
> On Mar 15, 2017, at 8:13 AM, Matt Sicker <bo...@gmail.com> wrote:
>
> You can change the JDK from "JDK 1.7 (latest)" to one of the JDK 9
> versions. Since there's no official release of 9 yet, they don't seem to
> have a "JDK 9 (latest)" profile set up on Jenkins yet.
>
> As for building this, the best solution I've seen so far basically
> involves a bit of manual configuration using some inline ant tasks or
> similar overly complicated nonsense which doesn't work well in any IDE to
> date. It may be worth investigating the existing maven plugin ecosystem and
> seeing if we need a custom plugin developed for this. Could be a useful
> feature addition to maven-compiler-plugin, though I haven't tried
> contributing to Maven yet.
>
> Using Maven profiles would help with this so that we can still build most
> of the project locally with JDK 1.7 or 1.8 as I doubt everyone wants to
> install JDK 9 on all their development machines while it's still in beta.
>
> On 15 March 2017 at 10:07, Ralph Goers <ra...@dslextreme.com> wrote:
>
>> I know how to implement the StackWalker code but I don’t quite know how
>> to get it into the build. The main build needs to keep using Java 7 but of
>> course the StackWalker stuff needs to be compiled with Java 9. Technically,
>> I know how I could do that except I have no idea how it would work in
>> Jenkins. It would also mean that everyone would be required to have Java 9
>> installed in order to do the build.
>>
>> An alternate approach would be to have the Java 9 specific classes in a
>> separate repo with its own build. It would have to be “released” but we
>> really wouldn’t need or want to release those jars to Maven Central as they
>> would only be needed in the Log4j build - the classes would be copied into
>> the Log4j jar.
>>
>> If any of you know we can set a Jenkins variable to point to the latest
>> Java 9 version that could solve the problem.
>>
>> Ralph
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>
>>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
>
>
--
[image: MagineTV]
*Mikael Ståldal*
Senior software developer
*Magine TV*
mikael.staldal@magine.com
Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
Privileged and/or Confidential Information may be contained in this
message. If you are not the addressee indicated in this message
(or responsible for delivery of the message to such a person), you may not
copy or deliver this message to anyone. In such case,
you should destroy this message and kindly notify the sender by reply
email.
Re: Java 9 support
Posted by Ralph Goers <ra...@dslextreme.com>.
I can’t change the JDK from JDK 1.7. The rest of the build must be compiled at Java 7 since that is what we support. I only want to compile the new classes with Java 9.
Using a profile is a very good solution. We would have to run the build twice but that would be OK. I will give that a try.
Ralph
> On Mar 15, 2017, at 8:13 AM, Matt Sicker <bo...@gmail.com> wrote:
>
> You can change the JDK from "JDK 1.7 (latest)" to one of the JDK 9 versions. Since there's no official release of 9 yet, they don't seem to have a "JDK 9 (latest)" profile set up on Jenkins yet.
>
> As for building this, the best solution I've seen so far basically involves a bit of manual configuration using some inline ant tasks or similar overly complicated nonsense which doesn't work well in any IDE to date. It may be worth investigating the existing maven plugin ecosystem and seeing if we need a custom plugin developed for this. Could be a useful feature addition to maven-compiler-plugin, though I haven't tried contributing to Maven yet.
>
> Using Maven profiles would help with this so that we can still build most of the project locally with JDK 1.7 or 1.8 as I doubt everyone wants to install JDK 9 on all their development machines while it's still in beta.
>
> On 15 March 2017 at 10:07, Ralph Goers <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
> I know how to implement the StackWalker code but I don’t quite know how to get it into the build. The main build needs to keep using Java 7 but of course the StackWalker stuff needs to be compiled with Java 9. Technically, I know how I could do that except I have no idea how it would work in Jenkins. It would also mean that everyone would be required to have Java 9 installed in order to do the build.
>
> An alternate approach would be to have the Java 9 specific classes in a separate repo with its own build. It would have to be “released” but we really wouldn’t need or want to release those jars to Maven Central as they would only be needed in the Log4j build - the classes would be copied into the Log4j jar.
>
> If any of you know we can set a Jenkins variable to point to the latest Java 9 version that could solve the problem.
>
> Ralph
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org <ma...@logging.apache.org>
> For additional commands, e-mail: log4j-dev-help@logging.apache.org <ma...@logging.apache.org>
>
>
>
>
> --
> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
Re: Java 9 support
Posted by Matt Sicker <bo...@gmail.com>.
You can change the JDK from "JDK 1.7 (latest)" to one of the JDK 9
versions. Since there's no official release of 9 yet, they don't seem to
have a "JDK 9 (latest)" profile set up on Jenkins yet.
As for building this, the best solution I've seen so far basically involves
a bit of manual configuration using some inline ant tasks or similar overly
complicated nonsense which doesn't work well in any IDE to date. It may be
worth investigating the existing maven plugin ecosystem and seeing if we
need a custom plugin developed for this. Could be a useful feature addition
to maven-compiler-plugin, though I haven't tried contributing to Maven yet.
Using Maven profiles would help with this so that we can still build most
of the project locally with JDK 1.7 or 1.8 as I doubt everyone wants to
install JDK 9 on all their development machines while it's still in beta.
On 15 March 2017 at 10:07, Ralph Goers <ra...@dslextreme.com> wrote:
> I know how to implement the StackWalker code but I don’t quite know how to
> get it into the build. The main build needs to keep using Java 7 but of
> course the StackWalker stuff needs to be compiled with Java 9. Technically,
> I know how I could do that except I have no idea how it would work in
> Jenkins. It would also mean that everyone would be required to have Java 9
> installed in order to do the build.
>
> An alternate approach would be to have the Java 9 specific classes in a
> separate repo with its own build. It would have to be “released” but we
> really wouldn’t need or want to release those jars to Maven Central as they
> would only be needed in the Log4j build - the classes would be copied into
> the Log4j jar.
>
> If any of you know we can set a Jenkins variable to point to the latest
> Java 9 version that could solve the problem.
>
> Ralph
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
--
Matt Sicker <bo...@gmail.com>