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 1 of 2  [1] 2  Next page →

#36556 — Jigsaw: RedHat and IBM say no

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?

[toc] | [next] | [standalone]

#36557

On 5/1/2017 1:25 PM, 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?

I think they are a bit late to raise those concerns.

As I see it then there is two aspects:
1) There are some specific design choices that they don't like.
2) They do not feel that they are ready, because nobody knows yet
    how OSGI and Java EE will look like in the Jigsaw world.

Re 1) I am sure many of those concerns are valid. But I also have
a feeling that no matter what design had be chosen then there would
be some issues.

Re 2) I can understand that. Everybody has been talking about Jigsaw
for years and I suspect that many had started to suspect that it would
never show up. Now suddenly it will be here in a few months and nobody
is ready.

Personally I like Jigsaw. Probably the biggest change in the history of
Java and it will certainly take time to get used to. But I really
like the concept.

Arne

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

#36558

On Monday, May 1, 2017 at 1:43:38 PM UTC-4, Arne Vajhøj wrote:
> Personally I like Jigsaw. Probably the biggest change in the history of
> Java and it will certainly take time to get used to. But I really
> like the concept.
> 
> Arne

I haven't tried it myself.  I currently just develop my own relatively small API, so if we don't have to jump on the new version right away I expect I don't need to test ahead of time.  Large companies with many more lines of code and many more developers would spend many hours changing and/or testing their code for any new version of Java that changes things fundamentally.  Ideally it should not require anyone to change existing code.

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

#36559

On 5/1/2017 2:14 PM, Eric Douglas wrote:
> On Monday, May 1, 2017 at 1:43:38 PM UTC-4, Arne Vajhøj wrote:
>> Personally I like Jigsaw. Probably the biggest change in the
>> history of Java and it will certainly take time to get used to. But
>> I really like the concept.
>
> I haven't tried it myself.  I currently just develop my own
> relatively small API, so if we don't have to jump on the new version
> right away I expect I don't need to test ahead of time.  Large
> companies with many more lines of code and many more developers would
> spend many hours changing and/or testing their code for any new
> version of Java that changes things fundamentally.  Ideally it should
> not require anyone to change existing code.

A lot of applications should run fine unchanged on Java 9.

But some will see some problems.

I think the two main categories of problems will be:
* usage of sun.* and com.sun.* classes that are no longer accessible
* already using another module system that is not Jigsaw compatible

Arne

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

#36560

On Monday, May 1, 2017 at 2:33:42 PM UTC-4, Arne Vajhøj wrote:
> A lot of applications should run fine unchanged on Java 9.
> 
> But some will see some problems.
> 
> I think the two main categories of problems will be:
> * usage of sun.* and com.sun.* classes that are no longer accessible
> * already using another module system that is not Jigsaw compatible
> 
> Arne

I wonder how many big companies have how many lines of code that won't work?
I thought the sun.java was just for Windows.  I believe the only one I came across was Windows specific.  I haven't tested my API on my Mac yet but I aim to write platform independent code.

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

#36561

On 5/1/2017 2:53 PM, Eric Douglas wrote:
> On Monday, May 1, 2017 at 2:33:42 PM UTC-4, Arne Vajhøj wrote:
>> A lot of applications should run fine unchanged on Java 9.
>>
>> But some will see some problems.
>>
>> I think the two main categories of problems will be:
>> * usage of sun.* and com.sun.* classes that are no longer accessible
>> * already using another module system that is not Jigsaw compatible
>
> I wonder how many big companies have how many lines of code that
> won'twork?
> I thought the sun.java was just for Windows. I believe the only one
> Icame across was Windows specific. I haven't tested my API on my Mac yet
> but I aim to write platform independent code.

Those classes are not platform specific (Windows) but implementation
specific (Oracle Java).

But it is a mess, because I believe that those classes are in 3
categories:
* documented/supported
* not documented/supported but exported so still works
* not documented/supported and not exported so don't work

Arne

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

#36562

On Monday, May 1, 2017 at 3:10:43 PM UTC-4, Arne Vajhøj wrote:
> Those classes are not platform specific (Windows) but implementation
> specific (Oracle Java).
> 
> But it is a mess, because I believe that those classes are in 3
> categories:
> * documented/supported
> * not documented/supported but exported so still works
> * not documented/supported and not exported so don't work
> 
> Arne

The one place I recall seeing it offhand was in sun.print.Win32PrintService, so I figured Win meant Windows.
I also only use Oracle's Java so that wouldn't be an issue.  I wonder what % of companies would use a non-Oracle Java (that otherwise currently runs all code written for Oracle's Java?).

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

#36566

On 5/1/2017 3:53 PM, Eric Douglas wrote:
> On Monday, May 1, 2017 at 3:10:43 PM UTC-4, Arne Vajhøj wrote:
>> Those classes are not platform specific (Windows) but implementation
>> specific (Oracle Java).
>>
>> But it is a mess, because I believe that those classes are in 3
>> categories:
>> * documented/supported
>> * not documented/supported but exported so still works
>> * not documented/supported and not exported so don't work
>
> The one place I recall seeing it offhand was in sun.print.Win32PrintService,
 > so I figured Win meant Windows.

That one sound indeed Windows specific but that is not the general case.

> I also only use Oracle's Java so that wouldn't be an issue.  I wonder what % of
 > companies would use a non-Oracle Java

If we talk about Java that is not official Oracle Java then a lot.

mainframe: IBM Java
AIX: IBM Java
i/OS: IBM Java
HP-UX: HP Java
OpenVMS: HP Java
Linux: OpenJDK, IBM Java, Azul Java

If we talk about Java that is not based on Oracle code base
then a lot less.

OpenJDK is the open source version of Oracle Java.

I believe that IBM and HP license source code from Oracle.

Azul is based on OpenJDK I believe.

But no matter what usage of those SUN classes is still not
as portable as Java should be.

Arne

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

#36564

On 5/1/2017 2:53 PM, Eric Douglas wrote:
> On Monday, May 1, 2017 at 2:33:42 PM UTC-4, Arne Vajhøj wrote:
>> A lot of applications should run fine unchanged on Java 9.
>>
>> But some will see some problems.
>>
>> I think the two main categories of problems will be:
>> * usage of sun.* and com.sun.* classes that are no longer accessible

     As I understand it (perhaps imperfectly), the com.sun.* classes are
fine.  They're not part of Java per se, but are "fine" in the same sense
that other non-core contributed classes like Apache Commons are.

     It's the sun.* classes that are "Subject to change without notice;
the Secretary will disavow all knowledge, hic draecones."

>> * already using another module system that is not Jigsaw compatible
>>
>> Arne
> 
> I wonder how many big companies have how many lines of code that won't work?
> I thought the sun.java was just for Windows.  I believe the only one I came across was Windows specific.  I haven't tested my API on my Mac yet but I aim to write platform independent code.
> 

     They're not Windows-specific, they're Oracle-specific.  If you
want code that's portable from Oracle's JVM to Somebody's JVM, or
even from Oracle's JVM version X to Oracle's JVM version X+1, don't
call anything in the sun.* packages.  See:

<http://www.oracle.com/technetwork/java/faq-sun-packages-142232.html>

     As for the question "How many coders ignored the warning?", it
looks like we might soon find out ...

-- 
esosman@comcast-dot-net.invalid
Thirteen hundred sixty days to go.

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

#36568

On 5/1/2017 4:00 PM, Eric Sosman wrote:
> On 5/1/2017 2:53 PM, Eric Douglas wrote:
>> On Monday, May 1, 2017 at 2:33:42 PM UTC-4, Arne Vajhøj wrote:
>>> A lot of applications should run fine unchanged on Java 9.
>>>
>>> But some will see some problems.
>>>
>>> I think the two main categories of problems will be:
>>> * usage of sun.* and com.sun.* classes that are no longer accessible
>
>     As I understand it (perhaps imperfectly), the com.sun.* classes are
> fine.  They're not part of Java per se, but are "fine" in the same sense
> that other non-core contributed classes like Apache Commons are.
>
>     It's the sun.* classes that are "Subject to change without notice;
> the Secretary will disavow all knowledge, hic draecones."

That is also how I thought it was.

But com.sun.java.swing.plaf classes are not exported ...

Arne

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

#36563

On 5/1/2017 1:25 PM, 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

And IBM:

http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2017-April/000684.html

Arne

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

#36565

On 05/01/2017 07:25 PM, 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?
>

They are quite right. Jigsaw is a very restricting and intrusive 
specification. This was mostly caused by too ambitious goals set for the 
new module system.

I would have preferred a modules-as-an-option kind of system. Leave 
everything the same by default but allow the explicit construction of 
modules where needed/desired. Modules as a convention to make conflicts 
avoidable and manageable instead of a rigid module system that provides 
guarantees at the cost of being restrictive and intrusive.

But it is probably too late now. I expect Jigsaw to cause a platform 
schism and a Jigsaw-less OpenJDK8 development branch that will stay 
around for eternity.

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

#36567

On 5/1/2017 4:01 PM, Silvio wrote:
> On 05/01/2017 07:25 PM, 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
>
> They are quite right. Jigsaw is a very restricting and intrusive
> specification. This was mostly caused by too ambitious goals set for the
> new module system.
>
> I would have preferred a modules-as-an-option kind of system. Leave
> everything the same by default but allow the explicit construction of
> modules where needed/desired.

Modules are not required.

You can choose to use modules or you can chose not to use modules.
For your code.

Oracle does the same for their code. And they chose modules.

 > But it is probably too late now. I expect Jigsaw to cause a platform
 > schism and a Jigsaw-less OpenJDK8 development branch that will stay
 > around for eternity.

Not likely in my opinion.

Arne

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

#36569

On 05/01/2017 10:09 PM, Arne Vajhøj wrote:
> On 5/1/2017 4:01 PM, Silvio wrote:
>> On 05/01/2017 07:25 PM, 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
>>>
>>
>> They are quite right. Jigsaw is a very restricting and intrusive
>> specification. This was mostly caused by too ambitious goals set for the
>> new module system.
>>
>> I would have preferred a modules-as-an-option kind of system. Leave
>> everything the same by default but allow the explicit construction of
>> modules where needed/desired.
>
> Modules are not required.
>
> You can choose to use modules or you can chose not to use modules.
> For your code.
>
> Oracle does the same for their code. And they chose modules.

That is not sufficient. Besides greenfield toy applications larger 
existing Java projects need to start off without modules and then 
gradually adopt them. This is not an option with Java9.

>
>> But it is probably too late now. I expect Jigsaw to cause a platform
>> schism and a Jigsaw-less OpenJDK8 development branch that will stay
>> around for eternity.
>
> Not likely in my opinion.

Let's wait and see.

>
> Arne
>

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

#36570

On 5/1/2017 5:17 PM, Silvio wrote:
> On 05/01/2017 10:09 PM, Arne Vajhøj wrote:
>> On 5/1/2017 4:01 PM, Silvio wrote:
>>> They are quite right. Jigsaw is a very restricting and intrusive
>>> specification. This was mostly caused by too ambitious goals set for the
>>> new module system.
>>>
>>> I would have preferred a modules-as-an-option kind of system. Leave
>>> everything the same by default but allow the explicit construction of
>>> modules where needed/desired.
>>
>> Modules are not required.
>>
>> You can choose to use modules or you can chose not to use modules.
>> For your code.
>>
>> Oracle does the same for their code. And they chose modules.
>
> That is not sufficient. Besides greenfield toy applications larger
> existing Java projects need to start off without modules and then
> gradually adopt them. This is not an option with Java9.

Why is that not an option?

I don't think there is any limitation on how large an application
you can make without defining modules.

Arne

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

#36578

On 05/02/2017 12:35 AM, Arne Vajhøj wrote:
> On 5/1/2017 5:17 PM, Silvio wrote:
>> On 05/01/2017 10:09 PM, Arne Vajhøj wrote:
>>> On 5/1/2017 4:01 PM, Silvio wrote:
>>>> They are quite right. Jigsaw is a very restricting and intrusive
>>>> specification. This was mostly caused by too ambitious goals set for
>>>> the
>>>> new module system.
>>>>
>>>> I would have preferred a modules-as-an-option kind of system. Leave
>>>> everything the same by default but allow the explicit construction of
>>>> modules where needed/desired.
>>>
>>> Modules are not required.
>>>
>>> You can choose to use modules or you can chose not to use modules.
>>> For your code.
>>>
>>> Oracle does the same for their code. And they chose modules.
>>
>> That is not sufficient. Besides greenfield toy applications larger
>> existing Java projects need to start off without modules and then
>> gradually adopt them. This is not an option with Java9.
>
> Why is that not an option?
>
> I don't think there is any limitation on how large an application
> you can make without defining modules.
>
> Arne
>

You don't get it. If you have a large existing Java system that you are 
constantly improving and extending (which is very common in the standard 
software business) one might want to gradually introduce modules into 
the code-base while needing 100% backward compatibility for all existing 
code and configurations.

With Java9 even just getting existing applications running is a 
challenge already. And the least part of the problem is explicitly using 
sun.* or com.sun.* classes. Not knowing which of your legacy libraries 
may fall apart and when that may happen is a much bigger problem.

I am not saying they should have adopted an existing module system. But 
they chose to invent one that is much less backward compatible than 
existing ones. I think they made a bad decision there.

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

#36579

On 5/2/2017 3:42 PM, Silvio wrote:
> On 05/02/2017 12:35 AM, Arne Vajhøj wrote:
>> On 5/1/2017 5:17 PM, Silvio wrote:
>>> On 05/01/2017 10:09 PM, Arne Vajhøj wrote:
>>>> On 5/1/2017 4:01 PM, Silvio wrote:
>>>>> They are quite right. Jigsaw is a very restricting and intrusive
>>>>> specification. This was mostly caused by too ambitious goals set for
>>>>> the
>>>>> new module system.
>>>>>
>>>>> I would have preferred a modules-as-an-option kind of system. Leave
>>>>> everything the same by default but allow the explicit construction of
>>>>> modules where needed/desired.
>>>>
>>>> Modules are not required.
>>>>
>>>> You can choose to use modules or you can chose not to use modules.
>>>> For your code.
>>>>
>>>> Oracle does the same for their code. And they chose modules.
>>>
>>> That is not sufficient. Besides greenfield toy applications larger
>>> existing Java projects need to start off without modules and then
>>> gradually adopt them. This is not an option with Java9.
>>
>> Why is that not an option?
>>
>> I don't think there is any limitation on how large an application
>> you can make without defining modules.
>
> You don't get it.

No. I don't.

>            If you have a large existing Java system that you are
> constantly improving and extending (which is very common in the standard
> software business) one might want to gradually introduce modules into
> the code-base while needing 100% backward compatibility for all existing
> code and configurations.

Yes.

And that should be possible.

Let us say that you have 200 packages with 2000 classes.

You build with Java 9 and it runs unchanged.

Then you take 1/10'th (10 packages with 200 classes) and convert
to a module. The rest of the application is unchanged - all
you need to change is the ref in the build and run to use the
new module.

Then you take the next 1/10'th and so on.

I don't think it is possible to create a module system that
is more backwards compatible than that.

> With Java9 even just getting existing applications running is a
> challenge already.

Really?

Surprisingly little has been said about that the year or more where the
EA has been available.

Where do you see those trouble stories? SO? LI?

>              And the least part of the problem is explicitly using
> sun.* or com.sun.* classes.

Everybody knew that was risky. Usage of those should not have passed
a code review.

>                             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?

Arne

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

#36581

On 05/02/2017 10:18 PM, Arne Vajhøj wrote:
> On 5/2/2017 3:42 PM, Silvio wrote:
>> On 05/02/2017 12:35 AM, Arne Vajhøj wrote:
>>> On 5/1/2017 5:17 PM, Silvio wrote:
>>>> On 05/01/2017 10:09 PM, Arne Vajhøj wrote:
>>>>> On 5/1/2017 4:01 PM, Silvio wrote:
>>>>>> They are quite right. Jigsaw is a very restricting and intrusive
>>>>>> specification. This was mostly caused by too ambitious goals set for
>>>>>> the
>>>>>> new module system.
>>>>>>
>>>>>> I would have preferred a modules-as-an-option kind of system. Leave
>>>>>> everything the same by default but allow the explicit construction of
>>>>>> modules where needed/desired.
>>>>>
>>>>> Modules are not required.
>>>>>
>>>>> You can choose to use modules or you can chose not to use modules.
>>>>> For your code.
>>>>>
>>>>> Oracle does the same for their code. And they chose modules.
>>>>
>>>> That is not sufficient. Besides greenfield toy applications larger
>>>> existing Java projects need to start off without modules and then
>>>> gradually adopt them. This is not an option with Java9.
>>>
>>> Why is that not an option?
>>>
>>> I don't think there is any limitation on how large an application
>>> you can make without defining modules.
>>
>> You don't get it.
>
> No. I don't.
>
>>            If you have a large existing Java system that you are
>> constantly improving and extending (which is very common in the standard
>> software business) one might want to gradually introduce modules into
>> the code-base while needing 100% backward compatibility for all existing
>> code and configurations.
>
> Yes.
>
> And that should be possible.
>
> Let us say that you have 200 packages with 2000 classes.
>
> You build with Java 9 and it runs unchanged.

Our most current system is written in Scala. Currently no Scala version 
runs on Java9.

>
> Then you take 1/10'th (10 packages with 200 classes) and convert
> to a module. The rest of the application is unchanged - all
> you need to change is the ref in the build and run to use the
> new module.

No. You did not read the article linked by the OP. If you depend on 
service loading introducing modules possibly breaks your application.

>
> Then you take the next 1/10'th and so on.
>
> I don't think it is possible to create a module system that
> is more backwards compatible than that.
>
>> With Java9 even just getting existing applications running is a
>> challenge already.
>
> Really?
>
> Surprisingly little has been said about that the year or more where the
> EA has been available.
>
> Where do you see those trouble stories? SO? LI?
>
>>              And the least part of the problem is explicitly using
>> sun.* or com.sun.* classes.
>
> Everybody knew that was risky. Usage of those should not have passed
> a code review.
>
>>                             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?

Can I depend on my libraries not doing that? And if they do: what can I 
do about it? Upgrading to newer versions can not be done without 
extensive modifications.

Both of our current applications fail on Java9. One because it is 
written in Scala. The other one is pure Java but it fails at startup 
with spurious class loading exceptions that are related to the use of an 
ancient Asterisk library which we have not yet been able to fix.

Zero modules involved thus far. Both use service loading and even if we 
get them up and running the may fail later on if we introduce modules.

The first signs are not very promising...

>
> Arne
>

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

#36583

On 5/2/2017 4:45 PM, Silvio wrote:
> On 05/02/2017 10:18 PM, Arne Vajhøj wrote:
>> On 5/2/2017 3:42 PM, Silvio wrote:
>>>            If you have a large existing Java system that you are
>>> constantly improving and extending (which is very common in the standard
>>> software business) one might want to gradually introduce modules into
>>> the code-base while needing 100% backward compatibility for all existing
>>> code and configurations.
>>
>> Yes.
>>
>> And that should be possible.
>>
>> Let us say that you have 200 packages with 2000 classes.
>>
>> You build with Java 9 and it runs unchanged.
>
> Our most current system is written in Scala. Currently no Scala version
> runs on Java9.

Since Java 9 is not officially release yet, then that is not
wildly surprising.

But I would expect Scala to eventually support Java 9.

To quote them:

<quote>
We are planning to add (some) support for Java 9 in the near future. 
Full Java 9 support will be part of the 2.13 roadmap discussions.</quote>

http://www.scala-lang.org/news/2.12.0

And then that issue goes away.

So you may not go to Java 9 when it is released, but it will come.

 >>>                             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?
 >
 > Can I depend on my libraries not doing that? And if they do: what can I
 > do about it? Upgrading to newer versions can not be done without
 > extensive modifications.

Use of unsupported features can cause a lot of pain. Which is
why one should not use them.

And Jigsaw will prevent that from happening again by simply
not exporting those.

There will be some pain now due to old sins.

 > Both of our current applications fail on Java9. One because it is
 > written in Scala. The other one is pure Java but it fails at startup
 > with spurious class loading exceptions that are related to the use of an
 > ancient Asterisk library which we have not yet been able to fix.

But one of the problem will go away by itself. And the other
has its root cause in previous mistakes - Jigsaw is just
bringing them forward.

And I find it a bit hard to see the justification for your
claim that anything "Besides greenfield toy applications"
can not be slowly migrated to Java 9 with basis in:
* a Scala application
* "ancient Asterisk library" library

I will claim that there are lots of non toy applications not
suffering from those.

Of course it is frustrating for you, but I don't see it as
a general problem.

>> Then you take 1/10'th (10 packages with 200 classes) and convert
>> to a module. The rest of the application is unchanged - all
>> you need to change is the ref in the build and run to use the
>> new module.
>
> No. You did not read the article linked by the OP. If you depend on
> service loading introducing modules possibly breaks your application.

All the most common usages of ServiceLoader works.

There are a some corner cases that breaks.

Like assuming a specific order of the services returned.

Maybe they should try and improve compatibility in this area.

That is a bit more specific than just postponing Jigsaw
completely.

Arne

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

#36588

On 5/2/2017 5:43 PM, Arne Vajhøj wrote:
> On 5/2/2017 4:45 PM, Silvio wrote:
>> On 05/02/2017 10:18 PM, 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?
>>
>> Can I depend on my libraries not doing that? And if they do: what can I
>> do about it? Upgrading to newer versions can not be done without
>> extensive modifications.
>
> Use of unsupported features can cause a lot of pain. Which is
> why one should not use them.
>
> And Jigsaw will prevent that from happening again by simply
> not exporting those.
>
> There will be some pain now due to old sins.

BTW, there is a workaround.

Let us say that something is using com.sun.java.swing.plaf.windows.
That was the package that Jan B had problems with and also the
one I have an application having problems with.

java --add-opens java.desktop/com.sun.java.swing.plaf.windows=ALL-UNNAMED

or:

java --add-exports java.desktop/com.sun.java.swing.plaf.windows=ALL-UNNAMED

will make that package available.

It is not a nice workaround - it is definitely a code smell. And
I suspect that it may go away some time in the future.

But if one has problems with Java 9 and accessibility and need
to move on, then it is a possibility.

Arne

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web