Uncooking Generic Types

Hello,

If I am not mistaken there was a refactoring for Uncooking of Generic types.
I could not find it any more. Is there any chance for it to come back? It is
very handy for converting sources back to JDK 1.4. If you could also
"uncook" some other 1.5 features like foreach loops etc and make it an ant
task (running only from IDEA is fine) I would be very happy indeed

Alex


9 comments
Comment actions Permalink

You might want to look at RetroWeaver at http://retroweaver.sourceforge.net/

0
Comment actions Permalink

Thanks Keith,

I was palying with it but I would rather do it on source level. Although if
it gets enough following (and therefore testing) I might consider it. I am a
bit worried that it will manipulate every class file in my project (and some
transformation it does are not entirely trivial), introducing its own
classess to support some 1.5 features. I think such a product needs to get a
very good testing before it can be trusted.

I was trying to get Sun to support limited -source 1.5 -target 1.4 javac
options (to output 1.4 compatible bytecode) but they firmly said that they
can not have a compiler without language specs and there is no specs for
limited 1.5



"Keith Lea" <keith@cs.oswego.edu> wrote in message
news:28631210.1081016576303.JavaMail.itn@is.intellij.net...

You might want to look at RetroWeaver at

http://retroweaver.sourceforge.net/


0
Comment actions Permalink

Alex Roytman wrote:

Hello,

If I am not mistaken there was a refactoring for Uncooking of Generic
types.


I am sorry to say there never were any such publicly available from us.

Friendly,
Dmitry

I could not find it any more. Is there any chance for it to come
back? It is very handy for converting sources back to JDK 1.4. If you
could also "uncook" some other 1.5 features like foreach loops etc and
make it an ant task (running only from IDEA is fine) I would be very happy
indeed

Alex


--
Dmitry Lomov
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"

0
Comment actions Permalink

Also, funny but it is generally impossible (without semantics changes).
Consider:

public interface RunnableWithException { public void run() throws E; } public class A implements RunnableWithException { public void run() throws IOException {...} } public class Util { public static void do( RunnableWithExcpetion]]> r) { ... }
}


public class Usage {
public void usage() throws IOException {
Util.do(new A()); // this line causes problems
// the only way to "uncook" this is to surrond it with try/catch,
// which is a "semantic" change (exception handler is introduced)
}
}

One could argue though that it is analogious to having an explicit runtime
cast...

Friendly,
Dmitry

Alex Roytman wrote:

Hello,

If I am not mistaken there was a refactoring for Uncooking of Generic
types. I could not find it any more. Is there any chance for it to come
back? It is very handy for converting sources back to JDK 1.4. If you
could also "uncook" some other 1.5 features like foreach loops etc and
make it an ant task (running only from IDEA is fine) I would be very happy
indeed

Alex


--
Dmitry Lomov
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"

0
Comment actions Permalink

Vote for the request here:
http://www.intellij.net/tracker/idea/viewSCR?publicId=27441

I for one have wanted to develop with generics but, since we are a 1.4
shop, de-generify my code before it gets checked in. All this 'uncook'
command would do is remove all the <> syntax and replace them with casts.

R

0
Comment actions Permalink

Dmitry,

Do you think it is possible to enumerate all cases which could lead to
semantic change on uncooking?
Could we have a refactoring which fails for such cases? Will it be too
limiting in your opinion?
I would be willing to avoid those cases (if they are not really crippling)
if you could provide limited but 100% reliable refactoring

Thank you

Alex


"Dmitry Lomov (JetBrains)" <Dmitry.Lomov@jetbrains.com> wrote in message
news:c4r1r0$11a$1@is.intellij.net...

Also, funny but it is generally impossible (without semantics changes).
Consider:

>

public interface RunnableWithException<E extends Throwable> {
public void run() throws E;
}

>

public class A implements RunnableWithException<IOException> {
public void run() throws IOException {...}
}

>

public class Util {
public static <E extends Throwable> void do(
RunnableWithExcpetion<E> r) { ... }
}

>
>

public class Usage {
public void usage() throws IOException {
Util.do(new A()); // this line causes problems
// the only way to "uncook" this is to surrond it with try/catch,
// which is a "semantic" change (exception handler is introduced)
}
}

>

One could argue though that it is analogious to having an explicit runtime
cast...

>

Friendly,
Dmitry

>

Alex Roytman wrote:

>

Hello,

>

If I am not mistaken there was a refactoring for Uncooking of Generic
types. I could not find it any more. Is there any chance for it to come
back? It is very handy for converting sources back to JDK 1.4. If you
could also "uncook" some other 1.5 features like foreach loops etc and
make it an ant task (running only from IDEA is fine) I would be very

happy

indeed

>

Alex

>

--
Dmitry Lomov
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"



0
Comment actions Permalink

Alex,
ok ok, here are some news.
We actually do internally have such a feature (dubbed "Degenerator", which
is not actually refactoring, but a command line source-to-source
transformer.

It is not overly polished (it inserts type casts all over the code, not only
where they are needed etc.), nor it it too fast (1.5 hours on IDEA sources),
but it "degenerates" IDEA quite happily.

We can consider opening it if there is much interest.

As to non-degenerateable cases, the one I quoted is the only one I am aware
of. It is not overly limiting, but rather annoying.

Friendly,
Dmitry

Alex Roytman wrote:

Dmitry,

Do you think it is possible to enumerate all cases which could lead to
semantic change on uncooking?
Could we have a refactoring which fails for such cases? Will it be too
limiting in your opinion?
I would be willing to avoid those cases (if they are not really crippling)
if you could provide limited but 100% reliable refactoring

Thank you

Alex


"Dmitry Lomov (JetBrains)" <Dmitry.Lomov@jetbrains.com> wrote in message
news:c4r1r0$11a$1@is.intellij.net...

>> Also, funny but it is generally impossible (without semantics changes).
>> Consider:
>>
>> public interface RunnableWithException { >> public void run() throws E; >> } >> >> public class A implements RunnableWithException { >> public void run() throws IOException {...} >> } >> >> public class Util { >> public static void do( >> RunnableWithExcpetion r) { ... } >> } >> >> >> public class Usage { >> public void usage() throws IOException { >> Util.do(new A()); // this line causes problems >> // the only way to "uncook" this is to surrond it with try/catch, >> // which is a "semantic" change (exception handler is introduced) >> } >> } >> >> One could argue though that it is analogious to having an explicit >> runtime cast... >> >> Friendly, >> Dmitry >> >> Alex Roytman wrote: >> >> > Hello, >> > >> > If I am not mistaken there was a refactoring for Uncooking of Generic >> > types. I could not find it any more. Is there any chance for it to come >> > back? It is very handy for converting sources back to JDK 1.4. If you >> > could also "uncook" some other 1.5 features like foreach loops etc and >> >]]> make it an ant task (running only from IDEA is fine) I would be very

happy

>> > indeed
>> >
>> > Alex
>>
>> --
>> Dmitry Lomov
>> Software Developer
>> JetBrains Inc.
>> http://www.jetbrains.com
>> "Develop with pleasure!"

--
Dmitry Lomov
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"

0
Comment actions Permalink

You're asking EAPers if there will be interest in a cool secret tool like that? :) You think EAPers will EVER say "No we really don't want a free feature, but thanks for asking?" :)

I'd be very interested in it, if it doesn't impede on your delivery time of Pallada.

Thanks
R

Hello Dmitry,

Alex,
ok ok, here are some news.
We actually do internally have such a feature (dubbed "Degenerator",
which
is not actually refactoring, but a command line source-to-source
transformer.
It is not overly polished (it inserts type casts all over the code,
not only where they are needed etc.), nor it it too fast (1.5 hours
on IDEA sources), but it "degenerates" IDEA quite happily.

We can consider opening it if there is much interest.

As to non-degenerateable cases, the one I quoted is the only one I am
aware of. It is not overly limiting, but rather annoying.

Friendly,
Dmitry
Alex Roytman wrote:

>> Dmitry,
>>
>> Do you think it is possible to enumerate all cases which could lead
>> to
>> semantic change on uncooking?
>> Could we have a refactoring which fails for such cases? Will it be
>> too
>> limiting in your opinion?
>> I would be willing to avoid those cases (if they are not really
>> crippling)
>> if you could provide limited but 100% reliable refactoring
>> Thank you
>>
>> Alex
>>
>> "Dmitry Lomov (JetBrains)" wrote in >> message news:c4r1r0$11a$1@is.intellij.net... >> >>> Also, funny but it is generally impossible (without semantics >>> changes). Consider: >>> >>> public interface RunnableWithException { >>> public void run() throws E; >>> } >>> public class A implements RunnableWithException { >>> public void run() throws IOException {...} >>> } >>> public class Util { >>> public static void do( >>> RunnableWithExcpetion r) { ... } >>> } >>> public class Usage { >>> public void usage() throws IOException { >>> Util.do(new A()); // this line causes problems >>> // the only way to "uncook" this is to surrond it with try/catch, >>> // which is a "semantic" change (exception handler is introduced) >>> } >>> } >>> One could argue though that it is analogious to having an explicit >>> runtime cast... >>> >>> Friendly, >>> Dmitry >>> Alex Roytman wrote: >>> >>>> Hello, >>>> >>>> If I am not mistaken there was a refactoring for Uncooking of >>>> Generic types. I could not find it any more. Is there any chance >>>> for it to come back? It is very handy for converting sources back >>>> to JDK 1.4. If you could also "uncook" some other 1.5 features like >>>> foreach loops etc and make it an ant task (running only from IDEA >>>> is fine) I would be very >>>> >> happy >> >>>> indeed >>>> >>>> Alex >>>> >>> -- >>> Dmitry Lomov >>> Software Developer >>> JetBrains Inc. >>> http://www.jetbrains.com >>>]]> "Develop with pleasure!"

-- Posted by JetBrains OmniaMea

0
Comment actions Permalink

Dmitry,

I would be VERY interested in it. For me personally Jetbrains commitment to
deliver this feature is sufficient (we have unlimited faith in you guys :)
and actual implementation can follow later after Pallada (?)
I personally would not mind paying some extra in addition to my IDEA license
to get this tool if Jetbrains choose put some more effort into it and polish
it a bit.
For me it is the difference between staying on 1.4 for another year and
using 1.5 right now. This tool does not have much future beyond IDEA 4.x
(may be one more release) so it is unfair to ask Jetbrains to put much
effort into it unless people are willing to purchase it but I am dreaming of
transform of some other 1.5 low hanging fruits (like foreach loops)


BTW "Degenerator" is an excellent codename! nice punt

Alex


"Dmitry Lomov (JetBrains)" <Dmitry.Lomov@jetbrains.com> wrote in message
news:c4s9fv$9v8$1@is.intellij.net...

Alex,
ok ok, here are some news.
We actually do internally have such a feature (dubbed "Degenerator", which
is not actually refactoring, but a command line source-to-source
transformer.

>

It is not overly polished (it inserts type casts all over the code, not

only

where they are needed etc.), nor it it too fast (1.5 hours on IDEA

sources),

but it "degenerates" IDEA quite happily.

>

We can consider opening it if there is much interest.

>

As to non-degenerateable cases, the one I quoted is the only one I am

aware

of. It is not overly limiting, but rather annoying.

>

Friendly,
Dmitry

>

Alex Roytman wrote:

>

Dmitry,

>

Do you think it is possible to enumerate all cases which could lead to
semantic change on uncooking?
Could we have a refactoring which fails for such cases? Will it be too
limiting in your opinion?
I would be willing to avoid those cases (if they are not really

crippling)

if you could provide limited but 100% reliable refactoring

>

Thank you

>

Alex

>
>

"Dmitry Lomov (JetBrains)" <Dmitry.Lomov@jetbrains.com> wrote in message
news:c4r1r0$11a$1@is.intellij.net...

>> Also, funny but it is generally impossible (without semantics changes).
>> Consider:
>>
>> public interface RunnableWithException<E extends Throwable> {
>> public void run() throws E;
>> }
>>
>> public class A implements RunnableWithException<IOException> {
>> public void run() throws IOException {...}
>> }
>>
>> public class Util {
>> public static <E extends Throwable> void do(
>> RunnableWithExcpetion<E> r) { ... }
>> }
>>
>>
>> public class Usage {
>> public void usage() throws IOException {
>> Util.do(new A()); // this line causes problems
>> // the only way to "uncook" this is to surrond it with

try/catch,

>> // which is a "semantic" change (exception handler is

introduced)

>> }
>> }
>>
>> One could argue though that it is analogious to having an explicit
>> runtime cast...
>>
>> Friendly,
>> Dmitry
>>
>> Alex Roytman wrote:
>>
>> > Hello,
>> >
>> > If I am not mistaken there was a refactoring for Uncooking of Generic
>> > types. I could not find it any more. Is there any chance for it to

come

>> > back? It is very handy for converting sources back to JDK 1.4. If you
>> > could also "uncook" some other 1.5 features like foreach loops etc

and

>> > make it an ant task (running only from IDEA is fine) I would be very

happy

>> > indeed
>> >
>> > Alex
>>
>> --
>> Dmitry Lomov
>> Software Developer
>> JetBrains Inc.
>> http://www.jetbrains.com
>> "Develop with pleasure!"

>

--
Dmitry Lomov
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"



0

Please sign in to leave a comment.