Eclipse IDE for Java

This year marks the fifth year the Eclipse IoT Working Group has asked the global IoT developer community to share their perceptions, requirements, and priorities.

After months of hard work, the 2019 IoT Developer Survey results are live today. This year marks the fifth year the Eclipse IoT Working Group has asked the global IoT developer community to share their perceptions, requirements, and priorities. The ... [More] survey has proven to be an influential assessment of the IoT market as viewed from the development front lines. Access the full findings of the 2019 IoT Developer Survey here. Over 1,700 individuals took the survey between February and March 2019. Just like in previous years (see results from 2018, 2017, and earlier here), Eclipse IoT collaborated with key IoT ecosystem players like Bosch and Red Hat to maximize the reach of the survey. The key findings this year include the following: IoT drives real-world, commercial outcomes today. 65% of respondents are currently working on IoT projects professionally or will be in the next 18 months. IoT developers mostly use C, C++, Java, JavaScript, and Python AWS, Azure, and GCP are the leading IoT cloud platforms Top three industry focus areas remain the same as last year: IoT Platforms, Home Automation, and Industrial Automation / IIoT. MQTT remains the dominant IoT communication protocol leveraged by developers The Eclipse Desktop IDE is the leading IDE for building IoT applications IoT gets real(er) Consistent with our findings last year, two-thirds of the respondents to our survey develop and deploy IoT solutions today or will be doing so within 18 months. This continued focus on building and deploying real world solutions is reflected in the increases in developers’ focus on performance, connectivity, and standards shown in the survey. C and Java dominate C won out as the programming language of choice for constrained devices, while Java was most popular for gateways/edge nodes and IoT cloud. Neither of those findings are surprising. C and C++ have long been the languages of choice for small embedded systems where minimizing memory space and power consumption, and maximizing processor utilization are key. Java is the dominant language and platform where the memory and processing resources are larger, and the complexity of the systems are greater. In particular, Java is the language of choice for most cloud infrastructure projects, so seeing it lead in IoT cloud is consistent with that. AWS, Azure, and Google hold on to the lead As expected AWS, Azure, and GCP maintain their status as the leading IoT cloud platforms. The list of three and their rankings are entirely consistent with their relative weights in the cloud computing marketplace as a whole, so there is no surprise to see this reflected in our results. A continued focus on platforms, home automation, and IIoT IoT Platforms (34%), Home Automation (27%), and Industrial Automation / IIoT (26%) were the respondents’ three most common industry focus areas. These areas are likely to continue to be key targets for IoT developer activity.  The fact that IoT Platforms is consistently year after year the number one focus for IoT developers is interesting. It implies that enterprises and industrials are putting resources into building their own IoT platforms for use by their companies. To me this suggests that industrial IoT is going to be a huge opportunity for hybrid cloud, as companies build and run IoT solutions on-premise based using modern, open technologies. Security is (still) top of mind Security is still the top concern for IoT developers. Communication Security (38%) Data Encryption (38%), and JSON Web Tokens (JWTs) (26%) were the top three security technologies cited in the survey, with virtualization also starting to play a stronger role in IoT Security. MQTT is still the dominant IoT communication protocol HTTP (49%), MQTT (42%), and Websockets (26%) were the top three communications protocols used by IoT developers. The growth in MQTT adoption over the past seven or eight years has been phenomenal, and I like to think that the Eclipse IoT community with its Eclipse Paho and Eclipse Mosquitto projects had a small part to play in that. Having robust open source implementations available has certainly been part of the MQTT’s success. Looking forward that main challenge we see for further MQTT adoption is the lack of interoperability built into the protocol. While MQTT is a great lightweight, low latency protocol it does not provide any guidance on the topic structures and payload definitions used by any device or application. This means that no two teams using MQTT would expect to have their systems be able to reliably exchange data. The Eclipse Tahu project defines the Sparkplug protocol — created by Arlen Nipper one of the co-inventors of MQTT itself. Sparkplug defines the topic structures and payload definitions necessary for out-of-the-box interoperability of SCADA systems. We are hopeful that Sparkplug could spur MQTT to even greater adoption in industrial IoT use cases. The Eclipse Desktop IDE is the leading IoT IDE 45% of respondents use the Eclipse Desktop IDE. It is not at all surprising that the Eclipse IDE has a strong franchise with IoT developers, given the dominance of C and Java. The Eclipse CDT project has long been hugely important in the embedded software space. The past decade CDT has been used by virtually every chip, SOC, and RTOS company as the basis for their toolset. Those developer solutions also typically use additional tools such as the Target Management Framework, and Remote Systems Explorer that were specifically designed with the embedded developer in mind. That, coupled with the Eclipse IDE’s broad use amongst professional Java developers makes its leadership in IoT clear. In addition, close to 10% also use Eclipse Che, our community’s next generation cloud-based tooling solution. It really seems part of the future of IoT is in the cloud, one way or another. Access the full findings of the 2019 IoT Developer Survey here. Thanks to everyone who took the time to fill out this survey, and thanks again our Eclipse IoT members for their help with the promotion. We are very interested in hearing your thoughts and feedback about this year’s findings. And, of course, we are always open to suggestions on how to improve the survey in the future! [Less]

With the Xtext framework, you can build DSL workbenches in just a few steps. However, sometimes you want to reuse model elements already defined in other formats or even in other languages. In this blog post I’m going to demonstrate typical scenarios ... [More] when you’re reusing model elements belonging to a different language. Firstly, consider having some pre-defined Eclipse UML2 models, and you want to reference classes of these UML models from your Xtext DSL. If you are interested in reusing model elements belonging to the same language but defined in different formats, take a look at my previous blog post “Combining EMF models with Xtext DSLs”. Let's get started with the preparatory steps: Preparatory steps Install the latest version of the UML2 Extender SDK and the Xtext Complete SDK of the Eclipse release train.   Create the Domainmodel project, based on the Xtext 15 Minutes Tutorial. The meta-model of the Domainmodel projectdescribes that a domain model consist of certain types (data types and entities), an entity contains features and each feature can have a type. To be able to use UML classes in the feature's type definition, the following modifications are necessary: Modifications1 in the org.example.domainmodel plug-in Extend the Domainmodel.xtext grammar definition: grammar org.example.domainmodel.Domainmodel with org.eclipse.xtext.common.Terminals ... import "http://www.eclipse.org/uml2/5.0.0/UML" as uml ... Feature: (many?='many')? name=ID ':' type=[uml::Class|FQN] | type=[Type]; ...   Extend the GenerateDomainmodel.mwe2 workflow: module org.example.domainmodel.GenerateDomainmodel import org.eclipse.emf.mwe.utils.* import org.eclipse.xtext.xtext.generator.* import org.eclipse.xtext.xtext.generator.model.project.* var rootPath = ".." Workflow { bean = StandaloneSetup { scanClassPath = true platformUri = rootPath uriMap = { from = "platform:/plugin/org.eclipse.emf.codegen.ecore/model/GenModel.genmodel" to = "platform:/resource/org.eclipse.emf.codegen.ecore/model/GenModel.genmodel" } uriMap = { from = "platform:/plugin/org.eclipse.emf.ecore/model/Ecore.genmodel" to = "platform:/resource/org.eclipse.emf.ecore/model/Ecore.genmodel" } uriMap = { from = "platform:/plugin/org.eclipse.uml2.codegen.ecore/model/GenModel.genmodel" to = "platform:/resource/org.eclipse.uml2.codegen.ecore/model/GenModel.genmodel" } uriMap = { from = "platform:/plugin/org.eclipse.uml2.uml/model/UML.genmodel" to = "platform:/resource/org.eclipse.uml2.uml/model/UML.genmodel" } uriMap = { from = "platform:/plugin/org.eclipse.emf.codegen.ecore/model/GenModel.ecore" to = "platform:/resource/org.eclipse.emf.codegen.ecore/model/GenModel.ecore" } uriMap = { from = "platform:/plugin/org.eclipse.emf.ecore/model/Ecore.ecore" to = "platform:/resource/org.eclipse.emf.ecore/model/Ecore.ecore" } uriMap = { from = "platform:/plugin/org.eclipse.uml2.codegen.ecore/model/GenModel.ecore" to = "platform:/resource/org.eclipse.uml2.codegen.ecore/model/GenModel.ecore" } uriMap = { from = "platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore" to = "platform:/resource/org.eclipse.uml2.uml/model/UML.ecore" } uriMap = { from = "platform:/plugin/org.eclipse.uml2.types/model/Types.genmodel" to = "platform:/resource/org.eclipse.uml2.types/model/Types.genmodel" } uriMap = { from = "platform:/plugin/org.eclipse.uml2.types/model/Types.ecore" to = "platform:/resource/org.eclipse.uml2.types/model/Types.ecore" } registerGeneratedEPackage = "org.eclipse.emf.ecore.EcorePackage" registerGeneratedEPackage = "org.eclipse.uml2.uml.UMLPackage" registerGeneratedEPackage = "org.eclipse.uml2.types.TypesPackage" registerGeneratedEPackage = "org.eclipse.emf.codegen.ecore.genmodel.GenModelPackage" registerGeneratedEPackage = "org.eclipse.uml2.codegen.ecore.genmodel.GenModelPackage" registerGenModelFile = "platform:/resource/org.eclipse.emf.ecore/model/Ecore.genmodel" registerGenModelFile = "platform:/resource/org.eclipse.emf.codegen.ecore/model/GenModel.genmodel" registerGenModelFile = "platform:/resource/org.eclipse.uml2.uml/model/UML.genmodel" registerGenModelFile = "platform:/resource/org.eclipse.uml2.codegen.ecore/model/GenModel.genmodel" } component = XtextGenerator { ... } }   Add the following plugins to the Require-Bundle section in the MANIFEST.MF file: org.eclipse.uml2.uml org.eclipse.uml2.codegen.ecore Add the following classes: UMLLanguageConstants.xtend UMLQualifiedNameProvider.xtend UMLRuntimeModule.xtend UMLStandaloneSetup.xtend Modifications2 in the org.example.domainmodel.ui plug-in Add the following classes: UMLExecutableExtensionFactory.xtend UMLUiModule.xtend ReflectiveTreeEditorOpener.xtend DomainmodelActivatorEx.xtend Register DomainmodelActivatorEx as Bundle-Activator in the MANIFEST.MF file. Add the following plugin to the Require-Bundle section in the MANIFEST.MF: org.eclipse.emf.ecore.editor Add the following section to the plugin.xml file:   Manual testing Start an Eclipse runtime to verify that parsing, linking, content assistant, hovering, hyperlink navigation, quickfixes, etc., are working properly. Automated testing Extend the org.example.domainmodel.tests plug-in by the Indexing, Linking, Parsing, Scoping, etc. JUnit test cases. Extend the org.example.domainmodel.ui.tests plug-in by the ContentAssistant, Hovering, Hyperlinking, Quickfixes, etc. JUnit Plug-in test cases. Conclusion We have done the preparatory steps, modifications and testing necessary to reuse model elements belonging to a different language. This example has been kept simple on purpose. If you are interested in more advanced use-cases on the Xtext/UML integration, I recommend Karsten‘s and Holger‘s presentation on “How to build Code Generators for Non-Xtext Models with Xtend”. Do you have questions or feedback? Feel free to leave me a comment below.   1,2 Please note that the blog post “Combining EMF Models with Xtext DSLs” explains the necessary modifications in detail. [Less]

The Eclipse CDT project has been around for a long time. The first code commits were in June 2002 when QNX contributed the core C/C++ tooling components of it’s fresh new Momentics IDE. For the time it was quite visionary. Platform vendors are more ... [More] often focused on their platforms and provide tools as an enabler for developers to leverage the power of those platforms. Having every company replicate that effort only leads to poor tools and unhappy developers. It doesn’t scale. Why not join together with like-minded vendors and build something we can all benefit from?As an added bonus, we end up with a standard platform that allows developers to work with multiple environments on the same platform leading to some interesting partnership opportunities. At the very least developers acquire skills working with that IDE they can take to other jobs or even other projects in the same company. It truly is a win/win for everyone and makes for a very rich ecosystem.But as with all long lasting projects, it has had it’s ebbs and flows. As we started, QNX and my team at Rational Software (later part of IBM) were the main contributors. There were a few others lurking around with a few contributions. The first few monthly CDT conference calls were cool as new voices appeared from around the world. It was a great start that led to the first EclipseCon where we had people standing in the hall trying to listen into our overflow birds of a feather session. We were overwhelmed by the interest.But it didn’t last forever and the powers that be decided my team at IBM was needed elsewhere in the company. Obviously I wasn’t pleased and certainly wasn’t ready to leave the community. So when Sebastien Marineau, the CDT project lead at the time suggested I come work for him at QNX, I jumped at the chance. It wasn’t the easiest of moves but it was my chance to do what I could to help keep the CDT machine rolling and ended up getting a good start on my pride and joy, CDT’s super-fast indexer.At the first CDT summit held in the fall of 2005 shortly after I had joined QNX, we had a lot of interest and it was well attended with over a dozen vendors present. We had some good presentations on what we were working on and some interesting presentations from other vendors on what they’d like to see in the project. Well someone said the wrong thing and I had to stop the proceedings. Of the 20 or so people in the room I asked the active contributors to stand up. There were four of us. How are they expecting this little team to do their bidding when the whole idea was to share in the effort and do something great together.That’s probably the proudest and hardest moment of my time on the CDT. It worked. And from the chart above you can see we had healthy growth and lots of vendors coming to help after that. Those were the best years for the project. Though for me personally, I never really did recover from my lost team at Rational/IBM and ended up moving around a bit, never leaving the CDT project but not really giving it my all.Luckily and happily, for the last four years, I’ve been back at QNX working on that original Momentics IDE and contributing to Eclipse trying to make it easier to use for C/C++ developers including my favorite add, the Launch Bar. Our customers are happy, the community seems happy, and there are more and more vendors delivering product based on our work in open source.But also from the chart you can see participation in the CDT has been on a worrying trajectory to a point where we once again have about 4 people actively working on it. Despite being as popular as ever, only a small percentage of people and companies out there are helping with the common cause. It’s made me sad, and frankly angry. And I must apologize to my friends at last year’s EclipseCon for losing control of that a bit, but when you have so many companies leveraging something you are passionately doing for free for them, thanks to my sympathetic employer, you feel taken advantage of.But as the leader of the project, it’s up to me with the help of my open source colleagues to find a way to turn that around. And we have some ideas that I’m very excited about. My next few posts will talk about that and go into details of some very cool new efforts underway in the CDT project. The IDE world has changed but it’s needed more than ever and we are ready to adapt. We really hope you can join us and make it great, again… [Less]

Refactoring is probably one of the most important tools for us, software developers since we constantly need to change the structure of the code to improve the code quality or to prepare the code for new features etc. The most used refactoring ... [More] operation is arguably rename refactoring. Find and replace could be used for renaming but the risk of renaming unrelated names is pretty high.N4JS IDE provides a powerful way of automatically renaming a definition and all its references with a comparable user experience as rename refactoring of Eclipse Java Development Tool (JDT).  The slogan is: I want to rename this thing, do it for me however you like but please in a safe manner so that I can move on! This will exactly be your experience with rename refactoring in N4JS IDE.Simple rename exampleLet's have look at a simple example to see how rename refactoring works in N4JS IDE in action. Assume that we have an N4JS file with the following content.When the cursor is at A of the constructor new A()and we press Cmd + Shift + R to rename A to B, the rename refactoring suggests that it would rename A to B at 3 different locations. After entering the new name B and pressing enter, the class A and all its usages are renamed to B, fully automatically :-)Name conflicts detection Renaming an element may cause name conflicts. The rename refactoring in N4JS IDE provides comprehensive checks for detecting name conflicts. If the new name would cause name conflicts, the rename refactoring is disallowed.In the example above,  renaming class A to class C would cause a name conflict because in the script scope the name C already exists. The rename refactoring provided by N4JS IDE can recognize this conflict and shows an error message.In a large code base, these checks are a true life saver. Imagine having to manually verify these kinds of name conflicts across hundred of files.Additionally, N4JS IDE's rename refactoring is capable of recognizing name conflicts when renaming members of classifier formal parameters of a function or method field of a structural type enum literal local variable, constant global variable, constant etc. Rename composed membersN4JS language supports composed elements. Renaming a composed element is somewhat special. In this example, ab.foo is a composed member because ab is of the intersection type A & B which is composed of both A and B. Renaming ab.foo would rename all the definitions that contribute to the creation of ab.foo as well as all references of these definitions. Preview of changesWhen you start rename refactoring operation, you have the possibility to see the preview of changes before actually executing the operation.Note that the preview shows the changes in each file in a very recognizable manner.Undo changesAfter the rename refactoring, if you feel regret and would like to undo the operation, simply press Cmd + Z. The undo will undo all the changes in affected files previously done by the rename refactoring.Current limitationsAs the time of this writing, the rename refactoring in N4JS IDE still has several limitations: Renaming alias is not supported Checking name conflicts do not take into account shadowing By Minh Quang Tran [Less]

With the Eclipse Foundation Specification Process (EFSP) a single open source specification project has a dedicated project team of committers to create and maintain one or more specifications. The cycle of creation and maintenance extends across ... [More] multiple versions of the specification, and so while individual members may come and go, the team remains and it is that team that is responsible for the every version of that specification that is created. The first step in managing how intellectual property rights flow through a specification is to define the range of the work encompassed by the specification. Per the Eclipse Intellectual Property Policy, this range of work (referred to as the scope) needs to be well-defined and captured. Once defined, the scope is effectively locked down (changes to the scope are possible but rare, and must be carefully managed; the scope of a specification can be tweaked and changed, but doing so requires approval from the Jakarta EE Working Group’s Specification Committee). Regarding scope, the EFSP states: Among other things, the Scope of a Specification Project is intended to inform companies and individuals so they can determine whether or not to contribute to the Specification. Since a change in Scope may change the nature of the contribution to the project, a change to a Specification Project’s Scope must be approved by a Super-majority of the Specification Committee. As a general rule, a scope statement should not be too precise. Rather, it should describe the intention of the specification in broad terms. Think of the scope statement as an executive summary or “elevator pitch”. Elevator pitch: You have fifteen seconds before the elevator doors open on your floor; tell me about the problem your specification addresses. The scope statement must answer the question: what does an implementation of this specification do? The scope statement must be aspirational rather than attempt to capture any particular state at any particular point-in-time. A scope statement must not focus on the work planned for any particular version of the specification, but rather, define the problem space that the specification is intended to address. For example: Jakarta Batch provides describes a means for executing and managing batch processes in Jakarta EE applications. and: Jakarta Message Service describes a means for Jakarta EE applications to create, send, and receive messages via loosely coupled, reliable asynchronous communication services. For the scope statement, you can assume that the reader has a rudimentary understanding of the field. It’s reasonable, for example, to expect the reader to understand what “batch processing” means. I should note that the two examples presented above are just examples of form. I’m pretty sure that they make sense, but defer to the project teams to work with their communities to sort out the final form. The scope is “sticky” for the entire lifetime of the specification: it spans versions. The plan for any particular development cycle must describe work that is in scope; and at the checkpoint (progress and release) reviews, the project team must be prepared to demonstrate that the behavior described by the specifications (and tested by the corresponding TCK) cleanly falls within the scope (note that the development life cycle of specification project is described in Eclipse Foundation Specification Process Step-by-Step). In addition the specification scope which is required by the Eclipse Intellectual Property Policy and EFSP, the specification project that owns and maintains the specification needs a project scope. The project scope is, I think, pretty straightforward: a particular specification project defines and maintains a specification. For example: The Jakarta Batch project defines and maintains the Jakarta Batch specification and related artifacts. Like the specification scope, the project scope should be aspirational. In this regard, the specification project is responsible for the particular specification in perpetuity. Further the related artifacts, like APIs and TCKs can be in scope without actually being managed by the project right now. Today, for example, most of the TCKs for the Jakarta EE specifications are rolled into the Jakarta EE TCK project. But, over time, this single monster TCK may be broken up and individual TCKs moved to corresponding specification projects. Or not. The point is that regardless of where the technical artifacts are currently maintained, they may one day be part of the specification project, so they are in scope. I should back up a bit and say that our intention right now is to turn the “Eclipse Project for …” projects that we have managing artifacts related to various specifications into actual specification projects. As part of this effort, we’ll add Git repositories to these projects to provide a home for the specification documents (more on this later). A handful of these proto-specification projects currently include artifacts related to multiple specifications, so we’ll have to sort out what we’re going to do about those project scope statements. We might consider, for example, changing the project scope of the Jakarta EE Stable APIs (note that I’m guessing a future new project name) to something simple like: Jakarta EE Stable APIs provides a home for stable (legacy) Jakarta EE specifications and related artifacts which are no longer actively developed. But, all that talk about specification projects aside, our initial focus needs to be on describing the scope of the specifications themselves. With that in mind, the EE4J PMC has created a project board with issues to track this work and we’re going to ask the project teams to start working with their communities to put these scope statements together. If you have thoughts regarding the scope statements for a particular specification, please weigh in. Note that we’re in a bit of a weird state right now. As we engage in a parallel effort to rename the specifications (and corresponding specification projects), it’s not entirely clear what we should call things. You’ll notice that the issues that have been created all use the names that we guess we’re going to end up using (there’s more more information about that in Renaming Java EE Specifications for Jakarta EE). [Less]

We have heard from members of the community some suggestions on what they need from the specification, but we can always use more!

As we prepare to engage in actual specification work, it's time to start thinking about changing the names of the specifications and the projects that contain their artifacts.

React is a popular JavaScript library created by Facebook widely used for developing web user interface. N4JS provides full support for React as well as the JavaScript extension JSX for describing UI elements. Internally, we have been using N4JS in ... [More] combination with React and JSX for years to develop very large e-commerce web applications.In this blog post, we would like to show you the support of React and JSX in N4JS. In particular, we will implement the game Tic-tac-toe in N4JS. The implementation is heavily based on the pure JavaScript version in the tutorial Tictactoe in React. In this post, we will focus on N4JS specifics as well as on the advantages of using N4JS over pure JavaScript.As typical with Rect applications, the first step is to design a tree of React components to represent the application.The root React component is Game that consists of two areas. The left area is the React component Board showing the Tic-tac-toe board while the right area shows the game information.N4JS type definitions of ReactIn order to make use of N4JS's type checking for React, we need to declare @n4jsd/react as dev dependency in package.json. @n4jsd/react, provided by us as a public npm, consists of n4jsd files that contain file definitions for React.{     "name": "tictactoe",     "devDependencies": {     "@n4jsd/react": "<=16.6.*",     },     "dependencies": {         "react": "^16.6.0",     } }File extension n4jsxThe standard file extension of N4JS is .n4js. N4JS files containing React and JSX must have the extension .n4jsxSquare React componentThe Square React component defines a single square of the Tic-tac-toe board that can be clicked by the current user. Its value is either X or O or null depending on which user is in turn or if the square is empty. In this example, we define Square as a lightweight functional component since it does not have any state./**  * Square props  */ interface ~SquareProps extends React.ComponentProps {     public value: string;     public onClick: {function(): void}}/**  * Square React component  */ function Square(props: SquareProps): React.Element> {   return (     "square" onClick={props.onClick}>       {props.value}       ); }The functional definition of Square must have a single props parameter and return an instance of type React.Element.When a Square is instantiated, it expects two mandatory props described by SquareProps value: the value of the square, either X, O or null onClick: the event handler to be called when the square is clicked SquareProps, as any data structure describing props of a React component, must extend React.ComponentProps. In addition to having explicit types, the props can be declared as mandatory (as in this example) or optional with the help of the question mark. For instance,  if you declared  public value?: string, value would be an optional prop.Here we start to see the advantages of N4JS over the pure non-type JavaScript implementation. When a Square component is created, the compiler will enforce the type of the props. Moreover, it will complain if a mandatory prop is missing. And all these checks happen at compile time. In pure JavaScript, we will recognize those mistakes only at runtime.Board componentThe Board React component represents the Tic-tac-toe board. Even though it does not have state, we define it as a class because it contains a helper method./**  * Board props  */ interface ~BoardProps extends React.ComponentProps {     public squares: [string];     public onClick: {function(int): void}}/**  * Board React component  */ class Board extends React.Component Object> {   /**    * Render the i-th square on the board    */   renderSquare(i: int) {     return (               value={this.props.squares[i]}         onClick={() => this.props.onClick(i)}       />     );   }   @Override   public render(): React.Element> {     return (               "board-row">           {this.renderSquare(0)}           {this.renderSquare(1)}           {this.renderSquare(2)}                 "board-row">           {this.renderSquare(3)}           {this.renderSquare(4)}           {this.renderSquare(5)}                 "board-row">           {this.renderSquare(6)}           {this.renderSquare(7)}           {this.renderSquare(8)}                   );   } }The Board class, as any class representing a React component, must extend React.Component. Note that React.Component expects two type arguments: the first type argument is the type of props and the second type argument is the type of state.Here, in the render method we simply create 9 Squares that make up the board.Game React componentThis is the root React component of this application and hence does not have any props. Instead, it has state represented by GameState which stores the history of the board, the step number and whether the next player is X./**  * Game state  */ interface ~GameState {     public history: Array<~Object with { squares: Array}>;     public stepNumber: int;     public xIsNext: boolean; }/**  * Game React component (root)  */ export default public class Game extends React.Component GameState> {   public constructor(props: React.ComponentProps) {     super(props);     this.state = {       history: [         {           squares: new Array<string>(9)         }       ],       stepNumber: 0,       xIsNext: true      };   }  ...    @Override   public render(): React.Element> {   ...  }}Here, again thanks to type checking, the N4JS compiler will complain if we access a non-existing field of the state or use the wrong type of a certain field at compile time. In pure JavaScript, we will recognize those mistakes only at runtime.Source codeYou can find the source code here                                                                                                                      By Minh Quang Tran [Less]

The official Scout version 9 has been released as part of the Eclipse simultaneous release 2019-03 and is now publicly available. In this article we highlight some of the new features such as improved responsiveness, support for OpenJDK and more. ... [More] With the Eclipse simultaneous release 2019-03, the new Scout version 9.0 has been released. As usual, it contains a lot of changes. We are happy to share some of the highlights with you. The complete release notes can be found here. Support for OpenJDK and newer Java Versions Long requested and finally here: Scout now supports running on OpenJDK, and on Java versions up to 11. Note that this requires a bit of work on the side of developers; and RedHat's OpenJDK version is not compatible out of the box due to missing elliptic curves. For more details, see the Java 11 section in the release notes and the migration guide. Dark theme You enjoy the dark theme of Eclipse, and want your Scout application users to enjoy the eye-friendliness of a dark theme too? Good news: A dark theme is now included with Scout and the widgets have been adjusted to blend in properly. Improved Usability To improve responsiveness if the window becomes narrow, group boxes can reduce their width by moving their field labels to the top automatically. The Scrollbar handles should be easier to catch, while the trees (treeboxes, navigation) scroll to show you a better view of your data when you expand or collapse an entry. Don't forget to check out the improved options for menu bars and how you can control what happens if there isn't enough space for all the menus. Denser layout option Sometimes screen space can be scarce and the generously spaced elements of Scout will show only a small amount of data in these instances. If you need to display more data at once, you can switch to the "Dense" layout, which reduces the amount of whitespace, which especially increases the number of table rows that are visible at the same time. Below you can see an example from our Contacts demo application: New widgets: Mode Selector and Popup Many widgets got small but awesome improvements – and for sure we have some new widgets too! For instances, check out the model selector and the popup widget. Widget 1: Mode Selector Similar to a Radio Button Group, the new Mode Selector allows you to switch between predefined options, but with a "regular button"-like interface that is quite common on smartphones. Widget 2: Popup With the new "Popup" (also known as popover on some platforms), you can display additional information in an overlay. You have many options to embed widgets here - we can't wait to see what you do with it! The Popup has the following features: Take any widget you like and open it in a Popup by using the WidgetPopup. Use any widget you like as anchor and align the Popup around it. Decide whether you want to point the Popup to the anchor by using the property withArrow. Control the behavior of what should happen if there is not enough space to display the whole Popup using various properties. Choose how the popup should react when the user clicks on the outside or on the anchor. try out all the widgets in our widget app Changed property lookup order In many technologies such as Docker or Kubernetes, changing the configuration without having to create a new deployment is essential. To support this in Scout, the lookup order for Scout properties has been adjusted: It now allows overriding properties in the configuration file by using environment variables. Get to know Scout? Visit our project page, make your first steps with Scout using the comprehensive documentation, and check out the Scout forum if you have questions around a particular topic! Scout survey Do you have two minutes to make Scout even better? Complete survey (2 MIN) [Less]