Update for Java developers

A few weeks ago you said you'd have more information for "old school" Java
programmers about IDEA's future. When can we expect that info?

--
Jordan Zimmerman
Principal Software Architect
SHOP.COM
http://www.shop.com


23 comments
Comment actions Permalink

I'm as well more than eager to know a bit more about that.

_marc - a disciple since early versions of 2.0 back in the old day ;)

0
Comment actions Permalink

Jordan Zimmerman wrote:

A few weeks ago you said you'd have more information for "old school" Java
programmers about IDEA's future. When can we expect that info?

I've got a bad feeling that the "information" is that there is nothing
significant planned...

N.

0
Comment actions Permalink

I've got a bad feeling that the "information" is that there is nothing
significant planned...


I have a similar feeling, although I don't need significant changes (at
least from the users POV). I would be happy about some (non-trivial)
polishing and fixing old bugs.

0
Comment actions Permalink

I know there will be at least the following improvements in IntelliJ which should be valuable for us "old school" java programmers:

  • some new refactorings

  • more improvements in version control

  • new inspections and intentions

  • new quick fixes for red code

  • improvements in code completion

  • and naturally many bugfixes


This information, except for the inspections and intentions, is all gleaned from JIRA, so more is probably coming/planned.

Bas

0
Comment actions Permalink
  • some new refactorings


You mean those from Sixth and Red River?

  • more improvements in version control


No need from my part.

  • new inspections and intentions


Which you have in mind?

  • new quick fixes for red code


Yes. One comes immediately to my mind: "Make class 'Foo' implement 'IBar'"
for more situations.

One more from me:

  • more good-code-style assistance, e.g. when trying to extract a variable or

field use the top-most type (e.g. List instead of ArrayList)

Tom

0
Comment actions Permalink
  • more improvements in version control


No need from my part.


Actually I've switched to Tortoise SVN to perform my actual updated/commit as I've got so many trouble with SVN support; many times, SVN updates gave me a lot of inconsistencies in the source code (e.g., duplicated/missing classes) that I've never experienced when using Tortoise SVN (until now). Of course, very difficult to reproduce to submit a bug/issue report :( After such a mess, most of the times I've got to clear the caches...

By the way, an SVN update is so slow using IDEA compared to TortoiseSVN (I'm on Windows XP) - do not know why.

Since, 7.03 I'm re-performing my commit using IDEA and saw no problem yet; before that got some commits failed with no specific error; then doing it with Tortoise SVN just after everything was ok? I must admint that my DSL might not be state of the art and I've got a quite high latency to my SVN repositories but.... Tortoise SVN never failed until now during a commit.


_marc - still an IDEA evangelist ;)

0
Comment actions Permalink

We would be happy if you could give SmartSVN a try.

Tom
syntevo.com

0
Comment actions Permalink
  • some new refactorings


You mean those from Sixth and Red River?


No, I do not know what is going to happen to those.
I mean new refactorings. I have seen JIRA issues mentioning a "Change type signature" and a "Replace method with method object" refactorings

  • more improvements in version control


No need from my part.


Ok, but I guess you are a special case:-)

  • new inspections and intentions


Which you have in mind?


Well, at this point in time I have implemented 3 new intentions and 7 new inspections for Diana. Jetbrains is creating new ones too. Not too many perhaps, but there is still plenty of time for more. These days I usually announce new intentions and inspections on Twitter (https://twitter.com/InspectorBas) if you are interested.

  • new quick fixes for red code


Yes. One comes immediately to my mind: "Make class 'Foo' implement 'IBar'"
for more situations.


Do you have a JIRA issue for that?

One more from me:

  • more good-code-style assistance, e.g. when trying to extract a variable or

field use the top-most type (e.g. List instead of ArrayList)


Nice idea, but how would you implement that, so it would do the right thing most of the time?

Bas

0
Comment actions Permalink

I have never experienced the problems you are describing. And the performance problem I cannot comment about because I have never compared the performance with TortoiseSVN. Have you reported your problems in JIRA?


Bas

0
Comment actions Permalink

>> Yes. One comes immediately to my mind: "Make class 'Foo' implement 'IBar'"
>> for more situations.


Do you have a JIRA issue for that?


IDEADEV-21023

>> * more good-code-style assistance, e.g. when trying to extract a variable or
>> field use the top-most type (e.g. List instead of ArrayList)


Nice idea, but how would you implement that, so it would do the right thing most of the time?


Just suggest the least restricting type that would not change the behaviour,
instead of using the current type. A common use-case for me is when starting
to code a method returning a collection:

public List getLines(Foo foo) { return new ArrayList(); } Introducing a local variable currently suggests the type ArrayList which is considered bad style: public List getLines(Foo foo) { final ArrayList lines = new ArrayList(); return lines; } I would expect to get following by just entering the new variable name: public List getLines(Foo foo) { final List lines = new ArrayList]]>();
return lines;
}

Tom

0
Comment actions Permalink

>> Yes. One comes immediately to my mind: "Make class 'Foo' implement 'IBar'"
>> for more situations.

Do you have a JIRA issue for that?

IDEADEV-21023

Voted, thanks.

>> * more good-code-style assistance, e.g. when trying to extract a variable or
>> field use the top-most type (e.g. List instead of ArrayList)


Nice idea, but how would you implement that, so it would do the right thing most of the time?


Just suggest the least restricting type that would not change the behaviour,
instead of using the current type.

How would IDEA know it is not changing the behaviour? ArrayList for example has several useful methods which are not present in the List interface. What if I want to introduce an ArrayList variable so I can call ensureCapacity()? And would this feature be useful for types outside of the collections api?
By the way, the introduce variable dialog provides a way to choose less specific types, doesn't it?

Bas

0
Comment actions Permalink

By the way, the introduce variable dialog provides a way to choose less specific types, doesn't it?


Yes, it does, but it is quite annoying to always have to change this,
especially for collections.

Tom

0
Comment actions Permalink

By the way, the introduce variable dialog provides a way to choose less specific types, doesn't it?


Yes, it does, but it is quite annoying to always have to change this,
especially for collections.


Maybe this can be made more convenient.
For example (1) the focus could (optionally) start in the type drop down menu.
Or (2) the type or variable used most often for a specific type of expression could be determined using statistics. That way users who always make their ArrayList variable type List would have that preselected, while users just using the most specific type would get that.

Bas

0
Comment actions Permalink

Hello Jordan,

A few weeks ago you said you'd have more information for "old school"
Java programmers about IDEA's future. When can we expect that info?


Sorry, we didn't actually say that. :) At the moment we don't have any document
that we can publish concerning this.

--
Dmitry Jemerov
Development Lead
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"


0
Comment actions Permalink

Hello Bas,

>>> By the way, the introduce variable dialog provides a way to choose
>>> less specific types, doesn't it?
>>>
>> Yes, it does, but it is quite annoying to always have to change this,
>> especially for collections.
>>

Maybe this can be made more convenient. For example (1) the focus
could (optionally) start in the type drop down menu. Or (2) the type
or variable used most often for a specific type of expression could be
determined using statistics. That way users who always make their
ArrayList variable type List would have that preselected, while users
just using the most specific type would get that.


Could you please file the JIRA issue for (2)? That sounds like a very useful
and easy to implement enhancement.

--
Dmitry Jemerov
Development Lead
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"


0
Comment actions Permalink

For example (1) the focus could (optionally) start in the type drop down menu.


Currently, press CtrlShiftTab to try to jump to the type combobox...

0
Comment actions Permalink

For example (1) the focus could (optionally) start in the type drop down menu.


Currently, press CtrlShiftTab to try to jump to the type combobox...

You probably mean Shift+Tab, but that has the same effect: none at all (at least on OS X)
Is there a bug open about this?

Bas

0
Comment actions Permalink

submitted: http://www.jetbrains.net/jira/browse/IDEA-18070

By the way, you are posting this from JavaOne right?

Bas

0
Comment actions Permalink

You probably mean Shift+Tab


Right.

Is there a bug open about this?


No, I had the hope, that the IDEA developers would find this problem themselves.

Tom

0
Comment actions Permalink

Is there a bug open about this?


No, I had the hope, that the IDEA developers would find this problem themselves.


They can, but they might think that not many people are bothered by this problem if nobody is filing JIRA issues about it. That way it probably will not get too much priority I am afraid.

Bas

0
Comment actions Permalink

IDEA-18077

0

Please sign in to leave a comment.