Shardingsphere: [Vote] upgrade JDK8 on Sharding-Sphere 3.x

Created on 17 Aug 2018  ·  77Comments  ·  Source: apache/shardingsphere

JDK8 is more popular, and JDK 7 has abandoned by oracle.
In future, we will use service-comb-saga(https://github.com/apache/incubator-servicecomb-saga) to to deal with BASE transaction. Saga only support JDK 8 and above version. So we planning upgrade to JDK 8 for new Sharding-JDBC and Sharding-Proxy on 3.0.0.

This vote will open in at least a week. Welcome any contributor, end user and interested people to express themselves.

Voters can either respond "agree, yes, +1", "disagree, no, -1", or "abstain".

discussion

Most helpful comment

Hi all PMC members(@terrymanu @haocao @hanahmily @PegasusS @pottieva )

I provided you with the following resources of the biggest Java community. Spring. Notice that even Spring didn't dare to upgrade directly. We need to be careful with that.

As of Spring Framework 4.0, Java 8 is supported as a first-class citizen and we’ve seen some confusion in the Spring community since then. How do we manage to support Java 8 and remain compatible with Java 6 and Java 7 after all?

See https://spring.io/blog/2015/04/03/how-spring-achieves-compatibility-with-java-6-7-and-8

My opinion is, if Saga needs JDK 8, the question is, in the compile stage or running stage. Even in the running stage. ShardingSphere could be compiled into two components, ss-core, and ss-transaction.

ss-core could stay in JDK 7 for the longer term. ss-transaction moved into JDK 8, considering it is the new feature to everyone, right?

Of course, this is only about Sharding-Sphere's JDBC lib part. Sharding-Sphere Proxy is free to upgrade.

All 77 comments

+1

agree, yes, +1

+1

+1

+1

+1

+1

+1

+1

+1

+1,期待使用上函数式编程的API

+1

+1

agree, yes, +1

+1

agree, yes, +1

+1

agree, yes, +1

+1

+1

+1
+1
+1

+1

+1

agree, yes, +1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

agree, yes, +1
Many open source frameworks runs on a JDK higher than or equal to version 8.

+1

agree, yes, +1

agree, yes, +1

agree, yes, +1

+1

+1

+1

agree, yes, +1

agree, yes, +1

agree, yes, +1

+1

agree, yes, +1

agree, yes, +1

Hi all PMC members(@terrymanu @haocao @hanahmily @PegasusS @pottieva )

I provided you with the following resources of the biggest Java community. Spring. Notice that even Spring didn't dare to upgrade directly. We need to be careful with that.

As of Spring Framework 4.0, Java 8 is supported as a first-class citizen and we’ve seen some confusion in the Spring community since then. How do we manage to support Java 8 and remain compatible with Java 6 and Java 7 after all?

See https://spring.io/blog/2015/04/03/how-spring-achieves-compatibility-with-java-6-7-and-8

My opinion is, if Saga needs JDK 8, the question is, in the compile stage or running stage. Even in the running stage. ShardingSphere could be compiled into two components, ss-core, and ss-transaction.

ss-core could stay in JDK 7 for the longer term. ss-transaction moved into JDK 8, considering it is the new feature to everyone, right?

Of course, this is only about Sharding-Sphere's JDBC lib part. Sharding-Sphere Proxy is free to upgrade.

+1

-1
Upgrading incompatible codes and dependencies is totally a disaster for original system.

FYI @WillemJiang https://github.com/sharding-sphere/sharding-sphere/issues/1157#issuecomment-413795884 Can you confirm the info about Saga project?

+1

+1

+1

+1

agree, yes, +1

-1

agree, yes, +1

+1

Sharding-JDBC is a framework, upgrade means all application which use JDK7 and below versions cannot support any more.
So, just like @wu-sheng said, we need to recognize , it is really a big revolution for Sharding-JDBC, the legacy system maybe cannot run any more.

Sharding-JDBC is a framework, upgrade means all application which use JDK7 and below versions cannot support any more.
So, just like @wu-sheng said, we need to recognize , it is really a big revolution for Sharding-JDBC, the legacy system maybe cannot run any more.

If PMC agreed with my proposal and it is executable, I hope to cancel this vote. Just make the new ss-transaction and ss-proxy into JDK8 without harm anyone, and keep ss-core in JDK 7, which will make everyone happy.

+1

+1

+1

+1

+1

+1

+1

+1

+1

@wu-sheng from the experience of Spring 4.x,

We chose not to use any Java 7 or Java 8 language features in our own codebase in order to give you the flexibility to write your Spring 4 applications for Java 6, 7 or 8.

I think we can consider to separate the actor module from the saga-core and let the saga-core only use the Java7 feature.

@terrymanu @WillemJiang How about we close this, and discuss the jdk requirement of each component in a separated issue? This vote thread burns my mailbox.🤣🤣

@wu-sheng ok, we just cancel vote now. We just do not upgrade jdk version. for sharding-sphere side, we can consider about only upgrade sharding-transaction module.
@WillemJiang it is the best solution if saga can separate the actor module from the saga-core.

+1

Was this page helpful?
0 / 5 - 0 ratings