On Wed, 9 Mar 2022 13:11:27 GMT, Roman Kennke wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [8eb453ba](https://github.com/openjdk/jdk/commit/8eb453baebe377697286f7eb32280ca9f1fd7775)
> from the [openjdk/jdk](https://git.openjdk.java.net/jdk) repos
On Wed, 9 Mar 2022 13:11:27 GMT, Roman Kennke wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [8eb453ba](https://github.com/openjdk/jdk/commit/8eb453baebe377697286f7eb32280ca9f1fd7775)
> from the [openjdk/jdk](https://git.openjdk.java.net/jdk) repos
Hi all,
This pull request contains a backport of commit
[8eb453ba](https://github.com/openjdk/jdk/commit/8eb453baebe377697286f7eb32280ca9f1fd7775)
from the [openjdk/jdk](https://git.openjdk.java.net/jdk) repository.
The commit being backported was authored by Roman Kennke on 10 Dec
On Thu, 13 Jan 2022 12:19:03 GMT, Roman Kennke wrote:
>> Thread.java would benefit from a refactoring similar to JDK-8278065 to use
>> ClassValue instead of the somewhat problematic WeakClassKey mechanism.
>>
>> Testing:
>> - [x] tier1
>> - [x] tier2
On Wed, 12 Jan 2022 19:39:29 GMT, Roman Kennke wrote:
> Thread.java would benefit from a refactoring similar to JDK-8278065 to use
> ClassValue instead of the somewhat problematic WeakClassKey mechanism.
>
> Testing:
> - [x] tier1
> - [x] tier2
> - [x] tier3
This pull
On Thu, 13 Jan 2022 14:41:51 GMT, Roger Riggs wrote:
>> Roman Kennke has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove obsolete comment
>
> @AlanBateman has been doing a lot of work with j.l.Thread
On Wed, 26 Jan 2022 19:09:58 GMT, Alan Bateman wrote:
> I think this looks okay. It's only used when running with a SecurityManager
> so unlikely to be used in most deployments.
Thanks, Alan! Could you also 'approve' this PR?
Thanks, Roman
-
PR: https://git.openjdk.java.net/jdk/p
On Wed, 19 Jan 2022 08:25:55 GMT, Aleksey Shipilev wrote:
>> JDK-8277072 introduced java.io.ClassCache, but there seem to be at least two
>> issues with it:
>> - The cache cannot disambiguate between cleared SoftReference and the
>> accidental passing of `null` value; in that case, the retry
On Fri, 14 Jan 2022 22:26:31 GMT, Aleksey Shipilev wrote:
> > One additional improvement would be to change r.get() == null to
> > r.refersTo(null) to check for cleared reference, that avoids reviving the
> > referent, e.g. in SATB GCs. I leave that up to you.
>
> I think that does not work, b
On Fri, 14 Jan 2022 19:27:18 GMT, Aleksey Shipilev wrote:
> JDK-8277072 introduced java.io.ClassCache, but there seem to be at least two
> issues with it:
> - The cache cannot disambiguate between cleared SoftReference and the
> accidental passing of `null` value; in that case, the retry loop
On Fri, 14 Jan 2022 19:27:18 GMT, Aleksey Shipilev wrote:
> JDK-8277072 introduced java.io.ClassCache, but there seem to be at least two
> issues with it:
> - The cache cannot disambiguate between cleared SoftReference and the
> accidental passing of `null` value; in that case, the retry loop
On Thu, 13 Jan 2022 10:02:04 GMT, Andrey Turbanov wrote:
>> Roman Kennke has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove obsolete comment
>
> src/java.base/share/classes/java/lang/Thread.java line 1
> Thread.java would benefit from a refactoring similar to JDK-8278065 to use
> ClassValue instead of the somewhat problematic WeakClassKey mechanism.
>
> Testing:
> - [x] tier1
> - [x] tier2
> - [x] tier3
Roman Kennke has updated the pull request incrementally with o
Thread.java would benefit from a refactoring similar to JDK-8278065 to use
ClassValue instead of the somewhat problematic WeakClassKey mechanism.
Testing:
- [x] tier1
- [x] tier2
- [x] tier3
-
Commit messages:
- 8279917: Refactor subclassAudits in Thread to use ClassValue
Chang
On Wed, 12 Jan 2022 14:27:17 GMT, Roger Riggs wrote:
> I would have appreciated a chance to review the latest changes.
Oh, ok, I'm sorry. I will wait some more next time that I get into a similar
situation. I hope you're ok with the changes?
-
PR: https://git.openjdk.java.net/jdk/
On Wed, 1 Dec 2021 14:45:23 GMT, Roman Kennke wrote:
> As a follow-up to #6375, this change refactors
> java.io.ObjectInputStream.Caches#subclassAudits and
> java.io.ObjectOutputStream.Caches#subclassAudits to use ClassValue instead of
> SoftReference, similar to what we did
On Wed, 12 Jan 2022 06:45:02 GMT, Peter Levart wrote:
> I think this looks good. Reviewed. Only a minor nit if you think it would be
> better, but not necessary if you don't. The following combo:
>
> ```
> Boolean result = Caches.subclassAudits.get(cl);
> assert result != null;
cs. Then we can now also remove the
> common machinery java.io.ObjectStreamClass#processQueue and
> java.io.ObjectStreamClass.WeakClassKey.
>
> Testing:
> - [x] tier1
> - [x] tier2
> - [ ] tier3
Roman Kennke has updated the pull request incrementally with two additio
On Fri, 10 Dec 2021 21:07:37 GMT, Roman Kennke wrote:
>> As a follow-up to #6375, this change refactors
>> java.io.ObjectInputStream.Caches#subclassAudits and
>> java.io.ObjectOutputStream.Caches#subclassAudits to use ClassValue instead
>> of SoftReference, similar to
cs. Then we can now also remove the
> common machinery java.io.ObjectStreamClass#processQueue and
> java.io.ObjectStreamClass.WeakClassKey.
>
> Testing:
> - [x] tier1
> - [x] tier2
> - [ ] tier3
Roman Kennke has updated the pull request with a new target base due to a
cs. Then we can now also remove the
> common machinery java.io.ObjectStreamClass#processQueue and
> java.io.ObjectStreamClass.WeakClassKey.
>
> Testing:
> - [x] tier1
> - [x] tier2
> - [ ] tier3
Roman Kennke has updated the pull request with a new target base due to a
On Fri, 12 Nov 2021 21:43:42 GMT, Roman Kennke wrote:
> The caches in ObjectStreamClass basically map WeakReference to
> SoftReference, where the ObjectStreamClass also references
> the same Class. That means that the cache entry, and thus the class and its
> class-loader,
On Fri, 10 Dec 2021 14:44:07 GMT, Kevin Rushforth wrote:
> This is a P4 bug. If the priority is correct, it does not meet the criteria
> to get it into JDK 18 during RDP1, as indicated in [JEP
> 3](https://openjdk.java.net/jeps/3).
>
> If this is objectively a P3 bug, and really does need to g
On Tue, 7 Dec 2021 10:42:50 GMT, Roman Kennke wrote:
>> The caches in ObjectStreamClass basically map WeakReference to
>> SoftReference, where the ObjectStreamClass also
>> references the same Class. That means that the cache entry, and thus the
>> class and its cl
On Tue, 7 Dec 2021 06:23:22 GMT, Peter Levart wrote:
>> Roman Kennke has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix cast; add testcase to cover memory pressure
>
> test/jdk/java/io/ObjectStreamClass/Te
SC's caches.
>
> The proposed change is to use WeakReference instead of SoftReference for the
> values in caches.
>
> Testing:
> - [x] tier1
> - [x] tier2
> - [x] tier3
> - [ ] tier4
Roman Kennke has updated the pull request incrementally with one additional
co
On Sat, 4 Dec 2021 08:47:03 GMT, Peter Levart wrote:
>> Roman Kennke has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove unnecessary import
>
> src/java.base/share/classes/java/io/Cla
SC's caches.
>
> The proposed change is to use WeakReference instead of SoftReference for the
> values in caches.
>
> Testing:
> - [x] tier1
> - [x] tier2
> - [x] tier3
> - [ ] tier4
Roman Kennke has updated the pull request incrementally with one additional
comm
On Thu, 2 Dec 2021 19:49:12 GMT, Roger Riggs wrote:
> Looks good.
Thank you!
I believe it makes sense to also use the ClassCache here, just as I did in
#6375. I'll change this PR accordingly tomorrow.
-
PR: https://git.openjdk.java.net/jdk/pull/6637
On Thu, 2 Dec 2021 16:14:18 GMT, Roger Riggs wrote:
>> Roman Kennke has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Implement ClassCache: reclaim entries under memory pressure
>
> ObjectStreamClass ma
SC's caches.
>
> The proposed change is to use WeakReference instead of SoftReference for the
> values in caches.
>
> Testing:
> - [x] tier1
> - [x] tier2
> - [x] tier3
> - [ ] tier4
Roman Kennke has updated the pull request incrementally with one additional
On Wed, 1 Dec 2021 21:09:14 GMT, Roger Riggs wrote:
> Without the use of SoftReference, memory pressure won't release any of the
> cached info. That seems to swing the other way from overly aggressively
> freeing memory with the WeakReference (and needing to recompute) as the
> change original
SC's caches.
>
> The proposed change is to use WeakReference instead of SoftReference for the
> values in caches.
>
> Testing:
> - [x] tier1
> - [x] tier2
> - [x] tier3
> - [ ] tier4
Roman Kennke has updated the pull request incrementally with one additional
co
As a follow-up to #6375, this change refactors
java.io.ObjectInputStream.Caches#subclassAudits and
java.io.ObjectOutputStream.Caches#subclassAudits to use ClassValue instead of
SoftReference, similar to what we did in #6375 for
java.io.ObjectStreamClass.Caches#localDescs. Then we can now also r
On Wed, 1 Dec 2021 10:49:54 GMT, Peter Levart wrote:
> ...I think that you could remove now obsolete
> java.io.ObjectStreamClass.EntryFuture nested class. It's not used any more.
Done.
> It would be nice to follow-up this patch with patches that make use of
> ClassValue also for:
>
> * j
SC's caches.
>
> The proposed change is to use WeakReference instead of SoftReference for the
> values in caches.
>
> Testing:
> - [x] tier1
> - [x] tier2
> - [x] tier3
> - [ ] tier4
Roman Kennke has updated the pull request incrementally with one additional
comm
On Mon, 15 Nov 2021 21:35:06 GMT, Roman Kennke wrote:
>> The caches in ObjectStreamClass basically map WeakReference to
>> SoftReference, where the ObjectStreamClass also
>> references the same Class. That means that the cache entry, and thus the
>> class and its cl
SC's caches.
>
> The proposed change is to use WeakReference instead of SoftReference for the
> values in caches.
>
> Testing:
> - [x] tier1
> - [x] tier2
> - [x] tier3
> - [ ] tier4
Roman Kennke has updated the pull request with a new target base due to a mer
On Mon, 15 Nov 2021 21:35:06 GMT, Roman Kennke wrote:
>> The caches in ObjectStreamClass basically map WeakReference to
>> SoftReference, where the ObjectStreamClass also
>> references the same Class. That means that the cache entry, and thus the
>> class and its cl
On Mon, 15 Nov 2021 21:35:06 GMT, Roman Kennke wrote:
>> The caches in ObjectStreamClass basically map WeakReference to
>> SoftReference, where the ObjectStreamClass also
>> references the same Class. That means that the cache entry, and thus the
>> class and its cl
On Mon, 15 Nov 2021 19:30:54 GMT, Roger Riggs wrote:
>> Roman Kennke has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Use ForceGC instead of System.gc()
>> - Convert test to testng
>
>
SC's caches.
>
> The proposed change is to use WeakReference instead of SoftReference for the
> values in caches.
>
> Testing:
> - [x] tier1
> - [x] tier2
> - [x] tier3
> - [ ] tier4
Roman Kennke has updated the pull request incrementally with two additiona
On Mon, 15 Nov 2021 18:01:04 GMT, Joe Darcy wrote:
> If the intent of this change is to alter the lifetimes of the objects in
> question in a meaningful way, I recommend a CSR for the behavioral
> compatibility impact.
It would be hard for application code to observe this change: before the
c
The caches in ObjectStreamClass basically map WeakReference to
SoftReference, where the ObjectStreamClass also references
the same Class. That means that the cache entry, and thus the class and its
class-loader, will not get reclaimed, unless the GC determines that memory
pressure is very high.
On Fri, 13 Aug 2021 14:41:54 GMT, Alan Bateman wrote:
> > Is this what you have been asking @mkarg in #4263 to do? Optimize
> > transferTo() only for FileInputStream? Would it interfere with #4263?
>
> #4263 is the input stream returned by Channels.newInputStream where the
> source may be a Fi
On Thu, 12 Aug 2021 21:07:53 GMT, Brian Burkhalter wrote:
>> Please consider this request to add an override
>> `java.io.FileInputStream.transferTo(OutputStream)` with improved performance
>> if the parameter is a `FileOutputStream`.
>
> Brian Burkhalter has updated the pull request incremental
On Mon, 18 Jan 2021 23:42:08 GMT, Kim Barrett wrote:
>> Please review this change which fixes the type of the private
>> Reference.discovered field. It was Reference, but that's wrong because
>> it can be any Reference object.
>>
>> I've changed it to Reference and let that flow through, updati
On Wed, 25 Nov 2020 23:35:14 GMT, Vladimir Kozlov wrote:
>> JDK-8188055 added the function Reference.refersTo. For performance, the
>> supporting native methods Reference.refersTo0 and PhantomReference.refersTo0
>> should be intrinsified by C2.
>>
>> Initial patch was prepared by @fisk.
>>
>>
On Mon, 23 Nov 2020 19:18:05 GMT, Per Liden wrote:
>> test/hotspot/jtreg/gc/TestReferenceClearDuringReferenceProcessing.java line
>> 28:
>>
>>> 26: /* @test
>>> 27: * @bug 8256517
>>> 28: * @requires vm.gc.Z
>>
>> Please add | vm.gc.Shenandoah here.
>
> Note that for this test to be useful,
On Mon, 23 Nov 2020 01:43:39 GMT, Kim Barrett wrote:
> Please review this change to Reference.clear() to address several issues.
>
> (JDK-8240696) For GCs using a SATB barrier, simply assigning the referent
> field to null may extend the lifetime of the referent value.
>
> (JDK-8240696) For GCs
On Mon, 23 Nov 2020 01:43:39 GMT, Kim Barrett wrote:
> Please review this change to Reference.clear() to address several issues.
>
> (JDK-8240696) For GCs using a SATB barrier, simply assigning the referent
> field to null may extend the lifetime of the referent value.
>
> (JDK-8240696) For GCs
On Sun, 22 Nov 2020 22:15:20 GMT, Kim Barrett wrote:
> I didn't notice this before it was integrated.
>
> The test for inactive isn't right; rather than `next == this` it
> should be `next != null`. This becomes apparent once
> FinalizerHistogram is fixed to call getInactive() rather than get().
On Mon, 16 Nov 2020 17:29:20 GMT, Roman Kennke wrote:
> A follow-up to JDK-8256106, this is adding two asserts to check that the API
> is used as it should be, i.e. only on inactive FinalReferences. Also, in
> Finalizer, where getInactive() is used, there is a null-check. The GC must
A follow-up to JDK-8256106, this is adding two asserts to check that the API is
used as it should be, i.e. only on inactive FinalReferences. Also, in
Finalizer, where getInactive() is used, there is a null-check. The GC must
never clean the referent, and Java code doesn't clean it either, it wou
On Wed, 11 Nov 2020 18:13:30 GMT, Albert Mingkun Yang wrote:
> With `getInactive`, is the null check, `if (finalizee != null` still needed?
Good point! I don't think it is. The GC should not clean the referent before we
finalized it (or not at all), and no other code is clearing it either.
Unf
On Wed, 11 Nov 2020 18:19:01 GMT, Mandy Chung wrote:
>> Roman Kennke has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Rename inactive-getter and improve javadocs
>
> src/java.base/share/classes/java/la
On Tue, 10 Nov 2020 09:37:29 GMT, Roman Kennke wrote:
> Finalizer calls Reference.get() from the Finalizer to acquire the finalizee.
> Concurrent reference processing GCs like Shenandoah and ZGC would return NULL
> for unreachable referents, and thus would not call finalize() on them.
trong references.
>
> Testing:
> - [x] hotspot_gc_shenandoah
> - [x] tier1 +UseShenandoahGC +ShenandoahVerify
> - [x] tier2 +UseShenandoahGC +ShenandoahVerify
> - [x] tier1
> - [x] tier2
Roman Kennke has updated the pull request incrementally with one additional
commit sin
trong references.
>
> Testing:
> - [x] hotspot_gc_shenandoah
> - [x] tier1 +UseShenandoahGC +ShenandoahVerify
> - [x] tier2 +UseShenandoahGC +ShenandoahVerify
> - [x] tier1
> - [x] tier2
Roman Kennke has updated the pull request with a new target base due to a merge
or a re
Finalizer calls Reference.get() from the Finalizer to acquire the finalizee.
Concurrent reference processing GCs like Shenandoah and ZGC would return NULL
for unreachable referents, and thus would not call finalize() on them.
ZGC works around this by fixing the referent before enqueuing, so that
On Thu, 2020-07-16 at 08:09 +0100, Alan Bateman wrote:
> On 15/07/2020 20:47, Roman Kennke wrote:
> > :
> > Why would it? Can you explain? (-ExplicitGCInvokesConcurrent is the
> > default for all GCs but Shenandoah, and has been that way forever.
> > Do
> > you
Hi Alan,
> On 15/07/2020 18:20, rken...@redhat.com wrote:
> > DirectBufferAllocTest is unreliable when running with
> > +ExplicitGCInvokesConcurrent, because allocating DBB spreads
> > System.gc() calls all over concurrent GC cycles. It becomes more
> > reliable when running with -ExplicitGCInvoke
That fix looks good to me.
Thanks!
Roman
> The revised webrev at [3] is confirmed by the submitter to fix the build.
>
> please review
>
> /Andy
>
> [3] http://cr.openjdk.java.net/~herrick/8235767/webrev.02/
>
> On 12/11/2019 9:49 AM, Andy Herrick wrote:
>> Please review simple jpackage fix f
(adding core-libs-dev)
Ping?
> I just realized that this has still not been reviewed. Can I do anything
> to move forward?
>
> Thanks,
> Roman
>
>> I added one extra verification to the JAXP based properties parser to
>> verify that no extra internal DTD is being supplied. As far as I can
>> t
>> Any other comments on:
>> "* Runs the garbage collector in the Java Virtual Machine.
>> *
>> * Calling this method suggests that the Java Virtual Machine
>> * expend effort toward recycling unused objects in order to
>> * make the memory they currently occupy available for reuse
>> * by the
I have verified that the program that failed before doesn't appear to
fail anymore.
The patch looks good to me.
Thanks!
Roman
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8212178
>
> See the details in the bug. We are hitting this race when Shenandoah is
> running in aggressive mode
> a
Hi Christoph & Magnus, thanks for reviewing!
Am 27.09.18 um 08:22 schrieb Langer, Christoph:
> Hi Roman,
>
> this looks good to me. +1
>
> Best regards
> Christoph
>
>> -Original Message-
>> From: build-dev On Behalf Of
>> Roman Kennke
>&g
Ping core-libs?
Roman
Am 25.09.18 um 11:06 schrieb Magnus Ihse Bursie:
>
>> 25 sep. 2018 kl. 10:21 skrev Roman Kennke :
>>
>> Not sure this is the correct list. Please redirect as appropriate.
>
> I believe core-libs is the appropriate place. Cc:d.
>
>
d time to implement a fix.
**Roman
-Original Message-
From: Chris Hegarty [mailto:chris.hega...@oracle.com]
Sent: 22 December 2010 17:35
To: Roman Kennke
Cc: core-libs-dev@openjdk.java.net
Subject: Re: Potential memory leak in java.util.logging.Level
On 12/22/10 02:36 PM, Roman Kennke wrot
Hello,
I believe java.util.logging.Level is potentially memory leaking. This can
happen if an application defines its own subclass of Level and is loaded by its
own classloader. Level's constructor adds a reference to the new instance of
the subclass to its 'known' ArrayList (which is a static
Hi Mario,
> >> According to the specs, malloc may return either a valid pointer that
> >> can be passed to free, or NULL, while generally NULL is considered to be
> >> a failure. Linux and Solaris, albeit non specifying it, return always a
> >> valid pointer, as far as I know
> >
> > I think NULL
Hi Mario,
> According to the specs, malloc may return either a valid pointer that
> can be passed to free, or NULL, while generally NULL is considered to be
> a failure. Linux and Solaris, albeit non specifying it, return always a
> valid pointer, as far as I know
I think NULL is returned in a
like a reasonable fix for the get methods. Did you
> > check the toString, subSequence, and duplicate methods in case they have
> > the same problem?
I checked them (and added tests), and yes, they have the same problem.
Fixed in this revised patch.
--
Dipl.-Inform. (FH) Roman Kennke
Hi,
there are some classes in the jdk/share tree, that seem to be Solaris
specific. I suggest moving them to the jdk/solaris tree instead. Or am I
wrong here?
/Roman
--
http://kennke.org/blog/
# HG changeset patch
# User Roman Kennke <[EMAIL PROTECTED]>
# Date 1201293270 -3600
# N
Hi,
> Please observe:
>
> 1.
> the amount of memory needed to manage the allocation
> is greater than the number of bytes
> needed to store one additional character,
> so the relative impact on memory usage will not be dramatic.
This is just ridiculous. An average Java app has tons of Strin
Heyo,
> > The specification is buggy
> > > in that it does not take into account the operating system interface
> > > and makes correct memory management inefficient
> > > for the benefit of sparing one byte per buffer
> > > where an OS call is not needed.
> > > Ridiculous.
> >
> > Tom Tromey
Hi,
> The specification is buggy
> in that it does not take into account the operating system interface
> and makes correct memory management inefficient
> for the benefit of sparing one byte per buffer
> where an OS call is not needed.
> Ridiculous.
Tom Tromey pointed out another possible pro
Hi,
> The specification is buggy
> in that it does not take into account the operating system interface
> and makes correct memory management inefficient
> for the benefit of sparing one byte per buffer
> where an OS call is not needed.
> Ridiculous.
> The developers at Sun
> found the correct way
eturned array of Unicode characters is not required to be zero
> > terminated and that one should use GetStringLength to determine the length.
>
> Roman Kennke wrote:
>
> > So this is indeed a bug, right? Do you think it makes sense to go out and
> > fix it?
Hi Alan,
Am Montag, den 21.01.2008, 21:52 + schrieb Alan Bateman:
> Roman Kennke wrote:
> > Hi,
> >
> > I'm trying to understand a piece of code in java.io . Let me try to
> > explain:
> >
> > When you look into WinNTFileSystem.c in the method
>
otspot terminates strings with
a null internally?
3. Or this is a serious bug, that for some reason doesn't bomb all the
time. After all, it _does_ bomb in the JamaicaVM, where I'm trying to
port the code to...
Any ideas? I'd be happy to get an explanation for this problem.
Cheers, Ro
://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6400189
The attached changeset fixes the problem. Could this be included?
/Roman
--
Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Straße 18 * D-76131
Hi there,
> Currently, there exist much better solutions than BigDecimal,
> unfortunately not from the Java space. For instance GMP
> ( http://gmplib.org/) is considered as one of the state of the art
> libraries in the area of precision arithmetics. And several libraries
> extent GMP such as th
Hi there,
Why not implement such a thing as a separate library/class. After all,
Map is an interface which can be implemented in many ways and for many
different purposes. I think there are a couple of efforts that go in
this direction, for example javolution:
http://javolution.org/
Cheers, Roma
with this one
and take them step by step. :-)
/Roman
--
Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Straße 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com * Tel: +49-721-663 968-0
USt-Id: DE216
l-Nachricht-Anlage ([PATCH] Load currency.data via
> ClassLoader.eml)
> > Weitergeleitete Nachricht ----
> > Von: Roman Kennke <[EMAIL PROTECTED]>
> > An: Core-Libs-Dev
> > Betreff: [PATCH] Load currency.data via ClassLoader
> > Datum:
suggest
to fall back to loading this file via the ClassLoader. See attached
patch. This should affect normal behaviour, and only adds the option to
put this file in the (boot) classpath instead. What do you think?
/Roman
--
Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke
ay for heap buffers. Now it is
> used as the offset into the char sequence in the wrapped case. We should
> probably comment that for the sake of future maintainers or else add a
> new strOffset field to StringCharBuffer to make it easier to understand.
I'd reuse the existing f
Hi there
> > This fixes a problem with sliced StringCharBuffers. See:
> >
> > http://bugs.sun.com/view_bug.do?bug_id=6546113
> >
> > Feel free to integrate this in the repository.
Ping, any opinions on this?
/Roman
--
http://kennke.org/blog/
Hi list,
The PlainSocketImpl family of classes have a method socketGetOption1(),
which is required by the AbstractPlainSocketImpl class, and implemented
by the subclasses, but apparently never used. There isn't even a native
implementation for the native method in PlainSocketImpl. Could this
metho
I definitely need this new Evolution thingy. Forgot the actual
attachement..
Am Donnerstag, den 27.09.2007, 20:50 +0200 schrieb Roman Kennke:
> This fixes a problem with sliced StringCharBuffers. See:
>
> http://bugs.sun.com/view_bug.do?bug_id=6546113
>
> Feel free to integr
This fixes a problem with sliced StringCharBuffers. See:
http://bugs.sun.com/view_bug.do?bug_id=6546113
Feel free to integrate this in the repository.
Cheers, Roman
--
http://kennke.org/blog/
Hi Paulo,
Am Samstag, den 14.07.2007, 18:52 +0100 schrieb Paulo Levi:
> I'd like to ask if it would be possible to modify the classes of some
> primitive immutable types for returning immutable read only views.
> For example for strings, when using the document hierarchy, any
> insertString in the
93 matches
Mail list logo
