On Tue, 24 May 2022 09:26:44 GMT, Maurizio Cimadamore
wrote:
> This patch tweaks the foreign API to use the newly added
> `WrongThreadException` instead of `IllegalStateException` to report
> confinement errors.
I changed the PR on our side, `IllegalStateException` is fine, if you catch it
On Tue, 24 May 2022 09:26:44 GMT, Maurizio Cimadamore
wrote:
> This patch tweaks the foreign API to use the newly added
> `WrongThreadException` instead of `IllegalStateException` to report
> confinement errors.
Thinking more about it: `IllegalStateException` is fine for a closed
On Tue, 24 May 2022 09:26:44 GMT, Maurizio Cimadamore
wrote:
> This patch tweaks the foreign API to use the newly added
> `WrongThreadException` instead of `IllegalStateException` to report
> confinement errors.
I have seen this PR now: Would it be also a good idea to replace the
On Fri, 13 May 2022 09:42:44 GMT, Maurizio Cimadamore
wrote:
>> This change here also closes
>> [JDK-8259034](https://bugs.openjdk.java.net/browse/JDK-8259034)
>
> @uschindler - the issue you mention with respect lack of UOE for wrong file
> system applies to BB as well. I suggest filing an
On Fri, 13 May 2022 11:59:12 GMT, Maurizio Cimadamore
wrote:
>> RFE = issue?
>
>> RFE = issue?
>
> issue, with type RFE (request for enhancement)
See: https://bugs.openjdk.java.net/browse/JDK-8286734
-
PR: https://git.openjdk.java.net/jdk/pull/7888
On Fri, 13 May 2022 09:43:55 GMT, Maurizio Cimadamore
wrote:
>> src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 1164:
>>
>>> 1162: }
>>> 1163: if (unmapper != null) {
>>> 1164: AbstractMemorySegmentImpl segment = new
>>>
On Thu, 12 May 2022 15:45:01 GMT, Maurizio Cimadamore
wrote:
>> This PR contains the API and implementation changes for JEP-424 [1]. A more
>> detailed description of such changes, to avoid repetitions during the review
>> process, is included as a separate comment.
>>
>> [1] -
On Fri, 13 May 2022 08:25:01 GMT, Uwe Schindler wrote:
>> Maurizio Cimadamore has updated the pull request with a new target base due
>> to a merge or a rebase. The pull request now contains 65 commits:
>>
>> - Merge branch 'master' into foreign-preview
&g
On Wed, 11 May 2022 20:04:39 GMT, Naoto Sato wrote:
>> This is to extend the `Custom ID`s in `java.util.TimeZone` class to support
>> second-level resolution, enabling round trips with `java.time.ZoneOffset`s.
>> Corresponding CSR is also being drafted.
>
> Naoto Sato has updated the pull
On Wed, 11 May 2022 08:32:48 GMT, Uwe Schindler wrote:
>> Can the test cover `UT` prefix as well? (This is another valid prefix in
>> `ZoneId`)
>>
>> If this PR isn't meant to work with UTC prefix, can a test be added that
>> proves it does *not* work.
On Wed, 11 May 2022 08:10:56 GMT, Stephen Colebourne
wrote:
>> Added them except "UTC+...", as it is not recognizable as a Custom ID.
>
> Can the test cover `UT` prefix as well? (This is another valid prefix in
> `ZoneId`)
>
> If this PR isn't meant to work with UTC prefix, can a test be
On Tue, 10 May 2022 17:43:24 GMT, Naoto Sato wrote:
>> src/java.base/share/classes/java/util/TimeZone.java line 543:
>>
>>> 541: return new ZoneInfo(totalSecs == 0 ? "UTC" : GMT_ID +
>>> tzid, totalSecs);
>>> 542: } else {
>>> 543: return getTimeZone(tzid,
On Mon, 9 May 2022 18:59:43 GMT, Naoto Sato wrote:
> This is to extend the `Custom ID`s in `java.util.TimeZone` class to support
> second-level resolution, enabling round trips with `java.time.ZoneOffset`s.
> Corresponding CSR is also being drafted.
Marked as reviewed by uschindler (Author).
On Thu, 28 Apr 2022 20:02:36 GMT, Brian Burkhalter wrote:
>> Modify native multi-byte read-write code used by the `java.io` classes to
>> limit the size of the allocated native buffer thereby decreasing off-heap
>> memory footprint and increasing throughput.
>
> Brian Burkhalter has updated
On Tue, 30 Nov 2021 14:52:37 GMT, Alan Bateman wrote:
> Thread.stop is inherently unsafe and has been deprecated since Java 1.2
> (1998). It's time to terminally deprecate this method so it can be degraded
> and removed in the future.
>
> This PR does not propose any changes to the JVM TI
On Thu, 8 Jul 2021 01:05:16 GMT, Brian Burkhalter wrote:
>> Please consider this change to make the `float` and `double` versions of
>> `java.lang.Math.abs()` branch-free.
>
> Brian Burkhalter has updated the pull request incrementally with one
> additional commit since the last revision:
>
>
On a quick review of version 2, I noticed that the double constant is declared
as integer with same value like the float one.
I think that's wrong, but I wonder why the asserts still pass.
Uwe
Am July 8, 2021 1:05:16 AM UTC schrieb Brian Burkhalter :
>> Please consider this change to make the
On Tue, 27 Apr 2021 10:50:51 GMT, Jim Laskey wrote:
>> Move makeXXXSpilterator from public (@hidden) to protected. No API ch
>
> Jim Laskey has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Remove unnecessary constructor.
Marked as reviewed
On Wed, 21 Apr 2021 13:13:16 GMT, Jim Laskey wrote:
>> Move makeXXXSpilterator from public (@hidden) to protected. No API ch
>
> Jim Laskey has updated the pull request with a new target base due to a merge
> or a rebase. The incremental webrev excludes the unrelated changes brought in
> by
On Thu, 15 Apr 2021 12:37:52 GMT, Jim Laskey wrote:
>> Move makeXXXSpilterator from public (@hidden) to protected. No API ch
>
> Jim Laskey has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Remove extraneous references to makeXXXSpliterator
On Thu, 15 Apr 2021 12:01:07 GMT, Jim Laskey wrote:
>> Move makeXXXSpilterator from public (@hidden) to protected. No API ch
>
> Jim Laskey has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Move makeXXXSpliterator methods to RandomSupport
On Wed, 14 Apr 2021 12:27:55 GMT, Jim Laskey wrote:
>> Move makeXXXSpilterator from public (@hidden) to protected. No API ch
>
> Jim Laskey has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Make makeXXXSpliterator final
To me this looks
On Tue, 13 Apr 2021 16:33:21 GMT, Jim Laskey wrote:
> Move makeXXXSpilterator from public (@hidden) to protected. No API ch
This looks exactly like my proposed solution!
+1 Thanks!
Just my question: Is `@hidden` not needed to remove the documentation from
protected method? Or is this
On Wed, 6 Jan 2021 16:32:17 GMT, Maurizio Cimadamore
wrote:
>> This patch tweaks `MemorySegment::mapFile` so that it will throw
>> `IllegalArgumentException` whenever the path to be mapped is associated with
>> a custom file system provider.
>>
>> The check in the implementation is heavily
On Tue, 5 Jan 2021 15:33:54 GMT, Maurizio Cimadamore
wrote:
> Hi,
> this patch fixes an oversight where the address() method in
> FileChannelImpl.Unmapper does not take into account the value of
> `pagePosition` - this leads to a situation in which, effectively, the
> specified offset when
On Tue, 5 Jan 2021 15:55:10 GMT, Uwe Schindler wrote:
>> test/jdk/java/foreign/TestByteBuffer.java line 28:
>>
>>> 26: * @modules java.base/sun.nio.ch
>>> 27: * jdk.incubator.foreign/jdk.internal.foreign
>>> 28: * @run testng/othervm --illegal-
On Tue, 5 Jan 2021 16:01:11 GMT, Uwe Schindler wrote:
>> I am not sure if a test like this is really needed.
>> The alignment is pageSize on Linux and some arbitrary value (65536) on
>> Windows. If you have some test file that writes like a few bytes (1, 2, 3,
>> 4,...)
On Tue, 5 Jan 2021 15:44:50 GMT, Alan Bateman wrote:
>> Hi,
>> this patch fixes an oversight where the address() method in
>> FileChannelImpl.Unmapper does not take into account the value of
>> `pagePosition` - this leads to a situation in which, effectively, the
>> specified offset when
On Tue, 5 Jan 2021 15:42:11 GMT, Maurizio Cimadamore
wrote:
>> When the size of the memory map is zero, FileChannelImpl returns a `null`
>> Unmapper - this creates issues to the mapped memory segment implementation.
>>
>> To fix, I've created an empty mapped segment class which is initialized
On Sun, 20 Sep 2020 22:22:47 GMT, Lance Andersen wrote:
>> Hi all,
>>
>> Please review the fix for JDK-8252739 which addresses an issue introduced by
>> https://bugs.openjdk.java.net/browse/JDK-8225189, where Deflater.c ignored
>> the offset specified by
>> Deflater.setDictionary. Mach5
On Sun, 20 Sep 2020 20:38:59 GMT, Lance Andersen wrote:
>> The tests with byte buffers (direct and heap) are not using offsets
>> (arrayOffset=0). The direct buffer test uses just a
>> series of 0-bytes, so incorrect offsets won't change result. There should be
>> real data copied into the
Hi,
I left some comments on the PR.
The tests with ByteBuffers are not testing the bug correctly.
Uwe
Am September 20, 2020 6:14:59 PM UTC schrieb Lance Andersen
:
>Hi all,
>
>Please review the fix for JDK-8252739 which addresses an issue
>introduced by
On Sun, 20 Sep 2020 18:03:02 GMT, Lance Andersen wrote:
> Hi all,
>
> Please review the fix for JDK-8252739 which addresses an issue introduced by
> https://bugs.openjdk.java.net/browse/JDK-8225189, where Deflater.c ignored
> the offset specified by
> Deflater.setDictionary. Mach5 jdk-tier1,
> https://bugs.openjdk.java.net/browse/JDK-8212620
>
>This RFE should also take hidden classes into account.
>
>Mandy
>
>On 9/5/20 4:55 AM, Uwe Schindler wrote:
>> Hi,
>>
>> I am doing a mockup for dynamically compiled scripts in Apache Lucene
>(later
>> also painles
- Mail original -
>> De: "Uwe Schindler"
>> À: "core-libs-dev"
>> Envoyé: Samedi 5 Septembre 2020 13:55:03
>> Objet: JDK 15 hidden classes & stack trace visibility
>
>> Hi,
>>
>> I am doing a mockup for dynamically compiled scr
parameter of
defineHiddenClass), to also pass a flag to show them in stack traces?
Uwe
-
Uwe Schindler
uschind...@apache.org
ASF Member, Apache Lucene PMC / Committer
Bremen, Germany
https://lucene.apache.org/
Hi,
In general, I'd prefer to have a predicate that uses matches() instead of
find(). In my code I have never used find() because in most cases you want to
match the whole string anyways. Of course you can use ^ and $ but I don't like
that leniency. If I write code, I prefer to be explicit in
) and should not rely on external forces, but I wanted
> to bring this in.
> >
> There is no proposal to change these methods.
Thanks for clarifying! I just wanted to mention this, because those methods are
different, so you should at least think about it
Uwe
-
Uwe Schindler
Hi,
Thanks Alan for the link to this issue about FileReader/Writer!
Uwe
-
Uwe Schindler
uschind...@apache.org
ASF Member, Apache Lucene PMC / Committer
Bremen, Germany
http://lucene.apache.org/
> -Original Message-
> From: core-libs-dev [mailto:core-libs-de
//blog.thetaphi.de/2012/07/default-locales-default-charsets-and.html
[2] https://github.com/policeman-tools/forbidden-apis
[3] https://jenkins.thetaphi.de/job/Forbidden-APIs/javadoc/
-
Uwe Schindler
uschind...@apache.org
ASF Member, Apache Lucene PMC / Committer
Bremen, Germany
http://lucene.apache.org/
tools are seeing it and having problems with it.
>>
>> :
>>
>> Do you have any recommendations on how we can resolve this impasse?
>>
>The Android tools should ignore class files in META/**, at least until
>they are updated to work with multi-release JARs. Hav
, way cool:
https://github.com/uschindler/lucene-solr/blob/d67eb6274d4c0b8315848db3f09809fbc0797f6e/lucene/core/src/tools/groovy/patch-mrjar-classes.groovy
-
Uwe Schindler
uschind...@apache.org
ASF Member, Apache Lucene PMC / Committer
Bremen, Germany
http://lucene.apache.org/
ones snapshotted when the process started. Now in JDK
>9
>we cannot workaround anymore, which either just kills Gradle
>performance or
>forces us to write even nastier code with bytecode manipulating agents
>to
>replace what `System.getenv` does.
>
>2017-05-16 19:46 GMT+02:00 U
nother build running at a later
time is changing the Gradle process environment.
At some point you have to break backwards compatibility and tell users: Please
update your code, otherwise plugin won't work anymore with Gradle version x.y
(the one that's compatible to Java 9).
Uwe
-
U
Hi,
> >> I guess "difficulty in properly triggering GC for non-memory resource
> >> exhaustion" is closest to what I just described.
> >
> > This has long been an issue in the Java client area where native desktop
> > resources or the like need to be managed carefully, but it is not just
> >
Hi,
It's also inconsistent, because the same type of code works with MethodHandles.
If you make something accessible (and succeed doing this), it uses some special
internal lookup that has no restrictions for unreflect.
Uwe
Am 9. Januar 2017 19:43:44 MEZ schrieb Martin Buchholz
Hi,
sorry for the delay! I updated Lucene's build system to use the JFrog snapshort
artifacts and build succeeds with JDK 9 b148+:
That's the one that was choosen by Apache Ant's Ivy downloader:
groovy-all-2.4.8-20161220.101835-40.jar
So we are waiting for a release!
Uwe
-
Uwe Schindler
Hi,
will there be an update for JEP 260, so this is documented?
Uwe
-
Uwe Schindler
uschind...@apache.org
ASF Member, Apache Lucene PMC / Committer
Bremen, Germany
http://lucene.apache.org/
> -Original Message-
> From: Chris Hegarty [mailto:chris.hega...@oracle.com]
> Sen
Hi Chris,
thanks, works perfectly. I compiled a JDK with this commit and Lucene's
unmapping works. Thanks.
https://github.com/apache/lucene-solr/compare/LUCENE-6989-v2
Uwe
-
Uwe Schindler
uschind...@apache.org
ASF Member, Apache Lucene PMC / Committer
Bremen, Germany
http
, but this is not allowed if we do a release of Lucene.
Uwe
-
Uwe Schindler
uschind...@apache.org
ASF Member, Apache Lucene PMC / Committer
Bremen, Germany
http://lucene.apache.org/
> -Original Message-
> From: Jochen Theodorou [mailto:blackd...@gmx.org]
> Sent: Saturday, December 1
ption: Unable to make public
jdk.internal.ref.Cleaner java.nio.DirectByteBuffer.cleaner() accessible: module
java.base does not "opens java.nio" to unnamed module @45c7ad7f
Don't care about the Groovy error printed later, this one is known, but does
not affect testing.
Uwe
-
Uwe Schindler
uschind...
penJDK, so if somebody could provide
me a patched build for windows or linux, I'd be happy.
Uwe
-
Uwe Schindler
uschind...@apache.org
ASF Member, Apache Lucene PMC / Committer
Bremen, Germany
http://lucene.apache.org/
> -Original Message-
> From: Chris Hegarty [mailto:chris.hega...@or
be in sun.misc.Unsafe – that’s also what most code is
using anyways.
Uwe
From: Peter Levart [mailto:peter.lev...@gmail.com]
Sent: Saturday, December 10, 2016 10:23 PM
To: Uwe Schindler <uschind...@apache.org>; Chris Hegarty
<chris.hega...@oracle.com>
Cc: jigsaw-...@open
Hi,
We noticed that buffers with zero length also have no cleaner. This is why we
also have the null check in our code (see Github) and the guardWithTest in the
MethodHandle, although we never free duplicates. So a noop is better imho.
I like the Unsafe approach. To me both variants are fine.
” to test this with Lucene before you commit something like this.
Uwe
-
Uwe Schindler
uschind...@apache.org
ASF Member, Apache Lucene PMC / Committer
Bremen, Germany
http://lucene.apache.org/
From: Peter Levart [mailto:peter.lev...@gmail.com]
Sent: Saturday, December 10, 2016 12
, the idea was proposed by Andrew Haley.
Uwe
-
Uwe Schindler
uschind...@apache.org
ASF Member, Apache Lucene PMC / Committer
Bremen, Germany
http://lucene.apache.org/
> -Original Message-
> From: Alan Bateman [mailto:alan.bate...@oracle.com]
> Sent: Saturday, December 10, 201
unmapping direct buffers works without command line
parameters that confuse people.
Uwe
-
Uwe Schindler
uschind...@apache.org
ASF Member, Apache Lucene PMC / Committer
Bremen, Germany
http://lucene.apache.org/
> -Original Message-
> From: Stephen Felts [mailto:stephen.fe...@oracl
Hi,
Of course, private field access is allowed to your own class if you use a
private lookup object. The setAccessible hack is only needed when reflection
would also be needed for frameworks or other "superusers".
Uwe
Am 8. Dezember 2016 22:10:32 MEZ schrieb Uwe Schindle
uld be too slow and
>would
>>> require data representation as a list of objects, rather than a
>continuous
>>> buffer (much less compact and cache-friendly). Security restrictions
>would
>>> be a concern as well. At first glance at Java 9, I don't see any
>>> facilities
>>> that would help here.
>>>
>>> This would seem to be a fairly common use case a low-level
>serialization
>>> framework, such as protobuf. Are there any thoughts on how such a
>use case
>>> could be supported post-Unsafe?
>>>
>>> Thanks,
>>> Nathan
>>>
>>
>>
--
Uwe Schindler
Achterdiek 19, 28357 Bremen
https://www.thetaphi.de
Path APIs. No need to change the
old-style java.io.File based APIs. This is easy to implement and add, because
you would only add the new Enum constant and then implement it in the default
FileSystem(-Provider) for each platform.
Uwe
-
Uwe Schindler
uschind...@apache.org
ASF Member, Apache
had no free bits anymore?
In forbiddenapis I took the route to allow any class below java.lang.invoke to
define polymorphic signatures. The new version is already out: 2.2
(https://github.com/policeman-tools/forbidden-apis/wiki/Changes)
Uwe
-
Uwe Schindler
uschind...@apache.org
ASF Member
lemented
purely the Java VM 8 spec, just extending the class name matcher to "everything
below java.lang.invoke", so it also works for VarHandles. But as said, this
does not look like "future-proof".
Uwe
-
Uwe Schindler
uschind...@apache.org
ASF Member,
+1
Let public Unsafe die (at least partially)! :-)
Uwe
-
Uwe Schindler
uschind...@apache.org
ASF Member, Apache Lucene PMC / Committer
Bremen, Germany
http://lucene.apache.org/
> -Original Message-
> From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On
&g
Hi,
I just noticed that there is the @since missing in javadocs:
http://hg.openjdk.java.net/jdk9/dev/jdk/rev/fd39cefc5c8f#l3.13
arrayConstructor has @since 9, but arrayLength() not.
Uwe
-
Uwe Schindler
uschind...@apache.org
ASF Member, Apache Lucene PMC / Committer
Bremen, Germany
http
Hi,
> > P.S.: I am not so familiar with the intrinsic stuff, so here is my
> > question: The
> intrinsic for the array accesses is always created before caching the MH; so
> why do we need the static implementation methods at all? I had the same
> question also about the old element getters and
ation"? If the
latter is the case, the test should ensure that the intrinsics are tested, too.
-
Uwe Schindler
uschind...@apache.org
ASF Member, Apache Lucene PMC / Committer
Bremen, Germany
http://lucene.apache.org/
> -Original Message-
> From: core-libs-dev [mailto:co
Hi,
I noticed the same when skimming through the patch! I'd change this, too.
Uwe
-
Uwe Schindler
uschind...@apache.org
ASF Member, Apache Lucene PMC / Committer
Bremen, Germany
http://lucene.apache.org/
> -Original Message-
> From: core-libs-dev [mailto:core-libs-de
Hi,
One addition, maybe add to issue:
If this was added, jdk.dynalink module could use it, too - this was mentioned
by Attila already:
http://hg.openjdk.java.net/jdk9/dev/nashorn/file/4b118e012ac4/src/jdk.dynalink/share/classes/jdk/dynalink/beans/BeanLinker.java
Uwe
-
Uwe Schindler
Hi,
OK, thanks for creating an issue!
Uwe
-
Uwe Schindler
uschind...@apache.org
ASF Member, Apache Lucene PMC / Committer
Bremen, Germany
http://lucene.apache.org/
> -Original Message-
> From: Remi Forax [mailto:fo...@univ-mlv.fr]
> Sent: Friday, May 13, 2016 10:37 AM
Hi Michael,
> > Am 11.05.2016 um 21:35 schrieb Uwe Schindler <uschind...@apache.org>:
> > With Java 9 this gets a bit worse: There is no "easy way" with the
> MethodHanldes class to generate a MethodHandles.countedLoop() on all
> elements of an array:
-
Uwe Schindler
uschind...@apache.org
ASF Member, Apache Lucene PMC / Committer
Bremen, Germany
http://lucene.apache.org/
From: Attila Szegedi [mailto:szege...@gmail.com]
Sent: Thursday, May 12, 2016 11:37 AM
To: Uwe Schindler <uschind...@apache.org>
Cc: Core-Libs-Dev <core
Hi Remi,
> > while working and trying the new JDK9 MethodHandles features like
> > MethodHandles#countedLoop, I recognized a API inconsistency problem
> with it.
> >
> > We also found this while implementing the "Painless" scripting language for
> > Elasticsearch (see https://goo.gl/DbOzjC)!
Accessor(Object[].class, false), Intrinsic.ARRAY_LOAD);
[with another intrinsic added: Intrinsic.ARRAY_LENGTH for the arraylength
bytecode]
What would be the process to propose such a change? Bug/Issue/JEP?
I could quickly create a patch, but fixing the Intrinsic/LambdaForm stuff is
way too complic
Hi Alan,
I can confirm, the problem is fixed in build 113. Thanks!
Uwe
-
Uwe Schindler
uschind...@apache.org
ASF Member, Apache Lucene PMC / Committer
Bremen, Germany
http://lucene.apache.org/
From: Alan Bateman [mailto:alan.bate...@oracle.com]
Sent: Sunday, March 27
can also look at class
names like I did for the BreakIterators.
I wish you happy Easter!
Uwe
-
Uwe Schindler
uschind...@apache.org
ASF Member, Apache Lucene PMC / Committer
Bremen, Germany
http://lucene.apache.org/
From: Alan Bateman [mailto:alan.bate...@oracle.com]
Sent
nt a stack trace? It is just
silent!
Uwe
-
Uwe Schindler
uschind...@apache.org
ASF Member, Apache Lucene PMC / Committer
Bremen, Germany
http://lucene.apache.org/
> -Original Message-
> From: Alan Bateman [mailto:alan.bate...@oracle.com]
> Sent: Saturday
lator, not the one for Arabic/Farsi text.
So it looks like the initialization code for locales misses to do some
doPrivileged() somewhere. Maybe that one was lost during the merge.
Uwe
-
Uwe Schindler
uschind...@apache.org
ASF Member, Apache Lucene PMC / Committer
Bremen, Germany
htt
rked before (in any previous Java 9 build
and any previous Java version 1.4+).
I have to revert to build 110, because we cannot make our tests pass on the
Jenkins server. I hope this can be fixed with the next build!
Uwe
-
Uwe Schindler
uschind...@apache.org
ASF Member, Apache Lucene PMC /
with
neither build 110 of Jigsaw and without.
Here are 2 failures:
http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/253/consoleFull
http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/16339/consoleFull
Uwe
-
Uwe Schindler
uschind...@apache.org
ASF Member, Apache Lucene PMC
Sorry,
false alarm! I missed to change the build number when changing EA build paths
on the Jenkins server. There was still "b110" in it. :(
Sorry for noise, all fine.
Uwe
-
Uwe Schindler
uschind...@apache.org
ASF Member, Apache Lucene PMC / Committer
Bremen, Ge
://bugs.openjdk.java.net/browse/JDK-8152161
Is there a quick way via command line flag to disable the extra beans which are
not found? I'd really like to test build 111.
Uwe
-
Uwe Schindler
uschind...@apache.org
ASF Member, Apache Lucene PMC / Committer
Bremen, Germany
http://lucene.apache.org/
> -Origi
Hi,
Unfortunately we found a bug in build 110 - not as bad as the Ant one, but the
Gradle build system does no longer start! :(
The following fails:
C:\Users\Uwe Schindler\workspace-lucene\tester\src>cat Test.java
import java.lang.management.ManagementFactory;
imp
Hi,
In fact, any static method on ManagementFactory fails with this trace. You
cannot get any bean, not even runtime bean!
Uwe
-
Uwe Schindler
uschind...@apache.org
ASF Member, Apache Lucene PMC / Committer
Bremen, Germany
http://lucene.apache.org/
> -Original Message-
>
Hi,
I opened JI-9032467.
Uwe
-
Uwe Schindler
uschind...@apache.org
ASF Member, Apache Lucene PMC / Committer
Bremen, Germany
http://lucene.apache.org/
> -Original Message-
> From: Rory O'Donnell [mailto:rory.odonn...@oracle.com]
> Sent: Thursday, March 17, 2016 10:55 PM
Hi,
JDK-9 build 109 works, build 110 does not work. This is *not* about Jigsaw,
just the standard JDK build.
I have the feeling this is just a packaging bug. The META-INF/services file in
question contains a class that is missing in the jimage.
Uwe
-
Uwe Schindler
uschind...@apache.org
Hi Rory,
thanks for the pointer. I installed it on our Jenkins server. Will report back.
My local tests showed that the MethodHandle-bug is solved, the other one is
hopefully fixed, too. Robert may have a way to quickly reproduce.
Uwe
-
Uwe Schindler
uschind...@apache.org
ASF Member
/HotSpotDiagnosticMXBean.html
And this is *not* Jigsaw. Was just standard build. But works with Jigsaw, build
109, too!
-
Uwe Schindler
uschind...@apache.org
ASF Member, Apache Lucene PMC / Committer
Bremen, Germany
http://lucene.apache.org/
> -Original Message-
> From: Remi Forax [mailto:fo..
Hi Alan,
sorry I already opened JI-9032467 in the bug tracker.
What change caused this? All previous builds had all the mbeans, just build 110
does not have them anymore.
Uwe
-
Uwe Schindler
uschind...@apache.org
ASF Member, Apache Lucene PMC / Committer
Bremen, Germany
http
s unusable because of the Ant build problems) and I
was quite sure that they will be in build 109. Those 2 issues still make the
test suite fail quite often (hotspot issues). On the issues the "resolved in"
field contains "team". What does this mean?
Uwe
-
Uwe Schindler
usc
resources in same JAR file by href)
Keep me informed when build 109 is downloadable.
Uwe
-
Uwe Schindler
uschind...@apache.org
ASF Member, Apache Lucene PMC / Committer
Bremen, Germany
http://lucene.apache.org/
> -Original Message-
> From: core-libs-dev [mailto:core-libs-de
constructs the JAR file URL on its own (it
> looks like this), but does not add the #release fragment. And because of this,
> JarURLConnection does not find the file...:
>
> [...] multiple parent causes [...]
> Caused by: java.io.FileNotFoundException: JAR entry
> org/apache/ivy/core/se
Hi Stefan,
> -Original Message-
> From: Stefan Bodewig [mailto:bode...@apache.org]
> Sent: Saturday, March 05, 2016 7:56 PM
> To: d...@ant.apache.org; Uwe Schindler <uschind...@apache.org>
> Cc: 'Alan Bateman' <alan.bate...@oracle.com>; core-libs-
> d..
Thanks Alan,
I am glad that the appending of "#resource" is indeed a bug.
> > I'd suggest to please ASAP revert the Multi-Release JAR file patch and
> provide a new preview build as soon as possible. I think there is more work
> needed to fix this. If this does not revert to the original state,
Hi Claes,
is there a way to just build a new runtime library without compiling a full JDK
(including Hotspot). So just replacing the jimage files locally?
Uwe
-
Uwe Schindler
uschind...@apache.org
ASF Member, Apache Lucene PMC / Committer
Bremen, Germany
http
and this is not a good sign, especially as
Jigsaw will be merged soon.
Thanks for listening,
Uwe
P.S.: I also CCed the Apache Ant team. They should fix the broken code anyways,
but this won't help for many projects already out there (e.g. Apache Lucene
still has a minimum requirement of Ant 1.8.2 bec
tp.getClassName(), false, null);
return true;
} catch (ClassNotFoundException e) {
return false;
}
}
-
Uwe Schindler
uschind...@apache.org
ASF Member, Apache Lucene PMC / Committer
Bremen, Germany
http://lucene.apache.org/
> -Original Message-
> F
hanks,
Uwe
-
Uwe Schindler
uschind...@apache.org
ASF Member, Apache Lucene PMC / Committer
Bremen, Germany
http://lucene.apache.org/
> -Original Message-
> From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On
> Behalf Of shilpi.rast...@oracle.com
> Sent:
Hi,
> On 15/02/2016 14:57, Chris Hegarty wrote:
> > Peter,
> >
> > >
> > http://cr.openjdk.java.net/~plevart/jdk9-
> dev/removeInternalCleaner/webrev.02/
> >
> > Given the changes in 6857566, I think your proposal to remove
> > jdk.internal.ref.Cleaner should be good. ( Note: third party
when we implement the changed Hack. BTW, we already have a preliminary
patch for Lucene (untested):
https://issues.apache.org/jira/secure/attachment/12784516/LUCENE-6989.patch
Thanks for taking care of this issue.
Uwe
-
Uwe Schindler
uschind...@apache.org
ASF Member, Apache Lucene PMC /
to invoke that method.
In my opinion, you should add some other runtime permission for safety, which
is checked on calling the run() method. This would make it safe, because as
soon as you have SecurityManager you would need to give explicit permission to
the code.
Uwe
-
Uwe Schindl
1 - 100 of 113 matches
Mail list logo
