Path: csiph.com!aioe.org!.POSTED!not-for-mail From: =?UTF-8?Q?Arne_Vajh=c3=b8j?= Newsgroups: comp.lang.java.programmer Subject: Re: Jigsaw: RedHat and IBM say no Date: Tue, 2 May 2017 16:18:13 -0400 Organization: Aioe.org NNTP Server Lines: 83 Message-ID: References: <59079419$0$24666$e4fe514c@newszilla.xs4all.nl> <5907a5ef$0$24695$e4fe514c@newszilla.xs4all.nl> <5908e12b$0$20463$e4fe514c@newszilla.xs4all.nl> NNTP-Posting-Host: PBuS014lhzVyHjLbXmo/ZQ.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 X-Notice: Filtered by postfilter v. 0.8.2 Xref: csiph.com comp.lang.java.programmer: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