[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 15:15:07 +0200
Thanks for the reply. I agree, that if copyright holders are the same in
both cases (the "Backport" would nevertheless more likely be all Apache,
Spec License won't apply outside the "javax" codebase) it makes it a bit
As you speak with Oracle in other cases, it seems best to also have a chat
with them on this. Potentially involving the license/legal folks, too, then
we could clarify if it's safe and advisable.
On Mon, May 12, 2014 at 3:01 PM, Anatole Tresch <atsticks@...> wrote:
> Hi Werner
> I also followed the things happening here. One major difference is that
> Credit Suisse is still the owner of the API. So if Credit Suisse provides a
> backport, there is nothing to fear. Additionally Credit Suisse and Oracle
> act more as partners. So things are different in this case. And be honest,
> Google really copied over quite a couple of things. They knew well what
> they are doing. For Google it was worth the try. But it was done to obvious
> IMO. Microsoft did it better, when they catched the ideas originally
> developed within the Apple Toolbox for their Windows APIs.
> And one last word: Oracle is aware of the possible risk, what would
> happen, if the Java ecosystem would be too much constraint. I would say, we
> would have to wait not more than 6-12 months until a new successor will be
> on the market (or the. .net platform is taking over control...).
> Anatole Tresch
> Glärnischweg 10
> 8620 Wetzikon
> Tel +41 (43) 317 05 30
> Send from Mobile
> Am 12.05.2014 um 14:23 schrieb Werner Keil <werner.keil@...>:
> 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<329.gif>) 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<329.gif>) 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"<341.gif>
> 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<347.gif>)
> 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 infrastructure.
> Kind Regards,
> 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
> DeviceMap" (GER)
> On Sun, May 11, 2014 at 3:40 PM, Otávio Gonçalves de Santana <
> otaviopolianasantana@...> wrote:
>> 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 API
>>> 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 of
>>> this JSR, so it is usable by people already as of now, without having
>>> 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 parties.
>>> 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