> 1. portlets that work in uPortal 4.2

I meant 4.1, of course.

Sent from my phone

On Jan 29, 2015, at 3:13 PM, Andrew Petro 
<[email protected]<mailto:[email protected]>> wrote:

Getting to latest GA Spring framework would be great.

Let’s consider calling the release that makes this upgrade uPortal 5.  The 
issues are subtle, but the very short version of what you wrote below is:

1. portlets that work in uPortal 4.2 instances today may not work in this new 
uPortal release without being updated, and
2. portlets that take advantage of the Java 8 language features available in 
this uPortal release will not work in uPortal 4.2 instance, and
3. it more or less matters whether a portlet is targeting uPortal 4.x or this 
uPortal release.

So, call it uPortal 5, and set roughly the right expectations about how much of 
a change we’re talking about between these releases.

Can make this tactical move without jumping to Semantic Versioning.  Pick that 
up for uPortal 6.0.0 if we can’t make the transition for this release. :)

Andrew



On Jan 29, 2015, at 2:59 PM, James Wennmacher 
<[email protected]<mailto:[email protected]>> wrote:

We've done some initial research on uPortal 4.2.0 supporting Java 8 (and only 
Java 8 so we can start to take advantage of its features) that I wanted to 
communicate to the community and solicit feedback on current research and 
thinking.  I will cross-post a message to portlet-dev alerting them to this 
conversation but wanted to keep the conversation in one place (this list).

First, many thanks to Gary Roybal at Unicon for doing all the research.

I expect the primary work of upgrading uPortal 4.2.0 to Java 8 involves 
updating to a version of Spring Framework that supports Java 8.  I expect there 
will be minor work related to updating documentation (altered JVM startup 
parameters), a few other unforeseen issues, and eventually someone may spend 
time trying the new-ish G1 garbage collector.

Currently, Spring 3.2.3 and greater supports deployment on JDK 8 [1] and Spring 
4.1.x supports some Java 8 features [2].  We could upgrade uPortal to support 
the latest Spring 3.2.x release (3.2.13) and still work with Java 8.  Spring 
Framework 3.2.x will support deployment on JDK 8 runtimes for applications 
compiled against JDK 7 (with -target 1.7) or earlier [1].  However the desired 
approach IMHO is to update uPortal 4.2.0 to use the latest Spring Framework 
4.1.x release since the Spring Framework 3.2.x line is effectively end of life 
at end of 2015 [3] and to benefit from Java 8 features in uPortal codebase.  We 
plan to move forward with uPortal migrating to Spring Framework 4.1.4 unless we 
find out that there is a significant technical issue or investment of time for 
uPortal to go to Spring Framework 4.1.4 as opposed to 3.2.13.

Supporting Java 8 also means that the Spring Framework in the portlets would 
also need to to be updated.  We are looking at updating the portlets to use 
Spring Framework 4.1.4 also.  However:

  *   the portlets generally must be compiled to Java 6 to be backwards 
compatible with uPortal 4.0.x [4].  This means of course no use of Java 8 
features in portlets (at least without doing a major rev release on the portlet 
and documenting its dependence on Java 8 and uPortal 4.2.0+) even though the 
portlet might be using Spring Framework 4.x
  *   A few portlets are currently compiled to Java 5. These will need to go to 
Java 6 as a target.  A quick check of the ones I have locally suggests this 
impacts Bookmarks, ESupTwitter, and SimpleContentPortlet.  There may be others.
  *   Though desirable due to EOL on Spring Framework 3.x in 2015, since there 
is no compelling reason to have to use Spring Framework 4.x in a portlet we may 
upgrade some portlets to Spring Framework 3.2.13 if we have a problem with 
Spring Framework 4.x in the portlet or it looks like it will take a lot of time 
for some reason.

Please let me know if you have other thoughts, opinions, suggestions, or 
concerns with this plan.  As a note, uPortal 4.2.0 should be able to run on 
Tomcat 7 or Tomcat 8 [5], but that is a separate issue from Java 8 support and 
is work that can be done later (and we'd love your help and contributions 
toward that!).

[1] http://spring.io/blog/2013/05/21/spring-framework-4-0-m1-3-2-3-available/
[2] 
http://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#_java_8_as_well_as_6_and_7
[3] 
http://spring.io/blog/2014/12/30/spring-framework-4-1-4-4-0-9-3-2-13-released
[4] https://wiki.jasig.org/display/UPM40/Requirements
[5] http://tomcat.apache.org/whichversion.html

other links:

  *   
http://www.oracle.com/technetwork/java/javase/8-compatibility-guide-2156366.html
  *   FYI on http://openjdk.java.net/jeps/173 - Referenced from bottom of above 
link.  Describes several GC options referenced in 
https://wiki.jasig.org/display/UPC/JVM+Configurations and possibly used at 
sites are deprecated (but not removed) in Java 8.

Looking forward to your thoughts.

Thanks,


James Wennmacher - Unicon
480.558.2420


--

You are currently subscribed to 
[email protected]<mailto:[email protected]> as: 
[email protected]<mailto:[email protected]>
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev


--

You are currently subscribed to 
[email protected]<mailto:[email protected]> as: 
[email protected]<mailto:[email protected]>
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

-- 
You are currently subscribed to [email protected] as: 
[email protected]
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Reply via email to