Jonathan Lalou's Blog

Posts Tagged ‘Eclipse’

At DevoxxUS2017, Martin Lippert, a pivotal figure at Pivotal and co-lead of the Spring Tool Suite, delivered an engaging presentation on advanced tooling for Spring Boot development within the Eclipse IDE. With a rich background in crafting developer tools, Martin showcased how recent updates to Spring IDE and Spring Tool Suite streamline microservice development, particularly for Spring Boot and Cloud Foundry. His live demos and coding sessions highlighted features that enhance productivity and transform the IDE into a hub for cloud-native development. This post explores the key themes of Martin’s presentation, offering insights into optimizing Spring Boot workflows.

Streamlining Spring Boot Development

Martin Lippert opened by demonstrating the ease of initiating Spring Boot projects within Eclipse, leveraging the Spring Tool Suite. He showcased how developers can quickly scaffold applications using Spring Initializr integration, simplifying setup for microservices. Martin’s live demo illustrated generating a project with minimal configuration, emphasizing how these tools reduce boilerplate code and accelerate development cycles, aligning with Pivotal’s mission to empower developers with efficient workflows.

Advanced Configuration Management

Delving into configuration, Martin highlighted enhanced support for Spring Boot properties in YAML and property files. Features like content-assist, validation, and hover help simplify managing complex configurations, crucial for microservices. He demonstrated real-time synchronization between local projects and Cloud Foundry manifests, showcasing how the Spring Boot dashboard detects and merges configuration changes. These capabilities, Martin noted, ensure consistency across development and deployment environments, enhancing reliability in cloud-native applications.

Spring Boot Dashboard and Cloud Integration

A centerpiece of Martin’s talk was the Spring Boot dashboard, a powerful tool for managing multiple microservice projects. He showcased its ability to monitor, start, and stop services within the IDE, streamlining workflows for developers handling distributed systems. Martin also explored advanced editing of Cloud Foundry manifest files, illustrating seamless integration with cloud runtimes. His insights, drawn from Pivotal’s expertise, underscored the dashboard’s role in transforming Eclipse into a microservice development powerhouse.

Links:

• Pivotal company website
• Spring Tool Suite website
• Cloud Foundry website

Lecturer

Ken Walker, a seasoned software engineer at IBM in Ottawa, Canada, leads the Orion project at the Eclipse Foundation. With extensive experience in software tooling, Walker has been instrumental in advancing web-based development environments. His work focuses on bridging the gap between traditional desktop IDEs and emerging cloud-based solutions, emphasizing accessibility and collaboration. As a key contributor to the Eclipse ecosystem, he leverages IBM’s long-standing involvement in open-source initiatives, including the Eclipse Foundation’s formation in 2004, to drive innovation in developer tools.

Abstract

The transition to cloud-based development environments has promised seamless collaboration, instant access, and reduced setup overhead, yet browser-based Integrated Development Environments (IDEs) like Orion face skepticism from developers accustomed to robust desktop tools such as IntelliJ IDEA or Visual Studio. This lecture, delivered at Devoxx France 2014, explores the reasons behind this resistance, dissecting the technical and usability shortcomings of browser IDEs while highlighting their unique strengths. Through a detailed comparison of desktop and cloud-based development workflows, Ken Walker examines performance bottlenecks, integration challenges, and user experience gaps that deter adoption. He also showcases Orion’s innovative features, such as real-time collaboration and cloud deployment integration, to demonstrate its potential. The discussion concludes with a forward-looking perspective on how evolving web technologies could make browser IDEs indispensable, offering insights for developers considering hybrid workflows in modern software engineering.

The Evolution of IDEs and the Cloud Paradigm Shift

Integrated Development Environments have evolved significantly since the 1980s, when tools like Turbo Pascal provided basic editing and compilation for single languages. The 1990s introduced cross-platform IDEs like Eclipse and NetBeans, which embraced modular architectures to support diverse languages and tools. These desktop IDEs excelled in performance, leveraging local hardware for fast code completion, debugging, and refactoring. However, the rise of cloud computing in the late 2000s sparked a shift toward browser-based IDEs, promising accessibility across devices, automatic updates, and collaborative features akin to Google Docs.

Ken Walker highlights that this shift has not been universally embraced. Developers often find browser IDEs lacking in responsiveness, particularly for tasks like code analysis or large-scale refactoring. This stems from browser sandboxing, which restricts access to local resources, and the inherent limitations of JavaScript execution compared to native applications. For instance, real-time syntax highlighting in a browser IDE may lag when processing thousands of lines, whereas desktop tools like IntelliJ leverage multithreading and local caching for near-instantaneous feedback.

Integration with local development environments poses another challenge. Desktop IDEs seamlessly interact with local file systems, Git clients, and build tools like Maven. In contrast, browser IDEs rely on cloud storage or WebSocket-based synchronization, which can introduce latency or data consistency issues during network disruptions. Walker cites user feedback from the Eclipse community, noting that developers often struggle with configuring browser IDEs to replicate the seamless toolchains of desktop counterparts.

Why Developers Resist Browser IDEs

Walker delves into specific pain points that fuel developer skepticism. One major issue is the lack of feature parity with desktop IDEs. Advanced debugging, a cornerstone of development, is less robust in browser environments. For example, Orion’s debugging relies on remote sessions, which can falter over unstable connections, making it difficult to step through code or inspect complex object states. In contrast, tools like Visual Studio offer graphical debuggers with real-time memory visualization, which browser IDEs struggle to replicate due to browser API constraints.

User experience gaps further compound resistance. Keyboard shortcuts, critical for productivity, often conflict with browser defaults (e.g., Ctrl+S for saving vs. browser save-page functionality), requiring developers to relearn bindings or configure overrides, which vary across browsers like Chrome, Firefox, and Safari. Touch-based devices exacerbate usability issues, as precise cursor placement or multi-line editing becomes cumbersome without mouse input, particularly on tablets.

Collaboration, a touted benefit of browser IDEs, can also disappoint. While real-time editing is possible, poorly handled concurrent changes lead to merge conflicts, especially in large teams. Orion’s Git integration supports basic workflows like commits and pulls, but complex operations like rebasing or resolving merge conflicts lack the intuitive interfaces of desktop tools. Walker acknowledges these issues but argues that they reflect growing pains rather than inherent flaws, as web technologies continue to mature.

Orion’s Strengths and Innovations

Despite these challenges, Orion offers compelling advantages that desktop IDEs struggle to match. Its cloud-native design enables instant project sharing: developers can fork a GitHub repository, edit code in the browser, and push changes without local setup. This lowers barriers for open-source contributors and simplifies onboarding for distributed teams. For example, a developer can share a workspace URL, allowing colleagues to edit code or review changes in real time, a feature that requires additional plugins in desktop IDEs.

Orion integrates seamlessly with cloud platforms like Heroku and AWS, enabling direct deployment from the browser. This streamlines workflows for web developers, who can preview applications without leaving the IDE. Walker demonstrates a live example where a JavaScript application is edited, tested, and deployed to a cloud server in under a minute, showcasing the potential for rapid prototyping.

Recent advancements in web technologies bolster Orion’s capabilities. WebAssembly enables computationally intensive tasks like code analysis to run efficiently in browsers, narrowing the performance gap with native tools. Service workers provide offline support, caching code to allow editing during network outages. Orion’s plugin architecture further enhances flexibility, allowing developers to add custom tools, such as live CSS previews or integration with CI/CD pipelines like Jenkins.

Comparing Desktop and Cloud Workflows

Desktop IDEs excel in performance and integration. IntelliJ IDEA, for instance, uses indexed codebases for instant autocomplete and refactoring across millions of lines. Local Git clients provide robust version control, and native debuggers offer granular control. However, these tools require significant setup—installing Java, configuring plugins, and ensuring compatibility across operating systems—which can hinder collaboration in distributed teams.

Browser IDEs prioritize accessibility. Orion requires only a browser, eliminating installation barriers and ensuring consistency across devices. For educational settings or hackathons, this is transformative: participants can start coding instantly without worrying about Java versions or environment variables. Walker cites Orion’s use in Eclipse community workshops, where novices and experts collaborate seamlessly on shared projects.

The trade-off lies in complexity. Desktop IDEs handle large, monolithic codebases better, while browser IDEs shine for web-focused or lightweight projects. Walker proposes a hybrid model: use browser IDEs for quick edits, prototyping, or collaborative tasks, and desktop IDEs for heavy-duty development like systems programming or enterprise applications.

Future Directions for Browser IDEs

Emerging web standards promise to address current limitations. WebGPU, for instance, will enable hardware-accelerated graphics, improving performance for tasks like code visualization. Progressive Web Apps (PWAs) enhance offline capabilities, making browser IDEs viable in low-connectivity environments. Integration with AI-driven tools, such as GitHub Copilot, could provide intelligent code suggestions, further closing the gap with desktop IDEs.

Walker envisions browser IDEs evolving into primary tools as browser performance approaches native levels. Projects like CodeSandbox and Replit, which emerged post-2014, validate this trajectory, offering robust cloud IDEs with growing adoption. Orion’s open-source nature ensures community-driven enhancements, with plugins for languages like Python and Go expanding its scope.

Conclusion: A Balanced Perspective on Cloud Development

Browser IDEs like Orion represent a paradigm shift, offering unmatched accessibility and collaboration but facing hurdles in performance and integration. While developer resistance is understandable given the maturity of desktop tools, rapid advancements in web technologies suggest a convergence of capabilities. By adopting a hybrid approach—leveraging browser IDEs for lightweight tasks and desktop IDEs for complex projects—developers can maximize productivity. Walker’s talk at DevoxxFR2014 underscores the potential for browser IDEs to reshape development, encouraging the audience to explore tools like Orion while acknowledging areas for improvement.

Links

• Lecture video
• Orion official site
• Eclipse Foundation
• CodeSandbox
• Replit

J’ai eu la chance d’assister a la derniere journee de DevoxxFR a Paris, le vendredi 29/03/2013, pour le compte de mon employeur StepInfo, sponsor de l’evenement. Voici quelques impressions en vrac

General

• C’est bien organise, il y a du monde, et excepte au moment du depart au niveau des vestiaires, il n’y a pas eu de gros souci de logistique.
• Les entreprises sponsors ont joue le jeu 😉
• Que ce soit au niveau des stands ou des conferences, la domination des Mac est ecrasante! Google a reussi a mettre en valeur ses ChromeBooks, mais j’ai vu peu de Windows et encore moins de Linux.
• J’ai pu assister a 4 conferences, toutes interessantes, mais d’un niveau heterogene, je reviens dessus plus en detail ci-dessous.

IDE Java : astuces de productivité pour le quotidien

La conference est animee par Xavier Hanin (@xavierhanin). Il y presente les trois IDE phares du monde Java: NetBeans, Eclipse et IntelliJ IDEA.

Maitrisant plutot bien IDEA, je n’ai pas appris de choses fondamentales sur mon IDE, si ce n’est le raccourci Ctrl+Shift+A pour afficher les intentions. J’ai connu NetBeans a ses debuts (Forte puis Sun ONE), mais j’en ai totalement perdu la maitrise depuis des annees. Quant a Eclipse, il m’arrive de le lancer quelques fois par an pour des problematiques clients specifiques, mais je suis contraint d’avoir recours a la souris en quasi-permanence ; sous IDEA c’est tres rare.

Un “sondage” assez grossier des personnes dans la salle a donne des resultats interessants: ~15% des developpeurs presents utilisent NetBeans, ~25% IDEA et ~90/95% Eclipse.

Quick Start avec le Cloud Google

La conference est animee par Didier Girard de SFEIR et Alexis Moussine-Pouchkine de Google France. Les principaux outils de Google pour le cloud sont presentes, en prenant pour hypothese de creer une startup: une solution “a l’ancienne”, avec serveurs d’applications, gestion materielle etc. est avancee, avant de ceder la place a une solution entierement sur le cloud de Google.

En un mot: c’est tres convaincant.
Je regrette que le sujet n’ait pas ete elargi vers des solutions cloud alternatives, comme celle d’Amazon.

• Didier Girard:
• Sur twitter: @DidierGirard
• Sur Google+: +Didier
• Alexis Moussine-Pouchkine:
• Blog: http://alexismp.wordpress.com/
• Twitter: @alexismp
• Google+: +Alexis

The Spring Update: Looking at Spring 3.1, 3.2, and 4.0

La presentation est menee par Josh Long de SpringSource. On se rend compte tres rapidement que ne serait-ce que pour la qualite du show, nous les Francais (voire les Latins) nous sommes largement en dessous de la qualite des Anglo-Saxons.

Josh enonce ses concepts, donne des exemples, met l’eau a la bouche. Au bout de 50′ de conference, je n’ai plus qu’une envie: retourner coder avec les dernieres versions de Spring!

Parmi toutes les nouveautes, j’en retiens deux:

• l’AnnotationConfigApplicationContext, qui m’evitera de taper d’ecrire un bloc comme:[xml]    <context:component-scan annotation-config="true" base-package="lalou.jonathan.beans"/>[/xml]
• l’integration future des websockets d’HTML5 pour obeir a la norme JEE7 d’ici la fin de l’annee.

Ce dernier point m’interesse particulierement, en raison d’un projet sur lequel je travaille actuellement, et dont nombre de problemes seraient resolus par les websockets de JEE7. Theoriquement, et potentiellement, d’ici la fin de l’annee 2013, nous pourrions integrer une brique “Spring JEE7” avec websocket au sein d’un WebSphere 8 (donc non JEE7-compliant), au lieu d’etre dependant dans la prochaine release du serveur d’applications d’IBM.

Josh:

• sur twitter: @starbuxman
• sur son blog: http://joshlong.com/
• Google+: +Josh

Entre HPC et big data: un case study sur la simulation du risque de contrepartie

C’est la conference dont j’ai vu le moins le rapport avec Devoxx, mais ayant passe 7 ans dans la finance de marche j’y ai trouve mon interet. En passant, j’y ai vu le seul PC sous Windows de toutes les conferences :-D.

Le theme de cette conference est: comment deporter une partie du calcul intensif de Monte-Carlo du CPU vers les GPU? Ces derniers ont une taille et une structure de memoire radicalement differente de celles des CPU (CPU+RAM pour etre plus precis). Les GPU permettent d’effectuer des masses de calcul en un temps bien plus faible (jusqu’a 99% de gain) qu’en architecture classique, moyennant une reecriture du code C en un autre langage adapte, par exemple OpenCL.

Les deux speakers, de Murex, sont Adrien Tay Pamart (visiblement pas tres a l’aise en mode geek) et Jonathan Lellouche pour la partie technique.

Durant les questions, l’existence de ponts Java vers OpenCL, comme JavaCL est evoquee. Il est dommage de ne pas avoir plus de temps pour creuser ce theme.

5 ans et 500 releases en 50 minutes !

La presentation est dirigee par Freddy Mallet  et Olivier Gaudin de Sonar.

La demonstration est rudement bien faite. Les dirigeant de SonarSource retracent, dans un ordre plus ou moins chronologique, les problemes, ou les impediments a-t-on envie de dire, rencontres en 5 ans sur Sonar.
Quelques themes forts: le context switching est une plaie, on ne gere pas une entreprise commerciale avec des clients comme un simple projet open source, etc.

• Freddy:
• Sur twitter: @FreddyMallet
• Olivier:
• Sur twitter: @gaudol

En guise de conclusion

Devoxx a repondu aux attentes que j’avais en y entrant:

• une journee de formation intensive et motivante
• revoir des “anciennes tetes”
• echanger des cartes de visite

Qu’il me soit donc permis ici de remercier StepInfo pour m’avoir permis d’acceder a cette journee, ainsi que les organisateurs de Devoxx pour le travail qu’il ont accompli.

Vivement DevoxxFR 2014!

Case

The project on which I work is built on Eclipse and Ant. I am trying to migrate it to Maven 3.0. I thought to do this within IntelliJ IDEA.
Once the pom.xml was created, I wanted to revert to a configuration based on Eclipse’s .classpath file.
Then IntelliJ IDEA crashes. On starting up again, I get the following error

[java]Cannot load module file ‘jonathanModule’ Unsupported classpath format eclipse[/java]

Quick Fix

For a reason I ignore, Eclipse integration plugin was disabled. To restore Eclipse compatibility, simply do enable Eclipse integration in the plugin preference menu of IntelliJ IDEA.

Case:

On launching Eclipse 3.6.1 under Linux 64bits, I get the following error:

[java]Locking is not possible in the directory "/opt/eclipse/configuration/org.eclipse.osgi". A common reason is that the file system or Runtime Environment does not support file locking for that location. Please choose a different location, or disable file locking passing "-Dosgi.locking=none" as a VM argument. /opt/eclipse/configuration/org.eclipse.osgi/.manager/.fileTableLock (Permission denied)[/java]

Fix:

Edit /opt/eclipse/eclipse.ini, add or move the line:

[java]-Dosgi.locking=none[/java]

at the end of the file, or at least after the argument -vmargs

Context

In a GWT application, you have to use RPC calls, using entities which are package in external jar archives. With Eclipse, no error appears ; yet when you build the project with Maven2, you get this message:

[java][INFO] [ERROR] Errors in ‘file:/C:/eclipse/workspace/myGwtProject/src/java/com/lalou/jonathan/web/gwt/client/component/JonathanPanel.java’
(…)
[INFO] [ERROR] Line 24: No source code is available for type com.lalou.jonathan.domain.MyEntity; did you forget to inherit a required module?
(…)
[INFO] Finding entry point classes[/java]

Fix

In related jar

In the project to which MyEntity belongs to (here: my/depended/project):

• create a file com/lalou/jonathan/MyDependedProject.gwt.xml, with as content:

  [xml]<module>
  <source path="">
  <include name="**/MyEntity.java"/>
  </source>
  </module>[/xml]

• In the pom.xml:
  • Add the source MyEntity.java in built jar. This way, the Java file itself will be considered as a resource, like an XML or property file. To perform this, the quickest manner is to add the following block in the pom.xml:
    [xml]<resources>
    <resource>
    <directory>${basedir}/src/java</directory>
    <includes>
    <include>**/MyEntity.java</include>
    </includes>
    </resource>
    </resources>[/xml]
  • Add an <include>**/*.gwt.xml</include> so that to have to MyDependedProject.gwt.xml file in the built jar.

  In GWT project

  In your *.gwt.xml file, add the dependency:

  [xml]<inherits name=’com.lalou.jonathan.MyDependedProject’ />[/xml]

  Caution!

  All these operations need be done on all dependencies -either direct or indirect-. Therefore, possibly you may have a huge amount of code to be got.
  Another issue appears when you use a jar of which you do not have the source code, such as in the case of tiers API for instance.

Case

You have to run a standalone Mule 2.2.1 in debug mode. Since Mule is launched in standalone, you have to debug a remote application.

Fix

Nice case

• Edit the %MULE_HOME%/conf/wrapper.conf
• Uncomment the line:

  wrapper.java.additional.<n>=-Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5005

• Don’t forget to set the parameter <n>

Boring case

In my case (Windows XP SP2, Java 1.5), the Mule refused to start and freezed:

------------------------------------------------------------------------
The JVM is being launched with a debugger enabled and could possibly be
suspended.  To avoid unwanted shutdowns, timeouts will be disabled,
removing the ability to detect and restart frozen JVMs.
------------------------------------------------------------------------
Launching a JVM...
Listening for transport dt_socket at address: 5005
------------------------------------------------------------------------
Startup: Timed out waiting for a signal from the JVM.
The JVM was launched with debug options so this may be because the JVM
is currently suspended by a debugger.  Any future timeouts during this
JVM invocation will be silently ignored.
------------------------------------------------------------------------

The fix this:

• Download the jar spring-agent here.
• Move it into %MULE_HOME%/lib/user/
• Edit the %MULE_HOME%/conf/wrapper.conf
• add the following block:

wrapper.java.additional.3=-javaagent:%MULE_HOME%\lib\user\spring-agent-2.5.3.jar
wrapper.java.additional.4=-Xdebug
wrapper.java.additional.5=-Xnoagent
wrapper.java.additional.6=-Djava.compiler=NONE
wrapper.java.additional.7=-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5005

• (by the way, even though properties #3 and #5 are inconsistent, don’t mind)
• launch the Mule
• In your IDE (Eclipse, NetBeans, IntelliJ IDEA), run debug on localhost:5005

Yeah, I know this must be widely known, yet I needed a short while before successing ;-).
Case: I must mount a Java projet from a Maven2 file, under Eclipse (I am back to my prefered IDE).

Fix:

• Checkout the sources from version control tool
• Open a console window
• Go to the project home
• (possibly: mvn install)
• mvn eclipse:eclipse
• Open Eclipse
• File > New Project > add the name > check "create project from existing tool" > Finish

And it’s over!