Feda /dev/ - No Javascript allowed

Normas
spoiler
Personas non gratas
Memes feda dev




_Rpv

Joder, menudo apellido tienes Alberto xD ( @desu )

Fyn4r

@desu es el auténtico M.Rajoy?

Grise

Mira Alberto, he visto tu GitHub y me ha dado un vuelco la sangre, me ha dado, mecagondios. Algo se ha removido dentro de mi, me cago en su puta madre, me cago en su puta madre por haber parido un GitHub con semejante nivel, mmmmmmmmm, artillería, artillería ingenieril, Alberto.

7 1 respuesta
eondev

#2907 qué poca cosa tienes. Donde está todo eso que nos cuentas que haces? Me extraña que un CV tan grande como el tuyo sea ijgnorado por Gaagle ;/

Troyer

Si que existe, me pasó su repo por privado.

afhn

me cago en mi puta vida, por qué está siendo tan difícil parsear un array 2D con el configparser?

RTeks

Puede sonar un poco extraña la pregunta, pero puede un proceso abrir 2 JVM de 2 versiones distintas de java simultaneamente?
Es que mi proceso en java 11 necesita correr un programa externo que es compatible solo con java 8.

1 respuesta
eondev

#2917 no lo entiendo, qué problema tienes en ejecutar el jar? El programa ya está compilado al bytecode, no debería haber problemas no?

2 respuestas
kidandcat

#2918 no, que va, es que le cambian las versiones a Java porque va cumpliendo años

1 respuesta
RTeks

#2918 El problema es que ese jar ejecuta un programa externo, y este programa solo es compatible con java 8. Entonces al correr con java 11 peta.

eondev

#2919 Pero el bytecode generado ese compatible. Osea, tú corres Java 8 copmilado a bytecode y debe correr sobre la JVM 11. :psyduck:

1 respuesta
RTeks

#2921 No, un .class compilado en java 11 no es compatible con java 8.

1 respuesta
eondev

#2922 Pero estamos hablando de un compilado de Java 8 sobre Java 11.

BTW, el programa por qué te falla. Falta de librerías?
https://stackoverflow.com/questions/54439762/java-jdk-11-breaking-old-jars-programs

2 respuestas
RTeks

#2923 Es incompatible el programa con versiones superiores a java 8.
Pero vamos que creo que lo he arreglado ya.

1 respuesta
eondev

#2924 Pero en la teoría, no debería fallar. Y según leo, debe ser por falta de alguna librería que sí incorporaba el SDK de Java 8. A partir de Java 11 se han quitado cosas de encima y ya no son parte del core por lo que leo.

1 respuesta
kidandcat

#2923 Cuando se cambia la major version, significa que ha habido un cambio incompatible en el software:

https://semver.org/

Normalmente en el cambio de una major no se promete retrocompatibilidad

1 respuesta
eondev

#2926 ? xD
Cuando tú compilas con Java 5, tu binario bytecode puede correr o debería correr sobre la JVM versión 6.
Cuando tú compilas para Java 6, tu binario bytecode no puede correr sobre la JVM versión 5.

1 respuesta
kidandcat

#2927 No

1 respuesta
eondev

#2928 Sí. La JVM usualmente siempre ha podido correr bytecode de versiones más antiguas.

2 respuestas
kidandcat

#2929 https://www.oracle.com/technetwork/java/javase/compatibility-417013.html#jdk7

PD: "usualmente", :+1:

PDPD: Te he puesto java 7, busca el resto de versiones, tampoco me pagas para tanto

1 respuesta
eondev

#2930 Ahí estás hablando de compilar código Java bajo la JDK. Yo estoy (más bien, se está) hablando de ejecutar bytecode sobre la JVM.

1 respuesta
Zoko

El Github de Desu no está mal, mucho snippet pero está bien, al menos se nota que curiosea con ciertas cosas que no conoce.

1 respuesta
kidandcat

#2931 Edit: Voy a rectificar, porque uno tiene su paciencia finita. Tu tienes toda la razón, disculpame, tu como creador de la JVM seguro que la conoces infinitamente mejor que yo. Asi que voy a ahorrarme mis esfuerzos por ayudar, ya que tu puedes resolver cualquier duda que tengas por tí mismo. Ánimo

1 respuesta
desu

#2913 no me llamo Alberto

En mi github no hay proyectos los tengo en gitlab.

En github tengo snippets que uso a veces o cosas que me quiero pasar del pc del curro a casa.

1 respuesta
HeXaN

#2932 Lo mejor son los repositorios con el cálculo del factorial.

1 1 respuesta
eondev

#2933 Te lo cito:

For this reason, it is recommended that code is written in such a way so that it does not depend on unspecified behavior: In this scenario, the problem is not an incompatibility in the platform, is it a bug in the code.

Incompatibilities between Java SE 7 and Java SE 6
Java SE 7 is strongly compatible with previous versions of the Java platform. Almost all existing programs should run on Java SE 7 without modification. However, there are some minor potential source and binary incompatibilities in the JRE and JDK that involve rare circumstances and "corner cases" that are documented here for completeness.

Se entiende perfectamente que no es la norma, pues la intención principal de una versión mayor de Java es ser retrocompatible con al menos, el bytecode compilado en versiones anteriores.

Pero bueno, visto el tono y tu contestación final de crío, lo dejo xD

2
Ranthas

#2929 dependiendo de las versiones.

Por ejemplo, jaxb dejo de ser parte del core en la version 9, por lo q si lo usas en versiones 9 o superior tu programa te va a soltar un classnotfound como un burro

Pero no es lo habitual

EDIT: vale veo que ya lo menciones en #2925, es justo por eso

1 respuesta
eondev

#2937 Sí, y en Java 11 aún es más gordo, se han ido deshaciendo de muchas más cosas (el enlace de SO en #2923 )

1
desu

#2935 es el scip, te animo a hacerlo. Yo voy casi a la mitad y es sufrir y llorar sangre.

Grise

#2934 No me jodas el meme, desgraciado.