Develop Reference

Language switching - l10n I18n

How does language switching work in Java/Vaadin? I have a web application and would like to integrate a combo box, that changes the language of every text in this application. Do i need to mark each text that should get translated manually and define its translation? How complex is it to implement this function into an exting project?

Do i need to mark each text that should get translated manually and define its translation?
You should use ResourceBundles to store/read translations of strings.
How does language switching work in Java/Vaadin?
You need to provide a class that implements I18NProvider. Documentation about that can be found here
Once implemented correctly, you will be able to call getTranslation("HelloWorld") on any Component (and therefore on any view since they must extend a component), to receive the translation of the key "HelloWorld" defined in the ResourceBundle-file of the current UI-Locale.
Views that extend LocaleChangeObserver are notified when the Locale is changed, and then you can call getTranslation("HelloWorld") again to find the translation of the freshly set language.
I would like to integrate a combo box, that changes the language of every text in this application.
See this SO answer of mine where I posted example code of a Select component that acts as a language switcher. It is using both ResourceBundle and I18NProvider. (You can use a ComboBox too, but with the downside that you can only display a String for the selected value)
The important part in that code there is that the Select has a ValueChangeListener that sets the Locale of the VaadinSession, which in turn will trigger the localeChange method of the LocaleChangeObserver that your view now should implement. In the localeChange method, you can re-translate the translatable Strings of every component in the view; set new texts in Labels, set new labels and placeholders for TextFields, etc etc.
How complex is it to implement this function into an exting project?
That depends very much on your definition of complex, and how familiar you already are with ResourceBundles. There certainly are less complex topics than this, but I18N is never easy. In my opinion, Vaadin has done a very great job of providing us devs with a way to use I18N in our applications.

Most people use a sort of translation file system for their localization. Basically you make a text file for each language with a key and value system where you name every translated message with a key and a translated value. You can then use these keys (that should be predefined) to get the correct message for the language you want. These files can be anything really, but if you're looking for a simple java implementation then there are pretty simple ways to do it. For an example look here.

Did you look at this section of the documentation? https://vaadin.com/docs/v14/flow/advanced/tutorial-i18n-localization.html

Procedure for making GUI based applications

Is there any method to be followed before writing code for a GUI program? For previous programs, i had algorithm and/or class diagrams before writing code for the normal programs(those done before learning GUI)Should we follow anything similar while making GUI?I just made a small game(Book cricket) which involves using data stored in files and some computations.
I have completed the game just by making one thing at a time and so, i have lots of code. I just wanted to know if there is any procedure while making GUI based applications that can be followed for optimizing and making the code easy to read and debug?
To be more specific:
1. Should we design all panels in different classes?
2. If there are actionListeners for the objects, then should i put them along with the creation of the objects?
3. While using cardLayout to manage which panel should be visible, i often had to convert all the fields related to a panel static so that i could modify fields in one panel on actionEvents in some other panel.
Is this a standard thing to do or should i be doing something different.
4. I use the terminal to write my codes. Since i have just started working on GUI, i thought working with terminal would be a more better learning experience.Should i continue using terminal or switch to some IDE like eclipse/netBeans ???
Thanks

What kind of program does you want to write : it is a game or just an application ? For each kind of thing, often, there are patterns to do this. Moreover, for each kind of game or application, there are many ways to build framework. In other word, it's diversity, and depend well on program.
Nevertheless, in general way, there are some suggestion when you start to design your program. For example, you can apply MVC (Model-View-Controller) to this by :
View : this is a GUI and just a GUI. it contains code to build a GUI, build action listener for some objects such as buttons .... when some action appears on this GUI, for example, someone click a button, it will call appropriate action in Controller. So, View, in fact, doesn't really understand anything. It doesn't know (and doesn't care) this button or that button should do what.
Controller : connect between View and model. It will initialize View and Model. It will receive action from View, and call appropriate method from model and return result again to view. Controller knows how to control flow of data from user.
Model : a class with bunch of action that your application can do. Model doesn't really know, how to operate your program, it just holds the state of program.
Hope this help :)

Separate user interface from domain in java Swing

As a Java Swing newbie, I have some trouble separating the user interface logic from the domain logic.
I have a small (trivial?) Swing app with a JFrame that contains a JLabel, JTextField and a JButton. When pressing the JButton a JFileChooser dialog pops up. After selecting a file, the JTextField contains the absolute path to the file. Nothing spectaculair so far.
The next thing I want to accomplish is that this absolute path of the file is 'injected' into a file manager class that will handle the actual processing of the file when the selection is made and the JTextField is updated (each time a file is selected using the JButton).
Questions I have:
How do I let the file manager know when to start reading the file? (for example count the number of lines within that file)
How can I implement the domain layer in such a way that minimal information is shared within the UI layer? Should I add a filemanager instance to the UI?
Should I use the value of the JTextField as the reference towards the file manager, or should I use the JButton action to set the value into the file manager? What I mean by that is: use propertychangelistener of JTextField OR use actionlistener of JButton?
Should I use a filebean to store the absolute path of the file within the domain layer or just directly insert it to the file manager? The difference is: when I use a property change listener the value of the absolute file path can be updated when the UI input changes, but when I insert the value directly using a contructor or setter, I have to handle the change in the file manager instead of handle the change in the filebean.
How can I reference the filebean that is used in the UI within the file manager within the domain logic?
Is the domain logic the same as the business logic? I mean: file manager class should be in package whatever.b-logic and filebean class should be in package whatever.domain??
The application is divided into several packages:
whatever : main class
whatever.presentation : swing stuff
whatever.domain : data stuff
whatever.logic : application logic
I hope I am clear enough...
Thanks in advance for clearing things up.

Personally, when I approach these kind of problems I try and look at re-usability and responsibility (who's responsible for what) as primary requirements.
That is, I try and get my models set up in such away so that they don't care about how or where the data is coming from or going to, they simple provide the interface access to make it happen.
To connect all the elements to together, I rely on the model providing events back to the client, cause the model shouldn't care about who wants to know, just provide the required functionality. So, in order to provide feedback to the client, I'd rely on a series of listeners.
I would break the listeners down into specific jobs, such notification of the file reading would be it's own listener, changes to the model (adding/removing/updating) the file beans would be another. Other notifications would be require different listeners, this stops you from creating monster listeners for which implementations don't really want to know about.
For setting values in the model, I would err on the side of property setters/getters. This decouples your model from the implementation (what if you are using the model in an automated fashion??)
Internal data would be best managed by the model if possible. That is, if you change a property on a file bean that the model is managing, the model should be capable of monitoring the change and dealing with it. Having said that, you may want a dumb model at some time in the future, where you could batch update a series of file beans and then ask the model to update itself.
I, personally, would probably provide the means for the model to be updated externally while providing at least one implementation capable of providing self monitoring, this gives you flexibility to chose the right model for the right situation.
There is also the danger of memory leaks here. If you don't properly remove any listeners from the file bean when you no longer need them, you could end up preventing the bean from been garbage collected at a later time.
Where possible, work with interfaces. This provides an great deal of flexibility when trying to pull these models together.
For what you describe, I would allow the file bean to be the responsibility of the file manager, such that the file manager becomes a container of file beans.
Depending on how large your project is and how you might want to reuse the code in the future will greatly effect the layout of the code.
I usually put UI code in a UI package and sub packages, but that's just me. I tend to separate interface content from implementation content (usually physically in separate Jar files, but again, that's me). This means that I only need to include the interface library and what ever implementation I might be using, using a factory of some sort to actually instantiate the implementation if required (or directly as is required). Think JDBC driver for example.
You want to look towards sphere's of responsibility. From what you describe, I feel that the file bean falls in the file manager's sphere of responsibility so I would bind the two together.
That's just my point of view

Here are a few suggestions:
Use SwingWorker, illustrated here, to keep the GUI lively while listening for progress.
Use Action, illustrated here, to encapsulate functionality.
Use File, a convenient, cross-platform abstraction. Use it to compose new abstractions, rather than pulling out non-cross-platform pieces.
Addendum: See also A Swing Architecture Overview and the answer.

Can Java self-modify via user input?

I'm interested in an executed script allowing user input to modify the process and corresponding source.
What precedents exist to implement such a structure?

Yes, depending on what is meant.
Consider such projects as ObjectWeb ASM (see the the ASM 2.0 tutorial for a general rundown).
Trying to emit the-would-need-to-be-decompiled Java source code is another story: if this was the goal then perhaps the source should be edited, re-compiled, and somehow loaded in/over. (This is possible as well, consider tools like JRebel.)
Happy coding.

You should not be able to modify existing classes. But if you implement a ClassLoader then you can dynamically load classes from non-traditional sources: network, XML file, user input, random number generator, etc.
There are probably other, better ways.

Maybe the Java scripting API is what you're looking for:
http://docs.oracle.com/javase/6/docs/api/javax/script/package-summary.html
http://docs.oracle.com/javase/6/docs/technotes/guides/scripting/programmer_guide/index.html

I wrote an app once that used reflection to allow tests to be driven by a text file. For instance, if you had a class like this:
class Tuner(String Channel) {
tune(){...
play(){...
stop(){...
}
You could execute methods via code like:
tuner=Channel 1
tune tuner
play tuner
stop tuner
It had some more capabilities (You could pass objects into other objects, etc), but mostly I used it to drive tests on a cable box where a full write/build/deploy in order to test took on the order of a half hour.
You could create a few reusable classes and tie them together with this test language to make some very complex and easy to create tests.
THAT is a DSL, not monkeying around with your loose-syntax language by eliminating parenthesis and adding underscores and dots in random locations to make it look like some strange semi-English.

Java SWT User Input Validation

What is the Java convention when it comes to user input validation in SWT? I read that there are FieldEditors which are very convenient fields but sadly only for preferences and dialogue boxes.
I also read that there is an IValidator interface. But it is often used with data binding, which is in my case, most of my inputs do not need any data binding yet. Also, IValidator requires me to write my own validation methods even for simple validations such as integer only, letters only, etc.
Since the FieldEditors cannot be applied in normal usage of input fields, what other convenient way can I use to do validation on user inputs? I am using SWT for my Java GUI.
Thanks!

You can validate the input of your control in a VerifyListener. See this forum thread for further explanation.
Alternatively, you can check out RCP Toolbox which has a built-in easy-to-use validation framework. See this article.