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.
Regards,
--
Jerry James
http://www.jamezone.org/
