Community
Participate
Working Groups
I saw the following tweet from Mark Reinhold Sorry, but we have no plans to ship 32-bit builds of JDK 9. We’re trying to focus more on the future than the past. Source : https://twitter.com/mreinhold/status/912311207935090689 What should be our plans on continuing support for 32-bit eclipse. For 32-bit we need 32-bit java. As it is not available anymore what will be future of 32-bit Eclipse?
For QNX Momentics, our latest release did not ship 32-bit. 64-bit only. I'm not sure how wise that was but so far there have been few complaints. For open source consumers who may have old machines, I think it may be important to keep it around one more release, i.e. Photon. That would like up nicely with the end of public updates for Java 8 which seems scheduled for Sept 2018. http://www.oracle.com/technetwork/java/eol-135779.html
There is no interest in having 32 bit Eclipse support after Photon is released from our side.
I don't care about Eclipse, but I care about 32-bit support of SWT. Though I don't have exact numbers available who still uses 32 bit Windows or Linux, but judging from the problems introduced by the GLIBC 2.14 requirement we had a couple of user complains who could not use our applications (SmartGit/SmartSVN) on their old systems (RedHat/CentOS 6.*) any more. That also keeps us at the moment at SWT 4.7 instead of going to 4.8. Not every user has the choice of what platform he is using. So please keep the 32-bit SWT for a while (maybe as long Windows/Linux is supporting 32-bit).
(In reply to Thomas Singer from comment #3) > So please keep the 32-bit > SWT for a while (maybe as long Windows/Linux is supporting 32-bit). Are you volunteering to maintain and support the SWT 32-bits related effort?
People expressing interest in keeping support for something have to vote with their feet. Aka actively test and provide patches if/when someone didn't made bindings for new features in 32/64 compatible way. We can not expect people to go to such extend of their work like finding old JVM, OS and etc. if others running on such are not stepping up.
(In reply to Mickael Istria from comment #4) > (In reply to Thomas Singer from comment #3) > > So please keep the 32-bit > > SWT for a while (maybe as long Windows/Linux is supporting 32-bit). > > Are you volunteering to maintain and support the SWT 32-bits related effort? No, but our company already offered money to attract people fixing bugs. The interest was, er, negligible. Feel free to offer Eclipse just as 64-bit application (without dropping SWT support) and see how much people will scream. We are trying this for the next SmartGit version 18.1.
(In reply to Thomas Singer from comment #6) > (In reply to Mickael Istria from comment #4) > > (In reply to Thomas Singer from comment #3) > > > So please keep the 32-bit > > > SWT for a while (maybe as long Windows/Linux is supporting 32-bit). > > > > Are you volunteering to maintain and support the SWT 32-bits related effort? > > No, but our company already offered money to attract people fixing bugs. The > interest was, er, negligible. Why not growing a committer? My team has done it with multiple people and they are active SWT committers now. It requires patience and will and we will support you into that if you go that way. > > Feel free to offer Eclipse just as 64-bit application (without dropping SWT > support) and see how much people will scream. We are trying this for the > next SmartGit version 18.1.
To me the problem is more of maintaining 32-bit java. With the tweet mentioned in https://bugs.eclipse.org/bugs/show_bug.cgi?id=526620#c0 it is clear that Oracle is not planning for 32-bit java in future. In this scenario if any one wants to support 32-bit they need to rebuild Java from source or use old java versions. We need to identify when we can drop 32-bit support. According to http://www.oracle.com/technetwork/java/eol-135779.html the end of public updates for java8 (last release with 32-bit support) is Sep 2018. I believe we should be drop 32-bit support after that.
When there are no more public Java updates for 1.8 I think we don't have a choice as we can not request contributors to pay for it or to run insecure versions.
I had a look at download stats ( https://dev.eclipse.org/committers/committertools/stats.php ) to count the number of downloads of Oomph installer for Oxygen release (as linked from download pages): * On Linux ** 32 bits: 16008 (~3.2%) ** 64 bits: 481855 (~96.8%) * On Windows ** 32 bits: 158728 (~3.5%) ** 64 bits: 4195326 (~96.5%) So the proportion of users that would suffer from this drop would be very minimal. The cost of maintaining 32-bits support of the IDE for 3.5% of users is not worth it for our community IMO. This would free us (contributors, infra) enough resources to work on more profitable things. I believe we should simply abandon community support (including builds and others) for everything that's 32-bits related. Adopters who still need those 32-bits support should come with necessary workforce and infra effort to keep it maintained @Eclipse.org, or should build them on their own.
I agree with the conclusion but not the rationale; 170,000 is a lot of 32 bit 'users' to upset. However one might guess that half the 32 bit downloads were repeats and that half were from habit rather than necessity. Still 40,000 upset users. Much more fundamental to me is the argument that a user who wants 32 bits wants everything that goes with it, and that is already there. They can use Oxygen and Java 8 for as long as they need 32 bit support.
I see dropping 32 bit support to be a great motivation to move to 64 bit :-).
(In reply to comment #8) > To me the problem is more of maintaining 32-bit java. > > With the tweet mentioned in > https://bugs.eclipse.org/bugs/show_bug.cgi?id=526620#c0 it is clear that Oracle > is not planning for 32-bit java in future. > > In this scenario if any one wants to support 32-bit they need to rebuild Java > from source or use old java versions. > > We need to identify when we can drop 32-bit support. According to > http://www.oracle.com/technetwork/java/eol-135779.html the end of public updates > for java8 (last release with 32-bit support) is Sep 2018. I believe we should be > drop 32-bit support after that. The Sep 2018 date for removal of public updates for java8 is for Oracle Java. For OpenJDK: "We will support OpenJDK 8 until October 2020" http://mail.openjdk.java.net/pipermail/jdk-dev/2017-November/000175.html Also Eclipse OpenJ9: "(*3): We fully expect that OpenJDK8 will have open community maintainers beyond January 2019, so we expect to be able to continue supporting JDK8 beyond that date. Until maintainers have been established we are unable to make a definitive support statement. This position is the same for JDK11 and all future "LTS" releases." https://www.eclipse.org/openj9/docs/openj9_support/ Also IBM SDK, Java Technology Edition https://developer.ibm.com/javasdk/2018/04/26/java-standard-edition-ibm-support-statement/ https://developer.ibm.com/javasdk/support/lifecycle/
2018-12 no longer contains 32bit builds. https://www.eclipse.org/downloads/packages/release/2018-12/m3
