#55 No recomendaria a nadie intentar determinar si estas afectado o no por este problema analizando el comportamiento de tu aplicacion y lo que intenta guardar en los logs. Personalmente recomendaria aquellos utilizando log4j2 que asuman que estan afectados y actualizen
#35 No es necesaria ninguna accion especialmente extraña con Log4j2 para estar afectado por este problema. Si utilizas log4j2, asume que estas afectado por este problema (porque casi seguro, lo estas). La unica opcion es actualizar log4j2 a 2.15+
#54 Que la movida es que te pueden mandar una peticion en la que figure ese texto asi formado, no?
"$"
Para que el jodio log4j se lo coma 
Ejemplo:
POST http://mipagina.com/user
#46 Hola,
Tu mensaje no es correcto. El fallo de log4j2 es critico, y en muchas ocasiones puede utilizarse independientemente de la version de OpenJDK en la que esta corriendo log4j2. La unica opción segura es actualizar Log4j2
#25 Correcto. Esta vulnerabilidad debe seguir considerandose critica y requiere una actualizacion de Log4j2.
#17 El uso de una version mas nueva de OpenJDK (ya sea en referencia a jdk8u121, jdk8u191 o 11.0.1) provee unicamente de una mitigacion parcial del problema. En muchas circunstancias, sigue siendo posible explotar la vulnerabilidad utilizando otras alternativas.
Esta vulnerabilidad debe considerarse critica independientemente de que version de OpenJDK se esta utilizando. La unica opcion para evitar el problema es actualizar Log4j2 a la ultiva version de 2.15 disponible (2.15rc2 en el momento de escribir este mensaje)
#48 una afirmación bastante atrevida. Veo tres formas de interpretar esto. O bien considerando que la mayoría de trabajos en informática son malos (y Java no es la excepción). O porque se desconoce el mercado laboral en el mundo de Java, o finalmente, porque se tiene una preferencia personal muy fuerte en contra del lenguaje. Pero ninguna de esas interpretaciones hacen que los trabajos en Java sean peores que otros
#52 Cuarta: La mayoría de trabajos en Java son para cárnicas que buscan un picacódigos temporales para mantener la aplicación hecha en 2008 para X cliente.
Porque al menos aquí en España no hacen aplicaciones punteras en Android. Ni ningún videojuego exitoso de móvil.
Pocas aplicaciones de escritorio que funcionen bien en Java, algún IDE.
#23 completamente cierto, no me verás a mi negarlo. Pero últimamente en entrevistas de trabajo, donde la gente puede elegir que lenguaje utilizar, la mayor parte opta por otros lenguajes, Python principalmente. No es mayor problema porque la gente espabilada, si luego tiene que ponerse con Java lo hace rapido
#5 Sigue dandose programación en Java? Era mi impresión que a día de hoy sería mas común ver otros lenguajes tipo Python o Javascript. Pero bueno, ya han pasado años
#23 completamente cierto, no me verás a mi negarlo. Pero últimamente en entrevistas de trabajo, donde la gente puede elegir que lenguaje utilizar, la mayor parte opta por otros lenguajes, Python principalmente. No es mayor problema porque la gente espabilada, si luego tiene que ponerse con Java lo hace rapido
#23 sigue siendo el lenguaje más usado
Nop. Según esto es C https://www.tiobe.com/tiobe-index/ según este Python https://pypl.github.io/PYPL.html y según este Javascript https://www.freecodecamp.org/news/stack-overflow-developer-survey-2020-programming-language-framework-salary-data/
#34 Esos estudios pueden servir para hacerse una idea de la evolución de un lenguaje a largo plazo, o para ver lenguajes que empiezan a despegar, pero no para extraer el dato de "el lenguaje más usado". Y mucho menos el TIOBE.
Ya el propio concepto en sí es bastante inasible, pero es que encima el modelado es de traca: TIOBE contabiliza los hits en motores de búsqueda de la query " programming". Eso representa un sesgo enorme hacia los nombres con poca buscabilidad, como C, y perjudica a otros como PHP o Prolog e incluso a otros que también tienen baja buscabilidad y que debido a esto tienen algún término de búsqueda como "golang" o "rustlang".
Y lo peor ya no es eso, sino que quitando a Google las fuentes de lo mejorcito: Amazon, Ebay... pero no stackoverflow o reddit Y así salen métricas como ésta de C (2016: 16%, 2017: 6%, 2018: 15%) o mi preferida:
El lenguaje más buscado en 2013 fue... TSQL WTF?
#23 La mayoría de trabajos que piden Java son malos...
#48 una afirmación bastante atrevida. Veo tres formas de interpretar esto. O bien considerando que la mayoría de trabajos en informática son malos (y Java no es la excepción). O porque se desconoce el mercado laboral en el mundo de Java, o finalmente, porque se tiene una preferencia personal muy fuerte en contra del lenguaje. Pero ninguna de esas interpretaciones hacen que los trabajos en Java sean peores que otros
#52 Cuarta: La mayoría de trabajos en Java son para cárnicas que buscan un picacódigos temporales para mantener la aplicación hecha en 2008 para X cliente.
Porque al menos aquí en España no hacen aplicaciones punteras en Android. Ni ningún videojuego exitoso de móvil.
Pocas aplicaciones de escritorio que funcionen bien en Java, algún IDE.
#17 Un compañero de trabajo ha hecho un fp y lo hizo en Java. Por referencias otra persona había hecho cursos de Java. Si, aún se enseña. En la educación reglada se va a lenguajes con tipados estáticos.
#24 Y tiene sentido, porque pasar de Java a Python es un paseo, pero al revés puede ser un poco más conflictivo. Y ya pasar de Python a C ni te cuento porque, como te toque manejar punteros y no tengas una base de conocimiento bien sólida, estás en un problema
#39 Python solo trabaja con punteros. Pero los punteros de C son bastante más jodidos. Yo hice punteros hace la tira de años en el módulo con Pascal y Delphi. Ya no me acuerdo de nada.
Python o lenguajes de alto nivel, son buenos para aprender, pero sí, creo que es mejor empezar con lenguajes más estrictos. Pero, si quieres torturar a tus alumnos, el mejor lenguaje es ADA. Con ese en teoría se aprende a estructurar el código.
#31 Esto que comentas no es totalmente cierto. La mayor parte de las implementaciones libres de la maquina virtual de java estan basadas en OpenJDK. OpenJDK es la maquina virtual que Sun libero poco antes de ser comprada por Oracle. Aunque al principio no incluia todos los componentes, en las ultimas versiones el JDK que ofrece Oracle es una build de OpenJDK. OpenJDK es GPLv2, por lo que incluso si el juicio hubiera ido a favor de Oracle, esto no habria afectado a OpenJDK (aunque quiza a otras implementaciones como OpenJ9). Igualmente, aunque Oracle no suministrase parches de seguridad, otra gente podria hacerlo (de la misma manera que a dia de hoy, Oracle distribuye parches de seguridad para OracleJDK8, pero para OpenJDK8 los parches de seguridad no necesariamente vienen de Oracle
#64 llevo seis años (aunque no todos en la división de AWS). He trabajado tanto en España como ahora en EEUU, y si bien no tenía queja en España, mi sensación es que en EEUU el trabajo es más light (aunque no creo que sea por horas o exigencias, creo que es subjetivo porque el trabajo que hago ahora es más interesante).
#23 #27 Soy ingeniero de AWS. Sinceramente, no se de donde vienen estos comentarios. Llevo varios años aquí y nunca he tenido la impresión de que esto fuera un quema gente, y por lo que hablo con compañeros, ellos tampoco.
No trabajo más horas que las 8 diarias, las contadisimas ocasiones que he trabajado más porque había alguna historia me han dado días libres para compensar. He pasado por varios equipos (no porque las cosas estuvieran mal, sino porque quería probar otras cosas) y algunos de mis amigos más cercanos son ex-compañeros. Personalmente, si alguien me preguntase, le recomendaría encarecidamente el curro.
#64 llevo seis años (aunque no todos en la división de AWS). He trabajado tanto en España como ahora en EEUU, y si bien no tenía queja en España, mi sensación es que en EEUU el trabajo es más light (aunque no creo que sea por horas o exigencias, creo que es subjetivo porque el trabajo que hago ahora es más interesante).
Dudo que quede alguien leyendo por aqui, pero esta es una herramienta publicada por el equipo de AWS Corretto (del que formo parte) que permite parchear esta vulnerabilidad en caliente, sin reiniciar la maquina virtual de java:
https://github.com/corretto/hotpatch-for-apache-log4j2