gt; have some basic tooling to help with exactly that approach but it has long
> been left behind. One reason is that potential for anarchy with several
> people converting the same library to a module. You might not like
> automatic modules but at least the module descriptors that are derived are
> very predictable (including the name).
>
> -Alan.
>
--
Best Regards,
Ali Ebrahimi
onal", which fits with the existing
> terminology used by maven for many years and more clearly indicates
> that users cannot rely on the dependency.
>
> Stephen
>
--
Best Regards,
Ali Ebrahimi
ce generally
> it's a _feature_ that the module system warns:
>
> java.lang.module.ResolutionException: Modules ant.junit4 and ant.junit
> export package org.apache.tools.ant.taskdefs.optional.junit
> to module hamcrest.core
>
> Alex
>
--
Best Regards,
Ali Ebrahimi
> >>>> :
> >>> >>>>
> >>> >>>> I don't particularly care what the mechanism is for this, but at
> the
> >>> >>>> requirements level:
> >>> >>>> - there are two modules - main and test
> >>> >>>> - each has its own source tree
> >>> >>>> - each has its own dependencies
> >>> >>>> - each is released separately
> >>> >>>> - each could be hosted on a central repo
> >>> >>>> - the test module needs to be able to contain the same packages as
> >>> the
> >>> >>>> main module
> >>> >>>> - the test module needs to be able to invoke package-scoped code
> in
> >>> >>>> the same package in the main module
> >>> >>>>
> >>> >>>> To clarify further consider 4 modules, A, B, A-test and B-test
> >>> where B
> >>> >>>> depends on A. Module A-test may have a method foo() that uses
> >>> package
> >>> >>>> scope to access something in A. Module B-test will depend on
> A-test
> >>> >>>> and rely on foo() to get access to that internal object.
> >>> >>> To your list, I would add the ability to make use of testing
> >>> frameworks
> >>> >>> like TestNG and JUnit.
> >>> >>>
> >>> >>> In any case, and as things currently stand, you've got most of the
> >>> >>> above. One differences is that the tests are not a separate module,
> >>> they
> >>> >>> are instead compiled and run in a way that patches the main module.
> >>> The
> >>> >>> second difference is that they don't have their own module
> >>> declaration,
> >>> >>> instead the compilation or run augments the dependences with any
> >>> >>> additional dependences that the tests have. As I said, if they
> tools
> >>> >>> makes it easy then I don't think it's too bad.
> >>> >>>
> >>> >>>>
> >>> >>>> (Note that I view the thread discussion of
> >>> >>>> references to test classes on the classpath as another hack.
> >>> >>>>
> >>> >>> Packages can't be split between modules and classpath so there is
> no
> >>> >>> support for that.
> >>> >>>
> >>> >>> -Alan
> >>> >>>
> >>>
> >>
> >
>
--
Best Regards,
Ali Ebrahimi
on-exported packages.
> > It has rudimentary support for user modules too. Additional dependences
> > are still an issue but our tests don't require additional dependences
> > beyond TestNG. The test harness employs a bit of hackery to get things
> > done, important when starting out, but I expect will go away in time.
> >
> > -Alan.
> >
> > [1]
> >
> http://hg.openjdk.java.net/code-tools/jtreg/raw-file/tip/src/share/doc/javatest/regtest/tag-spec.html
> >
> >
> >
>
--
Best Regards,
Ali Ebrahimi
r consider 4 modules, A, B, A-test and B-test where
> B
> >>>>> depends on A. Module A-test may have a method foo() that uses package
> >>>>> scope to access something in A. Module B-test will depend on A-test
> >>>>> and rely on foo() to get access to that internal object.
> >>>> To your list, I would add the ability to make use of testing
> frameworks
> >>>> like TestNG and JUnit.
> >>>>
> >>>> In any case, and as things currently stand, you've got most of the
> >>>> above. One differences is that the tests are not a separate module,
> they
> >>>> are instead compiled and run in a way that patches the main module.
> The
> >>>> second difference is that they don't have their own module
> declaration,
> >>>> instead the compilation or run augments the dependences with any
> >>>> additional dependences that the tests have. As I said, if they tools
> >>>> makes it easy then I don't think it's too bad.
> >>>>
> >>>>>
> >>>>> (Note that I view the thread discussion of
> >>>>> references to test classes on the classpath as another hack.
> >>>>>
> >>>> Packages can't be split between modules and classpath so there is no
> >>>> support for that.
> >>>>
> >>>> -Alan
> >>>>
> >
>
--
Best Regards,
Ali Ebrahimi
on or run augments the dependences with any
> > additional dependences that the tests have. As I said, if they tools
> > makes it easy then I don't think it's too bad.
> >
> > >
> > > (Note that I view the thread discussion of
> > > references to test classes on the classpath as another hack.
> > >
> > Packages can't be split between modules and classpath so there is no
> > support for that.
> >
> > -Alan
> >
>
--
Best Regards,
Ali Ebrahimi
Hi,
Can we all agree that native Optional dependency support would be clean,
best and reasonable solution.
On Fri, Dec 18, 2015 at 7:47 PM, Peter Levart
wrote:
> Hi Ali,
>
> On 12/18/2015 05:05 PM, Ali Ebrahimi wrote:
>
> Hi,
> In general, your workaround has some disadvanta
t there, it is simply ignored.
>>
>> So I think the safe "requires optional X" semantic would have to
>> be such that it acts as two descriptors:
>>
>> requires X - at compile time
>>
>> nothing - at runtime (no attempt to find the module and add it to
>> configuration)
>>
>> You would still have to put -addmods X to command line, but then
>> you would have a total control over configuration from
>> command-line only.
>>
>> Optional dependencies basically then just reduce to a means to
>> have two different descriptors: one for compile-time and one for
>> run-time, where run-time has a sub-set of requires from
>> compile-time descriptor. It can be done now (with separate
>> compilation), but it would be convenient to have a single
>> descriptor with two scopes of requires.
>>
>> Regards, Peter
>>
>>
>>
>
--
Best Regards,
Ali Ebrahimi
dentified a clear need for optional module
> dependencies in the jigsaw design, such that key information is not
> lost.
>
--
Best Regards,
Ali Ebrahimi
Hi,
On Sat, Dec 5, 2015 at 1:39 PM, Alan Bateman
wrote:
>
>
> On 05/12/2015 07:00, Ali Ebrahimi wrote:
>
>> :
>>
>> module FOO.aop{
>> implements FOO.api;
>> }
>>
>> In other word, consumer module doesn't know any think about imp
le FOO.debug{
implements FOO.api;
}
module FOO.aop{
implements FOO.api;
}
In other word, consumer module doesn't know any think about implementing
module since here we have contract and that is API module. think of today's
interface.
I think this would be much more powerful than service providers. So we have
api and implementation modules such that implementation modules can be
replaced without any change in consumer modules.
--
Best Regards,
Ali Ebrahimi
e code in Joda-Beans that
> actively calls Guava clases in addition to checking they exist by
> reflection.
>
I don't think this is optional dependency if you have static references to
Guava's types in source code.
--
Best Regards,
Ali Ebrahimi
Hi,
On Fri, Dec 4, 2015 at 5:12 PM, Alan Bateman
wrote:
>
> On 04/12/2015 12:27, Ali Ebrahimi wrote:
>
>
> Just as I said in another thread post:
>
> If we have module group concept and modules belong to same module group
> loaded by same classloader then we can suppor
ing Maven plugins supporting those options would
> be a great help.
Just as I said in another thread post:
If we have module group concept and modules belong to same module group
loaded by same classloader then we can support splited packages. This way
each module group maps to each classloader.
This will support test modules.
--
Best Regards,
Ali Ebrahimi
nd run the main module and hope the
> tests catch them.
If we have module group concept and modules belong to same module group
loaded by same classloader then we can support splited packages. This way
each module group maps to each classloader.
--
Best Regards,
Ali Ebrahimi
e B.
>
> "But B doesn't know anything about how A works. The shading was only to
> use a different version of A than was observable on the modulepath."
> OK, then shading A wasn't the right solution.
Yes, another option would be multi-layer configurations.
--
Best Regards,
Ali Ebrahimi
Hi,
On Wed, Nov 18, 2015 at 2:38 PM, Alan Bateman
wrote:
>
>
> On 18/11/2015 10:55, Ali Ebrahimi wrote:
>
> :
>
> Is there other options? (non-command-line options)
>
> As I said in one of the previous mails, there are a number of things that
> can be explored.
Hi,
On Wed, Nov 18, 2015 at 1:53 PM, Alan Bateman
wrote:
>
> On 18/11/2015 10:04, Ali Ebrahimi wrote:
>
> Hi,
> Currently only code inside java.base module can add (qualified)
> exports programmatically.
>
> Any module can export any of its packages to another module vi
gt; frameworks/containers working with us and helping to understand and work
> through the migration issues.
>
> -Alan
>
--
Best Regards,
Ali Ebrahimi
Thanks.
On Mon, Nov 16, 2015 at 8:04 PM, Philip Race wrote:
> This is a known issue and the fix should go into jdk9/dev in about 24
> hours.
> --disable-warnings-as-errors will work around it.
>
> -phil.
>
>
> On 11/16/15, 8:25 AM, Ali Ebrahimi wrote:
>
>
ed by a warning, try configure --disable-warnings-as-errors.
/cygdrive/f/openjdk/jake/make/Init.gmk:278: recipe for target 'main' failed
make[1]: *** [main] Error 1
/cygdrive/f/openjdk/jake/make/Init.gmk:182: recipe for target 'all' failed
make: *** [all] Error 2
--
Best Regards,
Ali Ebrahimi
is puzzling since with almost the equivalent code I get
>> another result. If you want I can show for you in another post.
>>
>
> It is puzzling. By specifying com.bar@2 as one of the root modules in
> cfg2, you have managed to get layer2's loader to load the class com.bar.Bar
> from com.bar@2. And code in module foo can access that class, despite
> module foo not reading any com.bar module.
>
I sent test files directly to your mail.
--
Best Regards,
Ali Ebrahimi
Hi,
On Fri, Nov 6, 2015 at 8:18 PM, Alan Bateman
wrote:
>
>
> On 06/11/2015 10:59, Ali Ebrahimi wrote:
>
>> :
>>
>> module com.foo {
>> requires com.baz;
>>
>> exports com.foo;
>>
>> }
>>
> In this example
Hi,
On Fri, Nov 6, 2015 at 11:42 PM, Alan Bateman
wrote:
>
>
> On 06/11/2015 19:18, Ali Ebrahimi wrote:
>
>>
>>
> Right, I think you are running into issue again where the two versions of
> com.bar have equal ModuleDescriptors. When you create modular JAR then I
Method mainMethod = mainClass.getMethod("main", String[].class);
mainMethod.invoke(null, (Object)new String[0]);
}
}
Result:
bar1
bar2
As you can see com.foo reads com.bar@2 without reflection.
I say this is puzzling since with almost the equivalent code I get
another result. If you want I can show for you in another post.
If you want I can send all test files to your mail?
--
Best Regards,
Ali Ebrahimi
ltiple versions in all possible layer arrangements is not a goal.
If goal is prevent from overriding as for methods in clesses why not use
'final': require final com.bar?
--
Best Regards,
Ali Ebrahimi
Hi,
On Thu, Nov 5, 2015 at 10:14 PM, Alex Buckley
wrote:
> On 11/5/2015 1:30 AM, Ali Ebrahimi wrote:
>
>> Hi alan,
>> So far quite disappointing!
>>
>> But I think Alex's last response on this topic says opposite of this:
>>
>> "We'll
Hi,
On Thu, Nov 5, 2015 at 11:43 PM, Peter Levart
wrote:
>
>
> On 11/05/2015 07:39 PM, Ali Ebrahimi wrote:
>
> Hi,
> So with current implementation of Implied readability w.r.t. layers and
> unexpected consequences of its remove or addition, I strongly propose to
> dro
Hi,
So with current implementation of Implied readability w.r.t. layers and
unexpected consequences of its remove or addition, I strongly propose to
drop it from current design.
On Thu, Nov 5, 2015 at 7:15 PM, Alan Bateman
wrote:
> On 05/11/2015 15:06, Ali Ebrahimi wrote:
>
>> :
&
m2@1 for M then you don't have duplicates.
--
Best Regards,
Ali Ebrahimi
Hi,
On Thu, Nov 5, 2015 at 5:32 PM, Alan Bateman
wrote:
>
>
> On 05/11/2015 13:17, Ali Ebrahimi wrote:
>
>>
>> If API usage of com.baz in com.foo does not contain any type of com.bar
>> you wouldn't have any issue, otherwise com.foo must live on layer1
Hi,
On Thu, Nov 5, 2015 at 3:08 PM, Alan Bateman
wrote:
> On 05/11/2015 09:30, Ali Ebrahimi wrote:
>
> Hi alan,
> So far quite disappointing!
>
>
> In this example then com.baz in layer1 doesn't know anything about
> com.bar@2 or other modules that comes in
e with flat classpath days not now!
I think we should assume sublayers and parent layers somewhat as subclasses
and supper classes and think about method overriding vs module overriding.
--
Best Regards,
Ali Ebrahimi
and developers would have to use newer versions of modules to fix
bugs.
What if com.foo compiled against com.bar@2? adding redundant requires com.bar
in com.foo does not help and my app will fail.
So what is advantage of multiple layers?
On Thu, Nov 5, 2015 at 12:20 PM, Alan Bateman
wro
Hi,
On Thu, Nov 5, 2015 at 1:33 AM, Alan Bateman
wrote:
>
>
> On 04/11/2015 16:26, Ali Ebrahimi wrote:
>
> :
>
> Yes, I got it. But should not upper level descriptors win over lower
> descriptors regards to current configuration.
> What I missed here?
>
> (Chang
9>+
}
<http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fd7cc28c24c7#l2.40>+
}
<http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fd7cc28c24c7#l2.41>+
parent = parent.parent().orElse(null);
<http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fd7cc28c24c7#l2.42>+
}
<http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fd7cc28c24c7#l2.43>+
}
Layer.findModule already do recursive search for modules in parent layers
--
Best Regards,
Ali Ebrahimi
Hi,
On Wed, Nov 4, 2015 at 7:31 PM, Alan Bateman
wrote:
>
> On 04/11/2015 15:55, Ali Ebrahimi wrote:
>
>
>
> Layer.findModule already do recursive search for modules in parent layers
>
> That is by name and so does not uniquely identify the module. The module
> de
esolve(...
Layer layer = Layer
.create(cfg, m -> cl);
assertTrue(layer.equals(cfg.layer())); //
After change:
assertTrue(layer.parent().equals(cfg.parentLayer()));
--
Best Regards,
Ali Ebrahimi
t that point.
>
> In any case, the issue that Ali ran into turns out to be a small oversight
> in the implementation, easily fixed. There is however another case that
> will need yet more thought and that is where an indistinguishable com.bar
> is in both layers. If they are different (meaning not equal) then the
> implementation will be correct. This is somewhat of a corner case but will
> need to be handled too.
>
> -Alan.
>
--
Best Regards,
Ali Ebrahimi
ect1 with the type in
com.bar@1 (com.baz can not read com.bar@2 from upper layer
'layer2') and if that object passed to com.foo in layer2 as said before,
error should occur.
--
Best Regards,
Ali Ebrahimi
@@
int methods_count = in.readUnsignedShort();
if (methods_count > 0)
-throw invalidModuleDescriptor("Bad #fields");
+throw invalidModuleDescriptor("Bad #methods");
int attributes_count = in.readUnsignedShort();
--
Best Regards,
Ali Ebrahimi
Thanks Alex,
So this is currently not fully implemented.
I think this would have many use cases in EE land where we would need
override some modules.
On Tue, Nov 3, 2015 at 5:57 AM, Alex Buckley
wrote:
> On 11/2/2015 3:32 PM, Ali Ebrahimi wrote:
>
>> On Tue, Nov 3, 2015 at 1:21 AM,
o M3. It's not related to Layer actually.
This would arise error as of pre-jigsaw with multiple classloaders and
expected.
I think completed related to layer. Intention of Layers is to handle such
scenarios.
> Frank
>
>
--
Best Regards,
Ali Ebrahimi
Hi,
On Tue, Nov 3, 2015 at 1:21 AM, Alan Bateman
wrote:
> On 02/11/2015 20:02, Ali Ebrahimi wrote:
> Thanks, I see the issue. The reason it didn't duplicate for me is because
> I hadn't dropped the requires com.bar.
>
> So the bug is implied readability across layers w
t.main(com.test/Test.java:48)
Caused by: java.lang.IllegalAccessError: class com.foo.Main (in module: com.foo)
cannot access class com.bar.Bar (in module: com.bar), com.foo cannot
read com.bar
at com.foo.Main.main(com.foo/Main.java:12)
... 5 more
Note that I get above result if Implied
says: com.foo cannot read com.bar. Why?
Is not two situation equivalent? (before Implied readability and after)
This is bug?
Best Regards,
Ali Ebrahimi
idea.
I think that was my idea and hence no feedback from experts in this case!.
[1]
http://mail.openjdk.java.net/pipermail/jpms-spec-observers/2015-October/000204.html
--
Best Regards,
Ali Ebrahimi
.append(mainClass.get())
+.append(" %*\n");
+}
try (BufferedWriter writer =
Files.newBufferedWriter(cmd,
StandardCharsets.ISO_8859_1,
On Wed, Sep 16, 2015 at 8:46 PM, Jean-Francois Denise <
jean-franc
nd(module).append('/')
.append(mainClass.get())
.append(" $@\n");
+} else {
+sb.append("%~dp0java -m ")
+.append(module).append('/')
+.append(mainClass.get())
+.append(" $*\n");
+}
Best Regards,
Ali Ebrahimi
50 matches
Mail list logo
