Skip to main content

[JSR-354] Re: Components

  • From: Chris Pheby <chris@...>
  • To: "jcurrency_mail@..." <jcurrency_mail@...>
  • Subject: [JSR-354] Re: Components
  • Date: Fri, 1 Feb 2013 13:27:26 +0000
  • Accept-language: en-GB, en-US

That would be 8.30pm GMT? That would be 4.30 in the morning here…

 

In terms of setting up a regular teleconference, if it was about 8.00pm here, that would be 1.00pm CET, 12 GMT, and 8am in Western USA, that would probably be the best time for all to join.

 

Regards Chris

 

From: Jeremy Davies [mailto:jerdavies@...]
Sent: 01 February 2013 16:57
To: jcurrency_mail@...
Cc: jcurrency_mail@...
Subject: [JSR-354] Re: Components

 

20:30 suits fine. Have a 2 year old and in approximately 3 weeks will have a 0 year old girl. Still, only 18 years before they leave home so not long...

Sent from my iPhone


On 1 Feb 2013, at 08:36, Anatole Tresch <atsticks@...> wrote:

Hi Jez

 

welcome to the club ;-), my are 1,5 and 7. That is also the reason why I tend to meet in the evening after 20:30 CET ;-)

 

Cheers

2013/2/1 Jeremy Davies <jerdavies@...>

I'm in London so CET suits. It would certainly help me get a clearer picture of where we are and consolidate the email chains. I can be available most evenings (having small children means my social life is practically zero :)

 

Cheers

Sent from my iPhone


On 31 Jan 2013, at 23:52, Anatole Tresch <atsticks@...> wrote:

Hangouts on Google are better in the evening not earlier than 20:30 CET and preferrably not later than 22:00 pm CET, if possible. Hangouts would also allow for visual feedback.

For telephone conf calls, I can also easily setup  conferences using the Credit Suisse infrastructure, where you can dialin world wide. This kind I can be available starting from 8:30 CET.

 

Cheers,

Anatole

 

Lets see what else is required. Chris is in Singapur, as far as I know.... So Singapur to US west coast may be the maximum of timezones I guess...

2013/2/1 Werner Keil <werner.keil@...>

Guess we should gather suggestions.

 

I have calls with some projects throughout the week. Mainly Tuesday 7-8pm CET, Thursday an hour earlier, and a JCP.next WG call, I join whenever I can for now on Friday very late (~10pm CET) Aside from these 3, I'd be relatively flexible, ideally not earlier than 6pm CET if it was a Hangout (I have no Wifi in the office where I am now, not sure, if I could request it for Android tablets) otherwise, if we had a conference call bridge with a number  anywhere in Europe, I guess I could even join calls earlier. E.g. one of our team mates is a Hudson committer who joins its calls once a week, too.

 

CLDC EG also plans to have a weekly call, but we have not started discussing the best time for that either. 

 

As of now, except Bob it looks like most of us are either in GMT or CET, right? Depending on what works best for most, some of these times would also be from around 9am PST, so people in America could also join. As long as we have few active participants from India or East Asia, that might make it a little easier<347.gif>

 

Btw., while I couldn't implement a full JavaFX Binding for MonetaryAmount or implementing classes in the short time of the NightHacking Session, I gatered most of the interfaces and base classes necessary to do so with JavaFX Architect Stephen Chin. And also demonstrated arithmetics of MonetaryAmount in a live session and recorded webstream (check nighthacking.com, I guess, will send the link or put it on the Wiki somewhere if I can soon) as part of Stephen's NightHacking Tour. A good opportunity to make people aware of it. And I'll start working on such JavaFX example including a binding in the GitHub example project.

 

Groovy/Grails was another area demonstrated. And for the local Gr8Conf in May, the host of that event said, there is a CFP and e.g. a "Grails Currency" plugin like this https://github.com/ricardojmendez/grails-currencies but for more recent Grails versions and the Money JSR might also be a good topic to show here in Copenhagen.

 

Btw., he also said, Groovy and Grails generally uses BigDecimal for all decimal values. Interesting to know<329.gif>

 

Cheers,

Werner

On Fri, Feb 1, 2013 at 12:10 AM, Jeremy Davies <jerdavies@...> wrote:

Do you guys have a schedule in place for conference calls to discuss next steps etc?

 

Cheers

Sent from my iPhone


On 31 Jan 2013, at 17:27, Werner Keil <werner.keil@...> wrote:

Looks good, thanks.

 

Btw, regarding portability, just to let you know, the CLDC 8 "Umbrella" Profile started today, and the Spec Lead wishes to plan calls and discussions in weekly intervals, so it looks like they want to catch up on a bit of the lost time there, too (keep in mind, that JSR just like 354 also falls under JCP 2.9, so it'll risk Renewal Ballots if nothing happens like an EDR soon<329.gif>) 

 

Whether those efforts take place in OpenJDK or another appropriate place, we should be able to contribute to relevant parts.

Most packages and classes are subsets of Java SE 8, javax.microedition is upgraded from the CLDC 1.1.1 spec:

  • java.lang
  • java.lang.ref
  • java.io
  • java.util

Meaning, a scaled down version of java.util.Currency as an RI for a limited part of the JSR (probably no more than the core-api) plus java.util.Money or a similar value type are perfectly in scope here. The platform and those platform JSRs define demand, if CLDC 8 happens before SE 9, so be it, and we can actually focus on a smaller set first, while fleshing other, heavier parts out for SE 9.

 

Cheers,

Werner

On Thu, Jan 31, 2013 at 5:32 PM, Tresch Anatole (KFSC 225) <anatole.tresch@...> wrote:

Dear Colleagues

 

I have defined the components in JIRA as for me should make sense. Feel free to give feedback. In short I’ve defined the following components:

<image001.gif>build and quality improvement

(Edit | Delete)

<image001.gif>misc: examples

(Edit | Delete)

<image001.gif>misc: presentations

(Edit | Delete)

<image001.gif>RI: Basic RI

(Edit | Delete)

<image001.gif>RI: JDK Adaptations

(Edit | Delete)

<image001.gif>spec: conversion

(Edit | Delete)

<image001.gif>spec: core

(Edit | Delete)

<image001.gif>spec: extensions

(Edit | Delete)

<image001.gif>spec: format

(Edit | Delete)

<image001.gif>spec: specification (Lead: atsticks)

(Edit | Delete)

<image001.gif>TCK

(Edit | Delete)

 

 

As you see, currently I only am the owner of the specification document. So everybody that wants to take over a basic default component responsibility can  ask for ;-)

Afterwards we have to define also the features and requirements and assign them to the components. Any support in this area is quite welcome!

 

By the way: the ongoing renewal ballot for this JSR looks good so far. This should allow us to continue effectively with our work.

 

Regards,

Anatole

 

Anatole Tresch

CREDIT SUISSE AG

Information Technology | Java Core Framework & Support, KSXK 23

Zollstrasse 20/36 | 8070 Zürich | Switzerland

Phone +41 44 334 03 89

anatole.tresch@... | www.credit-suisse.com

 

From: Werner Keil [mailto:werner.keil@...]
Sent: Wednesday, January 30, 2013 19:06
To: jcurrency_mail@...
Subject: [JSR-354] Feature Leads (as seen in JSR 347)

 

Dear All,

 

JSR 347, "Data Grid" which also is among the few JSRs with a Twitter handle btw., released this call on Google Groups: https://groups.google.com/forum/?fromgroups=#!topic/jsr347/D5-KATaXrzI

 

For all those who are official EG Members of JSR 354 (making it easier with IP and all that stuff, everyone may contribute, but officially only EG Members are supposed to add it to the Spec<image002.gif>) something similar may be a good idea here, too.

 

@Anatole, or anybody (also non-EG members) on the list, please suggest features or components. Also good to transfer that into JIRA as soon as the list of features is known and accepted.

 

The modules that currently exist could be a starting point:

  • Spec
    • Core + Singleton (I would say semantically close enough)
    • Convert
    • Format
    • Ext
  • RI
    • Standalone
    • JDK
  • TCK (tbd, there is no module yet)

There may of course be logical areas like 

  • Rounding
  • Precision
  • etc.

feel free to suggest something you think is important enough to form a "feature" or "component" right now.

 

TIA,

Werner

 

 



 

--

Anatole Tresch

Java Lead Engineer, JSR Spec Lead
Glärnischweg 10
CH - 8620 Wetzikon

 

Switzerland, Europe Zurich, GMT+1

Twitter:  @atsticks

Google: atsticks
Phone   +41-44 334 40 87
Mobile  +41-76 344 62 79



 

--

Anatole Tresch

Java Lead Engineer, JSR Spec Lead
Glärnischweg 10
CH - 8620 Wetzikon

 

Switzerland, Europe Zurich, GMT+1

Twitter:  @atsticks

Google: atsticks
Phone   +41-44 334 40 87
Mobile  +41-76 344 62 79



[JSR-354] Re: Components

(continued)

[JSR-354] Re: Components

Anatole Tresch 02/01/2013

[JSR-354] Re: Components

Jeremy Davies 02/01/2013

[JSR-354] Re: Components

Tresch Anatole (KFSC 225) 02/01/2013

[JSR-354] Re: Components

Stephen Colebourne 02/01/2013

[JSR-354] Re: Components

Werner Keil 02/01/2013

[JSR-354] Re: Components

Werner Keil 02/01/2013

[JSR-354] Re: Components

Tresch Anatole (KFSC 225) 02/01/2013

[JSR-354] Re: Components

Sascha Freitag 02/01/2013

[JSR-354] Re: Components

Anatole Tresch 02/01/2013

[JSR-354] Re: Components

Sascha Freitag 02/01/2013

[JSR-354] Re: Components

Chris Pheby 02/01/2013

[JSR-354] Re: Components

Werner Keil 02/01/2013

[JSR-354] Re: Components

Sascha Freitag 02/01/2013
 
 
Close
loading
Please Confirm
Close