We’ve received a large number of questions related to yesterday’s announcement of Android Studio, and we’ve decided to compile the answers in a FAQ post.
Where do I get Android Studio?
Android Studio is available for download at the developer.android.com site.
Is Android Studio a fork of IntelliJ IDEA?
No. Android Studio and the Android plugin for IntelliJ IDEA are built from the same code, and all of the changes in Android Studio are, and will continue to be, available in IntelliJ IDEA releases.
When can I get the Android Studio features in IntelliJ IDEA?
The EAP of IntelliJ IDEA 13, which includes all of the Android Studio features except for the redesigned new project wizard and the App Engine cloud endpoints integration, is available now. The remaining features are going to be integrated in the coming weeks.
Will the new features of Android Studio be available for users of IntelliJ IDEA 12?
No. The new features (especially the Gradle support) depend on the major changes that were done in the version 13 platform, and we do not have any plans to backport them.
If I’m already a user of IntelliJ IDEA, do I need to switch to Android Studio for Android development?
No. Android Studio is focused specifically on Android development and provides streamlined environment and project setup, but otherwise all of its features are available in IntelliJ IDEA.
If I rely on features that are only available in IntelliJ IDEA Ultimate (such as additional version control plugins), will I be able to use Android Studio?
No, these additional features will not be available in Android Studio. You should continue using IntelliJ IDEA Ultimate.
Are Android Studio projects compatible with IntelliJ IDEA?
Yes, the two IDEs use the same project format.
Is it planned to support NDK development in Android Studio or IntelliJ IDEA?
We have recently announced that we’re starting work on an IDE for C++, and we plan to eventually support NDK development as part of that effort. As for NDK development support in Android Studio, Google hasn’t announced anything so far.
Where do I report bugs?
If you’re using Android Studio, please report bugs to the AOSP issue tracker. IntelliJ IDEA issues, as before, should be reported through YouTrack.
Feel free to ask other questions and provide the feedback here and on our discussion forum.
That's an interesting move: Google announced to choose IntelliJ IDEA for the new Android Studio IDE.
The guys are not dumb - if they do such things, they have good reasons. I never had pleasure to use Android plugins for Eclipse, so I can't really judge if it was good or not...
But what does it mean for Eclipse? Is Eclipse not good enough for Google Android developers?
Would be interesting know what are the real reasons to leave Eclipse land for IntelliJ IDEA adventure.
Here are few candidates from me (just in random order):
Yep Google, I'm disappointed Eclipse user too.
Today we have exciting news to share with all IntelliJ IDEA fans who eagerly wait for the new features to appear in their favorite IDE. Almost six months before the official release we are happy to announce the early preview of IntelliJ IDEA 13, codenamed Cardea, which scheduled for release in December of 2013.

We believe that making perfect tools for developers is only possible when listening to feedback from the community. That’s why we are very much looking to hear from everyone about IntelliJ IDEA 13.
Most of the new features in this preview are about Android development support, and cover the new functionality added in Android Studio. Of course, everyone will find something tailored especially to their needs:
Project Configuration
Code Editor
Layout Editor and Preview
Integrated Tools
Also, if you want to take a look at the source code and the changes, we’ve opened a new repository browser for IntelliJ IDEA Community source code.
Feel free to share your feedback on our discussion forum and report bugs to the issue tracker.
Develop with Pleasure!
We keep saying how IntelliJ IDEA is the most intelligent IDE. This is close to obvious for all who use it every day, but there are still a lot of people out there who aren’t aware of its exciting features which make development so much more productive. That’s why we decided to create a 30-day guide helping the new users (coming from other IDEs or just the beginners) to get a quick start with IntelliJ IDEA and learn how to use its top features for more efficiency.
The guide will include 30 articles featuring different aspects of the IDE, for each day of the trial period for IntelliJ IDEA Ultimate, our flagship IDE for polyglot development.
We are going to publish the new articles every few days on the official website. Each article will be accompanied with a post here with highlights on the trickiest features described in the article.
User interface for higher productivity
Today we will start with the user interface. By default, IntelliJ IDEA shows you the navigation toolbar, tool window bars and the project view. This is the minimum set of what you can use to navigate around the project files and developer tools.
The navigation bar can be hidden to bring more space for the editor. The tool window bar can be also hidden by clicking the icon in the left bottom corner.

If you want to open a tool window when the tool window bar is hidden you can press Alt (Cmd for Mac) twice.
When you hide everything you don’t need, the IDE looks just like a text editor, a very powerful one at that. You can always maximize the editor by pressing Shift + Ctrl + F12 (Shift + Cmd + F12 for Mac).
Multiple windows
If you want to work with some files in a separate window, just drag the editor tab out of the window and the IDE will detach this tab into a window. You can easily drag your tabs from one window to another.

The complete article about the user interface in IntelliJ IDEA can be found here.
Stay tuned for more articles soon, and develop with Pleasure!

As you might know the fourth annual Scala Days conference is held this year in New York on June 10th-12th. This event brings together developers from all over the world to share their experiences and new ideas around creating applications with Scala, Akka and Play.
We are exciting to announce that IntelliJ IDEA team joins Scala Days 2013 and will present own session “Scala Developer Tools in IntelliJ IDEA: SBT, Play and Scalate“.
In this presentation we will showcase some of the IDE’s trickiest features that help developers to be more productive, and will provide a brief overview of IntelliJ IDEA’s plugin infrastructure for Scala development, including support for SBT, Play Framework and Scalate.
Be sure not to miss our session on Wednesday, June 12th from 11:15 - 12:00.
At our booth you will be able to learn more from our team about support for Scala, which is available for free in IntelliJ IDEA Ultimate and IntelliJ IDEA Community Edition. Our team will be happy to have a conversation and answer your questions.
See you there!
Woohoo! For the third year in a row, the IntelliJ IDEA team will participate in the Developer Sandbox at Google I/O 2013. We are thrilled to receive an invitation from the Google Android team to show off our Android support inside the IDE.
We’ve said it before and we will say it again: “This is the kind of event where if you’ve been there once, you don’t want to miss the next one!”
We will have an awesome team on location including JetBrains CTO, Dmitry Jemerov, ready to listen, chat, answer your questions and in general have a great time at the event.

If you are attending the conference, stop by our booth in the Android section. We’ll be glad to chat and to tell you what’s coming.
Aside from Android, we are happy to share with you that the WebStorm team was also invited to the Developer Sandbox by the Google Chrome team for our great integration with Chrome DevTools. The guys will be showing Live Edit and other cool features of WebStorm 6.
While the WebStorm team will be at a different booth than IntelliJ IDEA, we encourage you to stop by and say hello to them too.
We’ve just rolled out another update for IntelliJ IDEA 12.
Version 12.1.3 contains a number of bug fixes and usability improvements in many areas and features of the IDE. For a complete list of changes see the Release Notes page.
New version is available for download from the product web site or you can install a patch using “Check for updates” function inside the IDE.
IDE’s are no doubt important… but do not forget that it’s Mother’s Day this Sunday!
Develop with Pleasure!
There is new EAP build of IntelliJ IDEA 12.1.3 available for download. The complete list of changes can be found in Release Notes. We welcome your feedback on IntelliJ IDEA 12.1.3 EAP at our discussion forum and with bug reports in the issue tracker.
Develop with Pleasure!
We are excited to announce that IntelliJ IDEA 12.1.2 is available for download. This is the second update for IntelliJ IDEA 12.1 with a new bunch of enhancements and bugfixes.

The full list of changes in the update can be found in Release Notes.
If you are already running IntelliJ IDEA 12.1 right now, call Check for Updates… action and the IDE will download the update automatically.
Develop with Pleasure!
We are looking for Eclipse based technologies which would allow us to:
For sure we can do this with standard PDE/JDT but the main point is here "PDE development without Eclipse/Java knowledge".
What I'm roughly thinking so far would be some DSL on xbase at the beginning of the pipeline and some "plugin builder" at the end. But for sure there are billions people who already did something similar - and I would like to know about your experience with frameworks/libraries/tools which are most suitable for the task above.
Any helpful hints are welcome.
As we mentioned before the latest release of IntelliJ IDEA comes with better management for line separators.
The information about the line separators type used in the currently opened file is available now in the status bar.
Not a big surprise that it is possible to change the type of line endings for the current file via this control.
You can also perform a bulk change. Just select a target file or a directory in the project view and choose new separator via Main Menu → File → Line Separator.
Please feel free to share your feedback on this feature on our discussion forum or submit bug reports to the issue tracker.
Develop with Pleasure!
Two bits of exciting news for IntelliJ IDEA’s users today. The first one is that the upcoming release of IntelliJ IDEA 12.1.2 is available for early preview. The new build brings many enhancements and bugfixes.
The full list of changes can be found in Release Notes.
And the second exciting news is that you can get 50% OFF if you buy IntelliJ IDEA until the end of Earth Day Celebration. Hurry up!

As always you are welcome with your feedback on IntelliJ IDEA 12.1.2 EAP at our discussion forum and with bug reports in the issue tracker.
Develop with Pleasure!
It’s the time of the year again when the Eclipse Foundation calls all committers to cast their votes. Each year members of the board are elected for representing two very important groups of the community at Eclipse!
IMO this is one of the best ways to allow the community to participate and make its voice heard. Topics such as committer tools (Git, Bugzilla & co) and improvements to the IP process (such as parallel IP, incubation) are discussed at the board resulting into plans/directions for the Eclipse Foundation to implement.
My vision and my goals for 2013 are available online on my candidate page. If you have any questions please don’t hesitate and send them to me.
Two days ago webmaster sent out an email to all committers with voting credentials.
Please don’t miss this chance to make your voice heard and vote now. I would be pleased to receive yours.
![]()
Thanks!
For the first time ever I’ll be attending JavaOne next week. I’ll speak together with Shaun Smith from Oracle about Polyglot Persistence with EclipseLink JPA.
Polyglot Persistence: EclipseLink JPA for NoSQL, Relational, and Beyond
(Tuesday, Oct 2, 3:00 PM – 4:00 PM – Parc 55 – Cyril Magnin I)
Yes, there will be a demo running EclipseLink on Gyrex OSGi connecting to MongoDB.
I’m currently in Frankfurt waiting at the gate. I’ll arrive Friday night in San Francisco and will stay till next Friday (Oct. 5th). If you are around, interested in a chat (about runtimes, OSGi, other stuff that matters) and/or want to grab a beer please ping me!


Code size is increasing quite linearly, with a noticeable boost in size midway though 2009.

Summary: I’ve loved my last five years at the Eclipse Foundation. It’s time for me to move on. I’m going to Oracle to work on OpenJDK and other things.
The longer version:
It was over five years ago that I joined the Eclipse Foundation. I had just finished an MBA and was working at Oracle in a well regarded technical swat team in Java middleware. The Eclipse Foundation had launched in my hometown of Ottawa, and here I was, eager to learn about open source, the rapidly changing business model of enterprise software, ecosystems and to do something fresh. So I took advantage of this unique opportunity and convinced Mike that I should help run the Eclipse Foundation membership.
My 5+ years at Eclipse were incredibly rewarding both personally and professionally. I’ve made countless new friends and acquaintances from all the organizations that I’ve had the pleasure of working with. I was privileged to be working directly with many great thinkers in the software industry, and learning about how big ideas, like Eclipse, happen.
All the staff at the Eclipse Foundation that I’ve ever worked with have been high performing and maniacal about driving the Eclipse Ecosystem forward. I believe the Eclipse Foundation has done great things by helping hundreds of organizations keep pace with evolving business models and to make available a lot of high value free software. I leave the Eclipse Foundation with complete respect and admiration for every single person there. They do incredible things with limited resources and many constraints. I will continue to be a fierce advocate and supporter of all things Eclipse.
I believe strongly that we are at the beginning of a renaissance period for Java. Once again there is real investment and participation in Java. There is a roadmap that has an immediate impact with Java SE 7, and plans far into the future – with many organizations and stakeholders keen to see it happen. Moreover, I’m convinced that once a world class modularity solution becomes part of core Java, we will see even more and faster innovation. It means great things from the biggest cloud, to the smallest device.
I have a matching skill set to help Java evolve for the decade to come, so I decided to jump at an opportunity to join the Oracle Java SE team. I will be working with OpenJDK and other things. I am truly proud to be working with folks like Dalibor Topic, Henrik Staal, Mark Reinhold and Adam Messinger.
The team I’m on has one simple mandate – keep Java the number one computing platform in the world. Period. I start May 9th, and will post some pointers when I land.
- Don
I'm happy to report that I've been given company approval to port the relevant components of our Flex data binding library back to Eclipse Data Binding.
I haven't started the actual port yet--there are still some concepts on the Flex side that are not a perfect match to Java and existing idioms in Eclipse Data Binding. You'll see what I mean.
To avoid conflating the port to Java with the general API I'm going to just present what the Flex API looks like.
Bind.from(source, "foo")
.to(target, "bar");
This binding watches the source.foo property, and writes the new value to target.bar each time a change it detected. Now add some validation and conversion magic:
Bind.from(source, "foo")
.validate(Validators.stringToNumber)
.convert(Converters.stringToNumber)
.validate(Validators.greaterEqual(0))
.validate(Validators.lessThan(10))
.to(target, "bar");
Here we've added several additional steps in the pipeline.
Now suppose our binding is misbehaving somehow, and we want to troubleshoot. We can add logging steps to the pipeline in between the other steps so we can see exactly what is going on:
Bind.from(source, "foo")
.log(LogEventLeven.INFO, "source.foo == {0}")
.log(LogEventLeven.INFO, "validate {0} is a number")
.validate(Validators.stringToNumber)
.log(LogEventLeven.INFO, "convert {0} to a number")
.convert(Converters.stringToNumber)
.log(LogEventLeven.INFO, "validate {0} >= 0")
.validate(Validators.greaterEqual(0))
.log(LogEventLeven.INFO, "validate {0}
.validate(Validators.lessThan(10))
.log(LogEventLeven.INFO, "set target.bar = {0}")
.to(target, "bar");
(In Flex, string formatting is done with {n} format instead of the %s syntax which Java inherited from C. The log statement passes the values in the pipeline as additional arguments which you can reference in log statements.)
These log steps are a real lifesaver for tracking down and squashing bugs in your binding code.
If you've already worked with Eclipse Data Binding you may have noticed something else: you are no longer constrained to the standard data-binding pipeline. You are free to add steps in the pipeline wherever you like and in any order you like.
Next up is two-way bindings. The bind class provides a twoWay method which connects two bindings to the other one's starting point:
Bind.twoWay(
Bind.from(source, "foo"),
Bind.from(target, "bar") );
is equivalent to:
var lock:Lock = new Lock();
Bind.from(source, "foo")
.lock(lock)
.to(target, "bar");
Bind.from(target, "bar")
.lock(lock)
.to(target, "foo");
Notice that each binding has a "lock" step in the pipeline. Only one binding can hold a lock at a time. This solves the common infinite loop problem:
Since only one binding can hold the lock at a time, this is what happens instead:
You should never add the same lock more than once to a single binding, since that would guarantee that the binding will never run.
Two-way bindings can use validations, conversions, logging, locks etc just like regular one-way bindings (since two-way bindings are just two one-way bindings wired up to eachother):
Bind.twoWay(
Bind.from(person, "birthDate")
.convert(Converters.dateToString(dateFormat))
Bind.from(heightText, "text")
.validate(Validators.stringToDate(dateFormat))
.convert(Converters.stringToDate(dateFormat))
.validate(Validators.lessEqual(now))
);
We usually leave out the validations in the model-to-UI bindings. It's usually only important to apply validations when you're copying data back from the UI to the model, to make sure domain constraints are satisfied, such as ensuring that a birth date occurred in the past.
And now for my favorite part: binding from multiple sources, to multiple destinations. Raise your hand if you have ever had to wire up a UI form like this:
Is there a foo? (o) Yes ( ) No -- fooRadioGroup
Enter bar: ____________________ -- barText
Requirements:
Requirements 1 and 3 are easy:
var fooLock:Lock = new Lock();
Bind.twoWay(
Bind.from(model, "foo"),
Bind.from(fooRadioGroup, "selectedItem"),
fooLock); // explicitly provide the lock, see more below
Bind.from(fooRadioGroup, "selectedItem")
.to(barText, "enabled");
Requirements 2 and 4 are kind of related to eachother. The model-to-UI binding is simple enough: just write the value straight across:
var barLock:Lock = new Lock();
Bind.from(model, "bar")
.lock(barLock)
.to(barText, "text");
However the inverse binding (UI-to-model) must also take fooRadioGroup.selectedItem into account to decide whether to write back barText.text (if Yes is selected) or null (if No is selected).
The Bind class has another trick up its sleeve:
Bind.fromAll(
Bind.from(fooRadioGroup, "selectedItem")
.lock(fooLock),
Bind.from(barText, "text")
)
.lock(barLock)
.convert(function(foo:Boolean, bar:String):String {
return foo ? bar : null;
})
.to(model, "bar");
Look closely. The binding pipelines that we pass to fromAll(...) become the arguments, in the order they are provided, to the converter and validator functions further down the pipeline. The first pipeline is from fooRadioGroup.selectedItem and therefore that boolean value is the first argument to the converter. Likewise, the barText.text pipeline is provided second, so that string value becomes the second argument to the converter.
The converter takes multiple values but returns only a single value. This is where those values get coalesced into a single value that we can write to the model--in this case, a String value or null.
The outer pipeline adds a locking step on barLock, which is expected since we need to prevent infinite loops between the last two pipelines. However we are also locking on fooLock, on the first of the inner pipelines. We had a problem with our bindings overwriting values in the UI depending on the order things were initialized.
It turned out that without that lock, if a new model object was set, then the foo binding would fire first. Thus model.foo was copied to fooRadioGroup.selectedItem. But that would trigger our last binding to execute, so if the new foo value was false, then the last binding would override anything in the text box and set null on the model.bar field, before the model.bar => barText.text binding had a chance to execute!
A good rule of thumb is that any time you need to bind from multiple sources, you should make sure to create a lock to share between all the bindings to relate to the same field in the model.
Obviously there are several concepts that will have to be adapted to work elegantly with our existing APIs. Realms are a missing piece (Flex is single-threaded so we didn't even have to consider it). Also we would want to try to retrofit the existing binding classes to use this new API transparently, like we did with the transition from custom observables to custom properties.
So there you have it. This is my current vision of what Eclipse Data Binding should evolve toward.
Comments?