109 comments

Wow! Some of this is REALLY cool, even to a cynical angry jaded bitter old man like me!

Does this mean that IDEA will now have a central server component, that all instances can connect to to perform some of this stuff? (CI, serverside analysis, etc)

If this is the case, I'm hoping you make sure that offline support works flawlessly, given how many people code on the move.

As the developer of the tesng plugin, I think putting too many resources into junit4 support is a bit early, given that it's not released yet and is being developed in secret. Much nicer instead to refactor the existing junit support to make it more reusable.

0
Avatar
Permanently deleted user

This all looks cool although I'd like to see more focus on editor and
refactoring, as they are and will always be the core of modern Java editing. I
also think enhancement of nullable/notnull would be important for productivity
(special highlighting for nullability of a value in the editor, completion
popup, ctrl+p, etc).

You should make sure the continuous build and build server integration is
implemented 100% using OpenAPI. We use a huge custom build and continuous
testing platform and we're not going to switch to your system, but we would
probably like to use the integration and we would probably be willing to develop
custom plugin for it.

It's also important to us to integrate code reviews. We use perforce command
line tools for this now, but we'd like to use IDEA for it.

0
Avatar
Permanently deleted user

Hello Hani,

Wow! Some of this is REALLY cool, even to a cynical angry jaded bitter
old man like me!

Glad to please you :)

Does this mean that IDEA will now have a central server component,
that all instances can connect to to perform some of this stuff? (CI,
serverside analysis, etc)

Quite right.

If this is the case, I'm hoping you make sure that offline support
works flawlessly, given how many people code on the move.

Sure. If I recall correctly these kind of things are known to be the most
significant problem with stuff like maven so we'll try to avoid stepping
in their shoes.

resources into junit4 support is a bit early

Yep, that's true. But that will most probably be released before Demetra
release so we'll experience a great pressure on that. On the other hand having
another test runner developed internally we'll get an infrastructure open
enough to plug TestNG more flawlessly as well, right?

-


Maxim Shafirov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


0
Avatar
Permanently deleted user

Hello Keith,

more focus on editor and refactoring

No doubts we'll do it. It's just too obvious and there too many small items
there to mention in road map.

You should make sure the continuous build and build server integration
is implemented 100% using OpenAPI.

I'm not sure any particular API no matter how full is that will be able to
carry out everything possible here.
If you'd describe in a few words what your custom build is we'd try to make
sure it can embed easily into our build system.

It's also important to us to integrate code reviews.

Well, that's fine but we're lack of real use cases here thus it's hard to
decide what exactly this feature should do.
Again, it would be nice to hear from you on this.

-


Maxim Shafirov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


0
Avatar
Permanently deleted user

Keith Lea wrote:

This all looks cool although I'd like to see more focus on editor and
refactoring, as they are and will always be the core of modern Java
editing.


+1

I think however that basic enhancements of functionality and usability are covered, even
though they're not explicitly listed.

I also think enhancement of nullable/notnull would be important for
productivity
(special highlighting for nullability of a value in the editor, completion
popup, ctrl+p, etc).


+10

This stuff is so extremely cool that there should definitely be some automated help for
introducing and maintaining those annotations based on code analysis of what can be null,
can not be null and must not be null.

http://www.jetbrains.net/jira/browse/IDEA-2002

You should make sure the continuous build and build server integration is
implemented 100% using OpenAPI. We use a huge custom build and continuous
testing platform and we're not going to switch to your system, but we would
probably like to use the integration and we would probably be willing to
develop
custom plugin for it.


+1

I also don't think a proprietary build system will have any chance. Most build setups are
wickedly complicated using Ant, Maven, etc. and can not be moved to something else without
major hassle. This absolutely has to be pluggable.


Sascha

0
Avatar
Permanently deleted user

Hello Sascha,

Most build setups are wickedly complicated using Ant, Maven, etc. and

First of all we do support plain ant builds and will most probably support
maven.

-


Maxim Shafirov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


0
Avatar
Permanently deleted user

>> I also think enhancement of nullable/notnull would be important for
>> productivity (special highlighting for nullability of a value in
>> the editor, completion popup, ctrl+p, etc).
>

+10

This stuff is so extremely cool that there should definitely be some automated help for
introducing and maintaining those annotations based on code analysis of what can be null,
can not be null and must not be null.


+10 from me too. And there are probably quite a few other things that
can be done in this area to improve static inspections. For example,
when using lazy initialization there can be fields and variables that
can only go from null to non-null, never the other way around. Having
an annotation for this would mean getting rid of a number of false
warnings. Nullness of array elements or container contents is also not
covered in the current version.

0

Maybe have code reviews work like code coverage (see the clover plugin), where it's possible for a reviewer to mark off bits of code as being reviewed, and then having a toggle to show review bars.

Another feature that I've been hoping for since 3.0 is incremental background compilation. IDEA already knows so much about the structure of sources, so why not just go the final step and spit it out into bytecode on the fly?

0
Avatar
Permanently deleted user

Wow! Incredibly ballsy. If you can even pull 75% of this off, it'll be industry-changing. In particular, stuff like

>Code Coverage Integration
>Incremental test run. Rerun only tests that execute changed code
>Project wide error highlighting
>Separate dependencies for module interface, implementation, and test parts
>Instant messaging including code pointers,
>P2P sources sync

should truly rule.

Embedded languages API: XML tag contents and attributes, java String literals


All your little languages are belong to us.

My eyes glazed over on Project portal until I saw

>Share project-wide configurations
>Server-side code analysis results

You wouldn't happen to be looking for a metrics tool to go with that? Managers love pretty numbers on web sites!

And finally, gloriously

>Global Inspection API

If you'll all excuse me, I think I need a cigarette.

--Dave Griffith

0
Avatar
Permanently deleted user

Hello Hani,

background compilation.

Indeed, nothing prevents us from implementing this but performance considerations.
As we're planning to implement "project wide error highlighting" feature
we'll be forced to solve those performance issues that we'll most probably
have background compilation in Demetra.

-


Maxim Shafirov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


0
Avatar
Permanently deleted user

Maxim,

>> Most build setups are wickedly complicated using Ant, Maven, etc. and

First of all we do support plain ant builds and will most probably
support maven.


That's great to hear, but the roadmap does not really imply that. I made that assumption
because currently IDEA's build and packaging lacks a lot of flexibility and some features
like the deployment of j2ee modules fundamentally rely on it.

Sorry for jumping the gun on this.

Cheers,
Sascha

0
Avatar
Permanently deleted user

Hello Sascha,

but the roadmap does not really imply that

Pardon, I'll correct this.

-


Maxim Shafirov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


0
Avatar
Permanently deleted user

Very interesting.

What about extending support for JavaScript?

What about integrating 'going-back' technology so that when a problem
happens one can go back (there's a product that does that, don't
remember what is its name).

The server component is surely a very important piece of Demetra, though
I am concerned it will add complexity to managing IntelliJ and offline
work, which is why it may be a good idea to support using IDEA even
without the server component available (I'm sure you thought about all
of that, so disregard if so).

Thanks for sharing,
Amnon

0
Avatar
Permanently deleted user

Hello Amnon,

What about extending support for JavaScript?

It's there on the last line of the map.

What about integrating 'going-back' technology

Would you please explain in a bit more details. I'm affraid I do not follow.

it will add complexity to managing IntelliJ

We sincerely hope for exactly opposite!

-


Maxim Shafirov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


0
Avatar
Permanently deleted user

What about integrating 'going-back' technology

>Would you please explain in a bit more details. I'm affraid I do not follow.

Omnicore's "Back in Time" debugger, perhaps? Technically very cool, but I've never heard anyone say it was a killer app.

After the improvements in Irida, it looks like they've decided that the debugger is basically completed functionality. Can't say I disagree.

--Dave Griffith

0
Avatar
Permanently deleted user

Hello Maxim,

MS> can be found at
MS> http://www.jetbrains.net/confluence/display/IDEADEV/Demetra+Roadmap

AWESOME! personally I can't wait to use the continuous testing and the seemingly
MUCH improved testing framework support.

Way to go.

R


0
Avatar
Permanently deleted user

Dave Griffith wrote:
>>What about integrating 'going-back' technology
>>Would you please explain in a bit more details. I'm affraid I do not follow.


Omnicore's "Back in Time" debugger, perhaps? Technically very cool, but I've never heard anyone say it was a killer app.

After the improvements in Irida, it looks like they've decided that the debugger is basically completed functionality. Can't say I disagree.

--Dave Griffith


Yeah, I guess you're right. Can't say I ever needed it so much even to
trial it, though I came close a couple of times :)

Amnon

0
Avatar
Permanently deleted user

Maxim Shafirov (JetBrains) wrote:

Hello Amnon,

>> What about extending support for JavaScript?


It's there on the last line of the map.

Oops, I guess I looked for it in the wrong place.

>> What about integrating 'going-back' technology


Would you please explain in a bit more details. I'm affraid I do not
follow.

What Dave G says is correct, I did mean that.

>> it will add complexity to managing IntelliJ


We sincerely hope for exactly opposite!

------------------
Maxim Shafirov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

0

Back in time is handy! Another nice addition to the debugger would be being able to set a breakpoint in the middle of a line, vs a specific line, for example:

blah.doSomething(new Foo())

I'd like the breakpoint to be set at 'doSomething', which means that when it's hit, new Foo() has already been called.

Note that this IS different from just setting a breakpoint at doSomething in the Blah class, since that would be called for every invocation, not just when new Foo() is passed in.

0
Avatar
Permanently deleted user

Maxim Shafirov (JetBrains) wrote:
>> more focus on editor and refactoring


No doubts we'll do it. It's just too obvious and there too many small
items there to mention in road map.


Cool, I'm excited about it

>> You should make sure the continuous build and build server integration
>> is implemented 100% using OpenAPI.


I'm not sure any particular API no matter how full is that will be able
to carry out everything possible here.
If you'd describe in a few words what your custom build is we'd try to
make sure it can embed easily into our build system.


I don't know technical details about most of the build system, but I know it is
old, actively developed & supported, and complex. As long as the user can have a
similarly friendly and useful experience with our build system as with your
build server, I will feel good about it. I plan to stay involved in these
features and let you know how it looks as things develop.

>> It's also important to us to integrate code reviews.


Well, that's fine but we're lack of real use cases here thus it's hard
to decide what exactly this feature should do.
Again, it would be nice to hear from you on this.


No code can be submitted here until a Perforce CL is created, then it must be
reviewed and approved. Here, you choose who you want (or need) to get approval
from, and an email is sent to them. They run some command line diff tools to get
a basic idea of how the code works. When you receive an approval email, you
commit using p4 commit -c xx -a xx.

1. The code to be reviewed is never built or run or even checked for syntax
errors because we use a simple diff tool and not IDEA. It would be wonderful for
IDEA to be able to treat the code as real code, allowing navigation, etc.

2. Communication is not its best. Integration with the new idetalk stuff would
be cool and useful, but probably only used 10% of the time here. Usually we walk
over and ask about something, or for more structured feedback we send an email.

0
Avatar
Permanently deleted user

Sascha Weinreuter wrote:
>>You should make sure the continuous build and build server integration is
>>implemented 100% using OpenAPI. We use a huge custom build and continuous
>>testing platform and we're not going to switch to your system, but we would
>>probably like to use the integration and we would probably be willing to
>>develop
>>custom plugin for it.


+1

I also don't think a proprietary build system will have any chance. Most build setups are
wickedly complicated using Ant, Maven, etc. and can not be moved to something else without
major hassle. This absolutely has to be pluggable.


I think a proprietary build system that allows for hacky shell scripts and
collections of ant builds and enhances the process, without requiring extra
work or imposing its own standards and restrictions, will be very popular.

0
Avatar
Permanently deleted user

Many times lately I've wanted back in time debugger, considering how
asynchronous things like OpenAPI are.

Dave Griffith wrote:
>>What about integrating 'going-back' technology
>>Would you please explain in a bit more details. I'm affraid I do not follow.


Omnicore's "Back in Time" debugger, perhaps? Technically very cool, but I've never heard anyone say it was a killer app.

After the improvements in Irida, it looks like they've decided that the debugger is basically completed functionality. Can't say I disagree.

--Dave Griffith

0
Avatar
Permanently deleted user

Hani Suleiman wrote:

Back in time is handy! Another nice addition to the debugger would be being able to set a breakpoint in the middle of a line, vs a specific line, for example:

blah.doSomething(new Foo())

I'd like the breakpoint to be set at 'doSomething', which means that when it's hit, new Foo() has already been called.

Note that this IS different from just setting a breakpoint at doSomething in the Blah class, since that would be called for every invocation, not just when new Foo() is passed in.

I guess that at least some of the time you could get away with a
conditional breakpoint in 'doSomething', but I guess not always.

It would be a bit tricky to convey to the user where exactly the
breakpoint is, but I guess it could be done with refined highlighting
(not the full line) and the tooltip when hovering above the breakpoint
icon in the gutter.

Amnon

0
Avatar
Permanently deleted user

Tell me more about "Delayed commit: build and commit if successful". Does that mean I can setup the version control commit process so that attempted developer commits will be immediately rejected (with feedback?) if the project doesn't build on the server so the current head will always be in a buildable state?

Are you really planning on accomplishing all of the features in this huge list in one big 6.0 release instead of some smaller interim releases? The feature list is so extensive that I worry 6 will be years in the making.

Jon

0
Avatar
Permanently deleted user

Hello Amnon,

This is not only presentation problem but JPDA API only allows setting breakpoints
on per-line basis.

-


Maxim Shafirov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

Hani Suleiman wrote:

>> Back in time is handy! Another nice addition to the debugger would be
>> being able to set a breakpoint in the middle of a line, vs a specific
>> line, for example:
>>
>> blah.doSomething(new Foo())
>>
>> I'd like the breakpoint to be set at 'doSomething', which means that
>> when it's hit, new Foo() has already been called.
>>
>> Note that this IS different from just setting a breakpoint at
>> doSomething in the Blah class, since that would be called for every
>> invocation, not just when new Foo() is passed in.
>>

I guess that at least some of the time you could get away with a
conditional breakpoint in 'doSomething', but I guess not always.

It would be a bit tricky to convey to the user where exactly the
breakpoint is, but I guess it could be done with refined highlighting
(not the full line) and the tooltip when hovering above the breakpoint
icon in the gutter.

Amnon



0
Avatar
Permanently deleted user

Hello Jon,

Tell me more about "Delayed commit: build and commit if successful".

Yep, you understood quite right.

Are you really planning on accomplishing all of the features

At least we'll try. As the matter of fact there were so many nice ideas that
didn't get into the list. We have to limit ourselves.

Well, of course there will be EAP for the thing and we're hope we will be
able to keep the things usable from the very beginning so you may count it
as intermediate releases.

-


Maxim Shafirov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


0
Avatar
Permanently deleted user

It requires a custom compiler which embeds false line numbers for each expression.

Maxim Shafirov (JetBrains) wrote:

Hello Amnon,

This is not only presentation problem but JPDA API only allows setting
breakpoints on per-line basis.

------------------
Maxim Shafirov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

>> Hani Suleiman wrote:
>>
>>> Back in time is handy! Another nice addition to the debugger would be
>>> being able to set a breakpoint in the middle of a line, vs a specific
>>> line, for example:
>>>
>>> blah.doSomething(new Foo())
>>>
>>> I'd like the breakpoint to be set at 'doSomething', which means that
>>> when it's hit, new Foo() has already been called.
>>>
>>> Note that this IS different from just setting a breakpoint at
>>> doSomething in the Blah class, since that would be called for every
>>> invocation, not just when new Foo() is passed in.
>>>
>> I guess that at least some of the time you could get away with a
>> conditional breakpoint in 'doSomething', but I guess not always.
>>
>> It would be a bit tricky to convey to the user where exactly the
>> breakpoint is, but I guess it could be done with refined highlighting
>> (not the full line) and the tooltip when hovering above the breakpoint
>> icon in the gutter.
>>
>> Amnon
>>


0
Avatar
Permanently deleted user

Tell me more about "Delayed commit: build and commit if successful".

>

Yep, you understood quite right.


That's fantastic! I've been lusting for this since at least IDEA 3 but wondered if it would ever happen since it requires a server-side component that thankfully you are adding as a key aspect of Demetra.

Jon

0
Avatar
Permanently deleted user

The "Delayed commit: build and commit if successful" brings up other questions. Will we be able to tie this 'commit if successful' to server-side code inspections so that the commit can be rejected if it doesn't pass project-mandated inspections?

Can a project-wide code reformatting be applied to the code on the server side as it is committed?

Thanks,
Jon

0
Avatar
Permanently deleted user

Maxim Shafirov (JetBrains) wrote:

Hello Amnon,

This is not only presentation problem but JPDA API only allows setting
breakpoints on per-line basis.

Hmm... Could it be implemented behind the scenes by IntelliJ like
conditional breakpoints are implemented? i.e. if user sets a breakpoint
like the example in this thread, IDEA will do the necessary extra steps
to make it happen.

Since currently on the example stepping into on the normal breakpoint
will first go into the Foo constructor, IDEA can do that behind the
scene, step out of it, and then give the control to the user.

That way IJ won't need a custom compiler, just be smart about what it
does when the more coarse full-line breakpoint occurs.

Amnon

0

Please sign in to leave a comment.