Re: Removing jsr305

> did you try to add a module-info.java in jEdit ?

Not before, as I don't see any benefits, as described above.
But yes, now I also tried it in jEdit and it works perfectly fine,
though I still don't see why we should do that, so even if it were a problem it would not be for jEdit.

> I tried and got a split package error,

I have no idea how you managed that.

> I am of course not the only one, and it seems the solution for everybody is to replace the lib which is obsolete in my opinion.

"everybody" here just means the ones not managing to just use it and publicly complaining.
The people that manage to use it, don't publicly brag about it, especially as there is not much necessary to use it.
Even if it is a bit outdated, it still serves its purpose well and is supported by all usual tools by default.
Replacing with one of the competitors might be fine, if you find one that is compatible license-wise, but that would then again be a question for someone that knows exactly how you can combine different licenses, or a lawyer.

> https://nipafx.dev/jsr-305-java-9/ for example.

That blog post is pretty irrelevant though.
It describes a problem with Java 9, where there indeed still were annotations in the `javax.annotation` package in the standard JDK in the module `java.xml.ws.annotation`.
So there indeed was a split-package problem, that you would then have to mitigate for example using `--patch-module`, which would also have been ok as it is just a compile dependency, not a runtime dependency.

But the whole module and classes were removed in Java 11 which is even now our minimum version,
so the split-package is gone as long as we do not add a dependency to a second module with that package, which is unlikely.

> I don't like the idea of not being able to test it and maybe see advantages

I'm curious, tell me if you find any.
In the meantime I'd suggest that we revert your commit that inlines those annotations.
I attached for you the changes I did to compile as JPMS module, based on the revision before your changes.

> Do you have in mind some tools you use that could not be configured for that ?

Sure, many tools can be configured.
I don't know whether all.
But the point is, that you then do need to configure them,
while with the supported annotations, it will just work out-of-the-box.

Cheers
Björn

Am 14.10.2023 08:50, schrieb Matthieu Casanova:
> Hey,
> did you try to add a module-info.java in jEdit ?
> I tried and got a split package error, I am of course not the only one, and it seems the solution for everybody is to replace the lib which is obsolete in my opinion.
> https://nipafx.dev/jsr-305-java-9/ for example.
> I have no strong opinion about the fact of making jEdit a JPMS but I don't like the idea of not being able to test it and maybe see advantages.
> About replacing the annotations my intention would have been to use something widely used like jakarta annotations, but there is a different licence.
> About the tools that uses those annotations I think most of them should be configurable as most major projects (Eclipse, Spring and many others define their own similar annotations). At least IntelliJ Idea is configurable for Nullable and Nonnull. Do you have in mind some tools you use that could not be configured for that ?
>
> -- 
>   Matthieu Casanova
>   [email protected] <mailto:[email protected]>
>
>
> Ven 13 oct 2023, à 23:35, Vampire a écrit :
>> Hi
>>
>> Where did you actually see that problem and what exactly?
>>
>> I checked in Java 11 and Java 21 and in both there are only things within `javax.annotation.processing`.
>> In the jsr350 JAR are only things in `javax.annotation`, `javax.annotation.meta`,  and `javax.annotation.concurrent`, so there should not be a split-package problem there.
>>
>> I also quickly tried in a play project and it works like a charm.
>> jsr305 jar to the module path, a "requires transitive ..." clause to the module info, and all compiles just fine without complaint with both, Java 11 and Java 21.
>>
>> Besides that, it is imho anyway questionable whether jEdit should be made a JPMS module.
>> Which advantages do you see?
>> If we would start from scratch, it would maybe make sense.
>> And if we would have a clear definition of what Plugin API is and what not,
>> it would probably also be great to enforce this restriction by default.
>>
>> So unless we really want to define a clear Plugin API and forbid plugins to use anything else by default, it would maybe make sense.
>>
>> But even then, as I wrote above it should not be much of a problem to continue using the jsr305 annotations.
>> And it would probably even be preferable, as typically tools support these annotations,
>> but will not support the custom copies you made.
>>
>> What do you think?
>>
>> Cheers
>> Björn
>>
>>
>>
>>
>> Am 11.10.2023 21:24, schrieb Matthieu Casanova:
>>> Hey,
>>> years ago I added the google jsr305 library (annotations like Nonnull, Nullable) which is mostly a helper for IDE and documentation.
>>> Unfortunately that JSR was never aprooved which was not a problem until Java released the module system :
>>>
>>> Because those annotations were in javax package it caused problems when activating the module system introduced in Java 9 because javax is of course part of JRE so another library cannot provide the same package.
>>> So basically I created the same annotations in
>>>
>>> org.jedit.annotation package.
>>>
>>>
>>> Matthieu
>>>
>>>
>>>
>>>
>

-- 
-----------------------------------------------
jEdit Developers' List
[email protected]
https://lists.sourceforge.net/lists/listinfo/jedit-devel

Index: build.xml
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/build.xml b/build.xml
--- a/build.xml	(revision 25690)
+++ b/build.xml	(date 1697285630021)
@@ -220,13 +220,14 @@
 	</target>
 
 	<target name="compile"
-		depends="init">
+		depends="init,retrieve">
 		<mkdir dir="${classes.dir}/core"/>
 		<depend srcDir="${basedir}"
 			destDir="${classes.dir}/core"
 			cache="${classes.dir}"/>
 		<dependset>
 			<srcfilelist files="build.xml"/>
+			<srcfilelist files="module-info.java"/>
 			<targetfileset dir="${classes.dir}/core"/>
 		</dependset>
 		<javac srcdir="${basedir}"
@@ -239,10 +240,11 @@
 		       compiler="modern"
 		       encoding="UTF-8"
 		       includeAntRuntime="false">
-			<classpath id="classpath.compile">
+			<modulepath id="classpath.compile">
 				<fileset dir="${lib.dir}/compile"
 					 includes="*.jar"/>
-			</classpath>
+			</modulepath>
+			<include name="module-info.java"/>
 			<include name="org/**"/>
 			<compilerarg line="${config.build.compilerarg}"/>
 		</javac>
@@ -418,7 +420,7 @@
 	</target>
 
 	<target name="compile-textArea"
-		depends="init,prepare-textArea">
+		depends="init,retrieve,prepare-textArea">
 		<mkdir dir="${textAreaPackage}/build"/>
 		<javac srcdir="${textAreaPackage}/src"
 		       destdir="${textAreaPackage}/build"
Index: module-info.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/module-info.java b/module-info.java
new file mode 100644
--- /dev/null	(date 1697285843542)
+++ b/module-info.java	(date 1697285843542)
@@ -0,0 +1,27 @@
+/*
+ * module-info.java
+ * :tabSize=4:indentSize=4:noTabs=false:
+ * :folding=explicit:collapseFolds=1:
+ *
+ * Copyright (C) 2023 Björn Kautler
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.
+ */
+
+module org.jedit {
+	requires java.desktop;
+	requires java.net.http;
+	requires static jsr305;
+}