未发布 VectorDraw Developer Framework v7.7012.0.4发布丨附下载
VectorDraw Developer Framework（VDF）v7.7012.0.2更新内容：
WebJS
新增需求（7.7012.0.3）
漏洞（7.7012.0.2）
漏洞（7.7012.0.3）
Engine
漏洞（7.7012.0.2）
70001114 手柄选择未正确更新，并且屏幕上仍然显示
70001116 UpdatePropertiesFromPrinter丢失纸张信息
70001117 GetLineTypeDlg的Wrapper不会返回正确的行类型
漏洞（7.7012.0.3）
未发布 ActiveX组件CADViewX v12发布，支持最新的AutoCAD®DWG 2018版本 CADViewX一款能让应用程序具有强大CAD图像浏览和打印功能的图像处理工具，无需任何CAD软件或查看器即可打开、浏览、打印AutoCAD等几十种格式的图像文件，还能享受直观的鼠标滚轮缩放、拖拽、平铺印画功能。
CADViewX v12更新内容
CADViewX v12是用于导入和导出CAD文件的新版本的ActiveX组件。
现在，CADViewX Lite支持最新的DWG版本 - AutoCAD®DWG 2018。借助CADViewX Lite开发的应用程序将能够查看最新的图纸。
要测试CADViewX Lite并将DWG 2018查看功能添加到应用程序中，请下载试用>>>
未发布 VCL图表控件包TMS Grid Pack v6.7.2.2发布丨附下载 TMS Grid Pack是一款功能齐全的VCL图表控件包，包含TAdvStringGrid、TAdvColumnGrid、TAdvSpreadGrid、TAdvGridExcelIO、TAdvGridRTFIO、TAdvGridPDFIO和TDBAdvGrid多个控件于一体，能帮助用户节省大量的开发时间和费用。
v6.7.2.2
改进：
修复：
v6.7.2.1
改进：
修复：
分组的TDBAdvGrid中通过列行访问单元格的问题
TAdvStringGrid中edEditBtn在线编辑器按钮点击和隐藏选项的问题
TAdvGridPDFIO中单行网格的问题
TAdvStringGrid中鼠标滚轮的问题
TAdvStringGrid中单列网格索引排序的问题
TDBAdvGrid中的剪贴板复制的问题
【慧都十四周年庆预热开启！全场满额送七级豪礼，AppleMac笔记本电脑、iwatch、iPad等您来拿！】
活动时间：10月1日-10月30日
未发布 CAD .NET v12发布，提高GDI+可视化速度并可导入AutoCAD®DWG 2018丨附下载
CAD .NET新版本大大提高了GDI+可视化的速度。当加载具有复杂结构的大文件时可以很明确的体验到。例如，包含大量实体的一些文件的可视化速度现在提升了十倍。
更重要的是，CAD .NET现在可以导入最近发布的最新DWG版本的AutoCAD®DWG 2018。
此外，CAD .NET使用非Unicode SHX文本和形状的方式已经大大改善。这种改进对于使用本地非Unicode字体的系统尤其重要，例如德语、法语、希伯来语和其他语言的特殊字符。
CAD .NET 12包含的改进和修复的内容列表：
GDI+可视化速度大大提高
导入AutoCAD®DWG 2018
改进非Unicode SHX文本/形状支持
Bug修复
试用、下载、了解更多产品信息请点击"咨询在线客服"
未发布 数据库解决方案Data Abstract 9发布丨附下载 Data Abstract 9是一次重要的版本更新，而更重要的是它的基础：Remoting SDK框架。查看详细的更新日志，以获得所有功能、增强和错误修正的完整列表。
未发布 Oracle正式发布Java 9，引入新的Java编程组件 Java SE 9.0于2017年9月21日发布。
JDK 9的核心变化就是引入了一种新的Java编程组件，也就是模块，按照Oracle的说法，它是一个可命名的、自描述的代码和数据集合。模块技术的核心目标是减少Java应用和Java核心运行时环境的大小与复杂性。为此，JDK本身进行了模块化，Oracle希望通过这种方式提升性能、安全性和可维护性。为了支持Java 9的模块，引入一种新的模块化JAR文件形式，按照这种形式会在其根目录中包含一个module-info.class文件。Oracle同时提供了工具，允许我们组合和优化一组模块，形成自定义的运行时镜像（image），这样的镜像不必将整个Java运行时包含进来。模块化所带来的其他变化包括从Java运行时镜像中移除了rt.jar和tools.jar。 Java社区进程（JCP）执行委员会的成员Ben Evans认为最急需重构的应用恰好就是最适合进行模块化的应用。如果你已经备受Lava Flow/God Class/Stovepipe System地狱的折磨，而且你的利益相关方明确知道这一点，那么你可能更容易说服他们进行一次完整的底层重构，通过渐进式的努力形成一个完成的模块解决方案（而不是简单重构并迁移至Java 8）是值得去做的。
Oracle宣布Java 8会是一个长期支持的发布版本，会一直支持到2022年，因此Evans认为很多的应用将会停留在Java 8上，根本不会升级到Java 9。Evans补充说，有些应用可能会让开发和构建工具链使用Java 8版本，而在生产环境使用Java 9的运行时。
对特定类型的应用来说，这是很有帮助的。例如，我曾经见到有的电子商务网站具有非常大的堆空间，其中包含了大约40G的字符串数据。Java 9的ompact Strings技术能够将这种类型的内存使用减半。这反过来又会对GC的性能带来积极的影响。对于有些应用来说（这可能就包括大型的Solr安装环境及类似场景），单单这一项收益就值得将运行时升级到Java 9。
Java 9使用G1作为默认的垃圾收集器，替代了之前默认使用的Parallel GC。Evans对这项变化的评论：
这项变更是很重要的，因为相对于Parallel来说，G1会在应用线程上做更多的事情，而Parallel几乎没有在应用线程上做任何事情，它基本上完全依赖GC线程完成所有的内存管理。这意味着切换到G1将会为应用线程带来额外的工作，从而直接影响到应用的性能。
在很多（甚至可以说大多数）场景中，这种额外的性能损耗都不是什么问题。但是，在这方面，我确实也曾经见过从Parallel切换到G1时，有一定比例的工作负载会引起性能的下降。对于这些应用来说，这种性能下降是无法接受的，所以他们无法切换至G1收集器。随着G1成为默认的收集器，这将会影响到升级至Java 9的每个应用。
JClarity的CEO Martijn Verburg认为大型的代码库需要重构为模块的形式。Verburg给出了一些通用的模块化建议，并且指出了开发人员在采用Java 9模块系统时，需要注意的一些事情：
- 阅读Paul和Sander的图书“Java 9 modularity”：它是本权威指南，提到了所有需要注意的地方，阐述了模块、包以及JAR之间如何运行的关联关系；
- 在模块边界的地方，使用定义良好的接口并且针对这些接口编程；
- 不要拆分包（split package），也就是说一个包不要分散到两个模块中。Adopt OpenJDK有个探测工具，我们可以用它来探测已有的代码；
- 确保不要存在循环依赖（Jigsaw不允许这样）；
- 模块在源码的布局上与我们已习惯的方式有所不同，需要确保构建工具能够进行对应的处理；
- Jigsaw不支持多版本。
按照Verburg的说法，核心要点在于处理循环依赖、拆分包的问题，并确保针对接口进行编码。在尝试使用Jigsaw模块化重构之前，针对已有的代码库，这些工作需要预先完成。他还澄清了一个误解，那就是只有模块化的应用才能在Java 9上运行。
由于误解，在这方面有一种FUD（恐惧、不确定和怀疑）情绪，有人误认为在Java 9上运行的必须是模块化的应用。事实并非如此，我们可以将已有的基于类路径的应用直接在Java 9上运行。这里会有一些新的安全限制，因此我们需要设置一些特定的运行时标记（除非你重构代码，使用更安全的方式来访问Java的内部资源），即便如此，默认的行为也只是警告，而不是完全阻止我们（Java 10的限制会更严格）。
Verburg认为Jigsaw会是一个基石，会让Java的演进更快，这要归功于Mark Reinhold、Alan Bateman、Mandy Chung以及Jigsaw团队的其他成员多年来不知疲倦的工作，正是他们的努力使这一切得以实现。
Java 9还引入了jshell工具。这个命令行环境为Java平台带来了读入-求值-打印-循环（Read-Eval-Print-Loop，REPL）功能。它的目的在于以即时结果和反馈的形式，简化原型的实现并帮助我们探索语言在编码时的可选项。
Verburg和Evans看到Java 9中包含了jShell都非常兴奋，但令他们失望的是，HTTP/2只是作为Java 9的一个孵化模块（incubator module）提供的。鉴于社区对这项特性的兴趣和提供的帮助，Evans认为Oracle应该投入足够的工程资源，将HTTP/2交付为GA版本。
JDK 9完整的变更列表可以在Oracle的站点上查阅。Oracle宣布会按照每六个月一次的节奏进行发布，意味着Java 9是最后一次“keystone”特性驱动的版本发布，这反映出了Oracle目前管理Java的特点。Java下一阶段的演化将会按照更短的发布周期并且会按照更加面向特性的方式来发布。Java是否依然能够在服务端技术中占据领导者地位尚有待观察。
更多资讯点击查看>>>
未发布 使用Windows兼容包简化向.NET Core的迁移 从.NET迁移到.NET Core的一个主要原因，在于后者具备在Linux上运行的能力。但是对于大型企业应用，不可能实现一步迁移到位。由此，Microsoft推荐采用一种逐步迁移做法： 第一步，迁移到ASP.NET Core（依然使用.NET Framework）；
第二步，迁移到.NET Core（依然运行在Windows上）；
第三步，迁移到Linux上；
第四步，迁移到（托管Linux主机的）Azure中。
这一做法理论上可行，但是在第二步中会有阻碍，因为缺乏关键API。用于.NET Core的Windows兼容包的推出，意在解决这一问题。该兼容包是一个NuGet软件包集合，其中包含了近两万个API，目的在于解决Web应用程序开发人员对于优秀软件库的需求。
新引入的API大体上可分为两类。一类是仅适用于Windows的API，另一类是跨平台的软件库。其中，仅适用于Windows的API包括：
Active directory；
加密；
事件日志和性能计数器；
文件系统安全；
命名管道；
注册表访问（Registry Access）；
Windows服务。
其中大部分API是与Windows操作系统紧密关联的，而相应的Linux API通常在设计上迥异。
跨平台的软件库包括：
缓存；
配置管理（ConfigurationManager），即处理遗留的app.config和web.config文件；
数据集扩展（DatasetExtensions），用于不使用ORM访问数据库；
ODBC数据库访问；
System.Configuration.ConfigurationManager（MEF v1）；
System.Drawing；
System.IO.Packaging，用于与MS Office类型的压缩文件交互；
System.ServiceModel，即WCF（Windows Communication Foundation）。
需指出的是，这些API是刻意独立于.NET Core的完整发布的。对此，Microsoft的Immo Landwerth给出了如下解释：
以独立软件包提供的原因在于：（一）不少API是仅出于兼容性的考虑而提供的。在新代码中，不应依赖于这些API；（二）不少API仅用于Windows平台。我们不希望将用户引上一条更难以跨平台迁移应用的道路。
为了易于区分仅适用于Windows的和跨平台的API，现在有一种API兼容性分析工具可用。该工具可以标记出那些在应用中不应继续依赖的API。 你可以使用与弃用API相同的抑制选项，但是也可以选择对特定平台给出抑制警告。如果你仅规划在一组特定的平台上支持你的代码，例如只支持Windows和Linux但不支持macOS，这一工具十分有用。为此，你只需编辑项目文件，添加一个PlatformCompatIgnore属性，并在该属性中列出所有要忽略的平台。
未发布 Google开源了Abseil，为C++和Python开发提供支持 Google公开了其项目内部使用的一系列C++库，随后还会公开其Python库。
Abseil已在Google历经十多年的开发，它的目的是为Google编程人员在各种项目上的工作需求提供支持，这些项目包括Protocol Buffers、gRPC和TensorFlow等。Google评价Abseil为：
- 它是从Google内部代码块中抽取出来的一系列最基础的软件库。作为基本的组成部分，这些软件库支撑了几乎全部Google在运行的项目。以前这些API是零零散散地嵌入在Google的大部分开源项目中，现在我们将它们规整在一起，形成这样一个全面的项目。
- Abseil是Google代码库的最基本构建模块，其代码经过了生产环节测试，此后还会继续得到完全的维护。
最初，Abseil提供的抽象并非C++ 14或C++ 17的组成部分，但最终它们已被添加到C++标准中。例如，Google提供一个称为StringPiece的类型，随后C++ 17也添加了一个称为std::string_view的相近类型。为了与新的C++ 17类型具有一致的API，Google将StringPiece重构为absl::string_view。从底层机制上看，如果开发人员正在使用的是C++ 17，那么Abseil的string_view默认为标准实现；如果开发人员正在使用的是C++ 17以前的版本，那么string_view默认为Google的实现。
使用Abseil的优点在于可以访问一些目前依然尚未添加到标准中的C++特性，并且一旦这些特性被添加到C++标准中，Google保证会重构这些特性为默认使用标准实现。Google鼓励开发人员使用Abseil，并提及已有超过两亿五千万行的C++代码使用它，并且几乎所有从头开始构建的项目都使用了它。这意味着，Abseil已被Google广为使用，并出于与项目需求同步的考虑而得以频繁维护。
Abseil中包括如下的库：
- base：初始化，以及其它的基础代码。
- algorithm：对C++的库的补充，并为原算法提供了基于容器的版本。
- container：提供了更多的STL类型容器。
- debugging：用于检查泄漏的调试库。
- memory：包括兼容C++ 11版本的std::make_unique()和内存管理。
- meta：包括兼容C++ 11版本的类型检查，在C++ 14和C++ 17版本的C++ 库中可用。
- numeric：兼容C++ 11的128位整数。
- strings：各种字符串工具。
- synchronization：并发原语和同步抽象。
- time：抽象了绝对时间点操作和时区操作。
- types：非容器工具的类型。
沪公网安备31011202009668号 | 沪ICP备13020027号-2 