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 wrote:
> In general I agree with your points. However, I don't think we can get rid
> of all the reflection. Thr
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 ev
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 definit
[
https://issues.apache.org/jira/browse/LOG4J2-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13587561#comment-13587561
]
Jed Wesley-Smith commented on LOG4J2-169:
-
> What is bizarre?
Creating a new Conf
[
https://issues.apache.org/jira/browse/LOG4J2-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13587528#comment-13587528
]
Ralph Goers commented on LOG4J2-169:
What is bizarre?
> LogManager.
[
https://issues.apache.org/jira/browse/LOG4J2-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13587526#comment-13587526
]
Jed Wesley-Smith commented on LOG4J2-169:
-
> I looked at this code last night and
[
https://issues.apache.org/jira/browse/LOG4J2-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13587518#comment-13587518
]
Jed Wesley-Smith commented on LOG4J2-169:
-
> Using a CopyOnWriteArrayList seems li
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 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 worke
[
https://issues.apache.org/jira/browse/LOG4J2-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13587467#comment-13587467
]
Gary Gregory commented on LOG4J2-169:
-
Are duplicate factories allowed? If not, the ty
[
https://issues.apache.org/jira/browse/LOG4J2-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13587457#comment-13587457
]
Ralph Goers commented on LOG4J2-169:
I looked at this code last night and it struck me
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 wrote:
> No - I am actually using the Java 6 compiler and it is allowing
>
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 specif
Yogi over on the user list just posted a message saying the extras
companion was not available on any mirrors he tried - only via the archive
repository.
Any ideas how to fix that?
Thanks
Scott
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
[
https://issues.apache.org/jira/browse/LOG4J2-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13587311#comment-13587311
]
Gary Gregory commented on LOG4J2-169:
-
Using a CopyOnWriteArrayList seems like a brute
+1. Let's make Java 6 the requirement.
Gary
On Feb 26, 2013, at 2:25, Ralph Goers 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 set
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 wrote:
> Remko found a bug in AbstractStringLayout where the code actually requires
> Java 6 to compile although it should ru
17 matches
Mail list logo
