t Jigsaw then we
> 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
e simplest
> alternative is "requires optional", 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
y
> 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
n system modules so that they get
> > access to package private type or public types in non-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
o 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
at 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
isn'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
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 <peter.lev...@gmail.com>
wrote:
> Hi Ali,
>
> On 12/18/2015 05:05 PM, Ali Ebrahimi wrote:
>
> Hi,
> In general,
Hi,
On Sat, Dec 5, 2015 at 1:39 PM, Alan Bateman <alan.bate...@oracle.com>
wrote:
>
>
> On 05/12/2015 07:00, Ali Ebrahimi wrote:
>
>> :
>>
>> module FOO.aop{
>> implements FOO.api;
>> }
>>
>> In other word, consumer module doesn
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
one big
module 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
ach classloader.
This will support test modules.
--
Best Regards,
Ali Ebrahimi
Hi,
On Fri, Dec 4, 2015 at 5:12 PM, Alan Bateman <alan.bate...@oracle.com>
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 c
that there is source 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
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
> frameworks/containers working with us and helping to understand and work
> through the migration issues.
>
> -Alan
>
--
Best Regards,
Ali Ebrahimi
Hi,
On Wed, Nov 18, 2015 at 2:38 PM, Alan Bateman <alan.bate...@oracle.com>
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 thin
: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
Thanks.
On Mon, Nov 16, 2015 at 8:04 PM, Philip Race <philip.r...@oracle.com> 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 A
tModule());
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
Hi,
On Fri, Nov 6, 2015 at 11:42 PM, Alan Bateman <alan.bate...@oracle.com>
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.
Hi,
On Fri, Nov 6, 2015 at 8:18 PM, Alan Bateman <alan.bate...@oracle.com>
wrote:
>
>
> On 06/11/2015 10:59, Ali Ebrahimi wrote:
>
>> :
>>
>> module com.foo {
>> requires com.baz;
>>
>> exports com.foo;
>>
>> }
&
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.
>>
>
> 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 Thu, Nov 5, 2015 at 3:08 PM, Alan Bateman <alan.bate...@oracle.com>
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 mod
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 <alan.bate...@oracle.com>
wrote:
> On 05/11/2015 15:06, Ali
ited support for
> multiple 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 11:43 PM, Peter Levart <peter.lev...@gmail.com>
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
Hi,
On Thu, Nov 5, 2015 at 1:33 AM, Alan Bateman <alan.bate...@oracle.com>
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.
>
Hi,
On Wed, Nov 4, 2015 at 7:31 PM, Alan Bateman <alan.bate...@oracle.com>
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 i
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
3. 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
oint.
>
> 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
az should construct Object1 with the type in
com.bar@1 <com.bar@2>(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
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
n(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 re
Hi,
On Tue, Nov 3, 2015 at 1:21 AM, Alan Bateman <alan.bate...@oracle.com>
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 read
t 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
.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-francois.den...@oracle.com> wrote:
&
38 matches
Mail list logo
