On 18.05.2017 02:29, Gregg Wonderly wrote:
I understand that you might feel this is an excessive rant.
[snip]
I will be looking at Swift and/or Go and just moving on.
All the best on your future technological adventures, in any case,
whether they are with Java, or something else!
Please do
On 18/05/2017 01:29, Gregg Wonderly wrote:
I understand that you might feel this is an excessive rant. But, practically I
know of Java applications around the world which all use things like Spring.
Spring seems to be making great progress, here's a recent write-up from
Juergen Hoeller:
> On May 17, 2017, at 3:08 AM, Andrew Dinn wrote:
>
> On 16/05/17 19:11, Gregg Wonderly wrote:
>
>
>
>> If we really cannot actually keep from breaking 90% of existing Java
>> in the market place when this new JDK release goes out, how valuable
>> is JigSaw really?
>
> citation needed?
This
On 16/05/17 19:11, Gregg Wonderly wrote:
> If we really cannot actually keep from breaking 90% of existing Java
> in the market place when this new JDK release goes out, how valuable
> is JigSaw really?
citation needed?
regards,
Andrew Dinn
---
On 16/05/2017 19:11, Gregg Wonderly wrote:
At some level, this is the problem that is paramount on the release of JDK-9.
Earlier Mark asked if the Eclipse foundation had to approve or be ready to
support all of what JDK-9/Jigsaw supports before it could be released.
The statement below seems
At some level, this is the problem that is paramount on the release of JDK-9.
Earlier Mark asked if the Eclipse foundation had to approve or be ready to
support all of what JDK-9/Jigsaw supports before it could be released.
The statement below seems to stipulate that “all Java software must be
On 05/16/2017 06:02 AM, Alan Bateman wrote:
On 12/05/2017 14:31, David M. Lloyd wrote:
:
There is a lot more to #5, something that will become clear when you
work through all the scenarios. The JSR and spec part are minor
though but I'd prefer to hold off until there is more discussion on
t
On 12/05/2017 14:31, David M. Lloyd wrote:
:
There is a lot more to #5, something that will become clear when you
work through all the scenarios. The JSR and spec part are minor
though but I'd prefer to hold off until there is more discussion on
this topic in the JSR.
I'd rather not hold o
On 12/05/2017 14:31, David M. Lloyd wrote:
:
#4 seems to be working around the outcome of issue #CyclicDependences
in the JSR. I also don't wish to comment on that except to say that
introducing system properties to skip specified checks is highly
problematic from a conformance perspective.
On 12 May 2017 at 17:31, David M. Lloyd wrote:
>>> 4. Make run-time cycle checking optional
>>
>> My opinion is that run-time cycles are inevitable. The proposed
>> solutions (refactoring to API vs Impl) is not particularly good in an
>> open source context. I'm also concerned that "requires stati
On 12 May 2017 at 11:22, Alan Bateman wrote:
> However for #3 then you've
> missed several important error cases, e.g. illegal package names, or the
> package is already in another module defined to the class loader.
These checks are already present in implAddPackage, so why duplicate
those check
On 05/12/2017 01:02 PM, David M. Lloyd wrote:
On 05/12/2017 08:31 AM, David M. Lloyd wrote:
On 05/12/2017 03:22 AM, Alan Bateman wrote:
On 12/05/2017 01:43, David M. Lloyd wrote:
I've proposed five patches to the jpms-spec-experts list [1..5] for
discussion. The patches are as follows:
[.
On 05/12/2017 08:31 AM, David M. Lloyd wrote:
On 05/12/2017 03:22 AM, Alan Bateman wrote:
On 12/05/2017 01:43, David M. Lloyd wrote:
I've proposed five patches to the jpms-spec-experts list [1..5] for
discussion. The patches are as follows:
[...]
3. Layer primitive: addPackage() - allows M
On 12.05.2017 18:49, Michael Nascimento wrote:
#1-#3, IMHO, meet the needs of a niche who knows how to work around these
issues using other ways (although inconvenient).
I see me as someone needing this, and only having hints about how to
make it work, that are based on annotation processors
#1-#3, IMHO, meet the needs of a niche who knows how to work around these
issues using other ways (although inconvenient).
4 and 5 are solutions for problems any developer assembling a medium-large
application will definitely face and therefore are essential in my point of
view since it'd be unrea
On 05/12/2017 09:37 AM, Stephen Colebourne wrote:
On 12 May 2017 at 01:43, David M. Lloyd wrote:
1. Layer primitive: addExports() - mirrors the existing Module.addExports()
method for ModuleLayer.Controllers
2. Layer primitive: addUses() - mirrors the existing Module.addUses() method
for Module
On 12 May 2017 at 17:37, Stephen Colebourne wrote:
> On 12 May 2017 at 01:43, David M. Lloyd wrote:
>> 1. Layer primitive: addExports() - mirrors the existing Module.addExports()
>> method for ModuleLayer.Controllers
>> 2. Layer primitive: addUses() - mirrors the existing Module.addUses() method
On 12 May 2017 at 01:43, David M. Lloyd wrote:
> 1. Layer primitive: addExports() - mirrors the existing Module.addExports()
> method for ModuleLayer.Controllers
> 2. Layer primitive: addUses() - mirrors the existing Module.addUses() method
> for ModuleLayer.Controllers
> 3. Layer primitive: addPa
On 05/12/2017 03:22 AM, Alan Bateman wrote:
On 12/05/2017 01:43, David M. Lloyd wrote:
I've proposed five patches to the jpms-spec-experts list [1..5] for
discussion. The patches are as follows:
1. Layer primitive: addExports() - mirrors the existing
Module.addExports() method for ModuleLay
On 12/05/2017 01:43, David M. Lloyd wrote:
I've proposed five patches to the jpms-spec-experts list [1..5] for
discussion. The patches are as follows:
1. Layer primitive: addExports() - mirrors the existing
Module.addExports() method for ModuleLayer.Controllers
2. Layer primitive: addUses()
Regarding previous comments about not wanting to support such an extension of
what are viewed as internal APIs, these proposed extensions could be guarded by
a command line option such as --enable-jpms-experimental-api that carries
warning messages along the lines of the --permit-illegal-access
21 matches
Mail list logo
