the key issue is not the UI changes

the key issue is how the IDE interacts with your project

the fine details of how the code in the IDE interprets the code in your project and your build files

this issue does not exist in Inbox, for example, because the data resides on Google servers and its model is entirely under Google’s control

in IntelliJ, we have to interpret data created by our users, stored in text files in often very loosely defined formats

and as the product evolves, the interpretation changes

and it happens very often that the previous version of IJ either didn’t validate something or managed to somehow validate it without producing errors, and the new version starts reporting new errors

for EAP builds, people are OK with that - they complain and we fix stuff and it starts working

for major upgrades, it’s also somewhat expected - people plan for IDE version upgrades, and allocate time for that

but if every six weeks you’re starting to get new error reports in some part of your project that was previously fine, this gets very annoying very quick

Hello! In my code I had used object literals that reference themselves. Idea suggested those to be replaced with Lambdas. Is there a way to reference this lambda inside of it (Idea don't touch

this

and creates broken code)? Code sample:

object : Runnable {
            override fun run() {
               doThings(this)
            }
        }

Resulting lambda:

Runnable {
  doThings(this)
}

I had same case on Android with posting delayed runnables to handler in loop, the only UGLY resolution I’ve found:

var runnable: Runnable
runnable = Runnable {
    doThings(runnable)
}

btw. it fits #C0922A726

kinda related https://youtrack.jetbrains.com/issue/KT-10202

@yole: Appreciate the explanation. I've used the EAP versions at times either because I just like the latest and greatest and am willing to deal with being on the cutting edge or because it supports some feature or plugin I must have. I think Jetbrains has figured out a good system for the release of their products.

@yole: Your argument also holds for web browsers. HTML is tricky, messy, text based etc. Still, they manage. A combination of canary/beta/etc streams and running percentage-experiments helps them find bugs and issues before the code gets pushed to everyone

I posted this in the wrong channel, actually.

one big advantage of HTML is that Web pages tend to be public

so it’s easy to collect as many test cases as you like

and the result of processing said HTML is usually well-defined (you render HTML, you get an image)

so it’s easy to build regression tests

(yeah, I know about JS, animations and stuff)

and applications using framework X, for almost any value of X, tend to be closed-source and not accessible to us

so we build our support based on a very limited number of examples, covering a small percentage of things that people actually do with the framework

well, there are private websites too. perhaps even more than public. the chrome team crawls the public web using large numbers of cloud VMs. i suppose the equivalent would be to have a VM farm on AWS that loads every Java github project or every project that has a .idea directory to see what happens

public websites are generally representative of what private websites look like, which is not the case for enterprise apps simple smile

also, unlike a random Web site, a random enterprise project is likely to have a complicated set up process, and won’t build if you simply pull a single repo off github

Maybe google should switch to an EAP model with less frequent stable releases. I haven't heard any reasons why the google release pace is any better.

don't know if it's better, but I personally like tinkering with the latest features