geotools-gt2-users — Help and support for GeoTools users

Re: [Geotools-gt2-users] WKT to EPSG-code: cannot make CRS.lookupEpsgCode() to detect epsg:4647

[Viatcheslav S. <Via...@h-...>]

Hi,

Sorry if I expressed myself wrong: my data is actually in epsg:4647 and, since I am using FORCE_LONGITUDE_FIRST_AXIS_ORDER=false, it would be wrong to load the data in epsg:5652.

Now, since this specific WKT does not contain any information about proper axis order, from perspective of geotools epsg:5652 is probably a correct answer. I prefer though Geotools would not deliver just a first matching candidate but a set of possible matches; for an application or ultimately an user to choose the correct one from the set. Further I'd prefer CRS.lookupIdentifier() would not enforce FORCE_LONGITUDE_FIRST_AXIS_ORDER=true for this search​ 😕. Or, I now begin to wonder, is there a reason to?

The second issue, even if I copy/paste CRS class to my module and change the FORCE_LONGITUDE_FIRST_AXIS_ORDER flag to false, I still do not get 4647 as an answer.  I debugged it and found out, 4647 is discarded in IdentifiedObjectFinder#createFromCodes() / IdentifiedObjectFinder#deriveEquivalent() because its "baseCRS" ("EPSG:ETRS89") defines northing-easting axis to be default and so does not match "exactly (ignoring metadata)" "baseCRS" of the CRS constructed from WKT. This might be a bug, the axis order of "baseCRS" should not matter, since it is overridden in actual CRS anyway (always? I dont know).

With best regards, Slava
________________________________
Von: Ian Turton <ijt...@gm...>
Gesendet: Samstag, 24. Januar 2026 13:04
An: Viatcheslav Sysoltsev <Via...@h-...>
Cc: geo...@li... <geo...@li...>
Betreff: Re: [Geotools-gt2-users] WKT to EPSG-code: cannot make CRS.lookupEpsgCode() to detect epsg:4647

Your data is stored in epsg:5652 - while you could alter the metadata to make it appear to be stored in epsg:4647 it would end up in the wrong place (and flipped through 90 degrees) - what you need to do is reproject it to epsg:4647. The easiest way to do this is to use a ReprojectingFeatureCollection using something like this


public static void main(String[] args) throws IOException, NoSuchAuthorityCodeException, FactoryException {
     if(args.length==0) {
       System.err.println("usage: Reprojector shapefile.shp");
       System.exit(1);
     }
     FileDataStore ds = FileDataStoreFinder.getDataStore(new File(args[0]));
     SimpleFeatureCollection features = ds.getFeatureSource().getFeatures();
     try(SimpleFeatureIterator itr=features.features()){
       int count=0;
       while(itr.hasNext()&&count++<10) {
         System.out.println(((Geometry) itr.next().getDefaultGeometry()).getCentroid());
       }
     }
     System.out.println("");
     ReprojectingFeatureCollection rfc = new ReprojectingFeatureCollection(features, CRS.decode("epsg:3875"));
     try(SimpleFeatureIterator itr=rfc.features()){
       int count=0;
       while(itr.hasNext()&&count++<10) {
         System.out.println(((Geometry) itr.next().getDefaultGeometry()).getCentroid());
       }
     }
  }


Ian


On Fri, 23 Jan 2026 at 16:36, Viatcheslav Sysoltsev <Via...@h-...<mailto:Via...@h-...>> wrote:
Hi,

Hope someone can help me... I did get a shapefile, I believe produced by QGIS, with .prj file:

PROJCS["ETRS_1989_UTM_Zone_N32",
    GEOGCS["GCS_ETRS_1989",
       DATUM["D_ETRS_1989",
          SPHEROID["GRS_1980",6378137.0,298.257222101]
       ],
       PRIMEM["Greenwich",0.0],
       UNIT["Degree",0.0174532925199433]
    ],
    PROJECTION["Transverse_Mercator"],
    PARAMETER["False_Easting",32500000.0],
    PARAMETER["False_Northing",0.0],
    PARAMETER["Central_Meridian",9.0],
    PARAMETER["Scale_Factor",0.9996],
    PARAMETER["Latitude_Of_Origin",0.0],
    UNIT["Meter",1.0]
]

If I feed this WKT to the code:

CoordinateReferenceSystem crs = CRS.parseWKT(wkt);
Integer lookupResult = CRS.lookupEpsgCode(crs, true);

.. I do get number 5652, which is correct, but has northing-easting axis order (https://epsg.io/5652). I'd rather prefer 4647, which is the same, but with easting-northing. Is there a way to get it? I'm using gt-epsg-hsql plugin, here is the gradle classpath:

implementation 'org.geotools:gt-api'
implementation 'org.geotools:gt-referencing'
implementation 'org.geotools:gt-main'
implementation 'org.geotools:gt-epsg-hsql'
implementation 'org.geotools:gt-coverage'

Geotools version is 34.1.

// Strange thing, if I copy-paste Implementation of CRS class and set FORCE_LONGITUDE_FIRST_AXIS_ORDER to false, I still don't get 4647, but null. Might it be a bug, maybe 4647 is not in the hsql database?

With best regards, Slava



_______________________________________________
GeoTools-GT2-Users mailing list
Geo...@li...<mailto:Geo...@li...>
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users


--
Ian Turton

Re: [Geotools-gt2-users] WKT to EPSG-code: cannot make CRS.lookupEpsgCode() to detect epsg:4647

[Ian T. <ijt...@gm...>]

Your data is stored in epsg:5652 - while you could alter the metadata to
make it appear to be stored in epsg:4647 it would end up in the wrong place
(and flipped through 90 degrees) - what you need to do is reproject it to
epsg:4647. The easiest way to do this is to use
a ReprojectingFeatureCollection using something like this

public static void main(String[] args) throws IOException,
NoSuchAuthorityCodeException, FactoryException {
     if(args.length==0) {
       System.err.println("usage: Reprojector shapefile.shp");
       System.exit(1);
     }
     FileDataStore ds = FileDataStoreFinder.getDataStore(new File(args[0]));
     SimpleFeatureCollection features = ds.getFeatureSource().getFeatures();
     try(SimpleFeatureIterator itr=features.features()){
       int count=0;
       while(itr.hasNext()&&count++<10) {
         System.out.println(((Geometry)
itr.next().getDefaultGeometry()).getCentroid());
       }
     }
     System.out.println("");
     ReprojectingFeatureCollection rfc = new
ReprojectingFeatureCollection(features, CRS.decode("epsg:3875"));
     try(SimpleFeatureIterator itr=rfc.features()){
       int count=0;
       while(itr.hasNext()&&count++<10) {
         System.out.println(((Geometry)
itr.next().getDefaultGeometry()).getCentroid());
       }
     }
  }

Ian



On Fri, 23 Jan 2026 at 16:36, Viatcheslav Sysoltsev <
Via...@h-...> wrote:

> Hi,
>
> Hope someone can help me... I did get a shapefile, I believe produced by
> QGIS, with .prj file:
>
> PROJCS["ETRS_1989_UTM_Zone_N32",
>     GEOGCS["GCS_ETRS_1989",
>        DATUM["D_ETRS_1989",
>           SPHEROID["GRS_1980",6378137.0,298.257222101]
>        ],
>        PRIMEM["Greenwich",0.0],
>        UNIT["Degree",0.0174532925199433]
>     ],
>     PROJECTION["Transverse_Mercator"],
>     PARAMETER["False_Easting",32500000.0],
>     PARAMETER["False_Northing",0.0],
>     PARAMETER["Central_Meridian",9.0],
>     PARAMETER["Scale_Factor",0.9996],
>     PARAMETER["Latitude_Of_Origin",0.0],
>     UNIT["Meter",1.0]
> ]
>
>
> If I feed this WKT to the code:
>
> CoordinateReferenceSystem crs = CRS.*parseWKT*(wkt);
> Integer lookupResult = CRS.*lookupEpsgCode*(crs, true);
>
> .. I do get number 5652, which is correct, but has northing-easting axis
> order (https://epsg.io/5652). I'd rather prefer 4647, which is the same,
> but with easting-northing. Is there a way to get it? I'm using gt-epsg-hsql
> plugin, here is the gradle classpath:
>
> implementation 'org.geotools:gt-api'
> implementation 'org.geotools:gt-referencing'
> implementation 'org.geotools:gt-main'
> implementation 'org.geotools:gt-epsg-hsql'
> implementation 'org.geotools:gt-coverage'
>
> Geotools version is 34.1.
>
> // Strange thing, if I copy-paste Implementation of CRS class and set
> FORCE_LONGITUDE_FIRST_AXIS_ORDER to false, I still don't get 4647, but
> null. Might it be a bug, maybe 4647 is not in the hsql database?
>
> With best regards, Slava
>
>
>
> _______________________________________________
> GeoTools-GT2-Users mailing list
> Geo...@li...
> https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
>


-- 
Ian Turton

[Geotools-gt2-users] WKT to EPSG-code: cannot make CRS.lookupEpsgCode() to detect epsg:4647

[Viatcheslav S. <Via...@h-...>]

Hi,

Hope someone can help me... I did get a shapefile, I believe produced by QGIS, with .prj file:

PROJCS["ETRS_1989_UTM_Zone_N32",
    GEOGCS["GCS_ETRS_1989",
       DATUM["D_ETRS_1989",
          SPHEROID["GRS_1980",6378137.0,298.257222101]
       ],
       PRIMEM["Greenwich",0.0],
       UNIT["Degree",0.0174532925199433]
    ],
    PROJECTION["Transverse_Mercator"],
    PARAMETER["False_Easting",32500000.0],
    PARAMETER["False_Northing",0.0],
    PARAMETER["Central_Meridian",9.0],
    PARAMETER["Scale_Factor",0.9996],
    PARAMETER["Latitude_Of_Origin",0.0],
    UNIT["Meter",1.0]
]

If I feed this WKT to the code:

CoordinateReferenceSystem crs = CRS.parseWKT(wkt);
Integer lookupResult = CRS.lookupEpsgCode(crs, true);

.. I do get number 5652, which is correct, but has northing-easting axis order (https://epsg.io/5652). I'd rather prefer 4647, which is the same, but with easting-northing. Is there a way to get it? I'm using gt-epsg-hsql plugin, here is the gradle classpath:

implementation 'org.geotools:gt-api'
implementation 'org.geotools:gt-referencing'
implementation 'org.geotools:gt-main'
implementation 'org.geotools:gt-epsg-hsql'
implementation 'org.geotools:gt-coverage'

Geotools version is 34.1.

// Strange thing, if I copy-paste Implementation of CRS class and set FORCE_LONGITUDE_FIRST_AXIS_ORDER to false, I still don't get 4647, but null. Might it be a bug, maybe 4647 is not in the hsql database?

With best regards, Slava

[Geotools-gt2-users] GeoTools 34.2 released

[Gabriel R. <gab...@gm...>]

Hi GeoTools users

The GeoTools team is pleased to announce the release of the latest stable
version of GeoTools 34.2.

This release is also available from the OSGeo Maven Repository and is made
in conjunction with GeoServer 2.28.2 and GeoWebCache 1.28.2.

For more information, please refer to the GeoTools 34.2 blog post
<https://geotoolsnews.blogspot.com/2026/01/geotools-34.html>, or GitHub
release notes <https://github.com/geotools/geotools/releases/tag/34.2>.

Thanks to Gabriel Roldan (Camptocamp) for making this maintenance release.

-- 
Gabriel Roldán

Re: [Geotools-gt2-users] GeoTools 33.4, GeoServer 2.27.4, GeoWebCache 1.27.4 release

[Peter S. <gs...@sm...>]

Hi GeoTools users

GeoTools 33.4 is now available from SourceForge and maven.

For more information, please see the GeoTools 33.4 blog post
<https://geotoolsnews.blogspot.com/2025/12/geotools-334-released.html>,
or GitHub
release notes <https://github.com/geotools/geotools/releases/tag/33.41>.

Thanks to Peter Smythe (AfriGIS) for making this maintenance release.

--
Peter

GeoServer PSC
https://github.com/petersmythe

[Geotools-gt2-users] WMS extension: insanely long initialization time for XML parsing

[Viatcheslav S. <Via...@h-...>]

Hi everyone 😄

I recently started toying with wms extensions of Geotools (https://docs.geotools.org/latest/userguide/extension/wms/wms.html) and wondered, why it takes so much time to read the capabilities of a WMS server:

WebMapServer wms = new WebMapServer(url); // - takes seconds(!) to complete

I thought it is the server, which is slow, but QGIS reads the capabilities from the same server nearly instantly. It seems it boils down to the piece of code in WMSGetCapabilitiesResponse.java:

object = DocumentFactory.getInstance(inputStream, hints, Level.WARNING);

I did the same from the test code:

return (WMSCapabilities) DocumentFactory.getInstance(getClass().getResourceAsStream("/wms_basemapde.xml"), null, Level.WARNING);

... and whoa the line takes whole 3 seconds to complete on my "super modern notebook". It is basically the time Windows used to start after fresh install...
Any idea, what's going on there and how to avoid this delay?

With best regards and merry christmas / new year ;)

Viatcheslav Sysoltsev

Re: [Geotools-gt2-users] GeoTiffReader locks the file indefinitely?

[Roar B. <roa...@gm...>]

Hi,

Strange, then I would suggest that you file a report in the Jira.
I tried it at my Mac and it didn't seem to have the same problem as you experience. Which might indicate it is related to Windows.
You might include that in your report.

Regards,

Roar Brænden

> 11. des. 2025 kl. 17:16 skrev Viatcheslav Sysoltsev <Via...@h-...>:
> 
> Hi,
> 
> after reader.dispose() the file is still locked in actual version (34.1):
> File file = new File("C:\\Projects\\tmp\\tmp2\\qwf_T.tif");
> GeoTiffReader reader = new GeoTiffReader(file);
> GridCoverage2D grid = reader.read(null);
> grid.dispose(true);
> reader.dispose();
> 
> ... file still locked...
> Regards, Slava
> Von: Roar Brænden <roa...@gm... <mailto:roa...@gm...>>
> Gesendet: Donnerstag, 11. Dezember 2025 16:49
> An: Viatcheslav Sysoltsev <Via...@h-... <mailto:Via...@h-...>>
> Cc: Ian Turton <ijt...@gm... <mailto:ijt...@gm...>>; geo...@li... <mailto:geo...@li...> <geo...@li... <mailto:geo...@li...>>
> Betreff: Re: [Geotools-gt2-users] GeoTiffReader locks the file indefinitely?
>  
> Sie erhalten nicht häufig E-Mails von roa...@gm... <mailto:roa...@gm...>. Erfahren Sie, warum dies wichtig ist <https://aka.ms/LearnAboutSenderIdentification>	
> Hi,
> 
> The GeoTiffReader will handle the resource management of the file. You can have several calls for read with params referring to different parts of the file. You wouldn't clutter that with calls for opening / closing the file. The code should look more like:
> 
> GeoTiffReader reader = new GeoTiffReader(file);
> try {
>     reader.read(null);
> } finally {
>     reader.dispose();
> }
> // Here you could check if the file is closed
> 
> Regards,
> Roar Brænden
> 
>> 11. des. 2025 kl. 12:49 skrev Viatcheslav Sysoltsev <Via...@h-... <mailto:Via...@h-...>>:
>> 
>> Hi Ian,
>> 
>> Been debugging, the stream (of type it.geosolutions.imageio.stream.eraf.EnhancedRandomAccessFile) remains not closed after call at org.geotools.gce.geotiff.GeoTiffReader#read():737
>> > pbjRead.add(maskOvrProvider.getSourceSpiProvider().getStream());
>> ... where it is passed to JaI/ImageN
>> 
>> With best regards, Slava
>> 
>> Von: Ian Turton <ijt...@gm... <mailto:ijt...@gm...>>
>> Gesendet: Donnerstag, 11. Dezember 2025 12:16
>> An: Viatcheslav Sysoltsev <Via...@h-... <mailto:Via...@h-...>>
>> Cc: geo...@li... <mailto:geo...@li...> <geo...@li... <mailto:geo...@li...>>
>> Betreff: Re: [Geotools-gt2-users] GeoTiffReader locks the file indefinitely?
>>  
>> Sie erhalten nicht häufig E-Mails von ijt...@gm... <mailto:ijt...@gm...>. Erfahren Sie, warum dies wichtig ist <https://aka.ms/LearnAboutSenderIdentification>	
>> I think that's the expected behaviour on a windows machine for any file opened in a program. The code clearly closes the input stream created from the file that is passed in so I don't think there is any reason GeoTools would be locking the file.
>> 
>> Ian
>> 
>> On Wed, 10 Dec 2025 at 17:31, Viatcheslav Sysoltsev <Via...@h-... <mailto:Via...@h-...>> wrote:
>> Hi everyone,
>> 
>> I'd like to ask if it is an intended behavior, that GeoTiffReader locks the file indefinitely? If yes, is there a way to read the file completely and "dispose" the reader and the lock?
>> 
>> A simple program to demonstrate:
>> 
>> import org.geotools.coverage.grid.GridCoverage2D;
>> import org.geotools.gce.geotiff.GeoTiffReader;
>> import org.junit.jupiter.api.Test;
>> 
>> import java.io.File;
>> import java.time.Duration;
>> 
>> class GeotiffReaderTest {
>>    @Test
>>    public void read() throws Exception {
>>        File file = new File("C:\\Projects\\tmp\\tmp2\\qwf 2_TH.tif");
>>        GeoTiffReader reader = new GeoTiffReader(file);
>>        GridCoverage2D grid = reader.read(null);
>>        Thread.sleep(Duration.ofSeconds(60));
>>    }
>> }
>> when run, it reads the file and sleeps for a minute. Until JVM exits, the tif file cannot be moved or deleted:
>> 
>> C:\Projects\tmp\tmp2>mv "qwf 2_TH.tif" "qwf 2_TH.tif2"
>> /usr/bin/mv: cannot move 'qwf 2_TH.tif' to 'qwf 2_TH.tif2': Device or resource busy
>> 
>> // the problem is reproducible with geotools 34.1 and 33.0
>> 
>> With best regards,
>> Viatcheslav Sysoltsev / Slava
>> 
>> _______________________________________________
>> GeoTools-GT2-Users mailing list
>> Geo...@li... <mailto:Geo...@li...>
>> https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users <https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users>
>> 
>> 
>> -- 
>> Ian Turton
>> _______________________________________________
>> GeoTools-GT2-Users mailing list
>> Geo...@li... <mailto:Geo...@li...>
>> https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users <https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users>

Re: [Geotools-gt2-users] GeoTiffReader locks the file indefinitely?

[Viatcheslav S. <Via...@h-...>]

Hi,

after reader.dispose() the file is still locked in actual version (34.1):

File file = new File("C:\\Projects\\tmp\\tmp2\\qwf_T.tif");
GeoTiffReader reader = new GeoTiffReader(file);
GridCoverage2D grid = reader.read(null);
grid.dispose(true);
reader.dispose();

... file still locked...

Regards, Slava
________________________________
Von: Roar Brænden <roa...@gm...>
Gesendet: Donnerstag, 11. Dezember 2025 16:49
An: Viatcheslav Sysoltsev <Via...@h-...>
Cc: Ian Turton <ijt...@gm...>; geo...@li... <geo...@li...>
Betreff: Re: [Geotools-gt2-users] GeoTiffReader locks the file indefinitely?

Sie erhalten nicht häufig E-Mails von roa...@gm.... Erfahren Sie, warum dies wichtig ist<https://aka.ms/LearnAboutSenderIdentification>
Hi,

The GeoTiffReader will handle the resource management of the file. You can have several calls for read with params referring to different parts of the file. You wouldn't clutter that with calls for opening / closing the file. The code should look more like:

GeoTiffReader reader = new GeoTiffReader(file);
try {
    reader.read(null);
} finally {
    reader.dispose();
}
// Here you could check if the file is closed

Regards,
Roar Brænden

11. des. 2025 kl. 12:49 skrev Viatcheslav Sysoltsev <Via...@h-...<mailto:Via...@h-...>>:

Hi Ian,

Been debugging, the stream (of type it.geosolutions.imageio.stream.eraf.EnhancedRandomAccessFile) remains not closed after call at org.geotools.gce.geotiff.GeoTiffReader#read():737
> pbjRead.add(maskOvrProvider.getSourceSpiProvider().getStream());
... where it is passed to JaI/ImageN

With best regards, Slava

________________________________
Von: Ian Turton <ijt...@gm...<mailto:ijt...@gm...>>
Gesendet: Donnerstag, 11. Dezember 2025 12:16
An: Viatcheslav Sysoltsev <Via...@h-...<mailto:Via...@h-...>>
Cc: geo...@li...<mailto:geo...@li...> <geo...@li...<mailto:geo...@li...>>
Betreff: Re: [Geotools-gt2-users] GeoTiffReader locks the file indefinitely?

Sie erhalten nicht häufig E-Mails von ijt...@gm...<mailto:ijt...@gm...>. Erfahren Sie, warum dies wichtig ist<https://aka.ms/LearnAboutSenderIdentification>
I think that's the expected behaviour on a windows machine for any file opened in a program. The code clearly closes the input stream created from the file that is passed in so I don't think there is any reason GeoTools would be locking the file.

Ian

On Wed, 10 Dec 2025 at 17:31, Viatcheslav Sysoltsev <Via...@h-...<mailto:Via...@h-...>> wrote:
Hi everyone,

I'd like to ask if it is an intended behavior, that GeoTiffReader locks the file indefinitely? If yes, is there a way to read the file completely and "dispose" the reader and the lock?

A simple program to demonstrate:

import org.geotools.coverage.grid.GridCoverage2D;
import org.geotools.gce.geotiff.GeoTiffReader;
import org.junit.jupiter.api.Test;

import java.io.File;
import java.time.Duration;

class GeotiffReaderTest {
   @Test
   public void read() throws Exception {
       File file = new File("C:\\Projects\\tmp\\tmp2\\qwf 2_TH.tif");
       GeoTiffReader reader = new GeoTiffReader(file);
       GridCoverage2D grid = reader.read(null);
       Thread.sleep(Duration.ofSeconds(60));
   }
}
when run, it reads the file and sleeps for a minute. Until JVM exits, the tif file cannot be moved or deleted:

C:\Projects\tmp\tmp2>mv "qwf 2_TH.tif" "qwf 2_TH.tif2"
/usr/bin/mv: cannot move 'qwf 2_TH.tif' to 'qwf 2_TH.tif2': Device or resource busy

// the problem is reproducible with geotools 34.1 and 33.0

With best regards,
Viatcheslav Sysoltsev / Slava

_______________________________________________
GeoTools-GT2-Users mailing list
Geo...@li...<mailto:Geo...@li...>
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users


--
Ian Turton
_______________________________________________
GeoTools-GT2-Users mailing list
Geo...@li...<mailto:Geo...@li...>
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users

Re: [Geotools-gt2-users] GeoTiffReader locks the file indefinitely?

[Roar B. <roa...@gm...>]

Hi,

The GeoTiffReader will handle the resource management of the file. You can have several calls for read with params referring to different parts of the file. You wouldn't clutter that with calls for opening / closing the file. The code should look more like:

GeoTiffReader reader = new GeoTiffReader(file);
try {
    reader.read(null);
} finally {
    reader.dispose();
}
// Here you could check if the file is closed

Regards,
Roar Brænden

> 11. des. 2025 kl. 12:49 skrev Viatcheslav Sysoltsev <Via...@h-...>:
> 
> Hi Ian,
> 
> Been debugging, the stream (of type it.geosolutions.imageio.stream.eraf.EnhancedRandomAccessFile) remains not closed after call at org.geotools.gce.geotiff.GeoTiffReader#read():737
> > pbjRead.add(maskOvrProvider.getSourceSpiProvider().getStream());
> ... where it is passed to JaI/ImageN
> 
> With best regards, Slava
> 
> Von: Ian Turton <ijt...@gm... <mailto:ijt...@gm...>>
> Gesendet: Donnerstag, 11. Dezember 2025 12:16
> An: Viatcheslav Sysoltsev <Via...@h-... <mailto:Via...@h-...>>
> Cc: geo...@li... <mailto:geo...@li...> <geo...@li... <mailto:geo...@li...>>
> Betreff: Re: [Geotools-gt2-users] GeoTiffReader locks the file indefinitely?
>  
> Sie erhalten nicht häufig E-Mails von ijt...@gm... <mailto:ijt...@gm...>. Erfahren Sie, warum dies wichtig ist <https://aka.ms/LearnAboutSenderIdentification>	
> I think that's the expected behaviour on a windows machine for any file opened in a program. The code clearly closes the input stream created from the file that is passed in so I don't think there is any reason GeoTools would be locking the file.
> 
> Ian
> 
> On Wed, 10 Dec 2025 at 17:31, Viatcheslav Sysoltsev <Via...@h-... <mailto:Via...@h-...>> wrote:
> Hi everyone,
> 
> I'd like to ask if it is an intended behavior, that GeoTiffReader locks the file indefinitely? If yes, is there a way to read the file completely and "dispose" the reader and the lock?
> 
> A simple program to demonstrate:
> 
> import org.geotools.coverage.grid.GridCoverage2D;
> import org.geotools.gce.geotiff.GeoTiffReader;
> import org.junit.jupiter.api.Test;
> 
> import java.io.File;
> import java.time.Duration;
> 
> class GeotiffReaderTest {
>    @Test
>    public void read() throws Exception {
>        File file = new File("C:\\Projects\\tmp\\tmp2\\qwf 2_TH.tif");
>        GeoTiffReader reader = new GeoTiffReader(file);
>        GridCoverage2D grid = reader.read(null);
>        Thread.sleep(Duration.ofSeconds(60));
>    }
> }
> when run, it reads the file and sleeps for a minute. Until JVM exits, the tif file cannot be moved or deleted:
> 
> C:\Projects\tmp\tmp2>mv "qwf 2_TH.tif" "qwf 2_TH.tif2"
> /usr/bin/mv: cannot move 'qwf 2_TH.tif' to 'qwf 2_TH.tif2': Device or resource busy
> 
> // the problem is reproducible with geotools 34.1 and 33.0
> 
> With best regards,
> Viatcheslav Sysoltsev / Slava
> 
> _______________________________________________
> GeoTools-GT2-Users mailing list
> Geo...@li... <mailto:Geo...@li...>
> https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users <https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users>
> 
> 
> -- 
> Ian Turton
> _______________________________________________
> GeoTools-GT2-Users mailing list
> Geo...@li...
> https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users

Re: [Geotools-gt2-users] GeoTiffReader locks the file indefinitely?

[Simone G. <sim...@ge...>]

you need to dispose of all your objects otherwise streams will not be
closed (until the finalize kicks in).

Regards,
Simone Giannecchini
==
Online training classes for GeoNode, GeoServer and MapStore from the
experts!
Visit https://www.geosolutionsgroup.com/professional-training/ for more
information.
==
Ing. Simone Giannecchini
Founder/Director GeoSolutions Italy
President GeoSolutions USA

phone: +39 0584 962313
fax:     +39 0584 1660272
mob:   +39  333 8128928
US: +1 (845) 547-7905

https://www.geosolutionsgroup.com
https://www.linkedin.com/company/geosolutionsgroup/
https://x.com/geosolutions_it

-------------------------------------------------------
This email is intended only for the person or entity to which it is
addressed and may contain information that is privileged, confidential or
otherwise protected from disclosure. We remind that - as provided by
European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
e-mail or the information herein by anyone other than the intended
recipient is prohibited. If you have received this email by mistake, please
notify us immediately by telephone or e-mail.


On Thu, Dec 11, 2025 at 3:23 PM Viatcheslav Sysoltsev <
Via...@h-...> wrote:

> Hi Ian,
>
> Been debugging, the stream (of type
> it.geosolutions.imageio.stream.eraf.EnhancedRandomAccessFile) remains not
> closed after call at org.geotools.gce.geotiff.GeoTiffReader#read():737
> > pbjRead.add(maskOvrProvider.getSourceSpiProvider().getStream());
> ... where it is passed to JaI/ImageN
>
> With best regards, Slava
>
> ------------------------------
> *Von:* Ian Turton <ijt...@gm...>
> *Gesendet:* Donnerstag, 11. Dezember 2025 12:16
> *An:* Viatcheslav Sysoltsev <Via...@h-...>
> *Cc:* geo...@li... <
> geo...@li...>
> *Betreff:* Re: [Geotools-gt2-users] GeoTiffReader locks the file
> indefinitely?
>
> Sie erhalten nicht häufig E-Mails von ijt...@gm.... Erfahren Sie,
> warum dies wichtig ist <https://aka.ms/LearnAboutSenderIdentification>
> I think that's the expected behaviour on a windows machine for any file
> opened in a program. The code clearly closes the input stream created from
> the file that is passed in so I don't think there is any reason GeoTools
> would be locking the file.
>
> Ian
>
> On Wed, 10 Dec 2025 at 17:31, Viatcheslav Sysoltsev <
> Via...@h-...> wrote:
>
> Hi everyone,
>
> I'd like to ask if it is an intended behavior, that GeoTiffReader locks
> the file indefinitely? If yes, is there a way to read the file completely
> and "dispose" the reader and the lock?
>
> A simple program to demonstrate:
>
> import org.geotools.coverage.grid.GridCoverage2D;
> import org.geotools.gce.geotiff.GeoTiffReader;
> import org.junit.jupiter.api.Test;
>
> import java.io.File;
> import java.time.Duration;
>
> class GeotiffReaderTest {
>    @Test
>    public void read() throws Exception {
>        File file = new File("C:\\Projects\\tmp\\tmp2\\qwf 2_TH.tif");
>        GeoTiffReader reader = new GeoTiffReader(file);
>        GridCoverage2D grid = reader.read(null);
>        Thread.*sleep*(Duration.*ofSeconds*(60));
>    }
> }
> when run, it reads the file and sleeps for a minute. Until JVM exits, the
> tif file cannot be moved or deleted:
>
> C:\Projects\tmp\tmp2>mv "qwf 2_TH.tif" "qwf 2_TH.tif2"
> /usr/bin/mv: cannot move 'qwf 2_TH.tif' to 'qwf 2_TH.tif2': Device or
> resource busy
>
> // the problem is reproducible with geotools 34.1 and 33.0
>
> With best regards,
> Viatcheslav Sysoltsev / Slava
>
> _______________________________________________
> GeoTools-GT2-Users mailing list
> Geo...@li...
> https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
>
>
>
> --
> Ian Turton
> _______________________________________________
> GeoTools-GT2-Users mailing list
> Geo...@li...
> https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
>

Re: [Geotools-gt2-users] GeoTiffReader locks the file indefinitely?

[Andrea A. <and...@ge...>]

The format uses deferred loading, meaning it pulls tiles from the file as
needed.
Please dispose the coverage when you're done using it:

myCoverage.dispose(true)

Regards,

Andrea Aime


==


GeoServer Professional Services from the experts!

Visit http://bit.ly/gs-services-us for more information.

==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions Group
phone: +39 0584 962313

fax:     +39 0584 1660272

mob:   +39  339 8844549

https://www.geosolutionsgroup.com/

http://twitter.com/geosolutions_it

-------------------------------------------------------

Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE
2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si
precisa che ogni circostanza inerente alla presente email (il suo
contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è
riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il
messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra
operazione è illecita. Le sarei comunque grato se potesse darmene notizia.

This email is intended only for the person or entity to which it is
addressed and may contain information that is privileged, confidential or
otherwise protected from disclosure. We remind that - as provided by
European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
e-mail or the information herein by anyone other than the intended
recipient is prohibited. If you have received this email by mistake, please
notify us immediately by telephone or e-mail


On Thu, Dec 11, 2025 at 3:23 PM Viatcheslav Sysoltsev <
Via...@h-...> wrote:

> Hi Ian,
>
> Been debugging, the stream (of type
> it.geosolutions.imageio.stream.eraf.EnhancedRandomAccessFile) remains not
> closed after call at org.geotools.gce.geotiff.GeoTiffReader#read():737
> > pbjRead.add(maskOvrProvider.getSourceSpiProvider().getStream());
> ... where it is passed to JaI/ImageN
>
> With best regards, Slava
>
> ------------------------------
> *Von:* Ian Turton <ijt...@gm...>
> *Gesendet:* Donnerstag, 11. Dezember 2025 12:16
> *An:* Viatcheslav Sysoltsev <Via...@h-...>
> *Cc:* geo...@li... <
> geo...@li...>
> *Betreff:* Re: [Geotools-gt2-users] GeoTiffReader locks the file
> indefinitely?
>
> Sie erhalten nicht häufig E-Mails von ijt...@gm.... Erfahren Sie,
> warum dies wichtig ist <https://aka.ms/LearnAboutSenderIdentification>
> I think that's the expected behaviour on a windows machine for any file
> opened in a program. The code clearly closes the input stream created from
> the file that is passed in so I don't think there is any reason GeoTools
> would be locking the file.
>
> Ian
>
> On Wed, 10 Dec 2025 at 17:31, Viatcheslav Sysoltsev <
> Via...@h-...> wrote:
>
> Hi everyone,
>
> I'd like to ask if it is an intended behavior, that GeoTiffReader locks
> the file indefinitely? If yes, is there a way to read the file completely
> and "dispose" the reader and the lock?
>
> A simple program to demonstrate:
>
> import org.geotools.coverage.grid.GridCoverage2D;
> import org.geotools.gce.geotiff.GeoTiffReader;
> import org.junit.jupiter.api.Test;
>
> import java.io.File;
> import java.time.Duration;
>
> class GeotiffReaderTest {
>    @Test
>    public void read() throws Exception {
>        File file = new File("C:\\Projects\\tmp\\tmp2\\qwf 2_TH.tif");
>        GeoTiffReader reader = new GeoTiffReader(file);
>        GridCoverage2D grid = reader.read(null);
>        Thread.*sleep*(Duration.*ofSeconds*(60));
>    }
> }
> when run, it reads the file and sleeps for a minute. Until JVM exits, the
> tif file cannot be moved or deleted:
>
> C:\Projects\tmp\tmp2>mv "qwf 2_TH.tif" "qwf 2_TH.tif2"
> /usr/bin/mv: cannot move 'qwf 2_TH.tif' to 'qwf 2_TH.tif2': Device or
> resource busy
>
> // the problem is reproducible with geotools 34.1 and 33.0
>
> With best regards,
> Viatcheslav Sysoltsev / Slava
>
> _______________________________________________
> GeoTools-GT2-Users mailing list
> Geo...@li...
> https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
>
>
>
> --
> Ian Turton
> _______________________________________________
> GeoTools-GT2-Users mailing list
> Geo...@li...
> https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
>

Re: [Geotools-gt2-users] GeoTiffReader locks the file indefinitely?

[Viatcheslav S. <Via...@h-...>]

Hi Ian,

Been debugging, the stream (of type it.geosolutions.imageio.stream.eraf.EnhancedRandomAccessFile) remains not closed after call at org.geotools.gce.geotiff.GeoTiffReader#read():737
> pbjRead.add(maskOvrProvider.getSourceSpiProvider().getStream());
... where it is passed to JaI/ImageN

With best regards, Slava

________________________________
Von: Ian Turton <ijt...@gm...>
Gesendet: Donnerstag, 11. Dezember 2025 12:16
An: Viatcheslav Sysoltsev <Via...@h-...>
Cc: geo...@li... <geo...@li...>
Betreff: Re: [Geotools-gt2-users] GeoTiffReader locks the file indefinitely?

Sie erhalten nicht häufig E-Mails von ijt...@gm.... Erfahren Sie, warum dies wichtig ist<https://aka.ms/LearnAboutSenderIdentification>
I think that's the expected behaviour on a windows machine for any file opened in a program. The code clearly closes the input stream created from the file that is passed in so I don't think there is any reason GeoTools would be locking the file.

Ian

On Wed, 10 Dec 2025 at 17:31, Viatcheslav Sysoltsev <Via...@h-...<mailto:Via...@h-...>> wrote:
Hi everyone,

I'd like to ask if it is an intended behavior, that GeoTiffReader locks the file indefinitely? If yes, is there a way to read the file completely and "dispose" the reader and the lock?

A simple program to demonstrate:

import org.geotools.coverage.grid.GridCoverage2D;
import org.geotools.gce.geotiff.GeoTiffReader;
import org.junit.jupiter.api.Test;

import java.io.File;
import java.time.Duration;

class GeotiffReaderTest {
   @Test
   public void read() throws Exception {
       File file = new File("C:\\Projects\\tmp\\tmp2\\qwf 2_TH.tif");
       GeoTiffReader reader = new GeoTiffReader(file);
       GridCoverage2D grid = reader.read(null);
       Thread.sleep(Duration.ofSeconds(60));
   }
}
when run, it reads the file and sleeps for a minute. Until JVM exits, the tif file cannot be moved or deleted:

C:\Projects\tmp\tmp2>mv "qwf 2_TH.tif" "qwf 2_TH.tif2"
/usr/bin/mv: cannot move 'qwf 2_TH.tif' to 'qwf 2_TH.tif2': Device or resource busy

// the problem is reproducible with geotools 34.1 and 33.0

With best regards,
Viatcheslav Sysoltsev / Slava

_______________________________________________
GeoTools-GT2-Users mailing list
Geo...@li...<mailto:Geo...@li...>
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users


--
Ian Turton

Re: [Geotools-gt2-users] GeoTiffReader locks the file indefinitely?

[Ian T. <ijt...@gm...>]

I think that's the expected behaviour on a windows machine for any file
opened in a program. The code clearly closes the input stream created from
the file that is passed in so I don't think there is any reason GeoTools
would be locking the file.

Ian

On Wed, 10 Dec 2025 at 17:31, Viatcheslav Sysoltsev <
Via...@h-...> wrote:

> Hi everyone,
>
> I'd like to ask if it is an intended behavior, that GeoTiffReader locks
> the file indefinitely? If yes, is there a way to read the file completely
> and "dispose" the reader and the lock?
>
> A simple program to demonstrate:
>
> import org.geotools.coverage.grid.GridCoverage2D;
> import org.geotools.gce.geotiff.GeoTiffReader;
> import org.junit.jupiter.api.Test;
>
> import java.io.File;
> import java.time.Duration;
>
> class GeotiffReaderTest {
>    @Test
>    public void read() throws Exception {
>        File file = new File("C:\\Projects\\tmp\\tmp2\\qwf 2_TH.tif");
>        GeoTiffReader reader = new GeoTiffReader(file);
>        GridCoverage2D grid = reader.read(null);
>        Thread.*sleep*(Duration.*ofSeconds*(60));
>    }
> }
> when run, it reads the file and sleeps for a minute. Until JVM exits, the
> tif file cannot be moved or deleted:
>
> C:\Projects\tmp\tmp2>mv "qwf 2_TH.tif" "qwf 2_TH.tif2"
> /usr/bin/mv: cannot move 'qwf 2_TH.tif' to 'qwf 2_TH.tif2': Device or
> resource busy
>
> // the problem is reproducible with geotools 34.1 and 33.0
>
> With best regards,
> Viatcheslav Sysoltsev / Slava
>
> _______________________________________________
> GeoTools-GT2-Users mailing list
> Geo...@li...
> https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
>


-- 
Ian Turton

[Geotools-gt2-users] GeoTiffReader locks the file indefinitely?

[Viatcheslav S. <Via...@h-...>]

Hi everyone,

I'd like to ask if it is an intended behavior, that GeoTiffReader locks the file indefinitely? If yes, is there a way to read the file completely and "dispose" the reader and the lock?

A simple program to demonstrate:

import org.geotools.coverage.grid.GridCoverage2D;
import org.geotools.gce.geotiff.GeoTiffReader;
import org.junit.jupiter.api.Test;

import java.io.File;
import java.time.Duration;

class GeotiffReaderTest {
   @Test
   public void read() throws Exception {
       File file = new File("C:\\Projects\\tmp\\tmp2\\qwf 2_TH.tif");
       GeoTiffReader reader = new GeoTiffReader(file);
       GridCoverage2D grid = reader.read(null);
       Thread.sleep(Duration.ofSeconds(60));
   }
}
when run, it reads the file and sleeps for a minute. Until JVM exits, the tif file cannot be moved or deleted:

C:\Projects\tmp\tmp2>mv "qwf 2_TH.tif" "qwf 2_TH.tif2"
/usr/bin/mv: cannot move 'qwf 2_TH.tif' to 'qwf 2_TH.tif2': Device or resource busy

// the problem is reproducible with geotools 34.1 and 33.0

With best regards,
Viatcheslav Sysoltsev / Slava

Re: [Geotools-gt2-users] A problem with ImageN in a modularized project

[Viatcheslav S. <Via...@h-...>]

Hi all,

status update: I have submitted an issue https://github.com/eclipse-imagen/imagen/issues/127 and been looking for a workaround since then.

So far I was successful using gradle black magic to redirect all dependencies on org.eclipse.imagen:* to org.eclipse.imagen:imagen-all:0.9.1 (which can be modularized and has access to all necessary classes/resources, since it  a single fat jar).

I have found few problems with imagen-all though, which make sense to be fixed independently of the state of affairs with modularization:
(1) org.eclipse.imagen:vectorize contains classes from org.jaitools.media.jai.vectorize and generally looks very different from another artifacts of this group. Not a problem per se, just a thing to be aware of. Maybe an another group name for the artifact would be fitting better.
(2) org.eclipse.imagen:imagen-all misses the classes from org.eclipse.imagen:contour - it seems to me it was simply forgotten to be included ;)
(3) imagen-all-0.9.1.jar!\META-INF\org.eclipse.imagen.registryFile.imagen contains a lot of duplicates, I get lot of warnings in console:
Error in registry file at line number #378
A descriptor is already registered against the name "Constant" under registry mode "rendered"
Error in registry file at line number #389
A descriptor is already registered against the name "FilteredSubsample" under registry mode "rendered"
...

I don't know your affiliation with ImageN or who produces the releases/artifacts - should I report the issues (2) and (3) to ImageN or can you, Jody, just look at them / fix them?

With best regards, Slava

________________________________
Von: Jody Garnett <jod...@gm...>
Gesendet: Montag, 8. Dezember 2025 21:50
An: Viatcheslav Sysoltsev <Via...@h-...>
Cc: geo...@li... <geo...@li...>
Betreff: Re: [Geotools-gt2-users] A problem with ImageN in a modularized project

Hi Viatcheslav!

The quickstart has a modules example, but I have not tired it since the introduction of ImageN.

We have talked about removing JAI18N (and internationalization) from ImageN codebase as it does not add much value vs how much work it is to maintain. Please report it to the ImageN issue tracker and we can discuss further.

And yes it is these kind of things we want to sort out before ImageN 1.0 is made. Thank you very much for the feedback!
- -
Jody Garnett


On Dec 8, 2025 at 7:56:50 AM, Viatcheslav Sysoltsev <Via...@h-...<mailto:Via...@h-...>> wrote:
Hi everyone,

does anybody use geotools in java9-modularized project (former project jigsaw)? I get a problem updating from geotools-33.0 to 34.1 in regard to ImageN migration.

Short about my project: it is gradle based and uses java modules. I could patch JAI using https://github.com/gradlex-org/extra-java-module-info, but fail so far doing it for ImageN. The test case is rather minimal and does not even use Geotools (but uses java modules):

public static void main(String[] args) {
       ImageN.getDefaultInstance();
       ...
}

I get exception:

Caused by: java.lang.ExceptionInInitializerError
      at java.base/java.lang.Class.forName0(Native Method)
      at java.base/java.lang.Class.forName(Class.java:467)
      at java.base/java.lang.Class.forName(Class.java:458)
      at imagen.core@0.9.1-module/org.eclipse.imagen.RegistryFileParser.getInstance(RegistryFileParser.java:187)
      at imagen.core@0.9.1-module/org.eclipse.imagen.RegistryFileParser.registerDescriptor(RegistryFileParser.java:312)
      at imagen.core@0.9.1-module/org.eclipse.imagen.RegistryFileParser.parseFile(RegistryFileParser.java:251)
      at imagen.core@0.9.1-module/org.eclipse.imagen.RegistryFileParser.loadOperationRegistry(RegistryFileParser.java:55)
      at imagen.core@0.9.1-module/org.eclipse.imagen.OperationRegistry.registerServices(OperationRegistry.java:1543)
      at imagen.core@0.9.1-module/org.eclipse.imagen.ThreadSafeOperationRegistry.registerServices(ThreadSafeOperationRegistry.java:529)
      at imagen.core@0.9.1-module/org.eclipse.imagen.OperationRegistry.initializeRegistry(OperationRegistry.java:311)
      at imagen.core@0.9.1-module/org.eclipse.imagen.ImageN.<clinit>(ImageN.java:351)
      at SSV9GUIKomponents/de.oowv.application.SSVMainWindow.main(SSVMainWindow.java:51)
      at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
      ... 6 more
Caused by: java.lang.NullPointerException: Cannot invoke "java.util.ResourceBundle.getString(String)" because "b" is null
      at imagen.core@0.9.1-module/org.eclipse.imagen.media.util.PropertyUtil.getString(PropertyUtil.java:159)
      at org.eclipse.imagen.media.affine.JaiI18N.getString(JaiI18N.java:26)
      at org.eclipse.imagen.media.affine.AffineDescriptor.<clinit>(AffineDescriptor.java:254)
      ... 19 more

The way JaiI18N reads the resources is not compatible with modules, it has to use classloader of the class for which the properties are being loaded. I submit an issue to ImageN tomorrow, but not sure how to proceed with planned Geotools version update so far. Any ideas for me / experience in regard to the issue?

With best regards

Viatcheslav Sysoltsev / Slava


_______________________________________________
GeoTools-GT2-Users mailing list
Geo...@li...<mailto:Geo...@li...>
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users

Re: [Geotools-gt2-users] A problem with ImageN in a modularized project

[Jody G. <jod...@gm...>]

 Hi Viatcheslav!

The quickstart has a modules example, but I have not tired it since the
introduction of ImageN.

We have talked about removing JAI18N (and internationalization) from ImageN
codebase as it does not add much value vs how much work it is to maintain.
Please report it to the ImageN issue tracker and we can discuss further.

And yes it is these kind of things we want to sort out before ImageN 1.0 is
made. Thank you very much for the feedback!
- -
Jody Garnett


On Dec 8, 2025 at 7:56:50 AM, Viatcheslav Sysoltsev <
Via...@h-...> wrote:

> Hi everyone,
>
> does anybody use geotools in java9-modularized project (former project
> jigsaw)? I get a problem updating from geotools-33.0 to 34.1 in regard to
> ImageN migration.
>
> Short about my project: it is gradle based and uses java modules. I could
> patch JAI using https://github.com/gradlex-org/extra-java-module-info,
> but fail so far doing it for ImageN. The test case is rather minimal and
> does not even use Geotools (but uses java modules):
>
> public static void main(String[] args) {
>        ImageN.*getDefaultInstance*();
>        ...
> }
>
> I get exception:
>
> Caused by: java.lang.ExceptionInInitializerError
> at java.base/java.lang.Class.forName0(Native Method)
> at java.base/java.lang.Class.forName(Class.java:467)
> at java.base/java.lang.Class.forName(Class.java:458)
> at imagen.core@0.9.1-module
> /org.eclipse.imagen.RegistryFileParser.getInstance(RegistryFileParser.java:187)
> at imagen.core@0.9.1-module
> /org.eclipse.imagen.RegistryFileParser.registerDescriptor(RegistryFileParser.java:312)
> at imagen.core@0.9.1-module
> /org.eclipse.imagen.RegistryFileParser.parseFile(RegistryFileParser.java:251)
> at imagen.core@0.9.1-module
> /org.eclipse.imagen.RegistryFileParser.loadOperationRegistry(RegistryFileParser.java:55)
> at imagen.core@0.9.1-module
> /org.eclipse.imagen.OperationRegistry.registerServices(OperationRegistry.java:1543)
> at imagen.core@0.9.1-module
> /org.eclipse.imagen.ThreadSafeOperationRegistry.registerServices(ThreadSafeOperationRegistry.java:529)
> at imagen.core@0.9.1-module
> /org.eclipse.imagen.OperationRegistry.initializeRegistry(OperationRegistry.java:311)
> at imagen.core@0.9.1-module
> /org.eclipse.imagen.ImageN.<clinit>(ImageN.java:351)
> at
> SSV9GUIKomponents/de.oowv.application.SSVMainWindow.main(SSVMainWindow.java:51)
> at
> java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> ... 6 more
> Caused by: java.lang.NullPointerException: Cannot invoke
> "java.util.ResourceBundle.getString(String)" because "b" is null
> at imagen.core@0.9.1-module
> /org.eclipse.imagen.media.util.PropertyUtil.getString(PropertyUtil.java:159)
> at org.eclipse.imagen.media.affine.JaiI18N.getString(JaiI18N.java:26)
> at
> org.eclipse.imagen.media.affine.AffineDescriptor.<clinit>(AffineDescriptor.java:254)
> ... 19 more
>
> The way JaiI18N reads the resources is not compatible with modules, it has
> to use classloader of the class for which the properties are being loaded.
> I submit an issue to ImageN tomorrow, but not sure how to proceed with
> planned Geotools version update so far. Any ideas for me / experience in
> regard to the issue?
>
> With best regards
>
> Viatcheslav Sysoltsev / Slava
>
>
> _______________________________________________
> GeoTools-GT2-Users mailing list
> Geo...@li...
> https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
>

[Geotools-gt2-users] A problem with ImageN in a modularized project

[Viatcheslav S. <Via...@h-...>]

Hi everyone,

does anybody use geotools in java9-modularized project (former project jigsaw)? I get a problem updating from geotools-33.0 to 34.1 in regard to ImageN migration.

Short about my project: it is gradle based and uses java modules. I could patch JAI using https://github.com/gradlex-org/extra-java-module-info, but fail so far doing it for ImageN. The test case is rather minimal and does not even use Geotools (but uses java modules):

public static void main(String[] args) {
       ImageN.getDefaultInstance();
       ...
}

I get exception:

Caused by: java.lang.ExceptionInInitializerError
      at java.base/java.lang.Class.forName0(Native Method)
      at java.base/java.lang.Class.forName(Class.java:467)
      at java.base/java.lang.Class.forName(Class.java:458)
      at imagen.core@0.9.1-module/org.eclipse.imagen.RegistryFileParser.getInstance(RegistryFileParser.java:187)
      at imagen.core@0.9.1-module/org.eclipse.imagen.RegistryFileParser.registerDescriptor(RegistryFileParser.java:312)
      at imagen.core@0.9.1-module/org.eclipse.imagen.RegistryFileParser.parseFile(RegistryFileParser.java:251)
      at imagen.core@0.9.1-module/org.eclipse.imagen.RegistryFileParser.loadOperationRegistry(RegistryFileParser.java:55)
      at imagen.core@0.9.1-module/org.eclipse.imagen.OperationRegistry.registerServices(OperationRegistry.java:1543)
      at imagen.core@0.9.1-module/org.eclipse.imagen.ThreadSafeOperationRegistry.registerServices(ThreadSafeOperationRegistry.java:529)
      at imagen.core@0.9.1-module/org.eclipse.imagen.OperationRegistry.initializeRegistry(OperationRegistry.java:311)
      at imagen.core@0.9.1-module/org.eclipse.imagen.ImageN.<clinit>(ImageN.java:351)
      at SSV9GUIKomponents/de.oowv.application.SSVMainWindow.main(SSVMainWindow.java:51)
      at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
      ... 6 more
Caused by: java.lang.NullPointerException: Cannot invoke "java.util.ResourceBundle.getString(String)" because "b" is null
      at imagen.core@0.9.1-module/org.eclipse.imagen.media.util.PropertyUtil.getString(PropertyUtil.java:159)
      at org.eclipse.imagen.media.affine.JaiI18N.getString(JaiI18N.java:26)
      at org.eclipse.imagen.media.affine.AffineDescriptor.<clinit>(AffineDescriptor.java:254)
      ... 19 more

The way JaiI18N reads the resources is not compatible with modules, it has to use classloader of the class for which the properties are being loaded. I submit an issue to ImageN tomorrow, but not sure how to proceed with planned Geotools version update so far. Any ideas for me / experience in regard to the issue?

With best regards

Viatcheslav Sysoltsev / Slava

Re: [Geotools-gt2-users] GeoTools 34.0 released for Java 17 with Eclipse ImageN processing engine

[Kalesse S. <Soe...@dw...>]

Hi Jody and Andrea,

I just wanted to give you an update on the  progress. I have made these three tickets and PRs: 

- [ImageN Ticket](https://github.com/eclipse-imagen/imagen/issues/118) --> [ImageN PR](https://github.com/eclipse-imagen/imagen/pull/121)

- [GeoTools Ticket](https://osgeo-org.atlassian.net/browse/GEOT-7832) --> [GeoTools PR](https://github.com/geotools/geotools/pull/5414)

- [GeoServer Ticket](https://osgeo-org.atlassian.net/browse/GEOS-11987) --> [GeoServer PR](https://github.com/geoserver/geoserver/pull/8935)

The first is the change of names and registry in ImageN. The latter two are preparing the update to ImageN 0.9.1 that might hopefully include a fix for this problem - once in GeoTools and once in GeoServer. I have marked the latter as draft, because they can only be tackled once a new ImageN version would be available. 

Thanks
Sören


-----Ursprüngliche Nachricht-----
Von: Kalesse Sören <ska...@ex...> 
Gesendet: Donnerstag, 6. November 2025 15:44
An: Kalesse Sören <ska...@ex...>; 'Jody Garnett' <jod...@gm...>
Cc: GeoTools Users <geo...@li...>
Betreff: AW: [Geotools-gt2-users] GeoTools 34.0 released for Java 17 with Eclipse ImageN processing engine

Hi Jody, 

I have made that PR for ImageN now, see https://github.com/eclipse-imagen/imagen/pull/121. I have branches on my fork for GeoTools and GeoServer as well, but I would probably have to wait for a new ImageN release and make some JIRA tickets first as well right?

All of ImageN compiled and test-cases run successfully. I also tried locally and was able to verify that GeoTools and GeoServer are using the new scheme correctly. Infact it was one test-case in GeoTools that failed with the new lib, and was repaired by also switching the naming scheme there. So we know that it should work once I make my PRs for GeoTools and GeoServer. 

Thanks!
Sören

-----Ursprüngliche Nachricht-----
Von: Kalesse Sören <Soe...@dw...> 
Gesendet: Donnerstag, 6. November 2025 12:01
An: 'Jody Garnett' <jod...@gm...>
Cc: GeoTools Users <geo...@li...>
Betreff: Re: [Geotools-gt2-users] GeoTools 34.0 released for Java 17 with Eclipse ImageN processing engine

Hi Jody, 

I cannot judge about that.  I have done a quick check and it seems GeoTools has two operators (in gt-coverage and gt-process-raster) and GeoServer has one in wps-download. I can make Prs for those too if you want. 

Still, I think that this renaming task of the registry files is unrelated to the actual problem. I hope that we can agree on that. 

Btw, out of curiosity I have checked JAI-EXT and it turns out that it has the same problem. I have looked at GeoServer 2.27.3 that still uses JAI and JAI-EXT:

  - jt-jiffle and jt-vectorize have invalid ServiceLoader interface definitions similar too ImageN. Therefore these are ignored by JAI (Jai-ext seems to use the JAI operation registry)
  - jt-crop that the correct ServiceLoader interface, so in theory we would expect it to crash because it has both registryFile AND ServiceLoader. But for some extremely odd reasons, in jt-crop the registryFile is called registryFile.jaiext. Therefore, here in this case the registryFile is ignored by JAI (it does not know anything about the jaiext file extension).

So it looks these problems have been ported over from JAI-EXT, but since in any case only one of the registration schemes actually works, the problem is hidden. 

Sören

-----Ursprüngliche Nachricht-----
Von: Jody Garnett <jod...@gm...> 
Gesendet: Mittwoch, 5. November 2025 16:16
An: Kalesse Sören <ska...@ex...>
Cc: GeoTools Users <geo...@li...>
Betreff: Re: [Geotools-gt2-users] GeoTools 34.0 released for Java 17 with Eclipse ImageN processing engine

Because ImageN is so new I do it think other projects have implemented operators yet to be registered?


- -

Jody Garnett


On Wed, Nov 5, 2025 at 4:08 AM Kalesse Sören <Soe...@dw... <mailto:Soe...@dw...> > wrote:


	Hi again, 
	
	after reading my previous e-mail I believe maybe an example would make it clearer. Let's go by the ImageN crop example (although the same argumentation is valid also for the other two (jiffle and vectorize)).
	
	So let's assume at first that both ImageN and JAI work well individually with the two mechanisms of registration: the (JAI/ImageN) registryFile and Java ServiceLoader. 
	
	Then, let's look at crops's resources on the ImageN main branch. We have: 
	
	RegistryFile: 
	modules/crop/src/main/resources/META-INF/registryFile.jai (stripped of comments):
	---------------------------------------------------------------------------------------------------------------------------
	
	  descriptor  org.eclipse.imagen.media.crop.CropDescriptor
	  rendered  org.eclipse.imagen.media.crop.CropCRIF     org.eclipse.imagen.media  Crop   Crop
	
	and we have the Java ServiceLoader definition: 
	modules/crop/src/main/resources/META-INF/services/javax.media.jai.OperationRegistrySpi:
	---------------------------------------------------------------------------------------------------------------------------
	
	  org.eclipse.imagen.media.crop.CropSpi
	
	The most obvious thing here is that the Java ServiceLoader definition is wrong, because CropSpi does not implement the javax.media.jai.OperationRegistrySpi interface. 
	
	If we use only ImageN in our application, we will not notice the problem. ImageN is simply ignoring that ServiceLoader definition, because the interface is unknown to ImageN. BUT this will crash JAI, because ServiceLoader in JAI throws a ClassCastException given that definition. 
	
	Now, as proposed, we could (and should) fix this by renaming modules/crop/src/main/resources/META-INF/services/javax.media.jai.OperationRegistrySpi to modules/crop/src/main/resources/META-INF/services/org.eclipse.imagen.OperationRegistrySpi. 
	
	That now pleases JAI, because JAI does not know that new (ImageN) interface. Great! So now all should be good? NO! Because now we have this: 
	
	RegistryFile: 
	modules/crop/src/main/resources/META-INF/registryFile.jai (stripped of comments):
	---------------------------------------------------------------------------------------------------------------------------
	
	  descriptor  org.eclipse.imagen.media.crop.CropDescriptor
	  rendered  org.eclipse.imagen.media.crop.CropCRIF     org.eclipse.imagen.media  Crop   Crop
	
	and we have the fixed Java ServiceLoader definition: 
	modules/crop/src/main/resources/META-INF/services/org.eclipse.imagen.OperationRegistrySpi:
	---------------------------------------------------------------------------------------------------------------------------
	
	  org.eclipse.imagen.media.crop.CropSpi
	
	Technically everything looks fine, BUT ImageN will no longer initialize, because we apply the two types of registration schemes at once. With this, what happens is that the Crop operation gets registered once using registryFile, and then ImageN tries again using ServiceLoader, because now the definition is no longer ignored. 
	
	And this is the core problem. The wrong ServiceLoader definition files on main branch are simply hiding the problem, because ImageN will ignore them, but if we fix them to be correct, then ImageN will fail to initialize, because Crop is already there. The same argumentation goes for jiffle and vectorize, because those two also have (wrong) Java ServiceLoader  definitions. So fixing them too, will result in the same problem of failing initialization. 
	
	And last but not least, the reason for all other libraries to not fail, is that none of the other libraries have Java ServiceLoader definitions at all. 
	
	That as the reason why my initial PR#119 simply removed the three ServiceLoader definitions from crop, jiffle and vectorize. 
	
	Does that better illustrate the problem?
	
	
	==== Now another topic: should we rename registryFile.jai --> registryFile.imagen =======
	
	Maybe it should be done to make a more explicit distinction between ImageN and JAI registration. It should be noted though that the renaming is a breaking change for everyone using ImageN, because for example GeoTools/GeoServer and other applications that have their own ImageN operators implemented will have to switch to that new naming scheme. But, yeah, maybe it's worth the effort - I don't know. 
	
	What I want to emphasize though is that I have tried locally with the wrong ServiceLoader definitions removed from ImageN. I ran GeoServer 2.28.0 that is now based on ImageN with some of our custom JAI operators that are still based on JAI 1.1.3. First, now both ImageN and JAI initialized correctly and I was able to successfully run WMS queries (which should prove that ImageN is working correctly) and I could also verify that our own custom JAI operators are working as well. 
	
	My assumption based on that test is that it does not seem to matter too much how these registry files are named. It seems both, ImageN as well as JAI can cope with either and probably filtering the operations by the definitions they support. 
	
	Of course I can currently not prove that by the same names, both work correctly, but that was my first try. Maybe a JAI/ImageN interoperability Test-case could prove. I don't know. 
	
	But to summarize the current discussion. Whether or not the registry files should be renamed, does not relate to that other issue I presented in the first part of the e-mail.
	
	I hope, by this report, my argumentation becomes clearer. Sorry for that long wall of text.
	Thanks!
	Sören
	
	
	-----Ursprüngliche Nachricht-----
	Von: Kalesse Sören <Soe...@dw... <mailto:Soe...@dw...> > 
	Gesendet: Mittwoch, 5. November 2025 10:55
	An: Jody Garnett <jod...@gm... <mailto:jod...@gm...> >
	Cc: GeoTools Users <geo...@li... <mailto:geo...@li...> >
	Betreff: Re: [Geotools-gt2-users] GeoTools 34.0 released for Java 17 with Eclipse ImageN processing engine
	
	Hi Jody, 
	
	Ok, I can make a PR, but with that all renaming happening, it'll be quite some big change and probably PRs needed for GeoTools and GeoServer as well, right? ... and all other libs that are already using ImageN. 
	
	I am very sorry but I really need to emphasize again, that the registry files are not the problem here! ImageN and JAI seem to be able to cope with them even though they have the same name (registryFile.jai). I have tested it locally running ImageN and JAI in the same application and they do not interfere at all. I was able to run GeoServer 2.28.0 that uses ImageN and still use our own JAI operators based on JAI core 1.1.3 without any problems at all. 
	
	Really, the problem here are those invalid Java ServiceLoader definitions. 
	
	    modules/crop/src/main/resources/META-INF/services/javax.media.jai.OperationRegistrySpi
	    modules/jiffle/jt-jiffle-op/src/main/resources/META-INF/services/javax.media.jai.OperationsRegistrySpi
	    modules/vectorize/src/main/resources/META-INF/services/javax.media.jai.OperationsRegistrySpi
	
	The first one (crop) tries registering at JAI operation registry, which is wrong. This will cause a ClassCastException in JAI. 
	The other two (jiffle and vectorize) try the same thing but even worse, the interface names are wrong --> OperationsRegistrySpi vs. OperationRegistrySpi. So these two will simply be ignored, because that interface does not exist. 
	
	I could fix the names of the ServiceLoader definitions --> org.eclipse.imagen.OperationRegistrySpi. That would please Java at least. So that's good, but ImageN will no longer work, because as mentioned earlier, ImageN registry cannot currently not deal with two mechanisms being in place at the same time. Fixing the names will do this (Example taken from the Jiffle test cases):
	
	[ERROR] org.eclipse.imagen.media.jiffleop.NoSourceTest.createSequentialImage -- Time elapsed: 0 s <<< ERROR!
	java.lang.NoClassDefFoundError: Could not initialize class org.eclipse.imagen.ImageN
	        at org.eclipse.imagen.media.jiffleop.NoSourceTest.reset(NoSourceTest.java:82)
	        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	        at java.base/java.lang.reflect.Method.invoke(Method.java:580)
	        at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
	        at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	        at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
	        at org.junit.internal.runners.statements.RunAfters.invokeMethod(RunAfters.java:46)
	        at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33)
	        at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
	        at org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
	Caused by: java.lang.ExceptionInInitializerError: Exception java.lang.IllegalArgumentException: A descriptor is already registered against the name "Jiffle" under registry mode "rendered" [in thread "main"]
	        at org.eclipse.imagen.DescriptorCache.addDescriptor(DescriptorCache.java:144)
	        at org.eclipse.imagen.OperationRegistry.registerDescriptor(OperationRegistry.java:580)
	        at org.eclipse.imagen.ThreadSafeOperationRegistry.registerDescriptor(ThreadSafeOperationRegistry.java:156)
	        at org.eclipse.imagen.media.jiffleop.JiffleSpi.updateRegistry(JiffleSpi.java:73)
	        at org.eclipse.imagen.OperationRegistry.registerServices(OperationRegistry.java:1556)
	        at org.eclipse.imagen.ThreadSafeOperationRegistry.registerServices(ThreadSafeOperationRegistry.java:529)
	        at org.eclipse.imagen.OperationRegistry.initializeRegistry(OperationRegistry.java:311)
	        at org.eclipse.imagen.ImageN.<clinit>(ImageN.java:351)
	
	The descriptor cache does not allow an operation to be registered twice. That is why I am saying that fixing the ServiceLoader definitions won't help at all. The only options I see is:
	
	 1. make descriptor cache support registry definitions coming from multiple places at the same time 
	   ---> I am not sure if that's really a good idea
	 2. remove the ServiceLoader definitions from those three libs
	
	I am wondering anyway, why is it that only those three libs do have ServiceLoader files at all? What about the other libs? Not a single other lib has any ServiceLoader definition at all.
	
	My PR#119 did exactly that. It removed the ServiceLoader definitions from those three libs. That's all it did and that fixed it all. No renaming of registryFile.jai required. 
	
	To summarize: 
	============
	
	 I can make a PR that renames all registryFile.jai --> registryFile.imagen and changes the ImageN registry to use those instead - no problem. 
	
	But that will not help with the initial problem, we need to deal with those ServiceLoader files - fixing their names to match the correct interface will not help. On the contrary, it will make it worse, because ImageN will no longer initialize, because it cannot handle both (registryFile.[jai|imagen] and ServiceLoader) at the same time.
	
	My proposal is to go by the initial PR and remove the ServiceLoader files all together for these three modules that have them (crop, jiffle, vectorize).
	
	What do you think?
	Thanks
	Sören
	
	
	-----Ursprüngliche Nachricht-----
	Von: Jody Garnett <jod...@gm... <mailto:jod...@gm...> > 
	Gesendet: Mittwoch, 5. November 2025 02:47
	An: Kalesse Sören <ska...@ex... <mailto:ska...@ex...> >
	Cc: GeoTools Users <geo...@li... <mailto:geo...@li...> >
	Betreff: Re: [Geotools-gt2-users] GeoTools 34.0 released for Java 17 with Eclipse ImageN processing engine
	
	So ideally we should fix the invalid definitions, and rename the files to end with “imagen”.
	
	If you make a PR I am willing to do a 0.9.1 relate; and Gabe offered to make a geotools release on schedule next week. 
	
	- -
	
	Jody Garnett
	
	
	On Mon, Nov 3, 2025 at 11:12 PM Kalesse Sören <Soe...@dw... <mailto:Soe...@dw...>  <mailto:Soe...@dw... <mailto:Soe...@dw...> > > wrote:
	
	
	        Hi Andrea, 
	
	        That's exactly my point. I  do assume that it was not intended for these two to coexist, but it should just work fine because there are two different registries and the operations interfaces are different, so in theory these two do not collide at all. That gives all users a good "workaround" to live with until applications and libraries have succeeded to migrate. 
	
	        And that's also exactly where my PR comes in. The three mentioned ImageN libraries (and only those three!) contain ServiceLoader definitions that are wrong. The register the ImageN operations at the JAI registry. That leads to class cast exceptions (wrong interfaces). That's the point that must definitely be fixed whatsoever.
	
	        Now that fixed, here arises the second aspect: Right now you cannot mix standard ImageN and ServiceLoader registration. ImageN does not support that. It will fail to initialize if one operation had already been registered by that other means. So you must decide: either support multiple ways of registration in the ImageN core or decide upon one and let it go. 
	
	        Therefore my PR removes the three ServiceLoader definitions: 1) because they were wrong and 2) because that is the least invasive fix to make ImageN initialize correctly. The PR#119 was tested locally running GeoServer 2.2.8.0 and another application that uses JAI and it worked just fine.
	
	        I hope you can agree that this is a proper fix and should be part in one of the next releases. For us it is a show-stopper for upgrading to GT 33.x / GS 2.28.x. 
	
	        Thanks!
	        Sören
	
	        -----Ursprüngliche Nachricht-----
	        Von: Andrea Aime <and...@ge... <mailto:and...@ge...>  <mailto:and...@ge... <mailto:and...@ge...> > > 
	        Gesendet: Freitag, 31. Oktober 2025 15:25
	        An: Kalesse Sören <ska...@ex... <mailto:ska...@ex...>  <mailto:ska...@ex... <mailto:ska...@ex...> > >
	        Cc: GeoTools Users <geo...@li... <mailto:geo...@li...>  <mailto:geo...@li... <mailto:geo...@li...> > >
	        Betreff: Re: [Geotools-gt2-users] GeoTools 34.0 released for Java 17 with Eclipse ImageN processing engine
	
	        Hi,
	        I second what Jody said, there was no plan to make the coexist, it's an upgrade path.
	        However... I believe that a coexistence could be possible, the java packages
	        are different, so by having ImageN use a different file name for the registry files in META-INF, 
	        from registryFile.jai to registryFile.imagen, a coexistence might be possible, even if likely
	        wasteful (two separate image processing caches in memory are not the greatest of ideas).
	
	        A coexistence is just not in our plans, but since ImageN is not yet available as 1.0, if DWD wants
	        to put the development effort to get it done, I would not be against it.
	        I see this applicable to the GeoServer 3.0 series.
	
	        I would recommend switching existing software to ImageN though, we prepared migration scripts
	        that should help in the endeavor.
	
	        Regards,
	
	        Andrea Aime
	
	
	
	
	        ==
	
	
	        GeoServer Professional Services from the experts!
	
	        Visit http://bit.ly/gs-services-us <http://bit.ly/gs-services-us>  for more information.
	
	
	
	        ==
	
	        Ing. Andrea Aime 
	        @geowolf
	        Technical Lead
	
	
	
	        GeoSolutions Group
	        phone: +39 0584 962313
	
	        fax:     +39 0584 1660272
	
	        mob:   +39  339 8844549
	
	
	        https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVA0Pzs/NCh4MzwgPihnajM+PzQ+Pyh9Z2lgb3p7fGszP2s2ODk/Nm04PGs2b29vODk6Oj1tNj5rOG9tbG1qOG9sbDtqaG06aCh6Mz85ODw9PTg4PToof2dqMztPOzd4S1pmPjw8PD85IztPOzd4S1pnPjw8PD85KHxtfnozXWFrfGtgIEVvYmt9fWtOanlqIGprKG0zOzwoZmpiMz4=&url=https%3a%2f%2fwww.geosolutionsgroup.com%2f  <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVUzODw4My9/NDsnOS9gbTQ5ODM5OC96YG5naH18e2w0bTs+Ozo+bDtqajtqMDsxPT1qOmg5PD49MDE+Omwwam0xMWprbzE4Oy99NDg+Pzs6OT47MDkveGBtNDxIPDhkSGN5OTg/Pj46JDxIPDhkSGN4OTg/Pj46L3tqeX00WmZse2xnJ0JoZWx6emxJbX5tJ21sL2o0PDsvYW1lNDk=&url=https%3a%2f%2fwww.geosolutionsgroup.com%2f>  <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVs5MjYyOSV1PjEtMyVqZz4zMjkzMiVwamRtYnd2cWY+Ozs6OjQ2MTAyM2Y1MDU1NjQxZzFiOzUwMWA0ZjAwZzQwNzA6ZTY2NCV3PjI0NTI6MTM0OzolcmpnPjY6VUZSV3FGMzEyMTswLjY6VUZSV3FFMzEyMTswJXFgc3c+UGxmcWZtLUhib2ZwcGZDZ3RnLWdmJWA+NjEla2dvPjM=&url=https%3a%2f%2fwww.geosolutionsgroup.com%2f> 
	
	        https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVA0Pzs/NCh4MzwgPihnajM+PzQ+Pyh9Z2lgb3p7fGszNmpqbG1sO2g5ajhsOT1rOjo9PG0+PW9sbWw2PW06PW06Oz88ajo5aCh6Mz85ODw9PTg4PToof2dqMztPOzd4S1pmPjw8PD85IztPOzd4S1pnPjw8PD85KHxtfnozXWFrfGtgIEVvYmt9fWtOanlqIGprKG0zPTkoZmpiMz4=&url=http%3a%2f%2ftwitter.com%2fgeosolutions_it  <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVUzODw4My9/NDsnOS9gbTQ5ODM5OC96YG5naH18e2w0PWg9bW1obzFqaGpsPz5sbToxa2xrPjA9PW06PDBobDk5bG09a2s5bS99NDg+Pzs6OT47MDkveGBtNDxIPDhkSGN5OTg/Pj46JDxIPDhkSGN4OTg/Pj46L3tqeX00WmZse2xnJ0JoZWx6emxJbX5tJ21sL2o0Oj4vYW1lNDk=&url=http%3a%2f%2ftwitter.com%2fgeosolutions_it>  <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVs5MjYyOSV1PjEtMyVqZz4zMjkzMiVwamRtYnd2cWY+MDplNTQ7ZzM6YTozNmU7NGY1OjtmZzdnYTIzYjIwYmJmNGU2MDBgZiV3PjI0NTI6MTM0OzolcmpnPjY6VUZSV3FGMzEyMTswLjY6VUZSV3FFMzEyMTswJXFgc3c+UGxmcWZtLUhib2ZwcGZDZ3RnLWdmJWA+MDQla2dvPjM=&url=http%3a%2f%2ftwitter.com%2fgeosolutions_it> 
	
	        -------------------------------------------------------
	
	
	        Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia.
	
	        This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail
	
	
	
	        On Thu, Oct 30, 2025 at 5:29 PM Kalesse Sören <Soe...@dw... <mailto:Soe...@dw...>  <mailto:Soe...@dw... <mailto:Soe...@dw...> >  <mailto:Soe...@dw... <mailto:Soe...@dw...>  <mailto:Soe...@dw... <mailto:Soe...@dw...> > > > wrote:
	
	
	                Hi,
	
	                thanks for the new release! We have noticed a problem though, that deals with environments where GeoTools (and now ImageN) and JAI are used at the same time. I have documented the issue at https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVA0Pzs/NCh4MzwgPihnajM+PzQ+Pyh9Z2lgb3p7fGszb2tqOmw5bDo6Nz45OWhoPTc7PjY/PT89ajo+Pjo5a285azttPD8/bSh6Mz85ODw9PTg4PToof2dqMztPOzd4S1pmPjw8PD85IztPOzd4S1pnPjw8PD85KHxtfnozXWFrfGtgIEVvYmt9fWtOanlqIGprKG0zOzwoZmpiMz4=&url=https%3a%2f%2fgithub.com%2feclipse-imagen%2fimagen%2fissues%2f118  <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVUzODw4My9/NDsnOS9gbTQ5ODM5OC96YG5naH18e2w0MDs9azlvOT0+bT1oa2s7aGgwamxqPzAwbDs8OmxrPj88MD4+azo9PS99NDg+Pzs6OT47MDkveGBtNDxIPDhkSGN5OTg/Pj46JDxIPDhkSGN4OTg/Pj46L3tqeX00WmZse2xnJ0JoZWx6emxJbX5tJ21sL2o0PDsvYW1lNDk=&url=https%3a%2f%2fgithub.com%2feclipse-imagen%2fimagen%2fissues%2f118>  <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVs5MjYyOSV1PjEtMyVqZz4zMjkzMiVwamRtYnd2cWY+NDE1YDExNTs1ZjpnNTEwZzIyZmU7NmE7O2ZmZWFgYjJnMzA0NmY1NSV3PjI0NTI6MTM0OzolcmpnPjY6VUZSV3FGMzEyMTswLjY6VUZSV3FFMzEyMTswJXFgc3c+UGxmcWZtLUhib2ZwcGZDZ3RnLWdmJWA+NjEla2dvPjM=&url=https%3a%2f%2fgithub.com%2feclipse-imagen%2fimagen%2fissues%2f118>  and there is a PR attached https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVA0Pzs/NCh4MzwgPihnajM+PzQ+Pyh9Z2lgb3p7fGszOmxrOTdqams6Ozk/OTs3PGg7PTo9Oj1qN2s2Nm84Pms2OTw2Pm0/PSh6Mz85ODw9PTg4PToof2dqMztPOzd4S1pmPjw8PD85IztPOzd4S1pnPjw8PD85KHxtfnozXWFrfGtgIEVvYmt9fWtOanlqIGprKG0zOzwoZmpiMz4=&url=https%3a%2f%2fgithub.com%2feclipse-imagen%2fimagen%2fpull%2f119  <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVUzODw4My9/NDsnOS9gbTQ5ODM5OC96YG5naH18e2w0ajxsOGtoaj9sbzs9ODhvOG1qaDFqbTowPTg8Pzs4PWhoOzs/OT1vPi99NDg+Pzs6OT47MDkveGBtNDxIPDhkSGN5OTg/Pj46JDxIPDhkSGN4OTg/Pj46L3tqeX00WmZse2xnJ0JoZWx6emxJbX5tJ21sL2o0PDsvYW1lNDk=&url=https%3a%2f%2fgithub.com%2feclipse-imagen%2fimagen%2fpull%2f119>  <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVs5MjYyOSV1PjEtMyVqZz4zMjkzMiVwamRtYnd2cWY+ZmVgNDplZTRlYWY0NWUzZ2BlMjA3M2UzZTU1MGdmNjQ6Zzc1MGdnNyV3PjI0NTI6MTM0OzolcmpnPjY6VUZSV3FGMzEyMTswLjY6VUZSV3FFMzEyMTswJXFgc3c+UGxmcWZtLUhib2ZwcGZDZ3RnLWdmJWA+NjEla2dvPjM=&url=https%3a%2f%2fgithub.com%2feclipse-imagen%2fimagen%2fpull%2f119> . 
	
	                I wonder if there's any chance the problem can be solved soon as it currently prevents us from upgrading to GeoServer 2.28.x. 
	
	                Thanks and Best Regards
	                Sören 
	
	                -----Ursprüngliche Nachricht-----
	                Von: Jody Garnett <jod...@gm... <mailto:jod...@gm...>  <mailto:jod...@gm... <mailto:jod...@gm...> >  <mailto:jod...@gm... <mailto:jod...@gm...>  <mailto:jod...@gm... <mailto:jod...@gm...> > > > 
	                Gesendet: Mittwoch, 22. Oktober 2025 20:57
	                An: GeoTools Users <geo...@li... <mailto:geo...@li...>  <mailto:geo...@li... <mailto:geo...@li...> >  <mailto:geo...@li... <mailto:geo...@li...>  <mailto:geo...@li... <mailto:geo...@li...> > > >
	                Betreff: [Geotools-gt2-users] GeoTools 34.0 released for Java 17 with Eclipse ImageN processing engine
	
	                The GeoTools team is pleased to announce the release <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVE3PDg8Nyt7MD8jPStkaTA9PDc9PCt+ZGpjbHl4f2gwazk7bj5uNG8+Oj5saW5ub2s4NT5raW5paWg+bGw+bjs0OT41azw9PCt5MDw6Ozw8ODQ1OjsrfGRpMDg0QEc5bGFpPT85NDs4IDg0QEc5bGFoPT85NDs4K39ufXkwXmJof2hjI0ZsYWh+fmhNaXppI2loK24wNT0rZWlhMD0=&url=https%3a%2f%2fgeotoolsnews.blogspot.com%2f2025%2f10%2fgeotools-340-release.html>  of the latest stable version of GeoTools 34.0 <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVE3PDg8Nyt7MD8jPStkaTA9PDc9PCt+ZGpjbHl4f2gwbDU1azU5OWhpaT9sbG5rPTRuPmw9ND9rOWg7NGhuPDU9Oz88aWtsOit5MDw6Ozw8ODQ1OjsrfGRpMDg0QEc5bGFpPT85NDs4IDg0QEc5bGFoPT85NDs4K39ufXkwXmJof2hjI0ZsYWh+fmhNaXppI2loK24wOD8rZWlhMD0=&url=https%3a%2f%2fsourceforge.net%2fprojects%2fgeotools%2ffiles%2fGeoTools%252034%2520Releases%2f34.0%2f> . This release is available from the repo.osgeo.org <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVw4MzczOCR0PzAsMiRrZj8yMzgyMyRxa2VsY3Z3cGc/ZGA6MTE6NGEzZzthNTIwZ2AzOjFkNjQxNjVgMjsxOzQ1NWcwMTc1OiR2PzM1NDAxNzc6MzIkc2tmPzdDN0RFbXNxMjM2OzQ6LzdDN0RFbXN2MjM2OzQ6JHBhcnY/UW1ncGdsLEljbmdxcWdCZnVmLGZnJGE/NzAkamZuPzI=&url=http%3a%2f%2frepo.osgeo.org>  <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVUzODw4My9/NDsnOS9gbTQ5ODM5OC96YG5naH18e2w0PWtvPTBobDk6Pjs/MDloPDg7aGhsbTs4bTBsaz9sOjkxPWxoaGw5bC99NDg+Pzs6OT47MDkveGBtNDxIPDhkSGN5OTg/Pj46JDxIPDhkSGN4OTg/Pj46L3tqeX00WmZse2xnJ0JoZWx6emxJbX5tJ21sL2o0PDsvYW1lNDk=&url=http%3a%2f%2frepo.osgeo.org>  <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVs5MjYyOSV1PjEtMyVqZz4zMjkzMiVwamRtYnd2cWY+YGFhNzE3MmAxNDM1YmJlNjNhOzpiYTpiYjc6NGU6N2BiNTRiOjQyZiV3PjI0NTI6MTM0OzolcmpnPjY6VUZSV3FGMzEyMTswLjY6VUZSV3FFMzEyMTswJXFgc3c+UGxmcWZtLUhib2ZwcGZDZ3RnLWdmJWA+NjEla2dvPjM=&url=http%3a%2f%2frepo.osgeo.org>  <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVE3PDg8Nyt7MD8jPStkaTA9PDc9PCt+ZGpjbHl4f2gwbGw0Pms+O2g7NDs/aD84NT47PjloPj48O2g6PGw7OGxpbDg+aG44byt5MDw6Ozw8ODQ1OjsrfGRpMDg0QEc5bGFpPT85NDs4IDg0QEc5bGFoPT85NDs4K39ufXkwXmJof2hjI0ZsYWh+fmhNaXppI2loK24wOD8rZWlhMD0=&url=http%3a%2f%2frepo.osgeo.org>  and is made in conjunction with ImageN 0.9.0, ImageIO-Ext 2.0.0, GeoWebCache 1.28.0, and GeoServer 2.28.0.
	
	                This is a major update:
	
	                *       The library now requires Java 17, ending support for Java 11
	
	                *       Upgrade from Java Advanced Imaging Library 1.1.3 to Eclipse ImageN 0.9.0.
	
	                *       Library now provides a maven bill-of-materials import for both library modules and third-party-dependences making it considerably easier for downstream projects to synchronize dependences when upgrading GeoTools
	
	                *       For more information please see upgrade instructions <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVE3PDg8Nyt7MD8jPStkaTA9PDc9PCt+ZGpjbHl4f2gwNDk1bjo7P2s0bms0OTk9aTo+a287a2k8PzlvbjhuaTw9PjtoPj81NSt5MDw6Ozw8ODQ1OjsrfGRpMDg0QEc5bGFpPT85NDs4IDg0QEc5bGFoPT85NDs4K39ufXkwXmJof2hjI0ZsYWh+fmhNaXppI2loK24wOD8rZWlhMD0=&url=https%3a%2f%2fdocs.geotools.org%2fstable%2fuserguide%2fwelcome%2fupgrade.html>  in the user manual
	
	                Thanks to Jody Garnett (GeoCat) for making this release, Gabriel Roldan (Camptocamp) for all the build improvements, and Andrea Aime (GeoServer) for working so hard on the Eclipse ImageN migration.
	
	                These major library updates were undertaken as part of the GeoServer 3 activities, and we would like to the crowdfunding sponsors their financial support.
	
	                _______________________________________________
	                GeoTools-GT2-Users mailing list
	                Geo...@li... <mailto:Geo...@li...>  <mailto:Geo...@li... <mailto:Geo...@li...> >  <mailto:Geo...@li... <mailto:Geo...@li...>  <mailto:Geo...@li... <mailto:Geo...@li...> > > 
	                https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVA0Pzs/NCh4MzwgPihnajM+PzQ+Pyh9Z2lgb3p7fGszPjZvNj46OTw7OTc/Ozs4aDc+PDttO21oPDxrPmg7OGpvazdob283Pyh6Mz85ODw9PTg4PToof2dqMztPOzd4S1pmPjw8PD85IztPOzd4S1pnPjw8PD85KHxtfnozXWFrfGtgIEVvYmt9fWtOanlqIGprKG0zOzwoZmpiMz4=&url=https%3a%2f%2flists.sourceforge.net%2flists%2flistinfo%2fgeotools-gt2-users  <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVUzODw4My9/NDsnOS9gbTQ5ODM5OC96YG5naH18e2w0PG88aDw7OW05Pj5rPGs5MTgwMG8xOTs/MG87Pj86aD4/PD86bTtqOS99NDg+Pzs6OT47MDkveGBtNDxIPDhkSGN5OTg/Pj46JDxIPDhkSGN4OTg/Pj46L3tqeX00WmZse2xnJ0JoZWx6emxJbX5tJ21sL2o0PDsvYW1lNDk=&url=https%3a%2f%2flists.sourceforge.net%2flists%2flistinfo%2fgeotools-gt2-users>  <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVs5MjYyOSV1PjEtMyVqZz4zMjkzMiVwamRtYnd2cWY+Zmc0OmBnYDViNTA1NDdmMzMyNTQ6ZmIxYmcxNTJnNTMyNGJiNDU2NiV3PjI0NTI6MTM0OzolcmpnPjY6VUZSV3FGMzEyMTswLjY6VUZSV3FFMzEyMTswJXFgc3c+UGxmcWZtLUhib2ZwcGZDZ3RnLWdmJWA+NjEla2dvPjM=&url=https%3a%2f%2flists.sourceforge.net%2flists%2flistinfo%2fgeotools-gt2-users> 
	
	
	
	        _______________________________________________
	        GeoTools-GT2-Users mailing list
	        Geo...@li... <mailto:Geo...@li...>  <mailto:Geo...@li... <mailto:Geo...@li...> > 
	        https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVA0Pzs/NCh4MzwgPihnajM+PzQ+Pyh9Z2lgb3p7fGszPjZvNj46OTw7OTc/Ozs4aDc+PDttO21oPDxrPmg7OGpvazdob283Pyh6Mz85ODw9PTg4PToof2dqMztPOzd4S1pmPjw8PD85IztPOzd4S1pnPjw8PD85KHxtfnozXWFrfGtgIEVvYmt9fWtOanlqIGprKG0zOzwoZmpiMz4=&url=https%3a%2f%2flists.sourceforge.net%2flists%2flistinfo%2fgeotools-gt2-users  <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVUzODw4My9/NDsnOS9gbTQ5ODM5OC96YG5naH18e2w0PG88aDw7OW05Pj5rPGs5MTgwMG8xOTs/MG87Pj86aD4/PD86bTtqOS99NDg+Pzs6OT47MDkveGBtNDxIPDhkSGN5OTg/Pj46JDxIPDhkSGN4OTg/Pj46L3tqeX00WmZse2xnJ0JoZWx6emxJbX5tJ21sL2o0PDsvYW1lNDk=&url=https%3a%2f%2flists.sourceforge.net%2flists%2flistinfo%2fgeotools-gt2-users> 
	
	
	
	_______________________________________________
	GeoTools-GT2-Users mailing list
	Geo...@li... <mailto:Geo...@li...> 
	https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVA0Pzs/NCh4MzwgPihnajM+PzQ+Pyh9Z2lgb3p7fGszPjZvNj46OTw7OTc/Ozs4aDc+PDttO21oPDxrPmg7OGpvazdob283Pyh6Mz85ODw9PTg4PToof2dqMztPOzd4S1pmPjw8PD85IztPOzd4S1pnPjw8PD85KHxtfnozXWFrfGtgIEVvYmt9fWtOanlqIGprKG0zOzwoZmpiMz4=&url=https%3a%2f%2flists.sourceforge.net%2flists%2flistinfo%2fgeotools-gt2-users 
	


_______________________________________________
GeoTools-GT2-Users mailing list
Geo...@li...
https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVw4MzczOCR0PzAsMiRrZj8yMzgyMyRxa2VsY3Z3cGc/YTQ6NjAxZDMyMjc1YzEwZjdjZ2RmNDJhZjVmOzQzYzQxY2Q6NjczMiR2PzM1NDA2MDUyMzQkc2tmPzdDNEAxY2BLMjA2Mjs1LzdDNEAxY2BIMjA2Mjs1JHBhcnY/UW1ncGdsLEljbmdxcWdCZnVmLGZnJGE/NzAkamZuPzI=&url=https%3a%2f%2flists.sourceforge.net%2flists%2flistinfo%2fgeotools-gt2-users 

Re: [Geotools-gt2-users] GeoTools 34.0 released for Java 17 with Eclipse ImageN processing engine

[Kalesse S. <Soe...@dw...>]

Hi Jody, 

I have made that PR for ImageN now, see https://github.com/eclipse-imagen/imagen/pull/121. I have branches on my fork for GeoTools and GeoServer as well, but I would probably have to wait for a new ImageN release and make some JIRA tickets first as well right?

All of ImageN compiled and test-cases run successfully. I also tried locally and was able to verify that GeoTools and GeoServer are using the new scheme correctly. Infact it was one test-case in GeoTools that failed with the new lib, and was repaired by also switching the naming scheme there. So we know that it should work once I make my PRs for GeoTools and GeoServer. 

Thanks!
Sören

-----Ursprüngliche Nachricht-----
Von: Kalesse Sören <Soe...@dw...> 
Gesendet: Donnerstag, 6. November 2025 12:01
An: 'Jody Garnett' <jod...@gm...>
Cc: GeoTools Users <geo...@li...>
Betreff: Re: [Geotools-gt2-users] GeoTools 34.0 released for Java 17 with Eclipse ImageN processing engine

Hi Jody, 

I cannot judge about that.  I have done a quick check and it seems GeoTools has two operators (in gt-coverage and gt-process-raster) and GeoServer has one in wps-download. I can make Prs for those too if you want. 

Still, I think that this renaming task of the registry files is unrelated to the actual problem. I hope that we can agree on that. 

Btw, out of curiosity I have checked JAI-EXT and it turns out that it has the same problem. I have looked at GeoServer 2.27.3 that still uses JAI and JAI-EXT:

  - jt-jiffle and jt-vectorize have invalid ServiceLoader interface definitions similar too ImageN. Therefore these are ignored by JAI (Jai-ext seems to use the JAI operation registry)
  - jt-crop that the correct ServiceLoader interface, so in theory we would expect it to crash because it has both registryFile AND ServiceLoader. But for some extremely odd reasons, in jt-crop the registryFile is called registryFile.jaiext. Therefore, here in this case the registryFile is ignored by JAI (it does not know anything about the jaiext file extension).

So it looks these problems have been ported over from JAI-EXT, but since in any case only one of the registration schemes actually works, the problem is hidden. 

Sören

-----Ursprüngliche Nachricht-----
Von: Jody Garnett <jod...@gm...> 
Gesendet: Mittwoch, 5. November 2025 16:16
An: Kalesse Sören <ska...@ex...>
Cc: GeoTools Users <geo...@li...>
Betreff: Re: [Geotools-gt2-users] GeoTools 34.0 released for Java 17 with Eclipse ImageN processing engine

Because ImageN is so new I do it think other projects have implemented operators yet to be registered?


- -

Jody Garnett


On Wed, Nov 5, 2025 at 4:08 AM Kalesse Sören <Soe...@dw... <mailto:Soe...@dw...> > wrote:


	Hi again, 
	
	after reading my previous e-mail I believe maybe an example would make it clearer. Let's go by the ImageN crop example (although the same argumentation is valid also for the other two (jiffle and vectorize)).
	
	So let's assume at first that both ImageN and JAI work well individually with the two mechanisms of registration: the (JAI/ImageN) registryFile and Java ServiceLoader. 
	
	Then, let's look at crops's resources on the ImageN main branch. We have: 
	
	RegistryFile: 
	modules/crop/src/main/resources/META-INF/registryFile.jai (stripped of comments):
	---------------------------------------------------------------------------------------------------------------------------
	
	  descriptor  org.eclipse.imagen.media.crop.CropDescriptor
	  rendered  org.eclipse.imagen.media.crop.CropCRIF     org.eclipse.imagen.media  Crop   Crop
	
	and we have the Java ServiceLoader definition: 
	modules/crop/src/main/resources/META-INF/services/javax.media.jai.OperationRegistrySpi:
	---------------------------------------------------------------------------------------------------------------------------
	
	  org.eclipse.imagen.media.crop.CropSpi
	
	The most obvious thing here is that the Java ServiceLoader definition is wrong, because CropSpi does not implement the javax.media.jai.OperationRegistrySpi interface. 
	
	If we use only ImageN in our application, we will not notice the problem. ImageN is simply ignoring that ServiceLoader definition, because the interface is unknown to ImageN. BUT this will crash JAI, because ServiceLoader in JAI throws a ClassCastException given that definition. 
	
	Now, as proposed, we could (and should) fix this by renaming modules/crop/src/main/resources/META-INF/services/javax.media.jai.OperationRegistrySpi to modules/crop/src/main/resources/META-INF/services/org.eclipse.imagen.OperationRegistrySpi. 
	
	That now pleases JAI, because JAI does not know that new (ImageN) interface. Great! So now all should be good? NO! Because now we have this: 
	
	RegistryFile: 
	modules/crop/src/main/resources/META-INF/registryFile.jai (stripped of comments):
	---------------------------------------------------------------------------------------------------------------------------
	
	  descriptor  org.eclipse.imagen.media.crop.CropDescriptor
	  rendered  org.eclipse.imagen.media.crop.CropCRIF     org.eclipse.imagen.media  Crop   Crop
	
	and we have the fixed Java ServiceLoader definition: 
	modules/crop/src/main/resources/META-INF/services/org.eclipse.imagen.OperationRegistrySpi:
	---------------------------------------------------------------------------------------------------------------------------
	
	  org.eclipse.imagen.media.crop.CropSpi
	
	Technically everything looks fine, BUT ImageN will no longer initialize, because we apply the two types of registration schemes at once. With this, what happens is that the Crop operation gets registered once using registryFile, and then ImageN tries again using ServiceLoader, because now the definition is no longer ignored. 
	
	And this is the core problem. The wrong ServiceLoader definition files on main branch are simply hiding the problem, because ImageN will ignore them, but if we fix them to be correct, then ImageN will fail to initialize, because Crop is already there. The same argumentation goes for jiffle and vectorize, because those two also have (wrong) Java ServiceLoader  definitions. So fixing them too, will result in the same problem of failing initialization. 
	
	And last but not least, the reason for all other libraries to not fail, is that none of the other libraries have Java ServiceLoader definitions at all. 
	
	That as the reason why my initial PR#119 simply removed the three ServiceLoader definitions from crop, jiffle and vectorize. 
	
	Does that better illustrate the problem?
	
	
	==== Now another topic: should we rename registryFile.jai --> registryFile.imagen =======
	
	Maybe it should be done to make a more explicit distinction between ImageN and JAI registration. It should be noted though that the renaming is a breaking change for everyone using ImageN, because for example GeoTools/GeoServer and other applications that have their own ImageN operators implemented will have to switch to that new naming scheme. But, yeah, maybe it's worth the effort - I don't know. 
	
	What I want to emphasize though is that I have tried locally with the wrong ServiceLoader definitions removed from ImageN. I ran GeoServer 2.28.0 that is now based on ImageN with some of our custom JAI operators that are still based on JAI 1.1.3. First, now both ImageN and JAI initialized correctly and I was able to successfully run WMS queries (which should prove that ImageN is working correctly) and I could also verify that our own custom JAI operators are working as well. 
	
	My assumption based on that test is that it does not seem to matter too much how these registry files are named. It seems both, ImageN as well as JAI can cope with either and probably filtering the operations by the definitions they support. 
	
	Of course I can currently not prove that by the same names, both work correctly, but that was my first try. Maybe a JAI/ImageN interoperability Test-case could prove. I don't know. 
	
	But to summarize the current discussion. Whether or not the registry files should be renamed, does not relate to that other issue I presented in the first part of the e-mail.
	
	I hope, by this report, my argumentation becomes clearer. Sorry for that long wall of text.
	Thanks!
	Sören
	
	
	-----Ursprüngliche Nachricht-----
	Von: Kalesse Sören <Soe...@dw... <mailto:Soe...@dw...> > 
	Gesendet: Mittwoch, 5. November 2025 10:55
	An: Jody Garnett <jod...@gm... <mailto:jod...@gm...> >
	Cc: GeoTools Users <geo...@li... <mailto:geo...@li...> >
	Betreff: Re: [Geotools-gt2-users] GeoTools 34.0 released for Java 17 with Eclipse ImageN processing engine
	
	Hi Jody, 
	
	Ok, I can make a PR, but with that all renaming happening, it'll be quite some big change and probably PRs needed for GeoTools and GeoServer as well, right? ... and all other libs that are already using ImageN. 
	
	I am very sorry but I really need to emphasize again, that the registry files are not the problem here! ImageN and JAI seem to be able to cope with them even though they have the same name (registryFile.jai). I have tested it locally running ImageN and JAI in the same application and they do not interfere at all. I was able to run GeoServer 2.28.0 that uses ImageN and still use our own JAI operators based on JAI core 1.1.3 without any problems at all. 
	
	Really, the problem here are those invalid Java ServiceLoader definitions. 
	
	    modules/crop/src/main/resources/META-INF/services/javax.media.jai.OperationRegistrySpi
	    modules/jiffle/jt-jiffle-op/src/main/resources/META-INF/services/javax.media.jai.OperationsRegistrySpi
	    modules/vectorize/src/main/resources/META-INF/services/javax.media.jai.OperationsRegistrySpi
	
	The first one (crop) tries registering at JAI operation registry, which is wrong. This will cause a ClassCastException in JAI. 
	The other two (jiffle and vectorize) try the same thing but even worse, the interface names are wrong --> OperationsRegistrySpi vs. OperationRegistrySpi. So these two will simply be ignored, because that interface does not exist. 
	
	I could fix the names of the ServiceLoader definitions --> org.eclipse.imagen.OperationRegistrySpi. That would please Java at least. So that's good, but ImageN will no longer work, because as mentioned earlier, ImageN registry cannot currently not deal with two mechanisms being in place at the same time. Fixing the names will do this (Example taken from the Jiffle test cases):
	
	[ERROR] org.eclipse.imagen.media.jiffleop.NoSourceTest.createSequentialImage -- Time elapsed: 0 s <<< ERROR!
	java.lang.NoClassDefFoundError: Could not initialize class org.eclipse.imagen.ImageN
	        at org.eclipse.imagen.media.jiffleop.NoSourceTest.reset(NoSourceTest.java:82)
	        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	        at java.base/java.lang.reflect.Method.invoke(Method.java:580)
	        at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
	        at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	        at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
	        at org.junit.internal.runners.statements.RunAfters.invokeMethod(RunAfters.java:46)
	        at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33)
	        at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
	        at org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
	Caused by: java.lang.ExceptionInInitializerError: Exception java.lang.IllegalArgumentException: A descriptor is already registered against the name "Jiffle" under registry mode "rendered" [in thread "main"]
	        at org.eclipse.imagen.DescriptorCache.addDescriptor(DescriptorCache.java:144)
	        at org.eclipse.imagen.OperationRegistry.registerDescriptor(OperationRegistry.java:580)
	        at org.eclipse.imagen.ThreadSafeOperationRegistry.registerDescriptor(ThreadSafeOperationRegistry.java:156)
	        at org.eclipse.imagen.media.jiffleop.JiffleSpi.updateRegistry(JiffleSpi.java:73)
	        at org.eclipse.imagen.OperationRegistry.registerServices(OperationRegistry.java:1556)
	        at org.eclipse.imagen.ThreadSafeOperationRegistry.registerServices(ThreadSafeOperationRegistry.java:529)
	        at org.eclipse.imagen.OperationRegistry.initializeRegistry(OperationRegistry.java:311)
	        at org.eclipse.imagen.ImageN.<clinit>(ImageN.java:351)
	
	The descriptor cache does not allow an operation to be registered twice. That is why I am saying that fixing the ServiceLoader definitions won't help at all. The only options I see is:
	
	 1. make descriptor cache support registry definitions coming from multiple places at the same time 
	   ---> I am not sure if that's really a good idea
	 2. remove the ServiceLoader definitions from those three libs
	
	I am wondering anyway, why is it that only those three libs do have ServiceLoader files at all? What about the other libs? Not a single other lib has any ServiceLoader definition at all.
	
	My PR#119 did exactly that. It removed the ServiceLoader definitions from those three libs. That's all it did and that fixed it all. No renaming of registryFile.jai required. 
	
	To summarize: 
	============
	
	 I can make a PR that renames all registryFile.jai --> registryFile.imagen and changes the ImageN registry to use those instead - no problem. 
	
	But that will not help with the initial problem, we need to deal with those ServiceLoader files - fixing their names to match the correct interface will not help. On the contrary, it will make it worse, because ImageN will no longer initialize, because it cannot handle both (registryFile.[jai|imagen] and ServiceLoader) at the same time.
	
	My proposal is to go by the initial PR and remove the ServiceLoader files all together for these three modules that have them (crop, jiffle, vectorize).
	
	What do you think?
	Thanks
	Sören
	
	
	-----Ursprüngliche Nachricht-----
	Von: Jody Garnett <jod...@gm... <mailto:jod...@gm...> > 
	Gesendet: Mittwoch, 5. November 2025 02:47
	An: Kalesse Sören <ska...@ex... <mailto:ska...@ex...> >
	Cc: GeoTools Users <geo...@li... <mailto:geo...@li...> >
	Betreff: Re: [Geotools-gt2-users] GeoTools 34.0 released for Java 17 with Eclipse ImageN processing engine
	
	So ideally we should fix the invalid definitions, and rename the files to end with “imagen”.
	
	If you make a PR I am willing to do a 0.9.1 relate; and Gabe offered to make a geotools release on schedule next week. 
	
	- -
	
	Jody Garnett
	
	
	On Mon, Nov 3, 2025 at 11:12 PM Kalesse Sören <Soe...@dw... <mailto:Soe...@dw...>  <mailto:Soe...@dw... <mailto:Soe...@dw...> > > wrote:
	
	
	        Hi Andrea, 
	
	        That's exactly my point. I  do assume that it was not intended for these two to coexist, but it should just work fine because there are two different registries and the operations interfaces are different, so in theory these two do not collide at all. That gives all users a good "workaround" to live with until applications and libraries have succeeded to migrate. 
	
	        And that's also exactly where my PR comes in. The three mentioned ImageN libraries (and only those three!) contain ServiceLoader definitions that are wrong. The register the ImageN operations at the JAI registry. That leads to class cast exceptions (wrong interfaces). That's the point that must definitely be fixed whatsoever.
	
	        Now that fixed, here arises the second aspect: Right now you cannot mix standard ImageN and ServiceLoader registration. ImageN does not support that. It will fail to initialize if one operation had already been registered by that other means. So you must decide: either support multiple ways of registration in the ImageN core or decide upon one and let it go. 
	
	        Therefore my PR removes the three ServiceLoader definitions: 1) because they were wrong and 2) because that is the least invasive fix to make ImageN initialize correctly. The PR#119 was tested locally running GeoServer 2.2.8.0 and another application that uses JAI and it worked just fine.
	
	        I hope you can agree that this is a proper fix and should be part in one of the next releases. For us it is a show-stopper for upgrading to GT 33.x / GS 2.28.x. 
	
	        Thanks!
	        Sören
	
	        -----Ursprüngliche Nachricht-----
	        Von: Andrea Aime <and...@ge... <mailto:and...@ge...>  <mailto:and...@ge... <mailto:and...@ge...> > > 
	        Gesendet: Freitag, 31. Oktober 2025 15:25
	        An: Kalesse Sören <ska...@ex... <mailto:ska...@ex...>  <mailto:ska...@ex... <mailto:ska...@ex...> > >
	        Cc: GeoTools Users <geo...@li... <mailto:geo...@li...>  <mailto:geo...@li... <mailto:geo...@li...> > >
	        Betreff: Re: [Geotools-gt2-users] GeoTools 34.0 released for Java 17 with Eclipse ImageN processing engine
	
	        Hi,
	        I second what Jody said, there was no plan to make the coexist, it's an upgrade path.
	        However... I believe that a coexistence could be possible, the java packages
	        are different, so by having ImageN use a different file name for the registry files in META-INF, 
	        from registryFile.jai to registryFile.imagen, a coexistence might be possible, even if likely
	        wasteful (two separate image processing caches in memory are not the greatest of ideas).
	
	        A coexistence is just not in our plans, but since ImageN is not yet available as 1.0, if DWD wants
	        to put the development effort to get it done, I would not be against it.
	        I see this applicable to the GeoServer 3.0 series.
	
	        I would recommend switching existing software to ImageN though, we prepared migration scripts
	        that should help in the endeavor.
	
	        Regards,
	
	        Andrea Aime
	
	
	
	
	        ==
	
	
	        GeoServer Professional Services from the experts!
	
	        Visit http://bit.ly/gs-services-us <http://bit.ly/gs-services-us>  for more information.
	
	
	
	        ==
	
	        Ing. Andrea Aime 
	        @geowolf
	        Technical Lead
	
	
	
	        GeoSolutions Group
	        phone: +39 0584 962313
	
	        fax:     +39 0584 1660272
	
	        mob:   +39  339 8844549
	
	
	        https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVA0Pzs/NCh4MzwgPihnajM+PzQ+Pyh9Z2lgb3p7fGszP2s2ODk/Nm04PGs2b29vODk6Oj1tNj5rOG9tbG1qOG9sbDtqaG06aCh6Mz85ODw9PTg4PToof2dqMztPOzd4S1pmPjw8PD85IztPOzd4S1pnPjw8PD85KHxtfnozXWFrfGtgIEVvYmt9fWtOanlqIGprKG0zOzwoZmpiMz4=&url=https%3a%2f%2fwww.geosolutionsgroup.com%2f  <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVUzODw4My9/NDsnOS9gbTQ5ODM5OC96YG5naH18e2w0bTs+Ozo+bDtqajtqMDsxPT1qOmg5PD49MDE+Omwwam0xMWprbzE4Oy99NDg+Pzs6OT47MDkveGBtNDxIPDhkSGN5OTg/Pj46JDxIPDhkSGN4OTg/Pj46L3tqeX00WmZse2xnJ0JoZWx6emxJbX5tJ21sL2o0PDsvYW1lNDk=&url=https%3a%2f%2fwww.geosolutionsgroup.com%2f>  <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVs5MjYyOSV1PjEtMyVqZz4zMjkzMiVwamRtYnd2cWY+Ozs6OjQ2MTAyM2Y1MDU1NjQxZzFiOzUwMWA0ZjAwZzQwNzA6ZTY2NCV3PjI0NTI6MTM0OzolcmpnPjY6VUZSV3FGMzEyMTswLjY6VUZSV3FFMzEyMTswJXFgc3c+UGxmcWZtLUhib2ZwcGZDZ3RnLWdmJWA+NjEla2dvPjM=&url=https%3a%2f%2fwww.geosolutionsgroup.com%2f> 
	
	        https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVA0Pzs/NCh4MzwgPihnajM+PzQ+Pyh9Z2lgb3p7fGszNmpqbG1sO2g5ajhsOT1rOjo9PG0+PW9sbWw2PW06PW06Oz88ajo5aCh6Mz85ODw9PTg4PToof2dqMztPOzd4S1pmPjw8PD85IztPOzd4S1pnPjw8PD85KHxtfnozXWFrfGtgIEVvYmt9fWtOanlqIGprKG0zPTkoZmpiMz4=&url=http%3a%2f%2ftwitter.com%2fgeosolutions_it  <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVUzODw4My9/NDsnOS9gbTQ5ODM5OC96YG5naH18e2w0PWg9bW1obzFqaGpsPz5sbToxa2xrPjA9PW06PDBobDk5bG09a2s5bS99NDg+Pzs6OT47MDkveGBtNDxIPDhkSGN5OTg/Pj46JDxIPDhkSGN4OTg/Pj46L3tqeX00WmZse2xnJ0JoZWx6emxJbX5tJ21sL2o0Oj4vYW1lNDk=&url=http%3a%2f%2ftwitter.com%2fgeosolutions_it>  <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVs5MjYyOSV1PjEtMyVqZz4zMjkzMiVwamRtYnd2cWY+MDplNTQ7ZzM6YTozNmU7NGY1OjtmZzdnYTIzYjIwYmJmNGU2MDBgZiV3PjI0NTI6MTM0OzolcmpnPjY6VUZSV3FGMzEyMTswLjY6VUZSV3FFMzEyMTswJXFgc3c+UGxmcWZtLUhib2ZwcGZDZ3RnLWdmJWA+MDQla2dvPjM=&url=http%3a%2f%2ftwitter.com%2fgeosolutions_it> 
	
	        -------------------------------------------------------
	
	
	        Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia.
	
	        This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail
	
	
	
	        On Thu, Oct 30, 2025 at 5:29 PM Kalesse Sören <Soe...@dw... <mailto:Soe...@dw...>  <mailto:Soe...@dw... <mailto:Soe...@dw...> >  <mailto:Soe...@dw... <mailto:Soe...@dw...>  <mailto:Soe...@dw... <mailto:Soe...@dw...> > > > wrote:
	
	
	                Hi,
	
	                thanks for the new release! We have noticed a problem though, that deals with environments where GeoTools (and now ImageN) and JAI are used at the same time. I have documented the issue at https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVA0Pzs/NCh4MzwgPihnajM+PzQ+Pyh9Z2lgb3p7fGszb2tqOmw5bDo6Nz45OWhoPTc7PjY/PT89ajo+Pjo5a285azttPD8/bSh6Mz85ODw9PTg4PToof2dqMztPOzd4S1pmPjw8PD85IztPOzd4S1pnPjw8PD85KHxtfnozXWFrfGtgIEVvYmt9fWtOanlqIGprKG0zOzwoZmpiMz4=&url=https%3a%2f%2fgithub.com%2feclipse-imagen%2fimagen%2fissues%2f118  <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVUzODw4My9/NDsnOS9gbTQ5ODM5OC96YG5naH18e2w0MDs9azlvOT0+bT1oa2s7aGgwamxqPzAwbDs8OmxrPj88MD4+azo9PS99NDg+Pzs6OT47MDkveGBtNDxIPDhkSGN5OTg/Pj46JDxIPDhkSGN4OTg/Pj46L3tqeX00WmZse2xnJ0JoZWx6emxJbX5tJ21sL2o0PDsvYW1lNDk=&url=https%3a%2f%2fgithub.com%2feclipse-imagen%2fimagen%2fissues%2f118>  <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVs5MjYyOSV1PjEtMyVqZz4zMjkzMiVwamRtYnd2cWY+NDE1YDExNTs1ZjpnNTEwZzIyZmU7NmE7O2ZmZWFgYjJnMzA0NmY1NSV3PjI0NTI6MTM0OzolcmpnPjY6VUZSV3FGMzEyMTswLjY6VUZSV3FFMzEyMTswJXFgc3c+UGxmcWZtLUhib2ZwcGZDZ3RnLWdmJWA+NjEla2dvPjM=&url=https%3a%2f%2fgithub.com%2feclipse-imagen%2fimagen%2fissues%2f118>  and there is a PR attached https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVA0Pzs/NCh4MzwgPihnajM+PzQ+Pyh9Z2lgb3p7fGszOmxrOTdqams6Ozk/OTs3PGg7PTo9Oj1qN2s2Nm84Pms2OTw2Pm0/PSh6Mz85ODw9PTg4PToof2dqMztPOzd4S1pmPjw8PD85IztPOzd4S1pnPjw8PD85KHxtfnozXWFrfGtgIEVvYmt9fWtOanlqIGprKG0zOzwoZmpiMz4=&url=https%3a%2f%2fgithub.com%2feclipse-imagen%2fimagen%2fpull%2f119  <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVUzODw4My9/NDsnOS9gbTQ5ODM5OC96YG5naH18e2w0ajxsOGtoaj9sbzs9ODhvOG1qaDFqbTowPTg8Pzs4PWhoOzs/OT1vPi99NDg+Pzs6OT47MDkveGBtNDxIPDhkSGN5OTg/Pj46JDxIPDhkSGN4OTg/Pj46L3tqeX00WmZse2xnJ0JoZWx6emxJbX5tJ21sL2o0PDsvYW1lNDk=&url=https%3a%2f%2fgithub.com%2feclipse-imagen%2fimagen%2fpull%2f119>  <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVs5MjYyOSV1PjEtMyVqZz4zMjkzMiVwamRtYnd2cWY+ZmVgNDplZTRlYWY0NWUzZ2BlMjA3M2UzZTU1MGdmNjQ6Zzc1MGdnNyV3PjI0NTI6MTM0OzolcmpnPjY6VUZSV3FGMzEyMTswLjY6VUZSV3FFMzEyMTswJXFgc3c+UGxmcWZtLUhib2ZwcGZDZ3RnLWdmJWA+NjEla2dvPjM=&url=https%3a%2f%2fgithub.com%2feclipse-imagen%2fimagen%2fpull%2f119> . 
	
	                I wonder if there's any chance the problem can be solved soon as it currently prevents us from upgrading to GeoServer 2.28.x. 
	
	                Thanks and Best Regards
	                Sören 
	
	                -----Ursprüngliche Nachricht-----
	                Von: Jody Garnett <jod...@gm... <mailto:jod...@gm...>  <mailto:jod...@gm... <mailto:jod...@gm...> >  <mailto:jod...@gm... <mailto:jod...@gm...>  <mailto:jod...@gm... <mailto:jod...@gm...> > > > 
	                Gesendet: Mittwoch, 22. Oktober 2025 20:57
	                An: GeoTools Users <geo...@li... <mailto:geo...@li...>  <mailto:geo...@li... <mailto:geo...@li...> >  <mailto:geo...@li... <mailto:geo...@li...>  <mailto:geo...@li... <mailto:geo...@li...> > > >
	                Betreff: [Geotools-gt2-users] GeoTools 34.0 released for Java 17 with Eclipse ImageN processing engine
	
	                The GeoTools team is pleased to announce the release <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVE3PDg8Nyt7MD8jPStkaTA9PDc9PCt+ZGpjbHl4f2gwazk7bj5uNG8+Oj5saW5ub2s4NT5raW5paWg+bGw+bjs0OT41azw9PCt5MDw6Ozw8ODQ1OjsrfGRpMDg0QEc5bGFpPT85NDs4IDg0QEc5bGFoPT85NDs4K39ufXkwXmJof2hjI0ZsYWh+fmhNaXppI2loK24wNT0rZWlhMD0=&url=https%3a%2f%2fgeotoolsnews.blogspot.com%2f2025%2f10%2fgeotools-340-release.html>  of the latest stable version of GeoTools 34.0 <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVE3PDg8Nyt7MD8jPStkaTA9PDc9PCt+ZGpjbHl4f2gwbDU1azU5OWhpaT9sbG5rPTRuPmw9ND9rOWg7NGhuPDU9Oz88aWtsOit5MDw6Ozw8ODQ1OjsrfGRpMDg0QEc5bGFpPT85NDs4IDg0QEc5bGFoPT85NDs4K39ufXkwXmJof2hjI0ZsYWh+fmhNaXppI2loK24wOD8rZWlhMD0=&url=https%3a%2f%2fsourceforge.net%2fprojects%2fgeotools%2ffiles%2fGeoTools%252034%2520Releases%2f34.0%2f> . This release is available from the repo.osgeo.org <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVw4MzczOCR0PzAsMiRrZj8yMzgyMyRxa2VsY3Z3cGc/ZGA6MTE6NGEzZzthNTIwZ2AzOjFkNjQxNjVgMjsxOzQ1NWcwMTc1OiR2PzM1NDAxNzc6MzIkc2tmPzdDN0RFbXNxMjM2OzQ6LzdDN0RFbXN2MjM2OzQ6JHBhcnY/UW1ncGdsLEljbmdxcWdCZnVmLGZnJGE/NzAkamZuPzI=&url=http%3a%2f%2frepo.osgeo.org>  <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVUzODw4My9/NDsnOS9gbTQ5ODM5OC96YG5naH18e2w0PWtvPTBobDk6Pjs/MDloPDg7aGhsbTs4bTBsaz9sOjkxPWxoaGw5bC99NDg+Pzs6OT47MDkveGBtNDxIPDhkSGN5OTg/Pj46JDxIPDhkSGN4OTg/Pj46L3tqeX00WmZse2xnJ0JoZWx6emxJbX5tJ21sL2o0PDsvYW1lNDk=&url=http%3a%2f%2frepo.osgeo.org>  <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVs5MjYyOSV1PjEtMyVqZz4zMjkzMiVwamRtYnd2cWY+YGFhNzE3MmAxNDM1YmJlNjNhOzpiYTpiYjc6NGU6N2BiNTRiOjQyZiV3PjI0NTI6MTM0OzolcmpnPjY6VUZSV3FGMzEyMTswLjY6VUZSV3FFMzEyMTswJXFgc3c+UGxmcWZtLUhib2ZwcGZDZ3RnLWdmJWA+NjEla2dvPjM=&url=http%3a%2f%2frepo.osgeo.org>  <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVE3PDg8Nyt7MD8jPStkaTA9PDc9PCt+ZGpjbHl4f2gwbGw0Pms+O2g7NDs/aD84NT47PjloPj48O2g6PGw7OGxpbDg+aG44byt5MDw6Ozw8ODQ1OjsrfGRpMDg0QEc5bGFpPT85NDs4IDg0QEc5bGFoPT85NDs4K39ufXkwXmJof2hjI0ZsYWh+fmhNaXppI2loK24wOD8rZWlhMD0=&url=http%3a%2f%2frepo.osgeo.org>  and is made in conjunction with ImageN 0.9.0, ImageIO-Ext 2.0.0, GeoWebCache 1.28.0, and GeoServer 2.28.0.
	
	                This is a major update:
	
	                *       The library now requires Java 17, ending support for Java 11
	
	                *       Upgrade from Java Advanced Imaging Library 1.1.3 to Eclipse ImageN 0.9.0.
	
	                *       Library now provides a maven bill-of-materials import for both library modules and third-party-dependences making it considerably easier for downstream projects to synchronize dependences when upgrading GeoTools
	
	                *       For more information please see upgrade instructions <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVE3PDg8Nyt7MD8jPStkaTA9PDc9PCt+ZGpjbHl4f2gwNDk1bjo7P2s0bms0OTk9aTo+a287a2k8PzlvbjhuaTw9PjtoPj81NSt5MDw6Ozw8ODQ1OjsrfGRpMDg0QEc5bGFpPT85NDs4IDg0QEc5bGFoPT85NDs4K39ufXkwXmJof2hjI0ZsYWh+fmhNaXppI2loK24wOD8rZWlhMD0=&url=https%3a%2f%2fdocs.geotools.org%2fstable%2fuserguide%2fwelcome%2fupgrade.html>  in the user manual
	
	                Thanks to Jody Garnett (GeoCat) for making this release, Gabriel Roldan (Camptocamp) for all the build improvements, and Andrea Aime (GeoServer) for working so hard on the Eclipse ImageN migration.
	
	                These major library updates were undertaken as part of the GeoServer 3 activities, and we would like to the crowdfunding sponsors their financial support.
	
	                _______________________________________________
	                GeoTools-GT2-Users mailing list
	                Geo...@li... <mailto:Geo...@li...>  <mailto:Geo...@li... <mailto:Geo...@li...> >  <mailto:Geo...@li... <mailto:Geo...@li...>  <mailto:Geo...@li... <mailto:Geo...@li...> > > 
	                https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVA0Pzs/NCh4MzwgPihnajM+PzQ+Pyh9Z2lgb3p7fGszPjZvNj46OTw7OTc/Ozs4aDc+PDttO21oPDxrPmg7OGpvazdob283Pyh6Mz85ODw9PTg4PToof2dqMztPOzd4S1pmPjw8PD85IztPOzd4S1pnPjw8PD85KHxtfnozXWFrfGtgIEVvYmt9fWtOanlqIGprKG0zOzwoZmpiMz4=&url=https%3a%2f%2flists.sourceforge.net%2flists%2flistinfo%2fgeotools-gt2-users  <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVUzODw4My9/NDsnOS9gbTQ5ODM5OC96YG5naH18e2w0PG88aDw7OW05Pj5rPGs5MTgwMG8xOTs/MG87Pj86aD4/PD86bTtqOS99NDg+Pzs6OT47MDkveGBtNDxIPDhkSGN5OTg/Pj46JDxIPDhkSGN4OTg/Pj46L3tqeX00WmZse2xnJ0JoZWx6emxJbX5tJ21sL2o0PDsvYW1lNDk=&url=https%3a%2f%2flists.sourceforge.net%2flists%2flistinfo%2fgeotools-gt2-users>  <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVs5MjYyOSV1PjEtMyVqZz4zMjkzMiVwamRtYnd2cWY+Zmc0OmBnYDViNTA1NDdmMzMyNTQ6ZmIxYmcxNTJnNTMyNGJiNDU2NiV3PjI0NTI6MTM0OzolcmpnPjY6VUZSV3FGMzEyMTswLjY6VUZSV3FFMzEyMTswJXFgc3c+UGxmcWZtLUhib2ZwcGZDZ3RnLWdmJWA+NjEla2dvPjM=&url=https%3a%2f%2flists.sourceforge.net%2flists%2flistinfo%2fgeotools-gt2-users> 
	
	
	
	        _______________________________________________
	        GeoTools-GT2-Users mailing list
	        Geo...@li... <mailto:Geo...@li...>  <mailto:Geo...@li... <mailto:Geo...@li...> > 
	        https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVA0Pzs/NCh4MzwgPihnajM+PzQ+Pyh9Z2lgb3p7fGszPjZvNj46OTw7OTc/Ozs4aDc+PDttO21oPDxrPmg7OGpvazdob283Pyh6Mz85ODw9PTg4PToof2dqMztPOzd4S1pmPjw8PD85IztPOzd4S1pnPjw8PD85KHxtfnozXWFrfGtgIEVvYmt9fWtOanlqIGprKG0zOzwoZmpiMz4=&url=https%3a%2f%2flists.sourceforge.net%2flists%2flistinfo%2fgeotools-gt2-users  <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVUzODw4My9/NDsnOS9gbTQ5ODM5OC96YG5naH18e2w0PG88aDw7OW05Pj5rPGs5MTgwMG8xOTs/MG87Pj86aD4/PD86bTtqOS99NDg+Pzs6OT47MDkveGBtNDxIPDhkSGN5OTg/Pj46JDxIPDhkSGN4OTg/Pj46L3tqeX00WmZse2xnJ0JoZWx6emxJbX5tJ21sL2o0PDsvYW1lNDk=&url=https%3a%2f%2flists.sourceforge.net%2flists%2flistinfo%2fgeotools-gt2-users> 
	
	
	
	_______________________________________________
	GeoTools-GT2-Users mailing list
	Geo...@li... <mailto:Geo...@li...> 
	https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVA0Pzs/NCh4MzwgPihnajM+PzQ+Pyh9Z2lgb3p7fGszPjZvNj46OTw7OTc/Ozs4aDc+PDttO21oPDxrPmg7OGpvazdob283Pyh6Mz85ODw9PTg4PToof2dqMztPOzd4S1pmPjw8PD85IztPOzd4S1pnPjw8PD85KHxtfnozXWFrfGtgIEVvYmt9fWtOanlqIGprKG0zOzwoZmpiMz4=&url=https%3a%2f%2flists.sourceforge.net%2flists%2flistinfo%2fgeotools-gt2-users 
	


_______________________________________________
GeoTools-GT2-Users mailing list
Geo...@li...
https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVw4MzczOCR0PzAsMiRrZj8yMzgyMyRxa2VsY3Z3cGc/YTQ6NjAxZDMyMjc1YzEwZjdjZ2RmNDJhZjVmOzQzYzQxY2Q6NjczMiR2PzM1NDA2MDUyMzQkc2tmPzdDNEAxY2BLMjA2Mjs1LzdDNEAxY2BIMjA2Mjs1JHBhcnY/UW1ncGdsLEljbmdxcWdCZnVmLGZnJGE/NzAkamZuPzI=&url=https%3a%2f%2flists.sourceforge.net%2flists%2flistinfo%2fgeotools-gt2-users 

Re: [Geotools-gt2-users] GeoTools 34.0 released for Java 17 with Eclipse ImageN processing engine

[Kalesse S. <Soe...@dw...>]

Hi Jody, 

I cannot judge about that.  I have done a quick check and it seems GeoTools has two operators (in gt-coverage and gt-process-raster) and GeoServer has one in wps-download. I can make Prs for those too if you want. 

Still, I think that this renaming task of the registry files is unrelated to the actual problem. I hope that we can agree on that. 

Btw, out of curiosity I have checked JAI-EXT and it turns out that it has the same problem. I have looked at GeoServer 2.27.3 that still uses JAI and JAI-EXT:

  - jt-jiffle and jt-vectorize have invalid ServiceLoader interface definitions similar too ImageN. Therefore these are ignored by JAI (Jai-ext seems to use the JAI operation registry)
  - jt-crop that the correct ServiceLoader interface, so in theory we would expect it to crash because it has both registryFile AND ServiceLoader. But for some extremely odd reasons, in jt-crop the registryFile is called registryFile.jaiext. Therefore, here in this case the registryFile is ignored by JAI (it does not know anything about the jaiext file extension).

So it looks these problems have been ported over from JAI-EXT, but since in any case only one of the registration schemes actually works, the problem is hidden. 

Sören

-----Ursprüngliche Nachricht-----
Von: Jody Garnett <jod...@gm...> 
Gesendet: Mittwoch, 5. November 2025 16:16
An: Kalesse Sören <ska...@ex...>
Cc: GeoTools Users <geo...@li...>
Betreff: Re: [Geotools-gt2-users] GeoTools 34.0 released for Java 17 with Eclipse ImageN processing engine

Because ImageN is so new I do it think other projects have implemented operators yet to be registered?


- -

Jody Garnett


On Wed, Nov 5, 2025 at 4:08 AM Kalesse Sören <Soe...@dw... <mailto:Soe...@dw...> > wrote:


	Hi again, 
	
	after reading my previous e-mail I believe maybe an example would make it clearer. Let's go by the ImageN crop example (although the same argumentation is valid also for the other two (jiffle and vectorize)).
	
	So let's assume at first that both ImageN and JAI work well individually with the two mechanisms of registration: the (JAI/ImageN) registryFile and Java ServiceLoader. 
	
	Then, let's look at crops's resources on the ImageN main branch. We have: 
	
	RegistryFile: 
	modules/crop/src/main/resources/META-INF/registryFile.jai (stripped of comments):
	---------------------------------------------------------------------------------------------------------------------------
	
	  descriptor  org.eclipse.imagen.media.crop.CropDescriptor
	  rendered  org.eclipse.imagen.media.crop.CropCRIF     org.eclipse.imagen.media  Crop   Crop
	
	and we have the Java ServiceLoader definition: 
	modules/crop/src/main/resources/META-INF/services/javax.media.jai.OperationRegistrySpi:
	---------------------------------------------------------------------------------------------------------------------------
	
	  org.eclipse.imagen.media.crop.CropSpi
	
	The most obvious thing here is that the Java ServiceLoader definition is wrong, because CropSpi does not implement the javax.media.jai.OperationRegistrySpi interface. 
	
	If we use only ImageN in our application, we will not notice the problem. ImageN is simply ignoring that ServiceLoader definition, because the interface is unknown to ImageN. BUT this will crash JAI, because ServiceLoader in JAI throws a ClassCastException given that definition. 
	
	Now, as proposed, we could (and should) fix this by renaming modules/crop/src/main/resources/META-INF/services/javax.media.jai.OperationRegistrySpi to modules/crop/src/main/resources/META-INF/services/org.eclipse.imagen.OperationRegistrySpi. 
	
	That now pleases JAI, because JAI does not know that new (ImageN) interface. Great! So now all should be good? NO! Because now we have this: 
	
	RegistryFile: 
	modules/crop/src/main/resources/META-INF/registryFile.jai (stripped of comments):
	---------------------------------------------------------------------------------------------------------------------------
	
	  descriptor  org.eclipse.imagen.media.crop.CropDescriptor
	  rendered  org.eclipse.imagen.media.crop.CropCRIF     org.eclipse.imagen.media  Crop   Crop
	
	and we have the fixed Java ServiceLoader definition: 
	modules/crop/src/main/resources/META-INF/services/org.eclipse.imagen.OperationRegistrySpi:
	---------------------------------------------------------------------------------------------------------------------------
	
	  org.eclipse.imagen.media.crop.CropSpi
	
	Technically everything looks fine, BUT ImageN will no longer initialize, because we apply the two types of registration schemes at once. With this, what happens is that the Crop operation gets registered once using registryFile, and then ImageN tries again using ServiceLoader, because now the definition is no longer ignored. 
	
	And this is the core problem. The wrong ServiceLoader definition files on main branch are simply hiding the problem, because ImageN will ignore them, but if we fix them to be correct, then ImageN will fail to initialize, because Crop is already there. The same argumentation goes for jiffle and vectorize, because those two also have (wrong) Java ServiceLoader  definitions. So fixing them too, will result in the same problem of failing initialization. 
	
	And last but not least, the reason for all other libraries to not fail, is that none of the other libraries have Java ServiceLoader definitions at all. 
	
	That as the reason why my initial PR#119 simply removed the three ServiceLoader definitions from crop, jiffle and vectorize. 
	
	Does that better illustrate the problem?
	
	
	==== Now another topic: should we rename registryFile.jai --> registryFile.imagen =======
	
	Maybe it should be done to make a more explicit distinction between ImageN and JAI registration. It should be noted though that the renaming is a breaking change for everyone using ImageN, because for example GeoTools/GeoServer and other applications that have their own ImageN operators implemented will have to switch to that new naming scheme. But, yeah, maybe it's worth the effort - I don't know. 
	
	What I want to emphasize though is that I have tried locally with the wrong ServiceLoader definitions removed from ImageN. I ran GeoServer 2.28.0 that is now based on ImageN with some of our custom JAI operators that are still based on JAI 1.1.3. First, now both ImageN and JAI initialized correctly and I was able to successfully run WMS queries (which should prove that ImageN is working correctly) and I could also verify that our own custom JAI operators are working as well. 
	
	My assumption based on that test is that it does not seem to matter too much how these registry files are named. It seems both, ImageN as well as JAI can cope with either and probably filtering the operations by the definitions they support. 
	
	Of course I can currently not prove that by the same names, both work correctly, but that was my first try. Maybe a JAI/ImageN interoperability Test-case could prove. I don't know. 
	
	But to summarize the current discussion. Whether or not the registry files should be renamed, does not relate to that other issue I presented in the first part of the e-mail.
	
	I hope, by this report, my argumentation becomes clearer. Sorry for that long wall of text.
	Thanks!
	Sören
	
	
	-----Ursprüngliche Nachricht-----
	Von: Kalesse Sören <Soe...@dw... <mailto:Soe...@dw...> > 
	Gesendet: Mittwoch, 5. November 2025 10:55
	An: Jody Garnett <jod...@gm... <mailto:jod...@gm...> >
	Cc: GeoTools Users <geo...@li... <mailto:geo...@li...> >
	Betreff: Re: [Geotools-gt2-users] GeoTools 34.0 released for Java 17 with Eclipse ImageN processing engine
	
	Hi Jody, 
	
	Ok, I can make a PR, but with that all renaming happening, it'll be quite some big change and probably PRs needed for GeoTools and GeoServer as well, right? ... and all other libs that are already using ImageN. 
	
	I am very sorry but I really need to emphasize again, that the registry files are not the problem here! ImageN and JAI seem to be able to cope with them even though they have the same name (registryFile.jai). I have tested it locally running ImageN and JAI in the same application and they do not interfere at all. I was able to run GeoServer 2.28.0 that uses ImageN and still use our own JAI operators based on JAI core 1.1.3 without any problems at all. 
	
	Really, the problem here are those invalid Java ServiceLoader definitions. 
	
	    modules/crop/src/main/resources/META-INF/services/javax.media.jai.OperationRegistrySpi
	    modules/jiffle/jt-jiffle-op/src/main/resources/META-INF/services/javax.media.jai.OperationsRegistrySpi
	    modules/vectorize/src/main/resources/META-INF/services/javax.media.jai.OperationsRegistrySpi
	
	The first one (crop) tries registering at JAI operation registry, which is wrong. This will cause a ClassCastException in JAI. 
	The other two (jiffle and vectorize) try the same thing but even worse, the interface names are wrong --> OperationsRegistrySpi vs. OperationRegistrySpi. So these two will simply be ignored, because that interface does not exist. 
	
	I could fix the names of the ServiceLoader definitions --> org.eclipse.imagen.OperationRegistrySpi. That would please Java at least. So that's good, but ImageN will no longer work, because as mentioned earlier, ImageN registry cannot currently not deal with two mechanisms being in place at the same time. Fixing the names will do this (Example taken from the Jiffle test cases):
	
	[ERROR] org.eclipse.imagen.media.jiffleop.NoSourceTest.createSequentialImage -- Time elapsed: 0 s <<< ERROR!
	java.lang.NoClassDefFoundError: Could not initialize class org.eclipse.imagen.ImageN
	        at org.eclipse.imagen.media.jiffleop.NoSourceTest.reset(NoSourceTest.java:82)
	        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	        at java.base/java.lang.reflect.Method.invoke(Method.java:580)
	        at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
	        at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	        at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
	        at org.junit.internal.runners.statements.RunAfters.invokeMethod(RunAfters.java:46)
	        at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33)
	        at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
	        at org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
	Caused by: java.lang.ExceptionInInitializerError: Exception java.lang.IllegalArgumentException: A descriptor is already registered against the name "Jiffle" under registry mode "rendered" [in thread "main"]
	        at org.eclipse.imagen.DescriptorCache.addDescriptor(DescriptorCache.java:144)
	        at org.eclipse.imagen.OperationRegistry.registerDescriptor(OperationRegistry.java:580)
	        at org.eclipse.imagen.ThreadSafeOperationRegistry.registerDescriptor(ThreadSafeOperationRegistry.java:156)
	        at org.eclipse.imagen.media.jiffleop.JiffleSpi.updateRegistry(JiffleSpi.java:73)
	        at org.eclipse.imagen.OperationRegistry.registerServices(OperationRegistry.java:1556)
	        at org.eclipse.imagen.ThreadSafeOperationRegistry.registerServices(ThreadSafeOperationRegistry.java:529)
	        at org.eclipse.imagen.OperationRegistry.initializeRegistry(OperationRegistry.java:311)
	        at org.eclipse.imagen.ImageN.<clinit>(ImageN.java:351)
	
	The descriptor cache does not allow an operation to be registered twice. That is why I am saying that fixing the ServiceLoader definitions won't help at all. The only options I see is:
	
	 1. make descriptor cache support registry definitions coming from multiple places at the same time 
	   ---> I am not sure if that's really a good idea
	 2. remove the ServiceLoader definitions from those three libs
	
	I am wondering anyway, why is it that only those three libs do have ServiceLoader files at all? What about the other libs? Not a single other lib has any ServiceLoader definition at all.
	
	My PR#119 did exactly that. It removed the ServiceLoader definitions from those three libs. That's all it did and that fixed it all. No renaming of registryFile.jai required. 
	
	To summarize: 
	============
	
	 I can make a PR that renames all registryFile.jai --> registryFile.imagen and changes the ImageN registry to use those instead - no problem. 
	
	But that will not help with the initial problem, we need to deal with those ServiceLoader files - fixing their names to match the correct interface will not help. On the contrary, it will make it worse, because ImageN will no longer initialize, because it cannot handle both (registryFile.[jai|imagen] and ServiceLoader) at the same time.
	
	My proposal is to go by the initial PR and remove the ServiceLoader files all together for these three modules that have them (crop, jiffle, vectorize).
	
	What do you think?
	Thanks
	Sören
	
	
	-----Ursprüngliche Nachricht-----
	Von: Jody Garnett <jod...@gm... <mailto:jod...@gm...> > 
	Gesendet: Mittwoch, 5. November 2025 02:47
	An: Kalesse Sören <ska...@ex... <mailto:ska...@ex...> >
	Cc: GeoTools Users <geo...@li... <mailto:geo...@li...> >
	Betreff: Re: [Geotools-gt2-users] GeoTools 34.0 released for Java 17 with Eclipse ImageN processing engine
	
	So ideally we should fix the invalid definitions, and rename the files to end with “imagen”.
	
	If you make a PR I am willing to do a 0.9.1 relate; and Gabe offered to make a geotools release on schedule next week. 
	
	- -
	
	Jody Garnett
	
	
	On Mon, Nov 3, 2025 at 11:12 PM Kalesse Sören <Soe...@dw... <mailto:Soe...@dw...>  <mailto:Soe...@dw... <mailto:Soe...@dw...> > > wrote:
	
	
	        Hi Andrea, 
	
	        That's exactly my point. I  do assume that it was not intended for these two to coexist, but it should just work fine because there are two different registries and the operations interfaces are different, so in theory these two do not collide at all. That gives all users a good "workaround" to live with until applications and libraries have succeeded to migrate. 
	
	        And that's also exactly where my PR comes in. The three mentioned ImageN libraries (and only those three!) contain ServiceLoader definitions that are wrong. The register the ImageN operations at the JAI registry. That leads to class cast exceptions (wrong interfaces). That's the point that must definitely be fixed whatsoever.
	
	        Now that fixed, here arises the second aspect: Right now you cannot mix standard ImageN and ServiceLoader registration. ImageN does not support that. It will fail to initialize if one operation had already been registered by that other means. So you must decide: either support multiple ways of registration in the ImageN core or decide upon one and let it go. 
	
	        Therefore my PR removes the three ServiceLoader definitions: 1) because they were wrong and 2) because that is the least invasive fix to make ImageN initialize correctly. The PR#119 was tested locally running GeoServer 2.2.8.0 and another application that uses JAI and it worked just fine.
	
	        I hope you can agree that this is a proper fix and should be part in one of the next releases. For us it is a show-stopper for upgrading to GT 33.x / GS 2.28.x. 
	
	        Thanks!
	        Sören
	
	        -----Ursprüngliche Nachricht-----
	        Von: Andrea Aime <and...@ge... <mailto:and...@ge...>  <mailto:and...@ge... <mailto:and...@ge...> > > 
	        Gesendet: Freitag, 31. Oktober 2025 15:25
	        An: Kalesse Sören <ska...@ex... <mailto:ska...@ex...>  <mailto:ska...@ex... <mailto:ska...@ex...> > >
	        Cc: GeoTools Users <geo...@li... <mailto:geo...@li...>  <mailto:geo...@li... <mailto:geo...@li...> > >
	        Betreff: Re: [Geotools-gt2-users] GeoTools 34.0 released for Java 17 with Eclipse ImageN processing engine
	
	        Hi,
	        I second what Jody said, there was no plan to make the coexist, it's an upgrade path.
	        However... I believe that a coexistence could be possible, the java packages
	        are different, so by having ImageN use a different file name for the registry files in META-INF, 
	        from registryFile.jai to registryFile.imagen, a coexistence might be possible, even if likely
	        wasteful (two separate image processing caches in memory are not the greatest of ideas).
	
	        A coexistence is just not in our plans, but since ImageN is not yet available as 1.0, if DWD wants
	        to put the development effort to get it done, I would not be against it.
	        I see this applicable to the GeoServer 3.0 series.
	
	        I would recommend switching existing software to ImageN though, we prepared migration scripts
	        that should help in the endeavor.
	
	        Regards,
	
	        Andrea Aime
	
	
	
	
	        ==
	
	
	        GeoServer Professional Services from the experts!
	
	        Visit http://bit.ly/gs-services-us <http://bit.ly/gs-services-us>  for more information.
	
	
	
	        ==
	
	        Ing. Andrea Aime 
	        @geowolf
	        Technical Lead
	
	
	
	        GeoSolutions Group
	        phone: +39 0584 962313
	
	        fax:     +39 0584 1660272
	
	        mob:   +39  339 8844549
	
	
	        https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVA0Pzs/NCh4MzwgPihnajM+PzQ+Pyh9Z2lgb3p7fGszP2s2ODk/Nm04PGs2b29vODk6Oj1tNj5rOG9tbG1qOG9sbDtqaG06aCh6Mz85ODw9PTg4PToof2dqMztPOzd4S1pmPjw8PD85IztPOzd4S1pnPjw8PD85KHxtfnozXWFrfGtgIEVvYmt9fWtOanlqIGprKG0zOzwoZmpiMz4=&url=https%3a%2f%2fwww.geosolutionsgroup.com%2f  <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVUzODw4My9/NDsnOS9gbTQ5ODM5OC96YG5naH18e2w0bTs+Ozo+bDtqajtqMDsxPT1qOmg5PD49MDE+Omwwam0xMWprbzE4Oy99NDg+Pzs6OT47MDkveGBtNDxIPDhkSGN5OTg/Pj46JDxIPDhkSGN4OTg/Pj46L3tqeX00WmZse2xnJ0JoZWx6emxJbX5tJ21sL2o0PDsvYW1lNDk=&url=https%3a%2f%2fwww.geosolutionsgroup.com%2f>  <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVs5MjYyOSV1PjEtMyVqZz4zMjkzMiVwamRtYnd2cWY+Ozs6OjQ2MTAyM2Y1MDU1NjQxZzFiOzUwMWA0ZjAwZzQwNzA6ZTY2NCV3PjI0NTI6MTM0OzolcmpnPjY6VUZSV3FGMzEyMTswLjY6VUZSV3FFMzEyMTswJXFgc3c+UGxmcWZtLUhib2ZwcGZDZ3RnLWdmJWA+NjEla2dvPjM=&url=https%3a%2f%2fwww.geosolutionsgroup.com%2f> 
	
	        https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVA0Pzs/NCh4MzwgPihnajM+PzQ+Pyh9Z2lgb3p7fGszNmpqbG1sO2g5ajhsOT1rOjo9PG0+PW9sbWw2PW06PW06Oz88ajo5aCh6Mz85ODw9PTg4PToof2dqMztPOzd4S1pmPjw8PD85IztPOzd4S1pnPjw8PD85KHxtfnozXWFrfGtgIEVvYmt9fWtOanlqIGprKG0zPTkoZmpiMz4=&url=http%3a%2f%2ftwitter.com%2fgeosolutions_it  <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVUzODw4My9/NDsnOS9gbTQ5ODM5OC96YG5naH18e2w0PWg9bW1obzFqaGpsPz5sbToxa2xrPjA9PW06PDBobDk5bG09a2s5bS99NDg+Pzs6OT47MDkveGBtNDxIPDhkSGN5OTg/Pj46JDxIPDhkSGN4OTg/Pj46L3tqeX00WmZse2xnJ0JoZWx6emxJbX5tJ21sL2o0Oj4vYW1lNDk=&url=http%3a%2f%2ftwitter.com%2fgeosolutions_it>  <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVs5MjYyOSV1PjEtMyVqZz4zMjkzMiVwamRtYnd2cWY+MDplNTQ7ZzM6YTozNmU7NGY1OjtmZzdnYTIzYjIwYmJmNGU2MDBgZiV3PjI0NTI6MTM0OzolcmpnPjY6VUZSV3FGMzEyMTswLjY6VUZSV3FFMzEyMTswJXFgc3c+UGxmcWZtLUhib2ZwcGZDZ3RnLWdmJWA+MDQla2dvPjM=&url=http%3a%2f%2ftwitter.com%2fgeosolutions_it> 
	
	        -------------------------------------------------------
	
	
	        Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia.
	
	        This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail
	
	
	
	        On Thu, Oct 30, 2025 at 5:29 PM Kalesse Sören <Soe...@dw... <mailto:Soe...@dw...>  <mailto:Soe...@dw... <mailto:Soe...@dw...> >  <mailto:Soe...@dw... <mailto:Soe...@dw...>  <mailto:Soe...@dw... <mailto:Soe...@dw...> > > > wrote:
	
	
	                Hi,
	
	                thanks for the new release! We have noticed a problem though, that deals with environments where GeoTools (and now ImageN) and JAI are used at the same time. I have documented the issue at https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVA0Pzs/NCh4MzwgPihnajM+PzQ+Pyh9Z2lgb3p7fGszb2tqOmw5bDo6Nz45OWhoPTc7PjY/PT89ajo+Pjo5a285azttPD8/bSh6Mz85ODw9PTg4PToof2dqMztPOzd4S1pmPjw8PD85IztPOzd4S1pnPjw8PD85KHxtfnozXWFrfGtgIEVvYmt9fWtOanlqIGprKG0zOzwoZmpiMz4=&url=https%3a%2f%2fgithub.com%2feclipse-imagen%2fimagen%2fissues%2f118  <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVUzODw4My9/NDsnOS9gbTQ5ODM5OC96YG5naH18e2w0MDs9azlvOT0+bT1oa2s7aGgwamxqPzAwbDs8OmxrPj88MD4+azo9PS99NDg+Pzs6OT47MDkveGBtNDxIPDhkSGN5OTg/Pj46JDxIPDhkSGN4OTg/Pj46L3tqeX00WmZse2xnJ0JoZWx6emxJbX5tJ21sL2o0PDsvYW1lNDk=&url=https%3a%2f%2fgithub.com%2feclipse-imagen%2fimagen%2fissues%2f118>  <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVs5MjYyOSV1PjEtMyVqZz4zMjkzMiVwamRtYnd2cWY+NDE1YDExNTs1ZjpnNTEwZzIyZmU7NmE7O2ZmZWFgYjJnMzA0NmY1NSV3PjI0NTI6MTM0OzolcmpnPjY6VUZSV3FGMzEyMTswLjY6VUZSV3FFMzEyMTswJXFgc3c+UGxmcWZtLUhib2ZwcGZDZ3RnLWdmJWA+NjEla2dvPjM=&url=https%3a%2f%2fgithub.com%2feclipse-imagen%2fimagen%2fissues%2f118>  and there is a PR attached https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVA0Pzs/NCh4MzwgPihnajM+PzQ+Pyh9Z2lgb3p7fGszOmxrOTdqams6Ozk/OTs3PGg7PTo9Oj1qN2s2Nm84Pms2OTw2Pm0/PSh6Mz85ODw9PTg4PToof2dqMztPOzd4S1pmPjw8PD85IztPOzd4S1pnPjw8PD85KHxtfnozXWFrfGtgIEVvYmt9fWtOanlqIGprKG0zOzwoZmpiMz4=&url=https%3a%2f%2fgithub.com%2feclipse-imagen%2fimagen%2fpull%2f119  <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVUzODw4My9/NDsnOS9gbTQ5ODM5OC96YG5naH18e2w0ajxsOGtoaj9sbzs9ODhvOG1qaDFqbTowPTg8Pzs4PWhoOzs/OT1vPi99NDg+Pzs6OT47MDkveGBtNDxIPDhkSGN5OTg/Pj46JDxIPDhkSGN4OTg/Pj46L3tqeX00WmZse2xnJ0JoZWx6emxJbX5tJ21sL2o0PDsvYW1lNDk=&url=https%3a%2f%2fgithub.com%2feclipse-imagen%2fimagen%2fpull%2f119>  <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVs5MjYyOSV1PjEtMyVqZz4zMjkzMiVwamRtYnd2cWY+ZmVgNDplZTRlYWY0NWUzZ2BlMjA3M2UzZTU1MGdmNjQ6Zzc1MGdnNyV3PjI0NTI6MTM0OzolcmpnPjY6VUZSV3FGMzEyMTswLjY6VUZSV3FFMzEyMTswJXFgc3c+UGxmcWZtLUhib2ZwcGZDZ3RnLWdmJWA+NjEla2dvPjM=&url=https%3a%2f%2fgithub.com%2feclipse-imagen%2fimagen%2fpull%2f119> . 
	
	                I wonder if there's any chance the problem can be solved soon as it currently prevents us from upgrading to GeoServer 2.28.x. 
	
	                Thanks and Best Regards
	                Sören 
	
	                -----Ursprüngliche Nachricht-----
	                Von: Jody Garnett <jod...@gm... <mailto:jod...@gm...>  <mailto:jod...@gm... <mailto:jod...@gm...> >  <mailto:jod...@gm... <mailto:jod...@gm...>  <mailto:jod...@gm... <mailto:jod...@gm...> > > > 
	                Gesendet: Mittwoch, 22. Oktober 2025 20:57
	                An: GeoTools Users <geo...@li... <mailto:geo...@li...>  <mailto:geo...@li... <mailto:geo...@li...> >  <mailto:geo...@li... <mailto:geo...@li...>  <mailto:geo...@li... <mailto:geo...@li...> > > >
	                Betreff: [Geotools-gt2-users] GeoTools 34.0 released for Java 17 with Eclipse ImageN processing engine
	
	                The GeoTools team is pleased to announce the release <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVE3PDg8Nyt7MD8jPStkaTA9PDc9PCt+ZGpjbHl4f2gwazk7bj5uNG8+Oj5saW5ub2s4NT5raW5paWg+bGw+bjs0OT41azw9PCt5MDw6Ozw8ODQ1OjsrfGRpMDg0QEc5bGFpPT85NDs4IDg0QEc5bGFoPT85NDs4K39ufXkwXmJof2hjI0ZsYWh+fmhNaXppI2loK24wNT0rZWlhMD0=&url=https%3a%2f%2fgeotoolsnews.blogspot.com%2f2025%2f10%2fgeotools-340-release.html>  of the latest stable version of GeoTools 34.0 <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVE3PDg8Nyt7MD8jPStkaTA9PDc9PCt+ZGpjbHl4f2gwbDU1azU5OWhpaT9sbG5rPTRuPmw9ND9rOWg7NGhuPDU9Oz88aWtsOit5MDw6Ozw8ODQ1OjsrfGRpMDg0QEc5bGFpPT85NDs4IDg0QEc5bGFoPT85NDs4K39ufXkwXmJof2hjI0ZsYWh+fmhNaXppI2loK24wOD8rZWlhMD0=&url=https%3a%2f%2fsourceforge.net%2fprojects%2fgeotools%2ffiles%2fGeoTools%252034%2520Releases%2f34.0%2f> . This release is available from the repo.osgeo.org <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVw4MzczOCR0PzAsMiRrZj8yMzgyMyRxa2VsY3Z3cGc/ZGA6MTE6NGEzZzthNTIwZ2AzOjFkNjQxNjVgMjsxOzQ1NWcwMTc1OiR2PzM1NDAxNzc6MzIkc2tmPzdDN0RFbXNxMjM2OzQ6LzdDN0RFbXN2MjM2OzQ6JHBhcnY/UW1ncGdsLEljbmdxcWdCZnVmLGZnJGE/NzAkamZuPzI=&url=http%3a%2f%2frepo.osgeo.org>  <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVUzODw4My9/NDsnOS9gbTQ5ODM5OC96YG5naH18e2w0PWtvPTBobDk6Pjs/MDloPDg7aGhsbTs4bTBsaz9sOjkxPWxoaGw5bC99NDg+Pzs6OT47MDkveGBtNDxIPDhkSGN5OTg/Pj46JDxIPDhkSGN4OTg/Pj46L3tqeX00WmZse2xnJ0JoZWx6emxJbX5tJ21sL2o0PDsvYW1lNDk=&url=http%3a%2f%2frepo.osgeo.org>  <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVs5MjYyOSV1PjEtMyVqZz4zMjkzMiVwamRtYnd2cWY+YGFhNzE3MmAxNDM1YmJlNjNhOzpiYTpiYjc6NGU6N2BiNTRiOjQyZiV3PjI0NTI6MTM0OzolcmpnPjY6VUZSV3FGMzEyMTswLjY6VUZSV3FFMzEyMTswJXFgc3c+UGxmcWZtLUhib2ZwcGZDZ3RnLWdmJWA+NjEla2dvPjM=&url=http%3a%2f%2frepo.osgeo.org>  <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVE3PDg8Nyt7MD8jPStkaTA9PDc9PCt+ZGpjbHl4f2gwbGw0Pms+O2g7NDs/aD84NT47PjloPj48O2g6PGw7OGxpbDg+aG44byt5MDw6Ozw8ODQ1OjsrfGRpMDg0QEc5bGFpPT85NDs4IDg0QEc5bGFoPT85NDs4K39ufXkwXmJof2hjI0ZsYWh+fmhNaXppI2loK24wOD8rZWlhMD0=&url=http%3a%2f%2frepo.osgeo.org>  and is made in conjunction with ImageN 0.9.0, ImageIO-Ext 2.0.0, GeoWebCache 1.28.0, and GeoServer 2.28.0.
	
	                This is a major update:
	
	                *       The library now requires Java 17, ending support for Java 11
	
	                *       Upgrade from Java Advanced Imaging Library 1.1.3 to Eclipse ImageN 0.9.0.
	
	                *       Library now provides a maven bill-of-materials import for both library modules and third-party-dependences making it considerably easier for downstream projects to synchronize dependences when upgrading GeoTools
	
	                *       For more information please see upgrade instructions <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVE3PDg8Nyt7MD8jPStkaTA9PDc9PCt+ZGpjbHl4f2gwNDk1bjo7P2s0bms0OTk9aTo+a287a2k8PzlvbjhuaTw9PjtoPj81NSt5MDw6Ozw8ODQ1OjsrfGRpMDg0QEc5bGFpPT85NDs4IDg0QEc5bGFoPT85NDs4K39ufXkwXmJof2hjI0ZsYWh+fmhNaXppI2loK24wOD8rZWlhMD0=&url=https%3a%2f%2fdocs.geotools.org%2fstable%2fuserguide%2fwelcome%2fupgrade.html>  in the user manual
	
	                Thanks to Jody Garnett (GeoCat) for making this release, Gabriel Roldan (Camptocamp) for all the build improvements, and Andrea Aime (GeoServer) for working so hard on the Eclipse ImageN migration.
	
	                These major library updates were undertaken as part of the GeoServer 3 activities, and we would like to the crowdfunding sponsors their financial support.
	
	                _______________________________________________
	                GeoTools-GT2-Users mailing list
	                Geo...@li... <mailto:Geo...@li...>  <mailto:Geo...@li... <mailto:Geo...@li...> >  <mailto:Geo...@li... <mailto:Geo...@li...>  <mailto:Geo...@li... <mailto:Geo...@li...> > > 
	                https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVA0Pzs/NCh4MzwgPihnajM+PzQ+Pyh9Z2lgb3p7fGszPjZvNj46OTw7OTc/Ozs4aDc+PDttO21oPDxrPmg7OGpvazdob283Pyh6Mz85ODw9PTg4PToof2dqMztPOzd4S1pmPjw8PD85IztPOzd4S1pnPjw8PD85KHxtfnozXWFrfGtgIEVvYmt9fWtOanlqIGprKG0zOzwoZmpiMz4=&url=https%3a%2f%2flists.sourceforge.net%2flists%2flistinfo%2fgeotools-gt2-users  <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVUzODw4My9/NDsnOS9gbTQ5ODM5OC96YG5naH18e2w0PG88aDw7OW05Pj5rPGs5MTgwMG8xOTs/MG87Pj86aD4/PD86bTtqOS99NDg+Pzs6OT47MDkveGBtNDxIPDhkSGN5OTg/Pj46JDxIPDhkSGN4OTg/Pj46L3tqeX00WmZse2xnJ0JoZWx6emxJbX5tJ21sL2o0PDsvYW1lNDk=&url=https%3a%2f%2flists.sourceforge.net%2flists%2flistinfo%2fgeotools-gt2-users>  <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVs5MjYyOSV1PjEtMyVqZz4zMjkzMiVwamRtYnd2cWY+Zmc0OmBnYDViNTA1NDdmMzMyNTQ6ZmIxYmcxNTJnNTMyNGJiNDU2NiV3PjI0NTI6MTM0OzolcmpnPjY6VUZSV3FGMzEyMTswLjY6VUZSV3FFMzEyMTswJXFgc3c+UGxmcWZtLUhib2ZwcGZDZ3RnLWdmJWA+NjEla2dvPjM=&url=https%3a%2f%2flists.sourceforge.net%2flists%2flistinfo%2fgeotools-gt2-users> 
	
	
	
	        _______________________________________________
	        GeoTools-GT2-Users mailing list
	        Geo...@li... <mailto:Geo...@li...>  <mailto:Geo...@li... <mailto:Geo...@li...> > 
	        https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVA0Pzs/NCh4MzwgPihnajM+PzQ+Pyh9Z2lgb3p7fGszPjZvNj46OTw7OTc/Ozs4aDc+PDttO21oPDxrPmg7OGpvazdob283Pyh6Mz85ODw9PTg4PToof2dqMztPOzd4S1pmPjw8PD85IztPOzd4S1pnPjw8PD85KHxtfnozXWFrfGtgIEVvYmt9fWtOanlqIGprKG0zOzwoZmpiMz4=&url=https%3a%2f%2flists.sourceforge.net%2flists%2flistinfo%2fgeotools-gt2-users  <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVUzODw4My9/NDsnOS9gbTQ5ODM5OC96YG5naH18e2w0PG88aDw7OW05Pj5rPGs5MTgwMG8xOTs/MG87Pj86aD4/PD86bTtqOS99NDg+Pzs6OT47MDkveGBtNDxIPDhkSGN5OTg/Pj46JDxIPDhkSGN4OTg/Pj46L3tqeX00WmZse2xnJ0JoZWx6emxJbX5tJ21sL2o0PDsvYW1lNDk=&url=https%3a%2f%2flists.sourceforge.net%2flists%2flistinfo%2fgeotools-gt2-users> 
	
	
	
	_______________________________________________
	GeoTools-GT2-Users mailing list
	Geo...@li... <mailto:Geo...@li...> 
	https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVA0Pzs/NCh4MzwgPihnajM+PzQ+Pyh9Z2lgb3p7fGszPjZvNj46OTw7OTc/Ozs4aDc+PDttO21oPDxrPmg7OGpvazdob283Pyh6Mz85ODw9PTg4PToof2dqMztPOzd4S1pmPjw8PD85IztPOzd4S1pnPjw8PD85KHxtfnozXWFrfGtgIEVvYmt9fWtOanlqIGprKG0zOzwoZmpiMz4=&url=https%3a%2f%2flists.sourceforge.net%2flists%2flistinfo%2fgeotools-gt2-users 
	

Re: [Geotools-gt2-users] GeoTools 34.0 released for Java 17 with Eclipse ImageN processing engine

[Kalesse S. <Soe...@dw...>]

Hi again, 

after reading my previous e-mail I believe maybe an example would make it clearer. Let's go by the ImageN crop example (although the same argumentation is valid also for the other two (jiffle and vectorize)).

So let's assume at first that both ImageN and JAI work well individually with the two mechanisms of registration: the (JAI/ImageN) registryFile and Java ServiceLoader. 

Then, let's look at crops's resources on the ImageN main branch. We have: 

RegistryFile: 
modules/crop/src/main/resources/META-INF/registryFile.jai (stripped of comments):
---------------------------------------------------------------------------------------------------------------------------

  descriptor  org.eclipse.imagen.media.crop.CropDescriptor
  rendered  org.eclipse.imagen.media.crop.CropCRIF     org.eclipse.imagen.media  Crop   Crop

and we have the Java ServiceLoader definition: 
modules/crop/src/main/resources/META-INF/services/javax.media.jai.OperationRegistrySpi:
---------------------------------------------------------------------------------------------------------------------------

  org.eclipse.imagen.media.crop.CropSpi

The most obvious thing here is that the Java ServiceLoader definition is wrong, because CropSpi does not implement the javax.media.jai.OperationRegistrySpi interface. 

If we use only ImageN in our application, we will not notice the problem. ImageN is simply ignoring that ServiceLoader definition, because the interface is unknown to ImageN. BUT this will crash JAI, because ServiceLoader in JAI throws a ClassCastException given that definition. 

Now, as proposed, we could (and should) fix this by renaming modules/crop/src/main/resources/META-INF/services/javax.media.jai.OperationRegistrySpi to modules/crop/src/main/resources/META-INF/services/org.eclipse.imagen.OperationRegistrySpi. 

That now pleases JAI, because JAI does not know that new (ImageN) interface. Great! So now all should be good? NO! Because now we have this: 

RegistryFile: 
modules/crop/src/main/resources/META-INF/registryFile.jai (stripped of comments):
---------------------------------------------------------------------------------------------------------------------------

  descriptor  org.eclipse.imagen.media.crop.CropDescriptor
  rendered  org.eclipse.imagen.media.crop.CropCRIF     org.eclipse.imagen.media  Crop   Crop

and we have the fixed Java ServiceLoader definition: 
modules/crop/src/main/resources/META-INF/services/org.eclipse.imagen.OperationRegistrySpi:
---------------------------------------------------------------------------------------------------------------------------

  org.eclipse.imagen.media.crop.CropSpi

Technically everything looks fine, BUT ImageN will no longer initialize, because we apply the two types of registration schemes at once. With this, what happens is that the Crop operation gets registered once using registryFile, and then ImageN tries again using ServiceLoader, because now the definition is no longer ignored. 

And this is the core problem. The wrong ServiceLoader definition files on main branch are simply hiding the problem, because ImageN will ignore them, but if we fix them to be correct, then ImageN will fail to initialize, because Crop is already there. The same argumentation goes for jiffle and vectorize, because those two also have (wrong) Java ServiceLoader  definitions. So fixing them too, will result in the same problem of failing initialization. 

And last but not least, the reason for all other libraries to not fail, is that none of the other libraries have Java ServiceLoader definitions at all. 

That as the reason why my initial PR#119 simply removed the three ServiceLoader definitions from crop, jiffle and vectorize. 

Does that better illustrate the problem?


==== Now another topic: should we rename registryFile.jai --> registryFile.imagen =======

Maybe it should be done to make a more explicit distinction between ImageN and JAI registration. It should be noted though that the renaming is a breaking change for everyone using ImageN, because for example GeoTools/GeoServer and other applications that have their own ImageN operators implemented will have to switch to that new naming scheme. But, yeah, maybe it's worth the effort - I don't know. 

What I want to emphasize though is that I have tried locally with the wrong ServiceLoader definitions removed from ImageN. I ran GeoServer 2.28.0 that is now based on ImageN with some of our custom JAI operators that are still based on JAI 1.1.3. First, now both ImageN and JAI initialized correctly and I was able to successfully run WMS queries (which should prove that ImageN is working correctly) and I could also verify that our own custom JAI operators are working as well. 

My assumption based on that test is that it does not seem to matter too much how these registry files are named. It seems both, ImageN as well as JAI can cope with either and probably filtering the operations by the definitions they support. 

Of course I can currently not prove that by the same names, both work correctly, but that was my first try. Maybe a JAI/ImageN interoperability Test-case could prove. I don't know. 

But to summarize the current discussion. Whether or not the registry files should be renamed, does not relate to that other issue I presented in the first part of the e-mail.

I hope, by this report, my argumentation becomes clearer. Sorry for that long wall of text.
Thanks!
Sören


-----Ursprüngliche Nachricht-----
Von: Kalesse Sören <Soe...@dw...> 
Gesendet: Mittwoch, 5. November 2025 10:55
An: Jody Garnett <jod...@gm...>
Cc: GeoTools Users <geo...@li...>
Betreff: Re: [Geotools-gt2-users] GeoTools 34.0 released for Java 17 with Eclipse ImageN processing engine

Hi Jody, 

Ok, I can make a PR, but with that all renaming happening, it'll be quite some big change and probably PRs needed for GeoTools and GeoServer as well, right? ... and all other libs that are already using ImageN. 

I am very sorry but I really need to emphasize again, that the registry files are not the problem here! ImageN and JAI seem to be able to cope with them even though they have the same name (registryFile.jai). I have tested it locally running ImageN and JAI in the same application and they do not interfere at all. I was able to run GeoServer 2.28.0 that uses ImageN and still use our own JAI operators based on JAI core 1.1.3 without any problems at all. 

Really, the problem here are those invalid Java ServiceLoader definitions. 

    modules/crop/src/main/resources/META-INF/services/javax.media.jai.OperationRegistrySpi
    modules/jiffle/jt-jiffle-op/src/main/resources/META-INF/services/javax.media.jai.OperationsRegistrySpi
    modules/vectorize/src/main/resources/META-INF/services/javax.media.jai.OperationsRegistrySpi

The first one (crop) tries registering at JAI operation registry, which is wrong. This will cause a ClassCastException in JAI. 
The other two (jiffle and vectorize) try the same thing but even worse, the interface names are wrong --> OperationsRegistrySpi vs. OperationRegistrySpi. So these two will simply be ignored, because that interface does not exist. 

I could fix the names of the ServiceLoader definitions --> org.eclipse.imagen.OperationRegistrySpi. That would please Java at least. So that's good, but ImageN will no longer work, because as mentioned earlier, ImageN registry cannot currently not deal with two mechanisms being in place at the same time. Fixing the names will do this (Example taken from the Jiffle test cases):

[ERROR] org.eclipse.imagen.media.jiffleop.NoSourceTest.createSequentialImage -- Time elapsed: 0 s <<< ERROR!
java.lang.NoClassDefFoundError: Could not initialize class org.eclipse.imagen.ImageN
	at org.eclipse.imagen.media.jiffleop.NoSourceTest.reset(NoSourceTest.java:82)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
	at org.junit.internal.runners.statements.RunAfters.invokeMethod(RunAfters.java:46)
	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33)
	at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
	at org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
Caused by: java.lang.ExceptionInInitializerError: Exception java.lang.IllegalArgumentException: A descriptor is already registered against the name "Jiffle" under registry mode "rendered" [in thread "main"]
	at org.eclipse.imagen.DescriptorCache.addDescriptor(DescriptorCache.java:144)
	at org.eclipse.imagen.OperationRegistry.registerDescriptor(OperationRegistry.java:580)
	at org.eclipse.imagen.ThreadSafeOperationRegistry.registerDescriptor(ThreadSafeOperationRegistry.java:156)
	at org.eclipse.imagen.media.jiffleop.JiffleSpi.updateRegistry(JiffleSpi.java:73)
	at org.eclipse.imagen.OperationRegistry.registerServices(OperationRegistry.java:1556)
	at org.eclipse.imagen.ThreadSafeOperationRegistry.registerServices(ThreadSafeOperationRegistry.java:529)
	at org.eclipse.imagen.OperationRegistry.initializeRegistry(OperationRegistry.java:311)
	at org.eclipse.imagen.ImageN.<clinit>(ImageN.java:351)

The descriptor cache does not allow an operation to be registered twice. That is why I am saying that fixing the ServiceLoader definitions won't help at all. The only options I see is:

 1. make descriptor cache support registry definitions coming from multiple places at the same time 
   ---> I am not sure if that's really a good idea
 2. remove the ServiceLoader definitions from those three libs

I am wondering anyway, why is it that only those three libs do have ServiceLoader files at all? What about the other libs? Not a single other lib has any ServiceLoader definition at all.

My PR#119 did exactly that. It removed the ServiceLoader definitions from those three libs. That's all it did and that fixed it all. No renaming of registryFile.jai required. 

To summarize: 
============

 I can make a PR that renames all registryFile.jai --> registryFile.imagen and changes the ImageN registry to use those instead - no problem. 

But that will not help with the initial problem, we need to deal with those ServiceLoader files - fixing their names to match the correct interface will not help. On the contrary, it will make it worse, because ImageN will no longer initialize, because it cannot handle both (registryFile.[jai|imagen] and ServiceLoader) at the same time.

My proposal is to go by the initial PR and remove the ServiceLoader files all together for these three modules that have them (crop, jiffle, vectorize).

What do you think?
Thanks
Sören


-----Ursprüngliche Nachricht-----
Von: Jody Garnett <jod...@gm...> 
Gesendet: Mittwoch, 5. November 2025 02:47
An: Kalesse Sören <ska...@ex...>
Cc: GeoTools Users <geo...@li...>
Betreff: Re: [Geotools-gt2-users] GeoTools 34.0 released for Java 17 with Eclipse ImageN processing engine

So ideally we should fix the invalid definitions, and rename the files to end with “imagen”.

If you make a PR I am willing to do a 0.9.1 relate; and Gabe offered to make a geotools release on schedule next week. 

- -

Jody Garnett


On Mon, Nov 3, 2025 at 11:12 PM Kalesse Sören <Soe...@dw... <mailto:Soe...@dw...> > wrote:


	Hi Andrea, 
	
	That's exactly my point. I  do assume that it was not intended for these two to coexist, but it should just work fine because there are two different registries and the operations interfaces are different, so in theory these two do not collide at all. That gives all users a good "workaround" to live with until applications and libraries have succeeded to migrate. 
	
	And that's also exactly where my PR comes in. The three mentioned ImageN libraries (and only those three!) contain ServiceLoader definitions that are wrong. The register the ImageN operations at the JAI registry. That leads to class cast exceptions (wrong interfaces). That's the point that must definitely be fixed whatsoever.
	
	Now that fixed, here arises the second aspect: Right now you cannot mix standard ImageN and ServiceLoader registration. ImageN does not support that. It will fail to initialize if one operation had already been registered by that other means. So you must decide: either support multiple ways of registration in the ImageN core or decide upon one and let it go. 
	
	Therefore my PR removes the three ServiceLoader definitions: 1) because they were wrong and 2) because that is the least invasive fix to make ImageN initialize correctly. The PR#119 was tested locally running GeoServer 2.2.8.0 and another application that uses JAI and it worked just fine.
	
	I hope you can agree that this is a proper fix and should be part in one of the next releases. For us it is a show-stopper for upgrading to GT 33.x / GS 2.28.x. 
	
	Thanks!
	Sören
	
	-----Ursprüngliche Nachricht-----
	Von: Andrea Aime <and...@ge... <mailto:and...@ge...> > 
	Gesendet: Freitag, 31. Oktober 2025 15:25
	An: Kalesse Sören <ska...@ex... <mailto:ska...@ex...> >
	Cc: GeoTools Users <geo...@li... <mailto:geo...@li...> >
	Betreff: Re: [Geotools-gt2-users] GeoTools 34.0 released for Java 17 with Eclipse ImageN processing engine
	
	Hi,
	I second what Jody said, there was no plan to make the coexist, it's an upgrade path.
	However... I believe that a coexistence could be possible, the java packages
	are different, so by having ImageN use a different file name for the registry files in META-INF, 
	from registryFile.jai to registryFile.imagen, a coexistence might be possible, even if likely
	wasteful (two separate image processing caches in memory are not the greatest of ideas).
	
	A coexistence is just not in our plans, but since ImageN is not yet available as 1.0, if DWD wants
	to put the development effort to get it done, I would not be against it.
	I see this applicable to the GeoServer 3.0 series.
	
	I would recommend switching existing software to ImageN though, we prepared migration scripts
	that should help in the endeavor.
	
	Regards,
	
	Andrea Aime
	
	
	
	
	==
	
	
	GeoServer Professional Services from the experts!
	
	Visit http://bit.ly/gs-services-us <http://bit.ly/gs-services-us>  for more information.
	
	
	
	==
	
	Ing. Andrea Aime 
	@geowolf
	Technical Lead
	
	
	
	GeoSolutions Group
	phone: +39 0584 962313
	
	fax:     +39 0584 1660272
	
	mob:   +39  339 8844549
	
	
	https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVA0Pzs/NCh4MzwgPihnajM+PzQ+Pyh9Z2lgb3p7fGszP2s2ODk/Nm04PGs2b29vODk6Oj1tNj5rOG9tbG1qOG9sbDtqaG06aCh6Mz85ODw9PTg4PToof2dqMztPOzd4S1pmPjw8PD85IztPOzd4S1pnPjw8PD85KHxtfnozXWFrfGtgIEVvYmt9fWtOanlqIGprKG0zOzwoZmpiMz4=&url=https%3a%2f%2fwww.geosolutionsgroup.com%2f  <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVUzODw4My9/NDsnOS9gbTQ5ODM5OC96YG5naH18e2w0bTs+Ozo+bDtqajtqMDsxPT1qOmg5PD49MDE+Omwwam0xMWprbzE4Oy99NDg+Pzs6OT47MDkveGBtNDxIPDhkSGN5OTg/Pj46JDxIPDhkSGN4OTg/Pj46L3tqeX00WmZse2xnJ0JoZWx6emxJbX5tJ21sL2o0PDsvYW1lNDk=&url=https%3a%2f%2fwww.geosolutionsgroup.com%2f>  <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVs5MjYyOSV1PjEtMyVqZz4zMjkzMiVwamRtYnd2cWY+Ozs6OjQ2MTAyM2Y1MDU1NjQxZzFiOzUwMWA0ZjAwZzQwNzA6ZTY2NCV3PjI0NTI6MTM0OzolcmpnPjY6VUZSV3FGMzEyMTswLjY6VUZSV3FFMzEyMTswJXFgc3c+UGxmcWZtLUhib2ZwcGZDZ3RnLWdmJWA+NjEla2dvPjM=&url=https%3a%2f%2fwww.geosolutionsgroup.com%2f> 
	
	https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVA0Pzs/NCh4MzwgPihnajM+PzQ+Pyh9Z2lgb3p7fGszNmpqbG1sO2g5ajhsOT1rOjo9PG0+PW9sbWw2PW06PW06Oz88ajo5aCh6Mz85ODw9PTg4PToof2dqMztPOzd4S1pmPjw8PD85IztPOzd4S1pnPjw8PD85KHxtfnozXWFrfGtgIEVvYmt9fWtOanlqIGprKG0zPTkoZmpiMz4=&url=http%3a%2f%2ftwitter.com%2fgeosolutions_it  <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVUzODw4My9/NDsnOS9gbTQ5ODM5OC96YG5naH18e2w0PWg9bW1obzFqaGpsPz5sbToxa2xrPjA9PW06PDBobDk5bG09a2s5bS99NDg+Pzs6OT47MDkveGBtNDxIPDhkSGN5OTg/Pj46JDxIPDhkSGN4OTg/Pj46L3tqeX00WmZse2xnJ0JoZWx6emxJbX5tJ21sL2o0Oj4vYW1lNDk=&url=http%3a%2f%2ftwitter.com%2fgeosolutions_it>  <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVs5MjYyOSV1PjEtMyVqZz4zMjkzMiVwamRtYnd2cWY+MDplNTQ7ZzM6YTozNmU7NGY1OjtmZzdnYTIzYjIwYmJmNGU2MDBgZiV3PjI0NTI6MTM0OzolcmpnPjY6VUZSV3FGMzEyMTswLjY6VUZSV3FFMzEyMTswJXFgc3c+UGxmcWZtLUhib2ZwcGZDZ3RnLWdmJWA+MDQla2dvPjM=&url=http%3a%2f%2ftwitter.com%2fgeosolutions_it> 
	
	-------------------------------------------------------
	
	
	Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia.
	
	This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail
	
	
	
	On Thu, Oct 30, 2025 at 5:29 PM Kalesse Sören <Soe...@dw... <mailto:Soe...@dw...>  <mailto:Soe...@dw... <mailto:Soe...@dw...> > > wrote:
	
	
	        Hi,
	
	        thanks for the new release! We have noticed a problem though, that deals with environments where GeoTools (and now ImageN) and JAI are used at the same time. I have documented the issue at https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVA0Pzs/NCh4MzwgPihnajM+PzQ+Pyh9Z2lgb3p7fGszb2tqOmw5bDo6Nz45OWhoPTc7PjY/PT89ajo+Pjo5a285azttPD8/bSh6Mz85ODw9PTg4PToof2dqMztPOzd4S1pmPjw8PD85IztPOzd4S1pnPjw8PD85KHxtfnozXWFrfGtgIEVvYmt9fWtOanlqIGprKG0zOzwoZmpiMz4=&url=https%3a%2f%2fgithub.com%2feclipse-imagen%2fimagen%2fissues%2f118  <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVUzODw4My9/NDsnOS9gbTQ5ODM5OC96YG5naH18e2w0MDs9azlvOT0+bT1oa2s7aGgwamxqPzAwbDs8OmxrPj88MD4+azo9PS99NDg+Pzs6OT47MDkveGBtNDxIPDhkSGN5OTg/Pj46JDxIPDhkSGN4OTg/Pj46L3tqeX00WmZse2xnJ0JoZWx6emxJbX5tJ21sL2o0PDsvYW1lNDk=&url=https%3a%2f%2fgithub.com%2feclipse-imagen%2fimagen%2fissues%2f118>  <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVs5MjYyOSV1PjEtMyVqZz4zMjkzMiVwamRtYnd2cWY+NDE1YDExNTs1ZjpnNTEwZzIyZmU7NmE7O2ZmZWFgYjJnMzA0NmY1NSV3PjI0NTI6MTM0OzolcmpnPjY6VUZSV3FGMzEyMTswLjY6VUZSV3FFMzEyMTswJXFgc3c+UGxmcWZtLUhib2ZwcGZDZ3RnLWdmJWA+NjEla2dvPjM=&url=https%3a%2f%2fgithub.com%2feclipse-imagen%2fimagen%2fissues%2f118>  and there is a PR attached https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVA0Pzs/NCh4MzwgPihnajM+PzQ+Pyh9Z2lgb3p7fGszOmxrOTdqams6Ozk/OTs3PGg7PTo9Oj1qN2s2Nm84Pms2OTw2Pm0/PSh6Mz85ODw9PTg4PToof2dqMztPOzd4S1pmPjw8PD85IztPOzd4S1pnPjw8PD85KHxtfnozXWFrfGtgIEVvYmt9fWtOanlqIGprKG0zOzwoZmpiMz4=&url=https%3a%2f%2fgithub.com%2feclipse-imagen%2fimagen%2fpull%2f119  <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVUzODw4My9/NDsnOS9gbTQ5ODM5OC96YG5naH18e2w0ajxsOGtoaj9sbzs9ODhvOG1qaDFqbTowPTg8Pzs4PWhoOzs/OT1vPi99NDg+Pzs6OT47MDkveGBtNDxIPDhkSGN5OTg/Pj46JDxIPDhkSGN4OTg/Pj46L3tqeX00WmZse2xnJ0JoZWx6emxJbX5tJ21sL2o0PDsvYW1lNDk=&url=https%3a%2f%2fgithub.com%2feclipse-imagen%2fimagen%2fpull%2f119>  <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVs5MjYyOSV1PjEtMyVqZz4zMjkzMiVwamRtYnd2cWY+ZmVgNDplZTRlYWY0NWUzZ2BlMjA3M2UzZTU1MGdmNjQ6Zzc1MGdnNyV3PjI0NTI6MTM0OzolcmpnPjY6VUZSV3FGMzEyMTswLjY6VUZSV3FFMzEyMTswJXFgc3c+UGxmcWZtLUhib2ZwcGZDZ3RnLWdmJWA+NjEla2dvPjM=&url=https%3a%2f%2fgithub.com%2feclipse-imagen%2fimagen%2fpull%2f119> . 
	
	        I wonder if there's any chance the problem can be solved soon as it currently prevents us from upgrading to GeoServer 2.28.x. 
	
	        Thanks and Best Regards
	        Sören 
	
	        -----Ursprüngliche Nachricht-----
	        Von: Jody Garnett <jod...@gm... <mailto:jod...@gm...>  <mailto:jod...@gm... <mailto:jod...@gm...> > > 
	        Gesendet: Mittwoch, 22. Oktober 2025 20:57
	        An: GeoTools Users <geo...@li... <mailto:geo...@li...>  <mailto:geo...@li... <mailto:geo...@li...> > >
	        Betreff: [Geotools-gt2-users] GeoTools 34.0 released for Java 17 with Eclipse ImageN processing engine
	
	        The GeoTools team is pleased to announce the release <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVE3PDg8Nyt7MD8jPStkaTA9PDc9PCt+ZGpjbHl4f2gwazk7bj5uNG8+Oj5saW5ub2s4NT5raW5paWg+bGw+bjs0OT41azw9PCt5MDw6Ozw8ODQ1OjsrfGRpMDg0QEc5bGFpPT85NDs4IDg0QEc5bGFoPT85NDs4K39ufXkwXmJof2hjI0ZsYWh+fmhNaXppI2loK24wNT0rZWlhMD0=&url=https%3a%2f%2fgeotoolsnews.blogspot.com%2f2025%2f10%2fgeotools-340-release.html>  of the latest stable version of GeoTools 34.0 <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVE3PDg8Nyt7MD8jPStkaTA9PDc9PCt+ZGpjbHl4f2gwbDU1azU5OWhpaT9sbG5rPTRuPmw9ND9rOWg7NGhuPDU9Oz88aWtsOit5MDw6Ozw8ODQ1OjsrfGRpMDg0QEc5bGFpPT85NDs4IDg0QEc5bGFoPT85NDs4K39ufXkwXmJof2hjI0ZsYWh+fmhNaXppI2loK24wOD8rZWlhMD0=&url=https%3a%2f%2fsourceforge.net%2fprojects%2fgeotools%2ffiles%2fGeoTools%252034%2520Releases%2f34.0%2f> . This release is available from the repo.osgeo.org <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVUzODw4My9/NDsnOS9gbTQ5ODM5OC96YG5naH18e2w0PWtvPTBobDk6Pjs/MDloPDg7aGhsbTs4bTBsaz9sOjkxPWxoaGw5bC99NDg+Pzs6OT47MDkveGBtNDxIPDhkSGN5OTg/Pj46JDxIPDhkSGN4OTg/Pj46L3tqeX00WmZse2xnJ0JoZWx6emxJbX5tJ21sL2o0PDsvYW1lNDk=&url=http%3a%2f%2frepo.osgeo.org>  <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVs5MjYyOSV1PjEtMyVqZz4zMjkzMiVwamRtYnd2cWY+YGFhNzE3MmAxNDM1YmJlNjNhOzpiYTpiYjc6NGU6N2BiNTRiOjQyZiV3PjI0NTI6MTM0OzolcmpnPjY6VUZSV3FGMzEyMTswLjY6VUZSV3FFMzEyMTswJXFgc3c+UGxmcWZtLUhib2ZwcGZDZ3RnLWdmJWA+NjEla2dvPjM=&url=http%3a%2f%2frepo.osgeo.org>  <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVE3PDg8Nyt7MD8jPStkaTA9PDc9PCt+ZGpjbHl4f2gwbGw0Pms+O2g7NDs/aD84NT47PjloPj48O2g6PGw7OGxpbDg+aG44byt5MDw6Ozw8ODQ1OjsrfGRpMDg0QEc5bGFpPT85NDs4IDg0QEc5bGFoPT85NDs4K39ufXkwXmJof2hjI0ZsYWh+fmhNaXppI2loK24wOD8rZWlhMD0=&url=http%3a%2f%2frepo.osgeo.org>  and is made in conjunction with ImageN 0.9.0, ImageIO-Ext 2.0.0, GeoWebCache 1.28.0, and GeoServer 2.28.0.
	
	        This is a major update:
	
	        *       The library now requires Java 17, ending support for Java 11
	
	        *       Upgrade from Java Advanced Imaging Library 1.1.3 to Eclipse ImageN 0.9.0.
	
	        *       Library now provides a maven bill-of-materials import for both library modules and third-party-dependences making it considerably easier for downstream projects to synchronize dependences when upgrading GeoTools
	
	        *       For more information please see upgrade instructions <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVE3PDg8Nyt7MD8jPStkaTA9PDc9PCt+ZGpjbHl4f2gwNDk1bjo7P2s0bms0OTk9aTo+a287a2k8PzlvbjhuaTw9PjtoPj81NSt5MDw6Ozw8ODQ1OjsrfGRpMDg0QEc5bGFpPT85NDs4IDg0QEc5bGFoPT85NDs4K39ufXkwXmJof2hjI0ZsYWh+fmhNaXppI2loK24wOD8rZWlhMD0=&url=https%3a%2f%2fdocs.geotools.org%2fstable%2fuserguide%2fwelcome%2fupgrade.html>  in the user manual
	
	        Thanks to Jody Garnett (GeoCat) for making this release, Gabriel Roldan (Camptocamp) for all the build improvements, and Andrea Aime (GeoServer) for working so hard on the Eclipse ImageN migration.
	
	        These major library updates were undertaken as part of the GeoServer 3 activities, and we would like to the crowdfunding sponsors their financial support.
	
	        _______________________________________________
	        GeoTools-GT2-Users mailing list
	        Geo...@li... <mailto:Geo...@li...>  <mailto:Geo...@li... <mailto:Geo...@li...> > 
	        https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVA0Pzs/NCh4MzwgPihnajM+PzQ+Pyh9Z2lgb3p7fGszPjZvNj46OTw7OTc/Ozs4aDc+PDttO21oPDxrPmg7OGpvazdob283Pyh6Mz85ODw9PTg4PToof2dqMztPOzd4S1pmPjw8PD85IztPOzd4S1pnPjw8PD85KHxtfnozXWFrfGtgIEVvYmt9fWtOanlqIGprKG0zOzwoZmpiMz4=&url=https%3a%2f%2flists.sourceforge.net%2flists%2flistinfo%2fgeotools-gt2-users  <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVUzODw4My9/NDsnOS9gbTQ5ODM5OC96YG5naH18e2w0PG88aDw7OW05Pj5rPGs5MTgwMG8xOTs/MG87Pj86aD4/PD86bTtqOS99NDg+Pzs6OT47MDkveGBtNDxIPDhkSGN5OTg/Pj46JDxIPDhkSGN4OTg/Pj46L3tqeX00WmZse2xnJ0JoZWx6emxJbX5tJ21sL2o0PDsvYW1lNDk=&url=https%3a%2f%2flists.sourceforge.net%2flists%2flistinfo%2fgeotools-gt2-users>  <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVs5MjYyOSV1PjEtMyVqZz4zMjkzMiVwamRtYnd2cWY+Zmc0OmBnYDViNTA1NDdmMzMyNTQ6ZmIxYmcxNTJnNTMyNGJiNDU2NiV3PjI0NTI6MTM0OzolcmpnPjY6VUZSV3FGMzEyMTswLjY6VUZSV3FFMzEyMTswJXFgc3c+UGxmcWZtLUhib2ZwcGZDZ3RnLWdmJWA+NjEla2dvPjM=&url=https%3a%2f%2flists.sourceforge.net%2flists%2flistinfo%2fgeotools-gt2-users> 
	
	
	
	_______________________________________________
	GeoTools-GT2-Users mailing list
	Geo...@li... <mailto:Geo...@li...> 
	https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVA0Pzs/NCh4MzwgPihnajM+PzQ+Pyh9Z2lgb3p7fGszPjZvNj46OTw7OTc/Ozs4aDc+PDttO21oPDxrPmg7OGpvazdob283Pyh6Mz85ODw9PTg4PToof2dqMztPOzd4S1pmPjw8PD85IztPOzd4S1pnPjw8PD85KHxtfnozXWFrfGtgIEVvYmt9fWtOanlqIGprKG0zOzwoZmpiMz4=&url=https%3a%2f%2flists.sourceforge.net%2flists%2flistinfo%2fgeotools-gt2-users  <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVUzODw4My9/NDsnOS9gbTQ5ODM5OC96YG5naH18e2w0PG88aDw7OW05Pj5rPGs5MTgwMG8xOTs/MG87Pj86aD4/PD86bTtqOS99NDg+Pzs6OT47MDkveGBtNDxIPDhkSGN5OTg/Pj46JDxIPDhkSGN4OTg/Pj46L3tqeX00WmZse2xnJ0JoZWx6emxJbX5tJ21sL2o0PDsvYW1lNDk=&url=https%3a%2f%2flists.sourceforge.net%2flists%2flistinfo%2fgeotools-gt2-users> 
	


_______________________________________________
GeoTools-GT2-Users mailing list
Geo...@li...
https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVA0Pzs/NCh4MzwgPihnajM+PzQ+Pyh9Z2lgb3p7fGszPjZvNj46OTw7OTc/Ozs4aDc+PDttO21oPDxrPmg7OGpvazdob283Pyh6Mz85ODw9PTg4PToof2dqMztPOzd4S1pmPjw8PD85IztPOzd4S1pnPjw8PD85KHxtfnozXWFrfGtgIEVvYmt9fWtOanlqIGprKG0zOzwoZmpiMz4=&url=https%3a%2f%2flists.sourceforge.net%2flists%2flistinfo%2fgeotools-gt2-users 

Re: [Geotools-gt2-users] GeoTools 34.0 released for Java 17 with Eclipse ImageN processing engine

[Kalesse S. <Soe...@dw...>]

Hi Jody, 

Ok, I can make a PR, but with that all renaming happening, it'll be quite some big change and probably PRs needed for GeoTools and GeoServer as well, right? ... and all other libs that are already using ImageN. 

I am very sorry but I really need to emphasize again, that the registry files are not the problem here! ImageN and JAI seem to be able to cope with them even though they have the same name (registryFile.jai). I have tested it locally running ImageN and JAI in the same application and they do not interfere at all. I was able to run GeoServer 2.28.0 that uses ImageN and still use our own JAI operators based on JAI core 1.1.3 without any problems at all. 

Really, the problem here are those invalid Java ServiceLoader definitions. 

    modules/crop/src/main/resources/META-INF/services/javax.media.jai.OperationRegistrySpi
    modules/jiffle/jt-jiffle-op/src/main/resources/META-INF/services/javax.media.jai.OperationsRegistrySpi
    modules/vectorize/src/main/resources/META-INF/services/javax.media.jai.OperationsRegistrySpi

The first one (crop) tries registering at JAI operation registry, which is wrong. This will cause a ClassCastException in JAI. 
The other two (jiffle and vectorize) try the same thing but even worse, the interface names are wrong --> OperationsRegistrySpi vs. OperationRegistrySpi. So these two will simply be ignored, because that interface does not exist. 

I could fix the names of the ServiceLoader definitions --> org.eclipse.imagen.OperationRegistrySpi. That would please Java at least. So that's good, but ImageN will no longer work, because as mentioned earlier, ImageN registry cannot currently not deal with two mechanisms being in place at the same time. Fixing the names will do this (Example taken from the Jiffle test cases):

[ERROR] org.eclipse.imagen.media.jiffleop.NoSourceTest.createSequentialImage -- Time elapsed: 0 s <<< ERROR!
java.lang.NoClassDefFoundError: Could not initialize class org.eclipse.imagen.ImageN
	at org.eclipse.imagen.media.jiffleop.NoSourceTest.reset(NoSourceTest.java:82)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
	at org.junit.internal.runners.statements.RunAfters.invokeMethod(RunAfters.java:46)
	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33)
	at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
	at org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
Caused by: java.lang.ExceptionInInitializerError: Exception java.lang.IllegalArgumentException: A descriptor is already registered against the name "Jiffle" under registry mode "rendered" [in thread "main"]
	at org.eclipse.imagen.DescriptorCache.addDescriptor(DescriptorCache.java:144)
	at org.eclipse.imagen.OperationRegistry.registerDescriptor(OperationRegistry.java:580)
	at org.eclipse.imagen.ThreadSafeOperationRegistry.registerDescriptor(ThreadSafeOperationRegistry.java:156)
	at org.eclipse.imagen.media.jiffleop.JiffleSpi.updateRegistry(JiffleSpi.java:73)
	at org.eclipse.imagen.OperationRegistry.registerServices(OperationRegistry.java:1556)
	at org.eclipse.imagen.ThreadSafeOperationRegistry.registerServices(ThreadSafeOperationRegistry.java:529)
	at org.eclipse.imagen.OperationRegistry.initializeRegistry(OperationRegistry.java:311)
	at org.eclipse.imagen.ImageN.<clinit>(ImageN.java:351)

The descriptor cache does not allow an operation to be registered twice. That is why I am saying that fixing the ServiceLoader definitions won't help at all. The only options I see is:

 1. make descriptor cache support registry definitions coming from multiple places at the same time 
   ---> I am not sure if that's really a good idea
 2. remove the ServiceLoader definitions from those three libs

I am wondering anyway, why is it that only those three libs do have ServiceLoader files at all? What about the other libs? Not a single other lib has any ServiceLoader definition at all.

My PR#119 did exactly that. It removed the ServiceLoader definitions from those three libs. That's all it did and that fixed it all. No renaming of registryFile.jai required. 

To summarize: 
============

 I can make a PR that renames all registryFile.jai --> registryFile.imagen and changes the ImageN registry to use those instead - no problem. 

But that will not help with the initial problem, we need to deal with those ServiceLoader files - fixing their names to match the correct interface will not help. On the contrary, it will make it worse, because ImageN will no longer initialize, because it cannot handle both (registryFile.[jai|imagen] and ServiceLoader) at the same time.

My proposal is to go by the initial PR and remove the ServiceLoader files all together for these three modules that have them (crop, jiffle, vectorize).

What do you think?
Thanks
Sören


-----Ursprüngliche Nachricht-----
Von: Jody Garnett <jod...@gm...> 
Gesendet: Mittwoch, 5. November 2025 02:47
An: Kalesse Sören <ska...@ex...>
Cc: GeoTools Users <geo...@li...>
Betreff: Re: [Geotools-gt2-users] GeoTools 34.0 released for Java 17 with Eclipse ImageN processing engine

So ideally we should fix the invalid definitions, and rename the files to end with “imagen”.

If you make a PR I am willing to do a 0.9.1 relate; and Gabe offered to make a geotools release on schedule next week. 

- -

Jody Garnett


On Mon, Nov 3, 2025 at 11:12 PM Kalesse Sören <Soe...@dw... <mailto:Soe...@dw...> > wrote:


	Hi Andrea, 
	
	That's exactly my point. I  do assume that it was not intended for these two to coexist, but it should just work fine because there are two different registries and the operations interfaces are different, so in theory these two do not collide at all. That gives all users a good "workaround" to live with until applications and libraries have succeeded to migrate. 
	
	And that's also exactly where my PR comes in. The three mentioned ImageN libraries (and only those three!) contain ServiceLoader definitions that are wrong. The register the ImageN operations at the JAI registry. That leads to class cast exceptions (wrong interfaces). That's the point that must definitely be fixed whatsoever.
	
	Now that fixed, here arises the second aspect: Right now you cannot mix standard ImageN and ServiceLoader registration. ImageN does not support that. It will fail to initialize if one operation had already been registered by that other means. So you must decide: either support multiple ways of registration in the ImageN core or decide upon one and let it go. 
	
	Therefore my PR removes the three ServiceLoader definitions: 1) because they were wrong and 2) because that is the least invasive fix to make ImageN initialize correctly. The PR#119 was tested locally running GeoServer 2.2.8.0 and another application that uses JAI and it worked just fine.
	
	I hope you can agree that this is a proper fix and should be part in one of the next releases. For us it is a show-stopper for upgrading to GT 33.x / GS 2.28.x. 
	
	Thanks!
	Sören
	
	-----Ursprüngliche Nachricht-----
	Von: Andrea Aime <and...@ge... <mailto:and...@ge...> > 
	Gesendet: Freitag, 31. Oktober 2025 15:25
	An: Kalesse Sören <ska...@ex... <mailto:ska...@ex...> >
	Cc: GeoTools Users <geo...@li... <mailto:geo...@li...> >
	Betreff: Re: [Geotools-gt2-users] GeoTools 34.0 released for Java 17 with Eclipse ImageN processing engine
	
	Hi,
	I second what Jody said, there was no plan to make the coexist, it's an upgrade path.
	However... I believe that a coexistence could be possible, the java packages
	are different, so by having ImageN use a different file name for the registry files in META-INF, 
	from registryFile.jai to registryFile.imagen, a coexistence might be possible, even if likely
	wasteful (two separate image processing caches in memory are not the greatest of ideas).
	
	A coexistence is just not in our plans, but since ImageN is not yet available as 1.0, if DWD wants
	to put the development effort to get it done, I would not be against it.
	I see this applicable to the GeoServer 3.0 series.
	
	I would recommend switching existing software to ImageN though, we prepared migration scripts
	that should help in the endeavor.
	
	Regards,
	
	Andrea Aime
	
	
	
	
	==
	
	
	GeoServer Professional Services from the experts!
	
	Visit http://bit.ly/gs-services-us <http://bit.ly/gs-services-us>  for more information.
	
	
	
	==
	
	Ing. Andrea Aime 
	@geowolf
	Technical Lead
	
	
	
	GeoSolutions Group
	phone: +39 0584 962313
	
	fax:     +39 0584 1660272
	
	mob:   +39  339 8844549
	
	
	https://www.geosolutionsgroup.com/ <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVUzODw4My9/NDsnOS9gbTQ5ODM5OC96YG5naH18e2w0bTs+Ozo+bDtqajtqMDsxPT1qOmg5PD49MDE+Omwwam0xMWprbzE4Oy99NDg+Pzs6OT47MDkveGBtNDxIPDhkSGN5OTg/Pj46JDxIPDhkSGN4OTg/Pj46L3tqeX00WmZse2xnJ0JoZWx6emxJbX5tJ21sL2o0PDsvYW1lNDk=&url=https%3a%2f%2fwww.geosolutionsgroup.com%2f>  <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVs5MjYyOSV1PjEtMyVqZz4zMjkzMiVwamRtYnd2cWY+Ozs6OjQ2MTAyM2Y1MDU1NjQxZzFiOzUwMWA0ZjAwZzQwNzA6ZTY2NCV3PjI0NTI6MTM0OzolcmpnPjY6VUZSV3FGMzEyMTswLjY6VUZSV3FFMzEyMTswJXFgc3c+UGxmcWZtLUhib2ZwcGZDZ3RnLWdmJWA+NjEla2dvPjM=&url=https%3a%2f%2fwww.geosolutionsgroup.com%2f> 
	
	http://twitter.com/geosolutions_it <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVUzODw4My9/NDsnOS9gbTQ5ODM5OC96YG5naH18e2w0PWg9bW1obzFqaGpsPz5sbToxa2xrPjA9PW06PDBobDk5bG09a2s5bS99NDg+Pzs6OT47MDkveGBtNDxIPDhkSGN5OTg/Pj46JDxIPDhkSGN4OTg/Pj46L3tqeX00WmZse2xnJ0JoZWx6emxJbX5tJ21sL2o0Oj4vYW1lNDk=&url=http%3a%2f%2ftwitter.com%2fgeosolutions_it>  <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVs5MjYyOSV1PjEtMyVqZz4zMjkzMiVwamRtYnd2cWY+MDplNTQ7ZzM6YTozNmU7NGY1OjtmZzdnYTIzYjIwYmJmNGU2MDBgZiV3PjI0NTI6MTM0OzolcmpnPjY6VUZSV3FGMzEyMTswLjY6VUZSV3FFMzEyMTswJXFgc3c+UGxmcWZtLUhib2ZwcGZDZ3RnLWdmJWA+MDQla2dvPjM=&url=http%3a%2f%2ftwitter.com%2fgeosolutions_it> 
	
	-------------------------------------------------------
	
	
	Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia.
	
	This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail
	
	
	
	On Thu, Oct 30, 2025 at 5:29 PM Kalesse Sören <Soe...@dw... <mailto:Soe...@dw...>  <mailto:Soe...@dw... <mailto:Soe...@dw...> > > wrote:
	
	
	        Hi,
	
	        thanks for the new release! We have noticed a problem though, that deals with environments where GeoTools (and now ImageN) and JAI are used at the same time. I have documented the issue at https://github.com/eclipse-imagen/imagen/issues/118 <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVUzODw4My9/NDsnOS9gbTQ5ODM5OC96YG5naH18e2w0MDs9azlvOT0+bT1oa2s7aGgwamxqPzAwbDs8OmxrPj88MD4+azo9PS99NDg+Pzs6OT47MDkveGBtNDxIPDhkSGN5OTg/Pj46JDxIPDhkSGN4OTg/Pj46L3tqeX00WmZse2xnJ0JoZWx6emxJbX5tJ21sL2o0PDsvYW1lNDk=&url=https%3a%2f%2fgithub.com%2feclipse-imagen%2fimagen%2fissues%2f118>  <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVs5MjYyOSV1PjEtMyVqZz4zMjkzMiVwamRtYnd2cWY+NDE1YDExNTs1ZjpnNTEwZzIyZmU7NmE7O2ZmZWFgYjJnMzA0NmY1NSV3PjI0NTI6MTM0OzolcmpnPjY6VUZSV3FGMzEyMTswLjY6VUZSV3FFMzEyMTswJXFgc3c+UGxmcWZtLUhib2ZwcGZDZ3RnLWdmJWA+NjEla2dvPjM=&url=https%3a%2f%2fgithub.com%2feclipse-imagen%2fimagen%2fissues%2f118>  and there is a PR attached https://github.com/eclipse-imagen/imagen/pull/119 <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVUzODw4My9/NDsnOS9gbTQ5ODM5OC96YG5naH18e2w0ajxsOGtoaj9sbzs9ODhvOG1qaDFqbTowPTg8Pzs4PWhoOzs/OT1vPi99NDg+Pzs6OT47MDkveGBtNDxIPDhkSGN5OTg/Pj46JDxIPDhkSGN4OTg/Pj46L3tqeX00WmZse2xnJ0JoZWx6emxJbX5tJ21sL2o0PDsvYW1lNDk=&url=https%3a%2f%2fgithub.com%2feclipse-imagen%2fimagen%2fpull%2f119>  <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVs5MjYyOSV1PjEtMyVqZz4zMjkzMiVwamRtYnd2cWY+ZmVgNDplZTRlYWY0NWUzZ2BlMjA3M2UzZTU1MGdmNjQ6Zzc1MGdnNyV3PjI0NTI6MTM0OzolcmpnPjY6VUZSV3FGMzEyMTswLjY6VUZSV3FFMzEyMTswJXFgc3c+UGxmcWZtLUhib2ZwcGZDZ3RnLWdmJWA+NjEla2dvPjM=&url=https%3a%2f%2fgithub.com%2feclipse-imagen%2fimagen%2fpull%2f119> . 
	
	        I wonder if there's any chance the problem can be solved soon as it currently prevents us from upgrading to GeoServer 2.28.x. 
	
	        Thanks and Best Regards
	        Sören 
	
	        -----Ursprüngliche Nachricht-----
	        Von: Jody Garnett <jod...@gm... <mailto:jod...@gm...>  <mailto:jod...@gm... <mailto:jod...@gm...> > > 
	        Gesendet: Mittwoch, 22. Oktober 2025 20:57
	        An: GeoTools Users <geo...@li... <mailto:geo...@li...>  <mailto:geo...@li... <mailto:geo...@li...> > >
	        Betreff: [Geotools-gt2-users] GeoTools 34.0 released for Java 17 with Eclipse ImageN processing engine
	
	        The GeoTools team is pleased to announce the release <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVE3PDg8Nyt7MD8jPStkaTA9PDc9PCt+ZGpjbHl4f2gwazk7bj5uNG8+Oj5saW5ub2s4NT5raW5paWg+bGw+bjs0OT41azw9PCt5MDw6Ozw8ODQ1OjsrfGRpMDg0QEc5bGFpPT85NDs4IDg0QEc5bGFoPT85NDs4K39ufXkwXmJof2hjI0ZsYWh+fmhNaXppI2loK24wNT0rZWlhMD0=&url=https%3a%2f%2fgeotoolsnews.blogspot.com%2f2025%2f10%2fgeotools-340-release.html>  of the latest stable version of GeoTools 34.0 <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVE3PDg8Nyt7MD8jPStkaTA9PDc9PCt+ZGpjbHl4f2gwbDU1azU5OWhpaT9sbG5rPTRuPmw9ND9rOWg7NGhuPDU9Oz88aWtsOit5MDw6Ozw8ODQ1OjsrfGRpMDg0QEc5bGFpPT85NDs4IDg0QEc5bGFoPT85NDs4K39ufXkwXmJof2hjI0ZsYWh+fmhNaXppI2loK24wOD8rZWlhMD0=&url=https%3a%2f%2fsourceforge.net%2fprojects%2fgeotools%2ffiles%2fGeoTools%252034%2520Releases%2f34.0%2f> . This release is available from the repo.osgeo.org <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVUzODw4My9/NDsnOS9gbTQ5ODM5OC96YG5naH18e2w0PWtvPTBobDk6Pjs/MDloPDg7aGhsbTs4bTBsaz9sOjkxPWxoaGw5bC99NDg+Pzs6OT47MDkveGBtNDxIPDhkSGN5OTg/Pj46JDxIPDhkSGN4OTg/Pj46L3tqeX00WmZse2xnJ0JoZWx6emxJbX5tJ21sL2o0PDsvYW1lNDk=&url=http%3a%2f%2frepo.osgeo.org>  <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVs5MjYyOSV1PjEtMyVqZz4zMjkzMiVwamRtYnd2cWY+YGFhNzE3MmAxNDM1YmJlNjNhOzpiYTpiYjc6NGU6N2BiNTRiOjQyZiV3PjI0NTI6MTM0OzolcmpnPjY6VUZSV3FGMzEyMTswLjY6VUZSV3FFMzEyMTswJXFgc3c+UGxmcWZtLUhib2ZwcGZDZ3RnLWdmJWA+NjEla2dvPjM=&url=http%3a%2f%2frepo.osgeo.org>  <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVE3PDg8Nyt7MD8jPStkaTA9PDc9PCt+ZGpjbHl4f2gwbGw0Pms+O2g7NDs/aD84NT47PjloPj48O2g6PGw7OGxpbDg+aG44byt5MDw6Ozw8ODQ1OjsrfGRpMDg0QEc5bGFpPT85NDs4IDg0QEc5bGFoPT85NDs4K39ufXkwXmJof2hjI0ZsYWh+fmhNaXppI2loK24wOD8rZWlhMD0=&url=http%3a%2f%2frepo.osgeo.org>  and is made in conjunction with ImageN 0.9.0, ImageIO-Ext 2.0.0, GeoWebCache 1.28.0, and GeoServer 2.28.0.
	
	        This is a major update:
	
	        *       The library now requires Java 17, ending support for Java 11
	
	        *       Upgrade from Java Advanced Imaging Library 1.1.3 to Eclipse ImageN 0.9.0.
	
	        *       Library now provides a maven bill-of-materials import for both library modules and third-party-dependences making it considerably easier for downstream projects to synchronize dependences when upgrading GeoTools
	
	        *       For more information please see upgrade instructions <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVE3PDg8Nyt7MD8jPStkaTA9PDc9PCt+ZGpjbHl4f2gwNDk1bjo7P2s0bms0OTk9aTo+a287a2k8PzlvbjhuaTw9PjtoPj81NSt5MDw6Ozw8ODQ1OjsrfGRpMDg0QEc5bGFpPT85NDs4IDg0QEc5bGFoPT85NDs4K39ufXkwXmJof2hjI0ZsYWh+fmhNaXppI2loK24wOD8rZWlhMD0=&url=https%3a%2f%2fdocs.geotools.org%2fstable%2fuserguide%2fwelcome%2fupgrade.html>  in the user manual
	
	        Thanks to Jody Garnett (GeoCat) for making this release, Gabriel Roldan (Camptocamp) for all the build improvements, and Andrea Aime (GeoServer) for working so hard on the Eclipse ImageN migration.
	
	        These major library updates were undertaken as part of the GeoServer 3 activities, and we would like to the crowdfunding sponsors their financial support.
	
	        _______________________________________________
	        GeoTools-GT2-Users mailing list
	        Geo...@li... <mailto:Geo...@li...>  <mailto:Geo...@li... <mailto:Geo...@li...> > 
	        https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVUzODw4My9/NDsnOS9gbTQ5ODM5OC96YG5naH18e2w0PG88aDw7OW05Pj5rPGs5MTgwMG8xOTs/MG87Pj86aD4/PD86bTtqOS99NDg+Pzs6OT47MDkveGBtNDxIPDhkSGN5OTg/Pj46JDxIPDhkSGN4OTg/Pj46L3tqeX00WmZse2xnJ0JoZWx6emxJbX5tJ21sL2o0PDsvYW1lNDk=&url=https%3a%2f%2flists.sourceforge.net%2flists%2flistinfo%2fgeotools-gt2-users>  <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVs5MjYyOSV1PjEtMyVqZz4zMjkzMiVwamRtYnd2cWY+Zmc0OmBnYDViNTA1NDdmMzMyNTQ6ZmIxYmcxNTJnNTMyNGJiNDU2NiV3PjI0NTI6MTM0OzolcmpnPjY6VUZSV3FGMzEyMTswLjY6VUZSV3FFMzEyMTswJXFgc3c+UGxmcWZtLUhib2ZwcGZDZ3RnLWdmJWA+NjEla2dvPjM=&url=https%3a%2f%2flists.sourceforge.net%2flists%2flistinfo%2fgeotools-gt2-users> 
	
	
	
	_______________________________________________
	GeoTools-GT2-Users mailing list
	Geo...@li... <mailto:Geo...@li...> 
	https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVUzODw4My9/NDsnOS9gbTQ5ODM5OC96YG5naH18e2w0PG88aDw7OW05Pj5rPGs5MTgwMG8xOTs/MG87Pj86aD4/PD86bTtqOS99NDg+Pzs6OT47MDkveGBtNDxIPDhkSGN5OTg/Pj46JDxIPDhkSGN4OTg/Pj46L3tqeX00WmZse2xnJ0JoZWx6emxJbX5tJ21sL2o0PDsvYW1lNDk=&url=https%3a%2f%2flists.sourceforge.net%2flists%2flistinfo%2fgeotools-gt2-users> 
	

Re: [Geotools-gt2-users] GeoTools 34.0 released for Java 17 with Eclipse ImageN processing engine

[Jody G. <jod...@gm...>]

So ideally we should fix the invalid definitions, and rename the files to
end with “imagen”.

If you make a PR I am willing to do a 0.9.1 relate; and Gabe offered to
make a geotools release on schedule next week.

- -
Jody Garnett


On Mon, Nov 3, 2025 at 11:12 PM Kalesse Sören <Soe...@dw...> wrote:

> Hi Andrea,
>
> That's exactly my point. I  do assume that it was not intended for these
> two to coexist, but it should just work fine because there are two
> different registries and the operations interfaces are different, so in
> theory these two do not collide at all. That gives all users a good
> "workaround" to live with until applications and libraries have succeeded
> to migrate.
>
> And that's also exactly where my PR comes in. The three mentioned ImageN
> libraries (and only those three!) contain ServiceLoader definitions that
> are wrong. The register the ImageN operations at the JAI registry. That
> leads to class cast exceptions (wrong interfaces). That's the point that
> must definitely be fixed whatsoever.
>
> Now that fixed, here arises the second aspect: Right now you cannot mix
> standard ImageN and ServiceLoader registration. ImageN does not support
> that. It will fail to initialize if one operation had already been
> registered by that other means. So you must decide: either support multiple
> ways of registration in the ImageN core or decide upon one and let it go.
>
> Therefore my PR removes the three ServiceLoader definitions: 1) because
> they were wrong and 2) because that is the least invasive fix to make
> ImageN initialize correctly. The PR#119 was tested locally running
> GeoServer 2.2.8.0 and another application that uses JAI and it worked just
> fine.
>
> I hope you can agree that this is a proper fix and should be part in one
> of the next releases. For us it is a show-stopper for upgrading to GT 33.x
> / GS 2.28.x.
>
> Thanks!
> Sören
>
> -----Ursprüngliche Nachricht-----
> Von: Andrea Aime <and...@ge...>
> Gesendet: Freitag, 31. Oktober 2025 15:25
> An: Kalesse Sören <ska...@ex...>
> Cc: GeoTools Users <geo...@li...>
> Betreff: Re: [Geotools-gt2-users] GeoTools 34.0 released for Java 17 with
> Eclipse ImageN processing engine
>
> Hi,
> I second what Jody said, there was no plan to make the coexist, it's an
> upgrade path.
> However... I believe that a coexistence could be possible, the java
> packages
> are different, so by having ImageN use a different file name for the
> registry files in META-INF,
> from registryFile.jai to registryFile.imagen, a coexistence might be
> possible, even if likely
> wasteful (two separate image processing caches in memory are not the
> greatest of ideas).
>
> A coexistence is just not in our plans, but since ImageN is not yet
> available as 1.0, if DWD wants
> to put the development effort to get it done, I would not be against it.
> I see this applicable to the GeoServer 3.0 series.
>
> I would recommend switching existing software to ImageN though, we
> prepared migration scripts
> that should help in the endeavor.
>
> Regards,
>
> Andrea Aime
>
>
>
>
> ==
>
>
> GeoServer Professional Services from the experts!
>
> Visit http://bit.ly/gs-services-us <http://bit.ly/gs-services-us>  for
> more information.
>
>
>
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
>
>
> GeoSolutions Group
> phone: +39 0584 962313
>
> fax:     +39 0584 1660272
>
> mob:   +39  339 8844549
>
>
> https://www.geosolutionsgroup.com/ <
> https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVs5MjYyOSV1PjEtMyVqZz4zMjkzMiVwamRtYnd2cWY+Ozs6OjQ2MTAyM2Y1MDU1NjQxZzFiOzUwMWA0ZjAwZzQwNzA6ZTY2NCV3PjI0NTI6MTM0OzolcmpnPjY6VUZSV3FGMzEyMTswLjY6VUZSV3FFMzEyMTswJXFgc3c+UGxmcWZtLUhib2ZwcGZDZ3RnLWdmJWA+NjEla2dvPjM=&url=https%3a%2f%2fwww.geosolutionsgroup.com%2f>
>
>
> http://twitter.com/geosolutions_it <
> https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVs5MjYyOSV1PjEtMyVqZz4zMjkzMiVwamRtYnd2cWY+MDplNTQ7ZzM6YTozNmU7NGY1OjtmZzdnYTIzYjIwYmJmNGU2MDBgZiV3PjI0NTI6MTM0OzolcmpnPjY6VUZSV3FGMzEyMTswLjY6VUZSV3FFMzEyMTswJXFgc3c+UGxmcWZtLUhib2ZwcGZDZ3RnLWdmJWA+MDQla2dvPjM=&url=http%3a%2f%2ftwitter.com%2fgeosolutions_it>
>
>
> -------------------------------------------------------
>
>
> Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE
> 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si
> precisa che ogni circostanza inerente alla presente email (il suo
> contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è
> riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il
> messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra
> operazione è illecita. Le sarei comunque grato se potesse darmene notizia.
>
> This email is intended only for the person or entity to which it is
> addressed and may contain information that is privileged, confidential or
> otherwise protected from disclosure. We remind that - as provided by
> European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
> e-mail or the information herein by anyone other than the intended
> recipient is prohibited. If you have received this email by mistake, please
> notify us immediately by telephone or e-mail
>
>
>
> On Thu, Oct 30, 2025 at 5:29 PM Kalesse Sören <Soe...@dw...
> <mailto:Soe...@dw...> > wrote:
>
>
>         Hi,
>
>         thanks for the new release! We have noticed a problem though, that
> deals with environments where GeoTools (and now ImageN) and JAI are used at
> the same time. I have documented the issue at
> https://github.com/eclipse-imagen/imagen/issues/118 <
> https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVs5MjYyOSV1PjEtMyVqZz4zMjkzMiVwamRtYnd2cWY+NDE1YDExNTs1ZjpnNTEwZzIyZmU7NmE7O2ZmZWFgYjJnMzA0NmY1NSV3PjI0NTI6MTM0OzolcmpnPjY6VUZSV3FGMzEyMTswLjY6VUZSV3FFMzEyMTswJXFgc3c+UGxmcWZtLUhib2ZwcGZDZ3RnLWdmJWA+NjEla2dvPjM=&url=https%3a%2f%2fgithub.com%2feclipse-imagen%2fimagen%2fissues%2f118>
> and there is a PR attached
> https://github.com/eclipse-imagen/imagen/pull/119 <
> https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVs5MjYyOSV1PjEtMyVqZz4zMjkzMiVwamRtYnd2cWY+ZmVgNDplZTRlYWY0NWUzZ2BlMjA3M2UzZTU1MGdmNjQ6Zzc1MGdnNyV3PjI0NTI6MTM0OzolcmpnPjY6VUZSV3FGMzEyMTswLjY6VUZSV3FFMzEyMTswJXFgc3c+UGxmcWZtLUhib2ZwcGZDZ3RnLWdmJWA+NjEla2dvPjM=&url=https%3a%2f%2fgithub.com%2feclipse-imagen%2fimagen%2fpull%2f119>
> .
>
>         I wonder if there's any chance the problem can be solved soon as
> it currently prevents us from upgrading to GeoServer 2.28.x.
>
>         Thanks and Best Regards
>         Sören
>
>         -----Ursprüngliche Nachricht-----
>         Von: Jody Garnett <jod...@gm... <mailto:
> jod...@gm...> >
>         Gesendet: Mittwoch, 22. Oktober 2025 20:57
>         An: GeoTools Users <geo...@li...
> <mailto:geo...@li...> >
>         Betreff: [Geotools-gt2-users] GeoTools 34.0 released for Java 17
> with Eclipse ImageN processing engine
>
>         The GeoTools team is pleased to announce the release <
> https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVE3PDg8Nyt7MD8jPStkaTA9PDc9PCt+ZGpjbHl4f2gwazk7bj5uNG8+Oj5saW5ub2s4NT5raW5paWg+bGw+bjs0OT41azw9PCt5MDw6Ozw8ODQ1OjsrfGRpMDg0QEc5bGFpPT85NDs4IDg0QEc5bGFoPT85NDs4K39ufXkwXmJof2hjI0ZsYWh+fmhNaXppI2loK24wNT0rZWlhMD0=&url=https%3a%2f%2fgeotoolsnews.blogspot.com%2f2025%2f10%2fgeotools-340-release.html>
> of the latest stable version of GeoTools 34.0 <
> https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVE3PDg8Nyt7MD8jPStkaTA9PDc9PCt+ZGpjbHl4f2gwbDU1azU5OWhpaT9sbG5rPTRuPmw9ND9rOWg7NGhuPDU9Oz88aWtsOit5MDw6Ozw8ODQ1OjsrfGRpMDg0QEc5bGFpPT85NDs4IDg0QEc5bGFoPT85NDs4K39ufXkwXmJof2hjI0ZsYWh+fmhNaXppI2loK24wOD8rZWlhMD0=&url=https%3a%2f%2fsourceforge.net%2fprojects%2fgeotools%2ffiles%2fGeoTools%252034%2520Releases%2f34.0%2f>
> . This release is available from the repo.osgeo.org <
> https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVs5MjYyOSV1PjEtMyVqZz4zMjkzMiVwamRtYnd2cWY+YGFhNzE3MmAxNDM1YmJlNjNhOzpiYTpiYjc6NGU6N2BiNTRiOjQyZiV3PjI0NTI6MTM0OzolcmpnPjY6VUZSV3FGMzEyMTswLjY6VUZSV3FFMzEyMTswJXFgc3c+UGxmcWZtLUhib2ZwcGZDZ3RnLWdmJWA+NjEla2dvPjM=&url=http%3a%2f%2frepo.osgeo.org>
> <
> https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVE3PDg8Nyt7MD8jPStkaTA9PDc9PCt+ZGpjbHl4f2gwbGw0Pms+O2g7NDs/aD84NT47PjloPj48O2g6PGw7OGxpbDg+aG44byt5MDw6Ozw8ODQ1OjsrfGRpMDg0QEc5bGFpPT85NDs4IDg0QEc5bGFoPT85NDs4K39ufXkwXmJof2hjI0ZsYWh+fmhNaXppI2loK24wOD8rZWlhMD0=&url=http%3a%2f%2frepo.osgeo.org>
> and is made in conjunction with ImageN 0.9.0, ImageIO-Ext 2.0.0,
> GeoWebCache 1.28.0, and GeoServer 2.28.0.
>
>         This is a major update:
>
>         *       The library now requires Java 17, ending support for Java
> 11
>
>         *       Upgrade from Java Advanced Imaging Library 1.1.3 to
> Eclipse ImageN 0.9.0.
>
>         *       Library now provides a maven bill-of-materials import for
> both library modules and third-party-dependences making it considerably
> easier for downstream projects to synchronize dependences when upgrading
> GeoTools
>
>         *       For more information please see upgrade instructions <
> https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVE3PDg8Nyt7MD8jPStkaTA9PDc9PCt+ZGpjbHl4f2gwNDk1bjo7P2s0bms0OTk9aTo+a287a2k8PzlvbjhuaTw9PjtoPj81NSt5MDw6Ozw8ODQ1OjsrfGRpMDg0QEc5bGFpPT85NDs4IDg0QEc5bGFoPT85NDs4K39ufXkwXmJof2hjI0ZsYWh+fmhNaXppI2loK24wOD8rZWlhMD0=&url=https%3a%2f%2fdocs.geotools.org%2fstable%2fuserguide%2fwelcome%2fupgrade.html>
> in the user manual
>
>         Thanks to Jody Garnett (GeoCat) for making this release, Gabriel
> Roldan (Camptocamp) for all the build improvements, and Andrea Aime
> (GeoServer) for working so hard on the Eclipse ImageN migration.
>
>         These major library updates were undertaken as part of the
> GeoServer 3 activities, and we would like to the crowdfunding sponsors
> their financial support.
>
>         _______________________________________________
>         GeoTools-GT2-Users mailing list
>         Geo...@li... <mailto:
> Geo...@li...>
>         https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users <
> https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVs5MjYyOSV1PjEtMyVqZz4zMjkzMiVwamRtYnd2cWY+Zmc0OmBnYDViNTA1NDdmMzMyNTQ6ZmIxYmcxNTJnNTMyNGJiNDU2NiV3PjI0NTI6MTM0OzolcmpnPjY6VUZSV3FGMzEyMTswLjY6VUZSV3FFMzEyMTswJXFgc3c+UGxmcWZtLUhib2ZwcGZDZ3RnLWdmJWA+NjEla2dvPjM=&url=https%3a%2f%2flists.sourceforge.net%2flists%2flistinfo%2fgeotools-gt2-users>
>
>
>
>
> _______________________________________________
> GeoTools-GT2-Users mailing list
> Geo...@li...
> https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
>

Re: [Geotools-gt2-users] GeoTools 34.0 released for Java 17 with Eclipse ImageN processing engine

[Kalesse S. <Soe...@dw...>]

Hi Andrea, 

That's exactly my point. I  do assume that it was not intended for these two to coexist, but it should just work fine because there are two different registries and the operations interfaces are different, so in theory these two do not collide at all. That gives all users a good "workaround" to live with until applications and libraries have succeeded to migrate. 

And that's also exactly where my PR comes in. The three mentioned ImageN libraries (and only those three!) contain ServiceLoader definitions that are wrong. The register the ImageN operations at the JAI registry. That leads to class cast exceptions (wrong interfaces). That's the point that must definitely be fixed whatsoever.

Now that fixed, here arises the second aspect: Right now you cannot mix standard ImageN and ServiceLoader registration. ImageN does not support that. It will fail to initialize if one operation had already been registered by that other means. So you must decide: either support multiple ways of registration in the ImageN core or decide upon one and let it go. 

Therefore my PR removes the three ServiceLoader definitions: 1) because they were wrong and 2) because that is the least invasive fix to make ImageN initialize correctly. The PR#119 was tested locally running GeoServer 2.2.8.0 and another application that uses JAI and it worked just fine.

I hope you can agree that this is a proper fix and should be part in one of the next releases. For us it is a show-stopper for upgrading to GT 33.x / GS 2.28.x. 

Thanks!
Sören

-----Ursprüngliche Nachricht-----
Von: Andrea Aime <and...@ge...> 
Gesendet: Freitag, 31. Oktober 2025 15:25
An: Kalesse Sören <ska...@ex...>
Cc: GeoTools Users <geo...@li...>
Betreff: Re: [Geotools-gt2-users] GeoTools 34.0 released for Java 17 with Eclipse ImageN processing engine

Hi,
I second what Jody said, there was no plan to make the coexist, it's an upgrade path.
However... I believe that a coexistence could be possible, the java packages
are different, so by having ImageN use a different file name for the registry files in META-INF, 
from registryFile.jai to registryFile.imagen, a coexistence might be possible, even if likely
wasteful (two separate image processing caches in memory are not the greatest of ideas).

A coexistence is just not in our plans, but since ImageN is not yet available as 1.0, if DWD wants
to put the development effort to get it done, I would not be against it.
I see this applicable to the GeoServer 3.0 series.

I would recommend switching existing software to ImageN though, we prepared migration scripts
that should help in the endeavor.

Regards,

Andrea Aime




==


GeoServer Professional Services from the experts!

Visit http://bit.ly/gs-services-us <http://bit.ly/gs-services-us>  for more information.



==

Ing. Andrea Aime 
@geowolf
Technical Lead



GeoSolutions Group
phone: +39 0584 962313

fax:     +39 0584 1660272

mob:   +39  339 8844549


https://www.geosolutionsgroup.com/ <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVs5MjYyOSV1PjEtMyVqZz4zMjkzMiVwamRtYnd2cWY+Ozs6OjQ2MTAyM2Y1MDU1NjQxZzFiOzUwMWA0ZjAwZzQwNzA6ZTY2NCV3PjI0NTI6MTM0OzolcmpnPjY6VUZSV3FGMzEyMTswLjY6VUZSV3FFMzEyMTswJXFgc3c+UGxmcWZtLUhib2ZwcGZDZ3RnLWdmJWA+NjEla2dvPjM=&url=https%3a%2f%2fwww.geosolutionsgroup.com%2f> 

http://twitter.com/geosolutions_it <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVs5MjYyOSV1PjEtMyVqZz4zMjkzMiVwamRtYnd2cWY+MDplNTQ7ZzM6YTozNmU7NGY1OjtmZzdnYTIzYjIwYmJmNGU2MDBgZiV3PjI0NTI6MTM0OzolcmpnPjY6VUZSV3FGMzEyMTswLjY6VUZSV3FFMzEyMTswJXFgc3c+UGxmcWZtLUhib2ZwcGZDZ3RnLWdmJWA+MDQla2dvPjM=&url=http%3a%2f%2ftwitter.com%2fgeosolutions_it> 

-------------------------------------------------------


Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia.

This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail



On Thu, Oct 30, 2025 at 5:29 PM Kalesse Sören <Soe...@dw... <mailto:Soe...@dw...> > wrote:


	Hi,
	
	thanks for the new release! We have noticed a problem though, that deals with environments where GeoTools (and now ImageN) and JAI are used at the same time. I have documented the issue at https://github.com/eclipse-imagen/imagen/issues/118 <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVs5MjYyOSV1PjEtMyVqZz4zMjkzMiVwamRtYnd2cWY+NDE1YDExNTs1ZjpnNTEwZzIyZmU7NmE7O2ZmZWFgYjJnMzA0NmY1NSV3PjI0NTI6MTM0OzolcmpnPjY6VUZSV3FGMzEyMTswLjY6VUZSV3FFMzEyMTswJXFgc3c+UGxmcWZtLUhib2ZwcGZDZ3RnLWdmJWA+NjEla2dvPjM=&url=https%3a%2f%2fgithub.com%2feclipse-imagen%2fimagen%2fissues%2f118>  and there is a PR attached https://github.com/eclipse-imagen/imagen/pull/119 <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVs5MjYyOSV1PjEtMyVqZz4zMjkzMiVwamRtYnd2cWY+ZmVgNDplZTRlYWY0NWUzZ2BlMjA3M2UzZTU1MGdmNjQ6Zzc1MGdnNyV3PjI0NTI6MTM0OzolcmpnPjY6VUZSV3FGMzEyMTswLjY6VUZSV3FFMzEyMTswJXFgc3c+UGxmcWZtLUhib2ZwcGZDZ3RnLWdmJWA+NjEla2dvPjM=&url=https%3a%2f%2fgithub.com%2feclipse-imagen%2fimagen%2fpull%2f119> . 
	
	I wonder if there's any chance the problem can be solved soon as it currently prevents us from upgrading to GeoServer 2.28.x. 
	
	Thanks and Best Regards
	Sören 
	
	-----Ursprüngliche Nachricht-----
	Von: Jody Garnett <jod...@gm... <mailto:jod...@gm...> > 
	Gesendet: Mittwoch, 22. Oktober 2025 20:57
	An: GeoTools Users <geo...@li... <mailto:geo...@li...> >
	Betreff: [Geotools-gt2-users] GeoTools 34.0 released for Java 17 with Eclipse ImageN processing engine
	
	The GeoTools team is pleased to announce the release <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVE3PDg8Nyt7MD8jPStkaTA9PDc9PCt+ZGpjbHl4f2gwazk7bj5uNG8+Oj5saW5ub2s4NT5raW5paWg+bGw+bjs0OT41azw9PCt5MDw6Ozw8ODQ1OjsrfGRpMDg0QEc5bGFpPT85NDs4IDg0QEc5bGFoPT85NDs4K39ufXkwXmJof2hjI0ZsYWh+fmhNaXppI2loK24wNT0rZWlhMD0=&url=https%3a%2f%2fgeotoolsnews.blogspot.com%2f2025%2f10%2fgeotools-340-release.html>  of the latest stable version of GeoTools 34.0 <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVE3PDg8Nyt7MD8jPStkaTA9PDc9PCt+ZGpjbHl4f2gwbDU1azU5OWhpaT9sbG5rPTRuPmw9ND9rOWg7NGhuPDU9Oz88aWtsOit5MDw6Ozw8ODQ1OjsrfGRpMDg0QEc5bGFpPT85NDs4IDg0QEc5bGFoPT85NDs4K39ufXkwXmJof2hjI0ZsYWh+fmhNaXppI2loK24wOD8rZWlhMD0=&url=https%3a%2f%2fsourceforge.net%2fprojects%2fgeotools%2ffiles%2fGeoTools%252034%2520Releases%2f34.0%2f> . This release is available from the repo.osgeo.org <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVs5MjYyOSV1PjEtMyVqZz4zMjkzMiVwamRtYnd2cWY+YGFhNzE3MmAxNDM1YmJlNjNhOzpiYTpiYjc6NGU6N2BiNTRiOjQyZiV3PjI0NTI6MTM0OzolcmpnPjY6VUZSV3FGMzEyMTswLjY6VUZSV3FFMzEyMTswJXFgc3c+UGxmcWZtLUhib2ZwcGZDZ3RnLWdmJWA+NjEla2dvPjM=&url=http%3a%2f%2frepo.osgeo.org>  <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVE3PDg8Nyt7MD8jPStkaTA9PDc9PCt+ZGpjbHl4f2gwbGw0Pms+O2g7NDs/aD84NT47PjloPj48O2g6PGw7OGxpbDg+aG44byt5MDw6Ozw8ODQ1OjsrfGRpMDg0QEc5bGFpPT85NDs4IDg0QEc5bGFoPT85NDs4K39ufXkwXmJof2hjI0ZsYWh+fmhNaXppI2loK24wOD8rZWlhMD0=&url=http%3a%2f%2frepo.osgeo.org>  and is made in conjunction with ImageN 0.9.0, ImageIO-Ext 2.0.0, GeoWebCache 1.28.0, and GeoServer 2.28.0.
	
	This is a major update:
	
	*       The library now requires Java 17, ending support for Java 11
	
	*       Upgrade from Java Advanced Imaging Library 1.1.3 to Eclipse ImageN 0.9.0.
	
	*       Library now provides a maven bill-of-materials import for both library modules and third-party-dependences making it considerably easier for downstream projects to synchronize dependences when upgrading GeoTools
	
	*       For more information please see upgrade instructions <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVE3PDg8Nyt7MD8jPStkaTA9PDc9PCt+ZGpjbHl4f2gwNDk1bjo7P2s0bms0OTk9aTo+a287a2k8PzlvbjhuaTw9PjtoPj81NSt5MDw6Ozw8ODQ1OjsrfGRpMDg0QEc5bGFpPT85NDs4IDg0QEc5bGFoPT85NDs4K39ufXkwXmJof2hjI0ZsYWh+fmhNaXppI2loK24wOD8rZWlhMD0=&url=https%3a%2f%2fdocs.geotools.org%2fstable%2fuserguide%2fwelcome%2fupgrade.html>  in the user manual
	
	Thanks to Jody Garnett (GeoCat) for making this release, Gabriel Roldan (Camptocamp) for all the build improvements, and Andrea Aime (GeoServer) for working so hard on the Eclipse ImageN migration.
	
	These major library updates were undertaken as part of the GeoServer 3 activities, and we would like to the crowdfunding sponsors their financial support.
	
	_______________________________________________
	GeoTools-GT2-Users mailing list
	Geo...@li... <mailto:Geo...@li...> 
	https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVs5MjYyOSV1PjEtMyVqZz4zMjkzMiVwamRtYnd2cWY+Zmc0OmBnYDViNTA1NDdmMzMyNTQ6ZmIxYmcxNTJnNTMyNGJiNDU2NiV3PjI0NTI6MTM0OzolcmpnPjY6VUZSV3FGMzEyMTswLjY6VUZSV3FFMzEyMTswJXFgc3c+UGxmcWZtLUhib2ZwcGZDZ3RnLWdmJWA+NjEla2dvPjM=&url=https%3a%2f%2flists.sourceforge.net%2flists%2flistinfo%2fgeotools-gt2-users> 
	

Re: [Geotools-gt2-users] GeoTools 34.0 released for Java 17 with Eclipse ImageN processing engine

[Kalesse S. <Soe...@dw...>]

Hi Jody, 

that would be a disaster for many applications that had been using GeoTools as well as JAI for many years. While I agree that migration should be done, imagine how so many applications exist outside that cannot make that migration in a rush.  JAI has been there for many years without an alternative and is therefore built into applications deep down at their core. It's very unlikely that each and every application can now go and replace just like that - funding, resources, testing rollout etc..

And on the other hand. Why can I not use JAI and ImageN at the same time? That's exactly the point. Both can coexist at the same time. They have their own registries and their own set of operations. I don't see why they cannot? 

The only problem exists when the registries intermingle, which is what happens here and what is the bug in ImageN: The Java ServiceLoader definitions of the ImageN libraries register the ImageN operations at the wrong registry (JAI). They are using the wrong interfaces. Independent of JAI / ImageN, that will not work in Java at all and must be fixed. That's what the PR tried to do. Then, it turned out that when fixing ServiceLoader it still won't work, because then operations get registered twice - of course, because ImageN seems to be using two different mechanisms at the same time for registration of operations, but the registry cannot cope with it. 

Something must be fixed here: 

1) ServiceLoader definitions must be fixed, oherwise they will never work at all. That's Java.
2) With ServiceLoader definitions fixed, ImageN must decide to either
  a) support multiple ways of registration, then it must not fail to initialize if a operation was registered by some other means.
  b) decide to support one way of registration and go for that. 

My PR tries a least invasive fix, by removing the 3 wrong ServiceLoader defintions (2b). That will fix the registration and lets both ImageN and JAI live very well in one application. 

Thanks!
Sören

-----Ursprüngliche Nachricht-----
Von: Jody Garnett <jod...@gm...> 
Gesendet: Freitag, 31. Oktober 2025 09:02
An: Kalesse Sören <ska...@ex...>
Cc: GeoTools Users <geo...@li...>
Betreff: Re: [Geotools-gt2-users] GeoTools 34.0 released for Java 17 with Eclipse ImageN processing engine

You cannot use ImageN and JAI at the same time. ImageN is in effect JAI 2.0 


- -

Jody Garnett


On Thu, Oct 30, 2025 at 17:29 Kalesse Sören <Soe...@dw... <mailto:Soe...@dw...> > wrote:


	Hi,
	
	thanks for the new release! We have noticed a problem though, that deals with environments where GeoTools (and now ImageN) and JAI are used at the same time. I have documented the issue at https://github.com/eclipse-imagen/imagen/issues/118 <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVMxOj46MS19NjklOy1ibzY7OjE7Oi14Ymxlan9+eW42OjJqPD9tMzw7Ozxoaj04OTptOj84P2g7Oz8/aj1ub29paW0+OTI9ai1/Njo8PTozMjw8Mz0temJvNj4yXTM4PU1+Ozs4MjI+Jj4yXTM4PU19Ozs4MjI+LXloe382WGRueW5lJUBqZ254eG5Lb3xvJW9uLWg2PjktY29nNjs=&url=https%3a%2f%2fgithub.com%2feclipse-imagen%2fimagen%2fissues%2f118>  and there is a PR attached https://github.com/eclipse-imagen/imagen/pull/119 <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVMxOj46MS19NjklOy1ibzY7OjE7Oi14Ymxlan9+eW42MjppODxoPW0yPDI4bmkzOTk5OTgzOjwzPmlvMmg5bj4/ajxobmpuPC1/Njo8PTozMjw8Mz0temJvNj4yXTM4PU1+Ozs4MjI+Jj4yXTM4PU19Ozs4MjI+LXloe382WGRueW5lJUBqZ254eG5Lb3xvJW9uLWg2PjktY29nNjs=&url=https%3a%2f%2fgithub.com%2feclipse-imagen%2fimagen%2fpull%2f119> . 
	
	I wonder if there's any chance the problem can be solved soon as it currently prevents us from upgrading to GeoServer 2.28.x. 
	
	Thanks and Best Regards
	Sören 
	
	-----Ursprüngliche Nachricht-----
	Von: Jody Garnett <jod...@gm... <mailto:jod...@gm...> > 
	Gesendet: Mittwoch, 22. Oktober 2025 20:57
	An: GeoTools Users <geo...@li... <mailto:geo...@li...> >
	Betreff: [Geotools-gt2-users] GeoTools 34.0 released for Java 17 with Eclipse ImageN processing engine
	
	The GeoTools team is pleased to announce the release <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVE3PDg8Nyt7MD8jPStkaTA9PDc9PCt+ZGpjbHl4f2gwazk7bj5uNG8+Oj5saW5ub2s4NT5raW5paWg+bGw+bjs0OT41azw9PCt5MDw6Ozw8ODQ1OjsrfGRpMDg0QEc5bGFpPT85NDs4IDg0QEc5bGFoPT85NDs4K39ufXkwXmJof2hjI0ZsYWh+fmhNaXppI2loK24wNT0rZWlhMD0=&url=https%3a%2f%2fgeotoolsnews.blogspot.com%2f2025%2f10%2fgeotools-340-release.html>  of the latest stable version of GeoTools 34.0 <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVE3PDg8Nyt7MD8jPStkaTA9PDc9PCt+ZGpjbHl4f2gwbDU1azU5OWhpaT9sbG5rPTRuPmw9ND9rOWg7NGhuPDU9Oz88aWtsOit5MDw6Ozw8ODQ1OjsrfGRpMDg0QEc5bGFpPT85NDs4IDg0QEc5bGFoPT85NDs4K39ufXkwXmJof2hjI0ZsYWh+fmhNaXppI2loK24wOD8rZWlhMD0=&url=https%3a%2f%2fsourceforge.net%2fprojects%2fgeotools%2ffiles%2fGeoTools%252034%2520Releases%2f34.0%2f> . This release is available from the repo.osgeo.org <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVMxOj46MS19NjklOy1ibzY7OjE7Oi14Ymxlan9+eW42Om9tPT84aG4zam08Om84ODlvbTo6Oj09Mm8yOD5vP2hqOzI5bz45Py1/Njo8PTozMjw8Mz0temJvNj4yXTM4PU1+Ozs4MjI+Jj4yXTM4PU19Ozs4MjI+LXloe382WGRueW5lJUBqZ254eG5Lb3xvJW9uLWg2PjktY29nNjs=&url=http%3a%2f%2frepo.osgeo.org>  <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVE3PDg8Nyt7MD8jPStkaTA9PDc9PCt+ZGpjbHl4f2gwbGw0Pms+O2g7NDs/aD84NT47PjloPj48O2g6PGw7OGxpbDg+aG44byt5MDw6Ozw8ODQ1OjsrfGRpMDg0QEc5bGFpPT85NDs4IDg0QEc5bGFoPT85NDs4K39ufXkwXmJof2hjI0ZsYWh+fmhNaXppI2loK24wOD8rZWlhMD0=&url=http%3a%2f%2frepo.osgeo.org>  and is made in conjunction with ImageN 0.9.0, ImageIO-Ext 2.0.0, GeoWebCache 1.28.0, and GeoServer 2.28.0.
	
	This is a major update:
	
	*       The library now requires Java 17, ending support for Java 11
	
	*       Upgrade from Java Advanced Imaging Library 1.1.3 to Eclipse ImageN 0.9.0.
	
	*       Library now provides a maven bill-of-materials import for both library modules and third-party-dependences making it considerably easier for downstream projects to synchronize dependences when upgrading GeoTools
	
	*       For more information please see upgrade instructions <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVE3PDg8Nyt7MD8jPStkaTA9PDc9PCt+ZGpjbHl4f2gwNDk1bjo7P2s0bms0OTk9aTo+a287a2k8PzlvbjhuaTw9PjtoPj81NSt5MDw6Ozw8ODQ1OjsrfGRpMDg0QEc5bGFpPT85NDs4IDg0QEc5bGFoPT85NDs4K39ufXkwXmJof2hjI0ZsYWh+fmhNaXppI2loK24wOD8rZWlhMD0=&url=https%3a%2f%2fdocs.geotools.org%2fstable%2fuserguide%2fwelcome%2fupgrade.html>  in the user manual
	
	Thanks to Jody Garnett (GeoCat) for making this release, Gabriel Roldan (Camptocamp) for all the build improvements, and Andrea Aime (GeoServer) for working so hard on the Eclipse ImageN migration.
	
	These major library updates were undertaken as part of the GeoServer 3 activities, and we would like to the crowdfunding sponsors their financial support.
	
	_______________________________________________
	GeoTools-GT2-Users mailing list
	Geo...@li... <mailto:Geo...@li...> 
	https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVMxOj46MS19NjklOy1ibzY7OjE7Oi14Ymxlan9+eW42aW5vb2k4OT9paD1tPjlvOjppamlvaG89M288bTM8PW5qbzk6M209bS1/Njo8PTozMjw8Mz0temJvNj4yXTM4PU1+Ozs4MjI+Jj4yXTM4PU19Ozs4MjI+LXloe382WGRueW5lJUBqZ254eG5Lb3xvJW9uLWg2PjktY29nNjs=&url=https%3a%2f%2flists.sourceforge.net%2flists%2flistinfo%2fgeotools-gt2-users>