【干货】扫描识别控件Dynamic Web TWAIN在线示例汇总 Dynamic Web TWAIN是一个专为Web应用程序设计的TWAIN扫描识别控件。你只需在TWAIN接口写几行代码,就可以用兼容TWAIN的扫描仪扫描文档或从数码相机/采集卡中获取图像。然后用户可以编辑图像并将图像保存为多种格式,用户可保存图像到远程数据库或者SharePoint。这个TWAIN控件还支持上传和处理本地图像。
Dynamic Web TWAIN能够在所有主流浏览器上面进行网页扫描。兼容 Firefox, Mozilla , Chrome , Safari , Opera以及其他的浏览器;目前主要有三个版本:ActiveX, Plugin 和 Mac。
本文为大家整理了Dynamic Web TWAIN在线示例,欢迎收藏!
Dynamic Web TWAIN在线示例Demo>>>
Dynamic Web TWAIN v13.1最新版下载>>>
未发布 【教程】Edraw Max(亿图图示):思维导图怎样一次性键入分支内容? Edraw Max(亿图图示)作为一款功能齐全,使用方便、快捷的全类型图形图表设计软件,不仅富含丰富的模板和例子,还可以一键轻松导入思维导图的分支内容。本文就教大家具体的操作方法吧!
目前Edraw Max(亿图图示)在线订购享75折优惠活动正在进行中,欢迎您下载、购买进行运用!
第一步:选中需要添加分支的主题形状,然后点击“思维导图”菜单栏下的“添加多个主题”;
第二步:打开之后,依次输入需要添加的分支内容,按回车键(enter)换行,每一行代表一个主题;
第三步:重复以上两步,可以在第二级分支上再一次导入第三级分支;
第四步:数据导入之后,可以跟通过“思维导图”下的“布局”对整个思维导图的主题、样式进行调整,同时还可以将数据直接导出为Word、Excel以及文本格式。
未发布 AutoVue现在支持本地2D Creo / ProE图纸 随着最新的AutoVue 21.0.1 RUP3的发布,Oracle重新引入了对2D Creo / ProE图纸的本地支持。
为了提供一些上下文,Creo / ProE工程图包含完整的“本地”数据以及图形的预处理“显示列表”版本。使用“显示列表”往往会呈现绘图的最高保真度,但是在某些情况下不会出现,或者不会保持最新。
因此,AutoVue将优先显示“显示列表”版本。但是,如果显示列表不存在,或者如果检测到它已过时,将显示原始数据,以确保用户看到最新的信息。
未发布 HTML5文档查看器PrizmDoc发布v13.0,新增文档比较功能 PrizmDoc新版本增加了多个功能,可提高文档管理流程的效率,促进更高的生产力。
PrizmDoc v13.0中最重要的新功能是文档比较。允许用户比较与Microsoft Word文档的原始版本之间所做的更改。用户选择原始文件以及更新版本,并将原始文件的所有更改(添加、删除等)显示在新的文档中,并以超链接进行快速访问。该功能对于合同条款和附录、组织图、企业标准和程序等文件特别有用。该增强功能与Microsoft Word本身的“跟踪更改”功能类似,旨在满足众多终端用户的要求。
PrizmDoc v13.0还在图像查看技术方面取得了显着进步。新的伽玛调整、图像锐化和线条加粗工具可以增强矢量、像素图像的查看,从而允许用户生成比以往任何时候更精致的效果图。图像增强工具对于医疗、工程和建筑行业特别有用,X射线、蓝图和CAD绘图之类的图像在线观看比以往更容易。
PrizmDoc v13.0新功能
文档比较
PrizmDoc新增了Microsoft Word文档比较功能。文档比较是与先前版本交叉检查文档新版本的过程,您可以看到其更改的内容。这些更改可能包括格式修改如字体或间距更改、语法更改、添加或删除单词、句子、段落。有关如何使用新的文档比较功能的更多信息,请查看以下内容:
图像工具
PrizmDoc v13.0增加了一个名为Image Tools的新选项。您可以在查看器中操作文档保真度。有关更多信息,请参阅最终用户指南。
支持Ubuntu 16.04 LTS
PrizmDoc现在支持Ubuntu 16.04 LTS。
支持Windows Server 2016
PrizmDoc现在支持Windows Server 2016。
本地SVG图标
Viewer已升级为支持本地SVG图标。您可以将默认图标替换成自己的版本。
在线帮助
部署许可部分已更新,可以更好的帮助您了解所有许可选项。
最终用户指南部分已更新:
文档比较 - 如何使用新的比较查看器
图像工具 - 如何使用新的图像工具功能查看文档
PrizmDoc服务器
解决了错误的页面计数和呈现MS Word文档的内容问题(使用MSO渲染引擎时启用了跟踪更改)。
解决了使用LibreOffice渲染引擎时AAA/AAAA Excel日期/时间格式的不正确渲染。

未发布 MailBee.NET Objects发送电子邮件(SMTP)教程二:SMTP认证 大多数SMTP服务器都要求用户进行身份验证,才能将电子邮件发送到外部电子邮件地址(属于其他域的地址)。登录/密码通常与同一服务器上用户的POP3或IMAP帐户相同。
C#: Smtp mailer = new Smtp(); SmtpServer server = new SmtpServer("smtp.company.com", "jdoe", "secret"); mailer.SmtpServers.Add(server); ... mailer.Send(); |
VB.NET: Dim mailer As New Smtp() Dim server As New SmtpServer("smtp.company.com","jdoe","secret") mailer.SmtpServers.Add(server) ... mailer.Send() |
在这种情况下,如果要使用Connect方法手动建立连接,过程如下:
C#: Smtp mailer = new Smtp(); SmtpServer server = new SmtpServer("mail.domain.com", "user@domain.com", "pass"); mailer.SmtpServers.Add(server); mailer.Connect(); mailer.Hello(); mailer.Login(); |
VB.NET: Dim mailer As New Smtp() Dim server As New SmtpServer("mail.domain.com", "user@domain.com", "pass") mailer.SmtpServers.Add(server) mailer.Connect() mailer.Hello() mailer.Login() |
如果启用SMTP认证(由于登录名和密码在SmtpServer函数中已经确定),那么Login方法将尝试使用服务器支持的最佳(最安全)的方法在SMTP服务器上进行身份验证。你也可以强制MailBee使用指定的身份验证方法,或尝试最简单而不是最安全的方法。
以下代码可以强制MailBee使用SASL LOGIN(不安全)、SASL PLAIN(不安全)或SASL NTLM(安全)的方法。只有SASL LOGIN或SASL PLAIN暂不支持SASL NTLM:
C#: Smtp mailer = new Smtp(); SmtpServer server = new SmtpServer("smtp.company.com", "jdoe", "secret"); server.AuthMethods = AuthenticationMethods.SaslLogin | AuthenticationMethods.SaslPlain | AuthenticationMethods.SaslNtlm; server.AuthOptions = AuthenticationOptions.PreferSimpleMethods; mailer.SmtpServers.Add(server); ... mailer.Send(); |
VB.NET: Dim mailer As New Smtp() Dim server As New SmtpServer("smtp.company.com","jdoe","secret") server.AuthMethods = AuthenticationMethods.SaslLogin _ Or AuthenticationMethods.SaslPlain Or AuthenticationMethods.SaslNtlm server.AuthOptions = AuthenticationOptions.PreferSimpleMethods mailer.SmtpServers.Add(server) ... mailer.Send() |
一些较旧的服务器要求客户端自己进行身份验证,但不支持SMTP身份验证。这是因为SMTP身份验证是SMTP协议的可选扩展项(称为ESMTP身份验证更为正确)。在这种情况下,你可以使用与SMTP服务器共享用户帐户数据库的POP3服务器执行POP3认证。这被称为POP-before-SMTP认证。使用MailBee,你可以采用两种方式使用POP-before-SMTP。
如果POP3和SMTP服务器名称相同(例如,两个服务器都是mail.domain.com),并且POP3服务在默认端口110上运行:
C#: Smtp mailer = new Smtp(); mailer.SmtpServers.Add("mail.domain.com", "jdoe@domain.com", "secret").AuthPopBeforeSmtp = true; ... mailer.Send(); |
VB.NET: Dim mailer As New Smtp() mailer.SmtpServers.Add("mail.domain.com", "jdoe@domain.com", "secret").AuthPopBeforeSmtp = True ... mailer.Send() |
如果服务器名称不同(例如POP3的POP.domain.com和SMTP的smtp.domain.com)或POP3端口是非标准的,请在连接到SMTP服务器之前使用AuthPopBeforeSmtp方法。
C#: Smtp mailer = new Smtp(); mailer.SmtpServers.Add("smtp.domain.com"); mailer.AuthPopBeforeSmtp("pop.domain.com", 110, "jdoe@domain.com", "secret"); ... mailer.Send(); |
VB.NET: Dim mailer As New Smtp() mailer.SmtpServers.Add("smtp.domain.com") mailer.AuthPopBeforeSmtp("pop.domain.com", 110, "jdoe@domain.com", "secret") ... mailer.Send() |
注意:POP-before-SMTP验证完成后,你无需再调用Login方法。Login方法仅执行ESMTP认证。
MailBee还支持Windows集成身份验证(使用当前记录的Windows用户的凭据登录)。例如:
C#: Smtp mailer = new Smtp(); mailer.SmtpServers.Add("smtp.domain.com", null, null, AuthenticationMethods.SaslNtlm); |
VB.NET: Dim mailer As New Smtp() mailer.SmtpServers.Add("smtp.domain.com", Nothing, Nothing, AuthenticationMethods.SaslNtlm) |
如果你开发的是在匿名IIS或ASP.NET用户文本中运行的ASP.NET应用程序(因为当前记录的用户是IIS用户而不是使用该应用程序的人员),那么你无法使用它。
未发布 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日

未发布 百度正式开源其RPC框架brpc 9月14日,百度正式在GitHub上基于Apache 2.0协议开源了其RPC框架brpc。brpc是一个基于protobuf接口的RPC框架,在百度内部称为“baidu-rpc”,它囊括了百度内部所有RPC协议,并支持多种第三方协议,从目前的性能测试数据来看,brpc的性能领跑于其他同类RPC产品。
brpc开发于2014年,主要使用的语言是C++和Java,是百度内部使用最为广泛的RPC框架,它经受了高并发高负载的生产环境验证,并支撑了百度内部大约75万个同时在线的实例。据了解,百度内部曾有多款RPC框架,甚至在2014年时还开源过另外一款RPC框架sofa-pbrpc。那brpc是在什么样的背景下诞生的?它有什么样的优势?又为何要开源?就这些问题,InfoQ记者采访了brpc负责人戈君。
Q:谈谈brpc的一些基本情况?什么时候开始研发的?经过了怎么样的迭代和升级?目前在内部应用情况如何?
戈君:brpc于2014年创建,在百度内部称为“baidu-rpc”。到目前为止,brpc一共进行了3000次左右的改动,现在仍在持续优化中,百度内的wiki上可以查询到每次改动的描述。brpc的主要语言是C++和Java,对其他语言的支持主要是通过包装C++版本,比如brpc的Python版包含C++版的大部分功能。
brpc目前支撑百度内部大约75万个同时在线的实例(不含client),超过500种服务(去年的统计,现在已不统计这类数据)。Hadoop、Table、Mola(另一种广泛使用的存储)、高性能计算、模型训练、大量的在线检索服务都使用了brpc。brpc第一次统一了百度内分布式系统和业务线的通信框架。
Q:为什么百度当时要研发brpc?
戈君:我们在实践中意识到,RPC作为最基础的通信组件,当时的百度已经不领先了。我当时的经理刘炀曾是Google的工程师,非常重视基础架构的建设,也愿意在这个方向投入资源。
我们在内部会更加深入地讨论这些问题。“好用”有时看起来很主观,但其实还是有据可循的,它的关键点是能不能真正地提高用户的效率:开发、调试、维护都要考虑到,如果用户效率真的被提高了,用户会想着你的,靠吹嘘或政令推广的东西得不了人心。我们创建brpc的初衷是解决百度业务所面临的实际挑战,同时也希望成为百度同学最喜爱的工具,哪怕离开百度也会怀念brpc。我们希望在提供了一个好用框架的同时,也展现了一种工作方法:注释怎么写,日志怎么打,ChangeLog怎么写,版本怎么发布,文档怎么组织,甚至对未来不在百度的同学的工作也有帮助,所以从这点来说brpc从一开始就是拥抱开源的。事实上,我们在口碑上做得还不错,brpc的wiki可能是百度内被点赞最多的内容之一。
Q:与其他的一些开源的RPC框架相比,brpc的优势是什么?
戈君:brpc主打的是深度和易用性。一方面我们没有精力像gRPC那样摊大饼,什么都做。另一方面我们也注意到gRPC(包括更早的Thrift)的深度和易用性并不够。技术方面的东西就是这样,看示例程序,文档非常牛逼,但实战中可能就是另一回事了,为什么各个公司都要造自己的轮子,一个隐藏原因就是表面高大上的东西在一些细节上让你无法忍受。
RPC真正的痛点是什么?是可靠性、易用性和定位问题的便利性。服务中不要出现不可解释的长尾,程序的可变项要尽量少,各种诡异问题要有工具支持快速排查。而这些在目前开源的RPC框架中做的并不好,它们大多看着很牛,但就是无法在自己组织中推广开来。回到前面那三点,brpc是如何做的呢?
- 可靠性。这一方面是代码质量问题,通过为brpc团队设立很高的招聘门槛,以及在团队中深入的技术讨论,我们确保了稳固的代码基础。另一个问题是长尾问题,这是设计问题,brpc其实包含了很多模块,其中的bthread是一个M:N线程库,就是为了更好地提高并发避免阻塞。brpc中的读和写都是wait-free的,这是最高程度的并发。技术细节请点击链接查看。
- 易用性。有种设计是什么选择都做成选项丢给用户,号称功能都有,但一旦出问题,则是用户“配置错了”。而且这样用户还非常依赖开发团队,没有开发团队的支持基本用不了,开发团队有足够的理由扩充团队。这么做其实非常不负责任,用户面对海量的选项也很难受。brpc对于增加选项非常谨慎,框架能自己做判断的绝不扔给用户,所有用户选项都有最合理的默认值,不设也能用。我们认为这对用户体验来说非常重要。
- 定位问题的便利性。这点其它开源框架目前做的都不好,正常使用是可以的,但出问题就麻烦了。这个问题在百度内部其实也很严重,brpc之前用户排查问题都要拉RPC同学一起排查,RPC框架对用户是个黑盒,用户根本不知道里面发生了什么。按我们的经验,基本每天都有几个用户在群里问server卡顿,client超时之类的问题,排查问题是常态,人手必然不够。时间长了用户就觉得你这个框架各种问题,人还拽的不行很少回他们消息。brpc的解决办法是给server内加入各种HTTP接口的内置服务,通过这些服务,用户可以很快看到server的延时、错误、连接、跟踪某个RPC、CPU热点、内存分配、锁竞争等信息,用户还可以使用bvar来自定义各类统计信息,并在百度的运维平台NOAH上汇总。这样大部分问题用户可以自助解决。其实我们去看也是看这些,只是会更加专业。内置服务的具体说明可以看这里。
Q:作为公司内部的RPC框架,在服务治理方面有什么考虑?
戈君:百度内部RPC使用非常广泛,基本都是RPC调用,一些产品线还会通过local RPC隔离工程框架和策略代码。这么多年下来,服务周边的系统也比较全面了:编译是BCLOUD,发布是Agile,服务注册和发现是BNS,认证是Giano,监控和运维是NOAH。在百度内部,brpc和这些系统做了比较紧密的绑定,用户体验是一站式的。虽然在开源版本中,这些结合大都删掉了,但用户可以根据自己组织中的基础设施来进行定制:交互协议,名字服务,负载均衡算法都可以定制。对于其中一些特别通用的,我们希望用户反馈到开源版本中来以方便所有人。
Q:之前百度还开源过sofa-pbrpc,brpc与它的区别是什么?
戈君:sofa-pbrpc也是百度开发的一个比较早期的RPC框架,属于sofa编程框架的一部分,在搜索有应用。brpc相比sofa-pbrpc有如下优点:
- 对协议的抽象更一般化,并统一了全百度的通信架构。bprc能容纳非常多的协议,基于Protobuf的,基于HTTP的,百度内的nshead/mcpack,开源的Redis/Memcached,甚至RTMP/FLV/HLS直播协议,brpc能逐渐地嵌入现有系统,而不需要彻底重构,但sofa-pbrpc则不具备扩展协议的能力。类似的,sofa-pbrpc也无法定制负载均衡算法,brpc默认提供round-robin、随机、一致性哈希,Locality-aware(局部性感知)四种算法,用户还能定制。
- 多线程质量更好。多线程编程是非常困难的,看起来简单的RPC遍布多线程陷阱,比如处理超时的代码可能在RPC还没发出去时就运行了;发送函数还没结束,处理回复的回调就被运行了;一个回复还在被处理另一个回复回来了,诸如此类。另外,一个异步RPC的回调里发起一个同步RPC会发生什么,带着锁做同步RPC会发生什么。这些问题我们都不能在sofa-pbrpc中找到满意的答案。
- 完备的调试和运维支持。解决这个问题的本质还在可扩展性,你如何让用户参与进来定制他们感兴趣的指标,为此我们设计了bvar,让用户能用比原子变量代价还小的方式自由地定制各种指标,用户能在浏览器上看到指标的变化曲线,或在运维平台NOAH看到汇总的监控数据。brpc还加入了大量内置服务方便用户调试程序,查看连接,在线修改gflags,追踪RPC,分析CPU热点,内存分配,锁竞争等一应俱全。
无需讳言,brpc在诞生之初和sofa-pbrpc在百度内部是有竞争关系的,但就像其他地方一样,这种竞争带来了活力。类似的,brpc和其他已经开源的RPC框架也是良性的竞争关系,在比拼谁能真正提高用户效率的过程中共同进步。每个用户都可以去对比代码、文档质量,接口设计,易用程度,扩展能力等,投出自己的一票。
Q:谈谈brpc的整体架构?
戈君:技术栈无外乎是从传输层垒到应用层,就略过不讲了,具体可以去看下开源出来的文档。brpc在架构上强调“在不牺牲易用性的前提下增强可扩展性”,比如brpc支持非常多的协议,在百度内部一个brpc server同端口可以支持二十几种协议,这对于服务的平滑迁移就非常好用。
Client端的协议也非常多,用户用brpc和bthread用得很爽,所以希望我们最好能统一所有的客户端,像对Redis和Memcached的客户端支持也是在这个背景下做的,这两个客户端比官方Client好用多了,感兴趣的读者可以去尝试一下。但这么多协议的配置非常简单,填个字符串就行了,比如HTTP就是把ChannelOptions.protocol设为“http”,Redis就是“redis”。Server端甚至不用设,它会自动判断每个client的协议,怎么做到的开源文档里也有。
名字服务、负载均衡也都可以定制。但为了对用户负责,我们也不鼓励“太自由”的定制,比如一点点需求的变化就要搞个新的,这时更需要想清楚本质区别是什么。这个事情我们在百度内的支持群里每天都在做,我们是开放的”乙方”,但我们也是严厉的”乙方”。
Q:brpc的性能如何?这么高的性能是怎么做到的?
戈君:性能是我们非常看中的一点,它和用户体验也是紧密联系的。好用但性能不行,或不好用但性能很牛,用户会很难受,我们不希望用户纠结。从另一个角度来看,在推广初期,我们要说服产品线用brpc靠什么?最直观的就是性能提升。而且这儿的性能不能停留在benchmark的图片上,而是能在真实应用中体现出来。开放出来的案例文档中或多或少都包含了性能提升,具体如下:
- 百度地图API入口
- 联盟DSP
- ELF学习框架
- 云平台代理服务
Q:为什么要将brpc开源?接下来在开源项目的迭代方面有什么计划吗?
戈君:因为马上还有不少依赖RPC的百度系统要开源啊。RPC作为最基础的组件,开源不仅仅是为了自身,也是为其它开源项目铺路,比如说我们马上还会开源基于brpc的RAFT库,搭建高可用分布式系统非常方便;以及使用brpc的bigflow,让流式计算变得很顺手。这些年百度对开源的认识也在不断加深,开源看似曝光了百度的核心技术,但带来的生态影响力更重要。从Apollo、PaddlePaddle开始,百度真的开始拥抱开源了。brpc的开源版和内部版很接近,只是去掉了对百度内部独有的一些基础设施的支持,我们在内网写的深入分析RPC技术细节的文档也都一并开源了,后续也会及时推送改动,请大家放心。这是一个活项目,不会拉个开源分支就不管了。
查看更多资讯>>>
未发布 Java新版本的开发已正式进入轨道,版本号18.3 Java 9在9月21日正式发布,同时Oracle宣布将Java新版本的发布周期调整为每半年一次。目前,Java新版本的开发也已正式进入轨道。就已公开的消息来看,下一个版本的Java预计会在2018年3月发布,版本号将会是18.3,已经规划加入的特性包括JEP 286和296。
根据reddit站点上的讨论,首先更新的是JEP 296,Valhalla预计很快也会加入进来。OpenJDK的主页面则显示,已确定要在18.3版本实现的是JEP 286和296。
JEP 296主要是将JDK仓库群(JDK Repository Forest)合并为一个仓库,旨在降低管理大量仓库群的成本。根据InfoQ之前的报道,该仓库群的合并已经完成。这些软件仓库是在OpenJDK发展史上历次分裂生成的,在OpenJDK 9及以前的版本中将会继续存在。在这次合并操作之前,OpenJDK曾分裂为多个不同的Mercurial软件仓库群,这导致了许多问题,例如不能以原子方式对多个软件仓库应用漏洞修复(Bug Fixes)。在OpenJDK合并完成后,只会有一个软件仓库,并复制在三个开发线上。为了简化仓库的管理,JDK中还创建了用于在合并和未合并版本间移动更改的工具。
JEP 286提议在Java中引入局部变量的类型推断,该JEP在2016年提出,InfoQ曾经报道过该JEP的概况和相关的开发者调查结果。该JEP旨在减少编写Java代码相关的仪式性的内容,提升开发人员的体验,同时还要保证Java语言的静态性。它会减少开发人员在声明局部变量时,没有必要的变量类型声明。如果该JEP实现的话,在声明局部变量的时候,就可以采用类似如下的方式:
var list = new ArrayList(); // infers ArrayList
var stream = list.stream(); // infers Stream
这种语句只能用于带有初始化器(initializer)的局部变量、增强的for-loop中的索引以及传统for-loop中声明的局部变量。它不能用于方法声明、构造函数声明、方法返回值、字段、catch语句以及其他类型的变量声明中。
关于局部变量的类型推断,不管是JVM体系中的语言还是其他语言都提供了一定形式的支持,比如C++(auto)、C#(var)、Scala(var/val)以及Go(通过:=进行声明)。至于该使用var作为关键字,还是使用let或类似于C/C++中的auto作为关键字,之前曾经有过一个面向开发者的调查。大约84%的回答表明定义可变内容的变量用关键字var是恰当的,只有百分之几的回答者建议使用auto更合适。根据Java语言架构师Brian Goetz介绍,该功能应该使用关键词var。
关于该特性的用法,在reddit上有一些讨论。有人表示,即便在支持“auto”语法的语言中,该特性使用的也比较少,因为有些人希望一眼就能看出变量的类型是什么。也有人认为,var有它的适用空间,在小的代码块中,直接用它实例化对象是可以的。如果是作为方法返回值的话,还是希望明确声明类型,Java的类型推断并不支持方法返回值,这一点倒不必担心。如果函数或代码块比较长的话,就不建议使用var了并要考虑适时进行代码的重写。时间和经验将会让我们更加明确应该在何时使用新功能,就像Optional刚出现时,也是耗费了一些时间才明确其推荐适用场景。
Valhalla项目中包含了一些有趣的JEP,包括值类型(Value Type)、针对原始类型实现泛型功能、增强的volatile等,外界很期待这些内容最终也能添加到新版本中。
2017慧都十四周年狂欢搞事情!砸金蛋100%抽现金红包、满额豪送iPhone X、iPhone 8、DevExpress汉化免费送、团队升级培训套包劲省10万元......更多惊喜等您来探索!
