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 2013/02/26 08:24:50 UTC
Java compiler version
Remko found a bug in AbstractStringLayout where the code actually requires Java 6 to compile although it should run fine with Java 5. Does anyone have a problem with setting the compile source setting to 1.6 for Log4j 2? That is actually what I have been building all the releases with anyway.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Java compiler version
Posted by Gary Gregory <ga...@gmail.com>.
Move on to Java 6 and remove the dynamic method detection, it's noise IMO.
Gary
On Tue, Feb 26, 2013 at 2:53 PM, Scott Deboy <sc...@gmail.com> wrote:
> If it isn't a deal breaker, I'd say keep Java 5 support..if that changes
> in the future, it changes..at least folks would have a version of log4j2
> that worked on Java5.
>
> Scott
>
>
> On Tue, Feb 26, 2013 at 11:48 AM, Ralph Goers <ra...@dslextreme.com>wrote:
>
>> No - I am actually using the Java 6 compiler and it is allowing
>> AbstractStringLayout to reference a method that is in Java 6 but not Java
>> 5. The code is actually testing if the method exists so it won't get an
>> error when running in Java 5 but will use a less efficient method instead.
>> By specifying the source we are documenting that Java 6 is the minimum
>> compiler version we support.
>>
>> If specifying Java 6 for both source and target is what the majority
>> thinks is best I am OK with that. I actually have no pressing need to
>> support Java 5 for my own purposes.
>>
>> Ralph
>>
>>
>> On Feb 26, 2013, at 11:26 AM, Jacob Kjome wrote:
>>
>> >
>> > All "-source 1.6" does above and beyond 1.5 is allow for using
>> "@Override" on overridden interface methods, which is nice but not
>> critical; certainly no reason to switch to Java 6.
>> >
>> > What you actually seem to be proposing to use "-target 1.6" because you
>> wish to bind to 1.6+ API. This will both prevent compilation with any JDK
>> less than 1.6 and allow for creating 1.6 compatible binaries under later
>> JDKs.
>> >
>> > If there is API in 1.6 that we simply can't live without to produce a
>> quality logging implementation, then go for it, since 1.5 is pretty
>> outdated. But if it's just minor stuff that could be worked around using
>> existing 1.5 API, there are plenty of users stuck with JDK 1.5 that will be
>> left out of using Log4j2 for no good reason.
>> >
>> > In any case, the bug is primarily in our release process rather than
>> code. It is due to the fact that we are generating official release
>> artifacts using a JDK (6 or 7) later than the specified target JDK (5).
>> While javac source/target allows for a flexible build system by not
>> forcing everyday users to install an older JDK in order to generate
>> artifacts compatible with documented target JDK, project release managers
>> should *****always***** use the documented target JDK to generate official
>> release artifacts to avoid accidentally introducing bindings to API that
>> exists in later JDKs, but not the documented target JDK that the project
>> claims to be compatible with. Had this been done, this issue would have
>> been caught long before any official release.
>> >
>> > So, decide on a JDK to target and then actually use that JDK to
>> generate official release artifacts, rather than some arbitrary later one,
>> and we'll never run into this issue again.
>> >
>> >
>> > Jake
>> >
>> > On Mon, 25 Feb 2013 23:24:50 -0800
>> > Ralph Goers <ra...@dslextreme.com> wrote:
>> >> Remko found a bug in AbstractStringLayout where the code actually
>> requires Java 6 to compile although it should run fine with Java 5. Does
>> anyone have a problem with setting the compile source setting to 1.6 for
>> Log4j 2? That is actually what I have been building all the releases with
>> anyway.
>> >> Ralph
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> >> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> > For additional commands, e-mail: log4j-dev-help@logging.apache.org
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>
>>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: Java compiler version
Posted by Scott Deboy <sc...@gmail.com>.
If it isn't a deal breaker, I'd say keep Java 5 support..if that changes in
the future, it changes..at least folks would have a version of log4j2 that
worked on Java5.
Scott
On Tue, Feb 26, 2013 at 11:48 AM, Ralph Goers <ra...@dslextreme.com>wrote:
> No - I am actually using the Java 6 compiler and it is allowing
> AbstractStringLayout to reference a method that is in Java 6 but not Java
> 5. The code is actually testing if the method exists so it won't get an
> error when running in Java 5 but will use a less efficient method instead.
> By specifying the source we are documenting that Java 6 is the minimum
> compiler version we support.
>
> If specifying Java 6 for both source and target is what the majority
> thinks is best I am OK with that. I actually have no pressing need to
> support Java 5 for my own purposes.
>
> Ralph
>
>
> On Feb 26, 2013, at 11:26 AM, Jacob Kjome wrote:
>
> >
> > All "-source 1.6" does above and beyond 1.5 is allow for using
> "@Override" on overridden interface methods, which is nice but not
> critical; certainly no reason to switch to Java 6.
> >
> > What you actually seem to be proposing to use "-target 1.6" because you
> wish to bind to 1.6+ API. This will both prevent compilation with any JDK
> less than 1.6 and allow for creating 1.6 compatible binaries under later
> JDKs.
> >
> > If there is API in 1.6 that we simply can't live without to produce a
> quality logging implementation, then go for it, since 1.5 is pretty
> outdated. But if it's just minor stuff that could be worked around using
> existing 1.5 API, there are plenty of users stuck with JDK 1.5 that will be
> left out of using Log4j2 for no good reason.
> >
> > In any case, the bug is primarily in our release process rather than
> code. It is due to the fact that we are generating official release
> artifacts using a JDK (6 or 7) later than the specified target JDK (5).
> While javac source/target allows for a flexible build system by not
> forcing everyday users to install an older JDK in order to generate
> artifacts compatible with documented target JDK, project release managers
> should *****always***** use the documented target JDK to generate official
> release artifacts to avoid accidentally introducing bindings to API that
> exists in later JDKs, but not the documented target JDK that the project
> claims to be compatible with. Had this been done, this issue would have
> been caught long before any official release.
> >
> > So, decide on a JDK to target and then actually use that JDK to generate
> official release artifacts, rather than some arbitrary later one, and we'll
> never run into this issue again.
> >
> >
> > Jake
> >
> > On Mon, 25 Feb 2013 23:24:50 -0800
> > Ralph Goers <ra...@dslextreme.com> wrote:
> >> Remko found a bug in AbstractStringLayout where the code actually
> requires Java 6 to compile although it should run fine with Java 5. Does
> anyone have a problem with setting the compile source setting to 1.6 for
> Log4j 2? That is actually what I have been building all the releases with
> anyway.
> >> Ralph
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> >> For additional commands, e-mail: log4j-dev-help@logging.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> > For additional commands, e-mail: log4j-dev-help@logging.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
Re: Java compiler version
Posted by Gary Gregory <ga...@gmail.com>.
Personally, I am in favor of moving to Java 6. At work, we are talking
about how to move to Java 7 from 6 is the most efficient manner...
On Tue, Feb 26, 2013 at 4:54 PM, Ralph Goers <ra...@dslextreme.com>wrote:
> In general I agree with your points. However, I don't think we can get rid
> of all the reflection. ThrowableProxy specifically includes support for
> the enhancements introduced in Java 7. I'm not in favor of setting that to
> the minimum version as my employer hasn't moved to that yet and isn't even
> talking about it yet. However, supporting the new "suppressed" data was
> something I thought was important for users so I added via reflection. The
> difference is that I do periodically build and test with Java 7.
>
> Ralph
>
>
> On Feb 26, 2013, at 1:17 PM, Jacob Kjome wrote:
>
> >
> > Ok, I now understand your point about using "-source 1.6" for
> documentation purposes while keeping "-target 1.5" for Java5 compatibility.
> If Java5 is what we decide upon to target, and we are intent upon choosing
> Java version-specific implementations at runtime, I agree that we should
> definitely set "-source 1.6" at a minimum.
> >
> > Nevertheless, using a later JDK to build than you are targeting opens up
> the possibility of unintended Java6 API references leaking into the source.
> I realize that's exactly what you intended in this case, and use
> reflection to choose the appropriate implementation for the runtime Java
> version. But someone else might check in code that doesn't have such a
> check. Or you might check it in yourself on accident. And the release
> coordinator would never detect it at build time. Only if we ran tests
> under Java5 might we catch it at runtime. More likely, we'd have to wait
> for some user to report it.
> >
> > Again, I'm not against targeting Java6 if there's a compelling reason to
> do so. I'm against generating release artifacts using a later JDK than we
> are targeting.
> >
> > Bottom line: get rid of the reflection. Either the performance
> improvement of the Java6-specific getBytes(Charset) (along with other
> Java6-specific API) is compelling enough to use it or we just deal with the
> Java5 getBytes(String). The source/target values should be identical and
> release Java build version should match the source/target or we risk a
> brittle build.
> >
> >
> > Jake
> >
> > On Tue, 26 Feb 2013 11:48:43 -0800
> > Ralph Goers <ra...@dslextreme.com> wrote:
> >> No - I am actually using the Java 6 compiler and it is allowing
> AbstractStringLayout to reference a method that is in Java 6 but not Java
> 5. The code is actually testing if the method exists so it won't get an
> error when running in Java 5 but will use a less efficient method instead.
> By specifying the source we are documenting that Java 6 is the minimum
> compiler version we support.
> >> If specifying Java 6 for both source and target is what the majority
> thinks is best I am OK with that. I actually have no pressing need to
> support Java 5 for my own purposes.
> >> Ralph
> >> On Feb 26, 2013, at 11:26 AM, Jacob Kjome wrote:
> >>> All "-source 1.6" does above and beyond 1.5 is allow for using
> "@Override" on overridden interface methods, which is nice but not
> critical; certainly no reason to switch to Java 6.
> >>> What you actually seem to be proposing to use "-target 1.6" because
> you wish to bind to 1.6+ API. This will both prevent compilation with any
> JDK less than 1.6 and allow for creating 1.6 compatible binaries under
> later JDKs.
> >>> If there is API in 1.6 that we simply can't live without to produce a
> quality logging implementation, then go for it, since 1.5 is pretty
> outdated. But if it's just minor stuff that could be worked around using
> existing 1.5 API, there are plenty of users stuck with JDK 1.5 that will be
> left out of using Log4j2 for no good reason.
> >>> In any case, the bug is primarily in our release process rather than
> code. It is due to the fact that we are generating official release
> artifacts using a JDK (6 or 7) later than the specified target JDK (5).
> While javac source/target allows for a flexible build system by not
> forcing everyday users to install an older JDK in order to generate
> artifacts compatible with documented target JDK, project release managers
> should *****always***** use the documented target JDK to generate official
> release artifacts to avoid accidentally introducing bindings to API that
> exists in later JDKs, but not the documented target JDK that the project
> claims to be compatible with. Had this been done, this issue would have
> been caught long before any official release.
> >>> So, decide on a JDK to target and then actually use that JDK to
> generate official release artifacts, rather than some arbitrary later one,
> and we'll never run into this issue again.
> >>> Jake
> >>> On Mon, 25 Feb 2013 23:24:50 -0800
> >>> Ralph Goers <ra...@dslextreme.com> wrote:
> >>>> Remko found a bug in AbstractStringLayout where the code actually
> requires Java 6 to compile although it should run fine with Java 5. Does
> anyone have a problem with setting the compile source setting to 1.6 for
> Log4j 2? That is actually what I have been building all the releases with
> anyway.
> >>>> Ralph
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> >>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> >>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> >> For additional commands, e-mail: log4j-dev-help@logging.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> > For additional commands, e-mail: log4j-dev-help@logging.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: Java compiler version
Posted by Ralph Goers <ra...@dslextreme.com>.
In general I agree with your points. However, I don't think we can get rid of all the reflection. ThrowableProxy specifically includes support for the enhancements introduced in Java 7. I'm not in favor of setting that to the minimum version as my employer hasn't moved to that yet and isn't even talking about it yet. However, supporting the new "suppressed" data was something I thought was important for users so I added via reflection. The difference is that I do periodically build and test with Java 7.
Ralph
On Feb 26, 2013, at 1:17 PM, Jacob Kjome wrote:
>
> Ok, I now understand your point about using "-source 1.6" for documentation purposes while keeping "-target 1.5" for Java5 compatibility. If Java5 is what we decide upon to target, and we are intent upon choosing Java version-specific implementations at runtime, I agree that we should definitely set "-source 1.6" at a minimum.
>
> Nevertheless, using a later JDK to build than you are targeting opens up the possibility of unintended Java6 API references leaking into the source. I realize that's exactly what you intended in this case, and use reflection to choose the appropriate implementation for the runtime Java version. But someone else might check in code that doesn't have such a check. Or you might check it in yourself on accident. And the release coordinator would never detect it at build time. Only if we ran tests under Java5 might we catch it at runtime. More likely, we'd have to wait for some user to report it.
>
> Again, I'm not against targeting Java6 if there's a compelling reason to do so. I'm against generating release artifacts using a later JDK than we are targeting.
>
> Bottom line: get rid of the reflection. Either the performance improvement of the Java6-specific getBytes(Charset) (along with other Java6-specific API) is compelling enough to use it or we just deal with the Java5 getBytes(String). The source/target values should be identical and release Java build version should match the source/target or we risk a brittle build.
>
>
> Jake
>
> On Tue, 26 Feb 2013 11:48:43 -0800
> Ralph Goers <ra...@dslextreme.com> wrote:
>> No - I am actually using the Java 6 compiler and it is allowing AbstractStringLayout to reference a method that is in Java 6 but not Java 5. The code is actually testing if the method exists so it won't get an error when running in Java 5 but will use a less efficient method instead. By specifying the source we are documenting that Java 6 is the minimum compiler version we support.
>> If specifying Java 6 for both source and target is what the majority thinks is best I am OK with that. I actually have no pressing need to support Java 5 for my own purposes.
>> Ralph
>> On Feb 26, 2013, at 11:26 AM, Jacob Kjome wrote:
>>> All "-source 1.6" does above and beyond 1.5 is allow for using "@Override" on overridden interface methods, which is nice but not critical; certainly no reason to switch to Java 6.
>>> What you actually seem to be proposing to use "-target 1.6" because you wish to bind to 1.6+ API. This will both prevent compilation with any JDK less than 1.6 and allow for creating 1.6 compatible binaries under later JDKs.
>>> If there is API in 1.6 that we simply can't live without to produce a quality logging implementation, then go for it, since 1.5 is pretty outdated. But if it's just minor stuff that could be worked around using existing 1.5 API, there are plenty of users stuck with JDK 1.5 that will be left out of using Log4j2 for no good reason.
>>> In any case, the bug is primarily in our release process rather than code. It is due to the fact that we are generating official release artifacts using a JDK (6 or 7) later than the specified target JDK (5). While javac source/target allows for a flexible build system by not forcing everyday users to install an older JDK in order to generate artifacts compatible with documented target JDK, project release managers should *****always***** use the documented target JDK to generate official release artifacts to avoid accidentally introducing bindings to API that exists in later JDKs, but not the documented target JDK that the project claims to be compatible with. Had this been done, this issue would have been caught long before any official release.
>>> So, decide on a JDK to target and then actually use that JDK to generate official release artifacts, rather than some arbitrary later one, and we'll never run into this issue again.
>>> Jake
>>> On Mon, 25 Feb 2013 23:24:50 -0800
>>> Ralph Goers <ra...@dslextreme.com> wrote:
>>>> Remko found a bug in AbstractStringLayout where the code actually requires Java 6 to compile although it should run fine with Java 5. Does anyone have a problem with setting the compile source setting to 1.6 for Log4j 2? That is actually what I have been building all the releases with anyway.
>>>> Ralph
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Java compiler version
Posted by Jacob Kjome <ho...@visi.com>.
Ok, I now understand your point about using "-source 1.6" for documentation
purposes while keeping "-target 1.5" for Java5 compatibility. If Java5 is
what we decide upon to target, and we are intent upon choosing Java
version-specific implementations at runtime, I agree that we should definitely
set "-source 1.6" at a minimum.
Nevertheless, using a later JDK to build than you are targeting opens up the
possibility of unintended Java6 API references leaking into the source. I
realize that's exactly what you intended in this case, and use reflection to
choose the appropriate implementation for the runtime Java version. But
someone else might check in code that doesn't have such a check. Or you might
check it in yourself on accident. And the release coordinator would never
detect it at build time. Only if we ran tests under Java5 might we catch it
at runtime. More likely, we'd have to wait for some user to report it.
Again, I'm not against targeting Java6 if there's a compelling reason to do
so. I'm against generating release artifacts using a later JDK than we are
targeting.
Bottom line: get rid of the reflection. Either the performance improvement of
the Java6-specific getBytes(Charset) (along with other Java6-specific API) is
compelling enough to use it or we just deal with the Java5 getBytes(String).
The source/target values should be identical and release Java build version
should match the source/target or we risk a brittle build.
Jake
On Tue, 26 Feb 2013 11:48:43 -0800
Ralph Goers <ra...@dslextreme.com> wrote:
> No - I am actually using the Java 6 compiler and it is allowing
>AbstractStringLayout to reference a method that is in Java 6 but not Java 5.
> The code is actually testing if the method exists so it won't get an error
>when running in Java 5 but will use a less efficient method instead. By
>specifying the source we are documenting that Java 6 is the minimum compiler
>version we support.
>
> If specifying Java 6 for both source and target is what the majority thinks
>is best I am OK with that. I actually have no pressing need to support Java 5
>for my own purposes.
>
> Ralph
>
>
> On Feb 26, 2013, at 11:26 AM, Jacob Kjome wrote:
>
>>
>> All "-source 1.6" does above and beyond 1.5 is allow for using "@Override"
>>on overridden interface methods, which is nice but not critical; certainly
>>no reason to switch to Java 6.
>>
>> What you actually seem to be proposing to use "-target 1.6" because you wish
>>to bind to 1.6+ API. This will both prevent compilation with any JDK less
>>than 1.6 and allow for creating 1.6 compatible binaries under later JDKs.
>>
>> If there is API in 1.6 that we simply can't live without to produce a
>>quality logging implementation, then go for it, since 1.5 is pretty outdated.
>> But if it's just minor stuff that could be worked around using existing 1.5
>>API, there are plenty of users stuck with JDK 1.5 that will be left out of
>>using Log4j2 for no good reason.
>>
>> In any case, the bug is primarily in our release process rather than code.
>> It is due to the fact that we are generating official release artifacts
>>using a JDK (6 or 7) later than the specified target JDK (5). While javac
>>source/target allows for a flexible build system by not forcing everyday
>>users to install an older JDK in order to generate artifacts compatible with
>>documented target JDK, project release managers should *****always***** use
>>the documented target JDK to generate official release artifacts to avoid
>>accidentally introducing bindings to API that exists in later JDKs, but not
>>the documented target JDK that the project claims to be compatible with. Had
>>this been done, this issue would have been caught long before any official
>>release.
>>
>> So, decide on a JDK to target and then actually use that JDK to generate
>>official release artifacts, rather than some arbitrary later one, and we'll
>>never run into this issue again.
>>
>>
>> Jake
>>
>> On Mon, 25 Feb 2013 23:24:50 -0800
>> Ralph Goers <ra...@dslextreme.com> wrote:
>>> Remko found a bug in AbstractStringLayout where the code actually requires
>>>Java 6 to compile although it should run fine with Java 5. Does anyone have
>>>a problem with setting the compile source setting to 1.6 for Log4j 2? That
>>>is actually what I have been building all the releases with anyway.
>>> Ralph
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Java compiler version
Posted by Ralph Goers <ra...@dslextreme.com>.
No - I am actually using the Java 6 compiler and it is allowing AbstractStringLayout to reference a method that is in Java 6 but not Java 5. The code is actually testing if the method exists so it won't get an error when running in Java 5 but will use a less efficient method instead. By specifying the source we are documenting that Java 6 is the minimum compiler version we support.
If specifying Java 6 for both source and target is what the majority thinks is best I am OK with that. I actually have no pressing need to support Java 5 for my own purposes.
Ralph
On Feb 26, 2013, at 11:26 AM, Jacob Kjome wrote:
>
> All "-source 1.6" does above and beyond 1.5 is allow for using "@Override" on overridden interface methods, which is nice but not critical; certainly no reason to switch to Java 6.
>
> What you actually seem to be proposing to use "-target 1.6" because you wish to bind to 1.6+ API. This will both prevent compilation with any JDK less than 1.6 and allow for creating 1.6 compatible binaries under later JDKs.
>
> If there is API in 1.6 that we simply can't live without to produce a quality logging implementation, then go for it, since 1.5 is pretty outdated. But if it's just minor stuff that could be worked around using existing 1.5 API, there are plenty of users stuck with JDK 1.5 that will be left out of using Log4j2 for no good reason.
>
> In any case, the bug is primarily in our release process rather than code. It is due to the fact that we are generating official release artifacts using a JDK (6 or 7) later than the specified target JDK (5). While javac source/target allows for a flexible build system by not forcing everyday users to install an older JDK in order to generate artifacts compatible with documented target JDK, project release managers should *****always***** use the documented target JDK to generate official release artifacts to avoid accidentally introducing bindings to API that exists in later JDKs, but not the documented target JDK that the project claims to be compatible with. Had this been done, this issue would have been caught long before any official release.
>
> So, decide on a JDK to target and then actually use that JDK to generate official release artifacts, rather than some arbitrary later one, and we'll never run into this issue again.
>
>
> Jake
>
> On Mon, 25 Feb 2013 23:24:50 -0800
> Ralph Goers <ra...@dslextreme.com> wrote:
>> Remko found a bug in AbstractStringLayout where the code actually requires Java 6 to compile although it should run fine with Java 5. Does anyone have a problem with setting the compile source setting to 1.6 for Log4j 2? That is actually what I have been building all the releases with anyway.
>> Ralph
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Java compiler version
Posted by Jacob Kjome <ho...@visi.com>.
All "-source 1.6" does above and beyond 1.5 is allow for using "@Override" on
overridden interface methods, which is nice but not critical; certainly no
reason to switch to Java 6.
What you actually seem to be proposing to use "-target 1.6" because you wish
to bind to 1.6+ API. This will both prevent compilation with any JDK less
than 1.6 and allow for creating 1.6 compatible binaries under later JDKs.
If there is API in 1.6 that we simply can't live without to produce a quality
logging implementation, then go for it, since 1.5 is pretty outdated. But if
it's just minor stuff that could be worked around using existing 1.5 API,
there are plenty of users stuck with JDK 1.5 that will be left out of using
Log4j2 for no good reason.
In any case, the bug is primarily in our release process rather than code. It
is due to the fact that we are generating official release artifacts using a
JDK (6 or 7) later than the specified target JDK (5). While javac
source/target allows for a flexible build system by not forcing everyday users
to install an older JDK in order to generate artifacts compatible with
documented target JDK, project release managers should *****always***** use
the documented target JDK to generate official release artifacts to avoid
accidentally introducing bindings to API that exists in later JDKs, but not
the documented target JDK that the project claims to be compatible with. Had
this been done, this issue would have been caught long before any official
release.
So, decide on a JDK to target and then actually use that JDK to generate
official release artifacts, rather than some arbitrary later one, and we'll
never run into this issue again.
Jake
On Mon, 25 Feb 2013 23:24:50 -0800
Ralph Goers <ra...@dslextreme.com> wrote:
> Remko found a bug in AbstractStringLayout where the code actually requires
>Java 6 to compile although it should run fine with Java 5. Does anyone have
>a problem with setting the compile source setting to 1.6 for Log4j 2? That
>is actually what I have been building all the releases with anyway.
>
>
> Ralph
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Java compiler version
Posted by Gary Gregory <ga...@gmail.com>.
+1. Let's make Java 6 the requirement.
Gary
On Feb 26, 2013, at 2:25, Ralph Goers <ra...@dslextreme.com> wrote:
> Remko found a bug in AbstractStringLayout where the code actually requires Java 6 to compile although it should run fine with Java 5. Does anyone have a problem with setting the compile source setting to 1.6 for Log4j 2? That is actually what I have been building all the releases with anyway.
>
>
> Ralph
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Java compiler version
Posted by Christian Grobmeier <gr...@gmail.com>.
Java 5 is legacy, and its the perfect time to switch jdk versions
without major bumps. Let's go for Java 6.
Cheers
Christian
On Tue, Feb 26, 2013 at 8:24 AM, Ralph Goers <ra...@dslextreme.com> wrote:
> Remko found a bug in AbstractStringLayout where the code actually requires Java 6 to compile although it should run fine with Java 5. Does anyone have a problem with setting the compile source setting to 1.6 for Log4j 2? That is actually what I have been building all the releases with anyway.
>
>
> Ralph
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
--
http://www.grobmeier.de
https://www.timeandbill.de
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org