Re: [javaCompiler-users] Great tool

[Marco T. <mt...@gm...>]

Hello

Abir Basak wrote:
> Hi,
>   First, thanks for the great tool for gcj bundled with required 
> libraries. Good to use a prebundled app like this... (previously I was 
> useing thiscool gcj ....)

Thank you. Yes, I started with thisiscool gcj too, but it had a too old 
version of gcj and still needed all the knowledge of gcj command line 
parameters (something a average java developer isn't interested in 
spending time to learn...)


>   However, I expect a few additional features in the next version ....

If you pay me, you can expect features. Else you have to ask for them.
Feature requests are always welcome but I will only implement features 
that I consider usefull.


>   1) All the library versions are hard-coded inside the 
> JavaCompiler.java class. Can't it be set in th ui itself...

Yes, I'll provide a flexible configuration for the used 
utilities/programs (win-gcj, lin-gcj, jface, retroweaver, swingWT, swt 
and upx paths) in the next version.


>      Like If I want to use swingwt .88 (realeased a few days ago) I can 
> compile it  & build my application with it..

I'll provide an update of swingWT in the near future. But before that, I 
have to do some tests with cygwin.
Either update the files in the swingWT-0.87 folder yourself or use a 
managed jface project and add the swingWT jars. You can precompile them 
too with the "create jar object project".


> instead of downloading the 
> 150 mb bundle for next version once again! ...

Sorry, don't know what you mean with this.
I'll release updates of utilities (SWT, swingWT, ...) if they release 
new versions, you won't have to download the whole javacompiler again. 
That would be stupid. The updates will overwrite outdated files.

Until now, all releases contained an updated gcj. Because this requires 
a rebuild of all utilities, I always created a whole javaCompiler 
release... Hope you meant this.


> or bulding the application from source code for the library ...

Sorry, don't know what you mean with this either.


>   2) expect for linux one opt name & windows another , as opposed to the 
> convention that linux file append by -lin, & windows file by - win.exe. 

Ok. I'll consider that.


> Give an option to create shared library / dll also ...

No. Currently not possible with gcj...
I will add this as soon as gcj supports it again for windows.


>  3) expose gcc / gcj command line parameters (optimization, tuning / 
> architecture etc) , either through gui, or even just a text box will 
> work for most situations....

I will add the possibility to enter own flags and see the used commands 
during compilation...


> 4) as opposed to replacing all the swing package to swingwt, i think it 
> is better to move all the swingwt library to swing package & compile

why?


> (as the swingwt lib is only to fill the gap between gnu classpath & gcj.

There's no gap between gnu classpath and gcj. gcj uses gnu classpath.


> I think thiscool gcj prebuild swingwt works that way)

But I won't do it this way. Because:
- The result of changing the imports is exactly the same.
- This enables to use the gcj builtin awt/swing support too.


> 5) also give a standard makefile or ant script with the source code of 
> the program ...

No, this won't be of any use for javaCompiler users. If someone wishes 
to work with the sourcecode, I'm shure he/she will be able to create a 
project in eclipse, netbeans or similar...

> 6) also u can provide preompiled version of the new versionof library as 
> drop in  replacement of the old version, instead of downloading the 
> whole program...

Same question as above or did I understand you wrong there?


Thanks for all the feature request. Most of them will find it's way into 
the next main release...

regards
Marco