Eclipse IDE for Java

About a year ago, we realized that although the IoT is on everyone’s lips, there is a huge lack of technical resources available for people interested in learning more and getting their hands dirty with the solutions available today. Our Virtual IoT ... [More] meetup group is an attempt, pretty successful so far, at bridging this gap. The idea is simple: we are organizing regular hangouts where we invite IoT experts and thought leaders to share their experience in IoT, and you can join us to get a chance to learn more and directly ask to these experts any question you may have. We try to answer some of the most commons questions like: “What protocols should I use?”, “How do wireless sensor networks really work?”, “Is there a programming language of choice for IoT?”, “How can I extract meaningful info from my IoT firehose?”, etc. You should definitely check out (and subscribe to!) the YouTube playlist of our webinars to date. Please also make sure to RSVP to our next meetup on July 23 with Günter Obiltschnig. We’re going to learn more on macchina.io, a toolkit for building embedded IoT applications that is written in C++ (for efficiency and embeddability) that also leverages the V8 JavaScript engine for making it even simpler to write applications. Programming IoT Gateways in JavaScript with macchina.io Thursday, Jul 23, 2015, 8:00 AM No location yet. 69 IoT enthusiasts Attending This is a virtual Meetup occurring at 8AM Pacific time. For help with your timezone calculation, refer to this.The meetup will be held on Google Hangouts and you can watch the live stream directly on YouTube.http://www.youtube.com/watch?v=aUkeAW91k4EIn this talk I will introduce macchina.io, a new open source platform for programming Linux-based… Check out this Meetup → Last but not least, if you are interested in sharing with our crowd your experience on an IoT-related topic, please contact me and we would certainly be happy to have you! [Less]

The EMF-IncQuery project is happy to report that with our new release 1.0.0 the project is graduating out of incubation and reaches a new level of maturity. All downloads are available now from the Eclipse.org download servers or the Eclipse ... [More] Marketplace. Coinciding with this event is the first public release of the new generation of the VIATRA model transformation framework, which is a complete re-write (downloads, Marketplace). VIATRA is a high performance model transformation engine powered by IncQuery technology and an Xtend-friendly API based on the "internal DSL" design. Along with traditional, batch-style transformations, VIATRA includes support for source and target incremental live transformations, as well as advanced transformation execution semantics including design space exploration and complex event processing, all integrated over a reactive execution platform. The most important highlights of this EMF-IncQuery release include: compatibility with Eclipse Mars (Xtext 2.8), improved UI and builder stability and performance support for instance models with "non-wellbehaving" models through surrogate queries enhanced support for UML models, including UML-specific derived features improvements to the query language, in particular whitelists for pure functions that are useful for check expressions improvements to IncQuery Viewers, our live query result visualization technology improvements to our Maven-compatible builder to allow for building IncQuery projects on build servers improvements to the IncQuery Debugger Tooling, a tool to aid in debugging queries across JVM boundaries lots of various bug fixes (details) The most important highlights of the VIATRA release include: An internal DSL over the Xtend language to specify both batch and event-driven, reactive transformations. A complex event-processing engine over EMF models to specify reactions upon detecting complex sequences of events. A rule-based design space exploration framework to explore design candidates as models satisfying multiple criteria. A model obfuscator to remove sensitive information from a confidential model (e.g. to create bug reports). lots of various bug fixes (details) We encourage everyone to ask questions in the Eclipse Forums (IncQuery, VIATRA) - none will be left unanswered. Also, be sure to check out the new CPS Example that showcases the most complete feature set of both tools. Make sure to follow our blog at http://incquery.net! [Less]

Let’s say, you heard someone saying that Vert.x is awesome. Ok great, but you may want to try it by yourself. Well, the next natural question is “where do I start ?”. This post is a good starting point. It shows how is built a very simple vert.x ... [More] application (nothing fancy), how it is tested and how it is packaged and executed. So, everything you need to know before building your own groundbreaking application. The code developed in this post is available on github. This post is part of the Introduction to Vert.x series. The code of this post in in the post-1 branch. Let’s start ! First, let’s create a project. In this post, we use Apache Maven, but you can use Gradle or the build process tool you prefer. You could use the Maven jar archetype to create the structure, but basically, you just need a directory with: a src/main/java directory a src/main/test directory a pom.xml file So, you would get something like: . ├── pom.xml ├── src │ ├── main │ │ └── java │ └── test │ └── java Let’s create the pom.xml file with the following content: <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0modelVersion> <groupId>io.vertx.bloggroupId> <artifactId>my-first-appartifactId> <version>1.0-SNAPSHOTversion> <dependencies> <dependency> <groupId>io.vertxgroupId> <artifactId>vertx-coreartifactId> <version>3.0.0version> dependency> dependencies> <build> <plugins> <plugin> <artifactId>maven-compiler-pluginartifactId> <version>3.3version> <configuration> <source>1.8source> <target>1.8target> configuration> plugin> plugins> build> project> This pom.xml file is pretty straightforward: it declares a dependency on vertx-core it configures the maven-compiler-plugin to use Java 8. This second point is important, Vert.x applications require Java 8. Let’s code ! Ok, now we have made the pom.xml file. Let’s do some real coding… Create the src/main/java/io/vertx/blog/first/MyFirstVerticle.java file with the following content: package io.vertx.blog.first; import io.vertx.core.AbstractVerticle; import io.vertx.core.Future; public class MyFirstVerticle extends AbstractVerticle { @Override public void start(Future fut) { vertx .createHttpServer() .requestHandler(r -> { r.response().end("Hello from my first " + "Vert.x 3 application"); }) .listen(8080, result -> { if (result.succeeded()) { fut.complete(); } else { fut.fail(result.cause()); } }); } } This is actually our not fancy application. The class extends AbstractVerticle. In the Vert.x world, a verticle is a component. By extending AbstractVerticle, our class gets access to the vertx field. The start method is called when the verticle is deployed. We could also implement a stop method, but in this case Vert.x takes care of the garbage for us. The start method receives a Future object that will let us inform Vert.x when our start sequence is completed or report an error. One of the particularity of Vert.x is its asynchronous / non-blocking aspect. When our verticle is going to be deployed it won’t wait until the start method has been completed. So, the Future parameter is important to notify of the completion. The start method creates a HTTP server and attaches a request handler to it. The request handler is a lambda, passed in the requestHandler method, called every time the server receives a request. Here, we just reply Hello ... (nothing fancy I told you). Finally, the server is bound to the 8080 port. As this may fails (because the port may already be used), we pass another lambda expression checking whether or not the connection has succeeded. As mentioned above it calls either fut.complete in case of success or fut.fail to report an error. Let’s try to compile the application using: mvn clean compile Fortunately, it should succeed. That’s all for the application. Let’s test Well, that’s good to have developed an application, but we can never be too careful, so let’s test it. The test uses Junit and vertx-unit - a framework delivered with vert.x to make the testing of vert.x application more natural. Now create the src/test/java/io/vertx/blog/first/MyFirstVerticleTest.java with the following content: package io.vertx.blog.first; import io.vertx.core.Vertx; import io.vertx.ext.unit.Async; import io.vertx.ext.unit.TestContext; import io.vertx.ext.unit.junit.VertxUnitRunner; import org.junit.After; import org.junit.Before; import org.junit.Test; import org.junit.runner.RunWith; @RunWith(VertxUnitRunner.class) public class MyFirstVerticleTest { private Vertx vertx; @Before public void setUp(TestContext context) { vertx = Vertx.vertx(); vertx.deployVerticle(MyFirstVerticle.class.getName(), context.asyncAssertSuccess()); } @After public void tearDown(TestContext context) { vertx.close(context.asyncAssertSuccess()); } @Test public void testMyApplication(TestContext context) { final Async async = context.async(); vertx.createHttpClient().getNow(8080, "localhost", "/", response -> { response.handler(body -> { context.assertTrue(body.toString().contains("Hello")); async.complete(); }); }); } } This is a JUnit test for our verticle. The test uses vertx-unit, so we use a custom runner. vert.x-unit makes easy to test asynchronous interactions, which are the basis of vert.x applications. In the setUp method, we creates an instance of Vertx and deploy our verticle. You may have noticed that unlike the traditional Junit @Before method, it receives a TestContext. This object lets us control the asynchronous aspect of our test. For instance, when we deploy our verticle, it starts asynchronously, as most Vert.x interactions. We cannot check anything until it gets started correctly. So, as second argument of the deployVerticle method, we pass a result handler: context.asyncAssertSuccess(). It fails the test if the verticle does not start correctly. In addition it waits until the verticle has completed its start sequence. Remember, in our verticle, we call fut.complete(). So it waits until this method is called, and in the case of a failures, fails the test. Well, the tearDown method is straightforward, and just terminates the vertx instance we created. Let’s now have a look to the test of our application: the testMyApplication method. The test emits a request to our application and checks the result. Emitting the request and receiving the response is asynchronous. So we need a way to control this. As the setUp and tearDown methods, the test method receives a TestContext. From this object we creates an async handle (async) that lets us notify the test framework when the test has completed (using async.complete()). So, once the async handle is created, we create a HTTP client and emits a HTTP request handled by our application. The response is handled by a lambda. In this lambda we retrieves the response body by passing another lambda to the handler method. The body argument is the response body (as a buffer object). We check that the body contains the "Hello" String and declare the test complete. Let’s take a minute to mention the assertions. Unlike in traditional Junit tests, it uses context.assert.... Indeed, if the assertion fails, it will interrupt the test immediately. So it’s pretty important to always uses these assertion methods because of the asynchronous aspect of the Vert.x application and so tests. Our test can be run from an IDE, or using Maven: mvn clean test Packaging So, let’s sum up. We have an application and a test. Well, let’s now package the application. In this post we package the application in a fat jar. A fat jar is a standalone executable Jar file containing all the dependencies required to run the application. This is a very convenient way to package Vert.x applications as it’s only one file. It also make them easy to execute. To create a fat jar, edit the pom.xml file and add the following snippet just before : <plugin> <groupId>org.apache.maven.pluginsgroupId> <artifactId>maven-shade-pluginartifactId> <version>2.3version> <executions> <execution> <phase>packagephase> <goals> <goal>shadegoal> goals> <configuration> <transformers> <transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer"> <manifestEntries> <Main-Class>io.vertx.core.StarterMain-Class> <Main-Verticle>io.vertx.blog.first.MyFirstVerticleMain-Verticle> manifestEntries> transformer> transformers> <artifactSet/> <outputFile>${project.build.directory}/${project.artifactId}-${project.version}-fat.jaroutputFile> configuration> execution> executions> plugin> It uses the maven-shade-plugin to create the fat jar. In the manifestEntries it indicates the name of our verticle. You may wonder from where comes the Starter class. It’s actually a class from vert.x, that is going to create the vertx instance and deploy our verticle. So, with this plugin configured, let’s launch: mvn clean package This is going to create target/my-first-app-1.0-SNAPSHOT-fat.jar embedding our application along with all the dependencies (including vert.x itself). Executing our application Well, it’s nice to have a fat jar, but we want to see our application running! As said above, thanks to the fat jar packaging, running Vert.x application is easy as: java -jar target/my-first-app-1.0-SNAPSHOT-fat.jar Then, open a browser to http://localhost:8080. To stop the application, hit CTRL+C. Conclusion This Vert.x 3 crash class has presented how you can develop a simple application using Vert.x 3, how to test it, package it and run it. So, you now know everything you need to build amazing system on top of Vert.x 3. Next time we will see how to configure our application. Happy coding & Stay tuned ! [Less]

At the PolarSys exhibit at INCOSE (booth B6-B7), several PolarSys members will showcase the following PolarSys systems engineering solutions.

In programming literature it has become the standard to create a hello world program as the first example. In thisarticle I’ll be demonstrating how NPM users can quickly get started with vert.x. You will see that it is notthat different and in fact ... [More] it can be done using the tools you’re used to. Note that although we are using NPM we arenot relying on node.js, all javascript code runs on the JVM. Hello World Examples Here are four simple hello world examples. The comments in the code explain how the code works and the text around itexplain what it does and how to test it. Hello Console This example is about as plain as it can get. It prints the words “Hello World“ to the terminal. If you’re ajavascript developer you should be already used to npm and know that you always start a project with the filepackage.json: { "name": "vertx3-hello-console", "private": true, "dependencies": { "vertx3-min": "3.0.0-1" }, "scripts": { "start": "./node_modules/.bin/vertx run server.js" } } Note that we have a dependency wich is obvious vert.x now note that there are 3 flavours of this dependency: min base full According to your needs you can pick a different flavour, since for a simple hello world we only need the minimal thatis the one we add to the dependency property. Now we need to do a simple hello app, we will call this file “server.js“: // Call the console.log function. console.log("Hello World"); You can run this by running npm start. Hello HTTP I’d guess that while it’s not the only use case for vert.x, most people are using it as a web application platform. Sothe next example will be a simple HTTP server that responds to every request with the plain text message “Hello World“server.js: vertx.createHttpServer() .requestHandler(function (req) { req.response() .putHeader("content-type", "text/plain") .end("Hello World!"); }).listen(8080); Now you can reuse the same package.json we’ve just defined in the previous section and start the server withnpm start. Once the server starts you can open a browser to http://localhost:8080 and enjoy the message. Hello TCP Vert.x also makes an excellent TCP server, and here is an example that responds to all TCP connections with themessage “Hello World” and then closes the connection server.js: var server = vertx.createNetServer(); server.connectHandler(function (socket) { socket.write("Hello World!\n"); socket.close(); }); server.listen(7000, "localhost"); Again reuse the previous package.json and test it by doing telnet localhost 7000. Hello Web Often you won’t be using vert.x built-in libraries because they are designed to be very low level. This makes vert.xquick, nimble, and easy to maintain, but if you are planning to build a complex application you want some productivityand rely on a simple web framework. For this specific case there is vert.x web,a simple, yet productive framework, to build fast web application with routing, templaterendering, lots of middleware etc…usually not enough to get started on a real world application. This example shows anHTTP server that responds with “Hello World” to all requests to “/“ and responds with a 404 error to everything elseserver.js: var Router = require("vertx-web-js/router"); var server = vertx.createHttpServer(); var router = Router.router(vertx); router.get("/").handler(function (ctx) { // This handler will be called for "/" requests var response = ctx.response(); response.putHeader("content-type", "text/plain"); // Write to the response and end it response.end("Hello World!"); }); server.requestHandler(router.accept).listen(8080); In order to test this, you will need to install the vertx3-full stack. There are two ways to do this. You can eitherinstall it globally npm install -g vertx3-full or add it as a dependency to our package.json as we have done before,for example package.json: { "name": "vertx3-hello-web", "private": true, "dependencies": { "vertx3-full": "3.0.0-1" }, "scripts": { "start": "./node_modules/.bin/vertx run server.js" } } That’s it for now, Hopefully this will help you get started working with vert.x! [Less]

The Eclipse Mars release marked a special moment for myself and our team at QNX and BlackBerry. It’s the culmination a few things we’ve really wanted to get done for our Momentics users and share with the greater Eclipse community. It is focused ... [More] around the Launch Bar and we’ve received great feedback from those who’ve tried it and those trying to adapt it for their own launch configurations and remote targets. And working with the community is why we do open source. We built it first for our BlackBerry Momentics users building BB10 apps and they loved it. But as we push forward we can learn and benefit from other IDEs trying to adapt it. It just makes the architecture better for everyone and ensures we can adapt it ourselves as we try to use it for new things. Open Source isn’t a charity so we give, but it’s also not a donation as we get a lot back in return. Now that summer is in full force and I’ve finished off some vacation, it’s time to start planning for the next year. There’s still some work with the Launch Bar to do to clean up the rough edges and get it to the point where I would encourage all Eclipse packages to use it. I also want to continue the work we started with the PTP gang with the org.eclipse.remote target management system and make it a good replacement for the Remote System Explorer. I hope to get that in place by the Mars SR-1 release in September. I also want to get back into improving Qt support in the CDT to make QML and qmake projects first class citizens so that the CDT is a good option to Qt Creator and let Qt developers take advantage of the Eclipse ecosystem. That led me into the discussion about how to make it easier to add languages to Eclipse, in this case QML. There’s been some great discussion on the ide-dev list and other places with lots of ideas. I want to use ANTLR 4 for the QML work and am hoping I can generalize out of that so we can make it easier to add other complex languages like it. I’d like to extend CDT’s support to all languages supported by clang and LLVM. Even Swift if that’s the direction they take to open source it. And it opens up an area in CDT that we really need to improve to allow us to take advantage of new toolchains and build systems. The CDT build system has always been somewhat cumbersome both for adopters trying to hook our tools up, and users who are trying to set up their build environments. We’re going to work with the CDT community to see if we can come up with a simpler architecture that takes advantage of the build systems, such as Qt’s qmake and CMake, that weren’t around or as mature when we started. I also have my personal work on the Arduino C++ IDE for CDT. IoT is a great area of focus in open source and it’s really fun to architect an IDE for. You have a lot of choices in micro-controller (Arduino, ESP8266, and many upcoming Cortex-M* boards) and Raspberry Pi and other Cortex-A* boards. We really need to have CDT in shape for those developers. But IoT goes beyond devices, you also have the cloud that they pass data to and get commands from, and then you have the Web and Mobile clients that hook up to the cloud. IMHO, Eclipse is the best choice as an IDE to build and debug all those components. And with my recent work at QNX, I have first hand experience at that and swear by it. Lots to do and I’m certainly not going to get it all done when I want to, but we’ll keep plugging away and accept help when it’s offered and we’ll get there. [Less]

Tony McCrary discusses HiDPI's impact on Eclipse software development, how to get the best performance on HiDPI devices, and what can be done to support HiDPI in the Eclipse platform and SWT. By Tony McCrary

Maxime Porhel discusses possible integration paths between Sirius and Xtext with demos based on Xtext DSLs, and the latest progress made in Sirius 3.0 regarding this integration. By Maxime Porhel

You might ask… Handly sounds interesting, but can it be of any use if I already have a code model with a well-established API? (Or, perhaps, you’d like to use Handly in a greenfield, but are a bit uncomfortable about the leakage of Handly API to your ... [More] model’s clients.) If this sort of questions makes you delay considering Handly adoption, perhaps you should wait no longer. Handly can support legacy models while still providing the benefits of a uniform handle-based API. Now when the dust settled after the Handly 0.3 release, let me show you how. Although Handly imposes almost no restrictions on the model shape or on the languages modeled, it still requires that model elements implement some of the provided interfaces such as IHandle, ISourceElement and ISourceFile, which might be enough to break API compatibility with an existing model. However, a handle-based design makes it straightforward to implement lightweight adapter elements to the existing model API and expose this fully backwards compatible adapter model to clients. As long as those adapter elements implement IAdaptable and can adapt themselves to underlying Handly-based model elements, they can be fully supported by the generic IDE infrastructure built on top of the uniform Handly API. The adapter model does incur additional overhead in both time and space, but in many cases it should be manageable, and it is an architecturally sound solution. To make it more concrete and as a proof of concept, I have implemented a subset of the JDT Java model API atop the example model for Java and pushed it to the javamodel.jdt branch in the project’s repository. (I’m hesitant about merging it to master as I think it can unnecessarily complicate the Java model example. However, I’m open to reconsidering this decision based on the community feedback.) Once the adapter model had been in place, it was very easy to use existing JDT UI classes to build an almost fully functional Java Navigator. I said almost because, since the adapter model was based on the deliberately contrived example model, many of its methods just throw UnsupportedOperationException. However, navigation does work, and you can see all the usual actions in the context menu (although it is not recommended to actually use those actions since, as mentioned above, the underlying adapter model is incomplete and not all operations are supported; you can still use the JDT’s Package Explorer for performing the actions). I must say that implementing such an adapter to the JDT Java model API was an exciting (if a bit short) experience! In the end, it’s all about loose coupling. Your model API may depend on Handly, which can be convenient in many cases, but is not strictly required: instead, you can treat your Handly-based model as an implementation detail, exposing only the adapter model to clients. Generic IDE components (such as those already provided by Handly) may depend on the uniform Handly API, but can know nothing about specifics of a model. Finally, there may be (in theory, at least) alternative implementations of the Handly API in addition to the one provided by the project itself. Support for legacy models as well as overall API quality are going to be important themes on our way to the Handly 0.4 release. As always, feedback is most welcome and can be directed to the project’s forum or right to the developer mailing list. [Less]

Last few week we worked on RAP on e4 to adopt the latest upstream components from the Mars release: RAP 3.0 from Mars release e4 core libraries from Mars release So that people developing e4 applications on top of RAP (or single sourcing their ... [More] e4-RCP) can take advantage of the improvements (bugfixes and features) incorporated in the upstream projects. E.g. RAP 3.0 has improved performance significantly (see Ralf’s blog post on it). What’s new From the feature point of view the most important change for e4 on RAP was that RAP 3.0 added suppport for the Control#setParent(Composite) API. This new support allows e4 on RAP to provide support for sharing parts between perspectives. The following screencast shows the feature in action: At the code level the most important changes that we inherited was that we could get rid of the org.eclipse.e4.core.di fork we had to ship for Luna because the DI-Container was swallowing too many exceptions. Where to get it To bootstrap a RAP application the easiest way is to install our RAP-e4 tooling from http://download.eclipse.org/rt/rap/incubator/nightly/e4/tooling/site. We also prepared a complete self-contained target platform for you which you can access at http://download.eclipse.org/rt/rap/incubator/nightly/e4/target/site or if you prefer a local version you can download the p2 repository as a zip. We have a short description how you bootstrap an e4 on RAP application at https://wiki.eclipse.org/RAP/E4 Leave a Comment [Less]