Eclipse IDE for Java

It’s time to change the specification names… When we first moved the APIs and TCKs for the Java EE specifications over to the Eclipse Foundation under the Jakarta EE banner, we kept the existing names for the specifications in place, and adopted ... [More] placeholder names for the open source projects that hold their artifacts. As we prepare to engage in actual specification work (involving an actual specification document), it’s time to start thinking about changing the names of the specifications and the projects that contain their artifacts. Why change? For starters, it’s just good form to leverage the Jakarta brand. But, more critically, many of the existing specification names use trademarked terms that make it either very challenging or impossible to use those names without violating trademark rules. Motivation for changing the names of the existing open source projects that we’ll turn into specification projects is, I think, a little easier: “Eclipse Project for …” is a terrible name. So, while the current names for our proto-specification projects have served us well to-date, it’s time to change them. To keep things simple, we recommend that we just use the name of the specification as the project name.  With this in mind, we’ve come up with a naming pattern that we believe can serve as a good starting point for discussion. To start with, in order to keep things as simple as possible, we’ll have the project use the same name as the specification (unless there is a compelling reason to do otherwise). The naming rules are relatively simple: Replace “Java” with “Jakarta” (e.g. “Java Message Service” becomes “Jakarta Message Service”); Add a space in cases where names are mashed together (e.g. “JavaMail” becomes “Jakarta Mail”); Add “Jakarta” when it is missing (e.g. “Expression Language” becomes “Jakarta Expression Language”); and Rework names to consistently start with “Jakarta” (“Enterprise JavaBeans” becomes “Jakarta Enterprise Beans”). This presents us with an opportunity to add even more consistency to the various specification names. Some, for example, are more wordy or descriptive than others; some include the term “API” in the name, and others don’t; etc. We’ll have to sort out what we’re going to do with the Eclipse Project for Stable Jakarta EE Specifications, which provides a home for a small handful of specifications which are not expected to change. I’ll personally be happy if we can at least drop the “Eclipse Project for” from the name (“Jakarta EE Stable”?). We’ll also have to sort out what we’re going to do about the Eclipse Mojarra and Eclipse Metro projects which hold the APIs for some specifications; we may end up having to create new specification projects as homes for development of the corresponding specification documents (regardless of how this ends up manifesting as a specification project, we’re still going to need specification names). Based on all of the above, here is my suggested starting point for specification (and most project) names (I’ve applied the rules described above; and have suggested tweaks for consistency by strike out): Jakarta APIs for XML Messaging Jakarta Architecture for XML Binding Jakarta API for XML-based Web Services Jakarta Common Annotations Jakarta Enterprise Beans Jakarta Persistence API Jakarta Contexts and Dependency Injection Jakarta EE Platform Jakarta API for JSON Binding Jakarta Servlet Jakarta API for RESTful Web Services Jakarta Server Faces Jakarta API for JSON Processing Jakarta EE Security API Jakarta Bean Validation Jakarta Mail Jakarta Beans Activation Framework Jakarta Debugging Support for Other Languages Jakarta Server Pages Standard Tag Library Jakarta EE Platform Management Jakarta EE Platform Application Deployment Jakarta API for XML Registries Jakarta API for XML-based RPC Jakarta Enterprise Web Services Jakarta Authorization Contract for Containers Jakarta Web Services Metadata Jakarta Authentication Service Provider Interface for Containers Jakarta Concurrency Utlities Jakarta Server Pages Jakarta Connector Architecture Jakarta Dependency Injection Jakarta Expression Language Jakarta Message Service Jakarta Batch Jakarta API for WebSocket Jakarta Transaction API We’re going to couple renaming with an effort to capture proper scope statements (I’ll cover this in my next post). The Eclipse EE4J PMC Lead, Ivar Grimstad, has blogged about this recently and has created a project board to track the specification and project renaming activity (as of this writing, it has only just been started, so watch that space). We’ll start reaching out to the “Eclipse Project for …”  teams shortly to start engaging this process. When we’ve collected all of the information (names and scopes), we’ll engage in a restructuring review per the Eclipse Development Process (EDP) and make it all happen (more on this later). Your input is requested. I’ll monitor comments on this post, but it would be better to collect your thoughts in the issues listed on the project board (after we’ve taken the step to create them, of course), on the related issue, or on the EE4J PMC’s mailing list.   [Less]

There is a new release (2.9.0) of the ECF distribution provider for OSGi R7 Remote Services between Java and Python.This release has:An upgraded version of Py4jAn upgraded version of Google Protocol BuffersEnhancements to the distribution provider ... [More] based upon the improved Py4j and Protobuf libsIn this previous blog posting there are links to tutorials and examples showing how to use remote services between Python<->Java.Python<->Java remote services can be consumed or implemented in either Java or Python. [Less]

Technical Work We will need a lot of help on this front as well o   Jakarta EE specifications: specification documents and APIs We have heard from members of the community some suggestions on what they need from the specification, but we can ... [More] always use more. Get involved in the discussion on Github (https://github.com/eclipse-ee4j/jakartaee-platform/issues). o   Jakarta EE TCK It’s a goliath, inconvenient, and we want to slowly begin to break it up into separate TCKs for each specification. Not for the very first release of Jakarta EE, but we need to start planning and discussing the approach. o   Compatible Implementations To make a final version of a specification alive we need specification implementations. Whether the implementation is hosted in Eclipse Foundation or not is not the focus, we need you to implement the specification.     Collateral material related work While we encourage everyone to participate in specification development, please keep in mind this isn’t limited to coding only. Of equal importance is the need for collateral material related to the specification(s). This includes documentation, presentations, videos, demos, examples, blogs, tech talks, etc. This is the type of content we can circulate through the community and use to educate and spread the news on the new specifications. Presenting the material on the conferences is yet another aspect where you can help out also! Tags:  #JakartaEE #JavaEE #CommunityWork #Java [Less]

We are extremely pleased to announce that the Eclipse Vert.x version 3.7.0 has been released. It is an exciting milestone for a couple of reasons: it comes with great new features like the GraphQL extension for Vert.x Web. this is the last minor ... [More] version before Vert.x 4! Before we go throught the most notable new features, we would like to thank all the contributors. Your participation has been essential to this achievement. Vert.x Web GraphQL Vert.x Web GraphQL extends Vert.x Web with the GraphQL-Java library so that you can build a GraphQL server. To use this new module, add the following to the dependencies section of your Maven POM file: <dependency> <groupId>io.vertxgroupId> <artifactId>vertx-web-graphqlartifactId> <version>3.7.0version> dependency> Or, if you use Gradle: compile 'io.vertx:vertx-web-graphql:3.7.0' Then create a Vert.x Web Route and a GraphQLHandler for it: // Setup the GraphQL-Java object GraphQL graphQL = setupGraphQLJava(); // Use it to handle requests on a Vert.x Web route router.route("/graphql").handler(GraphQLHandler.create(graphQL)); The GraphQL handler supports out of the box: query context customization GraphQL-Java data loaders batching on POST requests (compatible with the apollo-link-batch-http transport) For detailed usage instructions, please refer to the Vert.x Web GraphQL documentation. Vert.x Cassandra Client Object mapper support Vert.x Cassandra Client now supports the cassandra-driver-mapping module. To enable this feature, you need to update your classpath by adding: <dependency> <groupId>com.datastax.cassandragroupId> <artifactId>cassandra-driver-mappingartifactId> <version>3.7.1version> dependency> Then for a given entity: @Table(keyspace = "test", name = "users") class User { @PartitionKey String name; // ... other fields and methods } You can retrieve a mapper and execute CRUD operations: VertxMappingManager manager = VertxMappingManager.create(cassandraClient); VertxMapper mapper = manager.mapper(User.class, vertx); mapper.save(new User("john", hander -> {})); Collector API The feature allows to use Java collectors for query results: // Create a collector projecting a row set to a string in the form (last_name_1,last_name_2,...) Collector collector = Collectors.mapping( row -> row.getString("last_name"), Collectors.joining(",", "(", ")") ); // Run the query with the collector client.execute("SELECT * FROM users", collector, ar -> { if (ar.succeeded()) { // Result in the form (last_name_1,last_name_2,...) String result = ar.result(); } else { System.out.println("Failure: " + ar.cause().getMessage()); } }); Cursor API The ResultSet object has been enhanced with ResultSet#several method, allowing you to obtain several rows at once: resultSet.several(30, ar -> { if (ar.succeeded()) { List result = ar.result(); } else { System.out.println("Failure: " + ar.cause().getMessage()); } }); A very useful feature for result batch iterations without resorting to streaming or fetching all rows in memory. Client lifecyle The client lifecyle has been revisited in 3.7. Previously users expected to connect manually before sending requests. It was also possible to disconnect a shared client thus failing requests sent from another verticle or part of the application. Now it is no longer required to manually connect a client (in fact, the method has been removed). As soon as you retrieve an instance you can start using it, the lifecyle is automatically managed: CassandraClientOptions options = new CassandraClientOptions() .addContactPoint("node1.address") .addContactPoint("node2.address") .addContactPoint("node3.address") .setKeyspace("my_keyspace"); CassandraClient sharedClient = CassandraClient.createShared(vertx, "sharedClientName", options); // Start sending requests to Cassandra with the client instance Similarly, when the new close method is invoked on a shared client, only the last active instance will actually disconnect from Cassandra: // Disconnects only if this is the last running instance of the shared client sharedClient.close(); Vert.x Redis Client The Vert.x Redis client has been reworked internally and provides now a new (more evolution friendly) API. The current API had the limitation of being manually crafted after the redis API and involved many non controlable features such as auto reconnect, unlimited buffering of requests, etc… The new API offers a more vert.x-y experience. It just exposes the base client: Redis .createClient(vertx, inetSocketAddress(7006, "127.0.0.1")) .connect(create -> { final Redis redis = create.result(); redis.send(Request.cmd(Command.PING), send -> { // ... should reply with PONG }); }); This has the benefits that you can now connect to Redis in any of it’s operation modes: Single server HA mode Cluster mode The API is decoupled from the handcrafted commands, which means that you can use new features such as: streams hyperloglog any extension module A generated helper RedisAPI is available that can wrap the client to provide a similar experience to the old API. The main difference is that this new wrapper is generated from the COMMAND command, so the correct API it always exposed: RedisAPI redis = RedisAPI.api(client); redis.set(Arrays.asList("key1", "value1"), set -> { // ... }); Vert.x AMQP Client The Vert.x AMQP client allows receiving and sending AMQP messages. It supersedes the current AMQP bridge and provide an API more flexible and very much user-friendly. The Vert.x AMQP client allows: Connecting to an AMQP broker or router - SASL and TLS connections are supported Consuming message from a queue or a topic Sending messages to a queue or a topic Checking acknowledgement for sent messages The AMQP 1.0 protocol support durable subscriptions, persistence, security, conversations, sophisticated routing… More details on the protocol can be found on the AMQP homepage. The Vert.x AMQP client is based on Vert.x Proton. If you need fine-grain control, we recommend using Vert.x Proton directly. To use this new module, add the following to the dependencies section of your Maven POM file: <dependency> <groupId>io.vertxgroupId> <artifactId>vertx-amqp-clientartifactId> <version>3.7.0version> dependency> Or, if you use Gradle: compile 'io.vertx:vertx-amqp-client:3.7.0' Then, you can connect to an AMQP broker: AmqpClientOptions options = new AmqpClientOptions() .setHost("localhost") .setPort(5672) .setUsername("user") .setPassword("secret"); AmqpClient client = AmqpClient.create(vertx, options); client.connect(ar -> { if (ar.failed()) { System.out.println("Unable to connect to the broker"); } else { System.out.println("Connection succeeded"); AmqpConnection connection = ar.result(); // You can create receivers and senders connection.createReceiver("my-queue", msg -> { // called on every received messages System.out.println("Received " + msg.bodyAsString()); }, done -> { if (done.failed()) { System.out.println("Unable to create receiver"); } else { AmqpReceiver receiver = done.result(); } } ); connection.createSender("my-queue", done -> { if (done.failed()) { System.out.println("Unable to create a sender"); } else { AmqpSender sender = done.result(); sender.send(AmqpMessage.create().withBody("hello").build()); } }); } }); Stream pipes When it comes to streaming, back-pressure is something you need to care about. You have very much likely heard or used the Vert.x Pump API to transfer data from a read stream to a write stream while respecting the write stream back-pressure. The Pipe a new API superseding the Pump to achieve the same effect and even more, it acts like a pump and handles for you read stream pause/resume write stream termination stream failures handling asynchronous result upon streaming completion You can transfer a read stream to a write stream simply, the write stream will be ended upon completion of the stream readStream.pipeTo(writeStream); You can also be notified when the pipe completes: readStream.pipeTo(writeStream, ar -> { if (ar.succeeded()) { System.out.println("done"); } else { System.out.println("failed " + ar.cause()); } }); Creating and using an asynchronous pipe is easy // The read stream will be paused until the pipe is used Pipe pipe = readStream.pipe(); getAsyncPipe(ar -> { if (ar.succeeded()) { pipe.to(writeStream); } else { pipe.close(); } }); Kafka admin client The new version brings a Vert.x based first implementation of the native Kafka Admin Client API which are in Java, instead of Scala used in the previous version. The AdminUtils is now deprecated and the new KafkaAdminClient is available instead. It allows to remove the last Scala artifact dependency. While the AdminUtils implementation needs to connect to Zookeeper for administration purposes, the KafkaAdminClient only uses the Kafka bootstrap brokers connection. Properties config = new Properties(); config.put(AdminClientConfig.BOOTSTRAP_SERVERS_CONFIG, "my-kafka-broker:9092"); KafkaAdminClient adminClient = KafkaAdminClient.create(vertx, config); The features currently supported are: create and delete topics list all the topics describe topics for getting information about leader partition, follower replicas and ISR (in-sync replicas) list alter topics configuration list all consumer groups describe consumer groups for getting information like the state, the coordinator host, consumers per topics and so on If you are using the AdminUtils today, consider migrate to the new KafkaAdminClient because the former will be removed in Vert.x 4.0. And more… Here are some other important improvements you can find in this release: Shared data structures available in local-only mode even when Vert.x is clustered JSON decoding without prior knowledge of the structure (object, array, string, …etc) Infinispan Cluster Manager upgraded to Infinispan 9.4.10.Final And obviously we have the usual bug fixes! Finally The 3.7.0 release notes can be found on the wiki, as well as the list of deprecations and breaking changes Docker images are available on Docker Hub. The Vert.x distribution can be downloaded on the website but is also available from SDKMan and HomeBrew. The event bus client using the SockJS bridge is available from: NPM Bower WebJars The release artifacts have been deployed to Maven Central and you can get the distribution on Bintray. That’s it! Happy coding and see you soon on our user or dev channels. [Less]

JBoss Tools 4.11.0 and Red Hat CodeReady Studio 12.11 for Eclipse 2019-03 are here waiting for you. Check it out! Installation Red Hat ... [More] CodeReady Studio comes with everything pre-bundled in its installer. Simply download it from our Red Hat CodeReady product page and run it like this: java -jar devstudio-.jar JBoss Tools or Bring-Your-Own-Eclipse (BYOE) CodeReady Studio require a bit more: This release requires at least Eclipse 4.11 (2019-03) but we recommend using the latest Eclipse 4.11 2019-03 JEE Bundle since then you get most of the dependencies preinstalled. Once you have installed Eclipse, you can either find us on the Eclipse Marketplace under "JBoss Tools" or "Red Hat CodeReady Studio". For JBoss Tools, you can also use our update site directly. http://download.jboss.org/jbosstools/photon/stable/updates/ What is new? Our main focus for this release was improvements for container based development and bug fixing. Eclipse 2019-03 itself has a lot of new cool stuff but let me highlight just a few updates in both Eclipse 2019-03 and JBoss Tools plugins that I think are worth mentioning. OpenShift 3 New OpenShift connection helper When you need to defined a new OpenShift connection, you need to provide the following information: cluster URL username and password or token If you’ve already logged in your cluster through the OpenShift Web Console, you can copy an oc command in the clipboard that contains both the cluster URL and your token. So, from now, there is a new option that allows you to initialize the wizard fields from the copied oc command: Click on the Paste Login Command button and the fields will be initialized: Server tools EAP 7.2 Server Adapter A server adapter has been added to work with EAP 7.2. Wildfly 15 Server Adapter A server adapter has been added to work with Wildfly 15. It adds support for Java EE 8. Related JIRA: JBIDE-26502 Wildfly 16 Server Adapter A server adapter has been added to work with Wildfly 16. It adds support for Java EE 8. Hibernate Tools New Runtime Provider The new Hibernate 5.4 runtime provider has been added. It incorporates Hibernate Core version 5.4.1.Final and Hibernate Tools version 5.4.1.Final Runtime Provider Updates The Hibernate 5.3 runtime provider now incorporates Hibernate Core version 5.3.9.Final and Hibernate Tools version 5.3.9.Final. The Hibernate 5.2 runtime provider now incorporates Hibernate Core version 5.2.18.Final and Hibernate Tools version 5.2.12.Final. Maven Maven support updated to M2E 1.11 The Maven support is based on Eclipse M2E 1.11 Platform Views, Dialogs and Toolbar User defined resource filters in Project Explorer The Filters and Customization…​ menu in Project Explorer now shows an additional User filters tab which can be used to exclude some resources from Project Explorer based on their name. Full name and regular expressions are supported. Error Log view added to Platform The Error Log view has been moved from the PDE project to the Platform project. See bug 50517 for details. Copy to clipboard in Installation Details A copy to clipboard action has been added to all tabs of the Installation Details dialog. Copy & paste of Environment Variables The Environment tab in a Launch configuration dialog supports copy & paste actions now. The environment variables are transferred as text data, so it is not only possible to copy & paste between two different launch configurations, but also between the launch configuration and e.g. some text editor or the command line. This feature is available in all launch configurations which use the common Environment tab. Useful links to add projects to empty workspace When Eclipse IDE is started for the first time or with a new workspace, it may not be intuitive for new users on how to proceed. To help the users in getting started, the following useful links have been provided to add a project to the workspace: Perspective specific project creation wizard Generic New Project wizard Import projects wizard New mnemonics in Error Log view New mnemonics have been added for Export Entry…​ and Event Detail entries in the context menu of Error Log view. Themes and Styling Improved Dark theme for Mac The Dark theme for Mac has been improved to use the colors from the macOS system dark appearance. Some of the notable changes in Eclipse IDE are the dark window title bar, menus, file dialogs, combos and buttons. Note: This change is available on macOS Mojave and later. Before: After: Improved Dark theme for Windows The drawing operations have been improved in Windows so the custom drawn icons look better now. For example, check the close icon below. Before: After: General Updates Performance improvements The startup and interactive performance of multiple operations has been improved again in this release. Java Developement Tools (JDT) Java 12 Support Java 12 Java 12 is out and Eclipse JDT supports Java 12 for 4.11 via Marketplace. The release notably includes the following Java 12 feature: JEP 325: Switch Expressions (Preview). Please note that this is a preview language feature and hence enable preview option should be on. For an informal introduction of the support, please refer to Java 12 Examples wiki. JUnit JUnit 5.4 JUnit 5.4 is here and Eclipse JDT has been updated to use this version. Test factory template JUnit Jupiter now allows test factory methods to return a single DynamicNode. The test_factory template has been updated to include DynamicNode in the return type. Java Editor Default and constant values in content assist information pop-up The additional information pop-up of a content assist proposal now shows the default value of an annotation type element: and the value of a constant: Create service provider method If a service defined in a module-info.java file has an invalid service provider implementation, a Quick Fix (Ctrl + 1) is now available to create the new provider method: Java Formatter Line wrapping settings for binary operators Instead of a single line wrapping setting for binary expressions, there’s now a whole section of settings for various kinds of binary operators (multiplicative, additive, logical, etc.). There are settings for relational (including equality) and shift operators, which were not covered by the old setting. Also, string concatenation can now be treated differently from arithmetic sum. The settings can be found in the Profile Editor (Preferences > Java > Code Style > Formatter > Edit…​) under the Line Wrapping > Wrapping settings > Binary expressions subsection. White space settings for binary operators The white space around operators in binary expressions can now be controlled separately for different groups of operators, consistent with the line wrapping settings. The new Binary operators sub-section has been added under White Space > Expressions in the Formatter profile editor. Wrapping setting for chained conditional expressions A chain of nested conditional expressions (using ternary operator) can be now wrapped as a single group, with all of them indented at the same level. It’s only possible for right-sided nesting. Find the Chained conditionals setting in the Profile Editor under the Line Wrapping > Wrapping settings > Other expressions subsection. Indent Javadoc tag descriptions The Formatter Profile has a new setting that indents wrapped Javadoc tag descriptions. It’s called Indent other tag descriptions when wrapped, in contrast to the preexisting Indent wrapped @param/@throws descriptions setting. It affects tags like @return or @deprecated. The settings can be found in the Profile Editor (Preferences > Java > Code Style > Formatter > Edit…​) under the Comments > Javadocs section. Debug History for expressions in the Variables view The Variables view now stores a history of the expressions used in the Detail pane. You can choose a previously entered expression for a variable from the new drop-down menu. The expression will be copied to the Detail pane where you can select it to perform various actions present in the context menu. And more…​ You can find more noteworthy updates in on this page. What is next? Having JBoss Tools 4.11.0 and Red Hat CodeReady Studio 12.11 out we are already working on the next release for Eclipse 2019-06. Enjoy! Jeff Maury [Less]

We'd like to welcome Gabriela Motroc to the Eclipse Foundation as a Content Marketing Specialist based in Germany!

The survey wrapped up at midnight on Monday, March 25, with over 1,770 responses from developers around the globe.

I am happy to announce that Gabriela Motroc has joined the Eclipse Foundation as a Content Marketing Specialist based in Germany. Gabriela joins us from the Software & Support Media Group, where she was an editor of JAXenter.com and JAX ... [More] Magazine. She is well known to many in the Eclipse community and recently spearheaded JAXenter’s excellent Understanding Jakarta EE Series.  Gabriela holds a Master’s degree in International Communication Management and a B.A. Journalism. Her knowledge and experience will be great assets in developing and sharing updates, news, and content that motivates, educates, and inspires the engagement of our community. Please join me in welcoming Gabriela to the Eclipse Foundation marketing team. Tags:  Eclipse Foundation Marketing Jakarta EE [Less]

JSON Forms is a framework for efficiently developing form-based UIs based on JSON Schema. It provides a simple declarative JSON based... The post Single-sourcing web & mobile forms with JSON Forms appeared first on EclipseSource.

Taking note of an important milestone, how we got here, and where we go next.Eclipse Collections became a reality at the Eclipse Foundation at the end of 2015. We had successfully migrated GS Collections to the Eclipse Foundation to become Eclipse ... [More] Collections. An announcement was published at InfoQ in January 2016 on the migration.By partnering with the Eclipse Foundation, we hope to grow a vibrant and open community of contributors and committers around the Eclipse Collections project.The GS Collections project had only allowed contributions from Goldman Sachs developers. At the Eclipse Foundation, anyone can contribute to the Eclipse Collections project as long as they sign the Eclipse Contributor Agreement.At the time of the move to the Eclipse Foundation, GS Collections had reached 1400 stars on GitHub. After three years of hard work, Eclipse Collections has reached the milestone of 1000 GitHub stars. I marked the milestone in Twitter.With 49 contributors so far, we are realizing our dream of building a vibrant and open community around Eclipse Collections. Contributors are welcome here!We started from zero stars three years agoAlthough GS Collections is no longer actively developed, it has continued growing from 1400 stars in 2016 to over 1700 on GitHub today.Eclipse Collections started at zero stars in 2016 and passed the 1000 star milestone earlier this month. This has been thanks to the support of our growing community. We are fortunate to have some motivated and inspirational Eclipse Collections advocates who help us raise awareness by acting as information radiators and amplifiers.How did we get here?I gave a talk at the Open Source Strategy Forum in 2017 which explained some of the things we have done to help increase awareness of Eclipse Collections. The title of the talk was “They Can’t Hear You On Mute.” It took a lot more than this to get us here.There is no “I” in Open Source.We got where we are today because we worked hard to build a community of energized contributors and vocal advocates. The success of Eclipse Collections has been driven by the support of its vibrant and open developer community. The first thing we had to do was build this community from the ground floor. We actively encourage developers to contribute to the project in numerous ways.We have promoted the approach of using code katas for learning and teaching the framework. The code katas for Eclipse Collections can be found here. One of the greatest contributions someone can make to a framework is to learn it, use it and then to teach it to others. The Eclipse Collections Kata was taught recently at a Dublin Java User Group meet-up.Teaching is the best way to learn, and a great way to contribute. Thank you to all the teachers!We’ve seen multiple blogs and articles written by members of the community, in addition to many tweets. We continue to make rounds at conferences and Java User Group meet-ups, and are happy to hand out Eclipse Collections stickers to anyone who wants one.Every little bit helps. Thank you to everyone who has contributed to our success.You can’t get there from hereThe committers on the project balance their day jobs with engaging with the open source Java community at tech conferences, on Twitter, writing blogs and articles, reviewing issues and pull requests, and occasionally adding new features to the framework. Our role as committers has changed significantly from the days when we were primarily contributors and our focus was to write code we needed for the projects we worked on. Our job now is to raise awareness, provide training, increase adoption, encourage and promote the contributions of others, and continue to build the community. We are actively looking out for developers who are interested in vesting themselves in the framework to the level at which they can become the next committers on the project.You can become a Committer and even Project Lead on an open source project if you set that as a goal and demonstrate you are vested in supporting the project. Below is a link to a great blog post which explains the process of becoming a Committer on an open source project at the Eclipse Foundation.https://waynebeaton.wordpress.com/2018/02/08/the-eclipse-committer-election-workflow/Thank you to everyone in the communityWe received our 1000th commit on the same day that we reached 1000 stars on GitHub. Thank you to our entire Eclipse Collections developer community for helping us reach this second amazing milestone!If you look at the activity in Eclipse Collections since the beginning, you will see a fairly steady flow of work being contributed by our amazing community.It is a nice milestone to have now passed 1000 commits, and it was cool to unlock this achievement on the same day we passed 1000 stars. I gave a shout out on Twitter to the developer who helped us pass this milestone.Thank you to all of the contributors who helped Eclipse Collections reach 1000 commits.Open source will surprise youIn 2018, the greatest surprise contribution from the open source community came in the form of Jackson serialization support for Eclipse Collections types in the jackson-datatypes-collections project.FasterXML/jackson-datatypes-collectionsThis is an amazing contribution to all users of Eclipse Collections who also use the Jackson library for serialization support. We literally did not see this contribution coming, until it arrived. I had hoped someone would be interested in providing this support, and I am very thankful to the developer who worked on it.Star this repo if you use a third-party collections library and benefit from the the Jackson serialization support provided by one of the amazing developers who contribute their time and energy to make our lives as developers easier.We sent some Eclipse Collections mugs and stickers to the developer who made this awesome contribution to the open source Java community.Be willing to be surprised, and remember to say thank you.What’s next for Eclipse Collections?We’re hoping to see our 50th, 60th, and maybe 100th contributor, and our 6th, 7th and maybe even 10th committer by the end of 2019. We appreciate contributions of any kind. No contribution is too small.We’d also like to pass 2000 stars in 2019. We can’t get there without further building our community, so expect to see some energized Eclipse Collections advocates presenting at technical conferences and Java User Group meet-ups throughout 2019.We will be releasing version 10.0 of the project in the next few months. The project has become stable enough that we have not done a major release since September 2017. The addition of default methods in Java 8 has made it possible for us to safely release API changes in minor releases, so the 9.1 and 9.2 releases had quite a few new APIs added.One last thank you for the journey aheadEclipse Collections is an open source project built by an amazing developer community for an amazing developer community. We love Java, and we are thankful to the Eclipse Foundation for giving us a great place to build our community.Thank you to all those that have helped the project reach this stage in its evolution. Thank you to all those that continue to help us as we move the project forward and as we look to build our community further.I hope this blog reaches developers out there who have been interested in joining an open source community and making their first contribution. We are here and happy to help you take that first step.Eclipse Collections is open for contributions. If you like the library, you can let us know by starring it on GitHub. [Less]