Hi Alan,
> Looks okay to me too, except @SuppressWarnings("unused") looks strange,
> is that an Eclipse compiler warning name?
Yes, it comes from Eclipse, probably only used by its compiler. The private
field EXIT_SYSERR doesn't seem to be used. Alternatively, I could comment it
out? Or remove
Hi Claes,
thanks for your quick review. I configured my IDE to go to wildcard at 10
imports from the same package. But if there's a common style guide for OpenJDK,
I can certainly reconfigure this.
Best regards
Christoph
> -Original Message-
> From: Claes Redestad
> Sent: Sonntag,
On 19/04/2020 17:31, Claes Redestad wrote:
Looks good to me, Christoph,
JmodTask.java: Not sure what the consensus is about wildcard imports,
but I'm fine with it here.
Looks okay to me too, except @SuppressWarnings("unused") looks strange,
is that an Eclipse compiler warning name?
-Alan
Looks good to me, Christoph,
JmodTask.java: Not sure what the consensus is about wildcard imports,
but I'm fine with it here.
/Claes
On 2020-04-19 17:32, Langer, Christoph wrote:
Hi,
please help review this cleanup patch for the Java code in module jdk.jlink.
It's mostly automatic IDE
Hi,
please help review this cleanup patch for the Java code in module jdk.jlink.
It's mostly automatic IDE cleanups of unused imports plus a few removals for
unused private methods, fields and annotations. I've also added some @Override
annotations where such were missing.
Bug:
On 19/04/2020 16:05, Uwe Schindler wrote:
Hi Alan,
from what I understood: He has some utility method in a shared class that wraps
ServiceLoader to discover services and do something with it (the usual way to
prevent code duplication). Problem is that ServiceLoade.load() is
caller-sensitive,
Hi Alan
Yes, you read that correctly. Do you mean that in ServiceProvider that is in
moduleA we
will do something like this:
if (!SerivceProvider.class.getModule().canUse(S)) {
SerivceProvider.class.getModule().addUses(S)
}
//here we some logic and return S service.
Best regards
Hi Alan,
from what I understood: He has some utility method in a shared class that wraps
ServiceLoader to discover services and do something with it (the usual way to
prevent code duplication). Problem is that ServiceLoade.load() is
caller-sensitive, so a shared utility method only sees the
On 19/04/2020 15:00, Alex Sviridov wrote:
Hi all,
Let's suppose we have modules (A, B, C..) and every module consumes and provides services.
To find these services I want to create one util class, for example
ServiceProvider that will be used
by all modules to get necessary services. There
Hi all,
Let's suppose we have modules (A, B, C..) and every module consumes and
provides services.
To find these services I want to create one util class, for example
ServiceProvider that will be used
by all modules to get necessary services. There are two ideas:
* to have one point to
Hi,
The problem you see is that ServiceLoader.load() is caller-sensitive, so it has
to be called from the exact module that will use the service.
You can still have some utility method that works on an already instantiated
service loader:
1. The utility class/method just takes a ServiceLoader
>
> Directories with a ".jar" suffix is clever but I don't think it gets away
> from the substantive issue that Java SE only specifies how automatic
> modules come into being when they are packaged as JAR files. I could also
> imagine tools and libraries that scan tripping up on directories named
On 18/04/2020 23:04, Eirik Bjørsnøs wrote:
:
Could we update ModulePath could to detect "automatic module
directories"?. Any directory path name ending with ".jar" could be
loaded as an automatic directory module, with the same semantics as if
the directory was zipped into a JAR.
This
13 matches
Mail list logo
