General archivos - Página 9 de 9

Invocar al recolector de basura

octubre 18, 2026agosto 22, 2011 por ant

Java y otros lenguajes tienen un mecanismo de liberación de memoria llamado Garbage Collector, el cual permite reutilizar la memoria durante la ejecución de un programa. Se puede llamar al recolector de basura utilizando System.gc() o Runtime.getRuntime.gc(). Aunque hacer esto no se considera buena práctica ya que tiene repercusiones importantes en el rendimiento de una aplicación. La mejor práctica es no tener que llamar a estos métodos haciendo un buen diseño y uso de los recursos.

La descripción en la documentación para estos métodos es la siguiente:

System.gc()

Hace correr al recolector de basura.

Al llamar al método gc se sugiere a la máquina virtual realice un esfuerzo de reciclaje de objetos no utilizados con el fin de hacer que la memoria que estos objetos ocupan esté disponible para su uso rápido. Cuando se devuelve el control de la llamada al método, la maquina virtual de java ha hecho su mejor esfuerzo para recuperar el espacio de los objetos desechados.

La llamada System.gc() es efectivamente equivalente a la llamada Runtime.getRuntime.gc()

Runtime.getRuntime.gc()

Hace correr al recolector de basura. Al llamar a este método se sugiere a la maquina virtual realice su mayor es fuerzo de reciclaje de objetos no utilizados con el fin de hacer que la memoria que estos objetos ocupan esté disponible para su uso rápido. Cuando se devuelve el control de la llamada a al método, la máquina virtual ha hecho su mejor esfuerzo para recuperar el espacio de los objetos desechados.

La maquina virtual lleva a cabo este proceso de reciclaje de forma automática cuando es necesario, en un hilo separado, incluso si el método gc no se invoca explícitamente.

El método System.gc() es el medio convencional y conveniente de la invocación de este proceso. En algunas ocasiones esta invocación no tendrá mayor efecto, ya que la liberación de recursos nunca está garantizada.

Java versión 7

octubre 18, 2026agosto 17, 2011 por ant

Oracle ha lanzado la versión 7 de Java. Algunas de las mejoras las listamos a continuación.

Maquina Virtual

JSR 292: Soporte para lenguajes escritos dinámicamente (InvokeDynamic)
Revisión estricta de archivos clase

Lenguaje

JSR 334: Mejoras pequeñas al lenguaje (Project Coin)

Core

Actualización de la arquitectura de carga de clases
Método para cerrar un URLClassLoader
Actualizaciones a concurrencia y colecciones (jsr166y)

Internacionalización

Soporte a Unicode 6.0
Mejoras en la API Locale
Localización de usuario separada y localización interfaz de usuario

IO y Networking

JSR 203: Nuevas APIs IO para la plataforma Java (NIO.2)
Un proveedor de sistema de archivos NIO.2 para archivos zip/jar
SCTP (Protocolo de transmisión de control de flujos)
SDP (Protocolo directo de sockets )
Uso de la pila IPv6 de Windows Vista
Soporte para TLS 1.2

Seguridad y Criptografía

Implementación de criptografía elliptic-curve (ECC)

Conectividad y Bases de Datos

JDBC 4.1

Cliente

XRender para Java 2D
Permite crear nuevas plataformas para gráficas 6u10
Nuevo look-and-feel Nimbus
Componente JLayer para Swing
Sintetizador de sonido Gervill

Web

Actualización de la pila de XML

Administración

MBeans mejorados

Mejoras diferidas a la versión de JDK8 o superiores

JSR 294: Soporte a la máquina virtual y al lenguaje para programación modular
JSR308: Anotaciones sobre tipos de java
JSR TBD: Proyecto Lambda
Modularización (Proyecto Jigsaw)
JSR 296: Marco de trabajo para aplicaciones Swing
Componente Swing JDatePicker

Puedes ver mas detalle en el artículo original de openjdk.java.net en:

http://openjdk.java.net/projects/jdk7/features/

Commons IO: leer un archivo y listar directorios con FileUtils

octubre 18, 2026agosto 15, 2011 por ant

FileUtils, de Apache Commons IO, resume en una línea tareas con archivos que con java.io llevaban diez. Este es el ejemplo de siempre, leer un archivo y listar los de ciertas extensiones, puesto al día. Y al lado, la versión con java.nio, que hoy hace casi lo mismo sin añadir nada.

La dependencia

<dependency>
    <groupId>commons-io</groupId>
    <artifactId>commons-io</artifactId>
    <version>2.22.0</version>
</dependency>

Es la última versión publicada en Maven Central. Si no usas Maven, basta con descargar el .jar y añadirlo al classpath.

El ejemplo

import org.apache.commons.io.FileUtils;
import java.io.File;
import java.io.IOException;
import java.nio.charset.StandardCharsets;
import java.util.Collection;

public class Prueba {
    public static void main(String[] args) throws IOException {
        File archivo = new File("ejemplo.txt");
        String contenido = FileUtils.readFileToString(archivo, StandardCharsets.UTF_8);
        System.out.println("contenido: " + contenido.strip());

        String[] extensiones = {"xml", "java", "dat"};
        Collection<File> archivos = FileUtils.listFiles(new File("proy"), extensiones, true);
        for (File f : archivos) {
            System.out.println("> " + f.getPath());
        }
    }
}

Lo probamos con un ejemplo.txt de una línea y una carpeta proy con seis archivos, de los que solo tres tienen las extensiones que buscamos:

javac -cp commons-io-2.22.0.jar Prueba.java
java -cp .:commons-io-2.22.0.jar Prueba

salidacontenido: Hola desde decodigo.com
> proy/pom.xml
> proy/src/main/java/ejemplo/App.java
> proy/datos/clientes.dat

Encontró el .xml, el .java y el .dat, en cualquier nivel de subcarpetas, y dejó fuera el .txt, el .md y el .class. El orden es el que devuelve el sistema de archivos, que no tiene por qué ser alfabético.

Lo que cambió desde la versión de 2011

El código original llamaba a readFileToString(archivo) sin indicar la codificación. Ese método está obsoleto:

javac -Xlint:deprecationVieja.java:6: warning: [deprecation] readFileToString(File) in FileUtils has been deprecated
        System.out.println(FileUtils.readFileToString(new File("ejemplo.txt")).strip());
                                    ^
1 warning

Sin codificación, el archivo se lee con la del sistema, y el mismo programa puede leer bien los acentos en un equipo y mal en otro. Por eso hay que pasar siempre StandardCharsets.UTF_8 (o la que tenga el archivo). El otro cambio es de estilo: la lista ahora es una Collection<File> con tipo, y se recorre con un for normal, sin Iterator ni conversiones.

Lo mismo sin dependencias

import java.io.IOException;
import java.nio.file.*;
import java.util.Set;
import java.util.stream.Stream;

void main() throws IOException {
    String contenido = Files.readString(Path.of("ejemplo.txt"));
    IO.println("contenido: " + contenido.strip());

    Set<String> extensiones = Set.of("xml", "java", "dat");
    try (Stream<Path> rutas = Files.walk(Path.of("proy"))) {
        rutas.filter(Files::isRegularFile)
             .filter(p -> {
                 String n = p.getFileName().toString();
                 int punto = n.lastIndexOf('.');
                 return punto > 0 && extensiones.contains(n.substring(punto + 1));
             })
             .sorted()
             .forEach(p -> IO.println("> " + p));
    }
}

java SinDependencias.javacontenido: Hola desde decodigo.com
> proy/datos/clientes.dat
> proy/pom.xml
> proy/src/main/java/ejemplo/App.java

Files.readString lee en UTF-8 por omisión, y Files.walk recorre el árbol. Filtrar por extensión lleva unas líneas más que con FileUtils, pero no hace falta ningún .jar. Aquí además las ordenamos con sorted(). El try con recursos es necesario, porque Files.walk deja abiertos los directorios hasta que se cierra el stream.

Para…	Commons IO	java.nio (JDK)
Leer un archivo entero	`FileUtils.readFileToString(f, UTF_8)`	`Files.readString(ruta)`
Escribir un archivo	`FileUtils.writeStringToFile(f, texto, UTF_8)`	`Files.writeString(ruta, texto)`
Listar por extensión, recursivo	`FileUtils.listFiles(dir, exts, true)`	`Files.walk` + filtro
Copiar un directorio entero	`FileUtils.copyDirectory(a, b)`	a mano, con `Files.walk`
Borrar un directorio con contenido	`FileUtils.deleteDirectory(dir)`	a mano, con `Files.walk` al revés

Para leer y escribir, java.nio basta. Commons IO sigue ahorrando trabajo en las operaciones con directorios enteros, como copiarlos o borrarlos. Las vemos, con sus salidas, en FileUtils de Commons IO.

Entrada publicada en 2011 y revisada en octubre de 2026. Todo el código se compiló y se ejecutó con Java 25 LTS en un contenedor limpio con Commons IO 2.22.0; las salidas están copiadas de esa ejecución.

Errores comunes en la ejecución de proyectos de TI

octubre 18, 2026marzo 2, 2010 por ant

¿Quién no ha incurrido en estos errores? Si ya llevas algún tiempo desarrollando, seguro has sufrido por alguno de ellos.

La lista de errores más frecuentes encontrados en la ejecución de los proyectos de TI:

Errores relacionados con la gente

Miembros del equipo desmotivados
Falta de capacitación de la gente involucrada en el desarrollo
Personas problemáticas en el equipo
Agregar más programadores a un proyecto ya retrasado
Oficinas ruidosas y aglomeradas
Fricciones entre quienes desarrollan y el cliente
Expectativas poco realistas
Falta de un líder efectivo para el proyecto
Falta de participación del usuario
Falta de acuerdo antes que el desarrollo de inicio
Las “Ilusiones”

Errores relacionados con los procesos

Planeación demasiado optimista
Falta de administración de riesgos
Falla en los contratos
No hay suficiente planeación
Abandono del plan bajo presión
Pérdida de tiempo al inicio del proyecto
Saltarse las tareas iniciales
Diseño no adecuado
Falta de supervisión por parte de los responsables
Falta de estimaciones adecuadas
Errores relacionados con el producto
Requerimientos excesivos
Cambio de requerimientos
Developers muy meticulosos

Errores relacionados con la tecnología

Síndrome de la panacea
Sobre-estimación de las ventajas del uso de una nueva herramienta
Cambio de herramientas a mitad del proyecto
Falta de un control de código fuente automático

Seguramente ya hay muchos mas.

Y ahora algunas de las razones por las que se incurre en estos errores:

Errores relacionados con la gente

Miembros del equipo desmotivados. Es casi imposible encontrar gente que se enamore de todos los proyectos.
Falta de capacitación de la gente involucrada en el desarrollo. «La gente que va comenzando es la que cobra menos, ¿Y por qué no meter solo becarios?» ¡Típico!
Personas problemáticas. Dime si no has estado junto al tipo que cree saber más que el líder de proyecto, pero no lleva más de unas semanas en un proyecto real (los de la escuela no cuentan). O bien, gente que simplemente no está bien con la vida ¡Y se dedicó a programar!
Agregar más programadores a un proyecto ya retrasado. Y como además no es necesario capacitarlos, explicarles las reglas de negocio, explicarles lo que quisieron hacer los otros programadores (que seguro ya no se acuerdan o ya ni están).
Oficinas ruidosas y aglomeradas. «Son programadores, no personas y solo necesitan una PC delante de ellos y unas mesas de madera»
Fricciones entre los developers y el cliente. ¡Esa manía de que la gente de TI de creer que siempre sabe lo que el cliente realmente necesita!
Expectativas poco realistas. Nunca falta el que quiere que le fabriquen un Word y pagar solo lo que cuesta el CD pirata.
Falta de un líder efectivo para el proyecto. Bueno, la gente de TI no nació para administrar proyectos, ¡Por eso programa! Pero casi nadie respeta a un líder de proyecto que no ha programado, por eso debe ser una especie de super administrador-programador-buena-gente.
Falta de participación del usuario. El usuario solo quiere sentarse y que su programa funcione y que no le quite tiempo para entrar al facebook.
Falta de acuerdo antes que el desarrollo de inicio. Y es que, ¿Cómo podemos estar de acuerdo con todas las tonterías que el cliente pide?
Las “Ilusiones”. El usuario piensa que le darán un automóvil, el líder de proyecto cree que solo le dará tiempo para hacer una bicicleta, los programadores tienen problemas para construir las ruedas de unos simples patines, y al final el usuario va a terminar caminando, como siempre lo ha hecho (el usuario es el incauto que trabaja para el que contrató a tu empresa, le vas a quitar tiempo y al final harás mas difícil su trabajo)

Errores relacionados con los procesos

Planeamiento demasiado optimista. ¡Claro! Hacemos un módulo por día y el último integramos todo.
Falta de administración de riesgos. ¿Alguien conoce a los que se dedican a administrar esas cosas?
Falla en los contratos. Lo bueno de usar plantillas de World es que todas incluyen las letras chiquitas donde no nos hacemos responsables de errores o vicios ocultos después de seis o más meses. Que es más o menos el tiempo en el que la base de datos se irá al carajo.
No hay suficiente planeamiento. Muchas veces solo se tiene el texto que viene en la propuesta comercial.
Abandono del planeamiento bajo presión. Sobre todo cuando le dices al usuario que hacer un facebook o un twitter es normalmente más caro que hacer una simple página web.
Pérdida de tiempo al inicio del proyecto. Y cuando pasa el pánico y comienza la negación.
Saltarse las tareas iniciales. Nunca analizas y nunca diseñas, ¡Esa es tarea de ñoños!
Diseño inadecuado. ¡Porque así me enseñaron en la escuela y los profesores son gente muy capacitada que lleva años en la industria del desarrollo de sistemas!
Falta de supervisión. Porque el gestor y el líder llevan como veinte proyectos al mismo tiempo y todavía no terminan otros que ya se entregaron. Y por supuesto los programadores se pueden enseñar solitos sobre lo que el cliente quiere.
Falta de estimaciones. ¡Para que! Si solo es la autoestima de los programadores lo que se va al carajo cuando fallan los proyectos.

Errores relacionados con el producto

Requerimientos excesivos. Si no está clara la propuesta el cliente te va a meter todas las funcionalidades que pueda y si puede hacer todo su trabajo, mejor.
Cambio de requerimientos. Porque claro, el mercado cambia constantemente y hay que ser competitivos y ajustarse a esos cambios. Pero la verdad es que, es hasta que el usuario comienza a usar el sistema, que se da cuenta de que nadie tenía idea de lo que se tenía que hacer realmente.
Developers muy meticulosos. Todos los programmers somos obsesivos compulsivos, es lo que nos metió en esto desde un principio.

Errores relacionados con la tecnología

Síndrome de la panacea. ¡Claro! Hay que usar Struts, Spring y Hibernate… siempre y ya con eso quedan bien todos los sistemas.
Sobre-estimación de las ventajas del uso de una nueva herramienta. Como cuando usas una de esas herramientas de business intelligence o un CMS, que según el vendedor, harán prácticamente todo lo que el cliente te pida.
Cambio de herramientas a mitad del proyecto. Si no funciona Struts usa JSF, porque es mejor, si no funciona tampoco pues usa Spring MVC, porque es más simple, si no funciona mete Flex, porque se ve bien, si no funciona… y así.
Falta de un control de código fuente automático. Te apuesto que eso si no te lo enseñaron en la escuela. Y que difícil es entender y usar subversión y que todos tus compañeros lo usen, la primera vez.