Search Results

Search found 407 results on 17 pages for 'jsr 361'.

Page 1/17 | 1 2 3 4 5 6 7 8 9 10 11 12  | Next Page >

  • JSR 360 and JSR 361: A Big Leap for Java ME 8

    - by terrencebarr
    It might have gone unnoticed to some, but Java ME took a big leap forward a couple of weeks ago with the filing of two new JSRs: JSR 360: “Connected Limited Device Configuration 8″ (aka CLDC 8) JSR 361: “Java ME Embedded Profile” (aka ME EP) Together, these two JSRs will significantly update, enhance, and modernize the Java ME platform, and specifically small embedded Java, with a host of new features and functionality. JSR 360 – Connected Limited Device Configuration 8 CLDC 8 is based on JSR 139 (CLDC 1.1) and updates the core Java ME VM, language support, libraries, and features to be aligned with Java SE 8. This will include: VM updated to comply with the JVM language specification version 2 Support for SE 7/8 language features like Generics, Assertions, Annotations, Try-with-Resources, and more New libraries such as Collections, NIO subset, Logging API subset A consolidated and enhanced Generic Connection Framework for multi-protocol I/O With CLDC 8, Java ME and Java SE are entering their next phase of alignment – making Java the only technology today that truly scales application development, code re-use, and tooling across the whole range of IT platforms, from small embedded to large enterprise. JSR 361 – Java ME Embedded Profile ME EP is based on JSR 228 (IMP-NG) and updates the specification in key areas to provide a powerful and flexible application environment for small embedded Java platforms, building on the features of CLDC 8:  A new, lightweight component and services model Shared libraries Multi-application concurrency, inter-application communication, and event system Application management API optionality, to address low-footprint use cases With ME EP, application developers will have a modern application environment which allows development and deployment of  modular, robust, sophisticated, and footprint-optimized solutions for a wide range of embedded use cases and devices. Summary While these JSRs are still under development, it’s clear that there are exciting new times ahead for Java ME – turning into a serious application platform while maintaining the focus on resource-constrained devices to address the expected explosion of small, smart, and connected embedded platforms. To learn more, click on the above links for JSR 360 and JSR 361. Or review the JavaOne 2012 online presentations on the topic: CON11300: Expanding the reach of the Java ME Platform CON5943: Java ME 8 Service Platform And stay tuned for more in this space! Cheers, – Terrence Filed under: Mobile & Embedded Tagged: "jsr 360", "jsr 361", "me 8", embedded, Embedded Java, JCP

    Read the article

  • JSR 360 and JSR 361: A Big Leap for Java ME 8

    - by terrencebarr
    It might have gone unnoticed to some, but Java ME took a big leap forward a couple of weeks ago with the filing of two new JSRs: JSR 360: “Connected Limited Device Configuration 8″ (aka CLDC 8) JSR 361: “Java ME Embedded Profile” (aka ME EP) Together, these two JSRs will significantly update, enhance, and modernize the Java ME platform, and specifically small embedded Java, with a host of new features and functionality. JSR 360 – Connected Limited Device Configuration 8 CLDC 8 is based on JSR 139 (CLDC 1.1) and updates the core Java ME VM, language support, libraries, and features to be aligned with Java SE 8. This will include: VM updated to comply with the JVM language specification version 2 Support for SE 7/8 language features like Generics, Assertions, Annotations, Try-with-Resources, and more New libraries such as Collections, NIO subset, Logging API subset A consolidated and enhanced Generic Connection Framework for multi-protocol I/O With CLDC 8, Java ME and Java SE are entering their next phase of alignment – making Java the only technology today that truly scales application development, code re-use, and tooling across the whole range of IT platforms, from small embedded to large enterprise. JSR 361 – Java ME Embedded Profile ME EP is based on JSR 228 (IMP-NG) and updates the specification in key areas to provide a powerful and flexible application environment for small embedded Java platforms, building on the features of CLDC 8:  A new, lightweight component and services model Shared libraries Multi-application concurrency, inter-application communication, and event system Application management API optionality, to address low-footprint use cases With ME EP, application developers will have a modern application environment which allows development and deployment of  modular, robust, sophisticated, and footprint-optimized solutions for a wide range of embedded use cases and devices. Summary While these JSRs are still under development, it’s clear that there are exciting new times ahead for Java ME – turning into a serious application platform while maintaining the focus on resource-constrained devices to address the expected explosion of small, smart, and connected embedded platforms. To learn more, click on the above links for JSR 360 and JSR 361. Or review the JavaOne 2012 online presentations on the topic: CON11300: Expanding the reach of the Java ME Platform CON5943: Java ME 8 Service Platform And stay tuned for more in this space! Cheers, – Terrence Filed under: Mobile & Embedded Tagged: "jsr 360", "jsr 361", "me 8", embedded, Embedded Java, JCP

    Read the article

  • JSR Updates and Inactive JSR ballots

    - by heathervc
    The following are JSRs have posted updates in the last week: JSR 331, Constraint Programming API, has posted a Maintenance Draft Review; this review closes 29 September. JSR 352, Batch Applications for the Java Platform, has posted an Early Draft Review; this review closes 29 September. JSR 353, Java API for JSON Processing, has posted an Early Draft Review; this review closes 7 October. Inactive JSRs: The following JSR proposals have been Inactive for at least two years and are currently on the EC ballot to be declared Dormant, following a period where the community was given an opportunity to express interest in their continued development: JSR 50, Distributed Real-Time Specification JSR 282, Real-Time Specification for Java (RTSJ) 1.1 JSR 307, Network Mobility and Mobile Data API JSR 327, Dynamic Contents Delivery Service API for Java ME JSR 328, Change Management API

    Read the article

  • Recent JSR Updates-JSR 356, 357, 355, 349, 236

    - by heathervc
    JSR 357, Social Media API, was not approved by the SE/EE EC to continue development in the JCP program. JSR 356, Java API for WebSocket, was approved by the SE/EE EC to continue development in the JCP program. JSR 355,  JCP Executive Committee Merge, published an Early Draft Review; this review closes 27 April.  You can read more about JSR 355 here. JSR 349, Bean Validation 1.1, published an Early Draft Review; this review closes 27 April. JSR 236,  Concurrency Utilities for Java EE, has updated the JSR page and moved to JCP version 2.8.

    Read the article

  • JSR updates - November 2013

    - by Heather VanCura
     This week has been a busy week for JCP participants! Ten JSRs related to the upcoming Java Standard Edition (Java SE) 8 release posted public reviews--four Public Reviews and six Maintenance Reviews.  All JSRs are operating under the latest version of the JCP program and have public feedback mechanisms and issue trackers.  Please review and comment on these JSRs--your input and participation is wanted and needed!  JSR 308, Annotations on Java Types, published a Public Review. This review closes 4 December. JSR 310, Date and Time API, published a Public Review. This review closes 4 December. JSR 335, Lambda Expressions for the Java Programming Language, published a Public Review. This review closes 4 December. JSR 337, Java SE 8 Release contents, published a Public Review.  This review closes 4 December. JSR 221, JDBC 4.0 API, published a Maintenance Review.  This review closes 4 December. JSR 199, Java Compiler API, published a Maintenance Review.  This review closes 4 December. JSR 160, Java Management Extensions Remote API, published a Maintenance Review.  This review closes 4 December. JSR 114, JDBC Rowset Implementations, published a Maintenance Review.  This review closes 4 December. JSR 3, Java Management Extensions Specification, published a Maintenance Review.  This review closes 4 December. JSR 206, Java API for XML Processing,  published a Maintenance Review.  This review closes 22 November. Two other JSRs also published recent updates:  JSR 354, Money and Currency API, published a Public Review.  This review closes 23 November.  JSR 107, JCACHE - Java Temporary Caching API, published a Proposed Final Draft.

    Read the article

  • Java EE 7 JSR Submitted

    - by Tori Wieldt
    Java EE 7 has been filed as JSR 342 in the JCP program. This JSR (Java Specification Request) will develop Java EE 7, the next version of the Java Platform, Enterprise Edition. It is an "umbrella JSR" because the specification includes a collection of several other JSRs. The proposal suggests the addition of two new JSRs: Concurrency Utilities for Java EE (JSR-236) and JCache (JSR-107) as well as updates to JPA, JAX-RS, JSF, Servlets, EJB, JSP, EL, JMS, JAX-WS, CDI, Bean Validation, JSR-330, JSR-250, and Java Connector Architecture. There are also two new APIs under discussion: a Java Web Sockets API and a Java JSON API. These are the new JSRs that are currently up for ballot:• JSR 342: Java Platform, Enterprise Edition 7 Specification• JSR 340: Java Servlet 3.1 Specification• JSR 341: Expression Language 3.0• JSR 343: Java Message Service 2.0• JSR 344: JavaServer Faces 2.2All 5 JSRs are now up for Executive Committee voting with ballots closing on 14 March, and slated for inclusion in Java EE  7.  All of these JSRs are also open for Expert Group nominations. Any JCP member can nominate themself to serve on the Expert Groups for these JSRs. Details on how to become a JCP member are on jcp.org. The JCP gives you a chance to have your own work become an official component of the Java platform and to offer suggestions for improving and growing the technology. Either way, everyone in the Java community benefits from your participation.There's a nice discussion about Java EE 7 in this podcast with Java EE spec lead Robert Chinnici and more information in this blog post on the Aquarium. It's exciting to see so much activity currently underway.

    Read the article

  • JSR 348, 355, and 358: Moving JCP Forward

    - by arungupta
    The three-step JCP evolution consists of the following JSRs: • JSR 348, JCP transparency • JSR 355, Merging the two existing Executive Committees • JSR 358, complex issues moved postponed from JSR 348 The JSR 348 is already completed and JSR 355 is scheduled to be complete later this year. JSR 358 was recently filed and plans to revise several items such as modify the JSPA, Process Document, and a large number of complex issues. Because of the nature and scope of work, the Expert Group consists of representatives from all companies in the Executive Committee. Following the process set by JSR 348, all the work is done in open at jsr358.java.net. All the email discussions are here and JIRA here. Read Patrick Curran's blog for more details as well. The JSR review ballot ends on Jul 9th however the work has already happening for the past few months. Now is your chance to contribute and make JCP more effective!

    Read the article

  • Java EE 7 JSR update

    - by Heather VanCura
    Java EE 7 JSR update...in case you missed the last few entries with JSR updates, there are 8 Java EE 7 JSRs currently in JCP milestone review stages.  Your input is requested and needed! JSR 342: Early Draft Review 2– Java Platform, Enterprise Edition 7 (Java EE 7) Specification (review ends 30 November); Oracle JSR 107: Early Draft Review - JCACHE - Java Temporary Caching API (review ends 22 November); Greg Luck, Oracle JSR 236: Early Draft Review – Concurrency Utilities for Java EE (review ends 15 December); Oracle JSR 338: Early Draft Review 2 – Java Persistence 2 (review ends 30 November); Oracle JSR 346: Public Review – Contexts and Dependency Injection for Java EE 1.1 (EC ballot 4-17 December); RedHat JSR 352: Public Review – Batch Applications for the Java Platform (EC ballot 4-17 December); IBM JSR 349: Public Review – Bean Validation 1.1 (EC ballot 20- 26 November); RedHat JSR 339: Public Review – JAX-RS 2.0: The Java API for RESTful Web Services (Review period ended, EC ballot ends 26 November); Oracle  Also, check out the Java EE wiki with a specification and schedule update, including most recently, the addition of JSR 236.

    Read the article

  • JSR updates - October 2013

    - by Heather VanCura
    A handful of JSRs have been making  progress in the JCP program--Java SE, Java ME and Java EE JSRs.  More to come in the next few weeks! Highlights and links to JSR material below. JSR 337,  Java SE 8 Release Contents, published an Early Draft Review. JSR 351, Java Identity API, published an Early Draft Review. JSR 360, Connected Limited Device Configuration (CLDC) 8, passed the EC Public Review Ballot with 21 yes votes. JSR 361, Java ME Embedded Profile, passed the EC Public Review Ballot with 20 yes votes. JSR 107, JCACHE-Java Temporary Caching API, published an update to their JSR Community Update Page.  You can find schedule information (plans to submit Proposed Final Draft very soon), Adopt-a-JSR suggestions, and presentation material from JavaOne.

    Read the article

  • JSR Updates

    - by heathervc
    JSR 359, SIP Servlet 2.0, is a new JSR that has been submitted for JSR Review.  The review closes 16 July; the JSR Approval Ballot will be 17-20 July 2012. JSR 355, JCP Executive Committee Merge, has passed the Public Review Ballot and a Proposed Final Draft is now available for review. JSR 340, Java Servlet 3.1 Specification, has posted an Early Draft Review.  The review closes 1 August 2012.

    Read the article

  • Third JCP.Next JSR Submitted

    - by heathervc
    JSR 358, A major revision of the Java Community Process was submitted for JSR Review on Thursday.  This JSR will modify the JSPA as well as the Process Document, and will tackle a large number of complex issues, many of them postponed from JSR 348. For these reasons, the JCP EC (acting as the Expert Group for this JSR), expects to spend a considerable amount of time working on it - at least a year, and probably more.  Read more from the Spec Lead, Patrick Curran, in his latest blog post for more details.

    Read the article

  • Force close while calling mainactivity from widget (android)

    - by Shaji Thorn Blue
    Iam creating a simple widget, by this widget i want to open my mainactivity. Iam sending a unique key from my widget class to check whether my mainactivity is called via widget or not. But as soon as i clicked on my widget my mainactivity get force close. here is code of my widget class... @Override public void onUpdate(Context context, AppWidgetManager appWidgetManager, int[] widgets) { // TODO Auto-generated method stub int numofWidgets = widgets.length; for(int i=0;i<numofWidgets;i++){ int widget = widgets[i]; Intent in = new Intent(context, EmergencyButton.class); in.putExtra("uniquevalue", "widget"); PendingIntent pendingintent = PendingIntent.getActivity(context, 0, in, 0); RemoteViews views = new RemoteViews(context.getPackageName(), R.layout.widgetlayout); views.setOnClickPendingIntent(R.id.button, pendingintent); appWidgetManager.updateAppWidget(widget, views); } } And Here is my code of mainactivity where iam checking whether called came from widget or not @Override protected void onCreate(Bundle savedInstanceState) { // TODO Auto-generated method stub super.onCreate(savedInstanceState); setContentView(R.layout.mainactivity); Intent intentwidget = this.getIntent(); if(intentwidget !=null) { String widgetdata = "nothing"; widgetdata = intentwidget.getExtras().getString("uniquevalue"); if(widgetdata.equals("widget")) { et1.setText(widgetdata); } } } And here is my logcat 11-04 14:57:14.361: E/AndroidRuntime(1701): FATAL EXCEPTION: main 11-04 14:57:14.361: E/AndroidRuntime(1701): java.lang.RuntimeException: Unable to start activityComponentInfo{com.appsionlabs.googlemapv2/com.appsionlabs.googlemapv2.EmergencyButton}: java.lang.NullPointerException 11-04 14:57:14.361: E/AndroidRuntime(1701): at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:1647) 11-04 14:57:14.361: E/AndroidRuntime(1701): at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:1663) 11-04 14:57:14.361: E/AndroidRuntime(1701): at android.app.ActivityThread.access$1500(ActivityThread.java:117) 11-04 14:57:14.361: E/AndroidRuntime(1701): at android.app.ActivityThread$H.handleMessage(ActivityThread.java:931) 11-04 14:57:14.361: E/AndroidRuntime(1701): at android.os.Handler.dispatchMessage(Handler.java:99) 11-04 14:57:14.361: E/AndroidRuntime(1701): at android.os.Looper.loop(Looper.java:123) 11-04 14:57:14.361: E/AndroidRuntime(1701): at android.app.ActivityThread.main(ActivityThread.java:3683) 11-04 14:57:14.361: E/AndroidRuntime(1701): at java.lang.reflect.Method.invokeNative(Native Method) 11-04 14:57:14.361: E/AndroidRuntime(1701): at java.lang.reflect.Method.invoke(Method.java:507) 11-04 14:57:14.361: E/AndroidRuntime(1701): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:839) 11-04 14:57:14.361: E/AndroidRuntime(1701): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:597) 11-04 14:57:14.361: E/AndroidRuntime(1701): at dalvik.system.NativeStart.main(Native Method) 11-04 14:57:14.361: E/AndroidRuntime(1701): Caused by: java.lang.NullPointerException 11-04 14:57:14.361: E/AndroidRuntime(1701): at com.appsionlabs.googlemapv2.EmergencyButton.onCreate(EmergencyButton.java:29) 11-04 14:57:14.361: E/AndroidRuntime(1701): at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1047) 11-04 14:57:14.361: E/AndroidRuntime(1701): at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:1611)

    Read the article

  • Pivotal Announces JSR-352 Compliance for Spring Batch

    - by reza_rahman
    Pivotal, the company currently funding development of the popular Spring Framework, recently announced JSR 352 (aka Batch Applications for the Java Platform) compliance for the Spring Batch project. More specifically, Spring Batch targets JSR-352 Java SE runtime compatibility rather than Java EE runtime compatibility. If you are surprised that APIs included in Java EE can pass TCKs targeted for Java SE, you should not be. Many other Java EE APIs target compatibility in Java SE environments such as JMS and JPA. You can read about Spring Batch's support for JSR-352 here as well as the Spring configuration to get JSR-352 working in Spring (typically a very low level implementation concern intended to be completely transparent to most JSR-352 users). JSR 352 is one of the few very encouraging cases of major active contribution to the Java EE standard from the Spring development team (the other major effort being Rod Johnson's co-leadership of JSR 330 along with Bob Lee). While IBM's Christopher Vignola led the spec and contributed IBM's years of highly mission critical batch processing experience from products like WebSphere Compute Grid and z/OS batch, the Spring team provided major influences to the API in particular for the chunk processing, listeners, splits and operational interfaces. The GlassFish team's own Mahesh Kannan also contributed, in particular by implementing much of the Java EE integration work for the reference implementation. This was an excellent example of multilateral engineering collaboration through the standards process. For many complex reasons it is not too hard to find evidence of less than amicable interaction between the Spring ecosystem and the Java EE standard over the years if one cares to dig deep enough. In reality most developers see Spring and Java EE as two sides of the same server-side Java coin. At the core Spring and Java EE ecosystems have always shared deep undercurrents of common user bases, bi-directional flows of ideas and perhaps genuine if not begrudging mutual respect. We can all hope for continued strength for both ecosystems and graceful high notes of collaboration via efforts like JSR 352.

    Read the article

  • JSR updates

    - by heathervc
    There were many JSR updates over the last week.  See below. JSR 258, Mobile User Interface Customization API, has published a Maintenance Release. JSR 257, Contactless Communication API, has published a Maintenance Release 2. JSR 180, SIP API for J2ME, has published a Final Release 5. JSR 269, Pluggable Annotation Processing API, has published a Maintenance Release. JSR 344, JavaServerTM Faces 2.2, has published an Early Draft Review.  The review closes on 8 December.

    Read the article

  • JCP.Next - Early Adopters of JCP 2.8

    - by Heather VanCura
    JCP.Next is a series of three JSRs (JSR 348, JSR 355 and JSR 358), to be defined through the JCP process itself, with the JCP Executive Committee serving as the Expert Group. The proposed JSRs will modify the JCP's processes  - the Process Document and Java Specification Participation Agreement (JSPA) and will apply to all new JSRs for all Java platforms.   The first - JCP.next.1, or more formally JSR 348, Towards a new version of the Java Community Process - was completed and put into effect in October 2011 as JCP 2.8. This focused on a small number of simple but important changes to make our process more transparent and to enable broader participation. We're already seeing the benefits of these changes as new and existing JSRs adopt the new requirements. The second - JSR 355, Executive Committee Merge, is also Final. You can read the JCP 2.9 Process Document .  As part of the JSR 355 Final Release, the JCP Executive Committee published revisions to the JCP Process Document (version 2.9) and the EC Standing Rules (version 2.2).  The changes went into effect following the 2012 EC Elections in November. The third JSR 358, A major revision of the Java Community Process was submitted in June 2012.  This JSR will modify the Java Specification Participation Agreement (JSPA) as well as the Process Document, and will tackle a large number of complex issues, many of them postponed from JSR 348. For these reasons, the JCP EC (acting as the Expert Group for this JSR), expects to spend a considerable amount of time working on. The JSPA is defined by the JCP as "a one-year, renewable agreement between the Member and Oracle. The success of the Java community depends upon an open and transparent JCP program.  JSR 358, A major revision of the Java Community Process, is now in process and can be followed on java.net. The following JSRs and Spec Leads were the early adopters of JCP 2.8, who voluntarily migrated their JSRs from JCP 2.x to JCP 2.8 or above.  More candidates for 2012 JCP Star Spec Leads! JSR 236, Concurrency Utilities for Java EE (Anthony Lai/Oracle), migrated April 2012 JSR 308, Annotations on Java Types (Michael Ernst, Alex Buckley/Oracle), migrated September 2012 JSR 335, Lambda Expressions for the Java Programming Language (Brian Goetz/Oracle), migrated October 2012 JSR 337, Java SE 8 Release Contents (Mark Reinhold/Oracle) – EG Formation, migrated September 2012 JSR 338, Java Persistence 2.1 (Linda DeMichiel/Oracle), migrated January 2012 JSR 339, JAX-RS 2.0: The Java API for RESTful Web Services (Santiago Pericas-Geertsen, Marek Potociar/Oracle), migrated July 2012 JSR 340, Java Servlet 3.1 Specification (Shing Wai Chan, Rajiv Mordani/Oracle), migrated August 2012 JSR 341, Expression Language 3.0 (Kin-man Chung/Oracle), migrated August 2012 JSR 343, Java Message Service 2.0 (Nigel Deakin/Oracle), migrated March 2012 JSR 344, JavaServer Faces 2.2 (Ed Burns/Oracle), migrated September 2012 JSR 345, Enterprise JavaBeans 3.2 (Marina Vatkina/Oracle), migrated February 2012 JSR 346, Contexts and Dependency Injection for Java EE 1.1 (Pete Muir/RedHat) – migrated December 2011

    Read the article

  • JSR Updates and Inactive JSRs

    - by heathervc
     The following JSRs have made progress in the JCP program this week: JSR 342, Java Platform, Enterprise Edition 7 (Java EE 7) Specification, has posted an Early Draft 2 Review.  This review closes 30 November. JSR 338, Java Persistence 2.1, has posted an Early Draft 2 Review.  This review closes 30 November.  JSR 346, Contexts and Dependency Injection for Java, EE 1.1, has posted a Public Review.  This review closes 3 December.  JSR 352, Batch Applications for the Java Platform, has posted a Public Review.  This review closes 3 December. Inactive JSRs: In 2008, we initiated an effort to identify JSRs that had not continued to make progress in the JCP program.  We have reported on this topic since that time at JCP Executive Committee Meetings. The term 'Inactive JSRs' was introduced, and a process was developed with the guidance of the EC to reduce the number of Inactive JSRs  (reduced from over 60 to 2 JSRs) through either moving to the next JSR stage or being Withdrawn or declared Dormant.  This process has been formalized in JCP 2.8 and above, with the introduction of JSR deadlines.  The JSRs which were put to a Dormancy Ballot in September 2012  have been approved by the EC and are now declared Dormant.  You can view the results of the JSR Voting on JCP.org.  The latest Inactive JSRs report is available as part of the September 2012 JCP EC Face-to-Face Meeting Materials. 

    Read the article

  • JSR Updates - Multiple JSRs migrate to latest JCP version

    - by Heather VanCura
    As part of the JCP.Next reform effort, many JSRs have migrated to the latest version of the JCP program in the last month.  These JSRs' Spec Leads and Expert Groups are contributing to the strides the JCP has been making to enable greater community transparency, participation and agility to the working of the JSR development through the JCP program. Any other JSR Spec Leads interested in migrating to the latest JCP version, now JCP 2.9, as of 13 November, incorporating the Merged Executive Committee (EC), see the Spec Lead Guide for instructions on migrating to the latest JCP version.  For JCP 2.8 JSRs, you are effectively already operating under JCP 2.9 since there are no longer two ECs.  This is the difference for JCP 2.8 JSRs migrating to JCP 2.9 -- a merged EC.  To make the migration official, just inform your Expert Group on a public channel and email your request to admin at jcp.org. JSR 310, Date and Time API, led by Stephen Colebourne and Michael Nascimento and Oracle (Roger Riggs)  JSR 349, Bean Valirdation 1.1, led by RedHat (Emmanuel Bernard) JSR 350, Java State Management, led by Oracle (Mitch Upton) JSR 339, JAX-RS 2.0: The Java API for RESTful Web Services, led by Oracle, (Santiago Pericas-Geertsen and Marek Potociar) JSR 347, Data Grids for the Java Platform, led by RedHat (Manik Surtani)

    Read the article

  • JSR Updates and EC Meeting Tuesday @ 15:00 PST

    - by Heather VanCura
    JSR 310, Date and Time API, has moved to JCP 2.9 (first JCP 2.9 JSR!) JSR 236, Concurrency Utilities for Java EE, has published an Early Draft Review. This review ends 15 December 2012.  Tomorrow, Tuesday 20 November is the last Public EC Meeting of 2012, and the first EC meeting with the merged EC. The second hour of this meeting will be open to the public at 3:00 PM PST. The agenda includes  JSR 355,  EC merge implementation report, JSR 358 (JCP.next.3) status report, JCP 2.8 status update and community audit program.  Details are below. We hope you will join us, but if you cannot attend, not to worry--the recording and materials will also be public on the JCP.org multimedia page. Meeting details Date & Time Tuesday November 20, 2012, 3:00 - 4:00 pm PST Location Teleconference Dial-in +1 (866) 682-4770 (US) Conference code: 627-9803 Security code: 52732 ("JCPEC" on your phone handset) For global access numbers see http://www.intercall.com/oracle/access_numbers.htm Or +1 (408) 774-4073 WebEx Browse for the meeting from https://jcp.webex.com No registration required (enter your name and email address) Password: JCPEC Agenda JSR 355 (the EC merge) implementation report JSR 358 (JCP.next.3) status report 2.8 status update and community audit program Discussion/Q&A Note The call will be recorded and the recording published on jcp.org, so those who are unable to join in real-time will still be able to participate.

    Read the article

  • JSR Updates

    - by heathervc
    JSR 349, Bean Validation 1.1, has published a Public Review. The review closes on 12 November. JSR 331, Constraint Programming API, has published a Maintenance Release. JSR 335, Lambda Expressions for the Java Programming Language, has moved to JCP 2.8!  Check out their java.net project. JSR 107, JCACHE - Java Temporary Caching API, has posted their Early Draft Release.  The review closes on 22 November.

    Read the article

  • Adopt-a-JSR for Java EE 7 - Getting Started

    - by arungupta
    Adopt-a-JSR is an initiative started by JUG leaders to encourage JUG members to get involved in a JSR, in order to increase grass roots participation. This allows JUG members to provide early feedback to specifications before they are finalized in the JCP. The standards in turn become more complete and developer-friendly after getting feedback from a wide variety of audience. adoptajsr.org provide more details about the logistics and benefits for you and your JUG. A similar activity was conducted for OpenJDK as well. Markus Eisele also provide a great introduction to the program (in German). Java EE 7 (JSR 342) is scheduled to go final in Q2 2013. There are several new JSRs that are getting included in the platform (e.g. WebSocket, JSON, and Batch), a few existing ones are getting an overhaul (e.g. JAX-RS 2 and JMS 2), and several other getting minor updates (e.g. JPA 2.1 and Servlets 3.1). Each Java EE 7 JSR can leverage your expertise and would love your JUG to adopt a JSR. What does it mean to adopt a JSR ? Your JUG is going to identify a particular JSR, or multiple JSRs, that is of interest to the JUG members. This is mostly done by polling/discussing on your local JUG members list. Your JUG will download and review the specification(s) and javadocs for clarity and completeness. The complete set of Java EE 7 specifications, their download links, and EG archives are listed here. glassfish.org/adoptajsr provide specific areas where different specification leads are looking for feedback. Your JUG can then think of a sample application that can be built using the chosen specification(s). An existing use case (from work or a personal hobby project) may be chosen to be implemented instead. This is where your creativity and uniqueness comes into play. Most of the implementations are already integrated in GlassFish 4 and others will be integrated soon. You can also explore integration of multiple technologies and provide feedback on the simplicity and ease-of-use of the programming model. Especially look for integration with existing Java EE technologies and see if you find any discrepancies. Report any missing features that may be included in future release of the specification. The most important part is to provide feedback by filing bugs on the corresponding spec or RI project. Any thing that is not clear either in the spec or implementation should be filed as a bug. This is what will ensure that specification and implementation leads are getting the required feedback and improving the quality of the final deliverable of the JSR. How do I get started ? A simple way to get started can be achieved by following S.M.A.R.T. as explained below. Specific Identify who all will be involved ? What would you like to accomplish ? For example, even though building a sample app will provide real-world validity of the API but because of time constraints you may identify that reviewing the specification and javadocs only can be accomplished. Establish a time frame by which the activities need to be complete. Measurable Define a success for metrics. For example, this could be the number of bugs filed. Remember, quality of bugs is more important that quantity of bugs. Define your end goal, for example, reviewing 4 chapters of the specification or completing the sample application. Create a dashboard that will highlight your JUG's contribution to this effort. Attainable Make sure JUG members understand the time commitment required for providing feedback. This can vary based upon the level of involvement (any is good!) and the number of specifications picked. adoptajsr.org defines different categories of involvement. Once again, any level of involvement is good. Just reviewing a chapter, a section, or javadocs for your usecase is helpful. Relevant Pick JSRs that JUG members are willing and able to work. If the JUG members are not interested then they might loose motivation half-way through. The "able" part is tricky as you can always stretch yourself and learn a new skill ;-) Time-bound Define a time table of activities with clearly defined tasks. A tentative time table may look like: Dec 25: Discuss and agree upon the specifications with JUG Jan 1: Start Adopt-a-JSR for Java EE 7 Jan 15: Initial spec reading complete. Keep thinking through the application that will be implemented. Jan 22: Early design of the sample application is ready Jan 29: JUG members agree upon the application Next 4 weeks: Implement the application Of course, you'll need to alter this based upon your commitment. Maintaining an activity dashboard will help you monitor and track the progress. Make sure to keep filing bugs through out the process! 12 JUGs from around the world (SouJava, Campinas JUG, Chennai JUG, London Java Community, BeJUG, Morocco JUG, Peru JUG, Indonesia JUG, Congo JUG, Silicon Valley JUG, Madrid JUG, and Houston JUG) have already adopted one of the Java EE 7 JSRs. I'm already helping some JUGs bootstrap and would love to help your JUG too. What are you waiting for ?

    Read the article

  • Concurrency Utilities for Java EE 6: JSR 236 Rebooting

    - by arungupta
    JSR 166 added support for concurrency utilities in the Java platform. The JSR 236's, a.k.a Concurrency Utilities for Java EE, goal was to extend that support to the Java EE platform by adding asynchronous abilities to different application components. The EG was however stagnant since Dec 2003. Its coming back to life with the co-spec lead Anthony Lai's message to the JSR 236 EG (archived here). The JSR will be operating under JCP 2.8's transparency rules and can be tracked at concurrency-spec.java.net. All the mailing lists are archived here. The final release is expected in Q1 2013 and the APIs will live in the javax.enterprise.concurrent package. Please submit your nomination if you would like to join this EG.

    Read the article

  • Social Media JSR 357 NOT approved by Executive Committee

    - by alexismp
    JSR 357 (Social Media API) has not passed the initial ballot which means, according to the JCP rules, that "the JSR submitter(s) who may revise the JSR and resubmit it within 14 days". Given the comments associated with the negative votes, it may be challenging for the submitters to address the concerns about the scope assessed by many as being too wide. Standardization is a difficult task and the JCP (the Executive Committee in fact) played its role by pointing out the challenges ahead of such a JSR as it was envisioned by its submitters, and thus the risk of never completing. If anything this proves that the JCP is working as expected. For those disappointed that Java will not get a standard "Social Media API" (for now at least), let me remind you of the recent open-sourcing of DaliCore.

    Read the article

  • JSR Updates and EC Nominations open

    - by heathervc
    JSR 310, Date and Time API, has published an Early Draft Review 2.  This review closes 14 October. JSR 353, Java API for JSON Processing, has published an Early Draft Review.  This review closes 7 October. JSR 356, Java API for WebSocket, has published an Early Draft Review. This review closes 27 October. JSR 339,  JAX-RS 2.0: The Java API for RESTful Web Services, has published a Public Review. This review closes 12 November. The EC Nominations are now open until 11 October.  Any JCP Member may nominate themselves for the 2 open seats in the 2012 EC Elections.  Note that both seats will be for a 1 year term only, since all EC Members will stand for Election in 2013.  The merged EC will take effect in November 2012.

    Read the article

  • A Look Inside JSR 360 - CLDC 8

    - by Roger Brinkley
    If you didn't notice during JavaOne the Java Micro Edition took a major step forward in its consolidation with Java Standard Edition when JSR 360 was proposed to the JCP community. Over the last couple of years there has been a focus to move Java ME back in line with it's big brother Java SE. We see evidence of this in JCP itself which just recently merged the ME and SE/EE Executive Committees into a single Java Executive Committee. But just before that occurred JSR 360 was proposed and approved for development on October 29. So let's take a look at what changes are now being proposed. In a way JSR 360 is returning back to the original roots of Java ME when it was first introduced. It was indeed a subset of the JDK 4 language, but as Java progressed many of the language changes were not implemented in the Java ME. Back then the tradeoff was still a functionality, footprint trade off but the major market was feature phones. Today the market has changed and CLDC, while it will still target feature phones, will have it primary emphasis on embedded devices like wireless modules, smart meters, health care monitoring and other M2M devices. The major changes will come in three areas: language feature changes, library changes, and consolidating the Generic Connection Framework.  There have been three Java SE versions that have been implemented since JavaME was first developed so the language feature changes can be divided into changes that came in JDK 5 and those in JDK 7, which mostly consist of the project Coin changes. There were no language changes in JDK 6 but the changes from JDK 5 are: Assertions - Assertions enable you to test your assumptions about your program. For example, if you write a method that calculates the speed of a particle, you might assert that the calculated speed is less than the speed of light. In the example code below if the interval isn't between 0 and and 1,00 the an error of "Invalid value?" would be thrown. private void setInterval(int interval) { assert interval > 0 && interval <= 1000 : "Invalid value?" } Generics - Generics add stability to your code by making more of your bugs detectable at compile time. Code that uses generics has many benefits over non-generic code with: Stronger type checks at compile time. Elimination of casts. Enabling programming to implement generic algorithms. Enhanced for Loop - the enhanced for loop allows you to iterate through a collection without having to create an Iterator or without having to calculate beginning and end conditions for a counter variable. The enhanced for loop is the easiest of the new features to immediately incorporate in your code. In this tip you will see how the enhanced for loop replaces more traditional ways of sequentially accessing elements in a collection. void processList(Vector<string> list) { for (String item : list) { ... Autoboxing/Unboxing - This facility eliminates the drudgery of manual conversion between primitive types, such as int and wrapper types, such as Integer.  Hashtable<Integer, string=""> data = new Hashtable<>(); void add(int id, String value) { data.put(id, value); } Enumeration - Prior to JDK 5 enumerations were not typesafe, had no namespace, were brittle because they were compile time constants, and provided no informative print values. JDK 5 added support for enumerated types as a full-fledged class (dubbed an enum type). In addition to solving all the problems mentioned above, it allows you to add arbitrary methods and fields to an enum type, to implement arbitrary interfaces, and more. Enum types provide high-quality implementations of all the Object methods. They are Comparable and Serializable, and the serial form is designed to withstand arbitrary changes in the enum type. enum Season {WINTER, SPRING, SUMMER, FALL}; } private Season season; void setSeason(Season newSeason) { season = newSeason; } Varargs - Varargs eliminates the need for manually boxing up argument lists into an array when invoking methods that accept variable-length argument lists. The three periods after the final parameter's type indicate that the final argument may be passed as an array or as a sequence of arguments. Varargs can be used only in the final argument position. void warning(String format, String... parameters) { .. for(String p : parameters) { ...process(p);... } ... } Static Imports -The static import construct allows unqualified access to static members without inheriting from the type containing the static members. Instead, the program imports the members either individually or en masse. Once the static members have been imported, they may be used without qualification. The static import declaration is analogous to the normal import declaration. Where the normal import declaration imports classes from packages, allowing them to be used without package qualification, the static import declaration imports static members from classes, allowing them to be used without class qualification. import static data.Constants.RATIO; ... double r = Math.cos(RATIO * theta); Annotations - Annotations provide data about a program that is not part of the program itself. They have no direct effect on the operation of the code they annotate. There are a number of uses for annotations including information for the compiler, compiler-time and deployment-time processing, and run-time processing. They can be applied to a program's declarations of classes, fields, methods, and other program elements. @Deprecated public void clear(); The language changes from JDK 7 are little more familiar as they are mostly the changes from Project Coin: String in switch - Hey it only took us 18 years but the String class can be used in the expression of a switch statement. Fortunately for us it won't take that long for JavaME to adopt it. switch (arg) { case "-data": ... case "-out": ... Binary integral literals and underscores in numeric literals - Largely for readability, the integral types (byte, short, int, and long) can also be expressed using the binary number system. and any number of underscore characters (_) can appear anywhere between digits in a numerical literal. byte flags = 0b01001111; long mask = 0xfff0_ff08_4fff_0fffl; Multi-catch and more precise rethrow - A single catch block can handle more than one type of exception. In addition, the compiler performs more precise analysis of rethrown exceptions than earlier releases of Java SE. This enables you to specify more specific exception types in the throws clause of a method declaration. catch (IOException | InterruptedException ex) { logger.log(ex); throw ex; } Type Inference for Generic Instance Creation - Otherwise known as the diamond operator, the type arguments required to invoke the constructor of a generic class can be replaced with an empty set of type parameters (<>) as long as the compiler can infer the type arguments from the context.  map = new Hashtable<>(); Try-with-resource statement - The try-with-resources statement is a try statement that declares one or more resources. A resource is an object that must be closed after the program is finished with it. The try-with-resources statement ensures that each resource is closed at the end of the statement.  try (DataInputStream is = new DataInputStream(...)) { return is.readDouble(); } Simplified varargs method invocation - The Java compiler generates a warning at the declaration site of a varargs method or constructor with a non-reifiable varargs formal parameter. Java SE 7 introduced a compiler option -Xlint:varargs and the annotations @SafeVarargs and @SuppressWarnings({"unchecked", "varargs"}) to supress these warnings. On the library side there are new features that will be added to satisfy the language requirements above and some to improve the currently available set of APIs.  The library changes include: Collections update - New Collection, List, Set and Map, Iterable and Iteratator as well as implementations including Hashtable and Vector. Most of the work is too support generics String - New StringBuilder and CharSequence as well as a Stirng formatter. The javac compiler  now uses the the StringBuilder instead of String Buffer. Since StringBuilder is synchronized there is a performance increase which has necessitated the wahat String constructor works. Comparable interface - The comparable interface works with Collections, making it easier to reuse. Try with resources - Closeable and AutoCloseable Annotations - While support for Annotations is provided it will only be a compile time support. SuppressWarnings, Deprecated, Override NIO - There is a subset of NIO Buffer that have been in use on the of the graphics packages and needs to be pulled in and also support for NIO File IO subset. Platform extensibility via Service Providers (ServiceLoader) - ServiceLoader interface dos late bindings of interface to existing implementations. It helpe to package an interface and behavior of the implementation at a later point in time.Provider classes must have a zero-argument constructor so that they can be instantiated during loading. They are located and instantiated on demand and are identified via a provider-configuration file in the METAINF/services resource directory. This is a mechansim from Java SE. import com.XYZ.ServiceA; ServiceLoader<ServiceA> sl1= new ServiceLoader(ServiceA.class); Resources: META-INF/services/com.XYZ.ServiceA: ServiceAProvider1 ServiceAProvider2 ServiceAProvider3 META-INF/services/ServiceB: ServiceBProvider1 ServiceBProvider2 From JSR - I would rather use this list I think The Generic Connection Framework (GCF) was previously specified in a number of different JSRs including CLDC, MIDP, CDC 1.2, and JSR 197. JSR 360 represents a rare opportunity to consolidated and reintegrate parts that were duplicated in other specifications into a single specification, upgrade the APIs as well provide new functionality. The proposal is to specify a combined GCF specification that can be used with Java ME or Java SE and be backwards compatible with previous implementations. Because of size limitations as well as the complexity of the some features like InvokeDynamic and Unicode 6 will not be included. Additionally, any language or library changes in JDK 8 will be not be included. On the upside, with all the changes being made, backwards compatibility will still be maintained. JSR 360 is a major step forward for Java ME in terms of platform modernization, language alignment, and embedded support. If you're interested in following the progress of this JSR see the JSR's java.net project for details of the email lists, discussions groups.

    Read the article

1 2 3 4 5 6 7 8 9 10 11 12  | Next Page >