Garbage free use cases typically have daily downtime (after trading closes
for the day for example), though admittedly I don’t know everyone’s use
cases.
On Tue, Mar 10, 2020 at 23:55 Ralph Goers
wrote:
> I have modified TimeFilter to properly account for the change from
> daylight saving time t
I have modified TimeFilter to properly account for the change from daylight
saving time to standard time and vice-versa. I also modified it to handle a
start time on the day before the end time. I have a suspicion that this filter
is being lightly used because there are a whole lot of use cases
You can encode it with \u codes. Emoji require multiple code points
anyways, so file formats can get weird whenever they're not using UTF-8.
On Tue, 10 Mar 2020 at 19:33, Gary Gregory wrote:
> I do not think your file.encoding sys prop matters, see the Javadoc for the
> Properties class.
>
> Gar
I do not think your file.encoding sys prop matters, see the Javadoc for the
Properties class.
Gary
On Tue, Mar 10, 2020, 20:22 Christopher wrote:
> That was my guess, but I don't see how this could happen since my JVM
> default encoding, my terminal, System.getProperty("file.encoding"),
> Syste
According to https://en.wikipedia.org/wiki/.properties , .properties files
are ISO-8859-1, except Java reads them as UTF-8 since Java 9, and falls
back to ISO-8859-1. I'd have to dig further to see how log4j is reading the
config files. It might be a library or custom code that assumes ISO-8859-1,
That was my guess, but I don't see how this could happen since my JVM
default encoding, my terminal, System.getProperty("file.encoding"),
System.getProperty("input.encoding") and the BOM in the config file are all
UTF-8. I'm using Java 11.
On Tue, Mar 10, 2020 at 8:17 PM Carter Kozak wrote:
> I
I think only new Java versions parse prop files as utf8
Gary
On Tue, Mar 10, 2020, 20:17 Carter Kozak wrote:
> I wonder if the log4j2.properties file is being parsed as ISO-8859-1
> rather than UTF-8, so we're not reading the cat properly?
>
> On Tue, Mar 10, 2020, at 20:04, Christopher wrote:
I wonder if the log4j2.properties file is being parsed as ISO-8859-1 rather
than UTF-8, so we're not reading the cat properly?
On Tue, Mar 10, 2020, at 20:04, Christopher wrote:
> In my log4j2.properties file, I used:
>
> appender.console.type = Console
> appender.console.name = STDERR
> appende
In my log4j2.properties file, I used:
appender.console.type = Console
appender.console.name = STDERR
appender.console.target = SYSTEM_ERR
appender.console.layout.type = PatternLayout
appender.console.layout.pattern = 🐈%style{%d{ISO8601}}{dim,cyan}
%style{[}{red}%style{%-8c{2}}{dim,blue}%style{]}{r
Did you specify a charset on the layout that supports that character?
Ralph
> On Mar 10, 2020, at 1:57 PM, Christopher wrote:
>
> I tried to put in a kitty (🐈) in my LayoutPattern, but it didn't
> work. It replaced it with some weird character. Is this is a known
> bug?
> Does PatternLayout not
I tried to put in a kitty (🐈) in my LayoutPattern, but it didn't
work. It replaced it with some weird character. Is this is a known
bug?
Does PatternLayout not support wide characters?
On Tue, Mar 10, 2020 at 12:06 PM Ralph Goers
wrote:
>
>
> > On Mar 10, 2020, at 8:40 AM, Gary Gregory
> wrote:
> >
> > My POV has nothing to do with performance, more about code clarity.
> > Building strings 'manually' can be error/typo prone, you can type a ','
> > instead of a '.' for example.
> On Mar 10, 2020, at 8:40 AM, Gary Gregory wrote:
>
> My POV has nothing to do with performance, more about code clarity.
> Building strings 'manually' can be error/typo prone, you can type a ','
> instead of a '.' for example. The idea being using String... was to
> formalize the split of hi
My POV has nothing to do with performance, more about code clarity.
Building strings 'manually' can be error/typo prone, you can type a ','
instead of a '.' for example. The idea being using String... was to
formalize the split of hierarchical elements just like you see in APIs
like java.nio.file.P
Yes, I was agreeing with you, Ralph. My (poorly articulated) point was that
concatenation can be optimized by the compiler as you mentioned, in addition to
cases where not all of the values are known at compile time. Sorry for the
confusion!
-ck
On Tue, Mar 10, 2020, at 11:13, Ralph Goers wro
Even with that, it is still no match for string concatenation performed by the
compiler. Notice that Gary’s example is concatenating two constants. The
compiler can detect that and concatenate them into a single string during
compilation.
In any case, using the comma operator means we would h
Jdk9+ provides https://openjdk.java.net/jeps/280 which makes string
concatenation with dynamic values more performant than string builders. That
said, requesting loggers from the context is already relatively expensive and
isn't expected to be on hot paths.
-ck
On Tue, Mar 10, 2020, at 10:32,
Cleaner? You changed a plus sign to a comma and turned the concatenation from
happening at compile time to runtime. Even if you could I would argue you
shouldn’t.
Ralph
> On Mar 10, 2020, at 7:10 AM, Gary Gregory wrote:
>
> On Mon, Mar 9, 2020 at 11:10 AM Ralph Goers
> wrote:
>
>> Why would
On Mon, Mar 9, 2020 at 11:10 AM Ralph Goers
wrote:
> Why would you want to do that? Most people seem to prefer getLogger()
> while I prefer getLogger(MyClass.class). I can’t imagine why anyone would
> want to dynamically construct a name like that and if they did, why
> wouldn’t they just using
19 matches
Mail list logo
