[JSR-354] Re: JSR News
- From: Werner Keil <werner.keil@...>
- To: "jcurrency_mail@..." <jcurrency_mail@...>
- Subject: [JSR-354] Re: JSR News
- Date: Mon, 12 May 2014 14:23:42 +0200
Thanks a lot for the update. As discussed with some of you (especially
Otavio and yourself) technically it seems not a bad intention to have even
the main API based on Java 8.
A major caveat however is the recently revived "Lawsuit Zombie" of Oracle
against Google, which isn't just about Android or whether Google might have
to pay a few cent (per device[?]) in license fees or damages... It's more
about API patentability, and looking at it from this angle, even the
original authors (Spec Lead and/or EG) could have trouble offering
something that "feels like the official javax.something" under a new Open
Source project "org.something.backport". I mentioned the risk around JSR
310, not just the troubles the JSR itself caused to Java 8 and the Java
ecosystem, but that given you have a functionally nearly identical project
like JodaTime, it seems like a waste of time and effort. Plus, if the API
patent war ends in Oracle's favor here, it could be extremely dangerous to
offer a "modeled after javax.something" API, especially to large
I'm sure you heard of another ruling on financial software patents
effectively destroying a pilar of RBS' IT:
licensing company is called "CSI", odd[?]) and while on the HW side, Bank of
America filed patent requests not far from Apple's patents for "An ATM with
a USB port"
something like that was approved, then every bank in the world or at least
US would likely have to "feed the Patent Troll"[?]
If you haven't done so, I strongly advise you discuss the issue with the CS
legal folks, probably also your EC rep (as they naturally have to deal with
patents and licensing a lot, too[?])
Ask them, how they see the prospect of a "backport" and if banks or similar
financial institutions with a large codebase of Java 7 or even 6 would feel
about using such "backport" in their business critical IT and Java
Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead |
Eclipse UOMo Lead, Babel Language Champion | Java Godfather
Twitter @wernerkeil | @UnitAPI | @JSR354 | #EclipseUOMo | #Java_Social |
Skype werner.keil | Google+ gplus.to/wernerkeil
* EclipseCon France WG Unconference: 17 Jun 2014, Toulouse, France. Werner
Keil and Jean-Marie Dautelle, JSR 363 Spec Leads will present "JSR 363 and
the Quantified Self"
* Developer Week: 14/15 Jul 2014, Nürnberg, Germany. Werner Keil, JCP EC
Member, JSR 363 Spec Lead, DevOps Guy will present "Triple-E' class
Continuous Delivery", "JSR 363 and IoT" (GER)
* Mobile Developer Conference kompakt: 18 Nov 2014, Hamburg, Germany.
Werner Keil, JCP EC Member, Apache DeviceMap Committer will present "Apache
On Sun, May 11, 2014 at 3:40 PM, Otávio Gonçalves de Santana <
> Great news!!
> 2 - Nowadays Java 9 is Java 8 with fixes bug and improvement of
> performance, but I thing it will be great
> ref: http://openjdk.java.net/projects/jdk9/
> On Sun, May 11, 2014 at 10:27 AM, Anatole Tresch <atsticks@...>wrote:
>> Dear all
>> having further discussion along our Public Review 2 I would like to
>> summarize my current idea how we should proceed with our JSR:
>> 1. We would simplify some aspects especially in the formatting area
>> (replace AmountStyle with AmountFormatContext), remove CurrencyStyle).
>> especially based on valuable feedback from LJC (thanks guys!).
>> 2. I decided further to move the JSRs documentation from Google Doc
>> into asciidoc. The spec is checkedin under main/src/asciidoc in the
>> 3. One other important topic is JDK 8 support. Regarding later
>> inclusion in JDK 9 it is quite more useful to move to JDK 9 also on the
>> and RI / TCK part as of now (*there are basically only very few
>> changes necessary on API level*).
>> 4. Additionally we will provide a JDK 7 compatible backport of the
>> API and RI. This backports will be forward compatile with the final API
>> this JSR, so it is usable by people already as of now, without having to
>> change the code later, when moving to the JDK based API/enabling JDK 8
>> (changes may necessary, if they want to benefit from the new JDK
>> of course).
>> 5. If possible, interested people may also be able to provide a ME
>> port of the API. Other languages, of course, are welcome, too...
>> I see several advantages in doing so:
>> - integration into JDK 9 is much easier.
>> - we can make use of new JDK features ;-)
>> - we can fully base on SE 8.
>> - JDK 7 / ME support can be done separately.
>> - Users based on JDK 7 can still use our API based on the backport.
>> Moving forward does not require any code changes.
>> - An ME compatible variant can be developed separately by interesting
>> A first port of the API (still work in progress) is available in the
>> "master-jdk8" branch on the "jsr354-api" repository.
>> *If someone sees important aspects, why we should not go that way, let me
>> know. Or just let us know, what you think.*
>> I will adapt the repositories accordingly next week during Geekon
>> conference in Poland. So at the end of the week, we should have a stable
>> state again on all the repos and a clear strategy, how to go with JDK 8
>> *Anatole Tresch*
>> Java Lead Engineer, JSR Spec Lead
>> Glärnischweg 10
>> CH - 8620 Wetzikon
>> *Switzerland, Europe Zurich, GMT+1*
>> *Twitter: @atsticks*
>> *Blogs: **http://javaremarkables.blogspot.ch/
>> *Google: atsticksMobile +41-76 344 62 79 <%2B41-76%20344%2062%2079>*
> Otávio Gonçalves de Santana
> blog: http://otaviosantana.blogspot.com.br/
> twitter: http://twitter.com/otaviojava
> site: *http://about.me/otaviojava <http://about.me/otaviojava>*
> 55 (11) 98255-3513
Description: GIF image
Description: GIF image
Description: GIF image