"bobef" <bobef_member@pathlink.com> wrote in message news:d7cfoi$2hsr$1@digitaldaemon.com...
> I know almost nothing about Java. All I did in java was a lousy j2me
game...
> What I know for sure is that it is slow (maybe after few years it wont be
slow
> in it will ruler the world :). But I guess this will not reflect to D
since it
> will not execute Java code like in the C case but instead convert it to D
and
> compile it.

Inner classes are not a cause of slow Java programs, so no need to worry there.

> What comes to my mind first, well second after that the Java syntax
> is ugly where it is not copied from C++, is that the Java code is relying
on the
> Java std lib or whatever it is called. And it is a huge one. It covers
gui,
> network, sound and everything else (let someone who deals with java
complete
> this list)... And the more important part is that this library is machine/platform independent because it is executed in the java virtual machine... How the HELL you gonna make this thing work with D?

Good point - the underlying Java standard library is not going to be converted. However, it turns out to be not necessary to. The goal isn't to do a hands-off completely mechanical translation, but to convert libraries (where the copyright/license of them allows) more or less mechanically, then go in and adjust/fix/adapt as necessary.

> P.S. I don't like the idea. Java is everything I want to escape from with
D.
> C/C++ is too old and needs replacement. I believe java/c# is not that replacement. I prefer to write C wrapers... But it requires a lot of
entusiasm
> and this is a big issue. Still, I believe a better solution is required.
And I
> don't know what your conversation with Kris was. Maybe this is the best solution. The other thing I don't agree is that D needs to reuse all the existing code in the world. It is like.. I don't know. When you no longer
can
> use a buildning, no longer can upgrade it and need a better one, you raze
to the
> ground and buid it once again. And D shouldn't be the next upgrade for
this C++
> building (even less to java). Well if you want to make money with it you
go with
> the java way. But I think you can't just make people use D. When they come
with
> the idea D is worthy language they will write D native (I mean in D not
reusing
> the old ones) gui and whatever libraries. If someone use D to for his
favourite
> old library be it java,c++ or whatever he better stays with it. This is
the same
> issue microsoft have with their win32 lib, because it is C... But all they
need
> is money and they can't stop support it. Otherwise they would throw it all
away
> and go with something totally new. This is what D needs to do in my
opinion. Not
> relying on some old code...

Let me put some of your concerns to rest <g>. D is not Java, it will never be Java. Phobos isn't going to be replaced with a Java clone library. But D does need a GUI, and doesn't have (yet) the resources to engineer a top-notch one from scratch. Just like C++ bootstrapped off of existing C libraries before going its own way, D needs to bootstrap off of something. For reasons I laid out, the Java GUI libraries are the shortest path to get D bootstrapped with a much needed crossplatform, modern GUI.

> In your Harmonia porting efforts, did you have to port Java inner classes
> to
> delegates as well? If so, was it something you think could be automated
> reasonably well w/o adding 'inner classes' to D?

j-smile:
http://www.terrainformatica.com/org/j-smile/index.htm
is the project I was porting from primarily.

j-smile is almost not using inner classes - listeners (AWT/SWING/SWT). Just don't need them in sinking/bubbling event propagation schema. All containers of some widget are by design listeners of all events coming to the widget.

<side-note>
The problem with listeners is one: they are too heavy for massive
use in UI. (WinForms.NET inherits the same design flaw.)
Java listener implementation tries to satify patterns:
Listener, Observer-Observable, Model-View-Controller
for all events. This is just overkill for most of the events.
See: *each* Component in Java contains fields
   ComponentListener cmpListener;
   KeyListener keyListener;
   FocusListener focusListener;
   MouseListener mouseListener;
   MouseMotionListener motionListener;
   ActionListener actionListener;

which are not used in 99% of cases,
only actionListener is used frequently.

In contrary, in Harmonia, only concrete classes
allows you to attach listeners and moreover to
events where they really make sense, e.g.
class Button
{
   bool delegate(Widget) _on_click;
}
For other cases SINKING/BUBLING works
and costs pretty much nothing - does not take
any instance memory.
</side-note>

Typical uses cases of inner/anonymous classes
is event handlers. And this is used primarily
in UI. In Java there are just three UI libraries
in active use: AWT, SWING and SWT.
I think that AWT and SWING are not free for
porting in D. And for IBM's SWT Shawn Liu
already did an excellent job.
----------------------------------------
Other big area of Listeners use in Java
is in JSP/Servlet/Server Faces.
http://www.onjava.com/pub/a/onjava/excerpt/JSF_chap8/index.html?page=1

(Ommited: question of GC and memory pools in D -
imo, the must for server implementations )

This framework uses ActionEvents only, afaik, so

>If so, was it something you think could be automated
> reasonably well w/o adding 'inner classes' to D?

See, typical pattern is

public class [[[NMTOKEN]]] implements ActionListener {
    ...
    public void processAction(ActionEvent e)
         throws AbortProcessingException {
        [[[ delegate function body ]]]
    }
}

This could be translated by using pretty simple Perl script into simple inline delegate function declartion.

And call replacements:

addActionListener(ActionListener listener);
removeActionListener(ActionListener listener);

can be also automated by Perl.

disclaimer: I am not
a Java expert, my experience is
limited by Java GUI area.
My Java server side experience is rather
theoretical than practical.

Andrew.


"Dave" <Dave_member@pathlink.com> wrote in message news:d7ch6m$2j3k$1@digitaldaemon.com...
> In article <d7c03s$27lf$1@digitaldaemon.com>, Andrew Fedoniouk says...
>>
>>I've ported Harmonia (big part of it) from Java.
>>It took me half of man/month. Doing porting
>>I've improved source code a lot - as too many
>>optimisation technics and features are not available
>>in Java but available in D.
>>
>
> In your Harmonia porting efforts, did you have to port Java inner classes
> to
> delegates as well? If so, was it something you think could be automated
> reasonably well w/o adding 'inner classes' to D?
>
> 

OK . Everything else sounds fine but this:

>
>Good point - the underlying Java standard library is not going to be converted. However, it turns out to be not necessary to. The goal isn't to do a hands-off completely mechanical translation, but to convert libraries (where the copyright/license of them allows) more or less mechanically, then go in and adjust/fix/adapt as necessary.
>

I still can't understand. We are talking about gui-s. As long as I understand Java has a basic gui and routines that supports it. Also drawing routines and everything else needed. And every other java gui depends on that. Its like the "asm" of java. You can't just go and write something your video card's memory, can you? And you depend on sun for that matter. Well you will convert some thirdparty code to D, but D misses gui and drawing. How you gonna replace these? And you can't add such functionality because D, unlike Java, is platform dependent.

Please tell me what I am missing here?

>
> I agree. But inner classes aren't conceptually the same thing, so a design wrapped around inner classes would need to be reengineered.
>

Generally speaking, yes. But 99% of
transformation of real code of inners
can be handled by using dumb Perl script.  imho.
Name the project/technology where you think
such java-to-D tool makes sense.
I don't know any case where Java-to-D
could be used without reengineered.
(inners are just very small part of the problem).

Again: conceptually speaking inners were invented
for close of the hole of luck of funtion pointers and
delegates. And inners in Java are used primarily for delegate
emulation and exactly in the same pattern.

Andrew.

>> I understand motivation of having porting tool from Java. But as a concept delegates are just better.
>
> I agree. But inner classes aren't conceptually the same thing, so a design wrapped around inner classes would need to be reengineered.

This is one of refactoring features of IntelliJ http://www.jetbrains.com/idea/features/refactoring.html

--------------
Convert Anonymous Class to Inner

Invoke this refactoring on an anonymous class to convert it to a named inner class. If the anonymous class accesses local variables, a constructor will be created for the inner class and values of the accessed variables will be passed to it. If the anonymous class is located in a non-static method, you may also choose an option to pass a reference to the outer class to the constructor. It is especially useful to apply this refactoring to large anonymous classes, so that the code becomes more readable. Additional benefit is the possibility to share the functionality provided by the inner class.
--------------

I think that using such tool you can prepare your
Java code to be converted into D without need of
inners in D.

Andrew.

bobef wrote:
> OK . Everything else sounds fine but this:
> 
> 
>>Good point - the underlying Java standard library is not going to be
>>converted. However, it turns out to be not necessary to. The goal isn't to
>>do a hands-off completely mechanical translation, but to convert libraries
>>(where the copyright/license of them allows) more or less mechanically, then
>>go in and adjust/fix/adapt as necessary.
>>
> 
> 
> I still can't understand. We are talking about gui-s. As long as I understand
> Java has a basic gui and routines that supports it. Also drawing routines and
> everything else needed. And every other java gui depends on that. Its like the
> "asm" of java. You can't just go and write something your video card's memory,
> can you? And you depend on sun for that matter. Well you will convert some
> thirdparty code to D, but D misses gui and drawing. How you gonna replace these?

I assume Kris will write his own implementation.

> And you can't add such functionality because D, unlike Java, is platform
> dependent.

It is possible to write cross platform code by using the version statement, though initially I suspect only Windows and Linux will be supported.

> 
> Please tell me what I am missing here?
> 
> 

On Sat, 28 May 2005 14:50:14 -0700, Walter wrote:

> This is based on discussions of mine with Kris where we were looking for a solution:
> 
> D can access existing code written in C very will. It's not hard to create a D interface to any C module. One can do it by rote with minimal effort.
> 
> The problem is that a lot of the libraries that D needs, like GUI libraries, are written in C++. C++ code tends to be so quirky, and and so wrapped up in its need to explicitly manage memory, that it is very resistent to rote translation into D (or any other language).

For some cool C GUI libs look at http://www.enlightenment.org/

On Sun, 2005-05-29 at 11:31 +0800, Shawn Liu wrote:
> This kind of technology is widly used in java.
> 
> class Outer{
> void foo(){
>     class NewActionListen : ActionListener{
>          public void actionPerformed(ActionEvent evt){
>             writefln("write some thing");
>          }
>     }
>     addActionLister(new NewActionListener());
> }
> }
> 
> and is the same as the following code.
> 
> class Outer{
> void foo(){
>     addActionLister(new ActionListener(){
>         public void actionPerformed(ActionEvent evt){
>             writefln("write some thing");
>         }
>    };
> }
> }
> We call the later "anonymous class" since it was derived from a base class
> but has not been assigned a name.

Actually, they are not the same.  As I recall, each time the code for the anonymous class is run, it creates a new class, whereas the inner class is one class.  The anonymous classes are basically an inefficient waste of memory.

John Demme

On Sun, 2005-05-29 at 01:39 -0700, Andrew Fedoniouk wrote:
> See, in Java:
> 
> class Outer{
> void foo(){
>     class NewActionListen : ActionListener{
>          public void actionPerformed(ActionEvent evt){
>             writefln("write some thing");
>          }
>     }
>     addActionLister(new NewActionListener());
> }
> }
> 
> And in D:
> 
> class Outer
> {
>   public void actionPerformed(ActionEvent evt) { writefln("write some
> thing"); }
>   void foo() { addActionLister ( &actionPerformed ); }
> }
> 
> -or just -
> 
> class Outer
> {
>    void foo()
>    {
>        addActionLister ( delegate void(ActionEvent evt)  { writefln("write
> some thing"); }  );
>    }
> }
> 
> Little bit better and clear, isn't it?

Sure delegates clearer for single functions like that, but inner classes are much clearer whenever the listener has more than one method. Delegates are handy, but are NOT a replacement for inner classes. They're handy, too.

It's like the difference between a crescent wrench and a vice grip.  You can use both of them to do a lot of things, but each shine for certain things.  "The right tool for the right job" and props to Walter for adding more tools to D's toolbox.

John Demme

"John Demme" <me@teqdruid.com> wrote in message news:1117411000.19815.7.camel@localhost.localdomain...
> On Sun, 2005-05-29 at 11:31 +0800, Shawn Liu wrote:
>> This kind of technology is widly used in java.
>>
>> class Outer{
>> void foo(){
>>     class NewActionListen : ActionListener{
>>          public void actionPerformed(ActionEvent evt){
>>             writefln("write some thing");
>>          }
>>     }
>>     addActionLister(new NewActionListener());
>> }
>> }
>>
>> and is the same as the following code.
>>
>> class Outer{
>> void foo(){
>>     addActionLister(new ActionListener(){
>>         public void actionPerformed(ActionEvent evt){
>>             writefln("write some thing");
>>         }
>>    };
>> }
>> }
>> We call the later "anonymous class" since it was derived from a base
>> class
>> but has not been assigned a name.
>
> Actually, they are not the same.  As I recall, each time the code for the anonymous class is run, it creates a new class, whereas the inner class is one class.  The anonymous classes are basically an inefficient waste of memory.
>

On each invocation of foo() will be created new instance.
anonymous classes are exactly the same as inner classes,
they just have no name and their declaration implies
hidden 'new' call.

In Java inner classes have access to 'final' local variables existing at the point of their definition.

There is no 'final' concept in D.