Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8259028

ClassCastException when using custom filesystem with wrapper FileChannel impl



    • Bug
    • Status: Resolved
    • P3
    • Resolution: Fixed
    • 16
    • 16
    • core-libs
    • openjdk version "16-ea" 2021-03-16
      OpenJDK Runtime Environment (build 16-ea+30-2130)
      OpenJDK 64-Bit Server VM (build 16-ea+30-2130, mixed mode, sharing)

    • b32
    • generic
    • generic



        Apache Lucene uses during its test suite some special file system wrappers to emulate some specific behaviour:
        - Windows behaviour (can't delete files when open,..)
        - Disable fsync to make the Lucene developer's SSD survive longer
        - track open file handles

        Unfortunetely while implementing a replacement for MappedByteBuffer usage in MMapDirectory using project Panama's MemorySegments, we discovered, that the following happens, if you try to mmap a file from a file system that returns a custom FileChannel implementation (although it only wraps everything from its public API):

        org.apache.lucene.store.TestMultiMMap > testFileExistsInListAfterCreated FAILED
            java.lang.ClassCastException: class org.apache.lucene.mockfile.HandleTrackingFS$3 cannot be cast to class sun.nio.ch.FileChannelImpl (org.apache.lucene.mockfile.HandleTrackingFS$3 is in unnamed module of loader 'app'; sun.nio.ch.FileChannelImpl is in module java.base of loader 'bootstrap')
                at __randomizedtesting.SeedInfo.seed([32623CC06FD28A36:98BBD11AF9EC8385]:0)
                at jdk.incubator.foreign/jdk.internal.foreign.MappedMemorySegmentImpl.makeMappedSegment(MappedMemorySegmentImpl.java:117)
                at jdk.incubator.foreign/jdk.incubator.foreign.MemorySegment.mapFile(MemorySegment.java:890)
                at org.apache.lucene.store.MMapDirectory.map(MMapDirectory.java:256)
                at org.apache.lucene.store.MMapDirectory.openInput(MMapDirectory.java:227)

        There should be a way to do the same without casting the file channel to some internal implementation class, because this makes wrapping impossible.

        Before Panama goes into JDK's core this must really be solved:
        Add the missing hooks for mapping files to memory segments to the public FileSystem API / FileChannel interface!

        IMHO, the code should be moved to the public FileChannel API, maybe using a default implementation in FileChannel interface that by default only throws UOE. Only FileChannelImpl implements the Mapping/Unmapper code, but this would avoid the ClassCastException and it would be possible for implementors of Custom FileSystems to implement the behavious or delegate to the FileChannel behind.


          Issue Links



                mcimadamore Maurizio Cimadamore
                uschindler Uwe Schindler
                0 Vote for this issue
                5 Start watching this issue