> On Fri, Feb 5, 2021 at 9:06 AM Jerry James <loganje...@gmail.com> wrote: > > The configure check for JDKs > 9 does not work correctly. With > > OpenJDK 11, for example: > > > > $ javac -version 2>&1 | head -n 1 > > javac 11.0.10 > > > > All of the commands that grep java_version fail, and java_version is > > set to 1.3. It should be done as in this pull request: > > > > https://github.com/manuel-serrano/bigloo/pull/45 > > > > Speaking of JDK versions, from the perspective of Fedora, nothing > > older than JDK 8 is interesting. Oracle's JDK 7 is on extended > > support until July 2022, so it may make sense to continue supporting > > it for now, but even JDK 6 reached end of extended support more than 2 > > years ago. Some aspects of the makefiles and code could be simplified > > if you removed support for ancient versions of Java; e.g., > > api/ssl/src/Makefile wouldn't have to check JAVA_VERSION at all. > > There are some issues in runtime/Jlib/foreign.java: > > foreign.java:3705: error: incompatible types: boolean cannot be converted to > int > return (d.calendar.get(Calendar.ZONE_OFFSET) == 0); > ^ > > This is the definition of the method in question: > > public static int BGL_DATE_ISGMT(date d) > { > return (d.calendar.get(Calendar.ZONE_OFFSET) == 0); > } > > It is attempting to return a boolean value from a method declared to > return int. Should it look like BGL_DATE_ISDST (just above > BGL_DAT_ISGMT)? If so, it would be defined like this: > > public static int BGL_DATE_ISGMT(date d) > { > return (d.calendar.get(Calendar.ZONE_OFFSET) == 0) ? 1 : -1; > } > > Compilation also fails on bgl_update_date, because the first parameter > has a type "date" but no name. I assume the first parameter should > read "date date" instead? > > There are two definitions of bgl_milliseconds_to_date. I think the > second one should probably be named bgl_milliseconds_to_utc_date. I have cleaned up all these issues. All the fixes will be in the next tarball.
Thanks again, -- Manuel
signature.asc
Description: PGP signature
