Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #36556 > unrolled thread

Jigsaw: RedHat and IBM say no

Back to article view | Back to comp.lang.java.programmer

Contents

  Jigsaw: RedHat and IBM say no Chris Riesbeck <Chris.Riesbeck@gmail.com> - 2017-05-01 12:25 -0500
    Re: Jigsaw: RedHat and IBM say no Arne Vajhøj <arne@vajhoej.dk> - 2017-05-01 13:43 -0400
      Re: Jigsaw: RedHat and IBM say no Eric Douglas <e.d.programmer@gmail.com> - 2017-05-01 11:14 -0700
        Re: Jigsaw: RedHat and IBM say no Arne Vajhøj <arne@vajhoej.dk> - 2017-05-01 14:33 -0400
          Re: Jigsaw: RedHat and IBM say no Eric Douglas <e.d.programmer@gmail.com> - 2017-05-01 11:53 -0700
            Re: Jigsaw: RedHat and IBM say no Arne Vajhøj <arne@vajhoej.dk> - 2017-05-01 15:10 -0400
              Re: Jigsaw: RedHat and IBM say no Eric Douglas <e.d.programmer@gmail.com> - 2017-05-01 12:53 -0700
                Re: Jigsaw: RedHat and IBM say no Arne Vajhøj <arne@vajhoej.dk> - 2017-05-01 16:06 -0400
            Re: Jigsaw: RedHat and IBM say no Eric Sosman <esosman@comcast-dot-net.invalid> - 2017-05-01 16:00 -0400
              Re: Jigsaw: RedHat and IBM say no Arne Vajhøj <arne@vajhoej.dk> - 2017-05-01 16:14 -0400
    Re: Jigsaw: RedHat and IBM say no Arne Vajhøj <arne@vajhoej.dk> - 2017-05-01 15:59 -0400
    Re: Jigsaw: RedHat and IBM say no Silvio <silvio@internet.com> - 2017-05-01 22:01 +0200
      Re: Jigsaw: RedHat and IBM say no Arne Vajhøj <arne@vajhoej.dk> - 2017-05-01 16:09 -0400
        Re: Jigsaw: RedHat and IBM say no Silvio <silvio@internet.com> - 2017-05-01 23:17 +0200
          Re: Jigsaw: RedHat and IBM say no Arne Vajhøj <arne@vajhoej.dk> - 2017-05-01 18:35 -0400
            Re: Jigsaw: RedHat and IBM say no Silvio <silvio@internet.com> - 2017-05-02 21:42 +0200
              Re: Jigsaw: RedHat and IBM say no Arne Vajhøj <arne@vajhoej.dk> - 2017-05-02 16:18 -0400
                Re: Jigsaw: RedHat and IBM say no Silvio <silvio@internet.com> - 2017-05-02 22:45 +0200
                  Re: Jigsaw: RedHat and IBM say no Arne Vajhøj <arne@vajhoej.dk> - 2017-05-02 17:43 -0400
                    Re: Jigsaw: RedHat and IBM say no Arne Vajhøj <arne@vajhoej.dk> - 2017-05-02 22:57 -0400
                      Re: Jigsaw: RedHat and IBM say no lewbloch@gmail.com - 2017-05-10 12:42 -0700
                        Re: Jigsaw: RedHat and IBM say no Eric Douglas <e.d.programmer@gmail.com> - 2017-05-10 13:12 -0700
                        Re: Jigsaw: RedHat and IBM say no Silvio <silvio@internet.com> - 2017-05-10 23:25 +0200
                          Re: Jigsaw: RedHat and IBM say no Arne Vajhøj <arne@vajhoej.dk> - 2017-05-14 20:44 -0400
                            Re: Jigsaw: RedHat and IBM say no Arne Vajhøj <arne@vajhoej.dk> - 2017-05-15 19:27 -0400
                              Re: Jigsaw: RedHat and IBM say no Sebastian <nowhere@nirvana.org> - 2017-05-16 22:39 +0200
                                Re: Jigsaw: RedHat and IBM say no Arne Vajhøj <arne@vajhoej.dk> - 2017-05-16 20:48 -0400
                                  Re: Jigsaw: RedHat and IBM say no Arne Vajhøj <arne@vajhoej.dk> - 2017-07-21 19:45 -0400
                Re: Jigsaw: RedHat and IBM say no v_borchert@despammed.com (Volker Borchert) - 2017-05-02 23:09 +0000
                  Re: Jigsaw: RedHat and IBM say no Arne Vajhøj <arne@vajhoej.dk> - 2017-05-02 22:45 -0400
    Re: Jigsaw: RedHat and IBM say no lewbloch@gmail.com - 2017-05-02 02:53 -0700
      Re: Jigsaw: RedHat and IBM say no Arne Vajhøj <arne@vajhoej.dk> - 2017-05-02 16:24 -0400
        Re: Jigsaw: RedHat and IBM say no Gene Wirchenko <genew@telus.net> - 2017-05-02 14:27 -0700
          Re: Jigsaw: RedHat and IBM say no Arne Vajhøj <arne@vajhoej.dk> - 2017-05-02 17:47 -0400

Page 2 of 2 — ← Prev page 1 [2]

#36601

Complaining that the new feature doesn't support hacks one shouldn't have used in the first place is like complaining about paying for child support when you didn't use contraception. You did something you shouldn't. You don't deserve a break for that.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#36602

On Wednesday, May 10, 2017 at 3:43:06 PM UTC-4, lewb...@gmail.com wrote:
> Complaining that the new feature doesn't support hacks one shouldn't have used in the first place is like complaining about paying for child support when you didn't use contraception. You did something you shouldn't. You don't deserve a break for that.
> 
> -- 
> Lew

We have software we pay thousands of dollars a year for support on that we rarely get anything out of.  Their updates are mostly fixing problems they caused.  One problem was somehow installing a Windows update made their software crash the server when someone tried to log in remotely.  We found out the hard way after installing that update we had to get a patch from them to fix that problem they caused.  So if someone isn't paying for support they don't get patches, and their solution is never allow Windows updates?

[toc] | [prev] | [next] | [standalone]

#36603

On 05/10/2017 09:42 PM, lewbloch@gmail.com wrote:
> Complaining that the new feature doesn't support hacks one shouldn't have used in the first place is like complaining about paying for child support when you didn't use contraception. You did something you shouldn't. You don't deserve a break for that.
>

You don't have children by association, you need to procreate yourself.

Software systems do not exist in isolation but are tightly integrated 
with and very dependent of libraries written in the past and mostly by 
other people. We rule our own code-bases but are forced to stay within 
boundaries set by existing libraries.

The problem I see coming up is a lack of options to evolve your own 
existing code-base (gradually adopting modules of some form) without 
causing problems some of the legacy libraries in use. I consider that 
disruptive.

I have been in many situations where a library upgrade would mandate a 
Java version upgrade. Since the opposite has never occurred yet that was 
not a problem. This may now change.

[toc] | [prev] | [next] | [standalone]

#36621

On 5/10/2017 5:25 PM, Silvio wrote:
> On 05/10/2017 09:42 PM, lewbloch@gmail.com wrote:
>> Complaining that the new feature doesn't support hacks one shouldn't
>> have used in the first place is like complaining about paying for
>> child support when you didn't use contraception. You did something you
>> shouldn't. You don't deserve a break for that.
>>
>
> You don't have children by association, you need to procreate yourself.
>
> Software systems do not exist in isolation but are tightly integrated
> with and very dependent of libraries written in the past and mostly by
> other people. We rule our own code-bases but are forced to stay within
> boundaries set by existing libraries.
>
> The problem I see coming up is a lack of options to evolve your own
> existing code-base (gradually adopting modules of some form) without
> causing problems some of the legacy libraries in use. I consider that
> disruptive.
>
> I have been in many situations where a library upgrade would mandate a
> Java version upgrade. Since the opposite has never occurred yet that was
> not a problem. This may now change.

It is certainly common that a real world application usually has lots
of external libraries.

But I will still claim that problems is technical debt surfacing.

Ones own code using unsupported features giving problems on Java 9 => 
obvious technical debt.

Some library  which is actively maintained using unsupported features 
giving problems on Java 9 => not really a problem - one just need to 
wait until they get a Java 9 compatible version out

Some library  which is not actively maintained using unsupported 
features giving problems on Java 9 => this is also a technical debt - 
one has chosen an external library that is not actively maintained

But these problems will certainly show up. We already have seen
a bunch here.

The good thing about the module system is that it will to large
extent prevent this from happening in the future (when the unsupported
features do not get exported).

And I also think that Oracle has done a lot of things to facilitate
migration:
* the module system has been underway for many many years so people
   have had long time to check their stuff
* early access version of Java 9 with module system has been out for
   quite some time allowing people to test
* they added a special solution for the much discussed
   problem sun.misc.Unsafe by exporting it from the
   module jdk.unsupported
* they added a command line option to the JVM
   --add-opens/--add-exports to workaround problems

Arne

[toc] | [prev] | [next] | [standalone]

#36629

On 5/14/2017 8:44 PM, Arne Vajhøj wrote:
> And I also think that Oracle has done a lot of things to facilitate
> migration:
> * the module system has been underway for many many years so people
>   have had long time to check their stuff
> * early access version of Java 9 with module system has been out for
>   quite some time allowing people to test
> * they added a special solution for the much discussed
>   problem sun.misc.Unsafe by exporting it from the
>   module jdk.unsupported
> * they added a command line option to the JVM
>   --add-opens/--add-exports to workaround problems

Note though that JSR 376 (module system) public review
was rejected by JCP EC.

13 NO votes (IBM, Redhat, Eclipse etc.)
10 YES votes (Oracle, Azul etc.)

But it may not be dead yet as the comments from some of the
NO voters sort of points towards a resolution.

Software AG:

<quote>
Assuming the ‘No’
vote carries, we hope the specification lead would take advantage of the 
30 days
afforded under the JCP process to attempt to form a healthier consensus 
within
the EG.
</quote>

Credit Suisse:

<quote>
With JSR 376, two main
concerns exists (i.e., automatic modules, reflection) that potentially 
conflict
with an easy adoption of this JSR. Our understanding is that solutions 
have been
proposed in the EG and it seems to be beneficial to give the EG some 
more time
to get consensus on these important topics.
</quote>

SAP:

<quote>
Assuming this JSR won't be approved with
the required two-thirds majority, we would expect the expert group and 
spec lead
to use the additional 30 days for regular meetings in order to sort out the
remaining issues and come up with a new, more sustainable and forward 
looking
proposal. While we're aware that it won't be possible to remedy all 
concerns, we
think that the last days have clearly demonstrated that good compromises are
still possible (e.g. the "automatic modules issue") and we're confident 
that the
additional time could be used to submit a better specification for the
reconsideration vote.
</quote>

London Java Community:

<quote>
The LJC is voting "No" on the spec *as it was submitted* at the start of the
voting period. During the 14 day voting period, great progress was made 
by the
Spec Lead and the EG to reach consensus on some very difficult issues 
such as
#AutomaticModuleNames. However, there are still on going conversations 
on some
of those issues and there simply has not been enough time spent by the 
ecosystem
to discuss some of the new designs in enough depth or enough time spent
implementing and testing prototypes based on the latest spec, e.g. The 
Eclipse
ejc compiler or the latest Automatic Module Naming design in Maven.

If required, we very much look forward to being able to vote ‘YES’ in <= 
30 days
on a version that has had that little bit of extra time for the EG (and the
ecosystem) to discuss / implement / test some of these difficult spec items.
Certainly the last 14 days have shown that consensus can be reached even 
when
viewpoints have started in opposing corners, and we think another short time
period to really bed in the last sticking points is needed.
</quote>

Ivar Grimstad:

<quote>
I am voting
"No" on the specification as it was submitted at the start of the voting 
period.
The discussion during the 14 day voting period has been very good, and I 
applaud
the progress being made by the Spec Lead and EG in this period. 
Especially the
latest Automatic Module Naming proposal.

With continued discussion and these changes incorporated in spec, I look 
forward
to vote "Yes" in a potential reconsideration ballot.
</quote>

It seems like a lot of EC members are hoping/expecting to get
an agreement in place within the next month.

But some (especially the OSGi crowd) are not likely to change
their mind.

Obviously nothing is sure until the final vote.

If this JSR falls then Java 9 will be hanging in the air.

Arne

PS: To read all comments see https://jcp.org/en/jsr/results?id=5959

[toc] | [prev] | [next] | [standalone]

#36635

Am 16.05.2017 um 01:27 schrieb Arne Vajhøj:
> On 5/14/2017 8:44 PM, Arne Vajhøj wrote:
>> And I also think that Oracle has done a lot of things to facilitate
>> migration:
>> * the module system has been underway for many many years so people
>>   have had long time to check their stuff
>> * early access version of Java 9 with module system has been out for
>>   quite some time allowing people to test
>> * they added a special solution for the much discussed
>>   problem sun.misc.Unsafe by exporting it from the
>>   module jdk.unsupported
>> * they added a command line option to the JVM
>>   --add-opens/--add-exports to workaround problems
>
> Note though that JSR 376 (module system) public review
> was rejected by JCP EC.
>
> 13 NO votes (IBM, Redhat, Eclipse etc.)
> 10 YES votes (Oracle, Azul etc.)
>
> But it may not be dead yet as the comments from some of the
> NO voters sort of points towards a resolution.
>
[comments snipped]

The comments by the nay-sayers broadly address the following topics:
•	module isolation and dynamic modules
•	cyclic dependencies
•	reflection
•	automatic modules
•	consensus in the EG

The time period for a revised spec is just too short to do anything 
about the first point. Oracle will not (and should not, in my opinion) 
change its stance with respect to the second and third point. Regarding 
automatic modules, in addition to what has been mentioned there is now 
also the possibility to specify in the module name in the Manifest. 
Consensus there will be not, because no one is going to convince Red Hat 
(and probably also not IBM).

So the remaining nay-sayers will have to consider whether their 
objections justify basically killing off Java 9. My guess is most will 
find that upholding the No vote would be too detrimental to the Java 
ecosystem as a whole, and that consequently the JSR will get bthe 
required two-thirds majority at the final vote without seeing much change.

-- Sebastian

PS: Rafael Winterhalter's opinion piece is very instructive in 
highlighting the issues at stake: 
http://mydailyjava.blogspot.de/2017/05/yet-another-jigsaw-opinion-piece.html 


Rafael Winterhalter ends with a plea to the EC to vote yes, saying that 
"Oracle has found a common denominator for a module system that serves 
most users."

[toc] | [prev] | [next] | [standalone]

#36639

On 5/16/2017 4:39 PM, Sebastian wrote:
> Am 16.05.2017 um 01:27 schrieb Arne Vajhøj:
>> Note though that JSR 376 (module system) public review
>> was rejected by JCP EC.
>>
>> 13 NO votes (IBM, Redhat, Eclipse etc.)
>> 10 YES votes (Oracle, Azul etc.)
>>
>> But it may not be dead yet as the comments from some of the
>> NO voters sort of points towards a resolution.
>>
> [comments snipped]
>
> The comments by the nay-sayers broadly address the following topics:
> •    module isolation and dynamic modules
> •    cyclic dependencies
> •    reflection
> •    automatic modules
> •    consensus in the EG
>
> The time period for a revised spec is just too short to do anything
> about the first point. Oracle will not (and should not, in my opinion)
> change its stance with respect to the second and third point. Regarding
> automatic modules, in addition to what has been mentioned there is now
> also the possibility to specify in the module name in the Manifest.

Time is short. Unless they decide to postpone Java 9 a few months.

> Consensus there will be not, because no one is going to convince Red Hat
> (and probably also not IBM).

It will be very hard to sell this to the OSGi guys.

> So the remaining nay-sayers will have to consider whether their
> objections justify basically killing off Java 9. My guess is most will
> find that upholding the No vote would be too detrimental to the Java
> ecosystem as a whole, and that consequently the JSR will get bthe
> required two-thirds majority at the final vote without seeing much change.

I think Oracle can do a lot by recognize the disagreements and
use more carrot than stick.

Based on the comments it sounds like they are doing just that.

Arne

[toc] | [prev] | [next] | [standalone]

#36976

On 5/16/2017 8:48 PM, Arne Vajhøj wrote:
> On 5/16/2017 4:39 PM, Sebastian wrote:
>> Am 16.05.2017 um 01:27 schrieb Arne Vajhøj:
>>> Note though that JSR 376 (module system) public review
>>> was rejected by JCP EC.
>>>
>>> 13 NO votes (IBM, Redhat, Eclipse etc.)
>>> 10 YES votes (Oracle, Azul etc.)
>>>
>>> But it may not be dead yet as the comments from some of the
>>> NO voters sort of points towards a resolution.
>>>
>> [comments snipped]
>>
>> The comments by the nay-sayers broadly address the following topics:
>> •    module isolation and dynamic modules
>> •    cyclic dependencies
>> •    reflection
>> •    automatic modules
>> •    consensus in the EG
>>
>> The time period for a revised spec is just too short to do anything
>> about the first point. Oracle will not (and should not, in my opinion)
>> change its stance with respect to the second and third point. Regarding
>> automatic modules, in addition to what has been mentioned there is now
>> also the possibility to specify in the module name in the Manifest.
> 
> Time is short. Unless they decide to postpone Java 9 a few months.
> 
>> Consensus there will be not, because no one is going to convince Red Hat
>> (and probably also not IBM).
> 
> It will be very hard to sell this to the OSGi guys.
> 
>> So the remaining nay-sayers will have to consider whether their
>> objections justify basically killing off Java 9. My guess is most will
>> find that upholding the No vote would be too detrimental to the Java
>> ecosystem as a whole, and that consequently the JSR will get bthe
>> required two-thirds majority at the final vote without seeing much 
>> change.
> 
> I think Oracle can do a lot by recognize the disagreements and
> use more carrot than stick.
> 
> Based on the comments it sounds like they are doing just that.

For those that missed it.

The revised draft passed the ballot with broad support (only
Redhat abstained - the rest voted all yes).

https://www.jcp.org/en/jsr/results?id=6016

One can of course wonder how many changed their vote due to:
* actual substantial change in specs
* appreciation of the good will was shown to accommodate what
   was possible to accommodate given the schedule
* serious arm twisting behind the scene

Arne

[toc] | [prev] | [next] | [standalone]

#36586

Arne Vajh??j wrote:
> On 5/2/2017 3:42 PM, Silvio wrote:
> 
> >                             Not knowing which of your legacy libraries
> > may fall apart and when that may happen is a much bigger problem.
> 
> Why should they fall apart?
> 
> Except by using SUN classes?

BTST, a commercial library using some sun.awt class which vanished
with 1.4.

-- 

"I'm a doctor, not a mechanic." Dr Leonard McCoy <mccoy@ncc1701.starfleet.fed>
"I'm a mechanic, not a doctor." Volker Borchert  <v_borchert@despammed.com>

[toc] | [prev] | [next] | [standalone]

#36587

On 5/2/2017 7:09 PM, Volker Borchert wrote:
> Arne Vajh??j wrote:
>> On 5/2/2017 3:42 PM, Silvio wrote:
>>>                             Not knowing which of your legacy libraries
>>> may fall apart and when that may happen is a much bigger problem.
>>
>> Why should they fall apart?
>>
>> Except by using SUN classes?
>
> BTST, a commercial library using some sun.awt class which vanished
> with 1.4.

I am sure that there will be many examples of such.

I have an example myself with a third party LAF that has
classes inheriting SUN classes.

But maybe it is time to weed out such code.

Arne

[toc] | [prev] | [next] | [standalone]

#36572

Chris Riesbeck wrote:
> Just saw a news item that RedHat and IBM plan to vote against releasing 
> Jigsaw for now.  Details of the concerns here:
> 
> https://developer.jboss.org/blogs/scott.stark/2017/04/14/critical-deficiencies-in-jigsawjsr-376-java-platform-module-system-ec-member-concerns
> 
> I have no expertise in evaluating these concerns, but would hate to see 
> some analog of the Python 2.7 / 3 bifurcation occur. Thoughts?

Seems they're angry that the standard, on which committee they sat, didn't just make their products the canonical implementation. There's ample reason to suspect some disingenuity and self-interest behind their protest.

https://blog.plan99.net/is-jigsaw-good-or-is-it-wack-ec634d36dd6f

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#36580

On 5/2/2017 5:53 AM, lewbloch@gmail.com wrote:
> Chris Riesbeck wrote:
>> Just saw a news item that RedHat and IBM plan to vote against releasing
>> Jigsaw for now.  Details of the concerns here:
>>
>> https://developer.jboss.org/blogs/scott.stark/2017/04/14/critical-deficiencies-in-jigsawjsr-376-java-platform-module-system-ec-member-concerns
>>
>> I have no expertise in evaluating these concerns, but would hate to see
>> some analog of the Python 2.7 / 3 bifurcation occur. Thoughts?
>
> Seems they're angry that the standard, on which committee they sat,
> didn't just make their products the canonical implementation. There's
> ample reason to suspect some disingenuity and self-interest behind their
> protest.

Jigsaw is very compatible with un-moduled Java applications.

But Jigsaw is overlapping but not able to replace OSGI, so
the OSGI guys have a problem until they have figured out how to
make Jigsaw and OSGI coexist.

Both JBoss and Eclipse are heavily invested in OSGI.

Fair enough that they complain that they think they will
get a problem.

But OSGI is relative small part of the Java world.

Arne

[toc] | [prev] | [next] | [standalone]

#36582

On Tue, 2 May 2017 16:24:39 -0400, Arne Vajhøj <arne@vajhoej.dk>
wrote:

[snip]

>But OSGI is relative small part of the Java world.

     Relative is relative.  If a problem is in your part of the Java
(or whatever) world, that your part of the world is relatively small
is of no help in mitigating the problem.  In fact, because it is
relatively small, problems in your area may be ignored or brushed off.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#36584

On 5/2/2017 5:27 PM, Gene Wirchenko wrote:
> On Tue, 2 May 2017 16:24:39 -0400, Arne Vajhøj <arne@vajhoej.dk>
> wrote:
>> But OSGI is relative small part of the Java world.
>
>      Relative is relative.  If a problem is in your part of the Java
> (or whatever) world, that your part of the world is relatively small
> is of no help in mitigating the problem.

Yes.

And that is why I can understand that the OSGI guys are frustrated.

But I don't see any way to make Jigsaw OSGI friendly - even though
they provide some similar features then they are also very different.

So unless Jigsaw is totally ditched, then the OSGI guys will need to
find a solution.

If they have specific suggestions to make Jigsaw more OSGI friendly
within the general Jigsaw approach, then Jigsaw team should be listening.

Arne

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.java.programmer

csiph-web