be even "___" but not obviously " ".
>
> On Tue, May 15, 2018 at 11:19 AM Jonathan Bluett-Duncan <
> jbluettdun...@gmail.com> wrote:
>
> > How about String.isWhitespaceOrEmpty? I think that accurately describes
> the
> > method.
> >
&g
>> Which jdk version/distribution are you using?
>>
>> I see .level = INFO in the jdk9/master sources:
>> http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/tip/src/java.
>> logging/share/conf/logging.properties
>>
>> There should be no changes WRT the default level between 8
Jeremy
On Thu, Jun 15, 2017 at 1:21 AM, Alan Bateman
wrote:
> On 15/06/2017 01:00, Jeremy Manson wrote:
>
>> :
>>
>> The upshot is that, in the same way as we would have turned on the big
>> kill switch by default to ease the transition, we are also likely to
>>
On Mon, May 8, 2017 at 5:54 AM, dalibor topic
wrote:
> On 05.05.2017 08:39, Jeremy Manson wrote:
>
>> Mostly, I'm telling you all because I think it makes an interesting case
>> study - a large Java installation and the issues it faces trying to roll
>> out JDK 9.
atibility for any desired change, so that users can always perform
stepwise migrations. Thanks for the inspiration. :)
Jeremy
On Mon, May 1, 2017 at 5:38 PM, Brian Goetz wrote:
> Or use multi-release JARs.
>
>
> On 4/25/2017 3:14 AM, Jeremy Manson wrote:
>
>> I guess I can call it reflectively.
>>
>
>
odebase, and it gives us a way to do the ones we can't
do with Unsafe. :)
Jeremy
On Mon, Apr 24, 2017 at 11:50 PM, Alan Bateman
wrote:
> On 25/04/2017 07:29, Jeremy Manson wrote:
>
> Ah, then it sounds as if I just don't know what I'm doing. Any pointers?
>>
>
Thanks, Alan. I don't use byteman, and my agent wasn't working out of the
box to redefine JDK classes... I guess I can keep digging.
Jeremy
On Mon, Apr 24, 2017 at 11:35 PM, Alan Bateman
wrote:
> On 25/04/2017 07:22, Jeremy Manson wrote:
>
> :
>>
>> The instrum
David: What the spec says and what glibc does are two different things:
https://sourceware.org/bugzilla/show_bug.cgi?id=11787
We have an internal Google patch to compensate for this. Nasty stuff.
Jeremy
On Mon, Dec 14, 2015 at 8:44 PM, David Holmes
wrote:
> On 15/12/2015 6:53 AM, Martin Buch
etting back to this)
>
> Hi Jeremy,
>
> On 05/16/2015 03:34 AM, Jeremy Manson wrote:
> > So, I'm pretty dubious, mostly because of the risks mentioned in the JEP.
> > If you need a flag-check and two code paths for every String method,
> that's
> > going to
So, I'm pretty dubious, mostly because of the risks mentioned in the JEP.
If you need a flag-check and two code paths for every String method, that's
going to make the String class more slow and bloated, and make it very
difficult for the JIT compiler to do its job inlining and intrinsifying
calls
Jeremy has already filed a bug (8062116), and is just finishing up the
patch (I jumped the gun a bit by attaching it to the bug - it has a few
bugs in it). I'll probably have something in reasonable shape to review
tomorrow (I've submitted it internally, and I want to let it spend a day or
so havi
Is there a bug?
Jeremy
On Mon, Aug 18, 2014 at 12:02 PM, Mike Duigou
wrote:
>
> On Aug 15 2014, at 22:38 , Jeremy Manson wrote:
>
> > No love from core-libs-dev?
>
> Pavel has been looking into this and doing corpus and historical bug
> checks. It seems possible that
No love from core-libs-dev? It's backwards-incompatible, but in a way that
would unbreak existing broken code. Might be a worthwhile cleanup.
Jeremy
On Fri, Aug 8, 2014 at 1:53 PM, Eddie Aftandilian wrote:
> Hi all,
>
> We recently realized that calling new StringBuilder(char) does not do wh
at 8:06 PM, Mandy Chung wrote:
> Hi Jeremy,
>
> Thanks for the feedback and the CallerFinder API you have.
>
>
> On 7/7/2014 9:55 AM, Jeremy Manson wrote:
>
> Hey folks,
>
> I don't know if Mandy's draft JEP has gotten any love,
>
>
> The JEP p
catch (IOException ioe) {
System.err.println("IOException happens in
testCreateTempFile");
On Mon, Jun 30, 2014 at 6:05 PM, Jeremy Manson
wrote:
> Hi folks,
>
> We had a couple of complaints about this from our users, and it is a
> pretty trivial fix, so I
On Thu, Mar 7, 2013 at 3:26 PM, Dean Long wrote:
> On 3/7/2013 10:18 AM, Jeremy Manson wrote:
>
> Hi guys,
>
> I'm really glad to see you are doing this. We've done something similar
> to good effect within Google (and we'll probably drop our similar, intern
Hi guys,
I'm really glad to see you are doing this. We've done something similar to
good effect within Google (and we'll probably drop our similar, internal
patch and pick up this patch once it is pushed).
Have you thought about support for having a JNI_OnLoad inside of a main
executable that *d
, Feb 18, 2013 at 1:36 AM, Florian Weimer wrote:
> On 02/17/2013 11:55 PM, David Holmes wrote:
>
>> On 16/02/2013 2:46 AM, Florian Weimer wrote:
>>
>>> On 02/15/2013 05:41 PM, Jeremy Manson wrote:
>>>
>>>> Can we just blacklist 4.1.2 explicitly?
&
Can we just blacklist 4.1.2 explicitly?
Jeremy
On Fri, Feb 15, 2013 at 2:20 AM, David Holmes wrote:
> On 15/02/2013 5:26 PM, Jeremy Manson wrote:
>
>> a) I don't know what's going on behind the scenes, but if this sounds
>> like a good idea to folks, can we op
a) I don't know what's going on behind the scenes, but if this sounds like
a good idea to folks, can we open a bug and get the process otherwise
rolling?
b) Martin, where did the 4.2 restriction come from? Both Apple's site and
the gcc wiki say that visibility support arrived in 4.0:
http://gcc.
Hi folks,
Pardon if this has come up before; a quick search didn't indicate anything,
but the mailing list archives are kind of hard to search.
I wonder if it makes sense to define JNIEXPORT as meaning __attribute__
((visibility ("default"))) when compiling with gcc. Currently, anyone
building J
Second, FWIW. Our users are constantly baffled as to why all of their
blocked-on-epoll threads are listed as RUNNABLE.
Jeremy
On Fri, Aug 13, 2010 at 10:18 AM, Martin Buchholz wrote:
> As a related project, we could fix the JDK so that threads blocked in IO
> operations would be much more likel
is my understanding that you can ship
whatever you want, as long as you abide by the GPL and don't claim
that what you are shipping is "Java".
Jeremy
On Sat, Aug 22, 2009 at 9:54 AM, Jeremy Manson wrote:
> To be fair, it isn't really all that much compared to the size of the
> plat
ly wants to use none of it.
>
> I guess that modular Java helps a little bit here in minimising the required
> class file list?
>
> Stephen
>
>
> Jeremy Manson wrote:
>>
>> Even with just a bytecode execution engine, you would need pretty much
>> all
Even with just a bytecode execution engine, you would need pretty much
all of the Throwables in java.lang - NullPointerException,
OutOfMemoryError, ArithmeticException, VerifyError, ClassFormatError,
IndexOutOfBoundsException and the like.
The flip side of "what classes does the VM need" is "what
ropriate native-language
* definition of it; returns {...@code false} otherwise.
*
* @since 1.7
*/
public boolean tryLink();
Jeremy
On Thu, Aug 13, 2009 at 1:49 AM, Alan Bateman wrote:
> Jeremy Manson wrote:
>>
>> Hi folks,
>>
>> I found myself in need o
Hi folks,
I found myself in need of a method that determines whether a given
native method is linked, and links it if it is present. My use case
prevents me from calling the method directly and catching an
UnsatisfiedLinkError, because the method has side effects.
This is not the first time I've
;> Here is a patch to improve the performance of
>> LogRecord.inferCaller. This improves the performance
>> of the microbenchmark in 6511515 by 5x.
>> Swamy, please review.
>> Contributed by Jeremy Manson.
>> http://cr.openjdk.java.net/~martin/inferCaller
>>
>
28 matches
Mail list logo
