Date: Fri, 19 Jul 2013 12:24:51 +0200
Antonio/all,
Thanks for summing this up on Dzone, too:
http://www.dzone.com/links/r/my_java_ee_8_wishlist.html
I won't comment on all, especially those that are discussed elsewhere or
may require further consensus by at least some large stakeholders...
- No buzzwords
Agree, that is among reasons why a JSR around another buzzword, "Social"
was turned down, allowing it however, to be fostered along the lines of
Drools, Hibernate or Arquillian (by the same vendor[?]) and I wouldn't
outrule some of it spilling back into the JCP either in a dedicated JSR or
via others (351 being just one example where this already started[?])
- Security
See above, given the JCP.next requirements for progress (or
"hibernation", while of cource some JSRs that didn't get Final are still
more alive and kicking than others that were declared Final[?]) we'll see
an EDR of Identity API any time soon, and there's going to be a
presentation at JavaOne, too. These and a few other Spec Leads also got
your message for help with Java EE 8 session content[?]
- Enterprise services and stereotypes
This sounds like a great idea, once the definition of such "Service"
could be standardized and agreed on, too. Plus with EE 8 having to carry
the burden of SE 8 (see below, things aren't getting so modular and
reusable as it seems, on the contrary[?]) it may be too early before
Jigsaw or something similar makes Java modular enough for that (followed by
EE 9[?])
- CDI, CDI, CDI
I can't agree more, and for SE and at least its Embedded version, it
looks like future CDI Specs should support it. Unfortunately, the Java SE
ecosystem as a whole got worse with Java 8, especially when it comes to
reusability and modularization. Your Fellow Java Champion Lars Vogel did a
nice tutorial on Java Date/Time
http://www.vogella.com/articles/JavaDateTimeAPI/
Of course, with Java 8 this one won't go away, and while java.util.Date
is the only one you may call portable as it works all the way down to ME
Embedded, you got
- java.util.Date/Calendar
- java.util.concurrent.TimeUnit (especially relevant for e.g. new Java
EE Concurrency[?])
- java.time (incompatible with all the others except a tiny bridge to
java.util.Calendar)
- javafx.util.Duration used anywhere in JavaFX
- JSR 302 with a HighResolutionTime and API around it, at least for
Embedded systems or other Security Critical applications, if any of it
becomes relevant to Java EE 8, at least the estimated schedule
of both JSRs
means, it should be available before or around the time Java EE 8 is
releases.
plus others like ICU4J or JodaTime where projects use them already
and do not get rewritten just for the sake of refactoring...
As long as Java keeps growing into a large, monolithic block with
half a dozen redundant implementations of a (relatively) trivial
thing like
"What's the time?" CDI alone won't help, even if some or all of
these would
be CDI-enabled and work with @Inject.
One of the main problems are "leftover" JSRs like 302, 310 (now
java.time) or even 107 (JCache, you mentioned it) carrying a
legacy from a
different time (Java EE was still at EJB 2 then or earlier[?]) and now
half-heartedly squeezed into a Java ecosystem of the 21st Century
that evolved around technologies like CDI.
- Standard artifacts and repositories
This (aside from Logging, but I leave that aside for now, too[?]) could
be the most difficult of your wishes. The "IP WG" of JSR 358 currently
cares not a bit about public APIs, given its official scope is only RI/TCK.
And depending on the Spec Lead's discretion (see
https://java.net/jira/browse/JSR358-49 I was the only EC Member who
identified the problem and the only one with enough technical experience to
care unfortunately, all others discuss legal and other "buzzwords" mostly,
and a similar JIRA issue you may remember from DevoXX
https://java.net/jira/browse/JSR358-30 we heard, this is unlikely to
happen where people with a more technical approach could deal with such
problems[?])
Thus you'll end up having some JSRs where the API is considered part of
the RI, hence its package name may be "com.somecompany.someapi.*" while
others are defined either via the respective Forge or Foundation (org.*)
and a few call it "javax.*" or see 310 it gets sucked into OpenJDK and ends
up "java.*" also quite often the case we see "org.glassfish.*" JSRs now.
Based on above JIRA ticket 358-49 almost every Java EE 7 Spec Lead and
JSR (only 352 reacted too slow or probably still waits for the lawyers to
talk to each other?[?]) as well as a vast majority of those catering
towards EE 8 follows minimum requirements for the Spec License, but a
majority of them also considers the scope of the "Spec" to be just a plain
text document and the JavaDoc of the public API. The API itself usually
ends up being part of the RI, hence there is no consistent package naming
and it's almost impossible we'll see a consistent Maven or related artifact
naming either.
-- Werner Keil | JCP Executive Committee Member | Eclipse UOMo Lead, Babel Language Champion | Java Godfather | Mærsk DevOps Build Manager Twitter @wernerkeil | @JSR354 | #EclipseUOMo | #Java_Social | #DevOps Skype werner.keil | Google+ gplus.to/wernerkeil * Eclipse DemoCamps Kepler 2013: June-August 2013, Germany, Denmark, Austria, Norway. Werner Keil, UOMo Lead, Mærsk DevOps Build Manager will present "Triple-E’class DevOps with Hudson, Maven, Kokki, Multiconf & PyDev", "M4M 2 the Rescue of M2M" On Tue, Jul 16, 2013 at 10:32 AM, Antonio Goncalves < antonio.goncalves_at_gmail.com> wrote: > I think that is two different topics. > > Back at Devoxx BE 2009, Java EE 6 was going to be released and there was > already talks about "Java EE 7 and the Cloud". Being involved in Java EE > and the JCP, plenty of people came to me saying "really, Java EE 7 and the > Cloud ?". I felt I had nothing to say : no consultation between spec leads > and expert members. If I go to a 1h BOF at JavaOne about Java EE 8, what > would I say ? I don't know what the spec leads have in mind. I don't know > what Java EE 8 will be. I would just seat in the room and listen. > > What I am proposing is : let's kickoff Java EE 8, at least, between spec > leads and expert members (if "adoptajsr" adepts want to join, great), agree > on a road map, and then, we can all go to BOFs, conferences, gatherings... > and present what Java EE 8 will be. With Java EE 7 I would always started > my presentations saying "Oracle wants Cloud in Java EE 7, but most of the > expert members don't". That's not a very positive message and doesn't bring > cohesion to the group. > > Antonio > > > On Mon, Jul 15, 2013 at 6:03 PM, Markus Eisele <myfear_at_web.de> wrote: > >> Hi Antonio, >> >> As John D. A. pointed out on twitter it might not be the right way to do >> this in a closed circle round. I would offer my insights and I would for >> sure accept such an invitation from oracle but I must say that I would love >> to see a more open (transparent) approach here. >> Might be this could be an adopt-a-JSR effort or some kind of survey. >> >> Cheers, >> M >> >> Am Montag, 15. Juli 2013 schrieb Antonio Goncalves : >> >> Hi all, >>> >>> I was wondering if we could use JavaOne to brainstorm on Java EE 8. And >>> I'm not just talking about a one hour BOF between some spec leads/expert >>> members and developers, I am more thinking of a half day with only spec >>> leads and expert members. >>> >>> To be honest, I felt very frustrated when Oracle announced "Java EE 7 >>> being Cloudish". Nobody asked what the expert members thought of such >>> announcement, of what they had in their mind for the future of the plaform. >>> >>> What do you think of physically meeting before/during/after JavaOne and >>> start shaping the future of the platform ? >>> >>> Antonio >>> >>> On Mon, Jul 15, 2013 at 5:48 AM, Markus Eisele <myfear_at_web.de> wrote: >>> >>>> Hi all, >>>> >>>> after the buzz around the EE 7 release is silencing a bit I just >>>> wanted to take the opportunity to send around a link I came across >>>> yesterday: >>>> >>>> http://arjan-tijms.blogspot.de/2013/07/java-ee-8-wish-list.html >>>> >>>> Arjan compiled a list of things he would love to see in EE 8. Good to >>>> see some of it already on the list but also some new things like >>>> spending some time to modernize the security frameworks. >>>> >>>> Cheers, >>>> - Markus >>>> >>> >>> >>> >>> -- >>> Antonio Goncalves >>> Software architect and Java Champion >>> >>> Web site <http://www.antoniogoncalves.org> | Twitter<http://twitter.com/agoncal>| >>> LinkedIn <http://www.linkedin.com/in/agoncal> | Paris JUG<http://www.parisjug.org> | >>> Devoxx France <http://www.devoxx.fr> >>> >> > > > -- > Antonio Goncalves > Software architect and Java Champion > > Web site <http://www.antoniogoncalves.org> | Twitter<http://twitter.com/agoncal>| > LinkedIn <http://www.linkedin.com/in/agoncal> | Paris JUG<http://www.parisjug.org> | > Devoxx France <http://www.devoxx.fr> >
