This week's book giveaway is in the OO, Patterns, UML and Refactoring forum.
We're giving away four copies of Five Lines of Code and have Christian Clausen on-line!
See this thread for details.
Win a copy of Five Lines of Code this week in the OO, Patterns, UML and Refactoring forum!

Jack Dwaltz

Greenhorn
+ Follow
since May 12, 2008
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
5
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Jack Dwaltz

Hi everybody, and welcome to John.

My question is about the high availability of the solutions.
We are told to design microserevices to fail fast in order to be easily restartable for a greater robustness of our solution.
My biggest experience is with Java EE platforms, where the application servers deals with the high availability and restarting of failing processes/threads.
I ask hence if you discuss how to implement a rubust solution, highly available to an enterprise grade

thanks in advance
dwaltz
2 years ago
Two key ingredients of functional programming are:
  • to be able to pass functions as arguments to other functions
  • use functions that have no "side effects"

  • The ability to pass functions as arguments to functions enables you to write simple solution for some problems, e.g. based on recursion etc.
    I will not go into details here.

    For the second point: a function has a side effect when it changes a shared state.
    In OO a shared state is, e.g., the internal state of any object shared among different threads, in procedural programming the shared state is in global variables or variables shared with pointers among threads.

    To create a function with no side effects, instead of writing the results it computes in the objects or referenced variables it receives, simply put the results in new objects or variables.

    E.g.: a function that computes sqrt(x) can be easily written with no side effects: you simply use local variable in your computation and return the computed value in a new variable not affecting the input value x.
    Another example: if you want to write a "no side effect" sorting of a list you don't use the method sort() on the object representing the list, rather you define a function sort() that accepts a list object, copies its content in a new list, sorts that, and returns it.

    Why would you want to do that? Simply because in this way you can write concurrent code without doing heavy synchronization.
    On modern computers we have multi-core cpus, to use them at best we must multithread efficiently, so any code should try to minimize locking for synchronization as much as possible.
    If you return all your computed result as new objects or values, and never modify anything you receive in input, you can write algorithms that scale naturally with no need of locking to implement synchronization.
    5 years ago

    Tomas Linhart wrote:
    I'd like to ask what is your recommended approach to using design patterns. Shall a programmer always start with looking for a appropriate design pattern when solving some problem, or should it emerge from his initial effort to find the solution?



    Well sometimes people tend to abuse of patterns, and I would suggest to study GoF patterns outside of Java EE, writing your own small sample programs to test if you got the point, and the benefits. Don't just copy and paste a sample to test it.
    Later you can try with Java EE specific patterns: search Java EE blueprints, or have a look at EAI patterns and Martin Fowler book: Pattern of Entrerprise Application Architecture, and the text presented here of course.

    Tomas Linhart wrote:pattern usage. Also, are there any design patterns (I mean the original from GoF), that are outdated, or that you would not recommend to use? I often hear this for example about Singleton pattern (though I've never really understood the "why").


    Some think the singleton is broken, I don't, and Java EE even has a @Singleton annotation for services that starts a single instance (beware, one in each server you start of you run a cluster).
    You can think that dependency injection (CDI in Java EE) is a replacement for the factory o builder patterns, but in general any pattern has it uses and times you can do without, and sometimes you use them not knowing that you do (see e.g. Java IO patterns).
    Learn to use them by doing some test programs and reading.

    Jaikiran Pai wrote:In the context of EJBs, remote refers to EJB components that belong to different applications/deployments even if they are on the same JVM.



    The client can also be a Java SE application that makes a lookup for the remote interface: e.g. a Java program running on a different JVM on the same or a different computer.

    Luk Cora wrote:It say that I need at least jdk5 but what about application server?



    Well for sure you need some sort of Java, no necessarely from Oracle though. IBM has JVM, OpenJDK is an open source option.
    The precise version depends on the version of the Application server.

    Luk Cora wrote:And if I don't want to use jboss but glassfish, weblogic or others?


    Well Java EE i supposed to work in some sort of EE container that manages transactions and all the Java EE services.
    So unless you want to write by yourself, you better get one.
    Besides the one you quote there are other options like Geronimo, TomEE ot JonAS Wikipedia some of this implment a subset called "Java EE Web profile".
    For a comparison of the full vs web profile se e.g. this:
    Web vs full
    On top of that if you need only Servlets and JSPs you can limit yourself to a Servlet container like Tomcat or Jetty.

    rajesh vass wrote:why do we create private constructors in java classes?



    to make them private which means they cannot be used from outside that class.
    A constructor is always required but if it is private it can be used only by another method of the same class, not even from a subclass.

    If you make all of them private no class instance can exist before having used any constructor and hence you need a static factory.

    rajesh vass wrote:And for creating that class object we give static factory methods.



    "One advantage of static factory methods is that, unlike constructors, they have names"

    a method name can better describe what sort of object you are building out of that class.

    "A second advantage of static factory methods is that, unlike constructors, they are not required to create a new object each time they’re invoked."

    so you can build singletons classes or, more generally cache invariant object instances: especially if they take a lot of time to build.

    "A third advantage of static factory methods is that, unlike constructors, they can return an object of any subtype of their return type."

    this gives you more flexibility.
    E.g. you can have an abstract class and several hidden implementations that depend on the parameters you use to build the object that provide better performances.

    All this is well explained in "Effective Java 2nd ed." by Joshua Bloch were I got the quotations from.


    8 years ago
    A Java Bean is a Java class that has getters and setters in order to conform to Java-bean standards.
    Essentially you declare properties private and use getters and setters to read or modify the data.
    The standardization was introduced to enable automatic access to properties via Java reflection to automate some activity performed e.g. by application servers.

    A POJO is a “plain old java object” hence and instance of a simple java class: the term is used to contrast to the EJB (Enterprise Java Beans).
    Enterprise beans are the Java beans used in JEE applications that are Java Beans that live in an application server that enables inter process communication and remote communication, dealing also with transactions and security.

    The term was used to mean "go back to simple objects" and stop using Java EE.

    The term “Value Objects” is used with different meanings.
    Some call a value-object a DTO: which usually is aq class with no logic use only to pack information in a single item like a C Struct.

    But the most wide-spread interpretation is a type of object that does not exist (yet) in Java.

    The difference is determined by the behaviour of the assignment of such an object to another one.

    In java a Struct or a Class are the same and any instance derived from a Class/Struct is an object used with the “reference logic”.
    Hence when you do an assignment of an object you copy a reference to a memory address that holds the data associated with object.

    In C# instead a Struct is a Value Object and is different from a Class.
    In this case if you assign an object implementing a struct the value is copied and not a reference to the object.

    The memory management is also different since the data of a Struct in C# is kept in the stack while for the classes the data is stored in the heap and the reference in the stack.
    This helps in performance.
    9 years ago

    Luqman Ghani wrote:Thanks,...
    Now I understand why every class has a main in it.



    actually at least one should have a main in it. The one you ask to the JVM to execute. The possible main() of other classes will be ignored.
    9 years ago
    Java for sure has a large basis in server usage: mostly thanks to the fact it has good support for security and makes muti-threaded programming simpler than former technologies (C/C++).
    This will last for years or even decades: I don't see yet the technology that will supersede Java in this place.

    For the development of GUI based programs C#, C++ and VB are mostly used under windows and C++, python under Linux, and Objective-C is having a second youth in the iOS world.

    In the clouds Java (with signed applets) is sometimes used as an alternative to Flash to enable to overcome the limitations imposed by HTML/Javascript and the browser security restrictions.

    While for the ubiquitous computing part for sure Java has a little advantage of being interoperable with many devices/OSs.
    For sure C++ is also available in many devices, but it is not as easy as Java for the developer, while Objective-C and C# apply to a more restricted market.
    C# might have a future in that direction thanks to C# porting to Linux via Mono.





    9 years ago

    Henry Wong wrote:

    Rahul Sudip Bose wrote:Can anyone tell me what it is in a nutshell, without going into technical details. What is its use and is it popular ?



    JMS is an abstraction layer for various messaging systems, such as TIBCO EMS, IBM MQ, Active MQ, Informatica UM, etc.


    JMS is a Java API for MOM. A MOM is a Message Oriented Middleware.

    A Middleware is a software/hardware that stays in the middle of other software components enabling somehow to exchange/share information.
    Usually a middleware is used to enable two separate computer systems/applications to communicate with each other.
    A MOM hence is a middleware that exchanges information using “messages”: sowhat similar to e-mail service but for application-to-application instead of human-to-human communication.
    A message can be as simple as a string of text, or more structured like an XML, JSON notation.

    As stated the JMS is only an API.

    TIBCO EMS, IBM MQ, Active MQ, Informatica UM, either are JMS imlementations or MOMs that inlude an implementations of this API.
    SUN (now Oracle) also has a “reference implementation” of the JMS API distributed with GlassFish, the reference implementation of the JEE application server.
    You can use this implementation as stand-alone (not using a full JEE application server).
    9 years ago

    Pat Farrell wrote:Real Soon Now. or not.

    I've been writing for a while that Java's multi-thread support is too hard to implement.
    ...



    For what it matters, it is far simpler than doing it in C/C++ and that is what is mostly used elsewere.
    If you want to preserve your Java classes and get something easier to implemet parallelism have a look at Scala language: that language has features, like erlang language that someone quoted, that make it simple to create "workers" (look in the Scala By example guide pa. 17.9).

    The point anyway is that to get real advantages you have to change the way you think your code: abolish the "shared state" and your code will become easier to be parallelized: have a look at Van Roy's Programming Paradigms for Dummies.
    10 years ago
    I would say: above all concurrent programming simpler than in Java.
    If I had to develop a new system that does heavy concurrent computation I would seriously consider Scala.

    Functional programming is also important: it takes a bit to get used to, but once you do, you really have a new powerful tool in your pocket.
    10 years ago
    For a book on patterns in Java here a couple of links:

    GOF in Java
    Java Patterns

    on scribd you need to register and signin to downlaod the pdf.

    Edvins Reisons wrote:Have you tried mapping two classes, with different levels of detail, to that one table?



    That is a dirty trick but works. Cool idea.
    Another option could be simply to have the data spread over two tables in 1 to 1 realation to each other, that share the primary key.

    vinoth ar wrote:hi friends,
    I heard that the EJB is an outdated technology



    The answer is not.
    But it depends on what you are going to work on/with.
    For sure in many cases other approaches could be more to the point.
    There are tons of frameworks in the Java world and plenty of solutions based on different languages, like dynamic languages (Ruby/Python/Perl), or C# or the dear ol C/C++.

    The point is that EJB is a simple tecnology to work with in the 3rd version, so if you know Java, it should not take to much time to you to learn a bit on how it works. And later you will have an extra tool in your pocket.

    If you want to work with componenets you might consider to study OSGI as well. (I don't think there is need to name SOA as I guess you hear already to much about it).