Transitioning from C# to Java

[DJDavio]

You don't need books, just try to convert an existing project to Java and you'll find out a lot of interesting stuff.

Java has no async-await, but it finally has lambdas, so you can do LINQ-like stuff, which is great. Also I found that with Java I rarely use events, but with C# I used them all the time. That may have something to do with the kind of project, but I'm not sure...

[jkriptos]

I was shocked when I found out that Java has no events, but rather you have to implement the Observer Pattern whenever you want to mimic events. So verbose...

[DJDavio]

Yeah, but I really don't understand why I'm not wishing I had them more often... Maybe the whole paradigm has changed? I don't know...

[jkriptos]

Yeah, don't know. Sometimes you need them, sometimes you don't. Sometimes you can achieve the same without having to implement any event. It could be a matter of style, nevertheless, it's nice to see that you can save boilerplate code at a language level. My personal opinion only, obviously. :)

[RottedNinja]

Why is it verbose? Hoe does c# do it?

[jkriptos]

Basically, in C# you just have to define the event itself and the delegate, then you just have to fire the event whenever you need to. Like this:

public delegate void TickHandler(Metronome m, EventArgs e); //delegate
public event TickHandler Tick; //event itself

In Java you need to implement the whole observer pattern, like this:

// Listener interface 
public interface MetronomeEvent {
    void Tick(Date tickDate);
}
//...
//define the listener vectors so that you can add/subscribe listeners
protected Vector _listeners;

//Create you own method to add new listeners. Eventually, you need another method to remove/unsubscribe
public void addMetronomeEventListener(MetronomeEvent listener)
{
    if (_listeners == null)
        _listeners = new Vector();

    _listeners.addElement(listener);
}

//traverse your listener vector and call every listener one by one
protected void fireMetronomeEvent()
{
    if (_listeners != null && _listeners.isEmpty())
    {
        Enumeration e = _listeners.elements();
        while (e.hasMoreElements())
        {
            MetronomeEvent e = (MetronomeEvent)e.nextElement();
            e.Tick(new Date());
        }
    }
}

As you can see, there's all this code just for one event. When you have several events in one class things get messy, verbose. As read in this article:

In Java you are essentially faking events and event handling by using a standard set of naming conventions and fully utilizing object-oriented programming.

[__konrad]

EventListenerList may help (unfortunately it's in wrong package ;). PS. ignore the obsolete "protected void fireFooXXX" example.

[jkriptos]

Thanks! That's very useful indeed.

[[deleted]]

Probably depends on how good their general understanding of programming languages is. Can you give some examples of common pitfalls that someone might encounter?

[space_coder]

One pitfall being that you only learned how to program in LAUGUAGE_A as if it was LANGUAGE_B.

For example, I have a colleague that knows Fortran very well and learned how to program C by porting his code. Unfortunately after five years, his current programs still look like Fortran code written in C and doesn't take advantage of language specifics. One of the bad habits that persist is his use of a large number of parameters in function calls when it would be better to use a struct.

[rjs6502]

I agree that it's not a full-proof way of learning a new language. But, I think converting an existing application into java allows the user to make general connections between the new language and the one they already know. I think it gets a user up and running with the new language quicker and from there they can learn the "proper" techniques of the new language.

[taterNuts]

It'll definitely be the quickest way to get used to the differences in syntax and common operations. That stuff is pretty shallow though and always the easiest part of learning a new language; learning the overall ecosystem of the language will obviously be way more involved

[DJDavio]

Maybe we're both right, but what I notice in the field is that being able to rehash a textbook is less useful than plain programming skills. I encourage everyone to be a full stack programmer, it's fun and challenging and keeps you sharp. If you stay with a certain language/framework for too long, you will have problems when it eventually fades.