Next Generation Eclipse IDE - What do you think?

General Discussion
1

The future of Eclipse is betting on the cloud:

https://eclipse.org/che/

I know we have quite a few Eclipse users here, so, what do you think about this new development? Does it make you excited about the future of Eclipse, or is this not what you were hoping for?

Personally - speaking merely as a trend-watcher of open source business and ecosystems but not an avid IDE user - I’m pretty excited about this. It’s something else entirely. Instead of pondering “SWT vs SWING” and nitpicks like that, the developer must consider whether a cloud-based centric environment makes sense for their workflow.

It might also mean that they can come up with some new business ventures so that working on improving Eclipse can actually be a viable livelihood, which is the only way they can compete with the likes of JetBrains in the long term.

2 Likes
2

I use the Eclipse IDE at work, all the time, and at home, for hobbies just as to program for the jMonkey engine… I don’t like the Netbeans IDE: it’s nothing personal, it’s just 12 years of “marriage”, working most of that time for the Big Blue, that is the eclipse backer: they would use eclipse even for toilet paper if they could find an auto-cleaning tablet.
And I think that to develop close to the shared repository only makes sense: the ones who lost some days worth of work because their computer crashed just before commiting something can vow for that.
Another important advantage of this is that it usually takes some time for each developer to configure their workspace to project standards… with the repository and ide just there, one authorization away, would mean lots of headaches less…
Now, for the possible downside of this: I haven’t tested it yet, but to program in the cloud means certainly that we must be connected to the cloud infrastructure all of the time, so I can’t just take the laptop on vacations to the middle of the amazonia rain forert and come back with a grown white bear and a kick*ss code in 2 stone tablets, two weeks later… Well, unless they have made very strong “offline” features…
And some infrastructures, that have many layers of access that can go wrong, such as connect to the vpn, then connect to machine 1 via socks, and to machine 2, and log to this firewall, that firewall, that other firewall, and yet that other firewall, (does anyone remember the Get Smart opening when I say this?) to reach the development environment… brrr… it gives me the creeps…

2 Likes
3

currently I am working as full timer Developer, following the standard procedure of having IDE, and source control for management, even the procedure is systematic we still face glitches and issue in case of setup new environments, Dockers going to decrease the environment setup time.

another use case if find it useful, I am developing my game, as hobby so some times i need to access code from my laptop, or PC or even my wife or mom laptop if I have any spare time i work with my game. (BTW jmonkey is more addictive than facebook)

So the Idea of cloud based IDE, I find it better than what I am doing now, that I duplicate the environment and synchronize with git repository on all machines except my mom laptop :smile: . because this new use case, it is not multiple developer, it is single developer from different locations

4

You are working for Big blue too :smile: welcome

5

I think we should take the term “cloud based” a bit more lightly. Reading the documentation for Che has me understanding it like this.

  1. You install a binary on your machine of choice, could be the same machine you use to develop or not.
  2. You open your browser on another machine and point it to the url of the machine with the binary.
  3. Your Eclipse Che IDE downloads (HTML and Javascript) and then opens in your browser.
  4. Creating a new project/workspace will fire up a docker container on the server and allow you to do your development.
  5. You develop and during that time your browser uses HTTP and REST to communicate with the Che backend.

The nice thing here is that you could install it on a server at home or on your more powerful desktop machine and then simply grab the laptop and sit somewhere else and just use the browser and let the desktop machine do all the compiling (if I understand correctly).

Downsides are of course when you want to be somewhere physically different (another network) from the server and you have no access to it, not sure how that would work. The other thing is that if there is a high latency you might not get that instant feedback of what’s wrong in your code.

It’s a very interesting concept though as you could have thin client machines or even just a Chrome Book and then offload the computation to a single powerful machine known as single point of failure :smiley:

3 Likes
6

VPS is an option here, to access it through internet, or some frameworks creator could provide their own che cloud service

I agree with you about the latency not sure about it yet.

7

Worst case is that you’d have to run the binary on your laptop as well, it’s still just an IDE like any other in that fashion. Just trying to figure out who will benefit from Che the most. Bigger businesses maybe, as they could use their central server hardware. The development of Che GUI is bound to be faster as well as it’s made in HTML and Javascript. Would be neat to look into creating a JME plugin for this :smiley:

8

and integrate with cloud gaming service, to execute the builds like Nvidia Grid I am not sure how it works
if it feasible you still could develop games on chrome book in this case :chimpanzee_evil:

9

I’m one of the Eclipse users as well, since I started there and have used it ever since. This che version looks pretty awesome with this sort of visualstudioeque design. The cloud functionality is a good thing if it ends up working right, but I feel that it’s gonna be one of those things that I’ll never actually use because its easier to just pack up the whole IDE on a flash drive and be done with it.

2 Likes
10

Imagine a central JME world builder where several clients can be logged in at the same time and alter the world at the same time :smiley:

Building a project shouldn’t require any GPU power though I would think.

1 Like
11

BTW, I am playing with electronics from time to time, there is a technology called mbed, this is some sort of rtos to ARM based embedded system, what is interesting they have web based IDE, and after finishing you code a binary file downloaded to you machine, and upload it to your arm kit and it works.

https://developer.mbed.org/handbook/mbed-Compiler
the benefits here that you do not need to get the SDK for each kit, you select the kit you target from their portal.

Similar approach taken by phoneGap but they only take the build service it is based on Cordova cross platform SDK, for mobile app, phone gap provide a similar buid system for many mobile os, instead of having SDK in your machine.

not sure how game engines could take advantage of this, but the cross platform builds, and testing the code on different GPU’s could be an interesting use case as well.

Auto desk has tons of cloud based tools, starting from character creators, to electronic circuit simulators.

12

Heard that Zuckerberg? we won!
Too bad we skipped the part when we become billionaires…

That sounds awfully cumbersome
Now you have a web server even for the IDE…

13

Yeah, I just downloaded it, thought I could give it a go. It wants me to download and set up a docker machine first. Sod that, maybe some other time.

14

I also find it pretty interesting that they seem to have bypassed JavaFX completely (afaict). Isn’t this sort of thing one of the primary use cases for JavaFX? :chimpanzee_annoyed:

15

Possibly, unless their main priority is an IDE that will run in a browser which is sort of understandable.

16

Hi everyone. I am founder of Codenvy and project lead for Eclipse Che. It’s pre-alpha still, so be kind :slight_smile: We updated the home page so that if you build it, build it from the next generation branch. Some comments on objectives.

The goal wasn’t to use HTML. Our goal was somewhat different. When I started Codenvy, it was after I had a pretty bad experience with developer tools. I had been offline from programming for 7+ years and lost most of my skills.

When I tried to get current with maven, java, eclipse, tomcat, I was unable to get a simple program to compile.
I had a simple thought - it should be possible to let anyone anywhere contribute to any project without first installing software. you should be able to click a link and then everything you need is generated for you - the workspace, the projects in that workspace, the environments that power those workspaces.

Now, if you are on a desktop, you may want to wire in your existing IDE to integrate with that workspace. But if you are a product manager and just want to test some code, you don’t want to install anything. So a browser experience is necessary then.

Generally, we have never seen the browser experience as the replacement objective or substitute. But it is a necessary deliverable for those who do not wnat to bother with installing software first.

Codenvy takes Che and is working to provide this sort of no-install workflow around a concept we call factories. You start in a private anonymous screen, click a link and everything you need to continue working is there. Really hard problem - that is what we focus on commercially.

But at the core of it, we needed a portable workspace server that had a web IDE. We chose GWT for the development of the GUI because of the cross browser portability and performance optimization. It’s a brutal technology but we get a lot of nice optimizations. We have started some explorations to support Vaadin for dynamic reloading of widgets and have some partners who may help us with a pure JavaScript client, too.

We are embedding all of the language services within the machines that power the environments that the workspace is bound to. We use either localhost or docker depending upon your configuration. Since everything is within, the actual comms between browser and the workspace machine is limited. So you can get a pretty darn good expeirence. The file operations are localhost native, so we are able to process Java files with 50K lines at about the same speed that Eclipse or Netbeans does (minus the part of the file system being inside of the docker container).

4 Likes
17

It is doing a few things:

  1. Workspaces are quietly powered by environments, backed by machines which are docker or localhost. This enables each workspace to be isolated with a stack apart from others.

  2. We will also demonstrate workspace portability. You can move an entire workspace and all of its tools from Che to Che, or from Che to cloud. And the environment will continue to run identically in each location.

  3. We are running the full JDT and other language services inside of the machine. We wrap these with RESTful wrapper. And then it allows the browser to gain capabilities for maven, refactoring, and a variety of powerful intellisence, and it’s generally the same speed as localhost.

  4. You can then exec commands, debuggers, and ssh into the workspace machines.

  5. We have also done a project with Red Hat to enable your workspace environments to have the same docker container structure as production. We will shortly release a plug-in for OpenShift and Kubernetes that let’s projects move back and forth with limited configuration. Becuase they are both running on a common container architecture.
    While we can solve workflow problems in our distributed system, such as a workflow we call continuous development, we wanted to have a fully fledged desktop IDE to demonstrate that this could have the performance and security of other types of tools. So we are working to have this installation be very fast and lightweight.

  6. Finally, this packaging is installable offline as well. While it is a cloud IDE, you can run it as a desktop app. We will finish our electron packaging of it shortly to demonstrate this.

2 Likes
18

Thank you for stopping by and explaining all of this.
The main objective seems really solid.
I guess it makes more sense in an enterprise context where you would have servers setup for you and then, as a developer you could access your projects through the browser or a light client.

Though with that kind of architecture other problems arise. Like servers QoS, browser compatibility ( things can break from one update to another). Also for example in my company, If I go to the OPS and say, “you need to operate several new servers to host our IDE backend”, I’m not sure they are going to be enthusiastic.

19

I agree the servlet experience is pretty naff in Java and if you’re interested, Spring solved that one pretty nicely with Spring Boot :smiley:

I do like the concept behind Che, it’s an interesting problem to solve and I believe many big companies could benefit from it.

OPS not enthusiastic about operating servers need to hand in their resignation and then you get into DEVOPS :wink:

20

Codenvy and Che are solving slightly different problems, but they are related. Che is solving the workspace portability issue. That is a hard problem because the workspace is bound to an environment, so you have to make environments portable, too.

Codenvy is solving a problem related to making teams more agile by solving developer bootstrapping, distributed workspace security, and modernizing legacy processes.

Che is meant to be a desktop installation. We will have an electron packaging for it soon. You can install the entire system as a desktop app and it runs the server behind the scenes. When you launch the desktop client, it runs within a chromium window and handles the server activities behind the scenes. It’s how slack windows client works.

With Codenvy, it is primarily intended for enterprises. It does require the system to be installed on their own servers. You can start with one server or scale to 1000 servers. Why do this?

  1. Security. Lots of large enterprises want to manage workspaces and control where code is cloned to.
  2. Agile flows.

with codenvy, have an automation ability that we call factories that generate workspaces similar to the way that puppet can generate servers - from a configuration. These factories are URLs that integrate with Jenkins, Jira, Github, etc. Now, developers can start within a Jira issue, identify an issue to work on, an then we embed factory links into those issues. The developer clicks a link, gets a branch, and a dedicated worksapce that is preconfigured perfectly to work.

They can do the work either in the workspace that we provide or in their desktop IDE.

As the branch evolves: commits, merge, etc. The workspace definition is updated automatically and the Factory is kept current. Other users like QA or PMs can also go into Jira and click the same link to get their own workable environment.

This sort of flow automation is big for enterprises, so we get most of our business that way.

2 Likes