Loading ...
Sorry, an error occurred while loading the content.

Oferta de Trabalho 2001-11-06

Expand Messages
  • Magno Cavalcante
    ... Nova oferta de Emprego cadastrada no site do SouJava : Data...........: 31/10/2001 Tipo de Emprego: ANALISTA PROGRAMADOR JAVA
    Message 1 of 2 , Nov 5, 2001
    • 0 Attachment
      -------------------------------------------------------------

      Nova oferta de Emprego cadastrada no site do SouJava
      <http://www.soujava.org.br>:
      Data...........: 31/10/2001

      Tipo de Emprego: ANALISTA PROGRAMADOR JAVA
      Nome da Empresa: Fourway Informática
      Localizacao....: São Paulo

      Somos uma consultoria em informática e buscamos profissionais com o
      seguinte perfil:
      * Experiência de pelo menos 2,5 anos na ferramenta J2EE;

      Contato........: Juliana e Thais
      Telefone.......: 3872-4873/3871-5441 R: 121/114
      E-Mail.........: julianar@.../thaisf@...

      -------------------------------------------------------------

      Nova oferta de Emprego cadastrada no site do SouJava
      <http://www.soujava.org.br>:
      Data...........: 30/10/2001

      Tipo de Emprego: Consultor de sistemas
      Nome da Empresa: ESafetransfer
      Localizacao....: Sao Paulo / SP

      Experiência mínima de 3 anos em desenvolvimento de sistemas de missão crítica
      na internet, preferencialmente com Java. Amplos conhecimentos em O.O. e
      UML.
      O profissional irá desenvolver aplicativos tanto no Server quanto no
      lado Client, podendo se especializar em JavaCard.

      Maiores informações: www.esafetransfer.com

      Contato........: somente por email com CV em txt ou html no anexo
      E-Mail.........: rh@...

      -------------------------------------------------------------

      Nova oferta de Emprego cadastrada no site do SouJava
      <http://www.soujava.org.br>:
      Data...........: 1/11/2001

      Tipo de Emprego: ESTÁGIO
      Nome da Empresa: CETIP
      Localizacao....: RIO DE JANEIRO

      A Cetip está contratando um Estagiário paraintegrar sua equipe no
      Departamento de
      Desenvolvimento de Sistemas. A empresa tem sede no Rio de Janeiro, atua
      prestando serviços para o Mercado Financeiro em geral e tem atualmente em
      torno de 170 funcionários.

      A equipe de desenvolvimento atualmente trabalha em projeto de tecnologia
      de ponta, principalmente dentro de ambiente Java.

      O projeto final contará com mais de 1200 clientes dentro do Sistema
      Financeiro e está sendo desenvolvido em três camadas usando-se
      HTML, Java, C++ e Banco de Dados Oracle. Todo o desenvolvimento é feito
      com equipe interna e usando técnicas, ferramentase metodologias de Orientação
      a Objetos.

      O Perfil de Estagiário de Desenv. Sistemas, segue às seguintes premissas
      :
      Requisitos necessários :

      1) No mínimo cursando o 5o. período de Faculdade de Informática.
      2) Domínio do ambiente Microsoft Windows.
      3) Domínio de pelo menos uma linguagem de programação visual(Visual
      Basic, Delphi, Java, etc.).
      4) Disponibilidade : de 4h a 6h diárias.

      Requisitos desejáveis :
      1) Experiência (mesmo que acadêmica) em Orientação a Objetos.
      2) Experiência (mesmo que acadêmica) em desenvolvimento Web (HTML).
      3) Experiência (mesmo que acadêmica) com SQL e qualquer Banco de Dados
      Relacional.
      4) Experiência (mesmo que acadêmica) com qualquer Sistema Operacional
      Unix.
      5) Boa noção de Técnicas de Programação e Estruturas de Dados.

      Obs.:
      1) Não é necessário experiência profissional anterior.
      2) Existe a possibilidade de que os profissionais selecionados para o
      estágio sejam contratados em definitivo a partir do momento de sua
      formação superior completa e/ou do momento de disponibilidade para
      trabalho em horário integral, devendo para isso apresentar bom
      rendimento durante o período de estágio.

      Esperamos contatos pelo telefones 2276-7474 ou por email para
      lucia@... para que uma entrevista possa ser marcada em horário
      de conveniência mútua.

      Contato........: Lucia Mainart
      Telefone.......: (21)2276-7505
      E-Mail.........: lucia@...

      -------------------------------------------------------------

      Nova oferta de Emprego cadastrada no site do SouJava
      <http://www.soujava.org.br>:
      Data...........: 30/10/2001

      Tipo de Emprego: Desenvolvimento/Programação
      Nome da Empresa: confidencial
      Localizacao....: São Paulo-S.P.

      Para trabalhar com desenvolvimento de aplicativos para Internet.Bons
      conhecimentos de Java2EE,JSP,Servlets,EJB e base de dados Oracle.

      Oferecemos salário compatível com a função + benefícios.

      Contato........: John Hughes
      E-Mail.........: info@...

      -------------------------------------------------------------

      ------

      Atenciosamente,
      -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-
      Magno Cavalcante - falecom@...
      PGP Public Key -
      http://keys.pgp.com:11371/pks/lookup?op=get&search=Magno+Alves+Cavalcante
      -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-
    • Alexandre Bairos
      To: bairos@eng.uerj.br Subject: JDC Tech Tips November 6, 2001 J D C T E C H T I P S TIPS, TECHNIQUES, AND SAMPLE CODE WELCOME to the Java
      Message 2 of 2 , Nov 6, 2001
      • 0 Attachment
        To: bairos@...
        Subject: JDC Tech Tips November 6, 2001


        J D C T E C H T I P S

        TIPS, TECHNIQUES, AND SAMPLE CODE


        WELCOME to the Java Developer Connection(sm) (JDC) Tech Tips,
        November 6, 2001. This issue covers:

        * Using Method Pointers
        * Abstract Classes vs. Interfaces

        These tips were developed using Java(tm) 2 SDK, Standard Edition,
        v 1.3.

        You can view this issue of the Tech Tips on the Web at
        http://java.sun.com/jdc/JDCTechTips/2001/tt1106.html

        - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
        USING METHOD POINTERS

        Suppose that you're using the Java programming language to
        implement some type of a sort or search algorithm. Suppose too
        that you need to pass to the algorithm a comparator method, that
        is, a method used to compare and rank two elements.

        A low-level language such as C supports function pointers,
        which are memory addresses of functions. You can pass these
        pointers to library functions such as qsort(), and combine qsort
        and a comparator function you specify to perform arbitrary types
        of sorting.

        The Java programming language does not have pointers that are
        visible to the user, and there are no global functions (methods).
        Every method is a part of some class. So how can you designate
        a particular comparator method for use when you're sorting,
        searching, or doing similar kinds of operations? Here's one
        approach:

        class Compare {
        public int compare(Integer a, Integer b) {
        int aval = a.intValue();
        int bval = b.intValue();
        return aval < bval ? -1 :
        (aval == bval ? 0 : 1);
        }
        }

        public class MethPtr1 {
        static int compare_ab(
        Integer a, Integer b, Compare c) {
        return c.compare(a, b);
        }

        public static void main(String args[]) {
        Integer a = new Integer(47);
        Integer b = new Integer(37);

        int cmp = compare_ab(a, b, new Compare());

        if (cmp < 0) {
        System.out.println("a < b");
        }
        else if (cmp == 0) {
        System.out.println("a == b");
        }
        else {
        System.out.println("a > b");
        }
        }
        }

        In this example, the method compare_ab is a very simplified
        version of a sort method. It's passed two Integer objects, along
        with a comparator. The method then ranks the Integer objects,
        returning -1 if the first object is less than the second, 0 if
        they're equal, and 1 if the first object is greater than the
        second.

        The comparator is an instance of the Compare class that has a
        method compare defined within it. The instance is called a
        "function object," given that it defines a single method, and
        that method performs operations on other objects that are passed
        to the method.

        An instance of Compare is created each time compare_ab is
        called. This could be optimized by creating one instance of
        Compare to be used throughout the program, or by using a
        singleton class.

        The output of the program is:

        a > b

        The approach above does the job, but it has some problems. One is
        that there's a fixed ranking strategy built into the compare
        method. If you wanted to reverse the order of comparison, or take
        the absolute value of the numbers before comparing them, you'd be
        out of luck. Also, a standard sorting or searching algorithm is
        not going to know about a Compare class that you've defined; the
        algorithm has to be implemented in terms of a standardized
        mechanism.

        To solve these problems, you can change the program like this:

        import java.util.Comparator;

        class Compare implements Comparator {
        public int compare(Object a, Object b) {
        int aval = ((Integer)a).intValue();
        int bval = ((Integer)b).intValue();
        return aval < bval ? -1 :
        (aval == bval ? 0 : 1);
        }
        }

        public class MethPtr2 {
        static int compare_ab(
        Integer a, Integer b, Comparator c) {
        return c.compare(a, b);
        }

        public static void main(String args[]) {
        Integer a = new Integer(47);
        Integer b = new Integer(37);

        Comparator c = new Compare();
        int cmp = compare_ab(a, b, c);
        /*
        int cmp = compare_ab(
        a, b, new Comparator() {
        public int compare(
        Object aa, Object bb) {
        int aval = (
        (Integer)aa).intValue();
        int bval = (
        (Integer)bb).intValue();
        return aval < bval ? -1 :
        (aval == bval ? 0 : 1);
        }
        });
        */

        if (cmp < 0) {
        System.out.println("a < b");
        }
        else if (cmp == 0) {
        System.out.println("a == b");
        }
        else {
        System.out.println("a > b");
        }
        }
        }

        java.util.Comparator is a standard interface that specifies the
        compare method. This interface is used by other classes and
        methods, for example, Collections.sort. You implement this
        interface, defining whatever comparison method you desire.

        Note that it's possible to use an anonymous inner class to
        implement the Comparator interface. The example above shows an
        alternative that illustrates the use of an inner class. This
        approach is useful in situations where you only need to use the
        implementing class in one place.

        The example is a demonstration of programming using interface
        types. When the MethPtr2 program calls compare_ab, the program
        passes the method a Compare object. But the corresponding
        parameter in compare_ab is defined as a Comparator. This is
        roughly like saying:

        Comparator x = new Compare();

        This is valid because the Compare class implements the Comparator
        interface. Another common example from the Collections Framework
        is:

        List x = new ArrayList();

        Passing a method to another method, by means of a function object
        or interface, so that the passed-in method can be called, is
        sometimes referred to as a "callback." Here's a more explicit
        example of a callback:

        import java.util.*;

        interface Visitor {
        void visit(Object o);
        }

        class Walker {
        public static void walk(Object o, Visitor v) {
        if (o instanceof Map) {
        o = ((Map)o).entrySet();
        }
        if (o instanceof Collection) {
        Collection c = (Collection)o;
        Iterator iter = c.iterator();
        while (iter.hasNext()) {
        v.visit(iter.next());
        }
        }
        else {
        throw new IllegalArgumentException();
        }
        }
        }

        public class MethPtr3 implements Visitor {
        public void visit(Object o) {
        System.out.println(o);
        }

        void doit() {
        List data1 = new ArrayList();
        data1.add("test11");
        data1.add("test12");
        data1.add("test13");
        Walker.walk(data1, this);

        Set data2 = new TreeSet();
        data2.add("test21");
        data2.add("test22");
        data2.add("test23");
        Walker.walk(data2, this);

        Map data3 = new HashMap();
        data3.put("test31key", "test31value");
        data3.put("test32key", "test32value");
        data3.put("test33key", "test33value");
        Walker.walk(data3, this);
        }

        public static void main(String args[]) {
        new MethPtr3().doit();
        }
        }

        Suppose that you have a collection data structure, that is, a
        List, Set, or Map, and you'd like to write a utility method that
        traverses the structure. As each element is visited, you'd also
        like to call a method that you specify. The program above does
        this.

        Walker.walk is a static method that accepts a reference to a data
        structure, along with an object of a class that implements the
        Visitor interface. The method uses iterators to traverse the
        structure, and it calls back to the visit method defined in the
        MethPtr3 class. When you run this program, the result is:

        test11
        test12
        test13
        test21
        test22
        test23
        test32key=test32value
        test31key=test31value
        test33key=test33value

        Most of the time, using function objects and interfaces is the
        right approach to implementing method pointers. But there's
        another mechanism that's important to know. Suppose that you're
        writing a debugger, interpreter, or similar type of program, and
        you want it look up and call methods by their string name. In
        other words, the user specifies a method name, and your program
        calls this method. How would you do this?

        This task is impossible in many other programming languages, but
        Java's reflection features make it easy. Here's an example:

        import java.lang.reflect.*;

        class A {
        public void f1() {
        System.out.println("A.f1 called");
        }
        public void f2() {
        System.out.println("A.f2 called");
        }
        }

        class B {
        public void f1() {
        System.out.println("B.f1 called");
        }
        public void f2() {
        System.out.println("B.f2 called");
        }
        }

        public class MethPtr4 {
        static void callMethod(Object obj, Method meth)
        throws Exception {
        meth.invoke(obj, null);
        }

        static void findMethod(String cname, String mname)
        throws Exception {
        Class cls = Class.forName(cname);
        Method meth = cls.getMethod(mname, new Class[]{});
        callMethod(cls.newInstance(), meth);
        }

        public static void main(String args[]) throws Exception {
        if (args.length != 2) {
        System.err.println("missing class/method names");
        System.exit(1);
        }

        findMethod(args[0], args[1]);
        }
        }

        After you compile this program, run it as follows:

        java MethPtr4 A f2

        Here you're specifying a class (A) and a method in the class to
        be invoked (f2). The findMethod method loads a class
        (Class.forName), and then finds a method within the class. Both
        the class and method names are specified by strings. After the
        method is found, it is represented by a Method object. The object
        is passed to the callMethod method, along with an object of the
        appropriate class.

        This approach is powerful, but it's best not to use it unless you
        really need it. For example, if you say:

        java MethPtr4 A f3

        you get an exception. By contrast, if you're not using
        reflection, and you call a nonexistent method (f3) in your
        program, you get a compile error. In other words, when you call
        a method using reflection, some of the checking a compiler does
        is necessarily deferred.

        For more information about using method pointers, see
        Section 11.2.6, The Method Class, in "The Java(tm) Programming
        Language Third Edition" by Arnold, Gosling, and Holmes
        http://java.sun.com/docs/books/javaprog/thirdedition/. Also see
        item 22, Replace function pointers with classes and interfaces,
        in "Effective Java Programming Language Guide" by Joshua Bloch
        (http://java.sun.com/docs/books/effective/).

        - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
        ABSTRACT CLASSES VS. INTERFACES

        In the JDC Tech Tips for October 9, 2001
        (http://java.sun.com/jdc/JDCTechTips/2001/tt1009.html), there was
        an item about using an abstract class hierarchy to implement the
        Java equivalent of a C union. The code looked something like
        this:

        abstract class Time {
        public abstract int getMinutes();
        }

        class Days extends Time {
        private int days;
        public int getMinutes() {
        return days * 24 * 60;
        }
        }

        class HoursMinutes extends Time {
        private int hours;
        private int minutes;
        public int getMinutes() {
        return hours * 60 + minutes;
        }
        }

        A reader asked why an interface could not be used instead of an
        abstract class, with the code written as follows:

        interface Time {
        int getMinutes();
        }

        class Days implements Time {
        private final int days;
        public Days(int days) {
        this.days = days;
        }
        public int getMinutes() {
        return days * 24 * 60;
        }
        }

        class HoursMinutes implements Time {
        private final int hours;
        private final int minutes;
        public HoursMinutes(int hours, int minutes) {
        this.hours = hours;
        this.minutes = minutes;
        }
        public int getMinutes() {
        return hours * 60 + minutes;
        }
        }

        public class AIDemo1 {
        public static void main(String args[]) {
        Time t1 = new Days(10);
        Time t2 = new HoursMinutes(15, 59);
        System.out.println(t1.getMinutes());
        System.out.println(t2.getMinutes());
        }
        }

        In fact, the interface approach does work. However, there are
        a series of tradeoffs between the use of abstract classes and
        interfaces. This tip examines some of those tradeoffs.

        Both of these mechanisms define a contract, that is, required
        behavior that another class must implement. If you have the
        following definitions:

        abstract class A {
        abstract void f();
        }

        interface B {
        void f();
        }

        then a concrete class that extends A must define f. A class that
        implements B must define f.

        Beyond this common feature, the two mechanisms are quite
        different. Interfaces provide a form of multiple inheritance
        ("interface inheritance"), because you can implement multiple
        interfaces. A class, by comparison, can only extend
        ("implementation inheritance") one other class. An abstract class
        can have static methods, protected parts, and a partial
        implementation. Interfaces are limited to public methods and
        constants with no implementation allowed.

        So what's the difference between using abstract classes and
        interfaces in the example above? One difference is that an
        abstract class is easier to evolve over time. Suppose that you
        want to add a method:

        public int getSeconds();

        to the Time contract. If you use an abstract class, you can say:

        public int getSeconds() {
        return getMinutes() * 60;
        }

        In other words, you provide a partial implementation of the
        abstract class. Doing it this way means that subclasses of the
        abstract class do not need to provide their own implementation of
        getSeconds unless they want to override the default version.

        If Time is an interface, you can say:

        interface Time {
        int getMinutes();
        int getSeconds();
        }

        But you're not allowed to implement getSeconds within the
        interface. This means that all classes that implement Time are
        now broken, unless they are fixed to define a getSeconds method.
        So if you want to use an interface in this situation, you need to
        be absolutely sure that you've got it right the first time. That
        way you don't have to add to the interface at a later time,
        thereby invalidating all the classes that use the interface.

        Another issue with this example is that you might want to factor
        out common data into the abstract class. There is no equivalent
        to this functionality for interfaces. For example, if you say:

        interface A {
        int x = 7;
        }

        class B implements A {
        void f() {
        int i = x; // OK
        x = 37; // error
        }
        }

        all is well if you want to declare a constant in the interface,
        but it's not possible to declare a mutable data field this way.

        Let's look at another example:

        import java.io.*;

        interface Distance {
        double getDistance(Object o);
        }

        interface Composite extends Comparable,
        Distance, Serializable {}

        class MyPoint implements Comparable, Distance, Serializable {
        //class MyPoint implements Composite {

        private final int x;
        private final int y;

        public MyPoint(int x, int y) {
        this.x = x;
        this.y = y;
        }

        public int getX() {
        return x;
        }
        public int getY() {
        return y;
        }

        public int compareTo(Object o) {
        MyPoint obj = (MyPoint)o;
        if (x != obj.x) {
        return x < obj.x ? -1 : 1;
        }
        return y < obj.y ? -1 : (y == obj.y ? 0 : 1);
        }

        public double getDistance(Object o) {
        MyPoint obj = (MyPoint)o;
        int sum = (x - obj.x) * (x - obj.x) +
        (y - obj.y) * (y - obj.y);
        return Math.sqrt(sum);
        }
        }

        public class AIDemo2 {
        public static void main(String args[]) {
        MyPoint mp1 = new MyPoint(1, 1);
        MyPoint mp2 = new MyPoint(2, 2);

        double d = mp1.getDistance(mp2);
        System.out.println(d);

        int cmp = mp1.compareTo(mp2);
        if (cmp < 0) {
        System.out.println("mp1 < mp2");
        }
        else if (cmp == 0) {
        System.out.println("mp1 == mp2");
        }
        else {
        System.out.println("mp1 > mp2");
        }
        }
        }

        MyPoint is a class that represents geometric X,Y points, with the
        usual constructor and accessor methods defined. The class
        implements three interfaces. One interface is used to compare one
        point to another, one is used to compute the Euclidean distance
        between points, and the last declares that MyPoint objects are
        serializable.

        An alternate approach would be to define a new interface
        Composite (called a "subinterface") that extends the three
        interfaces, and then implement Composite in MyPoint. This is an
        example of a "nonhierarchical type framework".

        The output of the program is:

        1.4142135623730951
        mp1 < mp2

        It's easy to retrofit an existing class to implement a new
        interface. Doing this is sometimes called a "mixin." In a mixin,
        a class declares that it provides some optional, side behavior in
        addition to its primary function. Comparable is an example of
        a mixin.

        Note that it would be awkward to implement the AIDemo2 example
        using abstract classes. Implementing several unrelated interfaces
        in a class is hard to duplicate using abstract classes.

        It's often desirable to combine interfaces and abstract classes.
        For example, part of the design of the Collections Framework
        looks roughly like this:

        interface List {
        int size();
        boolean isEmpty();
        }

        abstract class AbstractList implements List {
        public abstract int size();
        public boolean isEmpty() {
        return size() == 0;
        }
        }

        class ArrayList extends AbstractList {
        public int size() {
        return 0; // placeholder
        }
        }

        At the top of the hierarchy are interfaces, such as Collection
        and List, that describe a contract, that is, a specification of
        required behavior. At the next level are abstract classes, such
        as AbstractList, that provide a partial implementation. Note that
        size is not defined in AbstractList, but that isEmpty is defined
        in terms of size. If a list has zero size, it is empty by
        definition. A concrete class, such as ArrayList, then defines any
        abstract methods not already defined.

        If you use this scheme, and program in terms of interface types
        (List instead of ArrayList), there are several benefits:

        o Much of the implementation work is already done for you in the
        abstract classes.

        o You can easily switch from one implementation to another
        (LinkedList instead of ArrayList).

        o If ArrayList or LinkedList are not satisfactory, you can
        develop your own class that implements List.

        o If you cannot extend a given class, because you're already
        extending another class, you can instead implement the
        interface for the desired class and then forward method calls
        to a private instance of the desired class.

        Interfaces tend to be a better choice than abstract classes in
        many cases, though you need to get the interface right the first
        time. Changing the interface after the fact will break a lot of
        code. Abstract classes are useful when you're providing a partial
        implementation. In this case, you should also define an interface
        as illustrated above, and implement the interface in the abstract
        class.

        For more information about abstract classes vs. interfaces, see
        Section 4.4, Working with Interfaces, and Section 4.6, When to Use
        Interfaces, in "The Java(tm) Programming Language Third Edition"
        by Arnold, Gosling, and Holmes
        http://java.sun.com/docs/books/javaprog/thirdedition/. Also see
        item 14, Favor composition over inheritance, and item 16,
        Prefer interfaces to abstract classes, in "Effective Java
        Programming Language Guide" by Joshua Bloch
        (http://java.sun.com/docs/books/effective/).

        . . . . . . . . . . . . . . . . . . . . . . .

        IMPORTANT: Please read our Terms of Use and Privacy policies:
        http://www.sun.com/share/text/termsofuse.html
        http://www.sun.com/privacy/

        * FEEDBACK
        Comments? Send your feedback on the JDC Tech Tips to:
        jdc-webmaster@...

        * SUBSCRIBE/UNSUBSCRIBE
        - To subscribe, go to the subscriptions page,
        (http://developer.java.sun.com/subscription/), choose
        the newsletters you want to subscribe to and click "Update".
        - To unsubscribe, go to the subscriptions page,
        (http://developer.java.sun.com/subscription/), uncheck the
        appropriate checkbox, and click "Update".
        - To use our one-click unsubscribe facility, see the link at
        the end of this email:

        - ARCHIVES
        You'll find the JDC Tech Tips archives at:

        http://java.sun.com/jdc/TechTips/index.html


        - COPYRIGHT
        Copyright 2001 Sun Microsystems, Inc. All rights reserved.
        901 San Antonio Road, Palo Alto, California 94303 USA.

        This document is protected by copyright. For more information, see:

        http://java.sun.com/jdc/copyright.html

        This issue of the JDC Tech Tips is written by Glen McCluskey.

        JDC Tech Tips
        November 6, 2001

        Sun, Sun Microsystems, Java, and Java Developer Connection are
        trademarks or registered trademarks of Sun Microsystems, Inc. in
        the United States and other countries.

        To use our one-click unsubscribe facility, select the following URL:
        http://hermes.java.sun.com/unsubscribe?41516511252964891
      Your message has been successfully submitted and would be delivered to recipients shortly.